一个文件，9万星：Karpathy 用 4 条规则治好了 AI 写代码的"坏毛病"
不是框架，不是工具，只是一个 CLAUDE.md
你有没有遇到过这种情况：
让 AI 帮你改个 bug，它顺手把你的整个项目"重构"了一遍；让它加个验证，它给你造了一套完整的配置系统；你明明没说要什么抽象层，它已经帮你写好了工厂模式。
更气人的是，改完之后 diff 三屏都看不完，你根本不知道它到底动了什么。
如果你正在用 AI 写代码，这篇文章会帮你省掉大量 review 时间。我从背景、原理、实操到效果，一次性讲清楚。
一、背景：AI 写代码最大的问题，不是"不会写"
1.1 场景背景
2025 年开始，AI 编程工具全面爆发。Claude Code、Cursor、Copilot、Windsurf……几乎每个开发者都在用 AI 辅助写代码。
但用久了你会发现一个矛盾的现象：
AI 越强大，它的"自作主张"就越危险。
它不会犯低级错误，但它会犯一种更隐蔽的错误——过度自信地做你不想要的事。
1.2 痛点 / 问题背景
Andrej Karpathy，前特斯拉 AI 总监、OpenAI 创始成员，在 X 上发了一段话，把这个问题说透了：
"模型会替你做错误假设，然后一路狂奔。它们不管理困惑，不寻求澄清，不暴露矛盾，不展示权衡，不在该推回时推回。"
"它们特别喜欢过度复杂化代码和 API，膨胀抽象层，不清理死代码……1000 行能搞定的事，写成 1000 行。"
"它们有时还会在改代码时，顺手改掉跟你任务无关的注释和代码。"
我之前也踩过同样的坑。让 Claude 帮我重构一个模块，结果它不仅改了目标文件，还"优化"了三个相邻文件的命名风格，删掉了两个它认为"多余"的函数。最后跑了半小时才把测试全部修好。
1.3 初衷 / 目的
Karpathy 的推文引发了大量共鸣。有人把他的观察提炼成四条原则，写成了一个 CLAUDE.md 文件，放进项目根目录，Claude Code 的行为就肉眼可见地改善了。
这个仓库叫 andrej-karpathy-skills，创建 3 个月，拿下了 91,000+ Star，登顶 Star History 周榜第一。
1.4 行业现状
目前市面上关于"AI 编程最佳实践"的内容，要么太理论化（讲 prompt engineering 的学术论文），要么太碎片化（某条 X 推文的经验分享）。真正能落地、能直接用、效果可验证的方案，几乎没有。
这个项目填补了这个空白——一个文件，零成本，即装即用。
二、说明：四条规则，到底写了什么
2.1 核心定义
这不是一个代码库，不是框架，不是插件。它就是一个纯文本的 CLAUDE.md 文件，里面写了四条行为准则。Claude Code 在执行任务前会读取这个文件，按照里面的规则约束自己的行为。
2.2 实操说明
安装只需一行命令
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
把文件放到你的项目根目录，Claude Code 启动时会自动读取。
如果你已经在用 Cursor，项目里也自带了 .cursor/rules/karpathy-guidelines.mdc，同样生效。
四条原则详解
原则一：先想后写（Think Before Coding）
LLM 最常见的毛病是"默默选一个理解，然后一路狂奔"。这条原则要求它：
- ❓ 不确定就问，别猜
- 🔀 有歧义就列出多种解读，别默默选一个
- 💡 有更简单的方案就说出来，别藏着
- 🛑 遇到不懂的地方，停下来说明哪里不清楚
原则二：极简优先（Simplicity First）
这条针对的是 AI 的"过度工程癖"：
- 🚫 没人要求的特性不要加
- 🚫 单次使用的代码不要抽象
- 🚫 没人要的"灵活性"和"可配置性"别造
- 🚫 不可能出现的错误场景别处理
- ✂️ 200 行能搞定的，别写 1000 行
判断标准： 一个资深工程师看到你的代码会不会觉得"太复杂了"？如果是，简化它。
原则三：外科手术式修改（Surgical Changes）
这条解决的是"顺手改了不该改的"问题：
- 🚫 别"改进"相邻的代码、注释或格式
- 🚫 别重构没坏的东西
- 🎨 跟现有代码风格保持一致，即使你觉得可以更好
- 🧹 你改出来的新孤儿（无用的 import / 变量 / 函数）你清掉，别人留下的死代码别碰
判断标准： 每一行改动，都应该能直接追溯到用户的请求。
原则四：目标驱动执行（Goal-Driven Execution）
Karpathy 说：
"LLM 非常擅长循环执行直到满足特定目标……别告诉它做什么，给它成功标准，看它跑。"
把命令式指令变成声明式目标：
| ❌ 不要说 | ✅ 而是说 |
|---|---|
| "加个验证" | "写测试覆盖无效输入，然后让测试通过" |
| "修这个 bug" | "写一个能复现 bug 的测试，然后让它通过" |
| "重构 X" | "确保重构前后测试都能通过" |
多步骤任务，先列计划：
[步骤]→ 验证：[检查点][步骤]→ 验证：[检查点][步骤]→ 验证：[检查点]
核心逻辑： 成功标准越清晰，AI 越能自主循环。标准模糊（"让它跑起来"），你就得反复介入。
2.3 核心亮点
这个文件的真正价值不在于"写了什么"，而在于它把 AI 的行为边界画清楚了。
四条规则的本质是：
给 AI 套上一个"资深工程师的职业素养" ——不懂就问、能简单就不复杂、只动该动的、用测试证明自己。
2.4 适用范围
| 维度 | 说明 |
|---|---|
| 适用人群 | 所有使用 Claude Code 或 Cursor 的开发者 |
| 适用语言 | 任何编程语言和项目规模 |
| 风格偏向 | 谨慎而非速度，简单任务不必走完整流程 |
| 设计目标 | 减少非平凡任务中代价高昂的错误，不是拖慢简单任务 |
三、对比：加了 vs 没加，差距有多大
3.1 横向对比：四条规则 vs 原始行为
| 场景 | ❌ 没有规则时 | ✅ 有规则后 |
|---|---|---|
| 需求有歧义 | 默默猜一个，写完才发现猜错了 | 先列出 2-3 种解读，问你选哪个 |
| 改一个文件 | 顺手"优化"了 3 个相邻文件 | 只动该动的，其他一概不碰 |
| 加一个功能 | 写了 500 行，包含一堆你没要的抽象 | 100 行搞定，没有多余代码 |
| 修一个 bug | 直接改代码，改完才发现引入新问题 | 先写复现测试，再改代码，测试通过才算完 |
| 遇到不确定的地方 | 假设自己是对的，继续往下写 | 停下来，说明哪里不确定，等你确认 |
3.2 纵向对比：实际使用前后的 diff 变化
使用前 使用后
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📁 改动文件数：8-12 个 → 📁 改动文件数：2-4 个
📝 diff 行数：经常 200+ 行 → 📝 diff 行数：控制在 50 行以内
🔄 反复纠正："别改那个" → 🔄 AI 主动问"这里不确定，你确认"
⏱️ review 时间 > 编码时间 → ⏱️ review 时间大幅缩短
3.3 正反对比
❌ 错误用法： 把 CLAUDE.md 放进去就不管了，所有任务都按最高标准执行，连改个 typo 都要 AI 先写测试。
✅ 正确用法： 这个文件是"默认行为基线"，简单任务凭判断灵活处理，复杂任务才走完整流程。目标是减少大错误，不是消灭所有速度。
四、结果：9 万人验证过的有效性
4.1 数据结果
| 指标 | 数据 |
|---|---|
| ⭐ Star 数 | 91,000+ |
| 🍴 Fork 数 | 8,800+ |
| 👁️ Watch 数 | 477 |
| 📅 创建时间 | 2026 年 1 月 27 日 |
| 🏆 排行榜 | Star History 周榜 第一 |
4.2 真实反馈
项目的 GitHub Issues 和 X 上的讨论中，最常见的反馈：
"diff 立刻变干净了"
"AI 终于不再乱改我的代码了"
"加了这个之后，review 时间少了一半"
4.3 结果总结
一个纯文本文件，零依赖，零配置，一行命令安装。它不改你的代码逻辑，不引入新的工具链，不增加学习成本。它只是告诉 AI：
你是来帮忙的，不是来当主人的。
4.4 额外收益
这个文件还有一个隐藏好处：它逼你思考自己的需求是否足够清晰。
当你发现 AI 问你"这里有两种理解，你指的是哪一种"的时候，你会意识到，很多时候不是 AI 笨，是你自己还没想清楚。
五、结尾
📌 全文总结
AI 不会取代工程师，但会用 AI 的工程师，会取代不会用的。关键不在于你用什么模型，而在于你怎么约束它。一个文件，四条规则，9 万人亲测有效。
💬 互动引导
你在用 AI 写代码时踩过什么坑？有没有遇到过 AI "自作主张"的情况？欢迎在评论区分享你的经历，我们一起避坑。
觉得有用的话，点赞 + 在看 + 转发，让更多还在踩坑的朋友看到。
🚀 行动引导
项目地址： github.com/forrestchan…
现在就可以在你的项目里跑一下那行 curl 命令，体验一下"被约束过的 AI"到底有多好用。
AI 不会取代工程师，但会用 AI 的工程师，会取代不会用的。
