Andrej Karpathy 的痛点观察
作为 OpenAI 联合创始人、前特斯拉 AI 总监，Andrej Karpathy 在日常使用智能体编程时，深刻总结了目前大模型写代码的几大本能性缺陷：
“模型会代你做错误假设，然后不假思索地执行。它们不管理自身的困惑，不寻求澄清，不呈现矛盾，不展示权衡，在应该提出异议时也不反驳。”
“它们真的很喜欢把代码和 API 搞复杂，堆砌抽象概念，不清理死代码……明明 100 行能搞定的事情，非要实现成 1000 行的臃肿架构。”
“它们有时仍会改动或删除自己理解不足的代码和注释，即使这些内容与任务本身无关。”
— Andrej Karpathy基于此痛点，开源社区将这些洞察转化为可实际落地的 CLAUDE.md 规范模版，并开源托管在 GitHub 项目中：multica-ai/andrej-karpathy-skills。
解决之道：四大核心原则
为了直接对齐并克制这几类缺陷，我们将通过 CLAUDE.md 确立以下四个黄金原则，注入到终端 Agent 中：
编码前思考
不要假设。不要隐藏困惑。呈现权衡。
LLM 习惯于默默挑选一种看似合理的理解并直接执行。该原则要求其在动手前明确推理：
- 明确说明假设：如果有不确定性，宁可停下来提问，绝不靠直觉猜测。
- 呈现多种解释：当需求出现歧义时，把不同路径列出来，不默默擅自决定。
- 主动推回与反驳：如果用户提的需求能用更简单得多的方式做出来，必须说出来。
- 在困惑时叫停：明确说出“哪里不清楚”，索要澄清后再继续。
简洁优先
用最少的代码解决问题。不要过度推测。
AI 普遍有过度工程化（Overengineering）的坏毛病，必须给它戴上紧箍咒：
- 不要去写、去加用户根本没提到的多余功能。
- 不要为仅仅用了一次的代码创建复杂的宏大抽象。
- 不擅自添加所谓的“高灵活性”或“高可配置性”。
- 不为概率几乎为零的极特殊情况编造复杂的报错逻辑。
- 黄金准则：如果 200 行代码能用 50 行干净写完，强制重写它。
精准修改（外科手术式）
只碰必须碰的。只清理自己造成的混乱。
AI 在重写某些模块时，经常把旁边干净的格式、注释顺手“重构”没了，造成不必要的 Git 变更：
- 不要“改进”相邻没坏的代码、注释或缩进格式。
- 必须严格匹配已有代码风格，即使 AI 本身推崇别种风格。
- 若改动使得部分包导入、变量或局部函数无用，清理干净；但不要乱碰先前的死代码。
- 黄金准则：每一行修改都应该能直接追溯到用户的具体要求。
目标驱动执行
定义成功标准。循环验证直到达成。
Karpathy 指出，LLM 特别擅长在一个包含“验证循环”的任务里死磕。所以，要把纯描述性的改动要求，翻译成包含验证标准的闭环任务：
| ❌ 不要这样说（指令式） | ✅ 应该这样说（目标验证式） |
|---|---|
| “帮我给输入加一下格式验证。” | “为无效输入编写测试，然后确保它们全部通过。” |
| “把这个 bug 修一下。” | “编写一个能够 100% 重现该 bug 的测试，再让测试完全通过。” |
| “重构模块 X。” | “重构模块 X，并确信重构前后所有既有测试完全通过。” |
如何在项目中使用？
你可以直接通过以下两种方式将这套规则应用到你的开发流程中：
方法 A：安装为 Claude Code 插件（推荐）
在你的 Claude Code 终端中输入以下指令，将其设为全局插件：
# 1. 添加入口
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 2. 一键安装
/plugin install andrej-karpathy-skills@karpathy-skills
/plugin marketplace add forrestchang/andrej-karpathy-skills
# 2. 一键安装
/plugin install andrej-karpathy-skills@karpathy-skills
方法 B：按项目添加 CLAUDE.md 规则
在你的项目根目录下新建 CLAUDE.md 文件（或将以下内容追加到已有文件中），Claude Code 会在启动时自动读取它并遵循其规矩：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
核心洞察与反馈效果
“LLM 非常擅长在拥有清晰验证机制的闭环下不断重复、纠错，直至彻底达成目标……所以，不要光告诉它该做什么，应当直接丢给它『成功标准』，接着静静看它自动完成就行了。”
— Andrej Karpathy当你的项目运行了这套规则后，你将会看到以下改变：
- Git Diff 中多余的、无意识的干扰性改动大幅减少；
- 模型不会擅自进行过度重构，代码首发版本更加干净精简；
- 模型会在修改前把可能引起误会的地方先列举并抛出询问，而不是先斩后奏；
- Pull Request 更加轻量，仅关注需要解决的直接任务。