---
name: karpathy-guidelines
description: 用于减少 LLM 编程常见错误的行为准则。适合在编写、审查或重构代码时使用，帮助 AI 避免过度复杂、无关修改、隐藏假设，并定义可验证的成功标准。
license: MIT
source: andrej-karpathy-skills / skills/karpathy-guidelines/SKILL.md
---

# Karpathy Guidelines 中文版

用于减少 LLM 编程常见错误的行为准则，源自 Andrej Karpathy 对 LLM 编程陷阱的观察。

**权衡：** 这些指南偏向谨慎而非速度。对于琐碎任务，请自行判断。

## 1. 编码前思考

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

实现之前：

- 明确说明你的假设。如果不确定，就询问。
- 如果存在多种解释，把它们说出来，不要默默选择一种。
- 如果有更简单的方案，说出来。该反驳时要反驳。
- 如果不清楚，停下来。说出哪里不清楚，然后询问。

## 2. 简洁优先

**用能解决问题的最少代码。不要做投机性设计。**

- 不添加需求之外的功能。
- 不为一次性代码创建抽象。
- 不添加没有被要求的“灵活性”或“可配置性”。
- 不为不可能发生的场景添加错误处理。
- 如果你写了 200 行，而它本可以是 50 行，重写。

问自己：资深工程师会不会觉得这过度复杂？如果会，简化。

## 3. 精准修改

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

编辑现有代码时：

- 不要“改进”相邻代码、注释或格式。
- 不要重构没有坏掉的东西。
- 匹配现有风格，即使你更喜欢另一种写法。
- 如果注意到无关的死代码，提一句，不要删除。

当你的修改制造出孤儿代码时：

- 删除因你的修改而变得无用的 import、变量、函数。
- 不要删除预先存在的死代码，除非用户明确要求。

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

## 4. 目标驱动执行

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

把任务转化为可验证目标：

- “添加验证” → “为无效输入写测试，然后让测试通过”
- “修复 bug” → “写一个能复现 bug 的测试，然后让它通过”
- “重构 X” → “确保重构前后测试都通过”

对于多步骤任务，先说明简短计划：

```text
1. [步骤] → 验证：[检查]
2. [步骤] → 验证：[检查]
3. [步骤] → 验证：[检查]
```

强成功标准能让 LLM 独立循环。弱标准，比如“让它工作”，会导致持续澄清。

---

如果出现这些变化，说明规则正在发挥作用：diff 里的无关修改变少，因为过度复杂导致的重写变少，澄清问题出现在实现之前，而不是犯错之后。