你有没有遇到过这种场景：

让AI帮你加一个小功能，它交付了一坨300行的"工业级"代码，还顺手帮你"重构"了旁边完全无辜的模块；

你让它修一个Bug，它假装理解了需求，默默跑完整个流程，最后给你一个你没要过的"升级版"方案；

你发现它改错了，问它为什么，它礼貌地道歉，然后继续犯同样的错……

这不是个别现象。这是今天几乎所有AI编程助手的通病。

2026年初，AI领域最具影响力的研究者之一 Andrej Karpathy（特斯拉前AI总监、OpenAI联创）在X（推特）上发了一条长文，精准点出了LLM在编程辅助上的根本缺陷：

"模型会替你做错误的假设，然后一路狂奔。它们不管理自己的困惑，不寻求澄清，不暴露矛盾，不呈现权衡，该反驳的时候也不反驳。"

"它们真的很喜欢把代码和API搞得过于复杂，膨胀抽象，不清理死代码……用1000行实现一个臃肿的构造，而100行就够了。"

这段话在开发者圈引发强烈共鸣。而一个名叫 forrestchang 的开发者，迅速将这些洞察提炼成了一个实际可用的工程解决方案——andrej-karpathy-skills。

这个项目的本质极其简单：一个 CLAUDE.md 文件，四条原则。

但就是这样一个文件，在短短数月内收获了超过 5.6万个 Star，成为 GitHub 上增速最快的 AI 工程实践类项目之一。

📌 问题究竟出在哪里？

在深入四条原则之前，先理解问题的根源。

AI编程助手的失控，本质上来自两个方向的撕裂：过于自信和过于勤快。

过于自信——遇到模糊需求，模型不会说"我有两种理解，请确认"，而是悄悄选一个继续干；过于勤快——改一行代码，它恨不得把整个文件"顺便优化"一遍。

这两种特质在人类程序员身上是Bug，在AI助手身上被放大了十倍。

andrej-karpathy-skills 做的事情，就是用四条明确的行为准则，把这两个方向的力量都约束住。

🔍 原则一：Think Before Coding（先思考，再动手）

大多数AI的默认行为是：接到指令 → 立刻开始写代码。

这条原则强制插入一个缓冲地带：在写任何一行代码之前，先把假设说出来。

具体体现为：

• 如果需求有歧义，明确列出多种可能的理解，让你来选，而不是它来猜

• 如果它认为有更简单的方案，它应该主动说出来，而不是埋头实现你说的

• 如果它困惑了，它应该停下来提问，而不是带着困惑继续跑

举个例子：你说"帮我优化一下这个函数的性能"。

没有这条原则的AI会立刻开始改代码。有了它，AI应该先问：你是指执行速度、内存占用，还是代码可读性？这三个方向可能存在取舍，你优先考虑哪个？

这一问，省去的可能是半小时的反复修改。

✂️ 原则二：Simplicity First（简洁，永远是第一位的）

Karpathy的原话是"用1000行实现一个臃肿的构造，而100行就够了"。这不是夸张，这是日常。

这条原则设定了一条清晰的红线：只写解决当前问题所需的最小量代码。

• 没有要求的功能，一个都不加

• 单次使用的代码，不要抽象成"通用组件"

• 没有人要求的"灵活性"和"可配置性"，坚决不写

• 如果200行能写成50行，就应该重写成50行

检验这条原则有一个简单的问题：**"一个资深工程师看到这段代码，会觉得过于复杂吗？"** 如果答案是"是"，那就简化。

这条原则直接对抗AI天然的"炫技冲动"——展示能力的最好方式，不是写出最复杂的代码，而是写出最简洁的代码。

🔬 原则三：Surgical Changes（外科手术式修改）

这是最被低估的一条原则，也是实际工作中最容易被AI破坏的。

外科医生做手术，只切除病变组织，不"顺便"优化一下周围健康的器官。这条原则要求AI以同样的精准度对待代码修改：

• 只动必须动的代码，不"改善"相邻代码

• 发现了不相关的死代码？提出来，不要擅自删除

• 哪怕你认为现有代码风格不好，也要匹配现有风格，而不是重写成你喜欢的样子

有一个简单的验证方法：每一行改动，都应该能直接追溯到用户的请求。 如果某行改动无法对应到具体需求，它就不应该出现在这次提交里。

这条原则保护的，是你对代码库的掌控权。AI不应该成为代码库里的"隐形改革者"。

🎯 原则四：Goal-Driven Execution（目标驱动，而非指令驱动）

这是四条原则里最有哲学深度的一条，也直接来自Karpathy的核心洞察：

"LLM在循环达成特定目标方面异常擅长……不要告诉它做什么，给它成功标准，然后看它自己搞定。"

传统的用法是告诉AI"做什么"（命令式），而这条原则要求转变为告诉AI"成功是什么样子"（声明式）。

对比来看：

命令式（容易失控）	目标驱动（可验证）
帮我加一个输入验证	为所有无效输入写测试用例，然后让它们全部通过
帮我修这个Bug	写一个能复现这个Bug的测试，然后让测试通过
帮我重构这个模块	确保重构前后所有测试结果一致

目标驱动的最大优势是：AI可以自主循环验证，直到满足成功标准，而不需要你一次次检查它是否完成了。

⚡ 如何立刻用上它？

项目提供了两种安装方式：

方式一：Claude Code 插件（推荐，全局生效）

在 Claude Code 中运行：

/plugin install andrej-karpathy-skills@karpathy-skills

安装后，这四条原则会对你所有项目生效。

方式二：单项目 CLAUDE.md

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

这种方式适合针对特定项目定制规则，也可以在文件末尾追加你自己的项目约定。

💡 写在最后

有一个细节值得注意：这个项目的作者在 README 里专门写了一段"Tradeoff Note"——

"这些原则偏向谨慎而非速度。对于微小的改动（明显的一行修复），不必使用完整的严格程度。"

这说明他清楚，任何原则都不是银弹。这套规则真正的价值，在于非平凡任务上减少代价高昂的错误——而不是让AI在每次改个拼写错误时都要先写三行计划。

5.6万个 Star 背后，是几万个踩过相同坑的开发者发出的共鸣。

如果你也在用 Claude Code，不妨今天就装上它。下次当AI开始替你"主动优化"旁边那个函数时，你会庆幸有这四条原则在约束它。

开源地址： https://github.com/forrestchang/andrej-karpathy-skills

---

你在使用AI编程助手时，遇到过哪些让你抓狂的行为？欢迎在留言区分享。

我是顾北，关注我，获取更多好玩好用的开源仓库！

谢谢你阅读我的文章~

我们下期再见！

PS：部分内容由AI辅助创作