CLAUDE.md 深度定制
🎯 学完这课你能
- 理解 CLAUDE.md 的三层层级（全局/项目/子目录）
- 审视和优化你自己的 CLAUDE.md
- 掌握写好规则的五个原则
📊 你的 CC 数据说：你已经创建了全局 CLAUDE.md 并加入了反过度工程化规则——这让你在 Insight 报告中获得"Proactive Claude Code Customization"的好评。但报告还建议你加入飞书 API 权限前置检查、翻译任务分段执行、报错时的降级策略三条新规则。
你已经在用 CLAUDE.md 了——这很厉害。但你知道它到底是什么、怎么写才能让 CC 更听话吗？
CLAUDE.md = 给 AI 的岗位说明书（JD）
你给新员工写 JD 时会写什么？
- 岗位职责（做什么）
- 工作规范（怎么做）
- 注意事项（不能做什么）
- 汇报关系（跟谁配合）
CLAUDE.md 做的是完全一样的事——只不过"新员工"是 AI。
三层 CLAUDE.md
CC 会读取三个层级的指令文件，优先级从低到高：
就像制度体系：公司规定"所有文档用中文"（全局），但技术部可以规定"代码注释用英文"（项目级），而前端组还可以补充"CSS 类名用 kebab-case"（子目录级）。下级规则可以覆盖上级。
看看你现在的 CLAUDE.md 写了什么
你的全局 CLAUDE.md（~/.claude/CLAUDE.md）已经写了一些很好的规则：
✓ 做得好的
- "Avoid over-engineering" — 防止 CC 过度设计，非常关键
- Python UTF-8 规范 — 针对中文项目的实际问题
- UI/UX 先要截图 — 防止 CC 凭空设计
- 飞书集成的权限检查 — 从踩过的坑中总结的经验
- 部署前验证版本 — 避免 Prisma 版本不兼容的问题
💡 可以补充的
- 你的角色声明 — "我是 HR，不懂代码细节，请用通俗语言解释技术选择"
- 沟通风格偏好 — "回复简洁，不要长篇大论""改完告诉我改了什么、为什么"
- 错误处理偏好 — "遇到报错先解释是什么问题，再修复"
写好 CLAUDE.md 的五个原则
1. 具体 > 模糊
✗ "写好的代码"
✓ "函数不超过 30 行，变量名用英文"
2. 写"为什么"，不只是"什么"
✗ "用 SQLite"
✓ "用 SQLite 因为是单机部署，不需要独立数据库服务"
3. 来自真实踩坑，而非想象
每次 CC 犯了一个让你不爽的错误，就把"下次别这样"加到 CLAUDE.md 里。你的规则是血泪教训，不是空想。
4. 用标题分类
用 ## 标题把规则分成几个板块（编码规范、部署规则、沟通风格），CC 更容易找到相关规则。
5. 定期清理过时规则
项目变了、技术栈换了，过时的规则可能误导 CC。每隔一段时间审视一下。
CLAUDE.md 模板
给你一个通用模板，可以根据自己的需要修改：
## 我是谁
我是 HR，主要用 vibe-coding 做内部工具。
请用通俗语言解释技术决策，遇到报错先解释原因。
## 编码风格
- 不要过度工程化，只做我要求的事
- Python 文件使用 UTF-8 编码
- 改完代码告诉我改了什么、为什么
## 项目约定
- 数据库：SQLite（开发）/ Turso（生产）
- 认证：飞书 OAuth
- 部署前必须跑 npm run build 验证
## 不要做的事
- 不要在没问我的情况下升级依赖大版本
- 不要删除我没提到的代码
- 不要创建不必要的新文件
📝 小测验
以下哪条 CLAUDE.md 规则写得最好？
📝 小测验 2
你有一条全局规则"所有文件用中文命名"，但某个项目需要英文文件名。应该在哪里覆盖？