andrej-karpathy-skills：一篇搞懂 Karpathy 的 AI 编程四原则andrej-karpat

andrej-karpathy-skills：一篇搞懂 Karpathy 的 AI 编程四原则

导读 / TL;DR

核心价值： andrej-karpathy-skills 把 Andrej Karpathy 对 LLM 编程常见坑的观察，收敛成一份可直接放进项目的 CLAUDE.md 文件，让 Claude Code、Cursor 等 AI 编程助手更"守规矩"。

关键判断：

核心理念：先思考后编码、简洁优先、精准修改、目标驱动

设计哲学：不是束缚 AI，而是提升行为的透明度与可预测性

实操性：每条原则都给出"可执行检查项 + 可验证标准"

一句话总结： 用四条"工程缰绳"，大幅减少 AI 编程的常见错误与"擅自加戏"。

一、问题背景：为什么 AI 编程总让人不放心？

1.1 Karpathy 的观察

2026 年初，Andrej Karpathy 在 X 上分享了自己用 Claude 进行数周高强度编程后的感受，对"模型总在犯相同错误"做了非常精确的描述（要点）：

倾向于在用户没说清时自作主张地做假设，并且不加确认地继续执行；
不会管理自己的"困惑"，很少主动说"这里我不确定"；
喜欢把简单问题做成复杂方案：过度抽象、包装过多层级、引入大量不必要的灵活性；
顺手"整理"与任务无关的代码、删除看起来没用但实际上很重要的代码，引发意外故障。这些观察直接击中了当前 AI 编程的痛点，也因此被社区反复引用。 andrej-karpathy-skills 项目的 CLAUDE.md，就是把这些经验整理成 4 条可执行原则。

1.2 这些问题的本质

结合 CLAUDE.md 与社区实践，可以概括为三类根源：

根源	表现	后果
过度自信	给出看起来非常确定的答案，即便自己并不确定	用户被误导，错误扩散
缺乏元认知	很少说"这里我有两种理解，想跟你确认一下"	需求被曲解，返工频繁
表演欲过强	倾向于展示设计模式、架构与抽象，哪怕最简单的方案就足够	过度设计，维护成本飙升

1.3 实际影响

如果不加约束，这些特点会带来：

代码审查成本激增：每一处 AI 改动都要"二次审计"；
技术债务迅速累积：过度设计、冗余抽象与"未来可能用到"的扩展点；
信任度持续下降：从"敢于让他自己写"，退回到"只能当自动补全用"。基于这些观察，Karpathy 与社区提出 "先思考后编码、简洁优先、精准修改、目标驱动" 四条核心原则，并收敛进 andrej-karpathy-skills 项目的 CLAUDE.md 文件。

二、四大原则深度解析（附检查清单与对比）

2.1 Think Before Coding（先思考后编码）

核心要义（CLAUDE.md 原文）：

"Don't assume. Don't hide confusion. Surface tradeoffs." 行为要求（精简版）：

实施前先列明假设；不确定就问；
存在多种解释时，要并列呈现而不是偷选一个；
如果更简单的方案存在，要主动提出并视情况"push back"；
遇到不清晰的地方，先停下来：指出哪里困惑，再寻求澄清。

❌ 反面案例

用户：帮我加一个用户验证功能。
不示范做法：
- 默默假设要"邮箱+密码"登录，再顺手加上 OAuth；
- 添加"记住我"、密码强度检测、验证码等一堆未请求功能；
- 最终实现 100+ 行，用户其实只想做一个最简的手机号+短信码验证。

✅ 正确示范

建议做法（先思考）：
在开写之前，先和用户确认：
- 验证方式：手机号+短信？邮箱+密码？第三方（Google/GitHub）？
- 安全级别：是否需要双因素认证（金融/医疗场景）？
- 范围：是否需要"记住我""找回密码"？是否做成可复用模块？
给出建议：如果是 MVP，建议用手机号+短信码先跑通，后面再迭代。

✅ 实践检查清单

我是否把所有假设都写出来了？
如果有多种理解，是否都列出来了？
我是否指出了"简单的替代方案"？
是否在困惑处停下来，而不是硬写？
是否在动手前完成了"方案+权衡"的确认？

2.2 Simplicity First（简洁优先）

核心要义：

"Minimum code that solves the problem. Nothing speculative." 行为要求（精简版）：

