Claude Code 轻量 Harness：新手安全修改代码的最小脚手架

新手使用 Claude Code 时，第一类问题通常不是提示词写得差，而是还没有边界就让代理开始修改。Harness Lite 是一个很小的安全脚手架：先读，再改，再留下证据，然后检查公开 URL 和收入 CTA。

它是 Claude Code harness engineering 的入门版。面对陌生仓库时，可以配合 repo map first pass 和 permission receipt pattern，让每一次修改都有可解释的范围。

先写边界，再写任务

轻量 Harness 不是为了限制 Claude Code 的能力，而是为了让修改可说明、可回滚。开始前要说明哪些文件可以读，哪些文件可以改，哪些区域不能碰，哪个命令能证明修改，发布后要打开哪个页面。

内容站和产品页尤其需要这个顺序。文章、免费 PDF 表单、Gumroad 链接、咨询入口经常在同一页附近。一个很小的文案修改，如果没有边界，也可能破坏搜索流量到注册或购买的路径。

harness_lite:
  owner: "Masa"
  scope:
    allowed:
      - "read repository"
      - "edit selected files"
      - "run build or test"
    blocked:
      - "delete unrelated files"
      - "touch secrets"
      - "hide failed verification"
  proof:
    - "git diff reviewed"
    - "build command recorded"
    - "public URL opened"
    - "CTA path checked"

可复制的开始提示词

我想在这个仓库里安全完成一个很小的修改。
现在不要编辑文件。
请返回:
1. 需要先阅读的文件
2. 可以安全编辑的文件
3. 必须排除在范围外的区域
4. 最小验证命令
5. 公开 URL 上要检查的 h1、canonical、hero image 和 CTA
6. 如何保护免费 PDF、Gumroad 和咨询链接

这段提示词的重点不是让 Claude Code 立刻写代码，而是让它先给出工作边界。边界明确后，第二条消息只要求一个修改、一个验证命令和一个结果记录。

把验证变成一个小对象

修改后，让 Claude Code 填写一份 proof receipt。下面的 JavaScript 很简单，作用是把“可以提交”的条件写出来。

const proof = {
  goal: "change one small thing",
  filesChanged: 2,
  commands: ["npm run build"],
  publicUrlChecked: true,
  ctaChecked: true,
};

export function isReadyToCommit(receipt) {
  return receipt.filesChanged <= 3 &&
    receipt.commands.length > 0 &&
    receipt.publicUrlChecked &&
    receipt.ctaChecked;
}

console.log(isReadyToCommit(proof)); // true 表示达到提交前的最低条件

这个对象能抓住常见的半成品状态：build 通过但没有打开公开 URL；页面返回 200 但内容是旧文章；正文正确但 Gumroad 或咨询 CTA 指向了错误位置。

三个真实场景

• 修改 Astro 文章时，把范围限制在一个 MDX、一个 hero image 和一个相关产品页。部署后检查 h1、正文开头、canonical、免费 PDF 表单、Gumroad 按钮和咨询链接。
• 修改 React 小功能时，只触碰目标组件、附近测试和截图验证。认证、计费、secret、migration 不放进第一次修改。
• 团队导入时，把安全命令、受保护区域、证据格式和回滚说明写进 CLAUDE.md。下一位成员不用重新解释规则。

常见失败

最常见的失败是直接说“请全部检查并修复”。Claude Code 会努力帮忙，但 diff 会变大，验证也会变模糊。第二个失败是只看本地 build。公开路由即使返回 HTTP 200，也可能显示 fallback 页面或旧文章。

收入导线也会出错。正文推荐免费 PDF，文章底部 CTA 却跳到别的商品；多语言文章没有说明 Gumroad 目前以英文商品为主；咨询入口存在，但没有解释什么时候应该预约。Harness Lite 把这些检查放进任务本身。

免费 PDF、Gumroad 与咨询

如果还在学习命令和安全习惯，先拿 free cheatsheet。如果你反复写 review、debug、refactor 提示词，使用 50 Prompt Templates。如果瓶颈是权限、CLAUDE.md、hooks、MCP 或 CI/CD，使用 Setup Guide。如果需要团队流程或收入路径设计，进入 咨询页面。

本文已验证的内容

本文包含轻量 Harness、可复制提示词、验证对象、三个实际场景、失败例，以及免费 PDF、Gumroad 和咨询路径。下一步应观察这个 slug 带来的 PDF 注册、Gumroad 点击和咨询访问。

发布后的运营记录

实际使用这个模式时，不要把“文件已经生成”当作完成。只有公开 URL 上的读者能清楚选择下一步，工作才算完成。请用手机宽度检查 h1、正文开头、hero image、免费 PDF 表单、Gumroad 链接和咨询链接。正文正确但文章末尾 CTA 指向错误商品时，收入路径仍然没有完成。

多语言文章不能只看 slug 是否一致。要分别检查日语、英语、中文、韩语、西班牙语、法语、德语、葡萄牙语、印地语、印尼语的正文开头和 CTA 文案。只有标题翻译、正文或 CTA 仍是英语，会让读者不信任下一步。

下一轮改善不要只看 PV。把 PDF 注册开始数、Gumroad 点击、Products 页面访问、Training 页面访问、国家分布和搜索来源放进同一份 brief。Claude Code 拿到这些数字后，才能判断应该加强免费资产、Prompt Templates、Setup Guide，还是咨询路径。

每次发布文章时，也要把“读者今天能做的下一步”收束成一个判断。新手先拿免费 PDF，重复做同类工作的读者看 Prompt Templates，被权限、设置或 CI/CD 卡住的读者看 Setup Guide，需要团队导入或收入路径判断的读者去咨询。正文中间、文章底部 CTA、Products 页面卡片如果指向同一个判断，读者就不会犹豫。相反，正文推荐 PDF，卡片推荐另一个商品，咨询入口又不明显，PV 增长也很难变成注册或购买。

最后要留下验证日志。记录已经打开的公开 URL、截图检查位置、CTA 目标、修改文件和剩余风险。这样第二天运行 Claude Code 时，就不用重新猜昨天检查了什么。收入导线不是一次性大改，而是发布、确认、看数字、再修正的循环。

如果数字很弱，不要只责怪正文。要依次检查搜索意图和 CTA 是否匹配、heroImage 是否正常、手机端按钮是否容易点击、内部链接是否符合读者阶段。把这些具体问题交给 Claude Code，比只说“提高收入”更容易得到可执行的修改。

第一次实践时，可以把任务缩到只改一段导入文或一个内部链接。修改前先让 Claude Code 写出不能触碰的区域，例如结算、环境变量、已有商品页和咨询表单。修改后再要求它报告 diff 大小、执行过的命令、检查过的公开 URL，以及下一步最应该看的数字。这样做的好处是，新手不会被“自动化很强”带着跑偏，也能把每次文章更新和免费 PDF、Gumroad、咨询入口连接起来。流量增长只是第一层，真正要看的还是读者是否走到了下一步。