AI 工作流发布内容前，先过五道人工审核闸

AI 工作流要落地，靠的不是更长的提示词，而是五道能留下记录的人工审核闸。谁来定题、哪些事实可以用、草稿能说到哪一步、谁按发布键、上线后页面是否和批准的一致，这五个决定仍然归人。把闸门写进交接流程，智能体才有用；拿掉它们，只是把犯错的速度调快。

这篇假设你已经有内容 brief，也有核实事实的办法。如果 brief 还只是一个题目加字数，先看内容 brief 怎么写。如果审核这一步最弱，AI 内容审核怎么做里的主张台账就是配套工具。这里只解决一件事：当脚本或 AI 助手接手交接时，人站在哪一道闸上。

AI 工作流为什么需要审核闸，而不是提示词

闸门是「下一步开始前必须被记录下来的决定」，提示词只影响下一次输出。两者的差别在智能体身上会被放大：它可以调用工具、扣积分、写记录，中间不再问一次。协议把阻止它的责任放在 host 一侧。MCP 规范写明，host 在调用任何工具前「必须获得用户明确同意」（Model Context Protocol 规范，访问日期 2026-11-02）。这句同意就是一道闸，不该只存在于一个没人看的弹窗里。

多数团队其实已经有类似的决定：编辑批 brief，事实核对人签字，发布负责人按按钮。问题出在把这些动作搬进自动化交接时，没有人重写顺序。智能体被要求一次做完五件事，剩下的控制手段只有「信不信这次输出」。

第三种是这篇要搭的流程。它开头更慢，结尾更快，因为修改发生在还便宜的时候。真正贵的不是审一次，而是上线之后才发现要改。

这里有三个角色，不该共用一个身份。模型写，脚本搬数据并记录发生了什么，人来批准。三者共用一个密钥时，记录说不清是谁做的，第一次真正重要的审核会变成调查。分开密钥不是流程繁琐，而是让发布这道闸保持可见。密钥还可以按任务新建和撤销，一次集成出问题，不必把整套账号停掉。

AI 工作流要过的五道闸，按顺序来

按下面的顺序跑。每道闸都有能观察到的通过条件，也都要产出一条能交给下一个人的记录。没有记录，就按失败处理。

1. 输入闸：批准问题。brief 只写一个读者、一个搜索意图、一个应该拥有答案的页面。通过标志是 brief 里列出了它不能重复的现有页面。search intent 怎么判讲的就是怎么确认读者到底在问什么。
2. 证据闸：批准来源。每条事实要么有网址和访问日期，要么有第一方样本和时间窗。通过标志是没有「待确认」的条目，而且核对人打开过来源，不只是看了引用。
3. 草稿闸：批准论证。草稿在第一段回答问题，每节只讲一件事，并写明边界。通过标志是审读人能指出哪一句交代了这篇不覆盖什么。
4. 发布闸：批准动作。由具名的人在自己的账号里按发布。通过标志是发布记录里有网址、时间和执行账号。智能体可以准备内容，但不能变成账号持有人。
5. 复验闸：批准结果。抓取线上页面，与批准稿逐项比对。通过标志是标题、canonical、结构化数据和内链都与记录一致，网址返回 200。

用 API 或 MCP 交接时，闸门长什么样

交接不是接一个接口就完事，而是一组权限加一条可追的记录。走 REST 或 MCP 时，调用方需要一把密钥，它的 scope 要和它被允许碰的闸门对得上。QueryWin 的开发者文档把权限分成 read、publish、spend，并写明 publish 不包含 spend（QueryWin 开发者文档，访问日期 2026-11-02）。这个分法就是发布闸的技术版本：能读草稿的密钥，不会自动变成能继续花钱的密钥。

同一份文档列出 19 个 MCP 工具，并说明工具会按 scope 过滤，只读密钥在助手那里根本看不到生成工具。文档还写了每把密钥每分钟 120 次请求、每日生成上限，以及「你回写的已发布」和「QueryWin 约 72 小时后复核过的已验证」是两个不同字段。这些是控制项，不是保证。它们说明系统能记录什么，不判断草稿是否真实。

