Verification Sandwich 工作流：让 AI 先自查、再交付、再复核

AI Agent 很容易在“看起来完成了”的地方出问题。它写了文件，但没跑检查；它说页面可访问，但没有贴 HTTP 结果；它认为内容不重复，但没有和近期主题比较。Verification Sandwich 的作用，就是把验证夹在任务前后，让交付不是一句主观判断，而是一组可复查证据。

这个工作流适合内容发布、代码修改、数据修复、部署变更等任何容易“口头完成”的任务。

第一层：开工前验证

任务开始前先确认三件事：目标对象是否存在，当前状态是什么，禁止动作有哪些。比如补发文章前，要先确认 slug 真的不存在；覆盖旧文章前，要先确认旧 slug 和三语 ID 存在；部署前，要先确认当前线上版本和回滚点。

这一步的价值是防止“修错对象”。很多事故不是执行能力问题，而是目标识别错误。

第二层：交付中验证

执行过程中不要等到最后才检查。写完草稿先查标题和主题；发布前先 dry-run；更新生产后立即验证 API 行、公开页面和封面资源。每个阶段都留下一个最小证据。

这会让问题更早暴露。翻译失败、封面不可达、slug 已存在、相似度过高，都应该在中途被拦住。

第三层：交付后复核

最后的复核必须由另一条视角完成。可以是另一个 Agent，也可以是只读脚本。它不参与写入，只检查结果：页面是否 200，内容是否变更，链接是否保留，审计是否通过。

如果后复核失败，不要用“应该没问题”压过去，而要回到具体证据修。

实用模板

• 开工前：确认对象、状态、禁止动作。
• 执行中：每个关键步骤跑一次最小检查。
• 交付后：用只读方式复核线上结果。
• 报告里：写清命令、输出、文件路径和剩余风险。

结论

Verification Sandwich 不是增加流程负担，而是减少返工。AI 团队真正需要的不是更多“已完成”汇报，而是能经得起复查的完成状态。先验证、再执行、再复核，才能让自动化交付稳定起来。