Claude Code 验证回执工作流：用 build、公开 URL、CTA 和截图证明 AI 修改

为什么需要验证回执

Claude Code 可以很快改文章、改页面、改链接，但风险也出现在这里：diff 看起来合理，不代表公开页面真的可用。对于带有免费 PDF、Gumroad 商品、咨询入口的文章来说，本地 build 成功只是第一层证据。公开 URL 可能还是旧版本，CTA 可能指向错误商品，移动端截图里按钮也可能被长文案挤坏。

我把这种发布前证据叫做“验证回执”。它不是复杂文档，而是一张简短记录：改了哪些文件，为什么改，用什么命令验证，打开了哪个公开 URL，CTA 和收入路径是否仍然可用，截图里有没有明显布局问题，还有哪些风险没有完全排除。这样第二天继续修改时，不需要从聊天记录里猜当时到底检查过什么。

建议把本文和 build 错误排查流程、review 工作流检查清单、权限审计检查清单一起使用。一个负责构建失败，一个负责代码和内容审查，一个负责控制 Claude Code 的权限边界。

验证回执模板

下面的模板可以直接复制到 PR 评论、发布记录，或者让 Claude Code 在最后一轮按这个格式回复。关键是写“证据”，不要写“感觉没问题”。比如“build 通过”“公开页面包含预期 h1”“Gumroad 链接打开的是指定商品”都比“应该好了”更有价值。

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

其中“out of scope”很重要。Claude Code 很容易顺手清理相邻文件，但这会扩大风险。文章增强任务就只写文章，不要顺手升级依赖、改导航或重构组件。“what should not change”则用来保护 slug、canonical、作者、发布日期、商品链接和咨询入口。

build、公开 URL、CTA、截图的具体检查

第一步是本地证明。先看工作区是否只包含目标文件，再看 diff 规模，最后运行站点 build。Windows 环境中使用 npm.cmd 更稳定。

git status --short
git diff --stat
cd site
npm.cmd run build

第二步是公开 URL。不要只看 HTTP 200，因为不存在的页面也可能返回 fallback HTML。至少检查标题、文章里的独有短语，以及 CTA 或商品名称。

const checks = [
  {
    url: "https://claudecode-lab.com/zh/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude Code 验证回执", "验证回执模板", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/zh/training/",
    mustInclude: ["咨询"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

第三步是截图。文字检查能发现页面是否存在，但看不出移动端按钮是否换行过度，也看不出代码块是否把页面撑宽。使用 Playwright 保存桌面和手机宽度的截图，能给回执留下可复查证据。

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/zh/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-zh.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-zh.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

截图检查时看四个位置：首屏标题和导语、中间代码块、模板段落、结尾 CTA。多语言文章最常见的问题不是内容完全缺失，而是某个语言的按钮太长、列表太密、外部链接上下文不自然。

实例一：把薄文章补成可发布文章

当文章太短时，目标不是机械增加字数，而是补齐读者真正需要的步骤。以这篇 Claude Code 运维文章为例，读者想要的不是一句“请验证”，而是可以直接复制的模板、能运行的 build 命令、公开 URL 检查、CTA 检查、截图检查，以及失败案例。

验证回执应该记录新增了哪些章节，是否有内部链接和外部链接，代码块是否使用正常的 triple backtick，是否还保留 updatedDate 和 heroImage。如果文章有商品导线，还要确认导线是自然的：先用免费 PDF 建立习惯，再用 Gumroad 教材扩展模板，最后在团队发布、权限设计、收入路径检查变复杂时引导到咨询。

实例二：修改 CTA 或商品链接

CTA 修改看似只是几行文案，但它直接影响下载、购买和咨询。回执里不要只写“已修改 CTA”。更好的写法是：按钮文案是什么，链接指向哪里，目标页面标题是什么，下一步是下载、购买还是预约咨询。

免费 PDF 的检查重点是读者是否知道会得到什么，提交后是否能进入正确页面。Gumroad 的检查重点是商品名、说明开头和文章承诺是否一致。咨询入口的检查重点是上下文是否自然。读者读完验证回执工作流后，可能需要团队规则、审核标准、部署前检查清单，这时咨询导线就是合理的下一步。

实例三：发布多语言版本

多语言发布不能只检查英文。中文读者需要清楚理解“verification receipt”不是付款收据，而是发布前证据记录。韩语、西班牙语、德语等语言的 CTA 可能更长，移动端布局更容易出问题。印尼语读者可能接受 workflow 这个词，但仍需要用本地表达解释“工作流”。

验证回执里应该写明：每个语言都检查了导语、模板、失败案例、教材导线和截图。这样做不会让流程变重，反而减少返工。因为多语言问题通常不是语法错误，而是语气生硬、按钮溢出、链接去错语言、商品说明和正文承诺不一致。

常见失败和避免方法

第一，误把 HTTP 200 当成发布成功。必须检查页面独有文字、h1、canonical 和正文片段。

第二，只看 build 成功。build 说明源码能编译，不说明公开站点已经更新，也不说明图片和 CTA 在生产环境可用。

第三，只确认链接存在。链接存在不代表链接正确。商品链接、免费 PDF、咨询入口都要打开目标页面检查。

第四，不保留截图。没有截图，第二天很难证明移动端到底有没有看过。截图也是与团队沟通的低成本证据。

第五，让 Claude Code 自己决定验证范围。应该把模板交给它，让它按命令、URL、CTA、截图、剩余风险逐项回答。

教材和咨询的自然导线

如果只是个人日常使用，先从免费的 Claude Code cheatsheet 开始，固定常用命令和验证提示词。等到同样的审查请求反复出现，再使用 50 个 prompt 模板或 Setup Guide，把 CLAUDE.md、hooks、权限规则、发布前检查写成团队可以复用的形式。

如果你维护的是公开文章、LP、商品销售页或咨询入口，验证就不只是个人习惯。需要决定谁检查公开 URL，谁保存截图，哪些 CTA 属于收入路径，哪些错误必须阻止发布。这类规则适合通过咨询一起设计，因为它牵涉团队角色、风险容忍度和实际发布节奏。

• 免费 Claude Code Cheatsheet
• 50 个 Claude Code Prompt Templates
• Claude Code Setup Guide
• Products
• 咨询

这篇文章实际验证了什么

这篇文章把差异检查、build、公开 URL、CTA 和截图确认整理成一张验证回执。实际使用时，最明显的好处是能立刻发现遗漏：build 做了但公开 URL 没看，CTA 看了但咨询入口没看，桌面截图有了但手机截图没有。Claude Code 的价值在于速度，但公开内容需要证据。验证回执就是把速度和证据接起来的轻量规则。