每人一套规则文件：约定冲突、覆盖顺序不清，怎么收敛成一份

数据截至 2026-07，各工具读取规则文件的位置、触发方式与优先级行为以官方最新说明为准，本文只讲不依赖具体产品的排查方法。

**多数团队把这件事归错了因：以为是「规则写得不够细」，于是继续往里加条目，加到几百行还是压不住——真正的病因是同一时刻有好几份规则在对模型说话，而没有任何人能说清它们谁压谁。**加条目只会让冲突面变大。要修的是层级和来源，不是措辞。

这篇跟站内几篇的分工先说清楚：CLAUDE.md 怎么写 讲一份规则文件内部怎么组织，Cursor Rules 最佳实践 讲单一工具里规则的写法和触发方式，AI 工具的团队治理 讲制度层面的准入、审计和预算；本篇只处理一个具体故障——多人多份规则并存时的冲突排查与收敛动作，从现象倒推成因，一步步收到一份可维护的东西。

一、先别急着合并，先分清是「冲突」还是「没生效」

这两种现象在人眼里长得几乎一样：你写了规则，模型没照做。但成因完全相反，处置动作也相反。

真冲突是「两条规则同时有效且互相矛盾」，比如一条要求所有公开函数写文档注释、另一条要求删掉一切非必要注释。模型每次挑一条遵守，看起来像随机。这种情况的特征是：结果在两种确定的形态之间跳，而不是发散成十种。

没生效是「你以为它读到了，其实没有」。规则文件放在个人目录、被忽略文件排除、或者体量太大被挤出可用上下文，都会让模型完全不知道有这条约束。这种情况的特征是：结果发散、毫无规律，而且模型对该约束毫无自觉——你直接问它「当前有哪些必须遵守的硬约束」，它复述不出来。注意「发散」这一条本身不足以定性，长会话的历史污染同样会让结果发散，两者要靠「能不能复述出约束」来分：复述得出却仍然发散的，问题在会话不在规则文件。

判别的第一步最省事：让模型自己复述。开一个干净会话，不给任何任务，只让它列出当前它认为生效的项目约定，逐条读。复述不出来的，是没生效；复述出来两条打架的，是真冲突。这一步花不到五分钟，能省掉后面一整天的瞎猜。

复述这一招有个已知的坑：模型也可能顺着仓库里的代码风格反推出一条听着很像的约定，让你误判成「它读到了」。所以别只听它说了什么，要追一句「这条的原文怎么写的、在哪个文件里」。答不上原文、只能给出笼统概括的，一律按没生效处理；真读到规则文件的，措辞能大致复述对，也说得出它来自哪一层。这个追问只多花一分钟，却能把「压根没读到」和「读到了但被别的条目压住」分开——只有后者才需要往下走冲突裁决那条线。

复述法还有一个反方向的误判要防：有些工具支持把规则设成按条件附加，只有当你打开或改动匹配的文件时才把它塞进上下文。这类规则在「什么都没打开的空会话」里本来就不该出现，你去问它，它当然复述不出来，但这不是故障。所以空会话复述不出来的条目，别急着定性，先看一眼它的生效条件写的是什么；如果是按条件触发的，就换个姿势验：随便打开一个符合条件的文件、提一个必然会碰到该约束的小要求，看它这时候认不认。两种场景都不认，才轮得上按「没生效」处理。

顺带一提，如果你的团队里有人用 Claude Code、Cursor、Copilot 这类工具，其中部分产品官方对中国大陆有区域限制、不支持直连，团队成员实际的接入方式可能各不相同（存在第三方中转服务，这里不做任何背书，也不给渠道）。接入方式不同会带来模型版本、上下文可用量的差异，这本身就是「同样的规则不同人效果不同」的一个来源，排查时先把这个变量问清楚。

二、判别表：从现象倒推成因

把你手头的现象对到下表，先做验证，再做处置。不要跳过验证列直接执行处置动作。

