Claude Code 团队上线前先建一张「风险台账」：权限、CI、发布全都别踩坑

周五傍晚，同事突然说：「Claude Code 太好用了，下周咱们全组一起上吧。」

我心里咯噔一下。他一个人用的时候，自己开分支、自己审、自己合，出了岔子也只伤到他自己。可一旦变成全组用，故事就不一样了：谁批准、能动到哪一步、谁来确认改动？这些没说清楚就让六个人一起开干，那「不知不觉合进一条删掉生产库的改动」之类的事，真的会照常发生。

我在另一个团队就栽过这个坑。三个人各按自己的习惯配置 Claude Code，其中一个人随口说了句「帮我整理一下吧」，结果共享配置文件被改写，周一早上部署全线崩了。光定位原因就花了半天。没人是故意的，只是当时压根没有「全组一起托付时的规则」。

于是我做了这篇文章要讲的风险台账。说是台账，其实就一张表。但有没有这张表，决定了你的 Claude Code 团队上线是以「轻松多了」收尾，还是以「天天擦屁股」收尾。

本文要点

• 团队上线翻车，不是因为模型不够聪明，而是因为「谁来做、能做到哪、谁来确认」没定下来。
• 风险台账就是一张表：每个危险区域用一行写清「负责人、验证方法、放行条件」。一开始三行就够。
• 先把三件事钉死：权限（让它动哪些文件）、CI（改动没坏的证据）、发布（生产上线的确认）。
• 交给 Claude Code 的，只到「写草稿和跑验证」为止。删除、生产库、扣费、force push，必须由人来批准。
• 文末有可直接跑的台账模板，和拦截危险操作的配置示例。诀窍是：先只拿一个文件试。

风险台账到底是个啥？

风险台账，就是把「团队托付 Claude Code 干活时，最容易出事的地方」列成一张表。

每一行只需要三列：哪里危险、凭什么说它安全、谁来做这个确认。就这些，不需要什么花哨的管理工具。一开始一张电子表格就行，甚至代码里的一个数组都够用。

为什么非要做成表？因为「大概注意一下」才是最危险的。人一忙起来，一定会跳过确认。做成表，定好「这一行填满前不许合并」，那么再忙的周五傍晚也能把事故卡住。开头那次部署事故，只要事先把共享配置文件写成一行「禁止触碰区域」，就完全能避开。

先钉死三个危险点

团队上线翻车的地方，基本就集中在下面三处。反过来说，只要这三处写进台账，第一天的大事故就几乎都能挡住。

1. 权限（让它动哪些文件）

最常见的事故是「放权太多」。你说一句「帮我整理一下仓库」，Claude Code 会连配置文件、CI 定义都照改不误。所以哪里能改、哪里绝对不许碰，要提前用文字定下来。

我的标准很简单：文章、草稿、测试代码可以碰；.github/、生产环境变量、部署配置、数据库迁移，一律「等人确认前停下」。这条线要是任各人喜好去画，规则就会五花八门，最后总是那个管得最松的人闯祸。全组统一成一套，才是关键。

2. CI（让它拿出没坏的证据）

Claude Code 说「我修好了」，那只是它的感想，不是证据。所以要把「证明改动没坏」的命令写进台账：构建能过、测试变绿、没有类型错误，这几样里至少跑一样，定为「报告成功之前必须执行」。

这里有个要点：验证命令一定要快。全量测试要跑十分钟，没人愿意跑。把「只跑跟改动相关的测试、30 秒内出结果」配置好，确认才会变成习惯。

3. 发布（生产上的改动一定要亲眼看）

不管是博客的收入页面还是 API，凡是会对外的改动，都要留下「有没有用真实 URL 看过」的记录。构建能过，和用户实际看到的页面正确，是两回事。打开生产 URL，截一张图存下来，把这个定为完成条件。

发布 URL 返回 200，但内容是另一个页面，那跟没发布一样。中文页面里混进了英文正文，那也是没做完。看着是常识，可越是赶的日子，越容易跳过这一步。

哪些交给 AI，哪些由人来定

划线拿不准时，直接用下面这张表。判断标准只有一个：能不能撤回。

操作	交给 Claude Code	人批准后再执行
写草稿、改草稿	◯
跑测试、跑构建	◯
说明改动内容（总结差异）	◯
删除文件		◯
写入生产数据库		◯
会产生费用的操作		◯
force push、改写历史		◯
部署、生产上线		◯

规则只有一条：撤回起来很费劲的操作，一开始全部设成「先问人」。只把确认安全的操作，事后再升级成自动。与其一上来就放松、结果出事，不如先卡死、再一点点放宽，最后反而更快。

可复制的风险台账模板

先在发起请求之前，把交给 Claude Code 的指令做成模板。每次粘贴一遍，就能防住它擅自扩大范围。

开始干活前请遵守以下几点。
- 只能编辑 src/content/ 和 tests/ 里的内容。
- .github/、生产环境变量、部署配置、数据库迁移一律不碰。如果确实需要动，不要直接改，先说明理由并报告。
- 改完之后必须执行 `npm run check`，并报告结果。
- 一旦需要删除、写生产库、产生费用或 force push，不要执行，先来确认。
开始编辑前，请先用你自己的话把上面这些约束复述一遍，再动手。

然后是台账本身。一开始三行就够，把这里换成你们团队自己的危险点即可。

