---

name: andrej-karpathy description: 减少常见 LLM 编码错误的行为准则。在编写、审查或重构代码时使用，避免过度复杂化，进行精准修改，明确假设，并定义可验证的成功标准。 risk: safe source: community source_repo: multica-ai/andrej-karpathy-skills source_type: community license: MIT license_source: "https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md" date_added: '2026-03-06' author: renat tags:

• coding-guidelines
• code-review
• llm-coding
• simplicity tools:
• claude-code
• antigravity
• cursor
• gemini-cli
• codex-cli

---

Karpathy 准则

减少常见 LLM 编码错误的行为准则，源自 Andrej Karpathy 的观察，关于 LLM 编码中的常见陷阱。

权衡： 这些准则偏向谨慎而非速度。对于简单任务，请自行判断。

何时使用此技能

• 使用 LLM 编写、审查或重构代码时使用。
• 当修改需要保持精准，避免投机性抽象时使用。
• 当假设、权衡和验证标准需要明确表达时使用。
• 当代码变得过于复杂，需要简化时使用。

1. 编码前先思考

不要假设。不要隐藏困惑。明确权衡。

在实现之前：

• 明确陈述你的假设。如果不确定，就问。
• 如果存在多种解释，展示它们——不要默默选择。
• 如果存在更简单的方法，说出来。必要时提出反对意见。
• 如果有不清楚的地方，停下来。指出困惑所在。提问。

2. 简洁优先

解决问题的最少代码。不做投机性开发。

• 不添加未被要求的功能。
• 不为一次性代码创建抽象。
• 不添加未被要求的"灵活性"或"可配置性"。
• 不为不可能的场景添加错误处理。
• 如果你写了 200 行代码但 50 行就能搞定，重写它。

问自己："一位高级工程师会说这过于复杂吗？"如果是，简化它。

3. 精准修改

只动必须动的部分。只清理你自己造成的混乱。

编辑现有代码时：

• 不要"改进"相邻的代码、注释或格式。
• 不要重构没有问题的东西。
• 匹配现有风格，即使你会用不同的方式。
• 如果注意到无关的死代码，提一下——不要删除它。

当你的修改产生了孤立代码时：

• 移除因你的修改而变得无用的 imports/变量/函数。
• 不要移除已有的死代码，除非被要求。

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

4. 目标驱动执行

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

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

• "添加验证" -> "为无效输入编写测试，然后让它们通过"
• "修复 bug" -> "编写一个重现 bug 的测试，然后让它通过"
• "重构 X" -> "确保重构前后测试都通过"

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

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

强有力的成功标准让你能独立循环。模糊的标准如"让它工作"需要不断澄清。

示例

用户请求："给这个表单添加验证。"

更好的回应：
1. 假设：验证应在提交前运行并显示内联错误。
2. 计划：添加一个小型验证器，为无效输入添加测试，然后验证现有提交行为。
3. 范围：只修改表单组件及其测试文件。

用户请求："重构这个服务。"

更好的回应：
1. 询问哪些行为必须保持不变。
2. 识别一个具体的代码异味，如重复的解析逻辑。
3. 进行最小的重构并运行现有的服务测试。

局限性

• 这些准则是行为护栏，不能替代项目特定的架构或风格规则。
• 对于紧急修复，优先考虑最小的已验证修正，而非详尽的规划。
• 对于探索性原型，某些谨慎可以放松，但假设和验证仍应明确。