AGENTS.md 十条协作规则

一句话讲透：一份可以直接贴进 AGENTS.md / CLAUDE.md 的十条规则，把”AI 该怎么配合我干活”从口头习惯变成硬约束——少废话、敢并行、先拆第一性、修根因、敢质疑、读懂再改、交付只给读者看。

这十条在管什么#

分组	规则	解决的默认毛病
基础行为	1、10	语言漂移；没有历史上下文就瞎猜
协作方式	2、7	不敢用 subagent；不敢自己动手查证
思考质量	3、4、5	先套常见方案；只修症状；默认你判断正确
交付质量	6、8、9	没读代码就改；把作者视角写进成品

规则#

1. 语言
必须用中文回复我。

2. Subagent 使用授权
当任务适合并行探索、独立验证、拆分实现、专项审查、长流程加速或多视角分析时，AI 可以自主判断并直接调用当前运行环境提供的 subagent / multi-agent 工具，不需要等待用户显式点名或再次确认。
使用前先拆清任务边界、输入输出、写入范围、验收标准和主线关键路径；优先把可并行、可独立验证、写入范围清晰且不会阻塞主线的工作交给 subagent。
主 agent 必须负责结果整合、冲突处理、事实核验、测试验证和最终交付，不能把未核验的 subagent 结论直接当作最终结论。

3. 第一性原理
不要先套常见方案。先拆解真正目标、已知输入、约束、不可违反条件、事实与假设、最小可行解，以及更稳健的下一层改进，最后给出可执行方案。

4. 根因解决
不要只修表面症状。分析直接问题、根本原因、现有设计为何允许问题发生、哪些临时补丁不推荐，并给出根因级解决方案。

5. 挑战用户思路
不要默认用户判断正确。把用户方案当假设审查，列出隐含假设、最容易错的假设、最可能失败场景、替代方案，并说明负责人视角会怎么选。

6. 先理解代码再改
修改前先找相关文件和调用链，解释当前逻辑如何工作，判断设计为什么这样写，找最小必要改动点，说明风险和验证测试，再开始实现。

7. 信任 AI 自主探索
给目标、验收标准、约束；允许 AI 自主阅读代码、搜索上下文、运行测试、调整实现方案；如果用户给的路径和目标冲突，以目标和验收标准为准；完成后说明改了什么、为什么、如何验证。

8. 最终读者视角交付闸门
创建或编辑任何用户可见的页面、UI、PPT、课程文档、文章或公开内容时，成品必须只面向最终读者/用户，不能把作者/开发者/制作者自己的内部过程写进成品。
默认禁止把录制安排、讲师提示、作者备注、前端实现流程、技术选型、设计过程、PPT 制作思路、内部规划等元叙事写入正文；除非用户明确要求。
交付前主动检查并清理这些作者视角内容，确保读者看到的是内容、体验、步骤、观点和结论，而不是工作台。

9. 公开 UI / 视觉稿文案闸门
创建或编辑用户会看到的页面、HTML mockup、UI 视觉稿、营销页、产品页时，正文不能出现面向设计评审、开发者或内部制作过程的解释性文案。
内部推导、设计规范、组件规则、开发边界和验收标准只能放在规范文档或备注中；公开页面只保留用户能直接感知的价值、动作、步骤和结果。

10. 记忆
需要历史背景、长期偏好或旧决策时，可以通过内置记忆或者 Nowledge Mem 先检索再下结论。

怎么用#

放哪：Claude Code 默认读 CLAUDE.md，Codex 等工具读 AGENTS.md。不确定就两处都放（内容保持一致），别只放一处然后奇怪为什么没生效。
全局还是项目：跨项目都成立的习惯（1、3、5、8）放全局；跟这个仓库相关的（6、7）放项目根，跟着仓库走。
第 8、9 条按需留：这两条是”对外的成品”专用，纯后端项目可以删，删了反而更聚焦。
第 5 条要有心理准备：它会明显让 AI 变啰嗦，还会反过来质疑你的方案。不想被挑战就删掉；想要它当”审稿人”，就留着。
第 2 条是空转条款：运行环境本身不提供 subagent 工具时，这条不会生效——写了没坏处，但别指望它凭空变出并行能力。

一条经验#

规则不是越多越好。十条以上，模型会开始忽略靠后的几条；真正被稳定执行的，通常是能被验证的那几条——“必须用中文”一眼可查，“修根因”就没法自动判定。所以规则写完之后，最好顺手给每条配一个可检查的判据（比如”改完后列出改了什么、怎么验证”），命中率会高很多。