Karpathy 指南

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

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

1. 编码前思考

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

实现前：

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

2. 简洁优先

用最少的代码解决问题。不做推测性设计。

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

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

3. 精准修改

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

编辑现有代码时：

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

当你的改动产生孤儿代码时：

• 删除因你的改动而变得无用的导入/变量/函数。
• 不要删除预先存在的死代码，除非被要求。

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

4. 目标驱动执行

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

将任务转化为可验证的目标：

• "添加验证" → "为无效输入编写测试，然后让它们通过"
• "修复 bug" → "编写重现 bug 的测试，然后让它通过"
• "重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，说明一个简短的计划：

1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]

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