Claude Code 权限风险台账：在 Agent 动手前决定可做什么

为什么要做成独立产物

本文为从个人 Claude Code 使用走向团队审批规则的团队设计权限风险台账。常见失败很直接：团队总是在 agent 已经编辑、部署或请求危险命令之后才开始讨论权限。Claude Code 的工作不能停在一个自信回答，而要留下别人可以检查的产物。这里的产物是记录 action、default decision、proof 和 owner 的小型风险台账。

把这个产物当成 prompt、命令行和公开页面之间的契约。它要说明 Claude Code 读了什么、改了什么、用哪个命令证明结果，以及读者下一步该进入哪个收入路径。这个主题和 harness engineering、getting started、permissions 直接相关。

运营循环

循环分五步：定义 action，选择 proof，让 Claude Code 做最小有用工作，验证输出，再记录下一个收入动作。这里的 proof 不只是代码运行。要看审批次数、拒绝命令、rollback note、deploy 证据和咨询意图。这些字段可见后，你就不用靠猜测改文章。

1. 只读仓库梳理可以默认允许，只要最终记录读过的范围。

2. 内容编辑如果强制 diff review、build 和公开 URL 验证，就可以更安全地放行。

3. secret、billing、customer data 和 force push 即使 agent 很准确，也保持 owner 审批。

可复制的 starter

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

三个现场例子

例子 1. 只读仓库梳理可以默认允许，只要最终记录读过的范围。

例子 2. 内容编辑如果强制 diff review、build 和公开 URL 验证，就可以更安全地放行。

例子 3. secret、billing、customer data 和 force push 即使 agent 很准确，也保持 owner 审批。

自我复查清单

在把这个流程变成习惯之前，像检查 release note 一样检查文章。第一项是 scope：读者要知道什么时候使用权限风险台账，什么时候一个更小的 checklist 就够了。第二项是 proof：每个建议都要能指向 command、URL、diff 或 metric。第三项是 routing：免费 PDF、Gumroad guide 和咨询路径不要互相抢位置，而要回答不同紧急程度的问题。

再写一个小 owner rule。一个人负责产物，一个人负责验证，一个人负责下一次 CTA 实验。个人项目里可以是同一个人，但 note 里仍然要写清角色。这样 Claude Code 不会把发布、计量和销售文案混成一个模糊任务。下一次运行也能知道从哪里继续。

最后问一个实际问题：明天早上，什么会让这篇文章更容易验证？如果答案是 screenshot，就保存它。如果答案是更强的 prompt，就放进 prompt pack。如果答案是更清楚的边界，就写进 setup note。记录 action、default decision、proof 和 owner 的小型风险台账只有能被下一次 session 继续使用时才有价值。

实际运营中，发布当天的检查和第二天的复盘都很重要。发布当天确认 build、deploy、HTTP 200、h1 和 canonical。第二天再看搜索流量停在哪个段落，读者有没有到达 PDF form，Gumroad link 有没有点击，是否进入咨询页面。把审批次数、拒绝命令、rollback note、deploy 证据和咨询意图放在同一行，可以避免只看 PV 就宣布成功。

给 Claude Code 的权限也要分阶段。先 read-only 分析，再允许一个文件的小修改，最后才做 build 和公开 URL 验证。如果一开始就把 deploy 和商品导线都交给 agent，失败点会变得很模糊。权限风险台账不是为了制造流程负担，而是为了决定下一步可以放心交给 agent 的范围。

收入路径不是越用力销售越好，而是分流要准确。初学者给免费 PDF，重复工作给 Gumroad，团队导入和权限设计给咨询。当正文里的例子和 CTA 指向同一个问题时，读者更容易做出下一步行动。

最后把时间轴也写清楚。发布当天看技术正确性，第二天看读者行为，一周后看收入路径。这样不会把所有判断都压在同一个 PV 数字上。记录 action、default decision、proof 和 owner 的小型风险台账也可以帮助团队把短期验证和长期收入判断分开。

失败情况

第一个失败是只看 PV。第二个失败是没有 proof command 就批准修改。第三个失败是所有读者都送到同一个付费产品，即使有的人更适合免费 PDF 或咨询。解决方法是在改 CTA 前先写 routing rule。

收入路径

按瓶颈分流读者。需要命令熟练度，就去 免费 PDF 或 free Gumroad cheatsheet。如果每周重复同类工作，就去 50 Prompt Templates 或 Setup Guide。如果问题是 rollout、risk 或 revenue design，就去 咨询。对本文来说，Setup Guide 提供 policy 基线，consultation 适合生产或收入相关审批设计。

验证指标

发布后不要只看 HTTP 200。要确认 h1、canonical、hero image、正文开头、CTA link、mobile layout 和语言。然后观察审批次数、拒绝命令、rollback note、deploy 证据和咨询意图。如果指标不动，先改第一个具体例子附近的 CTA，而不是重写整篇。