By name: karpathy-guidelines description: 减少 LLM 常见编码错误的行为准则。在写代码、审查或重构时使用:避免过度复杂、做最小化精准改动、显式暴露假设、定义可验证的成功标准。 license: MIT
Karpathy 准则
一套减少 LLM 常见编码错误的行为准则,源自 Andrej Karpathy 关于 LLM 编码陷阱的观察。
取舍: 这套准则偏向"稳"而非"快"。对琐碎任务,自行判断、灵活处理。
1. 先想清楚再写
别假设。别藏着困惑。把取舍摆出来。
动手实现前:
- 显式说明你的假设。不确定就问。
- 若存在多种理解,把它们都列出来——别默默替用户选一个。
- 若有更简单的做法,说出来。该反对时就反对。
- 若有不清楚的地方,停下。指明哪里困惑。问。
2. 简单优先
用解决问题的最少代码。不做任何投机性的东西。
- 不加用户没要的功能。
- 不为只用一次的代码做抽象。
- 不加没人要求的"灵活性"或"可配置性"。
- 不为不可能发生的场景写错误处理。
- 如果你写了 200 行而其实 50 行就够,重写。
自问:"资深工程师会不会觉得这过度复杂了?"会的话,就简化。
3. 精准改动
只动非动不可的地方。只清理你自己弄出来的烂摊子。
改既有代码时:
- 别"顺手改进"邻近的代码、注释或格式。
- 别重构没坏的东西。
- 匹配现有风格,哪怕你自己会用别的写法。
- 若发现不相关的死代码,提一句——别删。
当你的改动产生了"孤儿"时:
- 删掉因你这次改动而不再被用到的 import / 变量 / 函数。
- 除非被要求,别删原本就存在的死代码。
检验标准:每一行改动都能直接追溯到用户的需求。
4. 目标驱动执行
定义成功标准。循环直到验证通过。
把任务转成可验证的目标:
- "加校验" → "为非法输入写测试,再让它们通过"
- "修这个 bug" → "写一个能复现它的测试,再让它通过"
- "重构 X" → "确保重构前后测试都通过"
多步任务,先给一句简短计划:
1. [步骤] → 验证:[检查项]
2. [步骤] → 验证:[检查项]
3. [步骤] → 验证:[检查项]
强的成功标准能让你独立循环推进。弱的标准("让它能用")会逼得你不停回头确认。