现象	大概率成因	怎么验证	处置动作
同一仓库不同人跑同一类任务，产出风格差异极大	规则文件在个人本地目录，或被忽略规则排除，没进版本库	在一个干净克隆里跑同样的小任务，看结果是否回到「无规则」形态	把真正生效的规则移入版本库，纳入代码评审
规则里明明写了，模型完全没提及	规则体量过大，或被会话历史挤掉	干净会话里让模型复述硬约束，看能否念出这条	砍规则总量，把长条目拆成按目录触发的小块
结果在两种固定形态之间来回跳	真冲突，两条规则同时有效且矛盾	临时把其中一条整条删掉（见下方提醒：别用注释的方式），两种配置下分别跑同一任务三次：删掉哪条、结果就稳定成另一条的形态，即可坐实	人来裁决删掉一条，不要试图用措辞调和
换一个子目录，同样的要求行为就变	目录级规则覆盖了仓库级，覆盖关系没人写下来	在两个目录各跑同一个最小任务做对比	显式写出层级顺序，并在每层顶部注明它覆盖了什么
同一人、同一目录，两次结果不同	会话历史污染或模型侧不确定性，跟规则无关	新开干净会话连跑三次：收敛了就是会话污染；仍不收敛、且模型复述不出约束，回到上面第二行按「没生效」查	改会话纪律而不是改规则文件
本地看着都对，只有 CI 拦下来	规则文件跟工具链配置（格式化、静态检查）说的不是一回事	本地手动跑一遍格式化和检查命令，比对差异	把可机器校验的约定退回工具链，规则文件里只留一句「以工具链为准」
新人第一天就撞上互相矛盾的说法	没有单一入口，规则散在多个文件和聊天记录里	让新人复述他理解的约定，听他从哪儿看来的	建单一入口文档，其他位置只留指针

两条关于验证方法本身的提醒，不注意的话整张表都会验歪。

第一条：做冲突验证时别用「注释掉」的办法。规则文件多数是 Markdown，很多人习惯用 <!-- --> 把一条包起来当作停用——但那只是渲染时不显示，文件的纯文本内容一个字都没少，模型读到的还是原样，甚至可能因为多了一层包裹更迷惑。要验证就整条剪走，存到另一个临时文件里，验完再贴回来。同理，把条目改成「（暂时不用）xxx」也不算停用，那还是在跟模型说话。

第二条：干净克隆只能排除仓库内的那几份。第一行那个验证动作有个盲区：用户级、机器级的规则文件不跟仓库走，换个克隆目录照样生效，所以「干净克隆里结果没变」不等于「规则没进版本库这件事被排除了」。要把这个变量也摘掉，得让另一个人在他自己的机器上跑同一个任务做对照，或者临时把本机的用户级规则文件挪走再跑一次。这一步经常被跳过，也是「明明团队谁都没写这条约定，模型却一直照做」的常见来源——那条约定长在某个人的个人配置里。

表里还有一条值得单独强调：同一人同一目录两次结果不同，不是规则问题。生成模型本身就有不确定性，会话越长、历史越杂，漂移越明显。这类现象请走 上下文污染排查 那条线，往规则文件里加条目一点用都没有，只会把文件撑大、加剧第二行那个成因。

三、收敛的正确姿势：按层，不按人

多数团队合并规则的做法是把每个人的文件贴到一起去重，结果是一份既长又互相打架的大文件。正确的做法是先分层，再分类。

分三层，层内不许重复。

第一层是不可协商的组织约定：安全红线、密钥不得写进代码、生产数据不得进入任何外部服务、许可证限制。这层只有一份，放在最外层，任何仓库不得覆盖。条目要少，少到每个人都背得出来。

第二层是仓库级约定：这个仓库的技术栈、目录结构、命名习惯、测试怎么跑、提交信息格式。这层跟着代码走，进版本库，改动走评审。

第三层是目录级约定：某个子模块的特殊约束，比如某个目录下不许引入新依赖、某个接口层必须保持向后兼容。这层只在进入该目录时才有意义。

