Karpathy 的 65 行文件让开发者们疯狂了

Andrej Karpathy 没有写框架。 他没有创办公司。 他甚至没有发布代码。

他只写了一个 65 行的 Markdown 文件。

而它却成了 GitHub 历史上增长最快的仓库之一。

这个文件叫 CLAUDE.md。

没有花哨的架构。 没有 AI 突破。 没有百亿参数模型。

只有四条极其简单的 AI 代码代理行为规则。

而根据开发者社区的说法，这四条规则颠覆了一切。

基于这些想法构建的仓库——灵感来自 Andrej Karpathy 的观察，由开发者 Forrest Chang 打包——迅速飙升至 GitHub 趋势榜第一，在镜像和 fork 中累计获得超过 22 万颗星。

当你意识到开发者们 star 的是什么时，这简直令人难以置信：

一个文本文件。

没有可执行代码。 没有依赖图。 没有基础设施。

只是一些指令，教 AI 在碰你的代码之前该如何表现。

老实说？

这比 2026 年任何其他东西都更能说明 AI 编程的现状。

真正的问题从来不是“AI 能写代码吗？”

AI 已经可以写代码了。

这个争论已经结束了。

真正的问题是，AI 代码代理表现得像过度自信、打字速度无限快的初级开发者。

它们：

• 假设需求而不提问
• 重写没人让它们碰的文件
• 过度工程化简单的修复
• 为未来可能出现的抽象问题创建抽象
• 默默地做出架构决策
• 优化从未出问题的东西
• 为 10 行任务生成 500 行改动

Karpathy 在从手动编码转向大量使用工具（如 Claude Code）的代理驱动开发后，公开描述了这些挫败感。

他的观察简单但重要：

问题不再是语法了。 问题是判断力。

这一见解引发了开发者对 AI 辅助编程思考方式的巨大转变。

因为一旦模型足够能写代码……

行为就成了瓶颈。

不是智能。 不是 token。 不是上下文窗口。 而是行为。

为什么 CLAUDE.md 会病毒式传播

CLAUDE.md 的巧妙之处在于，它并没有试图让 AI 更聪明。

它试图让 AI 更自律。

这是一个完全不同的概念。

这个文件位于项目的根目录，像 Claude Code 这样的工具会在每次会话中自动加载它作为持久的行为上下文。

这意味着 AI 不再像一个拿着键盘的金鱼一样进入每个仓库。

相反，它会收到关于如何思考、如何修改代码、如何限定改动范围、如何提问以及如何定义成功的持续指令。

结果不是“更好的编码”，而是更少的灾难性错误。

这个区别很重要。

大多数开发者实际上并不需要 AI 写天才算法。

他们需要 AI 停止破坏稳定的代码库。

这正是这些规则所瞄准的。

改变 AI 编程的四条规则

1. 先思考，再编码

这条规则听起来显而易见。

但它直接攻击了最糟糕的 LLM 行为之一：自信的猜测。

文件指示 AI：

• 明确陈述假设
• 在需求模糊时提问
• 公开不确定性，而不是隐藏它
• 避免假装理解它不懂的事情

这个单一的行为改变大幅减少了幻觉实现和错误的架构决策。

因为大多数 AI 失败并非发生在理解任务之后。

它们发生在理解任务之前。

人类在需求不明确时自然会暂停。

LLM 通常不会。

它们直接生成。

立即生成。

而且快速错误的答案远比缓慢正确的答案危险得多。

2. 简单至上

这可能是整个文件中最重要的规则。

AI 模型喜欢抽象。

尤其是不必要的抽象。

你要求修复一个按钮，结果却得到了：

• 服务层
• hooks
• 工厂模式
• 通用接口
• 依赖注入
• 配置系统
• 为没人要求的功能做的“未来兼容”

开发者不断看到 AI 代理把微小的任务变成架构重设计。

所以规则变得极其简单：

写解决当前问题的最少代码。

