夜雨聆风一位开发者，14 部名著，一个仓库
事情的起点很简单。
开发者 Maciej Ciemborowicz 在 GitHub 上开了一个仓库：`agent-rules-books`。
▲ Geek Lite (@QingQ77) 的 X 推文，转发了这个项目
他做的事情很明确：把经典编程书里的工程原则，转写成 AI coding agent 能直接读取的 Markdown 规则文件。
"I built a small repo of ready-to-use project rules for AI coding agents, based on classic software engineering books."
「我做了一个现成的项目规则库，给 AI 编程 agent 用，基于经典软件工程书。」
这里列出的 13 本书，每一本在软件工程领域都是教科书级别：
- A Philosophy of Software Design
— John Ousterhout - Clean Architecture
/Clean Code— Robert C. Martin - Code Complete
— Steve McConnell - Designing Data-Intensive Applications (DDIA)
— Martin Kleppmann - Domain-Driven Design
— Eric Evans - DDD Distilled
/Implementing DDD— Vaughn Vernon - Patterns of Enterprise Application Architecture
— Martin Fowler - Refactoring
— Martin Fowler - Release It!
— Michael T. Nygard - The Pragmatic Programmer
— Andrew Hunt & David Thomas - Working Effectively with Legacy Code
— Michael Feathers
再加上后来新增的Refactoring.Guru（一个系统性整理重构模式的公开资料站），总共 14 套规则。
▲ ciembor/agent-rules-books GitHub 仓库，14 个 rule set，1500+ Star
注意一个细节：X 上流传的链接指向的是 `mattpocock/agent-rules-books`，但这其实是一个 fork。原始仓库在 `ciembor` 名下，MIT 开源协议，2026 年 4 月 16 日上线，采集时已有 1513 Star、220 Fork。
规则怎么用？三档尺寸，按需加载
这套规则的设计思路很务实：每本书的规则都有三种尺寸——
- full
：完整参考版，适合深度审计和代码评审，14 套合计约 277KB - mini
：推荐的日常工作版，约 87KB - nano
：极度压缩版，上下文紧张时的 fallback，约 32KB
▲ 项目官网：AI agent rules / skills distilled from software engineering books
它支持的工具覆盖了当前主流的三大 AI 编程平台：
- Codex
→ 放进 `AGENTS.md` - Cursor
→ 放进 `.cursor/rules/.mdc` - Claude Code
→ 放进 `.claude/rules/.md`、skills 或 memory
作者在 HN 上明确说过这个项目的定位：
"The idea is not to summarize or replace the books, but to turn their engineering principles into practical instructions that can guide agent behavior during implementation, refactoring, review, and testing."
「目的不在于总结或替代原书，而是把工程原则转成实用指令，在实现、重构、评审、测试环节指导 agent 的行为。」
换句话说，这些规则文件的角色更像给 AI 的操作手册，告诉它在写代码时该注意什么、什么时候该深入模块而非增加层、什么时候该用 bounded context、什么时候该保持行为不变只改结构。
▲ Hacker News 上 ciembor 的原帖，列出 13 本书和支持的工具
用法有讲究：别把 14 套规则一股脑塞进去
项目方在 USAGE.md 里反复强调了一件事：不要把所有规则一次性全塞进全局上下文。
为什么？因为 full 版本合计 277KB，直接堆进去会浪费大量 token，挤压掉需求描述、代码片段、错误日志这些真正关键的上下文空间。
▲ USAGE.md：推荐按任务加载，mini 做日常层，nano 做紧上下文提醒
正确的用法是分层加载：
1.日常任务：用 `mini` 版本做 task-scoped skill 或主规则层 2.上下文紧张：用 `nano` 版本做简短提醒 3.深度审计：用 `full` 版本做参考和评审基准 4.按目录加载：不同子模块可以挂不同书的规则
这个设计对应了 AGENTS.md 格式的基本理念——把 agent 需要的上下文从 README 里分离出来，放在一个稳定的、跨工具通用的位置。agents.md 格式站点称，这种格式已经被60,000 多个开源项目采用。
▲ agents.md 站点：Think of AGENTS.md as a README for agents
社区的反应：有人追捧，有人质疑
Reddit 上，ciembor 以"I rewrote 13 software engineering books into AGENTS.md rules"为标题发帖，在 r/AI_Agents 社区引起了不少讨论。
▲ Reddit r/AI_Agents 讨论帖
但评论区的风向并不一边倒。
支持者认为，这填补了一个真实的空白——开发者确实在寻找更结构化的方式来约束 AI agent 的代码行为。有 GitHub issue 里的开发者提到，自己就曾因为 Claude 忽略 CLAUDE.md 里的项目规则，而不得不设计更细粒度的 agent 配置。
质疑者的火力集中在几个点上：
第一，没有效果数据。
项目方自己在 CRITICISM.md 里承认了这个问题：
"Without benchmarks, before/after comparisons, defect counts, review effort, or task-completion data, it is hard to know whether the rules actually improve code quality or just feel useful."
「没有 benchmark、前后对比、缺陷计数、评审投入或任务完成数据，很难判断这些规则是真的提升了代码质量，还是只是感觉有用。」
第二，规则会吃掉上下文。
"Loading too many of them at once can increase token usage, crowd out task-specific context, and make the agent less focused."
「一次加载太多规则会增加 token 消耗，挤压任务相关上下文，让 agent 变得不够专注。」
第三，不同书的规则可能互相打架。
Clean Architecture 强调分层隔离，DDD 强调领域建模，DDIA 关注分布式系统——这些书解决的问题层级不同。如果 agent 同时读取太多书的规则，可能在一个简单 CRUD 接口上也要搞 bounded context 和六边形架构。
第四，通用规则可能不如项目专属规则。
社区的一个核心观点是：真正高价值的 agent rules，往往来自项目自身的失败记录、测试命令、部署事故和代码风格约定——通用工程原则只是补充。这个 repo 更像一个可选的工程原则素材库，不能替代每个项目自己的 AGENTS.md。
▲ CRITICISM.md：项目方把 Reddit 的批评整理成了官方文档
这件事更深层的问题
这个项目有意思的地方，在于它反映了 AI 编程工具演化中的一个趋势变化。
过去，项目级的 agent 规则大多是操作层面的具体约定——跑什么测试命令、用什么代码风格、CI 怎么配、部署前检查什么。
现在有人开始尝试往里面装更抽象的工程判断——遇到复杂度时优先深模块、重构时保持行为不变、DDD 只在业务复杂度值得时才用 bounded context。
这个方向有价值，但也有风险。越抽象的规则越难验证效果，越容易让模型产生"伪服从"——表面上遵循了规则，实际上只是在输出里塞进了规则里提到的关键词。
作者显然也意识到了这一点。项目文档反复强调 `mini`、`nano` 和 task-scoped loading 的理念，以及一句潜台词：规则是参考，落地要靠人。
回到这件事本身
`agent-rules-books` 提供了一个有意思的实验：把经典软件工程书的决策框架，压缩成 AI coding agent 每次改代码前能读取的指令集。
它 MIT 开源，14 套规则可按需取用，支持主流 AI 编程工具。
但它也诚实地标注了自己的边界——没有 benchmark 证明效果，不能替代原书，也不能替代你项目自己的规则。
如果你正在用 Codex、Cursor 或 Claude Code 写代码，可以把它当成一个规则素材库来参考。把适合你项目的部分挑出来，mini 或 nano 版本就够。
至于那些经典著作里真正值钱的东西——工程直觉、架构品味、对复杂度的嗅觉——这些恐怕还是得人来读。
— END —
