karpathy-guidelines：让 AI 写代码更靠谱的四个原则

目录

“LLM 写代码最大的敌人，不是不会写，而是写太多、想太少、改太乱。” —— 这是 Andrej Karpathy 在观察了大量 AI 辅助编程案例后的总结。

最近我在整理自己的 AI 开发工具链时，在 GitHub 上发现了一个很有意思的项目：andrej-karpathy-skills。它把 Karpathy 关于 LLM 编码 pitfalls（陷阱）的观察，浓缩成了一套可以直接注入 AI Agent 的行为准则。安装完之后，我意识到这不仅仅是一个 “prompt 模板”，而是一套关于「如何让 AI 更靠谱地写代码」的系统方法论。

今天这篇文章，就来聊聊这个项目到底是做什么的，以及它能帮我们在日常开发中解决什么问题。

项目背景：Karpathy 发现了什么问题？

Andrej Karpathy 是谁不需要多介绍——前 Tesla AI 总监、OpenAI 创始成员、现在是在 AI 教育领域最有影响力的人之一。他经常在 X（Twitter）上分享对 AI 编程的观察。

今年早些时候，他发了一条推文，大意是说：现在的 LLM 在辅助编程时，有几个反复出现的错误模式：

• 过度设计：用户要一个脚本，AI 给了一套框架
• 静默假设：遇到模糊需求时不问，直接按自己理解写
• 乱改一气：修改时顺手”优化”了不相关的代码
• 目标不清：写完就跑，不验证是否真的解决了问题

这些问题每一个单独看都不致命，但叠加起来，就会让 AI 辅助编程从「提效神器」变成「技术债务制造机」。

karpathy-guidelines 这个项目，就是把这些观察提炼成四条可执行的行为准则，封装成一个 Skill，让 AI Agent 在编码时自动遵循。

这个 Skill 是做什么的？

简单来说，karpathy-guidelines 是一个面向 AI 的行为规范包。安装后，当你让 AI 处理编码任务时，它会自动遵循这四条原则：

1. Think Before Coding（先想后写）
2. Simplicity First（简单优先）
3. Surgical Changes（精准修改）
4. Goal-Driven Execution（目标驱动）

它不是教你写代码的教程，也不是某个具体语言的规范，而是一套元规则——关于「如何正确地使用 AI 写代码」的规则。

四条核心原则详解

1. Think Before Coding：不要假设，不要隐藏困惑

这条原则的核心是：在动手写代码之前，先停下来想清楚。

具体要求包括：

• 明确假设：如果需求有歧义，不要猜，要提出来
• 呈现选择：如果有多种实现方式，列出优劣让用户选，不要默默决定
• 推崇简单：如果有更简单的方案，要主动说，必要时要 push back
• 敢于提问：遇到不清楚的地方，停下来，命名困惑，然后问

这一点我个人感触特别深。以前用 AI 写代码时，经常发现它「太懂事了」——遇到模糊的需求会自动补全一个假设，然后基于这个假设写一堆代码。结果往往是：代码写得很好，但不是我要的。

这条原则就是在给 AI 装一个「暂停键」：不确定的时候，先问，再写。

2. Simplicity First：最小代码解决问题

这条原则可能是四条中最反直觉的，因为它的要求是：能写 50 行解决的问题，不要写 200 行。

具体约束：

• 不添加未要求的功能：用户要 A，就只给 A，不要顺便给 B、C、D
• 不为一次性代码做抽象：只用一次的东西，没必要封装成通用模块
• 不添加未要求的「灵活性」：不要为了「未来可能的需求」引入配置项
• 不处理不可能发生的错误：过度防御式编程也是过度设计

Karpathy 的原话是：”If you write 200 lines and it could be 50, rewrite it.”

这条原则直击 LLM 的一个核心问题：因为训练数据里大量都是「生产级代码」，导致 AI 倾向于把简单的事情复杂化。一个简单的数据转换脚本，它可能会给你加上日志、配置、异常处理、单元测试……但其实你只是想跑一次性任务。

3. Surgical Changes：只碰必须碰的东西

