今天让 Claude Code 做到哪一步？用四级审批工作表划清边界

周五傍晚，我本来只想往预发布环境里加一个小修改。

我只说了一句：“把文档里的错别字改一下，顺便看看构建能不能通过。”结果 Claude Code 改完错别字之后，自作主张升级了两个依赖包，还顺手改写了 .env.production 里的引用。因为本地构建是通过的，它（这个 AI）一脸轻松地告诉我“已完成”。

让我后背发凉的是，直到我把 diff 从头看到尾，才发现这件事。与其说是 AI 的错，不如说根本原因在我自己——我从头到尾都没有用语言说清楚“可以做到哪一步”。

反过来，另一天我也踩过坑：“是否允许？Yes/No”连续弹了大概 30 次，光是创建一个 commit 就把我的耐心耗光了。放得太宽会出事故，收得太紧又寸步难行。这篇文章讲的，就是一张能在两者之间划出刚刚好那条线的工作表。

本文要点

• 把交给 Claude Code 的工作分成四级：“只读”“只改”“对外发布”“碰机密信息”。
• 每一级都先定好“最后由谁来拍板”和“看到什么才算安全（证据）”。
• 第 0、1 级交给 AI，第 2 级由人确认，第 3 级只允许负责人亲自动手。
• 早上先用一句话宣布“今天就做到这一级”，再开始干活，审批次数会立刻骤降。
• 提供可直接复制的台账代码，以及每天早上一分钟就能定好的模板。

为什么要先定好“审批的预算”

让人在审批上精疲力尽的，不是 Claude Code 的能力，而是还没决定今天放权到哪一级就直接开跑。

不提前决定，人就会往两个极端倒。嫌麻烦，于是对所有操作一路点“允许”，某天连危险操作也放了过去；或者过度谨慎，连改个错别字都要确认一遍，工作彻底卡死。两者的共同点是：把判断完全交给了“当下的心情”。

这时候要用的，就是“审批预算”这个思路。和花钱的预算一样，先框定今天到这条车道为止可以自由发挥，再往前就由人来判断。有了这个框，你就不必每次盯着 AI 的回复提心吊胆。要看的不再是“AI 聪不聪明”，而是“它停在了哪条车道上”。

把判断标准写成文字，团队里也不会扯皮。因为你能说的不再是“总觉得不安所以拦了”，而是“这是第 2 级，轮到人来确认了”。关于权限设计的整体思路，Claude Code 入门指南 里也有提到，但这里要聚焦在更接地气的“今天这条线划在哪”。

把要交出去的工作分成四级

先把想让 Claude Code 做的事，按危险程度排成四级。别想得太复杂，只看三点：“能不能撤回”“会不会对外公开”“会不会碰到钱或机密”。

级别	工作示例	最后拍板的人	算安全的证据
0	读文件、了解结构	交给 AI	读过的范围清单
1	改一个可撤回的文件	AI（人看 diff）	diff 和构建结果
2	反映到公开站点	由人判断	公开 URL 和回滚步骤
3	碰机密信息、计费、客户数据	仅限负责人	书面审批

这张表的精髓在右边两列。“谁来拍板”和“看到什么才算安全”，必须在开始动手之前就定好。如果事后再定，就会被 AI 那句“已完成”的气势带着走，把确认环节直接跳过去。

第 1 级里的“可撤回”是关键。改错别字、加注释，就算改错了也能马上还原。所以可以交给 AI，人只需快速扫一眼 diff 就行。而升级依赖包则要提升到第 2 级——看着是小事，但影响范围根本看不清。开头我那场事故，正是因为把这件事当成了第 1 级。

交给 AI 的范围，和由人判断的范围

把这条线再画得清楚一点。可以交给 AI 的，是就算出错也能马上发现、马上还原的工作；该由人判断的，是一旦执行就会对外产生影响的工作。

