Claude Code 审批不再纠结：read/edit/run/deploy 判断日志怎么写

周五傍晚，我让 Claude Code「只把这个页面的链接改一下就行」。回来的却是满屏的确认提示：「可以执行这条命令吗？」累了一天的我，内容都没怎么看就按了回车。

第二天早上，线上站点的价格显示变了。原来在改链接的「顺手」之间，AI 把另一个写着价格的文件也一起「顺便」改了。而按下那个允许按钮的，确确实实是我自己。

问题不在于 AI 够不够聪明。真正的麻烦是：昨天点了 OK 的操作，和今天该拦下来的操作，这条界线只存在我脑子里，每次还会飘。如果「算了无所谓」会随当天心情而动，那事故就只是时间问题。今天我就来写这条界线该怎么搬到脑子外面去——也就是「审批日志」的做法。

本文要点

Claude Code 的审批，拆成「读取、修改、执行、发布」四类后，纠结就消失了。
每类操作分到「允许、确认、禁止」三档，把理由和验证命令每天记在一个文件里。
交给 AI 的是查资料和打草稿，人要亲自把关的是价格、线上发布、删除这几类。
文中放了可直接复制的日志模板，以及让 AI 帮你起草分档的提示词。
拿不准就别放进「允许」。光靠这一条，「顺手事故」基本就没再发生过。

把审批拆成「读取、修改、执行、发布」四类

用 Claude Code 的时候，各种确认会接连弹出来。之所以每次都累，是因为把它们一股脑当成「Yes 还是 No」来想。把要做的事分成四类，判断一下子就轻了。

读取：只是看文件或日志的内容。基本上放「允许」也不会出事。
修改：改写文件。改文章里的错别字可以随意，价格表就是另一回事了。
执行：跑一条命令。本地验证可以随意，但会影响外部的命令要慎重。
发布：把改动反映到线上站点。这一档我永远当成最后一道防线。

同样是「修改」，博客正文里的错别字和支付配置文件，分量天差地别。所以我后来不只看操作类型，还把「具体是哪个文件」一起定下来。

把判断分成三档

分好四类之后，每一类再分三档。不需要什么难懂的术语。

档位	含义	例子
允许	不用问，直接做	读取文章目录、改正文里的错别字
确认	先来问我一句	改价格文件、发布到线上
禁止	这次不让它做	批量删除文件、强制覆盖

诀窍只有一个：只要有一丝犹豫，就别放进「允许」，先扔进「确认」。等以后确认了「这个每次都安全」，再升级到「允许」就行。一开始把所有缰绳都攥在手里，只有验证过安全的才松手。光是守住这个顺序，开头那种价格事故就不会再发生。

每天记在一个文件里：日志模板

想靠脑子记，迟早会崩。每天就一个文件，把当天的分档写下来。格式怎么都行，我最后定型成下面这样，复制过去就能直接用。

