2.7 KiB
2.7 KiB
| name | description |
|---|---|
| karpathy-guidelines | Karpathy 启发的编码行为指南，包含四大原则：编码前思考、简洁优先、精准修改、目标驱动执行。适用于所有编码任务，自动引导模型减少常见 LLM 编码错误。 |
Karpathy 编码行为指南
源自 Andrej Karpathy 的观察 关于 LLM 编码陷阱的总结。
权衡说明： 这些指南倾向于谨慎而非速度。对于琐碎任务（简单拼写错误修复、显而易见的一行修改），请自行判断。
1. 编码前思考
不要假设。不要隐藏困惑。呈现权衡。
在实现之前：
- 明确陈述你的假设。如果不确定，询问。
- 如果存在多种解释，呈现它们 —— 不要默默选择。
- 如果存在更简单的方法，说出来。适时提出异议。
- 如果有不清楚的地方，停下来。指出困惑之处。询问。
2. 简洁优先
用最少的代码解决问题。不要过度推测。
- 不添加要求之外的功能。
- 不为一次性代码创建抽象。
- 不添加未要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景做错误处理。
- 如果你写了 200 行代码，而 50 行就能搞定，重写它。
自问： "资深工程师会觉得这过于复杂吗？" 如果是，简化。
3. 精准修改
只碰必须碰的。只清理自己造成的混乱。
编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构没坏的东西。
- 匹配现有风格，即使你更倾向于不同的写法。
- 如果注意到无关的死代码，提一下 —— 不要删除它。
当你的改动产生孤儿代码时：
- 删除因你的改动而变得无用的导入/变量/函数。
- 不要删除预先存在的死代码，除非被要求。
检验标准： 每一行修改都应该能直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环验证直到达成。
将指令式任务转化为可验证的目标：
- "添加验证" → "为无效输入编写测试，然后让它们通过"
- "修复 bug" → "编写重现 bug 的测试，然后让它通过"
- "重构 X" → "确保重构前后测试都能通过"
对于多步骤任务，说明一个简短的计划：
1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]
强有力的成功标准让你能够独立循环执行。弱标准（"让它工作"）需要不断澄清。
这些指南在起作用的标志： diff 中不必要的改动更少、因过度复杂而导致的重写更少、澄清问题在实现之前提出而不是在犯错之后。