为什么你的 AI 写代码帮手越来越蠢?一个28k星的 CLAUDE.md帮你解决

Karpathy 灵魂拷问：为什么你的 AI 写代码帮手越来越蠢？

不是模型不行，是你跟 AI 协作的方式从根上就错了

上周，GitHub 上出现了一个只有两个文件的开源项目，没有复杂代码，没有炫酷界面——只有一个 CLAUDE.md。

4 天，28,000 颗 Star，冲上 Trending 第一。

这个文件的内容，来自安德烈·卡尔帕西（Andrej Karpathy）——特斯拉 Autopilot 总监、OpenAI 创始成员、李飞飞高徒——对大模型编程失败原因的深度复盘。

模型在”配合”你，而不是帮你

Karpathy 的核心发现，用一句话概括就是：

“AI 正在无条件配合你的错误假设，一路狂奔。”

不是耸人听闻。他具体描述了三个典型场景。

第一个：它替你做了你没要求它做的决定。

当需求模糊时，AI 会默默选一个解释，然后假装这是唯一正确答案——不问你，不推回来，不提还有别的路径。为什么呢？它在”配合”你的沉默，而不是弥补你的信息缺失。

第二个：它把代码写复杂了。

Karpathy 的原话是：”implement a bloated construction over 1000 lines when 100 would do”——能用 100 行解决的问题，它写 1000 行。不是因为能力不够，是因为你没有明确限制它。

第三个：它删你不懂的代码。

AI 有时会改动或删除自己理解不了的注释和代码片段——因为它不理解那些注释的价值，所以认为它们是”冗余”的。它用自己的认知裁剪你的知识积累。

forrestchang/andrej-karpathy-skills 这个项目，就是针对这三个场景设计的”AI 协作规范”。文件很短，只有四条原则，每条都直接对应一个真实痛点：

第一条：编码前先想清楚。

不要假设。有歧义就问，不要替用户选。不要隐藏困惑，不要假装懂了。

第二条：简单优先。

没有明确要求的”灵活性”不加。没有单次使用的抽象层不建。如果 200 行可以写成 50 行，必须重写。

第三条：精准修改。

只改你必须改的。不要”优化”相邻代码，不要改格式，不要碰你理解不了的注释。

第四条：目标导向。

用测试验证结果，而不是用感觉判断完成。

你可能不用 Claude Code，但你大概率用过 Copilot、Cursor、通义灵码、Kimi Code——或者你的公司正准备引入”AI 编程助手”。

引入之后，你会发现：AI 确实快了，但 bug 也多了，代码也乱了，最后花更多时间修 AI 写的烂摊子。

这不是工具的问题，是协作方式的问题。

Karpathy 指出的是一个根本性的错位：人类给 AI 的是一个任务描述，但 AI 需要的是决策边界——什么能做，什么不能做，什么情况要停下来问。没有这个边界，AI 会用”它认为最优”的方式完成任务，而不是”你期望”的方式。

B 站上关于 AI 编程的视频，主流内容是”用 AI 一天写了 1000 行代码”、”AI 帮我做了整个项目”——数量感很强，情绪很爽。

但几乎没有人讲：AI 什么时候会帮倒忙，怎么设置安全边界，出问题了怎么让它停下来。

这个项目之所以 4 天 26k Star，正是因为它填补了这个空白——它不是在教你怎么用 AI 写更多代码，而是在教你怎么让 AI 不乱来。这是一个被严重低估的角度。

这个 GitHub 项目本身几乎没有代码——只有配置文件。

也就是说，真正有价值的信息，是怎么和 AI 对话的知识，而不是 AI 能生成什么代码。

这或许预示着 AI 编程的下一次范式转移：从”用 AI 生成代码”到”用 AI 维护项目上下文”——记忆问题、边界问题、意图对齐问题，比生成代码本身更值得关注。

文 · 虾看虾说

标签：AI编程 · LLM · 程序员 · GitHub · 科技