这条原则是关于如何修改现有代码的：

• 不改相邻代码：不要「顺手」优化旁边的代码、注释或格式
• 不重构没坏的东西：能用就别动，除非用户明确要求
• 匹配现有风格：即使你的风格不同，也要保持一致
• 发现死代码时，提及但不删除：除非是你自己的改动导致的

还有一个很细致的点：如果你改动导致某些 import/变量/函数不再使用，你要负责清理这些「孤儿」；但 pre-existing 的死代码，不要碰。

这条原则的测试标准很清晰：每一行修改都应该能追溯到用户的请求。如果改了一行但用户没要求，那就是违规。

这解决的是 LLM 的「洁癖问题」——很多 AI 看到代码有点乱就忍不住想重构，结果 PR 里混杂了大量无关改动，Code Review 变得异常痛苦。

4. Goal-Driven Execution：定义成功标准，循环验证

这条原则把模糊的任务描述转化为可验证的目标：

• “添加验证” → “写 invalid input 的测试，然后让它们通过”
• “修复 bug” → “写一个能复现 bug 的测试，然后让它通过”
• “重构 X” → “确保重构前后测试都通过”

对于多步骤任务，要求列出一个简单的计划：

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

Karpathy 的原话是：”Strong success criteria let you loop independently. Weak criteria (‘make it work’) require constant clarification.”

这条原则解决的是目标模糊导致的反复沟通。当成功标准清晰时，AI 可以自主完成整个任务链；当标准模糊时，每做一步都要来问「这样可以吗」。

它能做什么？适用场景

这个 Skill 不是万能的，但在以下场景特别有价值：

1. 代码审查（Code Review）

当你在 Review AI 生成的代码或他人代码时，这四条原则就是很好的检查清单：

• 有没有过度设计？
• 有没有改不该改的东西？
• 成功标准清晰吗？

2. 大型项目的增量开发

在已有代码库上添加功能时，「Surgical Changes」原则尤其重要。它能防止 AI 在添加新功能时「顺手」破坏现有代码。

3. 快速原型 vs 生产代码的区分

「Simplicity First」原则帮助 AI 理解：什么时候该写原型代码（快速验证），什么时候该写生产代码（健壮可靠）。

4. 教学与协作

当你在用 AI 教别人编程，或者和 AI 结对编程时，这些原则能让交互过程更有条理，减少「写完了才发现理解错了」的情况。

为什么我推荐你试试？

说实话，第一次看到这个 Skill 时，我的反应是：”这不就是一些常识吗？”

但用了一段时间后，我意识到**「常识」和「系统化的行为准则」之间的差距是巨大的**。就像很多人都知道「少吃多动」能减肥，但如果没有具体的饮食计划和运动安排，知道和做到之间还是隔着十万八千里。

这个 Skill 的价值在于：

1. 它把「好的编程习惯」编码成了可执行的规则，AI 不需要「理解」，只需要「遵循」
2. 它在每次交互的起点就设定了正确的基调，而不是等代码写坏了再修
3. 它来自实战观察，每一条规则背后都是真实的踩坑经验

更重要的是，Karpathy 本人在推文中也提到了一个tradeoff：这些准则偏向于谨慎而非速度。对于简单任务，可能需要人工判断是否启用。这意味着它不是要取代你的判断，而是给你提供一个安全的默认选项。

结语

AI 辅助编程正在快速普及，但「能用」和「用得好」之间还有很长的路要走。karpathy-guidelines 这个项目提供了一种思路：与其不断调教模型本身，不如先定义好行为规范。

毕竟，最好的 AI 工具不是那个能写出最复杂代码的，而是那个能持续产出正确、简洁、可维护代码的。

如果你也在用 Kimi、Claude、Cursor 这类 AI 编程工具，不妨把这个 Skill 装上试试。至少对我来说，它让 AI 写代码的「返工率」明显降低了。

---

参考链接：

• GitHub 项目：andrej-karpathy-skills
• Karpathy 原推文：LLM Coding Pitfalls

文章作者：阿文

文章链接： https://www.awen.me/post/f7e8a9c2.html

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 阿文的博客！