如何判断两本书的规则能否同时使用？agent-rules-books的CHECK

如何判断两本书的规则能否同时使用？agent-rules-books的CHECK_COMPATIBILITY工作流实战

【免费下载链接】agent-rules-booksAGENTS.md rules / skills for AI coding agents: Codex, Cursor & Claude Code. Inspired by Clean Code, Refactoring, DDD, Clean Architecture and DDIA programming books.项目地址: https://gitcode.com/gh_mirrors/ag/agent-rules-books

agent-rules-books 把 14 本软件工程经典书提炼成可直接加载给 AI 编程代理（Codex、Cursor、Claude Code）的规则集。当你想同时启用两本书的规则时，最核心的问题就是：它们会不会打架？本文带你实战这个项目内置的 CHECK_COMPATIBILITY 工作流，学会用三档判定（✅ 互补 / ❌ 冲突 / 🔁 重叠）科学判断两本书的规则能否同时使用。

📚 先搞懂：这里的"书规则"长什么样

每个书目都以纯 Markdown 规则发布，并提供三个版本：

版本	定位	适用场景
`mini`	推荐主力，决策压力完整	大部分真实任务、技能（skill）主体
`nano`	极小紧凑版	上下文预算非常紧张的常驻规则
`full`	完整权威源	审计、深度会话、参考资料

例如 Clean Code 的 mini 规则只有 47 行，却完整保留了"函数要小、命令与查询分离、按复杂度而非大小拆分"等会真正改变代理决策的规则。具体如何加载到编辑器，可参考 docs/USAGE.md。

🔍 三档判定：兼容性矩阵怎么看

所有书两两对比的结果汇总在 docs/COMPATIBILITY.md，矩阵单元格只有三种可能（外加对角线N/A）：

判定	含义	你应该怎么做
✅ Complementary 互补	两本书在不同层面施压，可平等加载	放心一起用
❌ Conflicting 冲突	同时加载会推动代理做出相反决策	不要同时作为主动规则加载
🔁 Overlap 重叠	干的是同一份工作，或一个是另一个的替代版	二选一，避免浪费上下文

当前 91 个书对的对战结果：✅ 78 对、❌ 2 对、🔁 11 对。也就是说，多数书是安全的，但 DDD 系和"企业应用架构"一碰就有问题——这正是下面案例要讲的。

⚙️ CHECK_COMPATIBILITY 工作流实战

整套判断逻辑写在 _rule-workbench/CHECK_COMPATIBILITY.md 里，是给 AI 代理执行的严格流程。核心步骤如下：

建工作队列：在_rule-workbench/compatibility-pair-workqueue.md生成 91 个未排序书对的复选框（14 本书 = 91 对）
一次只分析一对：从第一个未勾选项开始，禁止并行、禁止批量糊弄
只信mini证据：必须以两本书的mini文件为主证据，不允许凭书名、名气或社区印象打分
提取"主动压力"：每本书先回答——它最强的默认值、触发条件、停止条件、禁止动作是什么
三维打分：给出Conflict、Overlap、Complementarity三个百分比（0-20 弱 → 81-100 主导）
只给一个判定：不允许 ✅/❌ 这种混合结论
产出对比文件：写到docs/compatibility/<书A>/<书B>.md（按字母序，每对只建一个文件）
回写矩阵并勾选项：矩阵单元格与详细文件判定必须一致

防作弊的硬性规则

这个工作流最有价值的是它的一堆"反偷懒"约束：

每条结论必须引用具体行号区间，禁止"整文件引用"（比如lines 3-49一律不通过）
同族书对（如 DDD 三姐妹、Refactoring 与 Refactoring.Guru）默认判 🔁，除非能证明两者压力不同
高风险书对要判 ✅，必须满足"举证责任"：命名出公开张力、本地mini有门禁、加载后压力不重复
套话检测：如果某段分析能原样贴进其他对比文件，直接打回重写

📖 两个真实书对案例

案例一：Clean Code vs《A Philosophy of Software Design》→ 🔁 重叠

这是最典型的一对"同族张力"书。详见 docs/compatibility/a-philosophy-of-software-design/clean-code.md：

Verdict: 🔁 Overlap ｜ Conflict: 55% ｜ Overlap: 72%

矛盾点很具体：APoSD 规则要求"按总复杂度而非大小拆分、拒绝浅层 helper 模块"，而 Clean Code 规则要求"函数要小、混合阶段的函数要拆分"。两本都加载，代理就会一边拆到 Clean Code 满意，一边被 APoSD 骂拆出来的接口太浅——行为不稳定。所以结论是二选一：模块/API 设计任务选 APoSD，局部可读性与日常代码卫生选 Clean Code。

案例二：DDD vs《Patterns of Enterprise Application Architecture》→ ❌ 冲突

矩阵里仅有的 ❌ 之一，详见 docs/compatibility/domain-driven-design/patterns-of-enterprise-application-architecture.md：

Verdict: ❌ Conflicting ｜ Conflict: 62% ｜ Overlap: 68%

DDD 的默认压力是"把业务决策推进领域对象，用聚合、仓储、领域语言测试"；而 PoEAA 明确允许"简单域直接用 Transaction Script、Table Module、Active Record"。两本同时作为平等主动规则加载，代理会在深度领域建模和更简单的企业模式之间反复横跳。判定文件给出的加载建议：DDD 为主、PoEAA 只约束特定基础设施决策时，才可以一起出现。