安德烈·卡帕斯

Karpathy 准则

一套旨在减少 LLM 常见编程错误的行为准则，源自 Andrej Karpathy 对 LLM 编程陷阱的观察。

权衡： 这些准则倾向于“谨慎”而非“速度”。对于琐碎的任务，请自行判断。

何时使用此技能

• 使用 LLM 编写、审查或重构代码时。

• 需要进行精准修改（Surgical Changes）并避免推测性抽象时。

• 需要明确假设、权衡和验证标准时。

• 代码变得过于复杂需要简化时。

1. 编码前先思考

不要假设。不要掩饰困惑。明确权衡。

在实现之前：

• 明确陈述你的假设。如果不确定，请询问。

• 如果存在多种理解方式，请全部列出——不要私自选择。

• 如果存在更简单的方法，请指出。在必要时提出异议。

• 如果有不清楚的地方，请停下来。指出困惑点并询问。

2. 简约至上

用解决问题所需的最少代码。拒绝推测性开发。

• 不要添加超出请求范围的功能。

• 不要为一次性代码创建抽象。

• 不要添加未被要求的“灵活性”或“可配置性”。

• 不要为不可能发生的场景编写错误处理。

• 如果你写了 200 行但其实 50 行就能搞定，请重写。

问自己：“资深工程师会认为这太复杂了吗？” 如果答案是肯定的，请简化。

3. 精准修改 (Surgical Changes)

仅触动必须修改的部分。仅清理自己制造的混乱。

编辑现有代码时：

• 不要“优化”相邻的代码、注释或格式。

• 不要重构没有问题的部分。

• 匹配现有风格，即使你认为有更好的写法。

• 如果发现无关的死代码，请提及它——不要直接删除。

当你的修改导致某些代码失效时：

• 删除因你的修改而变得不再需要的 import/变量/函数。

• 除非被要求，否则不要删除原有的死代码。

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

4. 目标驱动执行

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

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

• “添加验证” $\rightarrow$ “为非法输入编写测试，然后使其通过”

• “修复 Bug” $\rightarrow$ “编写能复现该 Bug 的测试，然后使其通过”

• “重构 X” $\rightarrow$ “确保重构前后测试均能通过”

对于多步骤任务，请陈述简要计划：

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

强有力的成功标准允许你独立进行迭代。而像“让它运行起来”这样模糊的标准则需要不断的沟通确认。

示例

用户请求：“给这个表单添加验证。”
更好的响应：
1. 假设：验证应在提交前运行并显示行内错误。
2. 计划：添加一个小型验证器，为非法输入添加测试，然后验证现有的提交行为。
3.

用户请求：“重构这个服务。”
更好的响应方式：
1. 询问哪些行为必须保持不变。
2. 识别具体的代码异味（smell），例如重复的解析逻辑。
3. 进行最小范围的重构，并运行现有的服务测试。

局限性

• 这些指南是行为准则，不能替代特定项目的架构或风格规范。

• 对于紧急修复，优先考虑最小且经过验证的修正，而非详尽的规划。

• 对于探索性原型，可以适当放宽限制，但假设和验证仍应明确。