Rules 冲突排查：多条规则互相打架时如何用优先级、范围与示例消歧

Rules 写到一定密度，故障形态会从「模型不听话」变成「模型太听话」------它同时执行了两条互相打架的指令：一个说「测试必须先红后绿」，另一个在域规范里写「先实现再补测」；一个 Always 要求「最小 diff」，一个 glob 规则鼓励「顺便整理导入」。你看到的症状是风格漂移、重复返工、或 Agent 在解释里自我打架。

本文承接 10-01「Rules 工程化」：那边讲模块与触发，这边讲 冲突排查 。字段名以你当前 Cursor 版本为准；目标是 行为一致，不是把规则文件写得更长。

摘要

先复现：固定提问，记录矛盾输出。
再枚举：列出 Always 与命中的 glob 规则全文。
定层级：L0 安全 > L1 语言栈 > L2 域规范 > L3 厚清单。
改触发 ：缩 glob、降级 Always、厚文档改手动 @。
补示例：正例/反例是消歧最小补丁。
验收：无关题不误注入；相关题只剩一种说法。

结论：规则打架时，先缩范围再写示例；别再加一条 Always 和稀泥。

结论卡

症状	常见根因	先做
两种风格并存	重叠 glob / 双 Always	合并或分层
改按钮却提支付规范	glob 过大	收紧路径
安全提示被忽略	安全写在 L3	升到 L0 Always 短句
越改越长仍冲突	用散文调解	改触发 + 示例
仅偶发矛盾	手动 `@` 与 Always 叠	明确互斥场合

冲突诊断流

现象：把矛盾写成可引用的两句（最好贴 Agent 原话）。
枚举：打开 .cursor/rules，列出 alwaysApply: true 的全部，以及当前文件路径命中的 glob 规则。
消歧：按优先级表决定谁该赢；失败者改触发或改措辞。
复测：用「无关题 / 相关题」各一问验证。

不能复现的「感觉它有时听这个」优先怀疑会话历史噪声，而不是立刻再写规则。

优先级约定（写进 core）

建议在 core Always（一屏内）写明层级，而不是散落在各域文件：

层级	内容	冲突时
L0 安全	密钥、出网、不可逆操作	永远赢
L1 语言栈	包管理器、格式化、语言版本	赢过风格偏好
L2 域规范	支付/前端等 glob	仅路径内有效
L3 厚清单	发版手册等	仅手动 `@`

示例短句（可改写进 core）：

text 复制代码

优先级：安全与密钥禁令 > 包管理器与语言约定 > 路径域规范 > 手动清单。
若两条规则冲突，执行更高优先级；并在回复首句声明你遵循了哪一条。

要求 Agent「声明遵循哪一条」，会把冲突从暗处赶到明处，便于你继续改规则。

消歧五步

步骤 1：复现

固定工作区、固定文件、固定提问。记录：注入了哪些规则（若 UI 可见）、模型输出中的矛盾点、git diff 若已改码。

步骤 2：列规则

把相关规则文件名与关键句粘到一张排查卡。只看「指令句」，忽略抒情。

步骤 3：判层级

用 L0--L3 判定谁该赢。若两条同级，优先 合并成一条带条件 的规则，而不是并存。

步骤 4：改触发

Always 过长 → 砍到铁律。
glob 过大 → 收紧到真实目录。
低频流程 → 移出 Always，改手动 @。
两域重叠 → 拆目录或写「本目录以本文件为准」。

步骤 5：加示例

示例比形容词强：

text 复制代码

正例：修改 src/ui/Button.tsx 时，遵循 frontend.mdc 的命名；不要引入支付域错误码表。
反例：禁止在改 UI 文案时重写 packages/payments 下文件。

范围（glob）技巧

