Andrej Karpathy 的 63 行文档，4 条规则彻底解决 AI 瞎猜、乱改、画蛇添足、假装修好的问题
使用 Claude Code 做 Vibecoding 时，经常会遇到这些问题：你只是让它改一下按钮颜色，结果它顺手把整个页面布局都改了；你只是加一个小功能，结果它给你整了一套"可扩展架构"，200 行代码里 150 行根本用不上；它信誓旦旦说"已经开发好了，没有错误了"，结果打开一用还是疯狂报错。
就连 AI 圈最顶级的大佬——OpenAI 创始团队成员、前特斯拉 AI 负责人 Andrej Karpathy——也遇到过一模一样的问题。他没有换更贵的模型，也没有写复杂提示词，而是把自己踩过的坑总结成了一份 CLAUDE.md 文档，一共 63 行。这份文档现在在 GitHub 上已有 10 万星。
它的核心不是高级编程技巧，而是怎么让 AI 守规矩。不管你是用 AI 写代码、写文章、做表格还是整理资料，只要经常遇到"AI 自作主张"的问题，这套思路都能用。
这份文档出自 Andrej Karpathy（OpenAI 创始团队成员、前特斯拉 AI 负责人）之手。它不是复杂的项目，而是一份简短的行为准则文档，专门解决 AI 写代码时最常见的四种失控行为。
# CLAUDE.md
Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.
# CLAUDE.md
降低 AI 写代码常见错误的行为准则。可与项目专属规则合并使用。
**权衡：** 这些规则偏向"谨慎"而非"速度"。琐碎任务，请自行判断。
## 1. 动手前先想清楚（Think Before Coding）
**不假设、不藏糊涂、把权衡摊开来说。**
实现之前：
- 把你的假设明确说出来，不确定就问。
- 有多种理解时，把所有可能列出来——别擅自挑一个就闷头干。
- 如果有更简单的方案，说出来，必要时反驳我。
- 哪里不清楚，就停下来，指出哪里让你困惑，然后问我。
## 2. 最小化原则（Simplicity First）
**只写解决问题的最小代码，不要任何"以防万一"。**
- 不写需求里没要求的功能。
- 不为一次性使用的代码做抽象。
- 不加未要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景写 error handling。
- 如果你写了 200 行而 50 行就够，请重写。
自问一句："资深工程师会觉得这写得太复杂了吗？"如果是，请简化。
## 3. 外科手术式改动（Surgical Changes）
**只动该动的，只清自己的烂摊子。**
修改现有代码时：
- 别"顺手改进"周边代码、注释或格式。
- 别重构没坏的东西。
- 配合现有的代码风格，哪怕你不喜欢。
- 看到无关的死代码——告诉我，但别删。
如果你的改动产生了孤儿代码：
- 删掉因你改动而失去用途的 import / 变量 / 函数。
- 不要删原本就存在的死代码，除非我让你删。
判断标准：每一行改动都能追溯到我的需求。
## 4. 目标驱动执行（Goal-Driven Execution）
**定义成功标准，然后循环到通过为止。**
把任务转换成可验证的目标：
- "加个校验" → "写无效输入的测试，然后让它们通过"
- "修这个 bug" → "写能复现这个 bug 的测试，然后让它通过"
- "重构 X" → "保证重构前后测试都通过"
多步任务，给一个简短的计划：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
强的成功标准让你能独立闭环；弱的（比如"让它跑起来"）会让你不停回来问我。
---
**这些规则生效的标志：** diff 里不必要的改动变少了，因过度复杂而返工的变少了，澄清问题出现在动手之前而不是出错之后。
在使用 AI 辅助开发时，最常见的三种失控行为：
1. 不确定也硬干
AI 遇到不确定的需求时，不会停下来确认，而是自己猜一个答案就开始写代码。结果你以为它懂了，它也假装自己懂了，最后做出来的完全不是你想要的。
2. 喜欢给自己加戏
你只是想要一个按钮，AI 给你写了一套组件系统；你只是想要一个输入框，AI 给你加了各种状态管理。看起来很专业，实际上增加大量无效代码，让项目变得臃肿。
3. 做完不验证
AI 说"做完了"，很多时候只是它自己觉得做完了。它可能没跑、没测，甚至没打开看一眼，结果问题比原来还多。
这条规则直接针对"不确定也硬干"的问题。
核心要求：
加上这条规则后，AI 在动手之前会先把不确定的地方摊开。该问就问，该确认就确认，避免"你以为它懂了，它也假装自己懂了"这种最糟糕的情况。
这条规则管的是"AI 喜欢加戏"的问题。
核心原则：
文档里有句特别狠的话——"如果你写了 200 行，50 行就够，重写。"
自检标准："资深工程师会觉得这写得太复杂了吗？" 如果是，那就简化。
这条规则提醒 AI：先把眼前的问题解决，不要为了未来的想象，把项目做得太复杂。
什么叫外科手术一样改代码？只切病灶，不碰健康组织。
核心要求：
文档里有一句话特别关键——"每一行改动，都要能直接追溯到你的需求。"
很多人用 AI 写代码最崩溃的地方就在这里：明明只是让它改一个小点，它却顺手把周围一大片都"优化"了，还觉得是在帮你。结果项目越写越乱，越写越复杂。
这条规则就是告诉 AI：不要自作主张。只碰该碰的地方，别顺手把好好的东西改坏。
这条是最重要的规则，针对"做完不验证"的问题。
以前你给 AI 一个指令，它说"做完了"。但这个"做完"，很多时候只是它自己觉得做完了。
Goal-Driven Execution 要求反过来：先定好什么叫"做完"，达到了才算做完。 把 AI 主观的"我觉得好了"，变成客观的、可以验证的标准。
加上这条规则后，AI 再说"好了"，就不是随口一说，而是已经按标准验证过了。
使用方法非常简单：
CLAUDE.md 文件不用安装插件，不用配置环境，也不用记复杂命令。只要用 Claude Code 开发，它就能自动读取。
Karpathy 的原文（中文翻译版）可以在"搞定空间站"个人主页找到，复制粘贴就能直接用。
实际效果怎么样？来看第一个场景。
向 AI 提一个模糊需求："帮我在这个页面上加一个登录功能。"
这句话非常模糊——没说用邮箱还是手机号，没说要不要验证码，没说登录成功之后跳哪里，也没说按钮放在哪。
加了规则后的 AI 反应：它没有直接开始写代码，而是先停下来反问：
问清楚之后，它才开始动手。这就是第一条规则 Think Before Coding 在起作用。
接着登录页，再提一个需求："帮我给登录页的邮箱输入框加一个校验功能。"
加了规则后的 AI 反应：它没有直接开写，而是先拆了一步——"我先定义一下什么算校验通过。"
然后列出三条验证标准：
test@example.com），能正常提交abc），提示"请输入正确的邮箱格式"，阻止提交标准定完，才开始写代码。写完之后，它不是立刻说"好了"，而是自己跑一遍，把三条标准挨个测一遍，全部通过了才告诉你"校验功能已添加，三个场景都验证通过"。
这就是第四条规则 Goal-Driven Execution 在起作用。