夜雨聆风当AI学会"三思而后行"：Karpathy的CLAUDE.md如何重写LLM编程法则
2026年1月，一个名为
andrej-karpathy-skills的GitHub项目悄然上线。它只有一个CLAUDE.md文件，却在四个月内收获了54,000+星标。这不是一个新的AI模型，也不是一个突破性算法，而是对"如何让AI更好地写代码"这一问题的深刻反思。
一、当AI编程遇到"中年危机"
2025年，AI编程助手已经无处不在。GitHub Copilot、Cursor、Claude Code、Replit Agent——这些工具让编码效率提升了数倍。但在狂欢背后，一位AI领域的重量级人物看到了隐忧。
Andrej Karpathy，前Tesla AI总监、OpenAI创始成员，在X（Twitter）上发出了振聋发聩的观察：
"模型会代表你做出错误的假设，然后不加检查地运行下去。它们不管理自己的困惑，不寻求澄清，不暴露不一致，不展示权衡，不应该推回时也不推回。"
"它们真的喜欢让代码和API过度复杂化，膨胀抽象，不清理死代码……在100行就能解决的情况下，实现了超过1000行的臃肿结构。"
"它们有时仍会更改/删除它们不充分理解的注释和代码，即使这与任务正交，也会产生副作用。"
这三句话，精准击中了LLM编程的三大顽疾：
错误假设 - 默默做出错误选择并执行 过度工程化 - 倾向于复杂化而非简化 副作用修改 - 碰了不该碰的代码
Karpathy的观察不是空谈。作为AI领域的顶级实践者，他在Tesla Autopilot、OpenAI GPT等项目中的经验，让他对LLM的能力边界有着深刻理解。
二、一个CLAUDE.md文件，四条原则
andrej-karpathy-skills项目的核心，只有一个CLAUDE.md文件，但包含了四条直击要害的原则：
原则1：Think Before Coding（先思考再编码）
核心：不要假设，不要隐藏困惑，暴露权衡。
LLM倾向于在存在歧义时默默选择一个解释，然后沿着这个错误假设一路狂奔。这个原则要求：
✅ 明确陈述假设 - 如果不确定，就问 ✅ 提供多种解释 - 存在歧义时不要默默选择 ✅ 推回建议 - 如果有更简单的方法，说出来 ✅ 困惑时停止 - 指出不清晰的地方，请求澄清
实例：
用户：添加用户认证
LLM（默认）：默默选择JWT方案，开始实现
LLM（应用原则1）：我注意到"用户认证"有多种实现方式：
1. JWT tokens - 适合分布式系统
2. Session cookies - 适合单体应用
3. OAuth - 适合第三方登录
你的应用是什么架构？这将决定最佳方案。
原则2：Simplicity First（简单优先）
核心：用最少的代码解决问题。不要投机性代码。
LLM有过度工程化的倾向——为了"灵活性"而添加不需要的抽象，为了"健壮性"而处理不可能发生的错误。这个原则要求：
❌ 不要超出需求的特性 ❌ 不要为单次使用创建抽象 ❌ 不要添加未请求的"灵活性"或"可配置性" ❌ 不要为不可能的场景处理错误 ✅ 如果200行可以变成50行，重写它
测试标准：
"高级工程师会说这太复杂了吗？如果是，简化它。"
实例：
❌ 过度工程化
- 创建了AuthenticationStrategy接口
- 实现了JWTAuthStrategy、SessionAuthStrategy
- 添加了AuthStrategyFactory
- 引入了策略模式"以便未来扩展"
✅ 简单优先
- 直接实现JWT认证
- 一个文件，50行代码
- 满足当前需求
原则3：Surgical Changes（外科手术式修改）
核心：只触碰必须的。只清理自己的混乱。
LLM有时会"顺手"修改相邻代码、重构不相关的部分，或者删除它认为不必要的代码。这个原则要求：
当编辑现有代码时：
❌ 不要"改进"相邻的代码、注释或格式 ❌ 不要重构未损坏的部分 ✅ 匹配现有风格，即使你会用不同方式 ✅ 如果注意到无关的死代码，提及它 - 不要删除它
当你的更改产生孤立代码时：
✅ 删除你的更改导致未使用的导入/变量/函数 ❌ 除非被要求，否则不要删除预先存在的死代码
测试标准：
"每个更改的行都应该直接追溯到用户的请求。"
原则4：Goal-Driven Execution（目标驱动执行）
核心：定义成功标准。循环直到验证。
将命令式任务转换为可验证的目标：
| 原指令 | 转换后 |
|---|---|
| "添加验证" | "为无效输入编写测试，然后使它们通过" |
| "修复bug" | "编写重现它的测试，然后使它通过" |
| "重构X" | "确保之前和之后测试都通过" |
对于多步骤任务：
1. [步骤] → 验证：[检查]
2. [步骤] → 验证：[检查]
3. [步骤] → 验证：[检查]
Karpathy的名言：
"LLMs exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."
三、为什么有效？技术洞察
3.1 显式推理强制
LLM在处理歧义时倾向于"默默选择一个解释然后运行"。Think Before Coding原则强制显式推理，将隐式假设转化为显式讨论。
这就像是给LLM装了一个"刹车装置"——在加速之前先确认方向。
3.2 最小化原则
Simplicity First对抗的是LLM的"过度泛化倾向"。LLM训练数据中有大量"最佳实践"代码，这些代码往往包含为未来扩展设计的抽象。但LLM错误地将这种模式应用到所有场景。
这个原则提醒AI：**YAGNI（You Aren't Gonna Need It）**在AI编程中同样适用。
3.3 可追溯性
Surgical Changes确保每个代码改动都可以追溯到用户请求，减少了"路过式重构"（drive-by refactoring）。
这就像是要求外科医生：只切除肿瘤，不要顺便做个整容手术。
3.4 验证循环
Goal-Driven Execution将命令式编程转换为声明式目标。这本质上是TDD（测试驱动开发）的LLM版本——先定义成功标准，再实现。
Karpathy的洞察是：LLM擅长"循环直到满足特定目标"，但弱点是理解模糊指令。将模糊指令转化为可验证目标，就扬长避短了。
四、生态影响：从CLAUDE.md到技能体系
andrej-karpathy-skills项目引发了连锁反应。在GitHub上，出现了多个基于Karpathy方法论的衍生项目：
Karpathy Wiki - 构建持久、复合的知识库 Claude Autoresearch Skill - 自主目标导向迭代 LLM Wiki - LLM维护的个人wiki技能 Codex Autoresearch Skill - 自导向迭代系统（Modify → Verify → Keep/Discard）
这些项目共同构成了一个"AI辅助编程方法论"生态。
五、实战应用：对你的启发
基于你的"AI应用能力地图"和"AI媒体生产线"，这些原则有直接应用价值：
5.1 多Agent协作规范
你正在构建的多Agent系统（如18个投资大师AI Agent）可以应用类似的行为准则：
Agent间不默默假设，要明确陈述 避免过度复杂的多层抽象 每个Agent只修改自己的输出，不触碰其他Agent 定义明确的成功标准（如"风险评分低于X"）
5.2 内容生成质量保证
Goal-Driven Execution可直接应用于文章生成：
| 原指令 | 转换后 |
|---|---|
| "写一篇AI文章" | "1. 搜索Hacker News获取热点 → 验证：3个候选话题 2. 选择最有潜力的 → 验证：数据支撑充足 3. 生成3000字深度文章 → 验证：有数据、有洞察、有观点" |
这与你当前的"AI媒体生产线"高度契合。
5.3 技能开发标准
在开发OpenClaw技能时，应用Simplicity First原则：
避免为"未来扩展"添加不必要的抽象 每个技能只做一件事，做好它 50行能解决的，不要写成200行
六、争议与权衡
重要说明：
这些指南偏向谨慎而非速度。对于琐碎任务（简单的错别字修复、明显的单行代码），使用判断力 - 并非每个更改都需要完整的严格性。
目标：减少非平凡工作中代价高昂的错误，而不是减慢简单任务。
这个权衡是明智的。不是每次改代码都要经历完整的"思考-验证-确认"流程。但涉及到架构决策、复杂重构、多文件修改时，这些原则能避免灾难性错误。
七、如何使用
方法1：Claude Code插件（推荐）
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
方法2：项目级CLAUDE.md
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
方法3：与项目特定规则合并
## Project-Specific Guidelines
- Use TypeScript strict mode
- All API endpoints must have tests
- Follow the existing error handling patterns in `src/utils/errors.ts`
八、效果验证
这些指南正在工作，如果看到：
✅ 差异中不必要的更改更少 - 只出现请求的更改 ✅ 因过度复杂化而重写更少 - 代码第一次就简单 ✅ 实施前提出澄清问题 - 而不是犯错后 ✅ 干净、最小的PR - 没有路过式重构或"改进"
九、未来展望：从CLAUDE.md到AI协议
andrej-karpathy-skills项目的深远意义在于：它开启了"AI行为协议"的讨论。
正如HTTP协议让不同计算机能够协作，未来可能需要"AI Agent交互协议"：
如何陈述假设？ 如何推回不合理请求？ 如何验证成功？ 如何在Agent间传递上下文？
这个CLAUDE.md文件，可能是未来AI行为规范的一个雏形。
十、结语
54,000+星标的背后，是开发者社区对"更好的AI编程体验"的渴望。
Andrej Karpathy用四条简单原则，解决了LLM编程的三大顽疾。这不仅是技术技巧，更是一种哲学：在AI时代，简单胜过复杂，明确胜过隐晦，验证胜过假设。
正如Karpathy所说：
"Don't tell it what to do, give it success criteria and watch it go."
这或许就是AI编程的未来：不是让AI更聪明，而是让我们更懂得如何与AI协作。
数据来源：
GitHub: https://github.com/forrestchang/andrej-karpathy-skills Andrej Karpathy's X: https://x.com/karpathy/status/2015883857489522876
