CLAUDE.md 审阅
审计CLAUDE.md，找出那些实际影响输出质量的故障模式。
前提： CLAUDE.md 会在每次会话时加载到上下文中，因此每一行要么在付出租金，要么在每次交互中消耗你的代币。大多数“模型不遵循指令”的问题其实是指令本身的问题。
步骤
- 读取目标文件（默认为
./CLAUDE.md；同时检查~/.claude/CLAUDE.md以及任何嵌套的**/CLAUDE.md，如果项目结构中有的话，因为最接近的文件会胜出）。 - 对以下每个维度进行评分，并引用具体有问题的行。
- 输出底部提供的报告格式。提出具体的重写方案，而不是“考虑更具体一些”。
需要检查的内容
具体性 — 最具杠杆作用的维度。
- 标记不可验证的指令：“编写干净的代码”、“遵循最佳实践”、“小心谨慎”、“使用良好的命名”。
- 每条规则都应能通过查看差异来检查。
“重构超过40行的函数”是可检查的；而“保持函数简短”则不是。
命名锚点。
- 指向“配置文件”、“我们的API层”或“常规模式”的规则会迫使每次会话都重新探索。应替换为实际路径：
src/config/env.ts、src/api/client.ts。 - 验证每个提到的路径、命令和文件名是否仍然存在。报告失效的项——一个指向已删除文件的
CLAUDE.md会主动误导。
过时性。
- 版本号、模型名称和工具命令与仓库当前状态不匹配。
- 针对已移除的框架、脚本或目录的指令。
- 对照
package.json、Makefile、pyproject.toml或类似文件交叉检查构建/测试/代码检查命令——错误的测试命令比没有更糟糕。
臃肿与租金。
- 任何可以从代码本身推导出的内容（文件树列表、依赖列表、重复描述函数功能）。Claude 可以直接读取仓库。
- 只适用于偶尔执行的一次性任务的冗长流程：这些应属于技能（skill），其主体仅在使用时加载，而不是在每个会话的上下文中。
- 适用于所有软件项目的通用建议——这类建议对这个项目毫无价值。
冲突。
- 互相矛盾的规则，或者与代码实际行为矛盾的规则。同时标记双方，并询问哪个优先。
- 优先级意外：一个嵌套的
CLAUDE.md或~/.claude/CLAUDE.md覆盖了作者预期的内容。
缺失的内容。 值得指出的空白，如果以下内容缺失：
- 如何运行测试、构建和代码检查——自我验证更改所需的三个操作。
- 非明显的项目约束（必须保持不变的目录、生成的文件、必需的迁移步骤）。
- 那些真正令人惊讶且无法通过快速阅读代码发现的约定。
输出格式
## CLAUDE.md 审阅 — <路径> (<N> 行)
**结论：** <一句话>
### 阻塞性问题
- L<n>: <引用的行> → <具体重写>
### 值得修复
- L<n>: <引用的行> → <具体重写>
### 建议删除（每次会话消耗上下文，但无任何收益）
- L<n>–<m>: <内容及原因>
### 缺失内容
- <空白点> → <建议添加的行>
**编辑后预估大小：** <N> 行（从 <M> 行）
规则
- 引用真实的行号和真实文本。不要为了填充某个部分而凭空捏造发现。
- 如果某个部分没有发现，则写
无。——一个干净的文件也是有效结果。 - 优先删除而非重写。最好的
CLAUDE.md应该简短到人们愿意阅读。 - 除非被要求，否则不要编辑文件。先报告。