Claude Code 完成验收清单：用证据替代一句“搞定了”

周五晚上，我让 Claude Code “写一篇文章，顺手发布上线”，然后就去睡了。第二天早上翻日志，上面信心满满地写着“已完成，文章已发布”。我放心地打开公开 URL，结果页面上显示的，是上一篇文章的标题。

build 是过了的，URL 也确实返回了 200。可 h1 标签还停在另一个页面上。我把“检查 diff”这件事完全甩给了 AI，自己只信了“跑通了”这三个字。

那一刻我才明白，卡住我的不是 Claude Code 不够聪明，而是我“收尾的方式”有问题。交给 AI 的范围越大，做完之后要是不把“到底验证了什么”握在自己手里，就会一次又一次被假的完成报告骗到。

这篇文章，我就把这套“留下证据的套路”讲清楚，连可以直接复制的代码一起给你。

本文要点

• 别信 AI 的“搞定了”。只把机器验证过的证据——build、公开 URL、h1、CTA——当作判断完成的依据。
• 动手改之前，先用一句话定下“这次要验证什么”，并把验证命令也提前定好。
• 发布后每次都按同一个顺序目视检查（h1 → canonical → 正文开头 → CTA）。顺序固定下来，漏看就会变少。
• 把证据（截图、URL、下一步要看的数字）压缩成一行备忘。第二天的你或自动流程就不用把同一个判断重做一遍。
• 与其一次写出完美文章，不如发出一篇“第二天还能复查”的文章。从运营角度看，后者更稳。

为什么只说“搞定了”一定会翻车

Claude Code 会用文字帮你总结整个过程。麻烦就在这里：不管真的顺利还是其实出了问题，这段总结大多是同一副自信的表情返回给你。

build 通过，只能证明“语法没坏”。公开 URL 返回 200，只能证明“服务器返回了某个东西”。至于那个东西，是不是你这次要做的这篇文章，完全是另一回事。

我周五那次翻车，build 和 200 两项都过了。崩掉的只有一处——URL 和页面内容是否对得上。偏偏这一点谁都没看。

所以“是否完成”的判断，不能放在 AI 的措辞上，而要放在“你自己定好的检查项被一项项核实掉”的结果上。如果你连推进检查的基本流程都还没把握好，可以先用Claude Code 入门指南把基础节奏理顺，再回头看这套步骤会更顺。

15 分钟跑一遍的验收循环

每次都用零散随机的步骤去检查，忙起来一定会漏掉某一环。把顺序固定下来，做成不用动脑就能跑完的形式。

1. 用一句话写下“这次要验证什么才算完成”。例如：“这个 slug 的文章，带着正确的 h1 出现在公开 URL 上”。
2. 动手改之前，先把验证用的命令（build、显示 diff 等）定好。别等做完了再去找。
3. 改完之后，按 diff → build → 公开 URL 的顺序看。中途想法变了也不打乱这个顺序。
4. 在公开 URL 上目视确认 h1、canonical、正文开头、CTA 是否按预期排列。
5. 把剩下的风险和“下一步要做的最小动作”各用一行记下来。

这里最关键的是，一开始就把“交给 AI 的范围”和“人来决定的范围”切分清楚。

环节	可以交给 AI	由人来判断
选题	读已有标题、给出候选	最终写哪一篇
写作	正文、代码、标题的草稿	有没有掺进假信息或过时内容
验证	跑 build、总结 diff	公开 URL 的内容是否正确的最终确认
发布	执行发布命令	删除、上生产等不可逆操作的批准

不可逆的操作，一开始全部倒向“先问人”。等确认某个操作安全了，再把它升级成自动。这条边界怎么划，我在权限管理指南里整理得更细。

可以直接复制的委托话术模板

每次都从零开始用语言描述验证项，那天心情一变就会漏。把交给 Claude Code 的委托话术做成模板，检查项才稳得住。

这篇文章我已经发布了。在给出完成报告之前，请确认以下各项，并用表格返回结果。
- build 是否成功（连命令和退出码一起写出来）
- 公开 URL 的 h1，是否和这次 slug 的文章标题一致
- canonical 是否指向同一个 slug
- 正文开头，是否在沿用上一篇文章或首页的内容
- CTA（免费 PDF、教材、咨询）是否按读者当前所处状况的顺序排列
没能确认的项目，请老实写“未确认”。不要靠猜测写“OK”。

最后一句很关键。如果不明说“不要靠猜测写 OK”，AI 会把它没核实过的项目，也用一副差不多还行的表情返回“没问题”。如果你想把委托话术本身的组织能力整体提上去，可以顺带读一读进阶提示词设计。

可以直接跑的验证脚本

这一节是今天的主菜。脚本会去抓公开 URL，机器化地判断 h1 是不是你预期的标题。只用 Node.js（18 以上）就能跑。把判断完成的依据放在这个脚本的结果上，而不是 AI 的“搞定了”。

// verify-publish.mjs
// 用法: node verify-publish.mjs <公开URL> "<期望的h1标题>"
// 例: node verify-publish.mjs https://claudecode-lab.com/zh/blog/foo/ "文章标题"

const [url, expectedH1] = process.argv.slice(2);

