在 Github 上把 Anthropic 官方文档甩在身后，怪不得 Dario 要把他招回去。
作者丨樊天骄、郑佳美
编辑丨郑佳美
一份只有 65 行的 Markdown 文件，刚刚成为 GitHub 历史上最被讨论的 AI 工程实践——而它没有写一行可执行代码。
这就是 2026 年 4 月开始刷屏的 andrej-karpathy-skills 项目：累计 17.6 万颗星，单文件、零逻辑，却在同一个月里把 Anthropic 官方的 anthropics/skills 仓库（15.1 万星）甩在身后。两件事叠在一起看，AI 编程的竞争焦点正在发生一次清晰的位移——从"模型能不能写"，转向"模型在没人盯着时，能不能不写错"。
01
想让 AI 更聪明，就要约束它的行为
Karpathy 那条原话被开发者社区反复传阅：模型会代你做错误假设，然后不假思索地执行；它们喜欢把代码和 API 搞复杂，堆抽象，不清理死代码；它们有时会改动或删除自己理解不足的代码和注释，即使这些内容与任务无关。
这段吐槽戳中了 LLM 编码代理最普遍、却最少被正面讨论的失败模式——不是"不会写"，而是"乱写"。
已经使用过 CLAUDE.md 的开发者们表示：装上这份规则后，AI 编码任务通过率从 65% 提升到 94%。这个数字没有权威基准背书，但之所以能流传，是因为它对应的是开发者每天都在经历的真实落差。
把"65% → 94%"的逻辑拆开看，本质上是三类系统性错误被显式压制了。
第一类是误解需求。AI 编程代理最常见的失败不是不会写代码，而是"自行补全模糊需求"。模型收到"修一下登录逻辑"这类指令时，会默认一系列产品假设——前端怎么传参、用户态怎么校验、错误如何降级——然后把这些假设当成既定事实去实现。
因此，CLAUDE.md 第一条原则要求"遇到歧义必须先问、先呈现权衡"，硬切断了这种倾向。模型从"先动手再猜"变成"先汇报再请求授权"。
第二类是过度工程化。LLM 训练数据中高质量代码的密度极高，模型生成时倾向于堆叠抽象层、分层设计、泛化模式——本来 100 行能搞定的事情，往往被扩成 1000 行的臃肿架构。
对此，Karpathy 自己的吐槽是"100 行能搞定的非要写 1000 行"。而 "简洁优先"原则把"50 行能写完，绝不写 200 行"写进规则，等于给模型的"完美主义冲动"装了一个刹车。
第三类是修改扩散。没有边界约束时，AI 容易顺手 reformat 相邻代码、改动理解不足的模块、引入隐性副作用。Karpathy 称之为"作为副作用修改或删除了与任务无关的代码和注释"。
"外科手术式修改"原则要求"每一行改动都能追溯到原始需求"，本质上是降低编辑自由度——一个能写出 1000 行代码的模型，被规则强制只能写 50 行，效果反而更好。
这三条之外，文件里还有第四条原则：目标驱动执行。它要求 AI 在写代码前先把"修复 Bug"翻译成"先写一个能复现 Bug 的测试，再让测试通过"——即把模糊的命令转换成可验证的成功标准。LLM 围绕明确目标的循环能力极强，但前提是要给它清晰的成功判定。而这份规则让 AI 不再"我说我改好了"，而是"测试证明我已经改好了"。
把四条原则合在一起看，文件解决的不是"AI 写不好代码"的问题，而是"AI 太容易自作主张"的问题。它的设计目标不是让模型更聪明，而是让模型在每个关键节点停下来确认、克制、克制、再克制。
同时 CLAUDE.md 也让 AI 编程的"行为约束"第一次有了一个低成本、可分发、可审计的载体——一个普通开发者用 curl 命令两分钟就能装上，但所有 AI 代理都会照着执行。
因此，CLAUDE.md 登上 GitHub 榜首的真正原因，不在 prompt 写得多漂亮，而在于它把AI 编程的不确定性从"模型能力"问题，转化成了"工程设计"问题——而后者，是开发者可以亲手解决的。
02
为什么是 65 行，而不是 200 行
CLAUDE.md 的风潮很快席卷了 GitHub，衍生出一批同方向的探索项目。其中开发者 VoidLight00 的思路值得专门拿出来：一个能让 AI 自动优化 AI 规则的系统。
他的实现路径带着鲜明的工程思维：先在 eval.json 中定义一套断言测试集，用来量化评估规则文件的实际效果；再让系统进入"修改规则 — 重跑测评"的循环，如果本轮评分有提升就保留变更，没有增益就回滚到上一版本。整套流程相当于把原本靠人工反复打磨的提示词优化工作，转化成了类似代码自动化测试的标准化流程。
更有意思的是一组对照实验：有开发者试着把 Karpathy 这份规则扩充到 200 行，结果 AI 生成的代码质量非但没提升，反而出现了下滑。
背后的逻辑并不复杂。当规则文件越写越长，真正关键的约束会淹没在冗余的描述里。大模型固然能处理长上下文，但不代表它能在每一次生成中稳定识别并贯彻所有细则。规则文件的有效性，取决于模型在还没忘之前读到核心约束的概率。
这也解释了为什么 Karpathy 那份文件从一开始就走极简路线——四条原则、几十行、没有任何具体技术栈要求。它把工程纪律压缩到了 AI 最容易稳定执行的篇幅里。当 65 行就能解决核心问题，200 行的边际收益大概率是负的。
工程意义上的"短而精"，在 AI 编程时代有了新的具体含义：它不是文字上的克制，而是与模型注意力机制的精确对齐。规则写在模型能稳定看见的位置，写在它愿意照做的篇幅里，写在它最不容易读到一半就走神的长度内。
03
AI 编程下半场：
稀缺的不是模型，是约束设计
把这件事放回 LLM 工程化的整体脉络看，它指向了一个更清晰的分层。
第一层是 Prompt Engineering。关注点在"让模型听懂指令"。这一层在过去两年里被研究得最透，天花板也最明显——提示词写得再精妙，模型行为的不稳定性依然存在，因为提示词是"软"的，模型可以选择不听。
第二层是 Workflow Engineering。关注点在"让模型按步骤做事"。把任务拆成多步、引入 ReAct、引入反思机制，让模型有能力处理长链任务。这一层显著提升了单任务成功率，但仍然无法约束"模型在某个步骤上的越界行为"——工作流规定了"先做什么后做什么"，却没有规定"什么不能做"。
第三层是 Agent Governance。关注点在"让模型只能在边界内做事"。这一层的设计对象不是"任务"，而是"模型本身的行为约束系统"——包括规则文件、沙箱、审批、审计、回归测试。这些文件本质上是"投影"——它们从同一个规则源编译出来，分发给不同的 AI 代理。比如 AGENTS.md 写给机器，README.md 写给人，二者刻意分离。
CLAUDE.md 遵循的正是这第三层原则。而它之所以被反复传阅，本质上是开发者社区用脚投票，对"约束设计"这件事的集体确认。当模型能力已经足以完成写代码这件事之后，下一个真正稀缺的能力不是怎么让模型更聪明，而是"怎么让模型在不被盯着的时候也能做对"。
这也是为什么那段被无数开发者转发的吐槽能产生这么大的共鸣——或许当 AI 开始承担真正的工程任务时，它需要的不是更多能力，而是一份它必须遵守的行为契约。
上车，带你看遍全球 AI 顶会精华
可独家畅览：
专家演讲PPT
大会报告全文
热门论文解读
学术新星访谈
未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！
公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。
热门跟贴