内容量产的质量门：把「写得好」翻译成能跑脚本检查的规则
批量生成内容不难，难的是批量生成能用的内容。
如果产出之后还要人一条条看、一条条改，那这条产线并没有省下什么——只是把「写作」的活换成了「审稿」的活，而审稿往往更累。
破局点在于：把质量要求翻译成能跑脚本检查的规则。
这篇讲怎么做。
先接受一个前提
「写得好」没法自动判断，但「哪里明显不合格」可以。
不要试图让脚本判断文章质量。要做的是设一道门槛，把明显不合格的挡在外面，让人只看通过门槛的那部分。
这道门槛能拦掉的东西比你想的多。我们自己的内容产线跑下来，机械校验拦住的问题占了返工量的大部分。
能机械校验的七类
一、字数
最基础的一条，但中文有个坑：必须按字符数（码点）算，不能按字节算。
一个汉字在 UTF-8 里通常占三个字节，按字节数算会虚高好几倍——一篇五百字的文章会被判定成一千七百多字，直接通过了一千八百字的门槛。
用 Python 之类能正确处理 Unicode 的方式统计，别用命令行工具随手数。
二、结构完整性
该有的部分在不在：标题、小节、结尾、必要的元信息。
这类检查很简单，但能拦住「生成到一半断了」这类问题——而这类问题在批量任务里很常见，接口超时、返回被截断，产出看起来是完整的一段文字，实际少了后半截。
三、占位符和内部标记残留
生成过程中的模板占位符、内部标记、调试信息，如果漏在正文里，是最丢人的一类错误。
用正则扫一遍，成本极低。这条一定要做——我们踩过这个坑：批量产出的内容里残留了工具的内部标记，上线之后才发现，而且是被别人指出来的。
四、禁用词
项目约定不能出现的词：夸大表述、竞品的负面评价、法律敏感的承诺。
但要注意宽正则会误伤。 比如禁「保证」，但「不能保证」「无法保证」是正常表达，甚至是你想要的诚实表述。判据要精确，宁可漏报也别误报——误报比漏报危险，因为它会让人对整个检查失去信任，然后开始无脑跳过。
五、链接有效性
正文里引用的内部链接，目标页面真的存在吗？
这一条必须扫产物，不能靠人工检查，也不能靠 AI 自检。 AI 会告诉你「链接是对的」，但它核的是文件存在，不核路由前缀对不对。我们踩过这个坑：内容里的链接前缀写错了一个词，几十篇文章全是死链，构建不报错，上线之后才发现。
六、编造的具体数字
这一条最难，但也最重要。
完整的自动判断做不到，但可以做部分：扫出正文里的具体数字（价格、百分比、参数），人工过一遍看有没有依据。
更根本的做法是在生产端约束：明确规定哪些内容不许出现具体数字，只写机制。这样检查就变成了「有没有出现数字」，而这个是可以机械判断的。
七、重复度
批量生成最容易出的问题：几十篇文章开头都是同一个套路，或者互相之间大段雷同。
做个简单的相似度对比，超过阈值的挑出来人工看。
必须留给人的三类
一、事实对不对
这是机器判断不了的，也是最要紧的。
关键做法：把核实从生产里拆出来。 让写作的 Agent 自己核实自己写的东西，它会倾向于自圆其说——它会解释为什么自己是对的，而不是去查证。
由不参与写作的角色来核，效果完全不同。我们自己的产线就是这么改的，改完之后事实错误明显减少。
二、方向对不对
选题偏了、角度错了、答非所问——这类问题机器判断不了。
所以人工确认点要放在方向确定的环节，而不是成稿之后。 让流程从话题直接跑到成稿，一旦跑偏，一百篇都是废的，而且你要看完才知道。
把提纲拿出来让人过一眼，成本极低，能拦掉绝大部分方向性错误。
三、读起来像不像人写的
AI 腔是机器很难自查的东西，因为它就是这么写出来的。
能机械检查的只有一部分——某些高频套话可以做成禁用词。但整体的语感、节奏、有没有废话，只能人看。
建议做法：不必每篇都看，抽样看。抽到有问题的，回去改生产端的规则，而不是只改这一篇。
质量门的设计原则
一、门槛要能通过。 设得太严，每篇都要人工介入，产线就没意义了。设得太松，等于没有。先跑一批看实际分布，再定阈值。
二、失败要能单独重来。 跑一百篇，失败几篇是常态。要能知道哪几篇失败、为什么，单独重跑，而不是整批重来。
三、检查结果要能看懂。 报告要说清楚是哪一篇、哪一条规则、具体在哪里。只说「不合格」的检查没人愿意用。
四、检查器本身也会错。 首次跑出来的报警，先假设有误报，逐条看上下文。误报比漏报危险——它会让人对整个检查失去信任。
检查器本身会骗人，两个方向都会
这一条是我们踩出来的，值得单独说。
方向一：误报。 检查器报了一堆问题，逐条看下去发现大部分是正常表达。
比如禁用词「保证」，会误伤「不能保证」「无法保证」——而后者恰恰是你想要的诚实表述。 又比如禁「第一」，会误伤「第一步」「第一类」。
误报的危害比漏报大：一旦报告里有大量噪音，人就会开始跳过，然后真问题也一起跳过了。
应对：首次跑出来的报警，一律先假设是误报，逐条看上下文再定。规则要精确到能区分语境，宁可漏报也别宽泛匹配。
方向二：漏报，而且看起来像通过了。
比如检查脚本因为路径写错，实际上一个文件都没扫到，但退出码是 0——报告显示「全部通过」，其实什么都没查。
应对：检查器要输出「扫了多少个文件」。 数字对不上就说明有问题。这一条能拦住最隐蔽的一类失败——「假的通过」比明确的失败危险得多。
同理，验收时要数产物，不能只看脚本回显。 脚本说「已完成」和实际产出了多少文件，是两回事。
一个实际的顺序
- 先写标杆。 手工写两三篇达标的，定死标准和格式。
- 从标杆反推检查项。 这几篇为什么合格？把理由变成规则。
- 小批量跑，检查，调规则。 十篇左右，看检查器抓的对不对。
- 确认稳定后再放量。
- 每批产出后人工抽查。 机械校验拦不住内容跑偏。
跳过第一步直接放量，是最常见的浪费。
我们自己运营着一批内容站点，上面数千页内容就是用这条产线做出来的——这套东西目前是我们自用，还没有作为产品对外交付过。 如果你想按自己的流程做一套，我们可以做定制开发，可以聊聊。
产线的整体结构见内容 Agent 方案，工具层面的选择见用 n8n 跑批量内容处理。