工作流
让 AI 用反例审代码：草稿会不会泄漏
把审查问题落到一段数据和一次操作上。
资料核验2026.11.12 · 编码助手 · 可用于现有软件仓库
审查提示里只写「看看有没有 bug」，很容易得到格式、命名和日志建议。真正担心的是编辑旧文章时，新草稿是否会立刻暴露在公开站。把这个担心写成反例，审查就能落到实际路径上。
交给编码助手的任务
设一篇公开文章含标记 A，编辑台保存含标记 B 的修订。让 Codex 沿写入、公开列表、RSS 和构建四条路径找证据，每条都返回文件、函数和一条可以运行的检查。把「保存修订后 A 在、B 不在」写成评审条件，不给它预设哪个函数有错。
明确一次要守住的行为
交给助手已发布版本、改过的草稿、预期公开结果。让它沿保存入口、文件读取和站点构建追踪，指出哪一步可能读错版本，并给出可复跑的检查。
再要求一条相反路径的验证：确认发布之后，公开站应该读到新正文。两条都成立，才说明草稿隔离和发布都能工作。
最后自己检查引用的代码和结果。审查意见要能落到可观察行为上，才值得据此改动。
先准备一个对照样例
样本 A 写「六月版」，样本 B 写「七月修订未发布」。把两段文字当成探针，在生成目录和订阅 XML 里分别搜索。只有发布动作完成后才允许公开查到 B。如果 A 与 B 同时出现，顺着重复条目的文件名排查，而不是修改展示顺序。
用这些结果验收
- 保存后访问旧链接，首页搜索与 RSS 均只能找到 A。
- 无痕访问草稿预览得到登录要求。
- 明确发布后同一 URL 才能读到 B。
审查时容易漏掉什么
如果助手只查页面渲染，追问构建是不是从另一份文件清单读数据。公开边界往往失守在数据入口，单靠模板里藏按钮无法解决。把验证时使用的提交和构建产物一起交回，避免审的是本地代码、测的却是另一版静态文件。
检查不要依赖草稿路径的命名恰好和过滤规则一致。准备两个不同 slug，另对已有文章保存一个同 slug 的修订，分别验证新草稿和已发布稿修订。请求读到 404 时，也检查响应体有没有因自定义错误页把内容带出来。评审记录里至少附一条响应和一条构建产物检查。