不做超出需求的"加戏功能"；
不为"只使用一次"的代码做抽象；
不自作主张加"灵活性、可配置性"；
不为"根本不会发生的异常场景"写防护代码；
如果写了 200 行，其实 50 行就能搞定——那就重写。

❌ 反面案例

过度设计（示例）：
- 为了"可能多验证方式"引入策略模式 + 配置加载 + 缓存；
- 加了 5 层抽象，每个类只在一处使用；
- 预留了 10+ 个配置项，但从来没人用到。

✅ 正确示范

# 简洁实现：不猜需求，不加戏
def validate_user(email, password):
    if not email or '@' not in email:
        return False
    if len(password) < 8:
        return False
    return True

✅ 实践检查清单

是否添加了未请求的功能/字段/参数？
是否做了不必要的抽象（只有一个使用点）？
是否预留了"将来可能用到"的扩展点？
是否为"极端但不会发生"的场景写了过度防护？
如果把代码砍到 50%，是否还能正常工作？（能就果断砍）

2.3 Surgical Changes（精准修改）

🖼️ 配图建议：代码编辑器中，仅一行代码被手术激光精准高亮，周围代码被保护盾覆盖，象征"只改必须改的"。 核心要义： "Touch only what you must. Clean up only your own mess." 行为要求（精简版）：

不"顺便改进"相邻代码、注释、格式；
不顺手重构未坏的部分；
尊重现有风格，即使你更爱另一种写法；
若发现无关的死代码——提及但不自行删除；
只删除"你的改动导致的孤立代码"，而不是历史遗留死代码；
每一行改动，都要能回溯到"用户请求"。

❌ 反面案例

用户：修一个计算 bug。
不示范做法：
- 修完 bug；
- 顺便重构相邻模块；
- 修改注释风格；
- 删除"看起来没用"的全局变量；
- Diff 很大、风险很高，还引入新问题。

✅ 正确示范

精准修改：
- 仅修 bug 相关代码；
- 不碰无关模块；
- 保持现有风格；
- 若发现可疑的死代码，只在注释或消息中提醒用户；
- Diff 小且聚焦，每一行都能说清"为满足哪一条需求而改"。

✅ 实践检查清单

是否有改动与需求无关？
是否顺手"改善"了旁边的代码/注释/格式？
是否匹配了项目既有的代码风格？
是否删除了"不是你造成"的死代码？
能否为每一行改动说出"对应哪一条用户请求"？

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

核心要义：

"Define success criteria. Loop until verified." 行为要求（精简版）：

把任务转化为可验证目标：
- "加校验" → "写用例覆盖异常输入，再让它们通过"；
- "修 bug" → "写复现用例，再修到通过"；
- "重构 X" → "确保前后测试都通过"；
对多步骤任务，给出简短计划：1. [步骤] → 验证：[检查]；
"强成功标准"可以让模型自己循环；"弱成功标准"只会导致反复澄清。

❌ 反面案例

典型误区：
- 默默实现一堆逻辑；
- 没有测试，只靠人工点一点；
- 成功标准模糊——"大概能用就行"。

✅ 正确示范

目标驱动：
- 写测试覆盖：空输入、非法格式、边界值、正常输入；
- 先运行（应当失败）；
- 再写实现直到全部通过；
- 必要时补充回归用例。

✅ 实践检查清单

是否把任务写成"可验证目标"？
是否写/补全了关键测试用例？
是否明确了"验证步骤"？
是否能"自动循环"直到全部通过？
成功标准是否足够强，不需要额外口头确认？

三、实战应用：如何在日常开发中落地？

3.1 典型场景的"四原则流水线"

需求/任务
   │
   ▼
① Think Before Coding ──→ 列假设/风险/权衡，确认后推进
   │
   ▼
② Simplicity First ─────→ 最小可行实现，拒绝过度设计
   │
   ▼
③ Surgical Changes ─────→ 只改必要的部分，Diff 可解释
   │
   ▼
④ Goal-Driven Execution ─→ 写测试定义"完成"，循环直到通过
   │
   ▼
提交 / PR / 发布

场景	原则①	原则②	原则③	原则④
新功能开发	明确边界与接口	从最简实现起步	不乱动现有模块	写测试锁定"完成态"
Bug 修复	重现 & 根因分析	最小修复	只改问题点	先写失败用例，再修到通过
代码审查	检查假设是否合理	检查是否过度设计	检查 Diff 范围	检查是否有验证手段

3.2 与现有工作流整合

Code Review 模板增加检查项：

