AGENTS.md 高强度自用版：Vercel工程师60B Token总结的8条铁律

📝

Vercel 工程师 Marcos Hernanz 跑完 60B token 后总结的完整 AGENTS.md，以及小红书作者的高强度中文自用版（18规则/5板块）。核心：不向后兼容、最简实现、分层演进、长期决策。附作者真实使用统计：累计171.4亿 Token、连续98天。

AGENTS.md 高强度自用版：Vercel工程师60B Token总结的铁律

来源：小红书笔记（AI探索汇报，小红书号 102672264）。图二为 Vercel 工程师 Marcos Hernanz 跑完 ~60B tokens 后总结的完整 AGENTS.md（英文原版），图一为作者的高强度中文自用版（18 规则 / 5 板块）。

英文原版（Marcos Hernanz，@MarcosHernanz · Aug 3）

After doing ~60B tokens, this is my full AGENTS.md

# AGENTS.md
- Do not preserve backward compatibility. Remove obsolete paths instead of
  adding compatibility layers, fallbacks, or migrations.
- Choose the simplest implementation that fully meets the current requirements.
  Avoid speculative abstractions, configuration, and indirection.
- 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.
- Keep components modular and concerns clearly separated.
- Prefer established, well-maintained libraries when they reduce overall
  complexity or improve reliability. Do not reimplement common functionality
  without a clear reason.
- 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.
- Make architectural decisions for the long term. Do not accept a stopgap that
  only works for now and is meant to be replaced later.

中文高强度自用版（18 规则 / 5 板块）

核心思想

• 以第一性原理思考问题，理解需求背后的真实目标，而不是直接套用已有模式或技术方案
• 优先解决本质问题，避免为假设中的未来需求提前设计复杂系统
• 在保证长期可维护性的前提下，选择当前最简单、可靠、清晰的实现方案

简洁与设计原则

• 遵循 KISS：优先简单直接的实现，避免不必要复杂度
• 遵循 DRY：避免重复逻辑，但不要为了消除少量重复而创建过度抽象
• 遵循 SOLID：保持职责清晰、降低耦合，提高可维护性和扩展能力

架构原则

• 不要为了向后兼容长期保留废弃方案。优先删除过时代码，而不是增加兼容层、fallback 或临时迁移逻辑
• 不要进行未经验证的架构设计，避免提前引入抽象、配置和间接层
• 从最小可工作的版本开始逐步演进，每次修改建立在已有可运行系统之上
• 永远不要用未来可能需要的复杂性，牺牲当前产品的可用性

代码质量原则

• 保持模块职责明确，避免一个模块承担过多职责
• 优先使用成熟、稳定、维护良好的第三方库，不重复造轮子
• 用项目已有依赖解决问题，不随意新增依赖
• 引入新方案前，先检查已有代码、依赖、文档和能力
• 避免为了”看起来更优雅”而增加实际复杂度

工程决策原则

• 优先长期可维护的方案，而不是只能临时运行的方案
• 代码服务业务目标，而不是展示技术复杂度
• 简单方案已满足需求时，不主动升级为复杂方案

作者使用统计（图四：真实数据）

指标	数值
累计 Token	171.4 亿
峰值令牌数	11.7 亿
当前连续天数	98 天
最长耗时任务	19 小时 9 分钟
快速模式占比	80%
最常用推理强度	极高 · 41%
已探索技能	131 个

这套统计佐证了”60B tokens 跑出来的经验”含金量——作者是真的高强度使用了近百日。

拆解：8 条铁律背后的工程哲学

1. 不保留向后兼容 → 删除优于打补丁，技术债的源头是”兼容层”
2. 最简实现 → 反投机抽象，YAGNI 的具体化
3. 分层演进 → 最小可用版本起步，每次改动基于可运行系统
4. 模块化 → 职责单一，可维护性的基础
5. 优先成熟库 → 不重复造轮子，但要检查文档和能力
6. 依赖优先 → 先用项目已有依赖，不随意新增
7. 长期决策 → 不接受临时方案（stopgap）
8. （中文版补充） 第一性原理、KISS/DRY/SOLID、反优雅陷阱

本质是反过度设计 + 反兼容性负担 + 最小可行演进三原则合集。比常见的 AI 编码规范更”工程决策导向”——它约束的不是写代码的方式，而是做决策的方式。