29_内容生产质量网关Skill：草稿生成+事实校验+发布前检查

内容生产是最容易让团队误以为"AI 已经替我们搞定了"的领域。因为草稿出来得很快，排版也像样，语言甚至比很多人写得更顺。问题恰恰就在这里：越是容易写，越容易让人忽略最后那道真正重要的门。事实有没有错、引用有没有来源、品牌口径有没有偏、法规敏感表达有没有踩线、结构是否符合渠道规范，这些都不是一个"会写"的模型天然能守住的东西。它擅长的是生成，不是背锅。

所以这篇文章的定位，不是再教一个写稿 Prompt，而是把内容生产这件事从"写出来"升级成"写得能发"。真正值钱的不是草稿生成，而是质量网关。生成层负责把东西写出来，校验层负责逐条核实事实，发布前检查层负责把不该通过的内容拦下来。三层拆开，内容系统才会越来越稳；全塞在一起，则迟早会因为一篇"看起来完全没问题"的草稿出事。

一、先戳破一个错觉：会写，不等于能发

1.1 风险真正集中的地方，是发布前而不是生成时

很多团队第一次用 AI 写内容时，最直观的感受就是效率提升太明显了。一个原本要写半天的活动稿、产品稿、行业观察、内部通告，现在十分钟就有了像样初稿。于是很容易产生一个错觉：既然最花时间的部分都解决了，剩下的就是修修语句、看看排版。实际恰好相反。越到发布前，越是风险高度集中的地方。因为内容从内部草稿变成外部输出，意味着它开始承担品牌、事实、合规和渠道规范责任。

这里最危险的点在于，AI 草稿往往"看起来像真的"。如果一篇稿子明显胡说八道，团队很容易发现；真正麻烦的是它大体没问题，只有两三个事实点模糊、一个引用不牢、一个时间口径过期、一个敏感表达踩边。这类内容最容易漏过人工快速审读，因为整篇读起来太顺了。内容质量控制真正要对抗的，不是粗糙，而是这种看似成熟的隐性风险。

这也是为什么事实校验必须和生成过程解耦。同一个模型一边生成一边自证，很容易陷入"自己说服自己"的局面。它会用更漂亮的语言包装不够扎实的事实，让错误变得更难看出来。把校验层拆出来，不是故意增加流程，而是在结构上防止"生成和审查共谋"。

二、草稿生成 Skill：输出的是 draft，不是 publish-ready

2.1 claim_list 是整个质量网关能跑起来的起点

内容生成层当然有价值，但它的定位必须诚实。它负责把结构搭起来、把内容铺出来、把写作起点往前推；它不负责自动宣布内容可以发。很多系统一开始就错在这里：生成完一篇稿子之后，默认它已经接近成稿。这种默认很危险，因为它会直接影响团队对后续审校环节的重视程度。

所以生成 Skill 的输出最好不仅是正文，还包括一份待校验的 claim 列表：

name: content_draft_builder
description: >
  根据选题、目标受众和渠道要求生成初稿结构与正文草稿。
outputs:
  - draft_text
  - claim_list
  - channel_format
constraints:
  - 所有事实性陈述必须输出 claim_list 供后续校验
  - 不得默认把草稿标记为可发布状态

这里 claim_list 是整套质量网关的关键。因为只要生成层不主动把"自己说了哪些事实"显式列出来，后面的校验就会退化成全文漫扫。全文漫扫不是不能做，而是成本高、漏检率高，而且不同审校人看到的重点也会不一致。反过来，如果生成层老老实实列出"本文有这些事实陈述需要核"，后面的校验就从模糊阅读，变成明确对账。

channel_format 也不该被当成附属字段。因为很多内容不是一稿通吃。公众号文章、新闻稿、短视频脚本、产品更新公告、内部邮件，这些内容对结构、长度、措辞和信息密度的要求完全不同。生成层如果不显式产出渠道格式信息，后面的发布前检查就无法判断这篇内容到底是不是用在正确的地方。

三、事实校验 Skill：逐条核，而不是凭感觉读

3.1 无来源支持的 claim，必须被显式拦下

整套质量网关里，事实校验是最关键的一层。因为品牌语气偏一点可以改，渠道格式差一点可以修，但事实错了，很多时候就不是修文案那么简单，而是要承担外部后果。尤其在涉及产品参数、行业数据、政策口径、案例引用、公开数字的时候，内容团队最怕的从来不是"不够精彩"，而是"发出去之后被指出不对"。

