Claude Code Permission Receipt Pattern：记录权限、证据和回滚方式

权限配置不是写一次就结束。真实工作中，每个任务都应该留下简短记录：这次允许了什么，什么需要批准，留下了什么证据。这个记录就是 permission receipt。

为什么需要这个做法

给 Claude Code 的权限越大，速度越快，责任也越大。receipt 可以解释为什么运行某个命令，哪些文件在范围内，以及是否检查了咨询入口和 Gumroad 链接。

继续阅读: 继续阅读 1, 继续阅读 2, 继续阅读 3.

实际工作流

开始前，用 JSON 或 Markdown 写下 allowed、requiresApproval、filesInScope、proof 和 rollback。碰到认证、计费、密钥、邮件发送或生产部署时停止并请求批准。完成后，把 build 和公开 URL 证据补进去。

可复制的最小套件

{
  "request": "update article CTA links",
  "allowed": ["Read", "Grep", "Edit content files", "npm run build"],
  "requiresApproval": ["deploy production", "change product price", "send email"],
  "proof": ["build passed", "public URL checked", "CTA clicked"],
  "owner": "content-ops"
}

Before acting, write a permission receipt.
Include allowed actions, actions requiring approval, files in scope, commands to verify, and rollback note.
If the task touches billing, auth, secrets, email sending, or production deploy, stop and ask for approval.

export function needsHumanApproval(receipt) {
  const risky = ["billing", "auth", "secrets", "email", "production deploy"];
  return receipt.requiresApproval.some((item) =>
    risky.some((word) => item.toLowerCase().includes(word))
  );
}

真实例子

• 修改文章 CTA 时，允许 content files 和 build，但商品价格修改必须等待批准。
• 改善免费 PDF 表单时，可以把表单提交测试作为证据，但真实邮件发送要等待批准。
• 团队导入时，把 receipt 模板放进 CLAUDE.md，让每次会话留下同样结构。

运营检查清单

这个做法不是读一次就结束，而是每次使用 Claude Code 时都可以快速复用。只要改到文章、商品页或咨询入口，就把下面的清单当作小型运营控制。

• 开始前用一句话写清目标，并列出不在范围内的文件或功能。
• 把 Claude Code 应该阅读的文件和不应该阅读的文件分开。
• 实现后至少留下一个证据命令。内容变更不能只看 build，还要看公开 URL。
• 确认免费 PDF、Gumroad 和咨询链接在正文与文章底部 CTA 中一致。
• 多语言文章要确认 title、h1、正文开头和 CTA 都是目标语言。
• 不要 stage 无关的 dirty file。必要时在 commit 前重新拆分差异。
• 写下剩余风险和下次要看的指标，让下一次会话不用猜。

应该连接到哪一个产品或咨询

如果读者还不熟悉命令，第一出口应该是免费速查表。如果这个流程每周都会重复，Prompt Templates 可以固定 review、debug 和文章更新指令。如果真正的阻碍是 permissions、CLAUDE.md、hooks、MCP 或 CI/CD，就引导到 Setup Guide。如果团队责任、公开验证和收入路径需要一起设计，就把读者推向咨询。

handoff 里要留下什么

Claude Code 的工作不是补丁看起来完成就结束。下一位维护者能否不用重放整个会话，就理解这次判断，才决定它是否真的有用。handoff 里要写清修改范围、为什么只改这个范围、执行了哪些证据命令、公开 URL 是什么、CTA 指向哪里、还剩什么风险。内容工作还要记录 heroImage、内部链接、外部链接、语言检查，以及免费 PDF、Gumroad、咨询路径是否仍在正文里。靠近产品页时，还要说明哪类读者适合免费资源，哪类读者应该购买教材，哪类读者应该预约咨询。发布文章时，还要留下 slug、语言、图片、build、deploy、h1、canonical 和截图检查结果。改写旧文章时，要写清强化了哪一个搜索意图，以及把读者送往哪个收益入口。

下一步要看的数字

PV 不是唯一成功指标。发布后要看索引状态、国家来源、文章底部 CTA 附近点击、Gumroad 点击和咨询表单访问。修复既有热门文章时，要比较改写前后的跳出率和下一页跳转。如果下一次 Claude Code 会话先拿到这些数字，它就更容易做收入路径判断，而不是只继续生成文字。还要按文章类型拆分目标：入门文章先看免费 PDF 点击，设置和权限文章看 Setup Guide，review 和 debug 文章看 Prompt Templates，团队流程和上线验证文章看咨询页访问。这样即使某篇文章 PV 不高，也能判断它是否在正确位置推动购买或咨询。分析时不要只责怪文章，问题也可能在 CTA 文案、价格页、表单字段、页面速度或翻译质量。下一次只选一个最弱环节修正，并重新公开验证。

常见失败

• 只靠 settings 文件管理权限，看不到每个任务的实际判断。
• 批准边界模糊时，价格、邮件和部署这类难回滚动作容易溜过去。
• 没有 proof 字段，会把本地 build 成功和公开 URL 成功混在一起。

免费 PDF、Gumroad 和咨询路径

先用免费 PDF 固定日常命令习惯。流程开始重复时购买 Gumroad 教材；如果涉及团队导入、权限设计或收入路径，就进入咨询。CTA 要跟读者阶段匹配：新手拿免费资源，重复操作买模板，团队风险交给咨询。

• 免费 Claude Code 速查表
• 50 个 Claude Code 提示词模板
• Claude Code 设置指南
• 教材列表
• 导入咨询

验证记录

本文连接 permissions guide、permission budget loop 和 approval sandbox guide，并明确给出免费 PDF、Setup Guide、Prompt Templates 和咨询路径。