夜雨聆风早些时候，Andrej Karpathy发了一条长帖，分享自己密集写代码几周后的感受。
他说这是他二十年编程生涯中最大的工作流变化。编码比例从80%手写+20%AI，翻转成了80%AI+20%手动修改。
但帖子里真正有价值的部分，不是这个比例，而是他总结的AI写代码时的几个毛病。
模型会在你不知道的情况下做出错误的假设，然后一路跑下去，根本不回头检查。它不管理自己的困惑，不寻求澄清，不展示权衡取舍，该推回来的时候不推回来。它特别喜欢把代码搞复杂，过度抽象，不清理死代码，100行能解决的事情写1000行。它还会在你没要求的情况下，顺手改了旁边的代码和注释。
你如果用Claude Code或者Codex写过一段时间的代码，看到这几条会觉得，对，就是这样。
然后一个叫Forrest Chang的开发者，把Karpathy的这些观察提炼成了四条原则，写进一个CLAUDE.md文件，开源了。65行，一个markdown文件，现在152k star。
原则一：Think Before Coding — 先想，再写
这条针对的是模型「闷头往前冲」的问题。你给它一个模糊的需求，它不会问你「你确定是这个意思吗」，它会自己挑一个理解然后直接开干。等你发现它理解错了，代码已经写了几百行了。
这条规则要求AI在动手之前，把自己的假设显式地说出来。如果有多种理解方式，列出来让你选。如果觉得有更简单的方案，说出来。如果搞不清楚，就停下来问。
听起来很基础对吧。但模型默认真的不会这么做。
原则二：Simplicity First — 能简单就不复杂
这条针对的是模型的过度工程化倾向。你让它写一个简单的功能，它给你整一套完整的抽象层、配置系统、错误处理、扩展接口。你问它为什么，它说「为了将来的灵活性」。
但你没要求灵活性。
这条规则说得很直接，没人要求的功能不要写，单次使用的代码不要抽象，没人要求的「可配置性」不要加，不可能发生的场景不要做错误处理。如果200行能缩到50行，重写。
判断标准也给了：
如果一个资深工程师看了会说「这也太复杂了」，那就需要简化。
原则三：Surgical Changes — 精准改动
这条针对的是模型「顺手改别的东西」的问题。你让它修一个bug，它修了，然后顺手重构了旁边的函数，改了你的注释风格，调了一下缩进格式。
这些改动也许确实「更好」，但你没要求它做这些。而且这些额外的改动会污染你的diff，让code review变得困难，有时候还会引入新的bug。
规则是，只改你要求改的。旁边的代码、注释、格式，不要动。已有的代码风格，即使你觉得不好，也照着写。如果你的改动导致某些import或变量没人用了，清理掉，但只清理你自己造成的，不要动原来就存在的死代码。
每一行改动都应该能直接追溯到用户的需求。如果追溯不到，这行就不该改。
原则四：Goal-Driven Execution — 目标驱动
这条的思路有点不一样。它不是在限制AI，而是在教你怎么更好地使用AI。
Karpathy的原话是，LLMs非常擅长循环执行直到满足特定目标。不要告诉它做什么，给它成功标准，然后看着它跑。
这条规则建议你把指令性的任务转化成声明性的目标：
不要说「加一个验证」，而是说「写一个测试覆盖无效输入的情况，然后让测试通过」 不要说「修这个bug」，而是说「写一个能复现bug的测试，然后让它通过」 不要说「重构X」，而是说「确保重构前后测试都通过」
给AI一个可验证的终点，它自己会想办法到达那里。
为什么一个markdown文件能拿152k star
说到这你可能会想，就这？四条规则写成一个markdown文件，就能拿152k star？
我一开始也有点这种感觉。但仔细想想，这恰恰是它有意思的地方。
Karpathy在那条推里还说了一句，AI的能力在2025年12月前后跨过了某种连贯性的阈值，引发了软件工程的相变。
相变，phase shift。这个词用得很准。
水从99度到100度，还是水。从100度到101度，变成了蒸汽。物质没变，状态变了。
AI写代码这件事也在经历类似的过程。模型的能力到了一个临界点，从「辅助」变成了「主力」。当AI从写20%的代码变成写80%的代码，你和它的关系就变了。你不再是一个写代码的人，你变成了一个管理AI写代码的人。
管理AI写代码，和管理人写代码，核心问题其实是一样的，怎么让对方理解你的意图，怎么防止对方自作主张，怎么在对方犯错的时候及时发现。
Karpathy的四条原则，你把「AI」换成「新来的实习生」，每条都成立。先搞清楚需求再动手，别过度设计，别乱改别人的代码，每次改完跑一下测试。
这不是什么新道理。但问题是，AI不像实习生，你不能在工位旁边盯着它。你能做的，就是把这些规矩写进CLAUDE.md，让它每次启动的时候先读一遍。
这个文件能拿这么多star，不是因为它多高深，而是因为它把一个「大家都知道但不知道怎么落地」的问题，变成了一个可以直接copy-paste的解决方案。
怎么安装
如果你用 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如果你项目里已经有CLAUDE.md了，追加在后面就行：
echo"" >> CLAUDE.mdcurl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md
如果你用 Cursor，项目里也提供了对应的规则文件，在 .cursor/rules/karpathy-guidelines.mdc 路径下，打开项目就会自动生效。
装完之后会有什么变化
按照项目README和用过的人的反馈，主要是几个方面。diff变干净了，以前AI写完代码你看diff，里面一堆你没要求的改动，现在基本只剩你要求的。代码变简洁了，不会动不动给你搞一个过度设计的抽象层。AI开始问你问题了，以前它闷头就干，现在不确定的时候会停下来问你。PR变好review了，因为每一行改动都跟需求相关。
当然这些改善不是100%的。这个文件终究只是一个prompt层面的约束，模型底层的行为倾向还在那里。但在大部分场景下，效果是明显的。
我自己的感受是，这四条原则不只是在约束AI，它也在帮你养成更好的给AI下指令的习惯。
比如Goal-Driven Execution那条，它本质上是在教你，别说「帮我加个验证」，要说「帮我写个测试，测无效输入的场景，然后让测试通过」。后者的指令质量比前者高出一个量级，即使你不用这个CLAUDE.md文件，这个思路也值得学。
补充说明
这个仓库不是Karpathy本人做的，是开发者Forrest Chang根据Karpathy的推文提炼的。但Karpathy没有反对，社区也认可这个提炼的质量。152k star里面有很大一部分来自于「Karpathy」这个名字的信任背书，但内容本身确实是经得起检验的。
项目作者后来还做了一个叫Multica的开源平台，用来管理和运行编码Agent的可复用技能。CLAUDE.md只是他构想中的一个起点。
More
上次我们聊了nature-skills，一个把Nature论文的写作规范变成AI可执行规则的项目。这次的karpathy-skills，是把资深开发者关于代码质量的经验变成AI可执行规则。
这两个项目做的事情，底层逻辑是一样的，把某个领域里的隐性知识，结构化、显性化，然后写成AI能读懂的prompt。
我觉得这可能是接下来一段时间里非常重要的一个方向。AI的能力提升很快，但「怎么让AI用正确的方式使用这些能力」这个问题，还在靠社区里的聪明人一个一个场景地去解决。
每一个写得好的CLAUDE.md、SKILL.md、rules文件，都是在某个具体领域把「专家经验」翻译成了「机器可执行的规范」。
而你能做的最有价值的事情之一，是学会为你自己的工作流写这种规范。不管你是做开发、做科研、做设计还是做内容，你工作中那些「只有做久了才知道」的潜规则，都值得被结构化成AI能理解的指令。
项目地址：https://github.com/multica-ai/andrej-karpathy-skills
反正我觉得，不管你用不用Claude Code，这四条原则本身就值得看看。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～
感谢。
