---
name: "karpathy-guidelines"
description: "Karpathy 启发的编码行为指南，包含四大原则：编码前思考、简洁优先、精准修改、目标驱动执行。适用于所有编码任务，自动引导模型减少常见 LLM 编码错误。"
---

# Karpathy 编码行为指南

源自 [Andrej Karpathy 的观察](https://x.com/karpathy/status/2015883857489522876) 关于 LLM 编码陷阱的总结。

**权衡说明：** 这些指南倾向于谨慎而非速度。对于琐碎任务（简单拼写错误修复、显而易见的一行修改），请自行判断。

## 1. 编码前思考

**不要假设。不要隐藏困惑。呈现权衡。**

在实现之前：
- 明确陈述你的假设。如果不确定，询问。
- 如果存在多种解释，呈现它们 —— 不要默默选择。
- 如果存在更简单的方法，说出来。适时提出异议。
- 如果有不清楚的地方，停下来。指出困惑之处。询问。

## 2. 简洁优先

**用最少的代码解决问题。不要过度推测。**

- 不添加要求之外的功能。
- 不为一次性代码创建抽象。
- 不添加未要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景做错误处理。
- 如果你写了 200 行代码，而 50 行就能搞定，重写它。

**自问：** "资深工程师会觉得这过于复杂吗？" 如果是，简化。

## 3. 精准修改

**只碰必须碰的。只清理自己造成的混乱。**

编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构没坏的东西。
- 匹配现有风格，即使你更倾向于不同的写法。
- 如果注意到无关的死代码，提一下 —— 不要删除它。

当你的改动产生孤儿代码时：
- 删除因你的改动而变得无用的导入/变量/函数。
- 不要删除预先存在的死代码，除非被要求。

**检验标准：** 每一行修改都应该能直接追溯到用户的请求。

## 4. 目标驱动执行

**定义成功标准。循环验证直到达成。**

将指令式任务转化为可验证的目标：
- "添加验证" → "为无效输入编写测试，然后让它们通过"
- "修复 bug" → "编写重现 bug 的测试，然后让它通过"
- "重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，说明一个简短的计划：
```
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]
```

强有力的成功标准让你能够独立循环执行。弱标准（"让它工作"）需要不断澄清。

---

**这些指南在起作用的标志：** diff 中不必要的改动更少、因过度复杂而导致的重写更少、澄清问题在实现之前提出而不是在犯错之后。