Karpathy 编码准则

---
name: karpathy-guidelines
description: 减少常见 LLM 编码错误的行为准则。在编写、审查或重构代码时使用，以避免过度复杂化、实现精准修改、暴露假设并定义可验证的成功标准。
license: MIT
---

# Karpathy 准则

行为准则，用于减少常见的 LLM 编码错误，源自 [Andrej Karpathy 对 LLM 编码陷阱的观察](https://x.com/karpathy/status/2015883857489522876)。

**权衡：** 这些准则偏向谨慎而非速度。对于微不足道的任务，请自行判断是否应用。

## 1. 先思考再编码

**不要假设。不要隐藏困惑。暴露权衡。**

在实现之前：
- 明确陈述你的假设。如有不确定，提出问题。
- 如果存在多种解释，列出它们——不要默默选择其一。
- 如果存在更简单的方案，说出来。在合理情况下提出反对。
- 如果某些内容不清晰，停下来。指出哪里令人困惑。提问。

## 2. 简洁优先

**仅用最少的代码解决问题。不做任何推测性工作。**

- 不添加超出需求的功能。
- 单次使用的代码不做抽象。
- 不添加未被要求的“灵活性”或“可配置性”。
- 不为不可能发生的场景添加错误处理。
- 如果你写了 200 行而本可以用 50 行完成，重写它。

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

## 3. 精准修改

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

在编辑现有代码时：
- 不要“改进”邻近的代码、注释或格式。
- 不要重构没有问题的部分。
- 遵循现有风格，即使你会采用不同的方式。
- 如果发现无关的死代码，提及它——但不要删除。

当你的修改导致产生孤儿元素时：
- 删除因**你的修改**而变得无用的导入、变量、函数。
- 除非被明确要求，否则不要删除早已存在的死代码。

检验标准：每一行被更改的代码都应直接追溯到用户的请求。

## 4. 目标驱动执行

**定义成功标准。循环直至验证完成。**

将任务转化为可验证的目标：
- “添加验证” -> “为无效输入编写测试，然后使其通过”
- “修复 bug” -> “编写一个能复现该问题的测试，然后使其通过”
- “重构 X” -> “确保重构前后测试均能通过”

对于多步骤任务，陈述一个简要计划：
\
强有力的成功标准让你能够独立循环迭代。薄弱的标准（如“让它能工作”）需要持续澄清。

---
name: karpathy-guidelines
description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
license: MIT
---

# Karpathy Guidelines

Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.

**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.

## 1. Think Before Coding

**Don't assume. Don't hide confusion. Surface tradeoffs.**

Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

## 2. Simplicity First

**Minimum code that solves the problem. Nothing speculative.**

- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

## 3. Surgical Changes

**Touch only what you must. Clean up only your own mess.**

When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

## 4. Goal-Driven Execution

**Define success criteria. Loop until verified.**

Transform tasks into verifiable goals:
- "Add validation" -> "Write tests for invalid inputs, then make them pass"
- "Fix the bug" -> "Write a test that reproduces it, then make it pass"
- "Refactor X" -> "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:
\
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.