Claude Code 该放权到哪一步？不出事故的自主度四级法则

周五晚上，我对 Claude Code 说了句「把这个博客的旧文章里失效的链接顺手修一下」，就去睡了。第二天早上翻提交记录，发现 12 篇文章都被改过了。链接确实修好了。但它「顺便」连标题的措辞都「整理」了一遍，连我故意保留的旧说法也被覆盖掉了。

我花了两个小时才还原回去。本该很聪明的 Claude Code，为什么要做这些多余的事？答案很简单：我从头到尾都没告诉它「能做到哪一步」。

反过来的情况也有。我被吓到了，于是改成每改一行都来问一句「这个可以执行吗」的设置，结果半小时不到，我就被按审批按钮按到崩溃，最后自己写还更快。放权太多会出事故，卡得太死又累人。很多人就在这两个极端之间迷路。

这篇文章，就是为了终结这种迷路，讲清楚「自主度的四个等级」。只让它读、让它改、让它发布、只有人能碰——把这四条线一开始就划好，之后几乎每一次判断都能省掉。

本文要点

• 把交给 Claude Code 的工作按危险程度拆成四级，判断会轻松很多：只读 / 可回退的编辑 / 发布与上线 / 仅限人工。
• 每一级都必须先定好一个「完成的证据」：出现 diff、build 通过、线上 URL 正确，诸如此类。
• 删除、生产数据、计费、force push，再熟练也不要自动化。这几样每次都由人来按。
• 把等级写成一份 YAML，放在 CLAUDE.md 旁边，Claude Code 自己就能申报「现在处于哪一级」。
• 一开始从低一级起步，只把确认安全的操作往上升级，绝不反过来。

为什么「划线」比「聪明」更重要

在 Claude Code 上栽跟头的人，多数败在工作的收口方式上，而不是模型的性能。开头的我就是这样。指令本身没问题，只是「只改链接」这个范围，我只用一句话交代了。用一句话拜托，跟早上忙乱时对同事的口头吩咐一样，很容易理解偏差。

这时起作用的，就是按危险程度划线。把可以做的事，不靠「拜托的措辞」、而靠「等级」定下来。这样一来，Claude Code 每次想动手，都能对照「这是第几级的操作」。从含糊措辞的解释拉锯，变成了机械的核对。

这个思路并不新鲜。工厂里也一样：只能参观的人、负责组装零件的人、能按出货按钮的人、能打开金库的人，权限从一开始就是分开的。对 Claude Code，无非是划同一条线。

四个等级的具体内容

我实际在用的四级如下。先用一张表给出整体面貌。

等级	让它做什么	完成的证据
0 只读	摸清文件结构、梳理风险、提议确认命令	末尾备注里有「读过的文件清单」
1 可回退的编辑	修改一篇文章、更新一个测试	出现 diff 且 build 通过
2 发布与上线	build 后部署、确认线上 URL	h1、规范 URL、引导链接、回退步骤齐全
3 仅限人工	（不交给 Claude Code）	—

进入第 3 级的是：密钥、计费、生产数据、force push。这里再熟练也不自动化。因为出错时的损失，跟省下的那点功夫根本不成正比。

每一级最关键的，是先定好「完成的证据」。没有证据，哪怕 Claude Code 说「做好了」，你也不知道是不是真的做完。出现 diff、build 通过、打开线上 URL 确认 h1 正确——选这种能用机器核对的东西当证据。

该交给 AI 的范围，和该由人决定的范围

把线划清楚，分工也就自然定下来了。

可以交给 Claude Code 的，是步骤繁多、且结果能用机器核对的工作。读一大堆文件做摘要、按固定格式修改文章、跑测试再读日志。这类活儿它比人更快也更准。

该由人决定的，是无法回退的判断，以及损失巨大的操作。这篇文章到底能不能发、这个旧说法能不能删、这份客户数据能不能覆盖。这里可以让 Claude Code「提议」，但「执行」由人来按。

拿不准时，标准只有一条：「失败了能在 10 分钟内还原吗？」能还原就是第 1 级，不能还原就是第 2 级或第 3 级。开头我那次事故，从还原花掉两小时这一点看，其实本就该按第 2 级的谨慎来对待。

可直接复制的等级定义

把等级只放在脑子里，最后一定会跑偏。请写成一份 YAML，作为 autonomy.yml 放到项目根目录。再让 CLAUDE.md 引用它，Claude Code 自己就会申报「现在是第 1 级，所以不发布」。

# autonomy.yml —— 交给 Claude Code 的自主度划线
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["摸清文件结构", "梳理风险", "提议确认命令"]
    proof: "末尾备注里有读过的文件清单"
  level_1_reversible_edit:
    allowed: ["修改一篇文章", "更新一个测试"]
    proof: "出现 git diff 且 build 通过"
  level_2_publish_or_deploy:
    allowed: ["build 后部署", "确认线上 URL"]
    proof: "h1、规范 URL、引导链接、回退步骤齐全"
  level_3_owner_only:
    allowed: []
    examples: ["密钥", "计费", "force push", "客户数据"]

在 CLAUDE.md 里，只加这么一句就够了。

动手前先读 autonomy.yml，开头先声明本次工作属于哪一级。
第 2 级以上的操作，不要执行，等待人工批准。

用机器核对等级的验证脚本

光让它声明还是不放心，所以我会用机器盯着「第 2 级的操作（发布）有没有在缺证据的情况下被执行」。下面这段脚本会在部署后去抓线上 URL，确认 h1 不为空、规范 URL 指向的是自己的 slug。Node.js 18 及以上可以直接运行。

