团队使用 Claude Code 为何需要共同规则

10 个开发者都在用 Claude Code，产出却可能像来自 10 套工具：有人先核对需求，有人直接生成代码，有人顺手改掉半个仓库。作者认为，团队真正缺的不是一份更长的提示词，而是一套共同执行的工作规则。

他的方案是把需求确认、实现和自审拆成不同阶段，再用精简的 CLAUDE.md、按需加载的 skills 和规则变更记录串起来。这套思路值得借鉴，但原文没有提供落地后的对照数据，不能据此断言团队会交付得更快。

为什么代码写对了，任务还是会做错

作者首先指出一种容易被速度掩盖的失败：需求还没核实，代码已经写完。

原文举了一个场景：开发者贴入工单，4 分钟后得到 300 行能运行的代码，测试通过，合并请求也建好了。两天后，才有人指出工单表达的其实是另一件事。这个例子用来说明风险，原文没有交代它是不是一次真实事故。

跨语言协作会放大这种偏差。需求可能经过翻译、中间人转述，最后只剩一张截图或两行聊天消息。模型照着文字完成任务，并不等于团队理解了提出需求的人想要什么。

作者提出的 requirement-first skill，要先复述任务、列出假设和待确认问题、明确涉及的文件，然后停下来等待确认。每个问题旁边还要给出一个最佳猜测，让确认尽量简化成一句「OK」。

测试能检查实现是否符合断言，却不能替团队确认断言是否来自正确的需求。

这里最有用的动作，是把隐含理解写出来。尤其是「列表支持筛选」「调整登录逻辑」这类工单，先写清输入、行为和边界，通常比直接让 AI 开工更容易暴露分歧。

为什么改动太大和规则太长，会一起拖累评审

第二类问题是产出无法有效评审。AI 可能多改文件、顺手重命名、调整无关格式。面对涉及 40 个文件的 diff，评审者要么粗看后通过，要么整体退回，前者漏问题，后者抵消节省的时间。

作者把原因归结为团队没有定义「可评审的改动」：哪些文件可以动，改动多大需要拆分，哪些内容不能顺手处理。

但把这些要求全部塞进 CLAUDE.md，也会出现另一种负担。按原文描述，CLAUDE.md 每次都会完整加载；如果一个月内膨胀到 800 行，修一行错别字也要带上整套架构说明、部署步骤和历史教训。

他的分工是：仓库事实放进 CLAUDE.md，阶段性流程交给 skills。前者回答项目是什么、目录在哪里，后者规定某个阶段该怎么做。

作者还给出一项具体机制描述：skill 列表约占上下文窗口的 1%，超出后会从调用最少的 skills 开始丢弃描述。因此，保留 20 个不用的 skills，可能让真正重要的 3 个失去自动触发所需的描述；手动输入 /skill-name 仍然有效，导致问题不容易被察觉。原文称 /skill-doctor 可以查看从未调用过的 skills，但没有说明适用版本，也没交代这个命令的来源，实际采用前需要核实。

第三种常见补救是让代码评审兜底。作者反对把所有问题留到这里，因为需求、范围和改动大小，本来可以更早约束。Wiki 里的共享提示词同样不够：开发者未必打开，模型也未必读到。

三层规则怎样进入每天的工作

作者建议把根目录 CLAUDE.md 控制在 40 行以内，只保留仓库介绍、目录位置和三条通用规则：先书面确认需求，只改任务明确的文件，交给人之前先自审。

具体工作拆成三个 skills：

• requirement-first 负责需求复述、假设、问题和文件范围，并等待确认。
• implement 负责整个任务的范围、大小限制和测试规则，目标少于 300 行改动；超过 500 行时，停止并提出拆分方案。
• review 输出固定格式的自审结果，并直接用作 MR 描述，其中最有价值的一项是「look here first」，指出最可能出错的一两个位置。

流程还要覆盖 BA、QA 和 PM。他们通过浏览器使用 Claude，仓库里的 .claude/skills/ 对他们不起作用。因此，作者建议在 Claude Project 中放入一屏能读完的角色规则，让 BA 生成的工单直接符合需求确认阶段期待的格式。

规则本身也需要维护。作者描述了另一类失效：有人为本地问题改 CLAUDE.md，有人把旧版复制到新仓库，还有人的个人覆盖配置与团队规则冲突。六周后，团队可能已经说不清哪个版本有效。

他的约束是：每次规则变更都记录到 CHANGELOG.md，并通过 PreToolUse hook 阻止对 CLAUDE.md 和 .claude/ 的编辑，除非 CHANGELOG.md 已经处于变更中。评审者则先读自审，再看 diff，缺少自审的 MR 直接退回。

我的判断

我赞同把规则放进工作入口，并让自审结果进入 MR。相比 Wiki 文档，这样更接近实际执行；相比不断加长 CLAUDE.md，分阶段加载也更容易维护。

但原文给出的是流程建议，没有前后对照数据。作者明确不承诺提速，300 行目标、500 行拆分线、40 行根文件，都应看作起始约束。生成文件、锁文件和一次必要的接口联动，都会影响行数的解释，不能只凭数字判断改动是否合理。

「只改任务明确的文件」也有前提：需求确认时能识别大致范围。实际排查中发现必须补改其他模块，应当允许重新确认范围，否则容易逼出绕路实现。

此外，hook 检查 CHANGELOG.md 是否有变更，只能约束操作顺序，不能保证记录准确，更不能替代规则负责人。作者强调了所有权，却没有展开谁负责、怎样处理规则冲突。

能拿来做什么

• 在前端或 Node 工单执行前，让 AI 写出预期行为、未确认问题和预计修改文件；对模糊问题附上建议答案，降低确认成本。
• 给 AI 明确改动范围，把无关重命名和格式调整移出当前任务；先试用少于 300 行的目标，超过 500 行时要求说明拆分方式。
• 固定 MR 自审格式，至少包含改了什么、做了哪些验证、哪里最可能出错，并让评审者从「look here first」开始检查。
• 先观察两周，记录自审覆盖率、改动行数中位数、因范围或大小被退回的 MR，以及澄清问题后改变实现方向的工单数，再决定哪些规则值得保留。