尧图网页设计 
多本书规则怎么搭才不打架agent-rules-books 91对规则兼容性矩阵详解【免费下载链接】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-booksagent-rules-books仓库把 Clean Code、Refactoring、DDD、Clean Architecture 等 14 本经典编程书提炼成可直接喂给 Codex、Cursor、Claude Code 的 AGENTS.md 规则。但当你想同时加载多本书的规则时它们会互相打架吗docs/COMPATIBILITY.md 给出了一份14×14 的 91 对规则兼容性矩阵逐一判定哪些组合可以同载、哪些会冲突、哪些重复浪费上下文。为什么多书同载会打架每本书都有自己的决策压力方向有的推深模块有的推小函数有的推丰富领域模型有的推简单的企业模式。如果把两本方向相反的书同时作为平级活跃规则加载AI Agent 可能会 在拆小函数和保持模块深度之间反复摇摆️ 一边加 DDD 战术模式一边又保留更简单的企业级模式 浪费宝贵的上下文预算在重复指导上所以矩阵回答的核心问题只有一个这两本书要不要一起作为活跃规则加载图例看懂三种判定矩阵使用三种判定符号定义见 docs/COMPATIBILITY.md符号含义操作建议✅ Complementary互补可作为平级活跃规则组合加载❌ Conflicting冲突不要一起加载为平级规则 Overlap重叠二选一或让一方当裁判每对书还有三个定性评分冲突度Conflict、重叠度Overlap、互补度Complementarity且每个判定都引用了双方mini规则文件的具体行号作为证据可在 docs/compatibility/ 目录逐对查阅。矩阵总览78对互补、2对冲突、11对重叠14 本书两两组合共 91 对14×13÷2最终统计为判定数量说明✅ 互补78占绝大多数可放心组合❌ 冲突2必须回避的雷区 重叠11选一本即可详解2对冲突组合为什么是❌DDD vs 企业应用架构模式PoEAA冲突度 62%、重叠度 68%。详见 docs/compatibility/domain-driven-design/patterns-of-enterprise-application-architecture.md。DDD推动更深的领域建模聚合、通用语言、限界上下文、核心域PoEAA允许更简单的模式事务脚本、表模块、Active Record平级加载时Agent 可能既加 DDD 战术模式又保留简单企业模式在两种设计之间震荡。正确做法DDD 为主PoEAA 只在具体基础设施决策上受限使用。实现 DDDIDDDvs PoEAA冲突度 66%、重叠度 72%是全矩阵最强的实现层冲突。详见 docs/compatibility/implementing-domain-driven-design/patterns-of-enterprise-application-architecture.md。IDDD 是committed的 DDD 实现栈小聚合根、一个聚合一个事务、领域事件、CQRS 门而 PoEAA 可能主动选择绕开这一切的简单模式。两者平级加载会让通用 CRUD 仓库、事务脚本与聚合根仓库、领域事件直接对撞。详解11对重叠组合三族替身 判定意味着干的是同一份工作加载两本只是重复花上下文。典型的三族1️⃣ DDD 三兄弟互斥三选一DDD vs DDD Distilled重叠度 88%DDD vs IDDDDDD Distilled vs IDDD怎么选日常任务选 Distilled最小有效 DDD反仪式感需要完整 Evans 词汇和战略建模时选 DDD已决定用 DDD 落地实现时选 IDDD。2️⃣ 重构双雄Refactoring vs Refactoring.Guru详见 docs/compatibility/refactoring/refactoring-guru.md。一本偏安全小步重构 代码坏味道一本偏坏味道目录 重构手法目录触发同一类任务时选一本即可。3️⃣ 代码质量三件套APoSD vs Clean Code核心张力是深模块压力 vs 小函数压力同时加载会让 Agent 拆到 Clean Code 满意时APoSD 却说拆分增加了跳转Clean Code vs Code CompleteClean Code vs 程序员修炼之道、Code Complete vs 程序员修炼之道注意一个反直觉点APoSD 与 Clean Code 是重叠但 APoSD 与 Code Complete 是互补✅——矩阵是逐对基于mini规则原文判定的而不是凭书名印象。哪些看似危险的组合其实是✅矩阵中有几对公认有张力的组合经检查后判定为互补✅前提是各自的mini规则里已内置门控APoSD vs Refactoring深模块设计 vs 小步保行为重构方向不同阶段可同载Clean Architecture vs DDD架构边界依赖方向 vs 模型优先的领域边界作用于不同决策层Release It! vs DDIA服务韧性 vs 数据系统正确性一个管失败处理、一个管一致性语义这类高风险对在判定前必须结合外部资料研究详见 _rule-workbench/CHECK_COMPATIBILITY.md 中的高-risk 清单避免凭感觉打勾。实操建议3步搭出不打架的规则组合第1步只留一个主规则按 docs/USAGE.md 的原则用一个mini规则集作为始终在线的项目基线。多数任务场景的推荐起点是clean-code或the-pragmatic-programmer它们与几乎所有书都是 ✅。第2步其他书做成技能按需触发把任务型规则集做成 skill只在任务匹配时加载例如refactoring.mini.md→ 重构轮次working-effectively-with-legacy-code.mini.md→ 遗留代码改动release-it.mini.md→ 生产可靠性修复domain-driven-design.mini.md→ 建模密集型工作第3步查矩阵再加载多书同载前先在 docs/COMPATIBILITY.md 的矩阵中交叉核对✅ 放心组合 二选一❌尤其是 DDD/IDDD × PoEAA 这 2 对绝不平级加载。矩阵背后如何保证判定可信这份矩阵不是凭印象对比。_rule-workbench/CHECK_COMPATIBILITY.md 定义了严格的质量门槛每对比较必须引用双方mini文件的具体行号区间并解释该规则为何对本对重要每对给出 Conflict / Overlap / Complementarity 三个评分且必须被证据支撑高风险对必须标注mini-plus-external研究基础防止被社区刻板印象误导91 个规范比较文件一一对应 91 个矩阵单元格矩阵符号必须与文件判定一致你可以在 docs/compatibility/ 下按书名目录/书名.md的路径随时抽查任意一对的完整推理过程。常见问题Q为什么没有✅/❌混合判定因为矩阵回答的是单一问题要不要一起作为活跃规则加载只要一方需要当裁判就应判 或 ❌。Q冲突对的两本书还能一起用吗可以但要降级以一本为主另一本只作为背景参考或限定在单个具体决策如 DDD 之下只借 PoEAA 的 Unit of Work 思路。Q矩阵会更新吗会。每本书都有full/mini/nano三个版本版本发布数据见 README.md 的 Release Matrix规则变化后矩阵单元格需同步刷新流程见 docs/ADDING_THE_BOOK.md。总结场景推荐做法日常编码基线1 个mini如 Clean Code始终在线任务型加强查矩阵后按需加载 skillDDD 选型三选一勿叠加上 PoEAA先避开 DDD/IDDD 平级加载拿不准时打开对应docs/compatibility/a/b.md看证据记住一句话规则不在多在方向不打架。91 对矩阵就是帮你在加载前 10 秒内做出这个判断的地图。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 多本书规则怎么搭才不打架？agent-rules-books 91对规则兼容性矩阵详解
多本书规则怎么搭才不打架agent-rules-books 91对规则兼容性矩阵详解【免费下载链接】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-booksagent-rules-books仓库把 Clean Code、Refactoring、DDD、Clean Architecture 等 14 本经典编程书提炼成可直接喂给 Codex、Cursor、Claude Code 的 AGENTS.md 规则。但当你想同时加载多本书的规则时它们会互相打架吗docs/COMPATIBILITY.md 给出了一份14×14 的 91 对规则兼容性矩阵逐一判定哪些组合可以同载、哪些会冲突、哪些重复浪费上下文。为什么多书同载会打架每本书都有自己的决策压力方向有的推深模块有的推小函数有的推丰富领域模型有的推简单的企业模式。如果把两本方向相反的书同时作为平级活跃规则加载AI Agent 可能会 在拆小函数和保持模块深度之间反复摇摆️ 一边加 DDD 战术模式一边又保留更简单的企业级模式 浪费宝贵的上下文预算在重复指导上所以矩阵回答的核心问题只有一个这两本书要不要一起作为活跃规则加载图例看懂三种判定矩阵使用三种判定符号定义见 docs/COMPATIBILITY.md符号含义操作建议✅ Complementary互补可作为平级活跃规则组合加载❌ Conflicting冲突不要一起加载为平级规则 Overlap重叠二选一或让一方当裁判每对书还有三个定性评分冲突度Conflict、重叠度Overlap、互补度Complementarity且每个判定都引用了双方mini规则文件的具体行号作为证据可在 docs/compatibility/ 目录逐对查阅。矩阵总览78对互补、2对冲突、11对重叠14 本书两两组合共 91 对14×13÷2最终统计为判定数量说明✅ 互补78占绝大多数可放心组合❌ 冲突2必须回避的雷区 重叠11选一本即可详解2对冲突组合为什么是❌DDD vs 企业应用架构模式PoEAA冲突度 62%、重叠度 68%。详见 docs/compatibility/domain-driven-design/patterns-of-enterprise-application-architecture.md。DDD推动更深的领域建模聚合、通用语言、限界上下文、核心域PoEAA允许更简单的模式事务脚本、表模块、Active Record平级加载时Agent 可能既加 DDD 战术模式又保留简单企业模式在两种设计之间震荡。正确做法DDD 为主PoEAA 只在具体基础设施决策上受限使用。实现 DDDIDDDvs PoEAA冲突度 66%、重叠度 72%是全矩阵最强的实现层冲突。详见 docs/compatibility/implementing-domain-driven-design/patterns-of-enterprise-application-architecture.md。IDDD 是committed的 DDD 实现栈小聚合根、一个聚合一个事务、领域事件、CQRS 门而 PoEAA 可能主动选择绕开这一切的简单模式。两者平级加载会让通用 CRUD 仓库、事务脚本与聚合根仓库、领域事件直接对撞。详解11对重叠组合三族替身 判定意味着干的是同一份工作加载两本只是重复花上下文。典型的三族1️⃣ DDD 三兄弟互斥三选一DDD vs DDD Distilled重叠度 88%DDD vs IDDDDDD Distilled vs IDDD怎么选日常任务选 Distilled最小有效 DDD反仪式感需要完整 Evans 词汇和战略建模时选 DDD已决定用 DDD 落地实现时选 IDDD。2️⃣ 重构双雄Refactoring vs Refactoring.Guru详见 docs/compatibility/refactoring/refactoring-guru.md。一本偏安全小步重构 代码坏味道一本偏坏味道目录 重构手法目录触发同一类任务时选一本即可。3️⃣ 代码质量三件套APoSD vs Clean Code核心张力是深模块压力 vs 小函数压力同时加载会让 Agent 拆到 Clean Code 满意时APoSD 却说拆分增加了跳转Clean Code vs Code CompleteClean Code vs 程序员修炼之道、Code Complete vs 程序员修炼之道注意一个反直觉点APoSD 与 Clean Code 是重叠但 APoSD 与 Code Complete 是互补✅——矩阵是逐对基于mini规则原文判定的而不是凭书名印象。哪些看似危险的组合其实是✅矩阵中有几对公认有张力的组合经检查后判定为互补✅前提是各自的mini规则里已内置门控APoSD vs Refactoring深模块设计 vs 小步保行为重构方向不同阶段可同载Clean Architecture vs DDD架构边界依赖方向 vs 模型优先的领域边界作用于不同决策层Release It! vs DDIA服务韧性 vs 数据系统正确性一个管失败处理、一个管一致性语义这类高风险对在判定前必须结合外部资料研究详见 _rule-workbench/CHECK_COMPATIBILITY.md 中的高-risk 清单避免凭感觉打勾。实操建议3步搭出不打架的规则组合第1步只留一个主规则按 docs/USAGE.md 的原则用一个mini规则集作为始终在线的项目基线。多数任务场景的推荐起点是clean-code或the-pragmatic-programmer它们与几乎所有书都是 ✅。第2步其他书做成技能按需触发把任务型规则集做成 skill只在任务匹配时加载例如refactoring.mini.md→ 重构轮次working-effectively-with-legacy-code.mini.md→ 遗留代码改动release-it.mini.md→ 生产可靠性修复domain-driven-design.mini.md→ 建模密集型工作第3步查矩阵再加载多书同载前先在 docs/COMPATIBILITY.md 的矩阵中交叉核对✅ 放心组合 二选一❌尤其是 DDD/IDDD × PoEAA 这 2 对绝不平级加载。矩阵背后如何保证判定可信这份矩阵不是凭印象对比。_rule-workbench/CHECK_COMPATIBILITY.md 定义了严格的质量门槛每对比较必须引用双方mini文件的具体行号区间并解释该规则为何对本对重要每对给出 Conflict / Overlap / Complementarity 三个评分且必须被证据支撑高风险对必须标注mini-plus-external研究基础防止被社区刻板印象误导91 个规范比较文件一一对应 91 个矩阵单元格矩阵符号必须与文件判定一致你可以在 docs/compatibility/ 下按书名目录/书名.md的路径随时抽查任意一对的完整推理过程。常见问题Q为什么没有✅/❌混合判定因为矩阵回答的是单一问题要不要一起作为活跃规则加载只要一方需要当裁判就应判 或 ❌。Q冲突对的两本书还能一起用吗可以但要降级以一本为主另一本只作为背景参考或限定在单个具体决策如 DDD 之下只借 PoEAA 的 Unit of Work 思路。Q矩阵会更新吗会。每本书都有full/mini/nano三个版本版本发布数据见 README.md 的 Release Matrix规则变化后矩阵单元格需同步刷新流程见 docs/ADDING_THE_BOOK.md。总结场景推荐做法日常编码基线1 个mini如 Clean Code始终在线任务型加强查矩阵后按需加载 skillDDD 选型三选一勿叠加上 PoEAA先避开 DDD/IDDD 平级加载拿不准时打开对应docs/compatibility/a/b.md看证据记住一句话规则不在多在方向不打架。91 对矩阵就是帮你在加载前 10 秒内做出这个判断的地图。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考