{
  "date": "2026-06-07",
  "范围": "只换文章正文和引导链接",
  "读取":   { "允许": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "修改":   { "允许": ["新建的文章文件"], "确认": ["价格", "支付配置", "线上密钥"] },
  "执行":   { "允许": ["npm run build", "公开 URL 的显示检查"], "确认": ["发布", "git push"] },
  "发布":   { "确认完才发": ["构建通过", "公开 URL 的 h1 正确", "逐语言目视检查"] },
  "下次备注": "价格今后仍保持确认。文章引导链接的替换，确认安全后升到允许。"
}

写下来也就两三分钟。但正是这两三分钟，省掉了第二天「咦，这个昨天到底怎么处理的来着」要纠结的十分钟。范围 那一行看着不起眼，作用却很关键：先写清楚今天的活儿做到哪儿，AI 一旦越界你立刻就能察觉。

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

这两者一旦混在一起就会出事。先把界线划清楚。

可以交给 AI 的

找出哪些文件可能相关
写改动的草稿
把改动前后的差异展示出来
跑「构建能不能通过」这类验证命令

人必须亲自把关的

碰价格、支付、报名表单的改动
发布到线上站点（发布按钮自己按）
删除文件或数据
说不清怎么还原的操作

我的规则很简单：只要牵扯到「钱」「线上」「删除」「无法还原」这四样，最后一定亲手拍板。反过来说，除此之外的查资料、打草稿，尽管放心丢给 AI。这套划界思路在写给非工程师的 Claude Code 入门里也提过——哪怕没有专业知识，只要定下「钱和线上的事归我自己」，就足够守住底线了。

让 AI 帮你起草分档的提示词

分档这件事本身，也可以让 AI 搭把手。只是别对它给的结果照单全收，最后一关还得自己看。把下面这段指令原样贴进去就能用。

请帮我把今天 Claude Code 的工作，按「允许、确认、禁止」三档来分。
对象是这四类：读取 / 修改 / 执行 / 发布。

每一项请给我返回：
1. 可以允许的操作清单
2. 应先确认一次的操作清单
3. 本次禁止的操作清单
4. 用来验证安全的确认命令（例如：npm run build）
5. 面向下次的备注（确认 → 升到允许的条件）

凡是牵涉价格、支付、线上发布、删除的操作，拿不准就放进「确认」。

关键在最后一行。加上这句，就能挡住 AI 擅自把判断放松成「这个允许就行了吧」。想把提示词写得更讲究，可以一起看看 Claude Code 的提示词设计。

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

1. 替换博客文章里的链接 想把热门文章下面那一个报名链接换掉。这种时候如果说「把相关的地方都改一下」，范围就太宽了。先在日志里写好「能动的文件」「不能动的文件」「要检查的公开 URL」。这样改完之后的检查，就从「感觉还行」变成了「凭这个依据可以发布」。

2. 给咨询邮件分类 把收到的咨询丢给 AI 读，让它挑出看起来有意向的。读取放「允许」没问题，但写进客户名单要留在「确认」。这样就算 AI 分类错了，也会在擅自写入线上数据之前停下来。

3. 多语言文章发布前的检查 就算 frontmatter 里的语言设置是对的，正文也可能还留着没翻译的英文。逐个语言看标题、开头、引导链接这几处，确认那个语言的读者能不能看懂下一步该做什么。把这道目视检查，固定写成「发布前的确认项」。

复制即用：审批日志的检查脚本

日志写得再好，要是把最关键的「发布前确认」跳过了，也就白搭。所以我把发布前必过的检查，做成一个脚本。下面这个例子，让机器替你确认构建能不能通过、线上 URL 的标题对不对。只要有 Node.js 就能跑。

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

内容就这么点。

import { execSync } from "node:child_process";

// 确认通过参数传进来的公开 URL
const url = process.argv[2];
if (!url) {
  console.error("请把要确认的公开 URL 传进来");
  process.exit(1);
}

// 1. 先确认构建能不能通过（这里挂了就不发布）
try {
  console.log("正在确认构建...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("构建失败，停止发布。");
  process.exit(1);
}

// 2. 确认公开 URL 上有且只有一个 h1 标题
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URL 打不开（状态码：${res.status}）。重新检查发布。`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`h1 标题有 ${h1Count} 个。改成只有 1 个再发布。`);
  process.exit(1);
}

console.log("构建、URL、标题都确认通过了。可以放心发布。");

只有这个脚本亮绿灯，我才放行「发布」。反过来说，不亮绿灯的，无论如何都不发。把判断交给机器的对错号，而不是人当下的心情，这才是诀窍。

容易踩的坑，和怎么修

老实说，这些坑我基本都踩了一遍。

只改设置，不写理由。 只更新了配置文件，却不留「为什么这么做」，第二天的自己又会重复同样的纠结。修法很简单：在日志的「下次备注」里写一行理由就够了，比如「价格直接关系到信任，所以保持确认」。

一时冲动就把发布放进允许。 构建一通过，顺着那股劲就连发布也一起允许了。可发布前的确认是另一码事。把线上 URL 的标题、显示有没有错位、手机端显示都看一遍，这些项固定进「确认完才发」，过不了机器检查就不发布。

轻活和重活一视同仁。 把改正文错别字，和改报名链接、改价格当成同一档「允许」来跑，迟早会出开头那种事故。碰 gumroad 链接、价格、表单的活儿，要和改错别字分到不同的格子里。这条界线写进 CLAUDE.md 的写法当成规则，每次就不用重新想了。

常见问题

Q. 审批日志和安全设置有什么区别？ A. 安全设置是把「允许什么」固定下来，审批日志是记下「今天为什么下这个判断」。设置更像规则，日志更像日记。两者都有，第二天的自己或团队成员才能复现同样的判断。

Q. 每天写太麻烦了，怎么坚持？ A. 别追求完美。一开始只写「修改」和「发布」两列，就已经很管用了。做成两三分钟能写完的形式，当成动手前的第一句输入贴上去，就容易坚持。

Q. AI 给的分档建议能信吗？ A. 当草稿很方便，但最终判断由人来做。尤其是牵涉价格、线上、删除的那几行，就算 AI 说「允许就行」，也自己降回确认。目的是减少判断的工夫，而不是把判断本身整个甩出去。

Q. 团队一起用要注意什么？ A. 把日志集中放在一个地方，凡是放进「允许」的操作，都写清楚一个谁看了都会做出同样判断的理由。没理由的「允许」，会因人而异地被解读，正是事故的源头。逐步放宽审批的思路，可以参考安全地提升自主度的步骤。

Q. 小博客也需要做到这一步吗？ A. 规模越小，价格或链接的事故越会直接砸到营收上。恰恰是个人和小团队，更值得从「钱和线上的事一律确认」这一条规则开始。

参考链接

实际试过之后

这套审批日志我坚持了大概两周，最管用的地方意外地是「轻活」。改文章错别字可以安心放进允许，价格、链接、报名表单、发布设置则留在确认。光是先把这个区别写下来，读完 AI 的回复后那种「这活儿是不是该允许来着」每次都要重新想一遍的工夫，就消失了。

最容易犯嘀咕的，果然是「执行」和「发布」。构建可以允许，但没确认线上 URL 就发布，还是太早。有一次，我把标题、显示错位、手机端显示都用眼睛确认了一遍之后，同类的发布从下次起就能升到允许了。判断的台阶就这样留在了记录里，所以审批日志与其说是一份板着脸的安全文档，不如当成一份让每天判断变轻的备忘录来用，这是我现在最实在的体会。

如果你想把这条权限界线整理成适合自己团队的版本，或者想一起把线上发布的规则敲定下来，可以在培训与咨询里落到具体的运营做法上。