Karpathy 编码准则

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

1. 先想后写

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

开始实现前：

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

2. 简洁优先

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

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

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

3. 精准修改

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

编辑已有代码时：

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

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

• 删除由你的改动导致不再使用的 import / 变量 / 函数。
• 不要删除改动前就存在的死代码，除非被要求。

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

4. 目标驱动执行

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

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

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

对于多步骤任务，先给出简要计划：

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

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