Claude Code 行为优化指南：Andrej Karpathy 的四大原则

一个困扰所有 Claude Code 用户的问题

你让 Claude Code 做一个简单的改动。

它不仅改了，还：

  • 「顺便」重构了相邻的代码
  • 「顺便」改了注释和格式
  • 「顺便」加了一堆你没要求的 error handling
  • 「顺便」把一个简单函数写成了 1000 行的「通用方案」

结果你的 PR diff 一看，改了 200 行，但你只要求改 10 行。

🎯 为什么会这样？

Andrej Karpathy（Tesla AI 负责人）最近发了一条很火的推文，直指 LLM 编程的核心问题：

"模型会代表你做出错误的假设，然后就一直跟着这个假设走。
它们不管理自己的困惑，不寻求澄清，不表达矛盾，不提出权衡，
该反推的时候也不反推。

它们特别喜欢把代码复杂化，加很多不必要的抽象，
不清理死代码...用 1000 行实现一个 100 行就能做的东西。

它们还会随意改/删自己不完全理解的代码，
即使这些改动和你的任务毫无关系。"

这就是问题的根源。

💡 解决方案：一个文件 + 四个原则

有个开发者叫 Forrest Chang，他基于 Karpathy 的观察，创建了一个项目：

andrej-karpathy-skills — 一个 CLAUDE.md 文件，包含 4 个原则，直接地址这些问题。

这 4 个原则改变了 Claude Code 的行为方式。

🧠 四大原则详解

原则 1：思考优于编码（Think Before Coding）

问题： Claude 默默选择一个理解方式，然后执行。你说「加个验证」，它猜你的意思，然后就跑了。

解决方案： 强制明确陈述。

给 Claude Code 的指令要包含：
✅ 明确陈述你的假设 — 而不是让它猜
✅ 如果有多个理解方式，列出来 — 而不是默默选择
✅ 如果它有更简单的想法，让它说出来 — 而不是硬来
✅ 卡住了就问，不要硬猜

例子：

❌ 错误：「加个输入验证」 ✅ 正确：「写测试验证不合法输入（比如空字符串、负数、超长字符串），然后添加代码让这些测试通过」

原则 2：简化优先（Simplicity First）

问题： Claude 倾向于过度工程化。给它一个简单需求，它设计了一个可扩展的、可配置的、支持 10 种场景的系统。

解决方案： 最小化代码。只做被要求的事。

✅ 最小化代码 — 没有你没要求的功能
✅ 没有单用场景的抽象 — 代码不重复就不抽象
✅ 没有请求外的「灵活性」 — 不提前为了假想的需求设计
✅ 不处理不可能的错误 — 不要为你永远不会遇到的情况 error handle

测试标准： 一个资深工程师看这段代码，会不会说「这太复杂了」？

如果会 → 重写得更简单。

例子：

❌ 500 行的通用数据验证系统（支持 schema、async、custom rules…） ✅ 50 行的特定需求验证（精确处理这个用例）

原则 3：手术级修改（Surgical Changes）

问题： Claude 改代码时，不小心就改了不相关的东西。改了一个函数，连带改了：

  • 函数旁边的代码
  • 注释
  • 格式
  • 甚至删了一些「看起来像死代码」的东西

解决方案： 只改必须改的。

当编辑现有代码：
✅ 不改进相邻代码（即使你看着难受）
✅ 不重构没坏的东西
✅ 匹配现有风格（即使你觉得它不好）
✅ 看到无关死代码？指出来别删

当你的改动创造了孤立代码：
✅ 删除你的改动导致的无用 imports/variables/functions
✅ 不删除原有的死代码（除非被要求）

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

例子：

❌ 改动 diff

1
2
3
4
5
6
7
8