• 交给 AI：读、查、写草稿、改一个可撤回的文件、跑测试
• 最后由人判断：对外发布、改动生产数据、向外部服务注册、升级依赖、删除

拿不准时就把级别往上提一级。记住这一条，就不会大错特错。只有当你确信某个操作安全后，再事后把它一级一级往下调、逐步自动化。诀窍是别一上来就追求全自动。这种“逐级提级”的思路，和写项目规则的 CLAUDE.md 写法 也很搭——把定好的边界写进文件，下次就能复现。

可直接复制的审批台账

光靠嘴说，转头就忘。所以把这四级做成机器能读的形式，让“今天到哪一级”可以用过滤直接列出来。只要装了 Node.js 就能直接跑。

// 审批台账：给每件工作配上“危险级别”“负责人”“证据”
const approvalBudget = [
  { action: "读文件",                   level: 0, owner: "AI",          proof: "读过的范围清单" },
  { action: "改一个可撤回的文件",        level: 1, owner: "AI（人确认）", proof: "diff 和构建结果" },
  { action: "反映到公开站点",            level: 2, owner: "人",          proof: "公开 URL 和回滚步骤" },
  { action: "碰机密信息或计费",          level: 3, owner: "仅限负责人",    proof: "书面审批" },
];

// 今天的上限。0 表示只读，1 表示连可撤回的修改也交给 AI
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`今天交给 AI 的上限：第 ${todayMax} 级`);
console.table(allowedToday);
console.log("由人判断的工作：");
console.table(needsHuman);

运行就这么简单。用环境变量就能切换“今天的上限”。

# 今天连“可撤回的修改”一起交给 AI
APPROVAL_MAX=1 node approval-budget.mjs

# 今天只让它读
APPROVAL_MAX=0 node approval-budget.mjs

字段名保持原样，把 action 和 proof 的内容改成你自己项目的情况就行。把这段代码丢给 Claude Code，让它“按我这个仓库的情况把值填进去”，很快就能得到一份草稿。

每天早上一分钟搞定的提示词模板

台账做好后，在开始干活前先把“今天的框”告诉 AI。复制下面这段，把空白填上就行。

先定好今天的工作范围。

- 今天的目标：（例：修一篇博客文章的错别字和失效链接）
- 可以读的范围：仅限 site/src/content/blog/
- 可以改的范围：上述范围内的一个文件（仅限可撤回的改动）
- 可以执行的命令：npm run lint、跑测试
- 不要碰的：.env、生产部署、升级依赖包、删除

规则：
- 第 2 级及以上（发布、生产数据、升级依赖、删除）必须先问我，然后停下。
- 改完后，把改动的 diff 和构建结果作为“证据”，最后汇总展示。
- 不要只说一句“已完成”，要写清是用哪个命令确认的。

光是有这一段，AI 就会停止“先把所有事都做了再说”，转而在框里行动。熟练之后，可以照着 CLAUDE.md 写法 把这段内容搬进项目的规则文件，连每天早上粘贴的麻烦都省了。

这些场景里特别管用（三个）

1. 博客或资料的批量校对 只说“把文章改一下”的话，AI 会把正文、图片路径、链接一锅端全改了。用审批台账把“正文错别字算第 1 级，发布上线算第 2 级”分开，就能既把文字交给它，又把发布按钮留在自己手里。让它把 diff 和构建结果作为证据交出来，深夜复查会轻松很多。

2. 咨询的分类 读进来的咨询并做分类，是第 0 级，可以交给 AI。但写入客户台账是第 3 级。哪怕 AI 判断“这单可能能成交”，往生产数据库里写入这一步也得挂起，直到负责人亲手按下确认。用台账把这一点强制下来，“把分错类的客户擅自登记进去”这种事故就消失了。

3. 部署前的那口气 对外发布一定放到第 2 级。别因为本地构建通过就当成“完成”，要一直停到确认完公开 URL、标题、回滚步骤为止。开头我闯的那个祸——“擅自升级依赖包”，只要明确标成第 2 级，就一定会在人的确认环节被拦下来。

