最近看到一个挺有意思的GitHub项目。

它没有代码，没有Agent框架，没有数据库，没有服务端。核心就一个文件：CLAUDE.md。

但它拿到了十几万Star。

项目叫 andrej-karpathy-skills ，把Andrej Karpathy对LLM编程的一些观察，整理成Claude Code能直接用的规则。

我一开始看到的时候，第一反应是：现在一个配置文件都能这么火了？

但认真看完，我觉得它火得挺合理。

因为它说中的不是Claude Code的问题，而是整个AI编程正在遇到的问题。

这个项目到底是什么？

它把Andrej Karpathy对LLM写代码的几个观察，整理成了一套Claude Code的工作准则。

Karpathy提到过几个很典型的问题：

AI会替你做错误假设；不确定时也不问，直接往下写；喜欢把简单问题复杂化；还会顺手改掉一些它根本没理解的代码和注释。

这几个问题，用过Cursor、Claude Code、Copilot的人应该都懂（刚开始用cursor时真的是给我痛苦死了）。

你只是想让它改一个小bug，结果它顺手重构了旁边三个文件。你只是想加一个字段校验，结果它给你抽象出一套validation framework。你只是让它修一下登录问题，结果diff里混进了一堆格式化、重命名、注释调整。

代码确实写了，但Review的时候，人快疯了。

AI写代码为什么老跑偏？

我后来想了下，AI写代码跑偏，很多时候不是因为它"笨"。

恰恰相反，是因为它太能干了。

它会补全，会推理，会根据上下文猜你的意图，会自己规划下一步。这些能力本身都很强，但放在真实项目里，会产生一个问题：它太容易把"猜测"当成"事实"。

比如你说"帮我优化一下这个接口"，这句话对人来说都不够明确。优化性能？优化代码结构？优化返回字段？优化异常处理？

一个靠谱的工程师可能会先问一句"你说的优化具体是指哪方面？"但AI经常不会问。它会直接选一个方向，然后开始写。

如果猜对了，你会觉得它很神。如果猜错了，它就会沿着错误方向一路狂奔。

这也是我觉得AI编程最危险的地方：它不是不会执行，而是执行得太快。方向错了，速度越快，返工越多。

这份CLAUDE.md做了四件事

这个项目最核心的内容，可以概括成四条原则。都不复杂，但非常工程化。

第一层：先想清楚，再写代码

第一条叫Think Before Coding。意思是：别默认自己理解了需求。不确定就问，有假设就说出来，有多种理解就列出来，发现更简单的做法也要提醒用户。

这条看起来像废话，但我觉得它是整份配置里最重要的一条。

古人说，凡事预则立，不预则废。

这句话放到AI编程里，其实一点都不过时。

AI编程中很多错误，不是发生在代码层面，而是发生在需求理解层面。人类写错代码，通常还能靠测试发现。但如果需求理解错了，测试可能都是错的。

让AI在动手前先停一下，把自己的理解和假设说出来，本质上是在降低方向性错误。这件事对复杂任务尤其重要。

比如你让AI改一个支付逻辑、权限逻辑、数据迁移逻辑，它最好不要上来就写。它应该先告诉你：我理解你要改的是A，不是B；这里可能影响C和D；我会先补测试，再改实现。

这才像一个能协作的工程师。

第二层：简单优先，不要为了抽象而抽象

第二条叫Simplicity First。这个原则专门用来对抗AI的过度设计。

现在很多AI写代码都有一种倾向：喜欢把简单问题写得很"高级"。一个if能解决的事情，它可能给你搞策略模式。

一个只用一次的方法，它可能抽出三层工具类。一个小功能，它可能顺手设计一整套可配置架构。

看起来很专业，但真实项目里这种代码很烦。像cursor不给规则就会过度的去抽象设，下面这段代码就是它自己在随意扩展功能，严重无语

老子说，治大国若烹小鲜。

写代码有时候也是这样，不是写完就结束了。它要被别人读，要被维护，要被修改，要在半年后还能看懂。AI 生成代码的成本很低，但人类维护代码的成本很高。

所以这个项目要求Claude Code：不要加没要求的功能，不要为一次性逻辑抽象，不要提前设计未来可能用不到的灵活性。如果50行能解决，就别写200行。

我很喜欢这里面的一个判断标准：如果一个高级工程师看到后会觉得过度设计，那就应该简化。

对AI编程来说，"少写一点"有时候比"多写一点"更难。