不写任何猜测性的代码。 不写“为了可扩展性”的代码。 不写“以防万一”的代码。

因为过度工程化是 AI 生成代码中最大的隐性成本之一。

这太讽刺了：

人类花了几十年教导初级工程师不要过度复杂化软件。

现在我们正在教机器同样的事情。

3. 手术刀式改动

这是开发者最有共鸣的规则。

因为每个用过 AI 编码工具的人都经历过这种情况：

你要求一个微小的修改……

……而 AI 随意地重写了半个文件。

格式修改。 重构。 重命名变量。 重新组织导入。 “改进”不相关的逻辑。

突然间你干净的 git diff 变成了噩梦。

所以 CLAUDE.md 引入了一个听起来几乎像军事行动的原则：

只改动必要的部分。

每行修改都必须直接追溯到原始请求。

不附带任何损害。

这个单一概念极大地提高了可审查性。

而这很关键，因为 AI 生成的代码不再仅仅根据输出质量来评判。

它还要看：

• 可审计性
• 可预测性
• 可维护性
• 可信度

越容易理解为什么某处发生了变化，AI 在真正工程团队中的可用性就越高。

4. 目标驱动执行

这条规则攻击了 AI 代理的另一个重大弱点：

它们优化模糊的目标。

人类经常给出糟糕的指令：

“修复这个” “让它更干净” “优化性能” “改进用户体验”

没有成功标准，AI 自己填补空白。

这很危险。

所以这条规则迫使模型在开始编码前将模糊性转化为可衡量的结果。

例如：

• 复现 bug
• 定义预期行为
• 创建通过的测试
• 验证边界情况
• 建立完成标准

这改变了 AI 从“生成代码直到看起来正确”

变成“朝着可验证的目标执行”

这是一个巨大的转变。

这也是开发者报告可靠性大幅提升的原因之一。

更大规模的爆发原因

疯狂的不是文件本身。

疯狂的是它的流行所揭示的东西。

大量开发者不再问：

“AI 能写代码吗？”

他们在问：

“我们如何在真实生产系统中控制 AI 行为？”

这是一个成熟得多的对话。

而 CLAUDE.md 成为了一个象征，因为它代表了行业迫切需要的东西：

编码代理的行为对齐。

不是模型扩展。 不是基准分数。 而是操作纪律。

这个仓库还证明了一件重要的事情：

有时候最高杠杆的创新不是增加复杂性。

而是移除复杂性。

一个 65 行的 Markdown 文件变得比成千上万个过度构建的 AI 生产力工具更有价值，因为它解决了开发者每天面临的一个真实痛点。

这就是它传播得如此之快的原因。

不是炒作。

而是认同。

但也有大量炒作

平心而论，并非所有人都同意那些夸张的说法。

一些开发者认为星标数量被 Karpathy 的名声和文件易于复制粘贴到项目中而夸大了。另一些人则认为针对特定项目的定制指令远比通用行为规则重要。

老实说，他们说得有部分道理。

一个通用的 CLAUDE.md 并不能神奇地把糟糕的工程实践变成好的。

它不能取代：

• 干净的架构
• 测试
• 文档
• 代码审查
• 人的判断力

它真正做的是减少重复的 AI 失败模式。

这才是真正的价值。

不是魔法。

而是约束。

而约束在 AI 系统中被低估了。

这里最重要的教训

整个现象教给了我们关于软件工程未来的一个重大教训：

下一代开发者不会只是写代码。

他们将设计 AI 行为。

提示工程只是开始。

现在我们看到的是：

• 行为规范
• 代理操作规则
• 执行约束
• 记忆系统
• 持久编码策略
• AI 工作流治理

换句话说：

开发者正在成为自主编码系统的管理者。

而 CLAUDE.md 可能会被铭记为这一转变的最早主流例子之一。

一个微小的文件。

四条规则。

以及一种人与 AI 协作的完全不同的哲学。