给智能体单独一把密钥。共用密钥会把一次集成失守变成所有闸门同时失守，也会让发布记录失去意义，因为你分不清是谁动的手。

可以直接抄走的交付物：一页交接表

把这张表放进和 brief 同一个文档。它就是整套控制面：五行，每行一个负责人，一个记录证据的位置。没有负责人的闸门只是一个建议。

智能体运行之前：
[ ] brief 列出了这篇不能重复的页面
[ ] 每条事实都有网址和访问日期，或有样本和时间窗
[ ] 核对人已经打开过来源
[ ] 智能体有独立密钥，范围只覆盖这次任务
[ ] 发布动作写明了人和账号

智能体返回之后：
[ ] 草稿用一句话写明边界
[ ] 证据闸之后没有新增说法
[ ] 线上网址返回 200
[ ] 标题、canonical、结构化数据、内链都一致
[ ] 发布记录写清谁在什么时候操作

有两行很容易被糊弄。「核对人打开过来源」说的是行为，不是一个勾，所以把来源网址写在说法旁边。「线上页面一致」是一次比对，所以要保留批准稿的版本或哈希。拿不出记录，就当这道闸没发生。草稿不是决定。

这套流程会在哪里失效

多数损失来自三种失效。它们都能通过一次随意的通读，所以闸门必须被记录，而不是靠记忆。

1. 让智能体自己写 brief。输入闸退化成「模型本来想说什么」的总结，页面回答的是容易的问题，不是读者的问题。改法：生成之前先批 brief，把 brief 作为输入交给智能体。
2. 证据闸变成查链接。有人确认链接打得开，却没确认它支持那句话。来源可以真实存在，却没说草稿声称的事。改法：核对人先用自己的话把说法写在来源旁边，再和草稿比。
3. 把发布闸交给工具。集成带着 publish scope，于是它直接发布。技术上什么都没坏，记录里却写着智能体操作。改法：publish scope 只放在人用的密钥上，给智能体 read 加 spend。

我们没测过智能体跳过闸门的频率，因为跳过的闸不会留下记录。这正是问题所在：失效在输出里看不见，只在交接里看得见，所以记录比重试更重要。

我们也不知道你的审核产能。五道闸可能变成一条没人清的队列。如果瓶颈在队列，减文章数量，不要减闸门。少发几篇批准过的，胜过发更多没人读过的。先让流程能稳定跑一周，再谈提高产量；连一周都跑不稳，加量只会把积压藏得更深。

常见问题

AI 工作流到底是什么？

AI 工作流是把一个搜索机会变成一篇已批准页面的顺序，每一次交接都有人负责。它包括 brief、证据、草稿、发布动作和复验。模型可以参与起草，但不拥有这些决定。

智能体能不能不审核直接发布？

当页面要对你自己的产品、市场或客户做事实陈述时，不能。草稿不是决定。如果输出风险很低且可撤回，可以减轻闸门，但发布记录仍然要写明是哪个账号在操作。

AI 生成的内容怎么审？

审说法，不审文笔。把每条事实句放进台账，附来源和日期，再确认来源确实说了那句话。前面提到的主张台账就是这套方法，它能抓出重读时滑过去的编造数字。

MCP 会取代审核流程吗？

不会。MCP 统一的是助手怎么调用工具，不决定哪些调用已经被人批准。规范把同意权放在 host，你的流程仍然要记录那个「可以」。工具越多，记录越重要，因为两次审核之间能发生的事情更多。

这篇讲交接，不讲写作和提示词。它也不声称加了闸门草稿就为真，闸门只让决定变得可见。做到这一点，已经能挡住最贵的几类失败，剩下的判断仍然留在该在的人手里。交接表可以抄，但负责人必须写名字。名字是人，不是角色名。这一步不能省，也别拖，写清楚。