10分钟学会CLAUDE.md: 从入门到精通

土豆不吐皮

核心观点
规则越多，Agent 反而更容易跑偏。重点是：哪些该留、哪些该删。
CLAUDE.md 与 AGENTS.md 是什么  开工前要读的项目长期约定  
适合写：业务规则、开发验证方式、联动关系、验收标准、权威资料位置  
不适合写：代码里能直接看到的事实、强制安全机制（这些要用权限/Hook/测试/CI 兜底）

两者区别  Claude Code：CLAUDE.md + CLAUDE.local.md（个人偏好，加 .gitignore）  
Codex：AGENTS.md + AGENTS.override.md（覆盖文件）  
局部规则放对应子目录，注意加载触发方式不同

第一份文件怎么建
用 /init 生成草稿，然后先做减法
做减法：三条判断标准  Agent 能不能很快从项目里找到？（能就删）  
大多数任务都会用到吗？（否 → 下沉到子目录或按需加载）  
三个月后还成立吗？（临时信息不要写成长规则）

做加法：五个问题提取隐性知识  绝对不能搞错的业务规则  
固定的处理入口  
改完一处必须联动的地方  
完成标准（可验证）  
不确定时去哪里找答案

从 /init 草稿到可用文件的完整示范
电商项目例子：技术事实 vs 隐性知识分流，根目录只留通用规则，前端规则下沉到 frontend/
内容该放哪：判断表
发布流程 → Skill；高风险禁令 → 程序机制兜底
可直接复制的最小模板
故意写得很短，没有就删
同时用 Claude Code + Codex 时只维护一份
以 AGENTS.md 为唯一事实来源，CLAUDE.md 用 @AGENTS.md 导入
写完后验证是否真正生效
用具体小任务测试行为，而不是只让 Agent 复述
维护原则：新增 + 修剪  新增时机：重复错误、高代价隐性前提、固定流程多次出现  
删除时机：过期、重复、冲突、已能从代码发现  
推荐节奏 + 附赠「渐剪提示词」（审计用，默认不直接改文件）

定稿前 6 项检查清单
总结
好的指令文件 = Agent 无法自行发现、却会持续影响正确结果的最小规则集。像花园，不是档案馆。

在线阅读：

游客，如果您要查看本帖隐藏内容请回复