CLAUDE.md 深度定制
🎯 学完这课你能
- 理解 CLAUDE.md 的三层层级（全局/项目/子目录）
- 审视和优化你自己的 CLAUDE.md
- 掌握写好规则的五个原则
CLAUDE.md 不是写给自己看的愿望清单，也不是情绪发泄区。它应该让 CC 明白：什么该做、什么别做、为什么这样做、什么时候优先生效。
📊 你的 CC 数据说：你已经创建了全局 CLAUDE.md 并加入了反过度工程化规则——这让你在 Insight 报告中获得"Proactive Claude Code Customization"的好评。但报告还建议你加入飞书 API 权限前置检查、翻译任务分段执行、报错时的降级策略三条新规则。
你已经在用 CLAUDE.md 了——这很厉害。但你知道它到底是什么、怎么写才能让 CC 更听话吗？
CLAUDE.md = 给 AI 的岗位说明书（JD）
你给新员工写 JD 时会写什么？
- 岗位职责（做什么）
- 工作规范（怎么做）
- 注意事项（不能做什么）
- 汇报关系（跟谁配合）
CLAUDE.md 做的是完全一样的事——只不过"新员工"是 AI。
比如解释要通俗、别乱删文件、部署前必须验证，这些是你最常跟 CC 反复强调的，就应该优先固化下来。
只写“不要升级依赖”还不够，最好写出“因为这个项目对版本敏感，之前踩过兼容性坑”。这样 CC 更容易正确判断。
“写好代码”没法执行；“改完先跑 build，再用通俗语言解释改动原因”才是 AI 能照着做的指令。
技术栈变了、协作方式变了，CLAUDE.md 也要跟着调整，不然它会变成一份误导 AI 的过期说明书。
三层 CLAUDE.md
CC 会读取三个层级的指令文件，优先级从低到高：
看看你现在的 CLAUDE.md 写了什么
你的全局 CLAUDE.md（~/.claude/CLAUDE.md）已经写了一些很好的规则：
- "Avoid over-engineering" — 防止 CC 过度设计，非常关键
- Python UTF-8 规范 — 针对中文项目的实际问题
- UI/UX 先要截图 — 防止 CC 凭空设计
- 飞书集成的权限检查 — 从踩过的坑中总结的经验
- 部署前验证版本 — 避免 Prisma 版本不兼容的问题
- 你的角色声明 — "我是 HR，不懂代码细节，请用通俗语言解释技术选择"
- 沟通风格偏好 — "回复简洁，不要长篇大论""改完告诉我改了什么、为什么"
- 错误处理偏好 — "遇到报错先解释是什么问题，再修复"
写好 CLAUDE.md 的五个原则
每次 CC 犯了一个让你不爽的错误，就把"下次别这样"加到 CLAUDE.md 里。你的规则是血泪教训，不是空想。
用 ## 标题把规则分成几个板块（编码规范、部署规则、沟通风格），CC 更容易找到相关规则。
项目变了、技术栈换了，过时的规则可能误导 CC。每隔一段时间审视一下。
CLAUDE.md 模板
给你一个通用模板，可以根据自己的需要修改：
把规则写成“AI 能执行”的话
“回复简洁”可以再具体成“先给结论，再解释原因，默认不写长段背景”。越能被执行，规则越有用。
比如“部署前必须先跑 build”，“只有我明确要求时才升级大版本依赖”，这些边界能直接避免高代价误操作。
如果你每次都要补充“请说人话”“不要乱加文件”“先解释报错再修”，那这些就应该进 CLAUDE.md。
最好的规则来自真实项目和真实踩坑，而不是照抄别人模板。你的 CLAUDE.md 应该越来越像你的工作习惯说明书。
📝 小测验
以下哪条 CLAUDE.md 规则写得最好？
📝 小测验 2
你有一条全局规则"所有文件用中文命名"，但某个项目需要英文文件名。应该在哪里覆盖？