宁窄勿宽 ：src/payments/** 优于 src/**。
避免双命中：同一文件不要被两套对立域规则同时命中。
测试目录单独规则：防止「实现规范」与「测试规范」打架。
生成物目录：通常不写业务规范，避免噪声。

范围错了，优先级表再漂亮也救不了------因为不该出场的规则已经进场。

用「无关题 / 相关题」验收

无关题 ：在与支付无关的目录问「这个按钮文案怎么改比较清晰？」

通过标准：回答不应大段引用支付错误码或支付目录结构。

相关题 ：在支付目录问「新增错误码要怎么提交？」

通过标准：只出现支付域一种说法；并声明遵循的规则文件。

两关都过，才叫消歧完成。

案例：最小 diff vs 顺便整理

冲突：core 写「最小 diff」；某域规则写「提交前整理未使用导入」。

处理：把「整理导入」降为手动 @ 清单，或限定「仅当任务目标包含格式化时」；core 保留最小 diff。

复测：要求只改一处文案时，--stat 不应出现大范围导入重排。

案例：先测后改 vs 先实现

冲突：测试公约要求先红后绿；某业务规则示例却展示「先写实现」。

处理：统一 L1 测试公约；业务示例改成「给定失败测试再改实现」；删除对立段落。

复测：新任务卡是否默认要求贴红测输出。

团队协作注意

冲突规则进仓前要开 PR：附上复现提问与修复前后回答摘要。提示词库、ADR、Rules 是同一类「改行为」的变更，审的是行为，不是文采。

开源模板仓更要克制：不要把作者私人格式偏好写成 L0。L0 留给安全与密钥。

冲突修复验收清单

无关目录提问不再刷出域规范。
相关目录提问两套说法合并为一种。
core 仍保持一屏，未借消歧膨胀。
冲突案例写入简短 ADR 或规则注释。
团队知道优先级表在哪个文件。

踩坑

用更长散文调解：模型更晕。
再加第三条 Always：冲突平方级增长。
只改示例不改触发：旧规则仍进场。
不复测就合并：把争论留到下一次事故。

FAQ

Q：客户端没有明确「规则优先级」字段怎么办？

A：用 core 里的文字优先级 + 触发隔离（Always/glob/@）模拟；行为验收为准。

Q：能否靠更强模型消除冲突？

A：更强模型更擅长「两边都照顾」，有时更糟。消歧是工程问题。

Q：和 Token 的关系？

A：冲突往往伴随 Always 过长与 glob 过宽，两者都是前缀税来源。

今晚可执行

找一次真实「两套说法」会话。
枚举 Always + 命中 glob。
按五步改触发并加一对正反例。
跑无关题/相关题验收。

可复制提示词块

把关键约束写成可粘贴块，减少每次临场发挥：

text 复制代码

【模式】按任务选择 Ask / Agent / Manual
【目标】一句话可测结果
【允许路径】...
【禁止】密钥、出网、无关重构、改测试骗绿
【验收命令】...
【交付】diff --stat + 命令输出 + 风险一句

提示词块应进 Prompt 库或团队模板，而不是散落在聊天记录。变更时走评审，避免「口头最新版」。

验证与回滚

任何实战步骤都要回答两问：怎么知道成功？失败如何回滚？成功标准尽量是命令退出码或明确文件存在性；回滚尽量是 git checkout / git revert / 关掉某 MCP 分组。把回滚写进任务卡，Agent 较少在恐慌中扩大爆炸半径。

建议在文末「今晚可执行」里强制包含一次回滚演练：故意改错再撤回来，确认肌肉记忆。

与 Token、权限的交叉约束

实战文若只教「怎么做」，不提成本与权限，读者会在真实项目里付学费。固定提醒：

上下文只挂本任务需要的文件与提示。
写与出网工具默认关，用时再开。
新会话交接用手写摘要，不靠无限滚动历史。
密钥只走环境变量，示例仓走检查清单。

这些句子可以重复出现在多篇实战里------重复的是纪律，不是车轱辘新闻。

团队落地差异

个人仓库可以激进试错；团队仓库要默认保守。落地时把「可选项」与「必选项」分开：必选项进公约与 CI，可选项进个人笔记。新人第一周只要求必选项达标（例如去密钥、diff 不越界、测试命令可复跑），避免被工具宇宙吓退。

若团队有 AtomGit / 内网 Git，把模板仓作为唯一入口，比每人自行拼装更少分叉。

失败案例复盘模板

text 复制代码

日期：
任务目标：
使用的模式与模型（如可知）：
失败类型（卡住/乱改/漏测/权限/密钥）：
关键 diff 或日志：
根因（规则冲突/上下文脏/范围不清/...）：
规则或模板改动：
预防措施负责人与到期日：

两周一次把复盘模板过一遍，实战文章里的清单才会进化；否则清单会停在「写的时候很对，用的时候没人翻」。

度量：什么叫变好了

可选取的轻量指标（不必上复杂平台）：

越界文件次数 / 周
排障新会话次数 / 周（止损是否变快）
红测先行任务占比
示例仓密钥扫描告警数
站会是否人人能出示 --stat 摘要

指标用于改进模板，而不是考核惩罚。惩罚会逼人隐藏近失，这与安全目标相反。

排查卡模板（可打印）

text 复制代码

日期 / 仓库 / 分支：
固定提问原文：
Always 规则文件列表：
命中的 glob 规则文件列表：
矛盾句 A：
矛盾句 B：
判定赢家层级（L0--L3）：
触发改动（缩 glob / 降 @ / 合并）：
新增正例：
新增反例：
无关题结果：
相关题结果：
是否更新团队 ADR：

把排查卡与优先级表放在同一目录，下一次冲突就不必从头发明流程。

与 Token 观测的联动

冲突常伴随 Always 过长与 glob 过宽。消歧完成后，用一次无关题观察前缀是否仍被域规范占满；若仍占满，说明触发未改干净。把「冲突修复」记进个人 Token 仪表盘的一次事件，便于证明工程化收益。

开源模板的额外约束

对外模板仓：L0 只放安全与密钥；不要把作者私人格式偏好写成全局 Always。冲突示例可以用「虚构支付域 vs 前端域」演示，避免泄露真实业务规则。

消歧完成后的冻结期

冲突修复合并后，建议三天内不新增 Always。用无关题/相关题各回归一次，确认无反弹。若反弹，优先怀疑又有人用散文和稀泥，而不是模型回归。把冻结期写进团队公约，能减少「修好又搅浑」。

执行证据清单

检查项：确认本任务的允许路径、禁止项、验收命令与回滚方式已写进任务卡，并在完成后保存命令输出作为证据。
检查项：确认本任务的允许路径、禁止项、验收命令与回滚方式已写进任务卡，并在完成后保存命令输出作为证据。
检查项：确认本任务的允许路径、禁止项、验收命令与回滚方式已写进任务卡，并在完成后保存命令输出作为证据。

边界

不保证某一 Cursor 小版本的 UI 文案。
不替代人工审 diff。
draft 未发布。

规则的胜利条件不是「写全」，而是「在该出现的场合只出现一种正确约束」。