夜雨聆风7 条规则，3 条五星。最后附一版我会实际放进项目里的修改版。
最近看到一张传播很广的截图。
Marcos Hernanz 在 X 上晒出了自己的完整 AGENTS.md，原帖只有一句话：
After doing ~60B tokens, this is my full AGENTS.md.
也就是：大约用了 60B Token 之后，这就是他的完整 AGENTS.md。
国内转发时又多了一层说法：这份文件能在项目开发中省下 80% Token。截图里没有对应的测试方法和数据，所以这个 80% 我不当成事实。
但这 7 条规则确实值得看。下面按 5 星制逐条打分。
1. 不保留向后兼容
英文原文
Do not preserve backward compatibility. Remove obsolete paths instead of adding compatibility layers, fallbacks, or migrations.
中文：不要保留向后兼容。删除过时路径，而不是继续增加兼容层、fallback 或 migration。
★★★☆☆
这条很有针对性。Coding Agent 经常不敢删旧实现，新方案写一套，旧路径继续留着，再补 compatibility layer、fallback、migration。原本很小的一次改动，很快就长出两三套路径。
对个人项目、内部工具、尚未发布的新功能，这条很好用。但写成“不要保留向后兼容”太绝对。公共 API、SDK、数据库 Schema、已经发布的 App，都可能确实需要兼容和迁移。
所以我给三星：思路对，但必须加适用条件。
2. 选择满足需求的最简单实现
英文原文
Choose the simplest implementation that fully meets the current requirements. Avoid speculative abstractions, configuration, and indirection.
中文：选择能够完整满足当前需求的最简单实现。避免为假设中的未来需求提前增加抽象、配置和间接层。
★★★★★
这是整份文件里我最想保留的一条。
AI 写代码有一个很常见的问题：它知道的设计模式太多。一个简单功能，也可能主动加 Protocol、Factory、Adapter、Configuration，再顺手为“以后可能需要”预留扩展点。
这条把边界写得很清楚：当前需求没有要求的复杂度，不要提前实现。
3. 从最小可运行版本开始，一层层增加能力
英文原文
Grow the system in layers. Start from the smallest version that works end to end, and add each new capability on top of a product that already works. Never trade a working product for unfinished complexity.
中文：让系统逐层增长。先完成一个最小但端到端可工作的版本，再在已经能够工作的产品上增加新能力。不要为了尚未完成的复杂设计，牺牲一个已经能工作的产品。
★★★★★
这条规定的是 Agent 的开发节奏。
不要一次改十几个文件，最后再一起测试。先做最小完整链路，跑通，验证，再增加下一层能力。
Coding Agent 单次改动范围越大，后面的 Debug、返工和上下文消耗通常越难控制。小步完成、持续可运行，比一开始铺一套“大架构”可靠得多。
4. 保持模块化，职责分开
英文原文
Keep components modular and concerns clearly separated.
中文：保持组件模块化，并清楚地分离不同职责。
★★★★☆
原则没问题，但它太容易被 AI 过度执行。
“职责分离”不等于每个东西都要再建一层 Protocol、Manager、Coordinator。它必须和上一条“最简单实现”一起使用：该分开的职责分开，不为架构整齐额外制造抽象。
5. 优先成熟、维护良好的库
英文原文
Prefer established, well-maintained libraries when they reduce overall complexity or improve reliability. Do not reimplement common functionality without a clear reason.
中文：如果成熟、维护良好的库能降低整体复杂度或提高可靠性，优先使用。没有明确理由，不要重新实现常见功能。
★★★★☆
关键限制其实已经写在原文里：when they reduce overall complexity or improve reliability。
不是“能用库就用库”。引入依赖也有成本。要比较的是引入之后的总复杂度和可靠性。成熟的通用能力通常没必要让 Agent 再造一遍，但也没必要为了少写几十行代码就多背一个重依赖。
6. 先查项目已有依赖，再自己写
英文原文
Lean on the dependencies already in the project before writing your own implementation or adding packages. Do not assume a library lacks a capability without checking its documentation and types.
中文：在自己实现或者增加新 package 之前，先利用项目已经存在的依赖。不要没检查文档和类型定义，就认定某个库缺少某项能力。
★★★★★
这一条很适合 AI Coding。
Agent 很容易凭模型记忆判断：“这个库好像不支持。”然后自己写一个；或者一看到新需求，就马上加一个 package。
更稳妥的顺序应该是：先看项目里已经有什么，再查当前文档和 types，确认做不到以后，才考虑新增依赖或自己实现。
7. 架构决策考虑长期，不接受准备以后重写的临时方案
英文原文
Make architectural decisions for the long term. Do not accept a stopgap that only works for now and is meant to be replaced later.
中文：架构决策要考虑长期。不要接受一个只能暂时工作、并且准备以后再替换掉的权宜方案。
★★★★☆
方向是对的，但这一条必须和第 2、3 条一起读。
否则 Agent 很容易把“考虑长期”理解成“现在就把未来几年可能用到的架构全部设计好”，结果又回到过度设计。
可以只解决今天的需求，但不要明知道当前实现撑不住下一步，还先写一个准备以后推倒重来的 hack。范围小没有问题，明知是一次性架构才有问题。
如果是我自己用，我会改成下面这 7 条
原版我会保留大部分意思，但把几个容易误伤的地方收紧：兼容性按真实约束决定；模块化不能变成过度抽象；“长期”也不能变成为假想需求提前设计。
# AGENTS.md
- Do not preserve backward compatibility unless the current task, public API, persisted data, or existing users require it. Remove obsolete paths instead of keeping compatibility layers or fallbacks without a concrete need.
- Choose the simplest implementation that fully meets the current requirements. Do not add abstractions, configuration, indirection, or extensibility for hypothetical future needs.
- Work in small, end-to-end increments. Start with the smallest version that works, verify it, then add the next capability. Keep the project in a working state whenever practical.
- Keep responsibilities clearly separated and components reasonably modular, but do not introduce abstractions solely for architectural neatness.
- Prefer established, well-maintained libraries when they meaningfully reduce total complexity or improve reliability. Do not reimplement common functionality without a concrete reason.
- Before writing custom code or adding a dependency, check what the project already uses. Verify existing libraries against their current documentation, source, and types before concluding they cannot do the job.
- Make implementations durable enough for foreseeable requirements, but do not over-engineer for speculative future needs. Avoid known throwaway hacks that are expected to be rewritten later.
这 7 条里，我最看重的还是三个动作：少做假设、小步验证、先查现有能力。
至于“省 80% Token”，先别把数字当结论。能不能省，取决于项目、Agent、任务类型和原先的工作方式。至少这套规则能减少一类很常见的浪费：Agent 自己把简单任务做复杂。
如果喜欢这篇文章呢，欢迎点个赞哈
