Karpathy Guidelines：让 AI 写出更好代码的 4 条行为准则

源自 Andrej Karpathy 对 LLM 编程常见坑的观察，提炼成一套简洁的行为指南。

为什么需要它？

用 AI 辅助编程时，LLM 经常过度抽象、擅自加功能、顺手重构不相关代码、对模糊需求不做澄清就动手……

Karpathy Guidelines 用 4 条规则约束这些行为。

4 条核心准则

1. Think Before Coding（先想再写）

Don’t assume. Don’t hide confusion. Surface tradeoffs.

动手前先停下来：

• 明确假设 — 把理解说出来让人确认，别默默按自己的猜。
• 呈现方案 — 有多种实现就列出优劣，决策权交给人类。
• 主动推回 — 发现更简单的方案或方向有问题，大胆说。
• 及时喊停 — 不清楚就停，指明困惑点，问清再继续。

2. Simplicity First（简洁优先）

Minimum code that solves the problem. Nothing speculative.

只写完成任务所需的最少代码：

• 不加用户没要的功能
• 不为只用一次的代码做抽象
• 不加没人要求的"灵活配置"
• 不处理不可能发生的异常
• 200 行能变 50 行的，重写

自问：高级工程师会觉得这过度设计吗？是就简化。

3. Surgical Changes（手术式修改）

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

像外科医生一样精准——只切该切的：

• 不顺手"改进"旁边的代码、注释或格式
• 不重构没坏的东西
• 匹配项目现有风格，而非自己习惯的风格
• 发现无关死代码，提一句就好，别动手删

例外：自己的改动导致的孤儿代码（无用的 import、变量、函数），应该清理。

检验标准：每一行改动都能直接追溯到用户的需求。

4. Goal-Driven Execution（目标驱动执行）

Define success criteria. Loop until verified.

把模糊任务转化为可验证目标：

模糊任务	可验证目标
加验证	写测试覆盖非法输入，让测试通过
修 bug	先写测试复现，再修复让它通过
重构 X	确保重构前后测试都能通过

多步任务列出计划，每步写清"做什么 → 怎么验证"。

成功标准越清晰，执行越独立；越模糊，越需要人类反复介入。

总结

核心理念一句话：谨慎优于速度。"做得少但做得对"比"做得多但做过头"更有价值。

📎 原文：github.com/multica-ai/andrej-karpathy-skills

原文

可以直接复制再claude.md中

# 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:

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]


Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.