常见的绊脚石与修法

最常见的，是想用一次委托把所有事都做完，结果造出一个谁也没法验证的巨型 diff。修法很简单：把委托收窄到“一次只产出一个成果”。一篇文章、一个 PR、一处配置。切得够小，diff 才能从头读到尾。

第二常见的，是只凭本地构建成功就当成完成。公开站点上明明显示的是别的页面或首页，却只看到 HTTP 200 就放心了。在证据那一栏写上“确认公开 URL 和标题”，就能在这里停住。

第三个，是不留下试过什么。第二天又得把同样的判断从头来一遍。只要照后文那份备忘留一行，第二天的自己就不会再犯迷糊。如果想从根上提升对 Claude Code 的委托方式，建议一并读一读 进阶提示词设计实践，传达“框”的功力会再上一个台阶。

常见问题

问：审批的级别，是不是分得越细越好？ 一开始四级就够了。分得越多，运营就越复杂，最后反而没人遵守。先跑一阵，只对那些觉得“这里太粗”的地方，事后再细分出枝节。

问：第 1 级的“可撤回”到底怎么分辨？ 看两点：“能不能用一条 git 命令还原”“会不会对外产生影响”。改文件能还原，但部署、计费、发邮件、删除都还不回来。拿不准就提到第 2 级。

问：团队里用的时候，谁来定级别？ 开始干活的人早上先宣布，并提前定好第 2 级及以上的拍板者。如果负责人不在，就约定那天不做第 3 级的工作，这样最安全。

问：每次都要粘贴提示词，太麻烦了。 等框固定下来后，把它搬进项目的规则文件（CLAUDE.md）。AI 每次都会读它，就不用再粘贴了。

问：非工程师也能用这张工作表吗？ 能用。就算不跑代码，光靠四级表格和提示词模板也能划清边界。非工程师的用法，可以参考 写给非工程师的 Claude Code 实用指南。

用于交接的备忘

把当天的判断用一行记下来，第二天的自己或团队就不会再重复同样的纠结。复制下面这个格式填上就行。

- 日期：2026-06-07
- 今天的目标：修一篇博客文章的错别字和失效链接
- 今天的上限：第 1 级（到可撤回的修改为止）
- 证据：diff、npm run build 的日志、公开 URL 的标题确认
- 人拦下来的地方：升级依赖（属第 2 级，挂起）
- 给下次的交接：依赖升级改天集中起来，按第 2 级执行

有了这份备忘，发布后的确认也省力。光看 HTTP 200 还不够，要在公开 URL 上确认标题、规范链接（canonical）、封面图、正文开头是不是都对得上这篇文章。如果显示的是别的文章或首页，就当作未发布，重新跑构建和部署。关于权限设计的官方思路，也可以在 Anthropic 官方文档 里查到。

我实际试下来的结果

我把这张工作表，套用到自己的博客运营上，连续试了两周。

最管用的，是养成了早上贴一句“今天就做到第 1 级”的习惯。光是这一下，每个 commit 弹出的“是否允许？”，体感上就降到了一半以下。AI 一想往第 2 级以上踩，就会照模板里的规则乖乖停下来问我。开头那种“回过神依赖已经被升级了”的事故，从那以后是零。

反过来我也明白了一件事：级别表光做出来是不会去用的。把台账代码真正跑起来，把“今天要交出去的工作”显示在屏幕上再开始干活，遵守的概率才会上去。与其去找更聪明的 AI，不如先划好一个“摔了也能爬起来”的框。听着不起眼，但这是目前我体会到的、最不让人心累的放权方式。

如果想把这条线推广到整个团队，乃至生产环境运营，欢迎在 培训与咨询 里一起把具体的车道设计敲定。先从明天早上，贴一句“今天就做到第 1 级”开始试起吧。