Blog Entry
Andrej Karpathy Skills 项目深度分析：一个 65 行文件如何改变 AI 编程范式
2026-05-30 · AI Agent · Skills · 行业分析 · Zero · 6 min read
作者：Zero
从产品战略、技术演进与行业洞察三重视角，解读这个 GitHub 十万星项目背后的深层逻辑
一、项目概述：从一条推文到十万颗星
2026 年 1 月 26 日，Andrej Karpathy 在 X (原 Twitter) 上发布了一条长推文，分享了他使用 Claude Code 几周后的观察。这不是一篇技术教程，而是一位顶级 AI 专家对 LLM 编程行为的"病理报告"。
开发者 Forrest Chang (forrestchang) 做了一件看似简单的事：让 Claude Code 把 Karpathy 的观察转化为可执行的行为准则。AI 先生成了约 800 行描述，然后 Chang 让它自我审视——最终精简到 65 行清晰指令。
这个 CLAUDE.md 文件在 2026 年 4 月 13 日单日获得 5,828 颗 GitHub 星标，成为当日全球第二热门仓库。截至目前已超过 10 万颗星。
没有框架。没有库。没有 SDK。只是一个放在项目根目录的 Markdown 文件。
二、Karpathy 的诊断：LLM 编程的三大病症
Karpathy 在推文中精准描述了 LLM 写代码时的结构性缺陷：
病症一：沉默的假设 (Silent Assumptions)
"模型会替你做出错误假设，然后一路狂奔。它们不管理自己的困惑，不寻求澄清，不呈现不一致性，不展示权衡，该反驳时不反驳。"
这是最危险的问题。当你说"加个验证"，模型不会问"验证什么？怎样算失败？边界条件是什么？"它会默默选择一个自认为合理的实现，然后信心满满地交付。
病症二：过度工程 (Overengineering)
"它们真的很喜欢把代码和 API 搞复杂，膨胀抽象，不清理死代码。100 行能解决的问题，它们会写 1000 行。"
LLM 天生有"创造"的冲动。它见过太多设计模式、架构范式，于是倾向于往简单问题上堆砌复杂方案。"以防万一"的代码、"未来可能需要"的配置项、"更灵活"的抽象——全是噪音。
病症三：附带伤害 (Collateral Damage)
"它们有时会修改或删除它们没有充分理解的注释和代码，即便这些改动与任务正交。"
你让它修一个 bug，它顺手"优化"了旁边的格式，删了一段它认为"没用"的注释（其实是历史债务的重要记录），重构了一个它觉得"不够优雅"的函数（其实有未知的下游依赖）。
三、四大准则：从病理诊断到处方
CLAUDE.md 的四条准则并非空中楼阁，而是精准对症的处方：
| 准则 | 对治的病症 | 核心要求 |
|---|---|---|
| Don't Assume（不要假设） | 沉默的假设 | 显式陈述假设，多种理解时全部展示，不确定就停下来问 |
| Minimum Code（最小代码） | 过度工程 | 只写解决问题所需的最少代码，不加没要求的功能和抽象 |
| Surgical Changes（手术式改动） | 附带伤害 | 只改必须改的，不顺手优化，不重构没坏的东西 |
| Verifiable Goals（可验证目标） | 模糊执行 | 把任务转化为可验证的成功标准，用测试锁定边界 |
准则一的设计精妙
"不要假设"不是让 AI 变得优柔寡断，而是要求它暴露决策过程。当 AI 说"我看到两种方案：A 用简单正则做基础验证，B 按 RFC 5322 完整实现并做 DNS 检查。你需要哪种？"——这才是专业态度。
准则二的检验标准
"200 行能用 50 行写完就重写。自问：高级工程师会说这太复杂吗？"
这是可操作的自检机制。不是让 AI 追求代码量最小化，而是让它学会质疑自己的"创造冲动"。
准则三的关键区分
"你的改动导致的孤儿代码要清理，但已有的死代码别动。"
这条区分极其精准。你新增的函数如果让某个 import 变成孤儿，删掉——因为是你造成的。但原来就有的死代码？提一下，但不要动。因为你不知道历史债务背后的故事。
准则四的底层逻辑
Karpathy 的原话揭示了设计意图：
"LLM 特别擅长循环直到满足特定目标……不要告诉它做什么，给它成功标准，然后看它执行。"
这是对 LLM 能力边界的深刻理解。LLM 不擅长理解模糊意图，但擅长迭代验证。把"修这个 bug"变成"写一个能复现 bug 的测试，然后让测试通过"——这是在用 LLM 的长处弥补它的短板。
四、战略意义：为什么一个 Markdown 文件能火爆全球
4.1 时机的精准
Karpathy 在推文中写道：
"2025 年 12 月，LLM 代理能力跨过了某种连贯性阈值，软件工程发生了相变。"
他本人的数据：2025 年 11 月，80% 手写 + 20% AI；2025 年 12 月，反过来。这不是增量进化，是范式跃迁。
而恰恰在这个时间点，数百万开发者刚刚开始用 AI 写代码——然后集体撞上了 Karpathy 描述的那堵墙。
4.2 共鸣的力量
"这四条准则并不新奇。它们是每个用 Claude Code 超过一周的人都感受到的痛点的精准表达。这次传播是认同，不是发现。"
—— computeleap.com 分析
十万颗星不是因为 Karpathy 发现了新大陆，而是因为他替所有人说出了那句话："这不是你的问题，是工具的问题——而且是可以解决的。"
4.3 名字的分量
如果同样的内容由一个普通开发者发布，可能会有几百颗星。Karpathy 的名字本身就是信任背书：
- OpenAI 联合创始人：见证并参与了 GPT 系列的诞生
- Tesla AI 负责人：将 AI 落地到千万级产品
- "Vibe Coding"发明者：2025 年初他定义了这个时代的编程方式
- Eureka Labs 创始人：持续在 AI 最前沿探索
当这样一个人说"LLM 有问题"，整个行业都会竖起耳朵。
五、深层洞察：为什么顶级专家关注"小问题"
这是本文最关键的分析维度。
5.1 这不是"小问题"
表面看，"不要假设""代码精简""手术式改动"都是老生常谈的工程规范。但 Karpathy 关注的不是规范本身，而是：
LLM 违反规范的方式与人类完全不同，因此需要完全不同的约束机制。
人类新手可能因为经验不足而过度工程；LLM 过度工程是因为它见过太多模式。
人类可能因为粗心而修改不相关代码；LLM 修改不相关代码是因为它没有"上下文边界"的概念。
人类会问问题；LLM 会默默假设然后自信回答。
同样的病症，完全不同的病因，需要完全不同的治疗方案。
5.2 这是 AI 可靠性工程的基石
Karpathy 在 2026 年 5 月 Sequoia 的 AI Ascent 演讲中提出了"Agentic Engineering（代理工程）"的概念：
"Vibe Coding 提升了下限——任何人都能发布。Agentic Engineering 保住了上限——专业软件保持质量标准。"
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 目标 | 提升下限——任何人都能做 | 保住上限——专业标准不降 |
| 产出 | 原型、周末项目 | 生产系统，安全可维护 |
| 责任 | 隐式——"在我机器上能跑" | 显式——漏洞、回归、运维责任 |
| 人的角色 | 想象力、提示词技巧 | 规范撰写、监督、品味、评估设计、安全审查 |
CLAUDE.md 是 Agentic Engineering 的第一块砖。它回答的问题是：在 AI 写 80% 代码的世界里，人类如何保持控制？
5.3 "小问题"决定"大格局"
Karpathy 举过一个例子：最先进的 Opus 4.7 能重构十万行代码，能找到零日漏洞——但它会告诉你"走 50 米去洗车"，因为"很近"。它没意识到洗车需要车。
模型在某些维度飞天，在另一些维度坠机。
这种"参差智能"(Jagged Intelligence) 意味着：不能无脑信任，也不能全盘否定。你必须建立精确的约束机制，在 AI 擅长的领域放手，在 AI 薄弱的领域介入。
四条准则本质上是在 AI 最容易犯错的地方插入检查点。
六、对 AI 编程工具发展的启示
6.1 提示词工程的终点是规范工程
CLAUDE.md 的成功揭示了一个趋势：单次提示词的优化已经触及天花板，持久化的行为规范才是出路。
未来的 AI 编程工具竞争不会只在模型能力层面，还会在规范层生态层面：
- 谁能提供更好的默认规范？
- 谁能让用户更容易定制规范？
- 谁能建立规范的社区共享机制？
6.2 "可验证性"是护城河
Karpathy 反复强调：LLM 的能力在可验证领域（代码、数学）飙升，是因为可以大规模 RL 训练。不可验证的领域（品味、设计判断）几乎没有进步。
这对创业者的启示：
"如果你的领域是可验证的，而且大厂还没建 RL 环境——你可以自己建，然后超越通用模型。"
6.3 人的新角色：品味与监督
Karpathy 坦承他已经不记得是 keepdim 还是 keep_dims，是 dim 还是 axis。实习生（AI）处理细节。他拥有的是：规范、唯一用户 ID 的决策、抽象是否合理。
程序员的核心竞争力正在从"写代码"转向"定义什么代码该写"。
七、结论：一次范式跃迁的信号
Andrej Karpathy Skills 项目的十万颗星不是偶然的病毒式传播。它是一个时代的信号：
- AI 编程已经从"能用"进入"可控"阶段——工具本身没问题了，问题是人机协作的规范
- 顶级专家关注的"小问题"往往是系统性风险的早期预警——假设、过度工程、附带伤害，每一条都能让项目脱轨
- 未来属于"代理工程师"——不是手写代码的人，而是定义规范、设计验证、保持监督的人
Karpathy 在推文里写道：
"这是我二十年编程生涯中基础工作流的最大变化，而且是在几周内发生的。"
几周。二十年。
这就是我们所处的时代。
附录：项目资源
- GitHub 仓库：https://github.com/multica-ai/andrej-karpathy-skills (原 forrestchang 版本已转移)
- Karpathy 原推文：https://x.com/karpathy/status/2015883857489522876 (2026.1.26)
- 安装方式：
- 插件：
/plugin marketplace add forrestchang/andrej-karpathy-skills→/plugin install andrej-karpathy-skills@karpathy-skills - 文件：
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
分析报告由 Zero 撰写 | 2026.05.30