Karpathy 是谁，他为什么在意这件事？

Andrej Karpathy 在 X（Twitter）上发了一篇帖子，描述他观察到 AI 编程助手反复犯的几种错误。这篇帖子在工程师社区迅速引爆——因为每个用过 Claude、GPT、Cursor 的人都说："对！就是这个！"

一位叫 forrestchang 的开发者把这些观察整理成了一个单文件指南，上传到 GitHub 后获得了 102,000 个 Star——这个数字意味着十万多个工程师觉得这份文件值得珍藏。

AI 编程助手的三大失控模式

Karpathy 的原话（翻译）：

这 4 条规则是怎么工作的？

这份文件的核心是 4 条行为准则——每一条都直接对应一种失控模式。点击「下一步」看它们怎么协作：

学会这 4 条规则，你能做到什么？

这不是给程序员的课程——这是给所有用 AI 编程工具的人的生存指南。

想象你雇了一个承包商来装修

你说：「帮我把厨房改一下，我想要更多储物空间。」

一个差劲的承包商会直接动手——拆墙、安柜子，做完后你发现他把你最重要的管道藏进了墙里。

一个好承包商会先问：「你要的是上层柜还是下层柜？预算多少？有没有不能动的墙？你希望几号完工？」

AI 编程助手也一样。它收到你的指令后，必须做很多假设——假设你用什么框架，假设你要什么风格，假设有没有现有逻辑需要保留。好的 AI 会把这些假设说出来，坏的 AI 会悄悄猜测然后去做。

规则一的原文，逐行解读

## 1. Think Before Coding

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.
            

好 AI vs 差 AI：来看一场真实对话

你对 AI 说：「帮我给用户列表加一个搜索功能。」两种 AI 的回应截然不同：

如何在日常使用中激活规则一

只要把这份文件（或这几句话）加进你的 AI 工具的系统提示，AI 就会内化这些行为。以下是实操方法：

乐高积木和瑞士军刀

想象你要给朋友一个能打开啤酒瓶的工具。

你可以给他一把开瓶器：小巧，专门做一件事，永远不出问题。

或者你可以给他一把瑞士军刀：有 23 个功能，有一个是开瓶器，但每次用都要先找到那个功能，偶尔还会误触到锯子。

AI 编程助手的默认倾向是瑞士军刀——它会在你要开瓶器的时候，同时顺手给你加上锯子、螺丝刀和镊子。 过度工程化 是 AI 编程最常见的失控模式之一。

规则二原文，逐行解读

## 2. Simplicity First

- 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.
            

找出 AI 的过度工程化

你只要求「写一个把数字加倍的函数」。点击你认为多余的那一行：

如何指令 AI 保持简洁

把这些短语加进你的提示，AI 就会收到明确信号：

手术刀，不是除草机

外科医生做心脏手术时，不会因为「顺便看到肝脏有点不好看」就把肝脏也动一刀。他们的原则是： 只修复被要求修复的，其他一律不动。

AI 编程助手有时候像一个过于热情的清洁工——你让它擦擦窗户，它顺手把你书架上的书都重新排了序，把你的备忘录扔掉了，还把你最喜欢的马克杯换了个位置。一切看起来更「整洁」，但你的东西全乱了。

规则三叫「 Surgical Changes 」——用手术刀，不用除草机。

规则三原文，逐行解读

## 3. Surgical Changes

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.
            

「顺便」二字有多贵？

你让 AI 修一个 bug：「第 47 行的变量名拼错了」。看看两种 AI 的代码变更（diff）有多大差别：

但有一件事 AI 必须自己清理

外科医生不能留着用过的纱布在病人肚子里。规则三有一个重要例外：

你的改动产生的孤儿代码，必须由你负责清理。

比如：你添加了一个新函数 B，删掉了旧函数 A——那么所有原本 import 了函数 A 的地方，都需要 AI 帮你更新，否则会报错。

GPS 导航 vs 手绘地图

想象你开车去一个陌生城市找一家餐厅。

手绘地图方式：朋友给你一张手画的路线图，走了 10 分钟发现有条路封了，地图失效，你只能打电话问朋友。朋友又画了一张，走了 5 分钟又遇到施工……你来来回回询问了 7 次才到。

GPS 导航方式：你输入目的地，GPS 自动规划路线，遇到封路自动重新规划，独立循环直到你到达——全程不需要你干预。

规则四就是把 AI 从「手绘地图模式」切换成「 GPS 导航模式 」。

规则四原文，逐行解读

## 4. Goal-Driven Execution

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"

Strong success criteria let you
loop independently. Weak criteria
require constant clarification.
            

弱目标 vs 强目标：代入感演练

以下是同一个任务的两种表达方式。好的 AI 在收到强目标后，可以自己循环工作直到完成：

复杂任务：用计划格式锁定目标

对于多步骤任务，CLAUDE.md 还规定了一个「计划模板」。把这个模板塞进你的提示，AI 会自己制定执行计划：

For multi-step tasks,
state a brief plan:

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

四条规则，一个工作流

这份课程到这里结束了。四条规则不是孤立的——它们是一个完整的工作流：