Claude Code Harness Smoke Test：信任代理前的15分钟验证循环

在接近生产的任务里使用 Claude Code 时，第一步不应该是大型自动化，而是一个小的 smoke test。先写清楚它可以读什么、可以改什么、绝对不能碰什么，以及什么证据代表任务结束。

这篇文章面向想知道“到底能交给代理多少工作”的初学者和中级用户。对于有收入路径的网站，验证不能只看本地 build，还要看免费 PDF、Gumroad 商品和咨询入口是否仍然正确。

为什么这个做法有效

harness smoke test 不是证明模型永远安全，而是证明工作环境有边界。一个小的文章修改，如果弄坏 PDF 表单、商品链接或咨询链接，也会伤害收入。

15分钟足够短，可以每天重复。先通过读取范围、有限编辑、build、公开 URL、截图，而不是一开始就追求完美 CI。

实务流程

用一句话写目标，并把可编辑文件限制在三个以内
把密钥、付款、客户数据和部署设置写成禁止区域
编辑前就决定 build、diff、公开 URL 和截图如何证明完成
文章和落地页必须把免费 PDF、Gumroad、咨询 CTA 纳入检查
保留 run card，让第二天的工作从证据开始

场景	安全做法	验证
新文章	只允许正文和 frontmatter，layout 与 API 保持只读	build 与公开 URL
商品页	只改文案和卡片顺序，并逐个核对购买链接	Gumroad 链接检查
团队导入	先只读审计，再允许一个低风险修改	diff 与截图

可直接复制的提示词和代码

请为这个仓库执行15分钟 harness smoke test。暂时不要做大范围修改。返回目标、可编辑文件、禁止区域、验证命令、公开 URL 检查，以及免费 PDF/Gumroad/咨询 CTA 检查。

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

这段代码把模糊的代理请求变成 run card。可以把同样结构用于 PR 模板、发布检查表或咨询前诊断。

三个真实例子

Astro 文章发布

把修改限制在正文、heroImage 和 CTA。即使 build 成功，如果生产页面的 h1 或 CTA 属于别的页面，也算失败。

小型 UI 修改

只改按钮文案，也要检查移动端换行和点击区域。如果按钮指向商品，同一次检查里核对商品链接。

团队首次导入

不要一开始就写代码。先整理 README、权限、测试和禁止区域，这份资料可以直接成为咨询议程。

需要避免的失败例

让 Claude Code 一次性“全部改善”会让范围失控。
只看本地 build 会漏掉生产 fallback 和过期 CTA。
不检查 Gumroad 链接，可能把初学者流量送到不合适的付费商品。

多语言发布还有额外风险：slug 一致，但正文或 CTA 仍是旧内容。要看公开页面，不只看 frontmatter。

如何连接免费 PDF、Gumroad 和咨询

还不熟悉命令的读者先领取免费速查表。如果瓶颈是权限、CLAUDE.md、hooks、MCP 或 CI，可以使用 Setup Guide。

反复写 review 和 debug 提示词的读者适合 50 Prompt Templates。需要团队 rollout 设计时，进入咨询。想比较所有资源，可以看产品页。

发布前后要检查什么

发布前检查 frontmatter、heroImage、内部链接和 Gumroad 链接。发布后用手机宽度看 h1、正文开头和 CTA 区域。HTTP 200 不够，如果是 fallback 页面仍然失败。

接下来要看的数字

观察这个 slug 的搜索流量、PDF 开始数、Gumroad 点击、产品页访问和咨询页访问。PV 上升但商品点击不动，说明 CTA 阶段错了。

30分钟运营复盘

把 harness smoke test 放进真实工作后，最有价值的检查通常在第二天。先看运行记录，把允许范围、实际修改文件、验证命令和已经打开过的公开页面写成一条证据。不要只写“已检查页面”，要写清楚手机宽度的 h1、正文开头、CTA 区域、Gumroad 链接和咨询路径。

然后把工作者的安心和读者的行动分开看。工作者侧要确认禁止区域没有被碰、build 有证据、公开 URL 指向同一个 slug、翻译页面没有偷偷保留英文正文。读者侧要确认下一步明确：还在学命令的人拿免费 PDF，已经有重复瓶颈的人看 Gumroad，需要流程设计的人走咨询。

最后，把复盘变成下一次的一条规则。不要一次增加十条。只增加能避免这次问题的一条：改 layout 前先问、生产环境每个 Gumroad URL 都点击、每个语言都截图正文开头。每天能执行的小规则，比没人读的长政策更有价值。

留下一条小验证日志

如果要持续使用这个方法，最后只留一条验证日志。内容包括日期、slug、主 CTA、build 结果、公开 URL、截图确认过的语言，以及下一次要改的候选点。不需要写成长日报，越短越容易第二天读。下次再让 Claude Code 工作时，这一条记录就能说明上次确认到哪里、加强了哪条商品路径、哪种语言必须重点看。内容运营如果每天从零开始，很容易变形；小日志越多，免费 PDF、Gumroad 和咨询路径越容易稳定改善。

下周优先改哪里

下周优化时，先看已经有流量的文章。与其大改没人访问的页面，不如在已有搜索流量的文章里减少 CTA 犹豫。如果免费 PDF 有点击但 Gumroad 没有继续，就在商品说明前补一段“能省掉哪项工作”。如果 Gumroad 有点击但购买弱，就在文章里具体化交付物，而不是只谈价格。若有人进入咨询页，就说明读者需要流程设计，文章里应写清咨询前要准备的信息。