如果你最近用过 Claude Code、Cursor 这类 AI 编程助手，大概有过这样的体验：你说"帮我加个按钮"，它改了七八个文件；你说"修个小 bug"，它把整个模块重构了一遍；更烦的是，它根本不问你任何问题，悄悄做了一堆假设，等你发现的时候已经一团糟。

今年 1 月，AI 界的传奇人物 Andrej Karpathy（前 Tesla AI 总监、OpenAI 创始成员）分享了他用 AI 编程两个月的感悟——他描述了三个反复出现的痛点。一位叫 Forrest Chang 的开发者读完之后，花时间把这些痛点变成了一份只有 65 行的配置文件，放到了 GitHub 上。

这个项目叫 andrej-karpathy-skills，一周内收获了 42,000 个 Star，如今已突破 7 万，是当前 GitHub 上最火的周榜项目之一。

Karpathy 说 AI 有哪三个毛病？

Karpathy 原文这样描述：

模型会替你做出错误的假设，然后径直往前冲，既不管自己的困惑，不寻求澄清，不指出矛盾，不说明利弊，也不在该推回去的时候推回去。

具体来说，AI 编程助手有三个典型问题：

问题 1：沉默地做错误假设
需求有歧义？AI 不问，自己猜，然后埋头去做。等你发现方向不对，已经写了好几百行。

问题 2：热衷于过度工程
你说"加个按钮"，它给你一套支持多主题、可配置、面向未来扩展的按钮组件框架。你只需要一个 <button>。

问题 3：改动范围超出控制
让它修一行代码，它顺手"优化"了周围十行注释和三个函数命名。每次 diff 都是一场噩梦。

这份文件怎么解决问题的？

项目的核心是一个叫 CLAUDE.md 的文件。你把它放到项目根目录，Claude Code 每次工作时都会自动读取它，相当于给 AI 立下了四条工作规矩：

原则 1：先想清楚，再动手
开始之前，先说出你的假设。有歧义就停下来问。有多种方案，列出来让用户选，不要偷偷挑一个。

原则 2：简单优先
能用 50 行写完的，不要写 200 行。没有被要求的功能，一个都不加。不要为"将来可能用到"而抽象。

原则 3：外科手术式改动
只碰你必须碰的那行代码。不要"顺手"改格式、注释或命名。你写的每一行都要能追溯到用户的请求。

原则 4：目标驱动，可验证
把模糊的任务变成可以验证的目标。“修 bug"→"先写一个能复现 bug 的测试，再让它通过”。多步任务先列计划，每步都有验收标准。

怎么使用？30 秒就能上手

如果你在用 Claude Code，操作极其简单：

# 第一步：把文件下载到你的项目根目录
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

# 第二步：就这些，没有第三步
# Claude Code 会自动读取这个文件

如果你用的是其他 AI 工具（比如 Cursor、Codex），也可以把这四条原则贴到系统提示词里，效果类似。

为什么这么多人觉得有用？

本质上，这份文件做的事情很简单：它把"一个好的初级工程师应该有的习惯"写下来，贴给 AI 看。AI 并不傻，只是默认行为没有这些约束。给它规则，它就能遵守。

这也是 Karpathy 说的那个更大趋势的缩影——我们已经从"写代码"变成了"管理写代码的 AI"。而管理 AI，和管理人一样，需要清晰的期望和边界，不能只靠对方猜。

完整项目链接：forrestchang/andrej-karpathy-skills