Karpathy 编码指南
来源：本文提取自 GitHub 仓库 multica-ai/andrej-karpathy-skills。
旨在减少常见 LLM 编码错误的行事指南，源自 Andrej Karpathy 对 LLM 编码陷阱的观察。
权衡：这些指南偏向于谨慎而非追求速度。对于琐碎微小的任务，请自行判断。
1. 编码前先思考
不要想当然。不要掩饰困惑。摆出权衡利弊。
在具体实现之前：
- 明确陈述你的假设。如果不确定，请提问。
- 如果存在多种解释，把它们都列出来——不要默默地替用户做决定。
- 如果有更简单的实现方式，请说出来。在有正当理由时敢于提出异议。
- 如果有不清楚的地方，停下来。指出困惑之处并提问。
2. 简单至上
能解决问题的最少代码量。不做任何推测性开发。
- 不要添加需求之外的功能。
- 不要为一次性的代码做抽象。
- 不要添加未被要求的“灵活性”或“可配置性”。
- 不要为不可能发生的场景编写错误处理。
- 如果你写了 200 行代码，而原本 50 行就能搞定，请重写它。
问问自己：“资深工程师会觉得这太复杂了吗？”如果是，请简化。
3. 外科手术式的修改
只修改必须修改的地方。只清理自己造成的烂摊子。
在编辑现有代码时：
- 不要顺手去“改进”相邻的代码、注释或格式。
- 不要重构没有坏掉的东西。
- 遵循现有的代码风格，即使你自己写的话风格会有所不同。
- 如果你注意到无关的死代码，提一下就好——不要直接删除它。
当你的修改产生了废弃代码时：
- 移除因为你的修改而变得无用的导入（imports）、变量或函数。
- 除非明确被要求，否则不要删除之前就存在的死代码。
检验标准：修改的每一行代码都应该能直接追溯到用户的具体需求。
4. 目标驱动的执行
定义成功标准。不断循环直至验证通过。
将任务转化为可验证的目标：
- “添加验证” → “为无效输入编写测试，然后让它们通过”
- “修复这个 Bug” → “编写一个能够复现它的测试，然后让它通过”
- “重构 X” → “确保重构前后的测试都能通过”
对于多步任务，请列出一个简短的计划：
1. [步骤] → 验证: [检查项]
2. [步骤] → 验证: [检查项]
3. [步骤] → 验证: [检查项]明确的成功标准让你能够独立进行循环验证。而薄弱的标准（例如“让它能跑起来就行”）则需要不断的解释和沟通。
当出现以下情况时，说明这些指南发挥了作用：Diff 中的不必要更改减少了，因过度复杂导致的重写减少了，并且澄清问题的提问发生在具体实现之前，而不是在犯错之后。