// 团队上线风险台账：每个危险点用一行写清「负责人、证据、放行条件」
type RolloutRisk = {
  area: string;       // 危险区域
  risk: string;       // 可能会发生什么
  owner: string;      // 负责确认的人
  proof: string;      // 凭什么说它安全
  nextGate: string;   // 满足什么才能往下走
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "权限",
    risk: "Claude Code 把共享配置也改了",
    owner: "组长",
    proof: "可编辑、禁编辑清单已成文",
    nextGate: "先只拿一个文件试",
  },
  {
    area: "CI",
    risk: "验证命令太慢，或者根本没有",
    owner: "开发负责人",
    proof: "构建变绿，或相关测试变绿",
    nextGate: "把验证步骤写进 PR 模板",
  },
  {
    area: "发布",
    risk: "上生产的改动没用真实页面确认过",
    owner: "运维负责人",
    proof: "发布 URL 的截图",
    nextGate: "把回滚步骤写进备忘",
  },
];

console.table(rolloutRisks);

存成能用 node 跑的文件执行一下，就会打印出这张表。它不华丽，但价值在于「开干之前，能把危险点用语言说清楚」。只要定下「每一行填满前不合并」的规则，台账就成了事故的看门人。

这些团队最受用（三个实例）

如果你的处境跟下面相近，别重新造台账，把名字换掉直接用就行。

1. 两个人的小团队 动共享代码之前，把「哪里能改、哪里不能碰、哪些操作需要人批准」三个人一起念一遍，落成一张表。光这一步，就能消掉「一方不知情就把配置弄坏了」的事故。越是小团队越容易栽在「不说也该懂吧」上，所以一开始就写成文字，价值反而最大。

2. 走代码评审的团队 组长定规矩：Claude Code 做出的改动进评审之前，必须附上「验证命令的执行结果」和「改动要点」。没有这两样的 PR，一律不看。目标是让评审者能读懂差异、重跑验证、说清怎么回滚。

3. 有收入页面的团队 博客、商品页这类直接关系到钱的页面，改动在标记为完成之前，先存一张发布 URL 的截图。别停在「构建过了」，要确认用户真正看到的画面：标题、正文、图片、引导，是不是都跟预期一致，用眼睛过一遍。

常见的翻车，和怎么修

老实说，这张台账我一开始也没玩转。分享三个我踩过的坑。

各人自己造了一套规则 最早把配置交给个人，结果每个人能编辑的范围都不一样。出事的，永远是设置最松的那个人。修法很简单：把可编辑、禁编辑清单全组统一成一份，放进仓库。

把 CI 失败往后拖 一旦「回头再一起改」成了口头禅，第一次团队上线就会落下「装了 Claude Code 反而老崩」的坏印象。后来我定规矩：验证命令一挂，当场停手，没变绿之前一直按草稿处理。

负责人含糊不清，难判断的事就拖着 不定「谁来批准」，最难的生产上线判断就悬在半空。台账里的 owner 列必须填满，不许留空往下走。光是这一条，判断就不会再卡住。

一旦感觉活儿开始往外扩，别去重写整段请求，按这个顺序收紧：缩小可碰范围 → 先拿出验证 → 指定一个确认负责人。把失败也在团队内部当成共享留存下来，同样重要。只盯着成功案例，你就察觉不到自己其实已经踩进危险区。

常见问题

问：小团队也需要台账吗？ 两个人也需要。恰恰是人少，越容易想当然觉得「不说也懂」而出事。一开始三行模板就够，五分钟做完分享出去就行。

问：光靠 Claude Code 的权限设置不够吗？ 权限设置是「不让它碰的机制」，台账是「谁用什么来确认的运营规则」，两个都要。用设置在技术上拦死，用台账让人来确认。详见权限设置指南。

问：验证命令该选哪个？ 选你们团队里能说「没坏」的那条最短命令。类型检查、只跑相关测试、构建，三选一。全量测试要十分钟没人愿意跑，所以先定一条 30 秒能跑完的。

问：组里有非工程师也能转起来吗？ 能。台账就是读表、填表，不会读代码也能运营。非工程师的入门可以参考给非工程师的用法。

问：项目专属的规则写在哪里好？ 写进仓库的 CLAUDE.md，Claude Code 每次都会读。把禁编辑区域和验证命令集中到这里，就容易跟台账对齐。写法整理在CLAUDE.md 的写法里。也请把 Anthropic 官方的 Claude Code 文档当作一手资料确认。

实际试下来的结果

开头那次部署事故之后，我就不再纠结「该不该信 Claude Code」了。我改成看一件事：台账里哪一行还没填。

实际上线了三行的台账，把共享配置文件明文写成「禁止触碰区域」之后，弄坏配置的合并就归零了。把验证命令定成「报告成功前必须跑」之后，「评审时才第一次发现坏了」的情况没了，打回明显变少。给发布页面加上截图确认之后，「构建是过了，可显示的是另一个页面」这种漏看，也止住了。

我确认的就这三点。与其去找一个更聪明的 agent，不如先搭好「摔了也能爬回来」的运营流程。看着像绕远路，但在团队上线这件事上，这才是最快的，是我现在的真实体会。

如果你想在公司里正经推进 Claude Code 的导入、想一起把运营规则设计出来，那么培训・咨询可以陪你把具体步骤一步步搭起来。先从写出你们团队的三行危险点开始吧。