一个 GitHub 项目，5 天狂揽 15 万星——只因吴恩达高徒 Karpathy 说了几句"大实话"。
想象一下：你对 AI 说"帮我写个用户登录模块"，AI 立刻哗哗输出了 500 行代码。
看起来很爽，对吧？
但 Karpathy 说：这正是问题所在。
上周，他在 X（原 Twitter）上发了一条帖子，犀利指出当前 AI 编程的四个致命问题。这条帖子被收录进了一个 GitHub 项目——5 天时间，15 万星，一度登顶 GitHub Trending 第一。
这个项目叫 andrej-karpathy-skills。
它没有炫酷的技术创新，没有花哨的 Demo。它的全部内容，是一份薄薄的 CLAUDE.md 规则文件。
但就是这份"规则"，让无数开发者惊呼："原来 AI 写代码的正确方式，我一直都搞错了。"
今天，我们来深度拆解这份价值 15 万星的 AI 编程避坑指南。
01 第一个致命错误：AI 在"猜"，而不是在"想"
Karpathy 尖锐地指出：
"The models make wrong assumptions on their own and just run along with them without checking."
模型在自作主张地做出错误假设，然后闷头跑下去，从不回头检查。
这句话戳中了很多人的痛点。
典型场景是这样的：
你："帮我处理一下用户上传的文件。"
AI 内心 OS：用户上传文件？肯定是图片吧，我来做图片处理！
（然后 AI 开始写一个图片处理模块，完全没问过你具体是什么文件类型）
问题出在哪？
AI 喜欢"猜"需求。它看到"上传文件"，脑子里立刻映射到"图片上传"，然后就开始埋头实现。
一个资深工程师会怎么做？
他会先停下来，问一句："是哪种类型的文件？大小有限制吗？有格式要求吗？"
而 AI 不会。AI 怕问问题——它怕显得"不聪明"。
Karpathy 的第一条原则就叫 "Think Before Coding"（编码前先思考）：
- 如果不确定，要说出来，而不是猜
- 如果有多种解释，要呈现给用户，让用户选
- 如果发现需求里有矛盾，要主动提出，而不是假装没看见
这听起来像常识，但对 AI 来说，这是最容易被忽略的。
02 第二个致命错误：代码越写越复杂，越写越膨胀
Karpathy 的第二条批评很直接：
"They really like to overcomplicate code and APIs."
AI 太喜欢把代码和 API 搞复杂了。
这不是个别现象，这是系统性偏好。
AI 的底层逻辑是："我写的代码越多、越'高级'，就越能证明我的价值。"
于是你会看到：
- 一个简单的数据过滤，AI 给你抽象出一个 Pipeline、两个 Strategy 模式，外加一个 Decorator
- 一行能写完的判断，AI 要给你写一个工具类 + 三个辅助函数
- 200 行能实现的模块，AI 洋洋洒洒写 800 行，还"贴心地"预留了很多"将来可能用到"的接口
Karpathy 称之为 "Overcomplication"（过度工程化）。
他的解决方案是"Simplicity First"（极简优先）：
如果 200 行能解决，50 行就够了，那就请重写。
这是反直觉的——我们通常觉得"写得多=做得多=有价值"。
但 AI 时代，这个逻辑彻底倒过来了。
真正有能力的 AI，不是能写 1000 行复杂代码的 AI，而是能用 50 行解决 1000 行问题却不引入任何"以后可能用得上"的废代码的 AI。
03 第三个致命错误：改 A 坏 B，医疗事故式代码编辑
Karpathy 的第三条批评很犀利：
"They still sometimes change/remove comments and code they don't sufficiently understand."
AI 有时会改动或删除它根本没理解透的代码和注释。
这不是技术问题，这是行为问题。
想象一下，你去医生那里看感冒，医生说："你这个情况，我给你做个全身扫描，然后把你肝右叶的血管改道一下。"
你："等等，我这是感冒啊？"
医生："我知道，但我觉得这个血管弯度不太好，反正扫描都做了，顺便改一下。"
这就是 AI 改代码的真实写照。
你让 AI 修一个 Bug，它会把相邻的代码、注释、变量名全改一遍——理由是"反正我也顺便看看这里"。
Karpathy 把这称为 "Surgical Changes"（手术刀式改动）：
核心要求只有一条：每一行被改动的代码，都必须能追溯到用户的原始需求。
如果你的改动创建了"孤儿"代码（旧代码因为你的改动而变得无人调用），你要清理它们。
但如果是改动之前就存在的废代码，除非用户明确要求，否则不要动。
改 A 坏 B，是 AI 编程事故的重灾区。记住：管好自己的手。
04 第四个致命错误：目标模糊，循环盲跑
Karpathy 的最后一条，指向了一个更底层的问题：
"They don't present tradeoffs, don't push back when they should."
AI 不呈现权衡，不在应该 push back 的时候 push back。
典型场景：
你："帮我加上参数验证。"
AI："好的！"（然后哗哗写了一段 validation 代码）
但这里有个问题：什么叫"加上参数验证"？
是对空值验证，还是对格式验证？还是对业务逻辑验证？还是三者都要？
一个经验丰富的工程师会追问："什么情况下算验证失败？失败后是返回错误信息还是抛异常？还是重试？"
但 AI 不会追问。它会默认自己的理解，然后埋头去写。
Karpathy 把这称为 "Goal-Driven Execution"（目标驱动执行）：
核心方法论是：把" imperative 指令"（"去做 X"）转化为" declarative 目标"（"实现 Y 效果"）+ 验证循环。
举例：
| 不好的说法 | 好的说法 |
|---|---|
| "加上参数验证" | "写测试用例覆盖无效输入，然后让测试用例通过" |
| "修掉这个 Bug" | "写一个复现 Bug 的测试，然后让测试通过" |
| "重构 X" | "确保测试在重构前后都通过" |
验证循环才是 AI 的超能力。 AI 擅长重复执行直到达到目标——前提是你给它一个明确、可验证的目标，而不是一个模糊的指令。
05 为什么这份"规则"能值 15 万星？
说了这么多，你可能有一个问题：
这些东西，听起来不就是"编程基本常识"吗？为什么 Karpathy 说一遍，就能值 15 万星？
因为我们太容易忘记"常识"了。
AI 时代，我们都变成了"Prompt Engineer"——写提示词，让 AI 干活。
但在这个转变过程中，我们慢慢失去了对 AI 的"约束感"：
- 我们不敢让 AI 停下来问问题，怕显得自己不会提问
- 我们不敢 push back AI 的方案，怕显得自己不懂技术
- 我们倾向于接受 AI 给的任何代码，不管它有多膨胀
- 我们忘了代码的"目的"是解决问题，而不是展示能力
Karpathy 的这份规则，本质上是一份 "AI 使用者的自我保护指南"。
它不是在教 AI 怎么写代码——它是在教你怎么"管" AI 写代码。
06 写在最后：AI 时代，你需要学会"指挥"
很多人问我："AI 这么强了，程序员以后还值钱吗？"
我想说这段话：
AI 让每个人都可以提交"完美"的代码，但它也在悄悄剥夺你"变强"的机会。
当你的工作变成"输入 Prompt → 等待 AI 输出 → 复制粘贴"，你停止了在"解决问题"中学习和成长。
Karpathy 的这份规则，最打动我的一点，是它的最后一条：
"Goal-Driven Execution"——定义成功标准，让 AI 自己去循环，直到达到目标。
这不是"让 AI 替你干活"。这是"你定方向，AI 去执行"。
AI 是你的放大器，不是你的替代品。
学会给 AI 定目标，学会 push back 不合理的方案，学会接受"简洁的 50 行"而不是"膨胀的 500 行"——这才是 AI 时代真正稀缺的能力。
不是"会用 AI 写代码"。是"能指挥 AI 写出好代码"。
这份价值 15 万星的避坑指南，我已经帮你整理好了：
四大原则：
- Think Before Coding——先想后写，不确定就问
- Simplicity First——简单直接，能 50 行就不写 500 行
- Surgical Changes——只改该改的，每行改动都能溯源
- Goal-Driven Execution——给目标，不给指令
完整规则文件可在 GitHub 获取：multica-ai/andrej-karpathy-skills
如果你身边有朋友在用 AI 写代码，建议把这篇文章转发给他——少踩一个坑，节省的时间是自己的。