// verify-publish.mjs —— 用机器确认第 2 级的「完成的证据」
// 用法: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

const url = process.argv[2];
if (!url) {
  console.error("请用参数传入线上 URL");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: 还没发布成功`);
  process.exit(1);
}

const html = await res.text();

// h1 是否存在且有实际内容
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// 规范 URL 是否指向当前这个页面
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`存在 h1:       ${hasH1 ? "OK" : "NG"}`);
console.log(`规范 URL 一致: ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("第 2 级的证据齐了，可视为发布完成。");
} else {
  console.error("证据不足，先别标记为完成。");
  process.exit(1);
}

如果只把 HTTP 200 当成功，那么哪怕显示的是首页 fallback 或旧文章，你也察觉不到。要看到 h1 和规范 URL，才能说「这一级真的结束了」。

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

1. 刚进入一个新仓库时 在还不清楚结构和命令的状态下就让它直接编辑，很容易把配置文件改坏。最开始只放开第 0 级，让它报告文件结构、可用命令、一碰就危险的地方。等地图画出来了，再升到第 1 级。

2. 文章的错别字修正 这种第 1 级就够了。出现 diff 且 build 通过，证据就完成了。开头我那次事故，只要在这里写明「只改错别字，不动文章措辞」，本来就能避免。给 Claude Code 的委托文模板长这样。

请按第 1 级作业。
对象: content/blog/foo.mdx 中明显的错别字
不要做的: 标题改写、文章表达变更、改动其他文件
做完后给我看 git diff，自查改动是否只有错别字修正。

3. 正式发布的临门一脚 第 2 级要务必让它确认：build 是否通过、环境变量是否齐全、diff 是否符合预期、有没有回退步骤。最后把上面的验证脚本跑一遍，连线上 URL 的内容都能查到。

我亲手搞砸过的三件事

老实说，在收敛到这四级之前，我出过好几次事故。

第一件，是一次跨好几级。我省掉第 0 级，直接在第 1 级让它做大量编辑，结果产生了大到没法验证的 diff，连我自己都分不清哪里是对的。现在我一定从 0 开始逐级往上。

第二件，是只靠本地 build 就当作「完成」。本地通过了就发布。但生产环境上显示的是旧页面，我半天都没发现。从那以后，不看线上 URL 的 h1 和规范 URL，就不算完成。

第三件，是把审批只押在自己这双眼上。「最后我自己检查一遍就行」，在疲惫的深夜一定会崩盘。把字数、链接失效、类型错误这类机器能查的检查，纳入每一级的「证据」之后，深夜的疏漏就大幅减少了。

怎么开始

别一上来就奔着全自动的聪明 Agent 去。先挑一个失败了也能还原的小活儿。草稿的错别字检查、改动的初步 review、staging 发布前的确认。这种程度刚刚好。

顺序永远一样。① 把让它读的范围划窄 → ② 把交付物讲清楚 → ③ 确认尽量交给命令去做 → ④ 危险操作（删除、生产数据、计费、force push）一开始全部设成「问人」。只把确认安全的操作，事后一级一级往上升。反方向的降级不做。

如果卡在权限的细节设置上，可以先看Claude Code 入门指南；把等级规则写进 CLAUDE.md 的写法，可以参考CLAUDE.md 写法，这四级就能直接落成配置。如果前提是要让非工程师加入团队，也建议一并看看给非工程师的用法。

常见问题

Q. 等级划分是每次都要手动设置吗？ 不是。做一份 autonomy.yml 让 CLAUDE.md 引用它，之后 Claude Code 就会自己声明「现在是第 1 级」。设置只在最开始做一次。

Q. 连第 2 级的「发布」都自动化，没问题吗？ 如果证据能用机器凑齐，熟练之后自动化是可以的。但一定要像上面的验证脚本那样，加一道确认线上 URL 内容的机制。只信 HTTP 200 是最危险的。

Q. 怎么判断哪些操作该放进第 3 级？ 用「失败了道个歉就能了事，还是要赔偿」来想最快。覆盖客户数据、计费、删除生产数据属于后者，所以放第 3 级。再熟练也不自动化。

Q. 小团队也需要划线吗？ 人越少反而越管用。谁批准的容易变得含糊，把等级表共享出来，「这是该由谁拍板的操作」一眼就能看清。

Q. 把 prompt 写好，是不是就不用划等级了？ prompt 的解释会飘。写好委托文的能力另外靠Prompt 进阶实战去练；而等级划分是「不依赖措辞水平的安全网」。两者都有时最稳。

实际试过之后的结果

把这四级引入自己的博客运营后，开头那种「连没拜托的事都被做了」的事故，归零了。我确认了两点。

一点是，让 CLAUDE.md 引用 autonomy.yml 之后，Claude Code 会在动手前主动声明「本次是第 1 级，所以不发布」。把界限不靠文字、而靠等级来交付，解释就不再飘，这点我深有体会。

另一点是，把 verify-publish.mjs 设成每次发布后必跑之后，过去那种「半天没察觉旧页面挂在生产环境」的现象，能在发布后立刻被检出。只看 h1 和规范 URL，HTTP 200 的坑就填上了。

与其去找更聪明的模型，不如先把「摔了也不受伤的等级」定好。看着像绕远路，但这才是最快的，这是我现在的真实体会。如果你正处于「想给团队把 Claude Code 的权限规则理顺」的阶段，可以在研修与咨询里一起设计这条线。官方的权限设置也建议对照 Anthropic 的文档一并确认。