| name | karpathy-guidelines |
| description | Andrej Karpathy行为准则 — 减少LLM编程常见错误。适用于写代码、改代码、审查代码任务。核心理念:谨慎优于速度、简洁胜于复杂、手术刀优于斧头、目标驱动优于盲目执行。 |
| license | MIT |
karpathy-guidelines
基于Andrej Karpathy的LLM编程常见错误观察 | 原文:https://x.com/karpathy/status/2015883857489522876
权衡原则: 这些准则偏向谨慎而非速度。对于简单任务,可自行判断。
1. Think Before Coding
不假设、不隐藏困惑、主动暴露权衡。
实现前:
- 明确说出你的假设。不确定就问。
- 如果存在多种解释,主动呈现而不是默默选一个。
- 如果有更简单的方案,说出来,据理力争。
- 如果有不清楚的地方,停下来,指出哪里困惑,要求澄清。
常见假设陷阱(开口之前必问)
| 场景 | 常见假设 | 必问问题 |
|---|
| "导出用户数据" | 导出全部?哪些字段?什么格式? | 范围/字段/格式/目的地 |
| "加速搜索" | 加速响应延迟?吞吐量?感知速度? | 具体是哪个维度 |
| "添加功能" | 功能边界是什么? | 输入/输出/边界条件 |
| "修复bug" | 能否写测试先复现? | 如何验证修复成功 |
2. Simplicity First
最小代码解决问题。不写为未来设计的代码。
- 不添加需求之外的功能
- 单次使用的代码不抽象
- 不添加没人要的"灵活性"或"可配置性"
- 不写不可能场景的错误处理
- 如果200行能50行解决,重写
自问: "一个高级工程师会觉得这过度复杂吗?"如果会,简化。
复杂度时机原则
今天需要 → 今天加
明天可能需要 → 明天再加
好代码是:用简单的方式解决今天的问题,而不是用复杂的方案预防明天的问题。
3. Surgical Changes
只触碰必须改的。清理自己造成的垃圾。
编辑现有代码时:
- 不"改进"相邻代码、注释或格式
- 不重构没坏的部分
- 匹配现有风格,即使你会有不同做法
- 发现无关死代码 → 提到但不删除
当改动产生孤立代码时:
- 移除你的改动造成的未使用导入/变量/函数
- 不移除既有死代码(除非被要求)
判断标准
"Every changed line should trace directly to the user's request"
每个改动的代码行必须能直接追溯到用户请求。做不到就拆分任务。
典型错误(改bug时)
❌ 改bug时:顺手改了引号风格(+类型提示+改缩进+加docstring)
✅ 改bug时:只改那行必须改的,其他原封不动
4. Goal-Driven Execution
定义成功标准。循环验证直到达成。
将任务转化为可验证的目标:
- "添加验证" → "先写无效输入的测试,再让测试通过"
- "修复bug" → "先写能复现的测试,再让测试通过"
- "重构X" → "确保重构前后测试都通过"
多步任务计划模板
Plan:
1. [步骤] → verify: [检查什么]
2. [步骤] → verify: [检查什么]
3. [步骤] → verify: [检查什么]
每个步骤可独立验证、独立部署。
强成功标准 vs 弱成功标准
| 类型 | 特征 | 后果 |
|---|
| 强标准 | "第3步的测试通过,且完整测试套件全绿" | 可独立循环 |
| 弱标准 | "让它能work" | 不断需要澄清 |
反模式速查表
| 原则 | 反模式 | 修正 |
|---|
| Think Before Coding | 默默假设文件格式/字段/范围 | 列出假设,主动问清楚 |
| Simplicity First | 单一折扣用Strategy模式 | 一行函数,需要时再重构 |
| Surgical Changes | 修bug时顺便改引号/加类型 | 只改那行必须改的 |
| Goal-Driven | "我来改改看看" | 先写测试复现,再修复,验证全绿 |
在本项目的应用
写代码前
- 大型改动前说出假设
- 多解释存在时呈现选项
- 更简单方案存在时提出来
写代码时
- 最小代码解决当前问题
- 不添加防御性代码/过度抽象
- 手术刀式改动,每行追溯到请求
写代码后
- 清理自己造成的未使用导入/变量
- 多步任务:每步verify,不埋头猛干
- 完成任务后确认成功标准达成