也正因为这样，事实校验不能只是"请帮我检查有没有问题"，而应该基于 claim list 做逐条验证：

name: factual_claim_checker
description: >
  对草稿中的事实性陈述逐条做来源核验并返回结论。
outputs:
  - verified_claims
  - unsupported_claims
  - source_refs
constraints:
  - 未命中来源的 claim 必须进入 unsupported_claims
  - 禁止用模型主观知识替代正式来源

这里最核心的原则是：没有来源支持的 claim，不应该被模糊处理成"似乎没问题"。它必须被明确放进 unsupported_claims。这件事非常重要，因为很多内容事故不是因为系统没查，而是因为它查不到时没有明确承认自己查不到，而是给出一种"看起来大概也对"的模糊态度。质量网关最值钱的地方，就是把这种模糊态度改造成明确结论。

另外，来源引用也要分级看待。公开网页、权威报告、公司官网、监管文件、正式新闻稿、内部确认材料，可信度和适用范围都不一样。Skill 不一定每次都要做复杂来源评级，但至少不能把"随便搜到的二手转述"当成和一手来源同等可信。校验层如果对来源质量没有基本意识，最后就只是把"有出处"和"出处可靠"混成了一件事。

四、发布前检查 Skill：让规范成为网关，而不是建议

4.1 gatekeeper 的职责，是区分必须修和可以优化

很多团队做内容审校时，容易把所有问题都当成"建议改一下"。这在生产环境里往往不够。因为有些问题不是可优化项，而是不能过线的阻断条件。比如 unsupported claims 非空、品牌禁用表述命中、法规敏感词超限、渠道结构不合规、时间已失效却仍写成当前事实。这些问题如果还只是"给个建议"，那质量控制就没有真正站住。

所以发布前检查层本质上是一个 gatekeeper，而不是一个友好的审稿助手：

name: pre_publish_gatekeeper
description: >
  基于渠道规范、品牌口径、事实校验结果和敏感词规则做发布前检查。
outputs:
  - publish_verdict: pass | revise | block
  - issue_list
  - must_fix_items
constraints:
  - unsupported_claims 非空时不得 pass
  - 渠道格式不符合时至少返回 revise

must_fix_items 这个字段特别重要。因为现实里很多审校建议一多，团队就会失去优先级判断，不知道哪些是锦上添花，哪些是不改不能发。把必须修和可以优化分开，能极大降低返工混乱。内容质量控制不是为了提出越多建议越显得专业，而是为了让真正关键的问题优先被解决。

同时也要承认，人工兜底仍然重要。但人工兜底不该是"最后看一眼随缘发现问题"，而应该建立在结构化网关之上。只有前面的事实校验、渠道检查、品牌口径检查已经把大部分机械问题挡掉，人工的最后一轮审读才有可能真正聚焦在语境、语气、策略判断这类更高价值的地方。否则人工也只是在做疲劳审校。

五、内容质量控制真正依赖的，是关键数据结构

内容网关能不能稳定工作，最重要的其实不是模型多强，而是关键数据结构有没有设计好。claim_list 连接生成层和校验层，source_refs 连接校验层和可追溯性，must_fix_items 连接网关层和执行优先级。没有这些结构，系统很快就会退回到"靠人读一遍感觉一下"的旧模式。你表面上做了三层 Skill，实际上还在用老办法工作，只是换了点术语。

评估指标也应该围绕发布质量，而不是围绕写作速度。unsupported claim 命中率、一稿通过发布率、发布后纠错率、渠道格式违规率、人工审校耗时下降比例，这些指标才能告诉你质量网关到底有没有真正降低风险。写得快当然重要，但对内容团队来说，写快十倍却发错一次，通常就足以抵掉前面省下的大部分效率。

六、总结

内容生产 Skill 真正的价值，不是把草稿生成这件事做快，而是把"不能直接发"的风险显式拦下来。生成层负责把内容搭出来，事实校验层负责逐条核真伪，发布前检查层负责把规范变成真正的门。三层分开，内容团队才不会被一堆"看起来能发"的危险草稿拖进返工地狱。

说到底，质量网关不是在减慢内容生产，而是在防止内容生产用更快的速度把错误送出去。只要这点想清楚，团队就不会再把"写得像样"误认成"已经可以发"。