层级一旦确定，必须把覆盖顺序写成一句话放在最外层的开头，比如「下层可以收紧，不得放宽；出现矛盾时以更靠近代码的一层为准，但第一层的安全红线任何层不得覆盖」。这一句话是整套体系的地基。没有它，你合并多少次都会再次分裂。

分两类，分错类是最大的浪费。

一类是机器可校验的：缩进、引号、导入顺序、行宽、是否允许某个语法、依赖白名单。这些一条都不要写进规则文件。写进去的后果是模型不一定遵守，人也懒得看，而工具链的配置文件说的可能又是另一套，三方打架。正确做法是全部交给格式化器和静态检查器，规则文件里只留一句「代码风格以仓库内的工具链配置为准，提交前跑一次格式化」。

另一类是只能用自然语言表达的：这个项目为什么不用某个流行方案、哪些历史包袱不能碰、改动要不要先给出方案再动手、什么情况下必须停下来问人。这类才是规则文件真正该承载的东西，也是机器检查不出来的东西。

分完之后你会发现，多数团队那份几百行的规则文件里，有大半应该被删掉、退回到工具链。剩下的部分往往不到一屏。这才是能长期维护的体量。

四、一次收敛的执行顺序

盘点之前先冻结。找个时间点，跟所有人说清楚：从现在到收敛完成，谁都不要再改自己的规则文件。否则你合并到一半又冒出新版本。

然后是盘点。把仓库里所有可能被工具读到的规则文件、以及每个人本地那份，全部收上来。别只看版本库，本地那份往往才是真正在生效的。可以用一条通用命令看看版本库里这些文件的改动史，判断哪些是活的、哪些是长期没人碰的死文件：

# 带日期列出这个文件近半年的改动，最上面一行就是它最后一次被人碰的时间
git log --since="6 months ago" --date=short --pretty=format:"%ad %h %s" -- <规则文件路径>

不要用 --oneline，它不带日期，只能告诉你「有没有人改过」，判断不出「多久没人改了」。还有个容易误判的地方：默认不跟踪改名，一个被移动过位置的规则文件，历史会在改名那一刻断掉，看起来像「很久没人碰」。怀疑动过位置的，加上 --follow 再看一次：

git log --follow --since="6 months ago" --date=short --pretty=format:"%ad %h %s" -- <规则文件路径>

半年内一条记录都没有的，基本可以按死文件处理；但删之前仍要问一句原作者，有些约定就是三年不变、一变出事。

接着是归类和裁决。把所有条目摊平成一张列表，逐条打标：机器可校验 / 自然语言 / 已过期 / 与他条冲突。冲突项由一个人拍板，不要开会投票——规则文件的价值在于确定性，投票出来的折衷条款往往两边都不满意，模型也读不懂。

然后落成单一来源。一层一份文件，文件顶部写清楚它覆盖谁、被谁覆盖。其他所有位置删干净，别留「历史版本」——留下来的迟早有人读到。

最后是观察。收敛后不要立刻宣布成功，挑两三个典型任务，让三个不同的人各跑一次，对比产出。这一步能抓出「你以为删干净了其实某处还有一份」的情况。

关于改动范围失控这一类的连带问题，见 AI 改动范围失控——规则收敛之后，改动范围类的约束才有可能真正生效，之前它大概率是被别的条目盖掉了。

五、什么情况下别再折腾了

规则收敛是有边际收益的，过了某个点就是浪费时间。以下几种情况请果断止损。

同一条约定改写第三遍仍然不稳定，说明它超出了自然语言约束能覆盖的范围。要么把它变成机器可校验的检查（写个脚本、加条 CI 规则），要么承认它得靠人工评审兜底。继续调措辞是内耗。

规则文件已经超过一屏还在往上加，停手。这时候加的每一条都在挤掉前面的条目，净效果为负。回到第三节重新分类，先做减法。

收敛之后产出质量反而下降，且你能确认不是别的变量在动——立刻回滚到收敛前的版本。这就是为什么规则文件必须进版本库：回滚成本才够低。回滚点就是收敛前那次提交，别靠记忆重建。

# 只把规则文件恢复到收敛前那次提交的状态，其他代码不动
git checkout <收敛前那次提交的哈希> -- <规则文件路径>

