考察点
这道题出自 AI 编程工具实践类面经（Claude Code 使用经验的延伸追问），考察的是你到底有没有在真实项目里维护过这类文件。背概念的人会说"就是给 AI 看的 README"，干过的人会讲分层加载、内容取舍和过期治理。追问往和 README 的分工、防过期机制、多工具兼容上走。
参考答案
定位：可版本管理的项目记忆
AGENTS.md（开放约定，多家工具支持）和 CLAUDE.md（Claude Code）本质上是同一个东西：会话启动时自动注入系统上下文的 Markdown 文件，充当 Agent 的项目级持久记忆。它解决的问题是——项目知识（怎么构建、什么规范、哪些坑别踩）不该靠用户每轮口述，也不该指望模型从代码里自己悟。因为进 git、能 code review，它比向量记忆库直白可靠；因为每次会话必注入，它比 README 的触达率高得多。
写什么：四类内容
有效的内容就四类，都是"不看就会犯错"的信息：
- 命令：怎么安装依赖、跑测试、构建、起服务，带具体命令行和端口。Agent 最大的浪费就是猜构建命令试错。
- 技术栈与结构：框架和版本、目录布局、关键模块入口，让 Agent 改代码前知道去哪找。
- 约定：代码风格、提交规范、分支策略、"改 X 必须同步改 Y"这类跨文件约束。
- 禁忌：不许碰的目录、不能提交的文件、部署相关的红线。
反例是写产品背景、架构哲学、长篇设计文档——这些不指导具体操作，只会吃 token 稀释注意力。判断标准：删掉这条，Agent 会犯错吗？不会就删。
怎么组织：短、具体、分层
短：单文件控制在几百行内。它是每轮都要付费的上下文，写成两千行等于每轮烧掉几千 token 还淹没重点。具体：写"测试用 pytest tests/ -x，不是 unittest"，不写"请保持良好的测试习惯"——可执行的指令才有约束力，口号没有。分层：根目录放全局约定，子目录放局部约定（如 backend/ 下写后端专属命令），工具按当前工作目录就近加载，避免单文件膨胀。Claude Code 还有用户级（~/.claude/CLAUDE.md）放个人偏好，和项目级分开。
怎么活：随代码演进
最大的失败模式是文件写完没人管，构建命令换了半年还写旧的，Agent 照着执行必错——过期记忆比没有记忆更糟，因为模型会优先信任它。三条治理经验：把 AGENTS.md 的更新纳入 PR 检查项，改了构建流程、目录结构、技术栈的 PR 必须同步改它；定期让 Agent 自己"体检"——跑一次文件里的每条命令，失败的就是过期内容；文件头部维护"最后验证时间"，让人对它的新鲜度有预期。
多工具兼容
团队里 Claude Code、Codex、Cursor 混用时，以 AGENTS.md 为准（开放约定支持面最广），CLAUDE.md 等其他工具的配置文件用符号链接或一行 @AGENTS.md 引用指向它，避免多份内容漂移。单一事实来源这条原则，在配置文件上和数据库上同样成立。
可能的追问
- 和 README 什么分工？——README 面向人（项目是什么、怎么上手），AGENTS.md 面向 Agent（怎么干活、什么不许干）；有重叠的命令部分可以互相引用，别两份各写一遍。
- 写了很多规则 Agent 还是不遵守怎么办？——先查是不是太长被稀释，精简到红线以内；关键约束配合 hooks/CI 硬拦截（比如 lint 失败禁止提交），文件管提示，工具管强制。
- 敏感信息能写进去吗？——不能，它会被注入每次会话且随 git 分发；密钥、内部地址一律不放，用环境变量或本地配置文件，并在文件里写明"敏感配置走 .env"。