如何判断两本书的规则能否同时使用？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 规则发布，并提供三个版本：

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

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

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

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

⚙️ CHECK_COMPATIBILITY 工作流实战

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

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

防作弊的硬性规则

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

• 每条结论必须引用具体行号区间，禁止"整文件引用"（比如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 只约束特定基础设施决策时，才可以一起出现。

✅ 实战速查：判断两本书能否同时加载

不必自己跑完整流程，也可以照这个顺序快速自查：

• 是否触发同一类任务？两本书的"when to use"是否指向同一场景（如都管日常代码质量）
• 首选动作是否兼容？遇到同一问题，它们各自推荐的第一步会不会互相否定
• 复杂度方向是否对冲？一本书的默认抽象压力，是否正好增加另一本书想消除的复杂度
• 谁当裁判？如果必须指定一本书"说了算"，那这对就是 🔁 而不是 ✅
• 拿不准就只加载一个主规则集，把另一本降级为背景参考资料——docs/USAGE.md 的建议正是"从一个主规则集开始，用最小的机制改变代理决策"

📁 相关文件资源

• 工作流总纲：_rule-workbench/CHECK_COMPATIBILITY.md
• 兼容性矩阵与统计：docs/COMPATIBILITY.md
• 91 个书对详细对比：docs/compatibility/
• 规则加载方式（技能 / 常驻 / 按路径限定）：docs/USAGE.md
• 新书的规则提炼流程：_rule-workbench/PROCESS.md
• 版本发布说明：docs/ADDING_THE_BOOK.md

一句话总结：把"两本书能不能一起用"从感觉问题变成证据问题——读mini、引行号、打三分、给一判，你的 AI 代理就不会再被互相矛盾的规则撕扯了。

【免费下载链接】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