这条命令会直接覆盖工作区里这个文件的未提交改动，且覆盖掉的内容找不回来，跑之前先确认这份文件当下没有你还想留的临时修改。

之所以推荐按路径恢复而不是整笔反做，是因为收敛往往和别的改动混在同几次提交里，整笔反做会把不相干的东西一起带回去。如果收敛确实是干净的一笔、且只改了规则文件，那么反做那次提交也可以；要是它横跨好几次提交，就得指定区间反做，而区间里一旦混进合并提交，命令还要额外指明保留哪一侧的父提交——到这个份上，按路径恢复反而更省事、范围也更可控。恢复完记得当场提交一次并通知所有人，否则本地还在跑新版的人会跟你分叉。

争议卡在「团队要不要统一某种写法」而不是「规则文件怎么组织」，这不是本篇能解决的问题，也不是加规则能解决的问题。它是技术选型分歧，该开会开会，规则文件只负责把结论记下来。

只有一两个人在用 AI 编程工具，那就别搞三层体系了。一份仓库级文件、十来条，够用。分层的成本要在多人多目录的场景下才划算。

六、避坑清单

**把工具链能管的事写进规则文件。**踩的原因是这些条目写起来最容易、看起来最具体，让人有「我把规则写细了」的成就感。避法是定一条硬标准：凡是能用一条命令检查出来的，一律不进规则文件。

**用个人偏好当团队约定。**踩的原因是收敛时谁的文件先被读到，谁的习惯就成了默认值。避法是裁决时逐条问「这条如果不遵守，会造成什么可观察的损失」，答不上来的直接删。

**在规则里写「尽量」「建议」「一般情况下」。**踩的原因是不想把话说死，怕挡了特殊情况。后果是模型对模糊表述的执行完全不可预期，人读了也不知道该不该遵守。避法是每条要么是硬约束，要么删掉——真有例外，把例外条件写清楚。

**规则文件不进版本库。**踩的原因是它「不是代码」，随手放本地了。后果是改动无迹可查、无法回滚、新人拿不到、每个人的版本悄悄分叉。避法是把它当代码对待，改动走评审，评审时至少确认一件事：有没有跟已有条目矛盾。

**合并时只做去重不做裁决。**踩的原因是去重有明确操作、裁决要担责任。后果是矛盾条目被原封不动地并排放着，冲突从「多份文件之间」变成「一份文件内部」，更难发现。避法是合并环节强制指定一个人拍板，允许他删掉别人的条目。

**为一次性任务往规则文件里加条目。**踩的原因是当下确实有效，加完就忘了删。后果是三个月后没人知道这条为什么在这儿，也没人敢删。避法是临时约束放在当次会话里说，规则文件只放长期有效的东西；实在要加，就在条目后面注明生效背景和复查时间。

**收敛完不通知人。**踩的原因是觉得文件改了大家自然会看到。后果是有人继续用本地旧版本，你以为收敛完了其实还有第二份在跑。避法是收敛完成后要求每个人删掉本地那份并确认一次，这一步不能省。

收尾

这类问题的本质不是「规则不够好」，而是「说话的人太多」。收敛的目标不是写出一份完美的规则，而是让任何一个人在任何时候都能回答出「现在这条约定以哪份文件为准」。做到这一点，剩下的措辞问题都是小修小补。

收敛完成后，对着这张清单自检一遍：

• 干净会话里让模型复述硬约束，它能念对吗；
• 覆盖顺序有没有写成一句明确的话，放在最外层开头；
• 规则文件里还剩几条是工具链能查的，都退回去了吗；
• 每份规则文件都在版本库里、改动都走评审了吗；
• 本地散落的旧版本，有没有拿到每个人的删除确认；
• 找三个人跑同一个任务，产出是不是收敛到同一种形态；
• 回滚点在哪一次提交，你能立刻说出来吗。

七条全过，这件事就算收住了。过不了的那条，回到对应章节重做一遍，不要靠往规则里加字来绕过去。