CLAUDE.md 四大原则：让 AI 编程从”自信菜鸟”变身为靠谱工程师
一个不到 60 行的配置文件，让 AI 编程准确率从 65% 提升到 94%。
问题的根源：AI 是”自信的初级工程师”
用过 AI 编程助手的人，大概都遇到过这三个场景：
场景一：它默认了你的需求，没问就做了 你说”加个登录功能”，它吭哧吭哧搭了一套 JWT + Redis Session + 过期刷新，结果你只需要一个简单的账号密码校验。
场景二：它把代码改复杂了 你只是想修一个小 bug，它顺手把整个模块重构了，还加了一堆”为未来预留”的抽象层。
场景三：它改动了不相关的地方 你让它修 A 功能，它把 B 功能的代码风格也统一了，还顺手删了一行”看起来没用”的注释——那行注释其实是有意义的。
这不是工具的问题。这是行为模式的问题。
Andrej Karpathy（OpenAI 联合创始人、前特斯拉 AI 负责人）在 2025 年初发了这样一条推文，直指 LLM 编程的三个致命习惯：
- 遇到模糊问题时默认假设而不是提问
- 倾向于过度工程化，用复杂的方案解决简单问题
- 会无意间修改不相关的代码，产生副作用
开发者 Forrest Chang 把 Karpathy 的观察提炼成一份 CLAUDE.md 配置文件，四条行为准则，不到 60 行。GitHub 上收获 60,000+ stars，成为 AI 编程圈最火的配置文件。
四大原则详解
原则一：Think Before Coding — 先说清楚，再动手
核心理念：不要假设。不要隐藏困惑。把权衡摊开来说。
实施这条原则要求 AI 在写代码前做到四件事：
- 明确陈述自己的假设，不确定的地方主动提问
- 如果存在多种合理的实现方案，先列出来，不要默认选一个
- 如果发现更简单的方案，直接说出来，甚至主动 push back
- 如果遇到不清楚的地方，停下来，明确说出哪里不清楚，而不是蒙着做
这条原则解决的是”沉默假设”问题——AI 往往默认它理解了你的意图，而不验证这个假设是否正确。结果做完了才发现方向错了。
用一条 prompt 激活这条原则： “在开始写代码之前，先说说你对这个需求的理解，包括你做了哪些假设。“
原则二：Simplicity First — 克制是美德
核心理念：只写解决当前问题所需的最少代码。不写”未来可能用到”的东西。
具体要求：
- 不添加需求之外的功能
- 不为”只有一处使用”的代码创建抽象层
- 不添加没有被要求的”灵活性”或”可配置性”
- 不为不可能发生的场景写错误处理
- 如果写了 200 行能解决问题的代码，发现其实 50 行就够——重写
Karpathy 的检验标准值得参考：
“问问自己：一个高级工程师会觉得这过度复杂吗？如果是，简化。”
这条原则解决的是”过度工程化”问题。AI 倾向于”展示能力”，喜欢写通用方案、留扩展接口、加配置选项——这些对简单任务来说都是噪音。
原则三：Surgical Changes — 只切该切的地方
核心理念：修改代码时保持最小侵入。只清理自己产生的垃圾。
编辑现有代码时的规则：
- 不动相邻的代码、注释或格式（除非用户明确要求）
- 不重构没有坏掉的东西
- 匹配现有风格，即使你平时有不同偏好
- 发现无关的死代码时，提出来，而不是直接删掉
当你的改动产生了废弃的代码时：
- 清理你改动导致的 unused imports / variables / functions
- 不要删除本来就存在的死代码（除非被要求）
检验标准很简单：
“每一行被修改的代码，都应该能直接追溯到用户的请求。”
这条原则解决的是”副作用扩散”问题——AI 经常在”顺手改进”的名义下改动很多不相关的代码，引入了新的 bug。
原则四：Goal-Driven Execution — 用可验证的目标驱动执行
核心理念：把任务转化为可验证的目标，而不是模糊的”做完就行”。
核心方法是把模糊的任务变成具体的验证条件：
| 模糊任务 | 可验证目标 |
|---|---|
| ”加个校验" | "为无效输入写测试，然后让它们通过" |
| "修掉这个 bug" | "写一个能复现 bug 的测试，然后让它通过" |
| "重构 X 模块" | "确保重构前后测试都通过” |
对于多步骤任务，先声明计划，每个步骤带验证点：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]强成功标准让 AI 能够独立循环，不需要每一步都来问你。弱标准（“让它能工作”）意味着 AI 每走一步都要停下来确认方向。
效果：准确率从 65% 到 94%
根据使用者的实际反馈，按照这四条原则配置的 AI 编程 agent：
- 纠错次数显著减少：不需要在 AI 做完之后回头删掉过度工程的代码
- 返工减少：问清楚再做，比做完再改方向效率高得多
- 对齐质量提升：AI 在动手前先确认假设，输出的东西更符合预期
这四条原则的本质，是把 AI 从”执行者”变成”协作伙伴”——在盲目执行之前，先完成对问题的共同理解。
怎么用？
最简单的方式，在项目根目录创建 CLAUDE.md，把下面的内容贴进去：
# CLAUDE.md
## 1. Think Before Coding
State your assumptions explicitly. If uncertain, ask. Present multiple interpretations rather than picking silently.
## 2. Simplicity First
Write the minimum code that solves the problem. No speculative features or abstractions.
## 3. Surgical Changes
Touch only what you must. Clean up only your own mess. Don't improve unrelated code.
## 4. Goal-Driven Execution
Transform tasks into verifiable goals. State a plan with verification steps.如果使用 Claude Code，只需要把这个文件放在项目根目录，它会自动加载。
思考
CLAUDE.md 的流行说明了一个很朴素的事实：AI 编程的问题，不在于 AI 能力不够，而在于缺少清晰的行为约束。
这四条原则本质上是在模拟一个高级工程师的思维习惯：
先理解，再动手；最小化改动；用验证驱动开发。
这不是限制 AI 的能力，而是让它把能力用在正确的地方。
一个”自信的初级工程师”会让你花大量时间review和返工；一个”靠谱的高级工程师”会先问清楚，动手时精准施治，完成后给你一个干净的 diff。
CLAUDE.md 做到了这一点——不是通过更强大的模型，而是通过更好的行为准则。
参考项目：forrestchang/andrej-karpathy-skills（GitHub 60k+ stars）