if (!url || !expectedH1) {
  console.error("请传入两个参数：URL 和期望的 h1 标题。");
  process.exit(2);
}

// 抓取公开页面
const res = await fetch(url, { redirect: "follow" });
const html = await res.text();

// 粗略地把 h1 和 canonical 抠出来（不需要严格的解析器）
const h1 = (html.match(/<h1[^>]*>(.*?)<\/h1>/is)?.[1] ?? "")
  .replace(/<[^>]+>/g, "")
  .trim();
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]+href=["']([^"']+)["']/i)?.[1] ?? "";

// 一项一项核实检查项
const checks = {
  http200: res.status === 200,
  h1匹配: h1 === expectedH1,
  canonical匹配: canonical.includes(new URL(url).pathname),
};

console.table(checks);

const allOk = Object.values(checks).every(Boolean);
if (!allOk) {
  console.error("存在未确认或不一致的项目。先别把发布当作完成。");
  console.error(`抓到的 h1: ${h1 || "（空）"}`);
  process.exit(1);
}

console.log("证据齐了，可以当作完成。");

执行起来就这么一行。

node verify-publish.mjs https://claudecode-lab.com/zh/blog/foo/ "文章标题"

如果 h1匹配 是 false，那就正是我周五那次翻车的状态：URL 活着，内容却不对。只要退出码不是 0，就不把发布叫作“完成”。光是把这一条立成规矩，假的完成报告就会被挡在前面。

这些场景下特别管用

1. 文章的发布作业 这是最容易把 HTTP 200 当成功的场景。用上面的脚本确认 h1 和 canonical 是否指向同一个 slug，就能在发布前挡掉“沿用上一篇文章”或“回退到首页”的情况。

2. CTA（引导按钮）的替换 动过免费 PDF 或教材的按钮之后，把截图和“下一步要看的数字”记在同一行备忘里。之后想追“那次改动到底有没有提高注册数”时，就能靠记录而不是靠记忆去查。

3. 配置或权限的变更 恰恰是改了 CLAUDE.md 或权限设置的时候，要在改动前后跑同一条验证命令。如果你对配置怎么写还没底，先把CLAUDE.md 写法理顺，验证的前提才齐整。

常见的坑，以及怎么修

老实说，我在落到这套套路之前，反复掉进过同一些坑。

第一个，是想一次性把所有东西都改完，结果做出一个大到没法核实的 diff。一次动了 40 个文件的 diff，人和 AI 都读不完。修法很简单：把一次作业要验证的事收缩成一句话。一旦大到验不完，就把作业拆开。

第二个，是本地 build 一过就当成完成。本地能跑，和正确地出现在公开 URL 上，是两码事。修法是：把上面那个脚本在发布之后必跑一次。在把它塞进流程之前，我自己也发布过好几次内容对不上的页面。

第三个，是只顾着堆 CTA，却不告诉读者该往哪儿走。摆三个按钮，读者选不出来就没意义。修法是：按读者所处的状况（还对操作没底／在重复作业里疲了／在考虑团队导入），在正文里各加一句，说清楚哪个 CTA 适合他。

常见问题

Q. build 过了，是不是就算完成？ build 只能证明语法没坏。公开 URL 的内容是不是这次的文章，是另一个问题。要看到 h1 和 canonical 都对上，才算完成。

Q. 验证脚本每次都要手动跑吗？ 一开始手动就够。等流程稳了，再把它养成“发布命令之后自动触发”。做成“退出码不是 0 就拦下发布”的运营方式，事故会明显减少。

Q. 能不能连验证也全交给 AI？ 读取、总结这类活儿可以交。但“公开 URL 的内容是否正确”的最终判断，以及不可逆操作的批准，要握在人手里。把这两点交出去，就没人能拦住假的完成报告了。

Q. 非工程师也能跑这套检查吗？ 能。脚本复制就能跑，目视的步骤只是记住顺序而已。如果你对命令本身没底，从写给非工程师的入门切入会更平顺。

Q. 备忘留下什么就够了？ “这次验证了什么”“剩下的风险”“下一步最小的动作”这三样就够。不需要长篇会议纪要。目的只有一个：让第二天的你不用把同一个判断重做一遍。

实际试下来的结果

周五那次内容对不上的发布之后，我把判断完成的标准，从“AI 说了什么”切换成“脚本的退出码是不是 0”。

我实际把 verify-publish.mjs 在十来次发布上跑了一遍，其中有两次返回了 h1匹配 为 false。这两次都返回了 200，光看一眼根本察觉不到。要是没有这个脚本，我又会把沿用的页面发出去。

把目视顺序固定下来也很有效。h1 → canonical → 正文开头 → CTA，每次都按同一个顺序看之后，“咦，这儿上次好像也跳过了”这种漏看几乎消失了。把判断从脑子里挪出来、外置成步骤之后，晚上的复查明显轻松了不少。

与其去找更聪明的 AI，不如先把“摔了也能察觉”的机制铺好。看着像绕路，但现在我的结论是：这才是最快的路。

如果你想把这套验证套路定成团队的标准，或者塞进公司自己的发布流程，到了这个阶段，可以在研修与咨询里一起来设计。Claude Code 的官方文档可以在 Anthropic 文档里查到。