前言
你有没有碰到过这样的情况：让AI帮你加个功能，结果它给你来了一套策略模式+工厂模式+配置系统，300行代码解决一个5行就能搞定的问题？又或者你让它修个bug，它顺手把旁边不相关的注释、格式、变量名全”优化”了一遍，diff一片红？
这些都是大模型写代码时的典型通病。前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy发推总结过：
“模型会在你不知情的情况下做出错误假设，然后一路跑下去不做验证。它们不管理自己的困惑、不寻求澄清、不暴露矛盾、不呈现权衡、不在该推回的时候推回。”
“它们特别喜欢把代码和API搞复杂，搞膨胀的抽象，不清理死代码……100行能搞定的事非要搞出1000行来。”
开源项目 andrej-karpathy-skills 正是为了解决这个问题而生——用一个简洁的配置文件，为Claude Code/Cursor注入Karpathy的四大编码原则，让AI写出更干净、更可靠的代码。目前项目已获得10万+ Star，足见其价值。
核心功能一览
| 原则 | 针对的问题 |
|---|---|
| Think Before Coding（先想后写） | 错误假设、隐藏困惑、缺失权衡 |
| Simplicity First（简洁优先） | 过度复杂、膨胀的抽象 |
| Surgical Changes（精准修改） | 不相关的改动、动了不该动的代码 |
| Goal-Driven Execution（目标驱动） | 模糊标准、缺乏验证循环 |
四大原则详解
原则一：Think Before Coding（先想后写）
不要假设。不要隐藏困惑。呈现权衡。
大模型最常见的问题就是”默默认定一种理解然后闷头干”。这条原则强制AI在做之前先想清楚：
- 明确陈述假设 — 不确定就问，别猜
- 呈现多种理解 — 歧义存在时不要悄悄选一个
- 该推回就推回 — 如果有更简单的方案，说出来
- 困惑时停下来 — 说出哪里不明白，请求澄清
举个例子，用户说”添加用户导出功能”，AI常常默认导出所有用户、用文件方式、包含所有字段，一通操作搞出200行代码。而遵守这条原则的AI会先确认：导出范围？导出格式？包含哪些字段？数据量多大？
原则二：Simplicity First（简洁优先）
用最少的代码解决问题，不做”可能有用”的猜测性功能。
- 不要加没被要求的功能
- 不要给只用一次的代码搞抽象
- 不要加没人要的”灵活性”和”可配置性”
- 不要处理不可能发生的错误
- 如果200行能缩成50行，就重写
检验标准：一个资深工程师会说这代码过于复杂吗？如果是，就简化它。
经典反面教材：用户要一个计算折扣的函数，AI上来就是策略模式+工厂模式+配置系统+数据类，30多行才搞定。其实一个5行函数就够了：
def calculate_discount(amount: float, percent: float) -> float:
return amount * (percent / 100)
discount = calculate_discount(100.0, 10.0) # 10 off复杂度等真正需要的时候再加，而不是”以防万一”提前搞。
原则三：Surgical Changes（精准修改）
只动该动的。只清理自己造成的混乱。
编辑现有代码时：
- 不要”顺手”改进相邻的代码、注释或格式
- 不要重构没坏的东西
- 匹配已有的代码风格，哪怕你会换种写法
- 发现无关的死代码，提一嘴就行，别直接删
典型的反面案例：用户说”修复空邮箱导致崩溃的bug”，AI不仅修了bug，还顺手加了邮箱格式验证、加了用户名校验、改了注释风格、加了docstring……diff里全是无关改动。
检验标准：每一行改动都应该能直接追溯到用户的请求。
原则四：Goal-Driven Execution（目标驱动执行）
定义成功标准。循环直到验证通过。
把命令式的任务转化为可验证的目标：
| 不要这样 | 要这样 |
|---|---|
| “添加验证” | “为无效输入写测试，然后让测试通过” |
| “修复bug” | “写一个能复现bug的测试，然后让它通过” |
| “重构X” | “确保重构前后测试都通过” |
多步骤任务，先列出简要计划：
1. [步骤] -> 验证: [检查项]
2. [步骤] -> 验证: [检查项]
3. [步骤] -> 验证: [检查项]正如Karpathy所说：
“LLM非常擅长循环直到满足特定目标……不要告诉它做什么，给它成功标准，然后看它飞。”
安装使用
方式一：Claude Code 插件安装（推荐）
在Claude Code中执行以下命令：
# 先添加市场源
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 再安装插件
/plugin install andrej-karpathy-skills@karpathy-skills安装后，规则会在所有项目中自动生效。
方式二：CLAUDE.md 文件（单项目）
新项目直接下载：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md已有项目追加到现有文件：
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md方式三：Cursor 使用
项目自带了 .cursor/rules/karpathy-guidelines.mdc 规则文件，打开项目即可自动生效。
如果要在其他项目中使用，只需把该文件复制到目标项目的 .cursor/rules/ 目录下即可。
如何验证它在起作用
如果你发现以下变化，说明这些原则正在发挥效果：
- diff中的无关改动变少了 — 只有你要求的改动出现
- 因过度复杂而返工的次数变少了 — 代码一开始就是简洁的
- 澄清问题出现在实现之前 — 而不是犯错之后
- PR更干净 — 没有顺手重构或”改进”
自定义扩展
这些原则设计为可以与项目特定指令合并使用。你可以在 CLAUDE.md 中追加自己的规则：
## Project-Specific Guidelines
- 使用 TypeScript 严格模式
- 所有 API 端点必须有测试
- 遵循 src/utils/errors.ts 中的错误处理模式注意事项
这些原则偏向谨慎而非速度。对于简单的任务（改个拼写错误、明显的一行修改），请自行判断——不是每个改动都需要全套流程。
目标是在非平凡任务上减少代价高昂的错误，而不是拖慢简单任务。
总结
andrej-karpathy-skills 项目用最简单的方式——一个配置文件——解决了AI编程时代最普遍的痛点：AI乱猜、乱改、乱加复杂度。四大原则”先想后写、简洁优先、精准修改、目标驱动”直击要害，上手零成本，效果立竿见影。如果你在用Claude Code或Cursor写代码，强烈建议安装试试。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
