GitHub 上最近有个项目火了，几周之内便斩获数万 Star。
但这个项目并非什么新框架、新库或者应用，它仅仅是一个文件，一个不到 70 行的 skill 文件。
初次看到时，很多人可能都会怀疑是不是搞错了，点进去翻看一遍后，才发现项目真的只有一个文件。README 加上正文，全部内容加起来两分钟就能读完。可就是这么个看似简单的东西，却在开发者社区中赢得了市场的热烈追捧。
那么，这个项目到底是什么？为什么能火？我们不妨也来深入了解一下。
项目的由来：Karpathy 的犀利吐槽
要理解这个项目，得先从其“来历”说起，因为它的诞生本身就很耐人寻味。
今年 1 月底，AI 领域的顶尖人物 Andrej Karpathy 发布了一条长推。如果你对 Karpathy 不熟悉，这里简单介绍一下：他是 OpenAI 的联合创始人，前特斯拉 AI 总监，也是 vibe coding 这个网络流行词的创造者。在 AI 编程这个领域，他无疑站在了最前沿。
那条推文的标题很随意，叫做“用 Claude 写了几周代码的一些随笔”，但内容却一点也不随意。
在推文中，他几乎公开而精准地吐槽了当前 AI 写代码的三大普遍问题。
第一个毛病，自作主张：
They also don't manage their confusion, they don't seek clarifications, they don't surface inconsistencies, they don't present tradeoffs, they don't push back when they should, and they are still a little too sycophantic.
翻译一下：AI编程助手通常不会主动管理自己的困惑，不寻求澄清，不指出需求中的矛盾之处，不陈述不同方案间的利弊权衡，在该回绝不合理需求时不会回绝，并且有时表现得有些过于“谄媚”。
第二个毛病，过度工程：
They will implement an inefficient, bloated, brittle construction over 1000 lines of code and it's up to you to be like "umm couldn't you just do this instead?"
简单来说，就是 100 行代码能搞定的事情，AI 非要给你写出 1000 行，构建一个低效、臃肿且脆弱的“巨无霸”代码结构。
第三个毛病，误伤友军：
They still sometimes change/remove comments and code they don't like or don't sufficiently understand as side effects, even if it is orthogonal to the task at hand.
AI 有时候会“顺手”改掉或删掉一些它没有完全理解、或者它“不喜欢”的代码和注释，即使这些东西与当前任务毫无关系。
如果你用过 AI 编程助手，看到这三条吐槽，应该会有一种强烈的“被说中了”的感觉。Reddit 上有个说法特别精准，他们管这类 AI 编程助手叫“自信的初级工程师”：干活特别快，特别能写，但永远不会跟你说“我不确定”。当它不确定时，不是停下来问你，而是自己猜一个答案，然后带着 120% 的自信一路向前冲。它写代码的速度是人类的一百倍，所以它搞砸的速度也是一百倍。
吐槽完问题，关键在于如何解决。Karpathy 的推文发出后，一位名叫 Forrest Chang 的开发者做了一件漂亮事：他将 Karpathy 的吐槽提炼成了四条具体、可执行的规则，并写进了一个文件里。这就是那个火爆的 开源项目 的核心。
四条核心规则：给AI编程戴上“紧箍咒”
这个项目包含的四条规则，每一条都直指痛点。
第一条规则：先想，再写。
这条听起来像是废话，但你仔细回想一下，平时是怎么给AI下指令的？是不是经常这样：
帮我写一个导出用户数据的功能。
然后 AI 就“唰唰唰”写了一大堆。你一看，它默认导出全部用户，默认用 JSON 格式，默认存到本地文件，默认包含所有字段，甚至可能包括密码哈希。这四个“默认”，哪个是你明确说的？一个都不是，都是它自己猜的。
正确的做法应该是什么？AI 应该在动手编码之前，先向你提出关键问题：
- 需要导出哪些用户（全部、特定分组、满足某些条件的）？
- 导出的数据格式是什么（JSON、CSV、Excel）？
- 需要包含哪些字段？有没有敏感或隐私字段（如密码哈希、手机号）需要排除？
- 数据量大不大，是否需要分页或分批处理？
换句话说，它应该主动把自己可能存在的困惑“说出来”，而不是“藏起来”。这一条是四条规则中最核心的，因为所有后续的问题——过度设计、误删代码、改动无关内容——根源都在于此。如果AI不先问清楚，它就会去“猜”。一旦开始猜，就会带着自信跑偏，而且它跑偏的产物往往看起来有模有样（代码整洁、结构“优美”），可能要过几天你才会发现底层逻辑全是错的。
第二条规则：能简单就简单。
你让AI写一个计算折扣的函数。一个经验丰富的程序员可能会怎么写？
def calculate_discount(amount, percent):
return amount * (percent / 100)
三行，完事，清晰明了。
但AI会怎么写？它可能会给你创建一个 AbstractDiscountStrategy 抽象类，再派生出 PercentageDiscount 和 FixedDiscount 两个子类，最后再来一个 DiscountConfig 配置类用于初始化。洋洋洒洒五十多行，使用时还得额外写几十行初始化代码。
你只是想要一个简单的乘法运算，它却给你建了一座摩天大楼。
这个毛病严格来说不是技术错误，它用的设计模式可能是对的，遵循的SOLID原则也可能没问题。但核心矛盾在于：你当前的需求仅仅是“计算一个折扣”。规则明确指出：凡是200行能缩写成50行的代码，就值得重写。没有被明确要求的功能不要添加，没有被要求的灵活性不要预设，不可能出现的错误场景不用过度处理。
一个很实用的检验标准是：如果一个资深工程师看了代码后会说“这也太复杂了吧”，那它就是太复杂了。
第三条规则：只改该改的。
这条直接对应 Karpathy 提到的第三个毛病——AI顺手改动它不理解的内容。规则很简单：你让我修复某个bug，我就只修改与这个bug直接相关的那几行代码。旁边的代码写得再“丑”我也不碰，注释再“过时”我也不改，代码风格即便与我的习惯不同，我也严格遵循原有的写法。
每一行代码的改动，都必须能够直接追溯到用户提出的具体需求或问题。这一条说起来简单，但对AI而言却最难做到，因为AI似乎天生有一种“顺手优化”的冲动，就像有些人看见歪了的画框就一定要扶正一样，AI看见它认为“不够好”的代码就手痒。
第四条规则：用目标驱动，而非指令驱动。
这条被 Karpathy 认为是最高效的一条。他的原话是：
LLMs are exceptionally good at looping until they meet specific goals... Don‘t tell it what to do, give it success criteria and watch it go.
大语言模型特别擅长朝着一个明确的目标反复迭代，直到达标。所以，你不应该直接告诉它“怎么做”，而是告诉它“做成什么样算成功”。
举个例子：
- 不要说：“给这个函数加一个输入验证。”
- 而要说：“写一组单元测试，覆盖所有非法输入的情况，然后让所有测试通过。”
- 不要说：“修一下这个bug。”
- 而要说：“写一个能稳定复现这个bug的最小测试用例，然后修改代码让这个测试用例通过。”
区别在哪里？前者是模糊的指令，AI会按照自己的理解去“发挥”，结果可能不是你想要的。后者是明确的、可检验的成功标准，AI会朝着这个标准持续努力，直到达标。这个思维上的微妙转换，带来的效果差距往往是巨大的。
一个强的、明确的目标能让AI自己“闷头跑”向终点，而一个弱的、模糊的指令只会让它越跑越偏。
如何应用：将规则“喂”给你的AI助手
看完这四条规则，你可能会觉得：这不就是一些编程和协作的常识吗？没错，它们确实是常识。但常识最大的问题往往不是没人知道，而是很少有人把它系统地、结构化地写下来，并“喂”给AI，让它也成为AI的“常识”。
这个项目最厉害的地方，不在于它发现了什么惊天的秘密，而在于它将 Karpathy 这种顶尖从业者的“隐性经验”，转化成了一个可执行、可复用的配置文件。你只需要将这个文件放入你的项目或开发环境，AI 助手的行为模式就会发生积极的改变。
具体怎么用？这取决于你使用的工具。
如果你使用 Claude Code：
只需要两行命令：
/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
一行命令即可搞定。
如果你使用 OpenAI 的 Codex：
同样可以使用。Codex 拥有一个与 Claude Code 的 CLAUDE.md 几乎一模一样的机制，叫做 AGENTS.md。原理相同：Codex 在启动时会自动读取这个文件，并将其中的内容作为行为准则。
而且，Codex 的系统设计可能更灵活一些，它支持三层规则结构：
- 全局规则：存放在
~/.codex/AGENTS.md，对所有项目生效。Karpathy 的这四条规则就非常适合放在这里。
- 项目规则：存放在项目根目录的
AGENTS.md，只对当前项目生效。
- 目录规则：存放在子目录中，例如
services/payments/AGENTS.md，只在处理该目录下的代码时生效。
这三层规则从外到内叠加，越靠近当前工作目录的规则优先级越高，类似于 CSS 的层叠样式表原理。
配置步骤也很简单：
# 第一步，创建存放全局规则的目录
mkdir -p ~/.codex
# 第二步，下载规则文件到全局目录
curl -o ~/.codex/AGENTS.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
# 第三步，验证规则是否生效
codex "Summarize the current instructions."
如果 Codex 能够复述出那四条规则，就说明配置成功了。
所以，无论你使用的是 Claude Code 还是 OpenAI Codex，其核心逻辑是相通的：将你对 AI 协作伙伴的行为期望，清晰、具体地写成一个规则文件，让它每次开始“工作”前都先“读”一遍。这就像给一位新员工一本详尽的《员工手册》。在 Claude 这里，这本手册叫 CLAUDE.md；在 Codex 那里，它叫 AGENTS.md，但里面的“公司章程”（最佳实践）可以完全一致。掌握这类工具的高级用法，本身就是 技术文档 价值的体现。
更深层的思考：不仅是AI，更是协作哲学
最后，让我们思考得更深一点。你有没有注意到，这四条规则其实不仅仅适用于 AI。
“先想再做”、“能简单就简单”、“只动该动的”、“用目标驱动而非指令驱动”——如果你把“AI”两个字去掉，这四条规则套用在任何一个你正在指导的新人、任何一个正在合作的同事，甚至是用来自我反省，都同样成立。
Karpathy 在吐槽 AI 的时候，其实也在揭示一个更大的命题：人类与日益强大的工具之间的关系。工具越强大、越智能，使用者的判断力、引导力和把控力就变得越关键。AI 让你写代码的速度成百倍提升，同时也让你产出“代码垃圾”的速度成百倍提升。
AI 编程的门槛确实降低了，但真正的瓶颈从来都不是“怎么写代码”，而是“你写出来的东西，你自己能不能最终负责、理解和掌控”。
Reddit 上有句评论说得特别好：AI 不会让优秀的工程师失业，但它会让优秀工程师和普通工程师之间的效率与产出质量差距，拉大到一百倍。 因为优秀的工程师知道什么时候该放手让 AI 全力奔跑，什么时候又必须及时拉紧缰绳，给予明确的引导和约束。
而这个不到 70 行的 skill 文件，正是那根至关重要的“缰绳”。它代表了人类经验对 人工智能 能力的有效驯服与引导。
如果你对这个项目感兴趣，想亲自尝试或查看更多细节，项目地址如下：
https://github.com/forrestchang/andrej-karpathy-skills
在 云栈社区，我们持续关注这类能切实提升开发者效率的开源项目与最佳实践。技术的进化不仅仅是工具的升级，更是使用工具的方法论的迭代。希望这四条规则，能帮助你更好地驾驭AI编程助手，写出更简洁、更可靠、更符合预期的代码。
发表于 昨天 19:32
|
查看: 5|
回复: 0