第三层：只改该改的地方

第三条叫Surgical Changes。这条我觉得是最能提升日常体验的。

它要求AI像做外科手术一样改代码：只碰必须碰的地方，只清理自己制造的问题，不要顺手优化旁边代码，不要顺手格式化整个文件，不要删除自己没完全理解的旧逻辑。

这太重要了。

很多时候，AI最大的问题不是功能没实现，而是diff太脏。本来一个10行改动能解决的问题，它给你改出300行diff。里面有真正的功能修改，也有格式化，也有重命名，也有"它觉得更好"的小调整。最后Review的人根本不知道哪些是必要改动，哪些是附带噪音。

这会直接破坏团队协作。

在真实项目里，一个好的PR不只是要能跑，还要边界清楚。别人一眼能看出：你为什么改这些地方。

所以这个原则的核心不是"不要优化代码"，而是：不要在这次任务里优化不属于这次任务的代码。

你发现旁边有坏味道，可以提出来，但不要擅自改。这就是边界感。

第四层：把目标变成可验证的结果

第四条叫Goal-Driven Execution。这条我觉得是最有Agent味道的。

它不是让你对AI说"加个校验"，而是让AI把任务变成"为非法输入写测试，然后让测试通过"。它不是让你说"修这个bug"，而是让AI变成"先写一个能复现bug的测试，再修到测试通过"。

这两种说法差别很大。前者是在命令AI写代码，后者是在给AI一个可验证的目标。

《大学》里有句话：知止而后有定。

所谓“知止”，就是知道目标在哪里，知道做到什么程度算完成。 AI编程也是一样。AI真正适合做的事情，是围绕明确目标循环：尝试、运行、失败、分析、再改，直到通过。

所以我现在越来越觉得，用AI编程不能只说"帮我做什么"，更应该说清楚"什么叫做完"。

这个标准越硬，AI越不容易跑偏。"让它能跑"这种标准太弱，"测试通过、覆盖边界输入、diff只包含相关改动"这种标准才有用。

它为什么能拿到 15 万 Star？

表面看，这是一个配置文件火了。但更深层的原因是：开发者已经进入AI编程的第二阶段了。

第一阶段，大家关心的是：AI会不会写代码？

第二阶段，大家关心的是：AI写得快不快？

但现在越来越多的人开始关心第三个问题：AI写出来的东西，能不能稳定进入真实工程流程？

这才是关键。

真实开发不是写个demo。然后demo里AI生成一屏代码就很惊艳。实际在项目里，你要考虑历史包袱、测试方式、代码风格、Review、多人协作等。AI如果没有纪律，就会变成一个很能干但很难管的队友。它能帮你，也能添乱。

这个项目的价值就在于，它不是继续给AI加油门，它是在给AI加方向盘、刹车和车道线。这比单纯"让它更快"更重要。

我试下来，最明显的变化是什么？

如果只说一个体感，我觉得是：无关diff少了。

它不一定每次都完美，但至少它会更频繁地意识到：这不是我该碰的地方。

这件事很小，但对工程效率影响很大。因为AI编程的成本不只在生成阶段，更大的成本在后面。

你要Review，你要测试，你要确认它没有误伤导致bug。如果它能少制造一点噪音，整体体验就会好很多。

怎么用？

如果你用Claude Code，可以通过插件方式安装。项目里给了类似这样的方式：

# 在 Claude Code中，首先添加插件市场
/plugin marketplace add forrestchang/andrej-karpathy-skills

# 然后安装插件
/plugin install andrej-karpathy-skills@karpathy-skills

也可以直接把CLAUDE.md放进你的项目根目录。它的作用很简单：让Claude Code在这个项目里工作时，默认遵守这些规则。

如果你用Cursor，也可以参考项目里的Cursor规则文件。本质都一样：把AI编程的行为边界提前写清楚。

最后总结

这个项目最厉害的地方，不是它写了一份多神奇的Prompt。而是它提醒了我们一件事：AI编程的核心，不只是让模型更强，而是让模型更守规矩。

过去我们给人类程序员写代码规范、提交规范、Review规范。现在AI也进了开发流程，它同样需要规范。

你想下15万人Star，说明这件事真戳到了大家的痛点。

下一章节：聊一聊自己如何开发一个需求（OpenSpec、Superpowers、Spec-Kit）

我是赛博李同学，大厂写代码的，觉得有用点个赞 + 转发给需要的TA，感谢支持！，我们下期见！