AI大神卡帕西Andrej Karpathy通过长期实践总结了LLM在编程中的系统性缺陷，而Github社区把这些“失败模式”工程化，变成一个可执行的行为约束文件CLAUDE.md，点击标题！
这个项目到底解决什么问题
很多人让AI写代码都会遇到同一个头疼的问题。AI像一个刚入职的实习生，特别兴奋特别想表现，结果做出来的事情让你想砸电脑。
你让它写一个简单的函数，它给你造出一整套架构。
你让它修复一个bug，它顺手把半个项目重构了。
你明明三句话前说了不要加额外功能，它全忘了，给你塞了一堆你根本没要求的代码。
这不是你一个人遇到的问题，这是所有人用AI写代码都会遇到的稳定翻车模式。
卡帕西Andrej Karpathy，这位AI领域的顶级专家，系统性地把这些失败模式一个一个记下来，像一个医生记录病人的症状一样精确。他没有停留在抱怨层面，而是把这些观察直接转化成一个配置文件。这个配置文件的名字叫做andrej-karpathy-skills，过去一周获得了超过三千七百个星标。人们疯狂转发使用，因为它真的管用。
这个项目本质上做了一件非常简单又非常聪明的事情。它不训练新模型，不写新框架，不做任何复杂的技术创新。它就是把Karpathy观察到的那些失败模式，逐条翻译成AI能看懂的行为规则。
你把这个配置文件丢给Claude或者其他AI编程工具，AI就会像戴上了紧箍咒一样，行为立刻变得稳重可靠。
核心文件只有一个，叫做SKILL.md，或者在某些版本里叫CLAUDE.md。
你把它放在项目的根目录下面，AI每次启动的时候自动读取，不需要你在每个对话里重新教一遍，不需要你像保姆一样盯着它。一次配置，永久生效。
卡帕西的三大经典翻车模式
第一个翻车模式叫做过度发挥。
你让AI写一个函数判断用户是不是成年了，它给你生成一个完整的用户年龄验证系统，包含数据库查询、缓存策略、日志记录、异常处理，甚至还给你加了一个管理后台的接口。你看着几百行代码完全不知道说什么好。你只是想要一个简单的if语句而已。
AI的问题在于它不知道什么叫够用，它总是觉得越多越好，越复杂越显得自己厉害。这就像一个实习生做汇报，明明只需要三页PPT，他做了三十页，每一页都塞满了动画和图表，反而把核心信息淹没了。
第二个翻车模式叫做瞎猜需求。
你给AI说写一个函数读取配置文件，它自己脑补出你要支持JSON、YAML、TOML三种格式，还自动实现了热加载和文件监控。你根本没有提这些需求，它自己就加了。更可怕的是它不会问你，不会确认，它觉得自己猜得很对。
这就像一个服务员你点了杯水，他给你端来一杯加了柠檬、薄荷、冰块和苏打水的高级特调，还收了你三十块钱。你只是渴了想喝水而已。
AI的这种行为源自它的训练方式，它被训练成要尽量提供完整的答案，但它分不清什么是用户真正需要的，什么只是它自己脑补出来的。
第三个翻车模式叫做大刀阔斧乱改。
你让AI修复一个简单的空指针异常，它看完代码之后觉得这个函数命名不规范，那个变量作用域可以优化，整个类的设计模式可以升级，于是它开始大规模重构。最后空指针异常确实修好了，但是另外五个之前能正常工作的功能全崩了。你问它为什么改那些没问题的代码，它会告诉你它觉得这样更好。你不想要更好，你想要它只修那个bug。这就像一个水管工来修你厨房的水龙头漏水，他顺手把你整个房子的水管系统全换了，还收了你十倍的钱。你的水龙头确实不漏了，但你家所有房间都在喷水。
四条核心规则怎么压制AI的错误行为
第一条规则叫做写之前先动脑。
AI默认的行为模式是拿到需求直接开写，写到哪算哪，遇到问题临时想办法。这个规则强制AI在写任何代码之前，必须先说清楚自己的假设，把理解的需求复述一遍。如果有歧义的地方必须停下来问清楚，不能自己瞎猜。如果有多种实现方案，要列出来让用户选，不能自己决定。如果不确定某个技术细节，不能蒙混过关，必须明确表示不知道。这条规则的本质是禁止AI先写再说。你想想看，一个靠谱的工程师接到任务之后，第一件事绝对不是打开IDE开始敲代码，而是先确认需求，先理解问题，先设计方案。AI现在被迫这样做，它的行为自然就稳了。
第二条规则叫做能简单就别复杂。
这条规则的核心思想非常直接，能写五十行代码解决的问题，绝对不写两百行。AI被严格禁止添加任何用户没有要求的功能。你让它写一个函数，它就只写那个函数，不加额外的方法，不加辅助工具类，不加未来的扩展接口。它被禁止搞任何抽象，除非这种抽象在当前这个需求里面是绝对必要的。它不能提前设计未来的扩展，因为未来可能根本不需要那些扩展。这条规则直接砍掉了AI的自嗨设计能力。很多AI写出来的代码之所以看起来过度设计，就是因为AI喜欢炫技，喜欢展示自己会多少设计模式，会多少高级特性。现在这些全部被禁止了，AI只能老老实实写最简单直接的代码。
第三条规则叫做外科手术式修改。
这条规则最狠也最实用。AI被强制要求只修改你明确要求它修改的地方。它不能顺手优化别的代码，哪怕它觉得那些代码写得很烂。它不能重构任何没有问题的部分，哪怕它觉得用另一种设计模式会更优雅。它必须保持原有的代码风格，哪怕那种风格在它看来很丑很过时。它只被允许清理自己造成的垃圾，比如修改过程中产生的临时变量或者未使用的导入。
这条规则杜绝了AI顺手帮你改一切的行为。你想象一下外科医生做手术，你说切除阑尾，他绝对不会顺手帮你把扁桃体也切了，哪怕他觉得你的扁桃体也不健康。AI现在就像一个有纪律的外科医生，你说切哪里它就只切哪里，其他地方绝对不动。
第四条规则叫做目标驱动执行。AI常见的问题是我觉得应该可以了，然后就把代码交给你。这条规则强制每个任务都必须有可验证的标准。AI在写任何代码之前，必须先想清楚怎么验证这段代码是正确的。如果是修bug，它必须先写一个能复现那个bug的测试用例，然后才开始修代码。代码修完之后跑那个测试，通过了才算完。如果是加新功能，它必须先写测试用例描述这个功能应该怎么工作，然后再实现功能代码。每一步都有检查点，每一步都要验证通过才能走下一步。
这条规则的本质是把从感觉对了变成验证通过了。你想想看，一个工程师如果每次修改代码都先写测试，他的代码质量会差到哪里去。AI现在被迫这样做，它的输出自然就可靠了。
这个项目为什么突然火了
因为它命中了一个所有人都遇到但没人系统性解决的问题。市面上所有的AI编程工具都在比谁更聪明，谁能力更强，谁能处理更复杂的任务。没有人想过让AI变笨一点，让AI变克制一点，让AI不要那么积极主动。
Karpathy的思路正好反过来了，他发现AI的问题不是不够聪明，而是太聪明太主动太想表现了。AI像一个刚毕业的天才学生，满脑子都是最新最酷的技术，你让他写一个简单的链表，他给你写一个支持并发访问的跳表。你不需要那个，你只需要链表而已。
这个项目之所以有效，底层逻辑非常清晰。传统优化AI写代码的思路是提高模型能力，或者提高prompt的复杂度，写几百行甚至上千行的prompt来约束AI。但模型能力的提升需要大量的训练数据和计算资源，prompt越写越长，AI反而越容易忽略其中的关键指令。
Karpathy这个项目的做法是反过来，不追求让AI更聪明，而是追求减少AI犯错的空间。你把AI可能犯错的路径一条一条堵死，它自然就只能走正确的路。这是一种工程哲学上的转变，从增强能力转向减少缺陷。限制大于能力，这句话听起来反直觉，但在AI行为约束这个场景下，它完全正确。
这个项目还有一个特别聪明的地方，它把Karpathy的观察逐条翻译成了AI能直接执行的指令。你不需要理解Karpathy的原话，不需要学习他的思维方式，你只需要把这个配置文件丢给AI，AI自己就会按照Karpathy的方式工作。这就像一个菜谱，你不用知道那个大厨为什么这样搭配调料，你只要按照菜谱做，你就能做出和大厨一样味道的菜。这个项目就是一个AI行为的大厨菜谱，而且是Karpathy这个级别的大厨写的。
怎么使用这个项目
使用方法非常简单，你不需要会编程，不需要懂AI技术，只需要会复制粘贴一行命令。
你先安装skills这个工具，然后运行npx skills add加上这个项目的GitHub地址，再指定一个技能名字。
这行命令会把配置文件下载到你本地的技能库里面。然后你把它接入到你使用的AI编程工具里面。
这些工具包括Claude Code、Cursor、Codex CLI、Gemini CLI等等。这些工具会把配置文件当成系统级的行为约束，每次AI开始工作之前自动加载这些规则。
你不用在每个对话里面重复输入那些指令，不用写长长的prompt告诉AI不要做什么。你只需要做一次配置，后续所有的对话里面AI都会自动遵守这些规则。这就像给你的电脑装了一个杀毒软件，装一次之后它就在后台自动运行，你不用每次开机都重新配置一遍。这个配置文件就是AI编程的杀毒软件，它持续工作，持续约束AI的行为，让你不用一直盯着AI干活。
这个项目还有一个特别适合团队使用的特性。你把配置文件放在项目的根目录下面，并且提交到代码仓库里面。团队里面每个人拉取代码的时候都会得到这个配置文件，所有人的AI工具都会遵守同一套行为规范。这保证了团队协作的一致性，不会出现你用的AI按照你的方式工作，别人用的AI按照别人的方式工作，最后代码风格混乱的情况。这就像团队统一使用同一个代码格式化工具，所有人的代码看起来像同一个人写的。只不过这个配置文件约束的不只是代码格式，而是AI的整个行为模式。
这个项目适合什么场景
这个项目最适合的场景是生产环境下的代码修改和调试。当你的项目已经上线运行，代码已经经过测试相对稳定的时候，你绝对不想要AI胡乱改东西。你只想要AI精确地修复某个bug，或者精确地添加某个小功能。这个配置文件正好满足这个需求，它让AI像外科医生一样精准操作，不会波及周围的健康组织。你在生产环境里面用AI修bug的时候，这个配置文件就是你的保险丝，防止AI把整个系统搞炸。
第二个适合的场景是代码重构。
重构是一个风险很高的操作，你需要在保持外部行为不变的前提下改变内部结构。AI如果不加约束地去重构，很容易引入微妙的bug或者改变原有行为。这个配置文件强制AI只修改你指定的部分，保持原有风格，不顺手优化别的地方，这正好符合安全重构的要求。你让AI帮你重构一个函数，它只会改那个函数，不会改调用那个函数的地方，不会改被那个函数调用的地方，不会改任何看似相关但实际上你还没准备好修改的地方。
第三个适合的场景是Agent工作流。
当你用多个AI Agent协同工作的时候，每个Agent都需要遵守相同的行为规范，否则整个系统会变得混乱。这个配置文件提供了一个统一的行为基线，你让所有Agent都加载同一个配置文件，它们的工作方式就会保持一致。这就像一支军队里面所有士兵遵守同一套纪律，每个人都清楚什么能做，什么不能做，整个系统的可靠性大大提升。
这个项目不太适合的场景是创意代码编写和快速原型开发。当你想要快速尝试一个想法，想要看AI能想出什么新奇的方案的时候，这个配置文件的约束可能会让你觉得太慢太死板。它强制AI先思考后动手，强制AI保持简单，这会让AI失去一些创造性的空间。快速原型开发的时候，你反而希望AI大胆尝试，哪怕偶尔过度设计也没关系，因为你只是验证想法，后面还会重写。
所以你要根据场景选择是否使用这个配置文件，不是所有场景都适合。