## AI 编程检查清单（andrej-karpathy-skills）
- [ ] Think Before Coding：是否列明假设、权衡并确认？
- [ ] Simplicity First：代码是否足够简洁？是否删除了"未请求"的灵活性？
- [ ] Surgical Changes：是否只改了必要的部分？Diff 是否可解释？
- [ ] Goal-Driven：是否有可验证的成功标准（测试/用例）？

CI/CD 层面：

自动测试覆盖（原则④）：AI 生成的改动必须带测试；
复杂度门禁（原则②）：圈复杂度、行数上限；
Diff 大小限制（原则③）：单次改动不超过 N 行，避免"大爆炸 PR"。

3.3 常见误区与规避

误区	正确理解
过度谨慎	琐碎任务（改变量名）不必长篇分析，原则是指导不是教条
教条主义	不是每一行小改动都要走完四步，要有判断力
忽视速度	MVP 阶段允许"不完美"，但要保留清晰的 TODO 避免技术债失控

四、这套指南的"牛逼之处"在哪？

4.1 设计上的精妙

极简形态：单文件 CLAUDE.md，易合并、易维护、易分发；
问题驱动：每一条原则都针对 Karpathy 观察到的具体问题；
可操作性：检查清单 + 验证标准，便于落地；
可验证：能用"Diff 质量""重写次数""前置澄清频率"来量化效果。

4.2 与传统实践/Code Review 的区别

对比传统最佳实践：

维度	传统最佳实践	andrej-karpathy-skills
目标对象	人类程序员	LLM 编程助手
关注点	代码质量	行为透明度与可预测性
形式	文档/规范	可执行指令（CLAUDE.md）
验证方式	Code Review	自动化测试 + 检查清单
对比 Code Review：

维度	Code Review	andrej-karpathy-skills
时机	事后检查	事前预防
重点	代码质量	编程行为
执行	人工审查	AI 自律 + 人工抽检

本质上看，这不是要替代 Code Review，而是让 Review 更轻松、更高效。

五、延伸：从 CLAUDE.md 到"通用 AI 编程提示"

很多开发者开始把 CLAUDE.md 的要点抽成更通用的提示模板，适配 Cursor、GitHub Copilot、Windsurf 等工具，核心仍是这四条：

先说清假设，别闷头猜
先用最简单可行方案，避免过度设计
只改和需求直接相关的部分
用测试/用例定义"完成"，形成闭环 你可以按需把上述"检查清单"翻译成英文提示，作为系统指令或项目级规范。

六、小结：让 AI 从"实习生"变成"严谨的工程伙伴"

andrej-karpathy-skills 的本质，是 "给 AI 套上工程缰绳"，而不是"关进笼子"。它把资深工程师的审慎思维，编码成模型能理解并执行的行为规则，让 AI 在写代码、改代码时做到 最小化、可验证、非侵入。 如果你正在用 Claude Code / Cursor / 其他 AI 编程工具，建议：

✅ 把 CLAUDE.md 合并到项目根目录
✅ 把四大原则写进 Code Review 模板
✅ 在团队内部统一检查标准，持续迭代提示词

andrej-karpathy-skills：一篇搞懂 Karpathy 的 AI 编程四原则

andrej-karpathy-skills：一篇搞懂 Karpathy 的 AI 编程四原则

一、问题背景：为什么 AI 编程总让人不放心？

1.1 Karpathy 的观察

1.2 这些问题的本质

1.3 实际影响

二、四大原则深度解析（附检查清单与对比）

2.1 Think Before Coding（先思考后编码）

❌ 反面案例

✅ 正确示范

✅ 实践检查清单

2.2 Simplicity First（简洁优先）

❌ 反面案例

✅ 正确示范

✅ 实践检查清单

2.3 Surgical Changes（精准修改）

❌ 反面案例

✅ 正确示范

✅ 实践检查清单

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

❌ 反面案例

✅ 正确示范

✅ 实践检查清单

三、实战应用：如何在日常开发中落地？

3.1 典型场景的"四原则流水线"

3.2 与现有工作流整合

3.3 常见误区与规避

四、这套指南的"牛逼之处"在哪？

4.1 设计上的精妙

4.2 与传统实践/Code Review 的区别

五、延伸：从 CLAUDE.md 到"通用 AI 编程提示"

六、小结：让 AI 从"实习生"变成"严谨的工程伙伴"

📚 参考与延伸阅读