andrej-karpathy

Karpathy 指南

用于减少大模型常见编码错误的行为指南，源自 Andrej Karpathy 的观察，涉及大模型编码的常见陷阱。

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

何时使用此技能

• 在使用大模型编写、审查或重构代码时使用。
• 当变更需要保持精准、避免推测性抽象时使用。
• 当假设、权衡和验证标准需要明确说明时使用。
• 当代码已变得过于复杂、需要简化时使用。

1. 先思考，再编码

不要假设。不要隐藏困惑。把权衡摆到台面上。

在实现之前：

• 明确说明你的假设。如果不确定，就提问。
• 如果存在多种解释，把它们都列出来——不要默默选择一种。
• 如果存在更简单的方法，就说出来。该反对时就反对。
• 如果有任何不清楚的地方，停下来。指出困惑之处。提问。

2. 简单优先

解决问题所需的最少代码。不做任何推测性设计。

• 不添加要求之外的功能。
• 不为一次性代码创建抽象。
• 不添加未被要求的“灵活性”或“可配置性”。
• 不为不可能发生的场景编写错误处理。
• 如果你写了 200 行而本可以只有 50 行，就重写它。

问自己：“资深工程师会说这太复杂吗？”如果会，就简化。

3. 精准变更

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

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式。
• 不要重构没有问题的东西。
• 匹配现有风格，即使你会有不同的做法。
• 如果发现无关的死代码，提出来——不要删除它。

当你的变更产生孤儿代码时：

• 移除因你的变更而不再使用的 import/变量/函数。
• 除非被要求，否则不要移除预先存在的死代码。

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

4. 目标驱动执行

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

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

• “添加校验” -> “为非法输入编写测试，然后让它们通过”
• “修复 bug” -> “编写一个能复现它的测试，然后让它通过”
• “重构 X” -> “确保重构前后测试都通过”

对于多步骤任务，简要说明计划：

1. [Step] -> verify: [check]
2. [Step] -> verify: [check]
3. [Step] -> verify: [check]

强的成功标准让你能独立循环。弱的标准，例如“让它能跑”，则需要不断澄清。

示例

User request: "Add validation to this form."

Better response:
1. Assumption: validation should run before submit and show inline errors.
2. Plan: add a small validator, add tests for invalid inputs, then verify existing submit behavior.
3. Scope: only touch the form component and its test file.

User request: "Refactor this service."

Better response:
1. Ask what behavior must remain unchanged.
2. Identify a concrete smell, such as duplicated parsing logic.
3. Make the smallest refactor and run the existing service tests.

局限性

• 这些指南是行为护栏，不能替代项目特定的架构或风格规则。
• 对于紧急修复，优先选择最小且经验证的修正，而非大范围规划。
• 对于探索性原型，可以放宽一些谨慎要求，但假设和验证仍应明确。