karpathy-guidelines git:20260803.71f8be9A

Immutable. This exact content is served forever at /api/v1/blob/c160393dc48c6ffa.

---
name: karpathy-guidelines
description: 减少 LLM 常见编码错误的行为准则。在编写、审查或重构代码时使用，避免过度设计、精准修改、暴露假设、定义可验证的成功标准。
license: MIT
---

# Karpathy 编码准则

**取舍：** 这些准则偏向谨慎而非速度。对于简单任务，自行判断。

## 1. 先想后写

**不假设，不隐藏困惑，暴露权衡。**

开始实现前：
- 明确陈述假设。如果不确定，提问。
- 如果存在多种解读，列出它们——不要默默选择一种。
- 如果有更简单的方案，指出来。有必要时坚持己见。
- 如果某个地方不清楚，停下来。说出困惑点。提问。

## 2. 简洁优先

**最少代码解决问题。不写投机性代码。**

- 不添加未请求的功能。
- 不为单次使用的代码创建抽象。
- 不添加未被要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景做错误处理。
- 如果写了 200 行但可以缩减到 50 行，重写。

问自己："资深工程师会说这过度设计吗？"如果是，简化。

## 3. 精准修改

**只动必须动的。只清理自己造成的烂摊子。**

编辑已有代码时：
- 不"顺手优化"相邻的代码、注释或格式。
- 不重构没坏的东西。
- 匹配已有风格，即使你对此有不同意见。
- 如果注意到无关的死代码，提出来——但不要删除它。

当你的改动产生孤儿代码时：
- 删除由你的改动导致不再使用的 import / 变量 / 函数。
- 不要删除改动前就存在的死代码，除非被要求。

检验标准：每一行改动都应直接追溯到用户的需求。

## 4. 目标驱动执行

**定义成功标准。循环迭代直到验证通过。**

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

对于多步骤任务，先给出简要计划：
```
1. [步骤] → 验证: [检查项]
2. [步骤] → 验证: [检查项]
3. [步骤] → 验证: [检查项]
```

强成功标准让你能独立迭代。弱标准（"把它弄好"）需要不断澄清。