你的 AI 品控规则越来越多了------但它们已经在打架了，你没看见
我维护 sharp-skills 半年多，规则从 10 条膨胀到 100 条的时候，出了一个让我意外的事：不是规则的覆盖度不够，是规则之间开始互相打架。
最典型的场景是：sharp-tech-writing 有一条"MUST 给每个 API 配上可运行的代码示例"，sharp-copywriting 有一条"MUST 避免代码块超过 30 行"。当一个 API 本身就需要 50 行代码才能说清楚时，这两条规则就正面冲突了。AI 出来的东西要么违反了"必须有完整代码示例"，要么违反了"代码块不能太长"。
这种冲突不是语法错误，是品控规则自己内部的矛盾。如果没有一个冲突仲裁机制，规则越多，AI 越无所适从，最终的输出质量反而会下降。
这篇聊的不是怎么写规则，是规则多了之后怎么让它们不打架。
规则冲突的三种类型
我在维护过程中遇到的规则冲突，大致可以归到三类：
第一类：范围冲突------"必须 A"和"禁止 A"撞车
最直白的冲突。比如 sharp-tech-writing 早期有一条"术语首次出现时必须给出英文原文"，sharp-copywriting 有一条"营销文案必须避免中英混用显得土"。两个规则都对，但合在一起，技术文档里的英文术语标识就做不出来了。
这类冲突的根源是规则没标注适用场景。一条规则如果没写"在 X 场景下生效"，它就会默认在所有场景下生效，跟其他规则碰撞只是时间问题。
第二类：优先级冲突------两条规则都该执行，资源不够
比如 sharp-tech-writing 的"代码示例必须可运行"和"代码示例必须覆盖所有错误码"。两个错误码的 API，第一个规则想要"完整可运行"，第二个规则想要"穷尽覆盖"。时间有限/上下文有限的情况下，AI 必须二选一。
冲突的根源是规则没声明优先级。当品控规则集大到一定程度，你没办法靠"按文件顺序"或者"按时间顺序"来决定谁先谁后------你需要一个明确的优先级机制。
第三类：语义冲突------两条规则字面对立但都对
这是最隐蔽的一类。sharp-api-design 有一条"错误码必须反映真实错误类型"（比如 5xx 是服务器错，4xx 是客户端错），sharp-presentation 有一条"演示文稿必须用通俗类比解释错误码"（比如"500 说明服务器开小差了"）。两个规则的目的是一致的------让用户理解错误码。但 sharp-presentation 的"通俗类比"在严格意义上违反了"错误码必须反映真实错误类型"的精神，因为"开小差"这种类比不是真实的错误类型。
这种冲突在规则文件里看不出来，但 AI 一执行就发现两边都在跟自己说要做相反的事。
仲裁器：让规则有自己的"宪法"
解决冲突的核心思路，是引入一个规则优先级仲裁器。它不是规则本身，是规则的"宪法"。
仲裁器做的事，分三步：
第一步：场景归一化。 每条规则必须标注它适用的场景------后端 API 文档、前端组件文档、营销文案、求职简历、PPT 演示。规则不再"默认全场景生效"，在某个具体场景下，AI 只需要考虑该场景的规则集。
这一步把第一类冲突（范围冲突）大幅消解了。两个规则撞车，往往是因为它们本来就属于不同场景。
第二步：优先级分层。 在同一个场景下，规则按优先级排：
- L1 安全规则： 涉及合规、安全、隐私的规则，永远最高优先级。比如"代码示例不能出现真实密钥"。这类规则是 MUST-NEVER。
- L2 准确性规则： 涉及事实正确性的规则。比如"技术文档引用的 API 名称必须和代码里一致"。这是 MUST。
- L3 完整性规则： 涉及内容完整度的规则。比如"代码示例必须包括错误处理"。这是 MUST。
- L4 风格规则： 涉及表达风格的规则。比如"代码块不超过 30 行"。这是 SHOULD，可被上下文覆盖。
同一层级的规则发生冲突，按"明确性优先"------更具体的规则胜过更通用的规则。比如"用户认证模块的所有 API 必须用 OAuth 2.0"胜过"API 鉴权方式必须符合行业标准"。
第三步：冲突可观测。 当规则冲突发生时，仲裁器必须把冲突暴露出来，而不是默默选一个。AI 应该在输出里标注"这条满足规则 A，违反了规则 B（优先级低于 A），原因如下"。人能看到决策过程，事后可以调整规则权重。
一个实战案例
最近遇到一个具体案例：用户在用 sharp-api-design 生成一份库存系统的 API 文档，其中一个 API 是"批量更新库存"，涉及到批量写入。
当时触发的规则有：
- L1：所有 API 文档必须包含鉴权说明（NR）
- L2：所有 API 文档必须包含请求/响应示例（NR）
- L3：所有 API 文档必须包含错误码说明（NR）
- L4：批量 API 文档必须包含"批量大小限制"说明（NR）
- L4：单个示例代码块不超过 30 行（NR）
如果批量更新涉及 5 个字段、3 种错误码、2 个示例，代码块加起来会超过 30 行。L4 内部冲突------一条要求"必须包含完整信息"，另一条要求"代码块不能太长"。
仲裁器决策：
- L4 内部冲突，触发"明确性优先"。"必须包含完整信息"是 API 文档的硬要求，比"代码块不超过 30 行"更具体。
- 触发 L4 的兜底策略。"代码块不超过 30 行"这一条降级为 SHOULD，转而通过"将代码块拆分为多个"` 标签来同时满足两条规则。
- AI 输出里标注："代码块按
Step 1: 鉴权、Step 2: 批量更新、Step 3: 错误码拆成 3 段，每段不超过 30 行。"
这个决策过程是透明的、可追溯的。如果用户对拆分方式不满意，可以直接说"我想要完整代码块"，仲裁器就会把"代码块不超过 30 行"暂时降级，等当前任务完成后再恢复。
规则的可执行性 vs 规则的相互独立性
之前写过的"规则可执行性"是规则本身的质量维度------能不能用代码检查、能不能跑出确定结果。
但今天讲的"规则优先级仲裁"是规则之间的关系维度------它们互相独立还是互相依赖、互相冲突还是互相协作。
很多人维护规则集的误区是：以为只要规则写得够清楚就够了。但规则集的复杂度不是单条规则的复杂度叠加，是规则之间的相互关系。20 条相互独立的规则，比 50 条相互冲突的规则好用得多。
sharp-skills 现在的做法是：每条规则除了内容字段外，还强制带三个元数据------scene（适用场景）、priority（优先级 L1-L4）、arbiter_hint（出现冲突时的默认处理建议）。规则文件本身用 YAML 而非 Markdown，方便机器解析，也方便在 PR 评审时检查规则元数据是否完整。
仲裁器不是规则的下属，是规则的合作者
最后想说一个认知：仲裁器不是规则的"管理者"，它是规则的"翻译官"。
规则本身是静态的文本，AI 的具体上下文是动态的。同一条规则在不同上下文里的"权重"是不一样的。仲裁器的价值，是把"规则"和"当前上下文"对齐，让 AI 知道这条规则在当下"到底有多重"。
sharp-skills 的仲裁器目前是规则文件 + 一个 Python 脚本的组合，逻辑不复杂。但它让规则库从 50 条扩展到 100 条的过程中，没有出现"规则多了反而不好用"的反效果。这对我来说就是最大的胜利。
我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，23 个设计模式用漫画 + 答题的方式讲，目前正在开发中。如果你觉得这类内容有意思，搜一下「爪爪代码冒险记」，或者等我后面的文章。