- function validateEmail(email) {
+ function validateEmail(email) {
    if (!email) return false;
+   // Better formatting
+   const parts = email.split('@');
+   // Refactored to be more readable
    return email.includes('@');
  }

✅ 改动 diff

1
2
3
4
5

- function validateEmail(email) {
+ function validateEmail(email) {
    if (!email) return false;
    return email.includes('@');
  }

原则 4：目标驱动执行（Goal-Driven Execution）

问题： 模糊的指令导致模糊的执行。

解决方案： 定义可验证的成功标准，让 Claude 自动循环。

命令式（模糊）vs 声明式（清晰）：

❌ 「加个验证」
✅ 「写测试验证不合法输入，然后使测试通过」

❌ 「修这个 bug」
✅ 「写一个测试再现这个 bug，然后修改代码使测试通过」

❌ 「重构 X」
✅ 「确保重构前后测试都通过」

多步骤任务的做法：

1. [第一步] → 验证: [具体检查点]
2. [第二步] → 验证: [具体检查点]
3. [第三步] → 验证: [具体检查点]

关键优势： 清晰的成功标准让 Claude 可以独立循环到达目标，你不用一步步指挥。

🚀 怎么使用？

方案 A：Claude Code 插件（推荐）

最简单，一次安装，所有项目可用。

在 Claude Code 中运行：

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

✅ 完成。现在你所有项目都有这个指南了。

方案 B：项目级 CLAUDE.md

灵活，可以加入项目特定规则。

新项目：

1

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

现有项目（追加）：

1
2

echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

✅ 完成。Claude Code 会自动读取。

📊 效果有多明显？

用了这个指南后，你应该看到：

✅ Diff 更干净 — 只有你要求的改动，没有「顺便改」 ✅ 代码第一次就简洁 — 不再是 1000 行可用方案 ✅ 澄清问题提前出现 — Claude 先问，不是后悔 ✅ PR 更小更精 — 没有「我顺便还改了…」

真实对比：

❌ 没有指南：

你：修复这个 bug
Claude：我检查了... 这个地方有问题。
        顺便我还改了函数名、重写了注释、加了新的 error handling...
        
你的反应：❌ 等等，我只要你改 bug！

✅ 用了指南：

你：修复这个 bug（症状是 X，位置是 Y 函数）
Claude：让我确认：假设是 Z 吗？还是可能是 W？

你：是 Z

Claude：好，我写一个测试再现这个 bug...
        现在修复...
        ✓ 测试通过
        
你的反应：✅ 完美。只改了需要改的。

🎯 和你的项目结合

如果你已经有 CLAUDE.md，直接加入项目特定规则：

1
2
3
4
5
6
7

## Project-Specific Guidelines

- 使用 TypeScript strict mode
- 所有 API 端点必须有对应测试
- 遵循 src/utils/errors.ts 的错误处理模式
- 数据库查询必须用参数化查询（防 SQL 注入）
- 不改动 src/legacy 目录（它是维护模式）

Claude 会同时遵循通用原则和你的项目规则。

⚡ 什么时候「放松标准」？

这个指南偏向谨慎。对于非常简单的任务（typo 修复、明显的一行改动），用判断别太严格。

目标是：减少复杂工作的代价性错误，不是拖慢简单任务。

💬 Andrej 的关键洞察

“LLMs 特别擅长在循环中迭代直到达到特定的目标… 不要告诉它做什么，给它成功标准，然后看它去。”

这就是「目标驱动执行」的本质。

与其命令式指挥（做这个、做那个），不如声明式目标（达到这个状态），让 AI 自动找路。

📈 总结

指标说明
安装难度⭐ 1 分钟（插件）
学习成本⭐ 低（只需理解 4 个原则）
实际收益⭐⭐⭐⭐⭐ 巨大（干净代码、少返工）
适用范围⭐⭐⭐⭐⭐ 所有 Claude Code 项目

🎯 立即开始

  1. 今天： 装上插件（1 分钟）
  2. 明天： 在你的重点项目加上项目级 CLAUDE.md
  3. 观察： PR 质量的改变

这个东西特别值得用。如果你经常用 Claude Code，这会显著改善你的工作流。

关键：不是 Claude Code 变好了，而是你更清楚地告诉它你想要什么。