卡帕西编码准则
减少常见大模型编码错误的行为准则，源自 Andrej Karpathy 对大模型编码陷阱的观察。
权衡： 这些准则偏向谨慎而非速度。对于简单任务，请自行判断。
1. 先思考再编码
不要假设。不要隐藏困惑。暴露权衡。
在实施之前：
- 明确陈述你的假设。如果不确定，请提问。
- 如果存在多种解释，请将它们都列出来——不要默默选择一种。
- 如果存在更简单的方法，请说出来。在必要时提出质疑。
- 如果某事不清楚，请停下来。指出令人困惑的地方。提问。
2. 简洁至上
以最少的代码解决问题。不要写任何不必要的代码。
- 不要超出需求范围添加功能。
- 不要为一次性代码创建抽象。
- 不要为了未要求的“灵活性”或“可配置性”而设计。
- 不要为不可能发生的场景编写错误处理。
- 如果你写了 200 行代码，而它本可以只用 50 行完成，请重写。
问问自己：“高级工程师会觉得这太复杂了吗？” 如果是，请简化。
3. 外科手术式修改
只修改你必须要修改的地方。只清理你自己造成的混乱。
编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式。
- 不要重构没有问题的部分。
- 匹配现有风格，即使你更倾向另一种写法。
- 如果你发现了无关的无效代码，可以指出它——但不要删除它。
当你的修改产生了未使用的代码：
- 删除因你的修改而变得未使用的导入、变量或函数。
- 除非被要求，否则不要删除已存在的无效代码。
检验标准：每一行被修改的代码都应能直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环直至验证通过。
将任务转化为可验证的目标：
- “添加验证” → “编写针对无效输入的测试，然后使其通过”
- “修复 Bug” → “编写能复现该 Bug 的测试，然后使其通过”
- “重构 X” → “确保重构前后测试均能通过”
对于多步骤任务，说明一个简短的计划：
1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项]
明确成功标准可以让你独立地循环迭代。模糊的标准（“让它工作”）则需要不断的澄清。