📌 项目地址：multica-ai/andrej-karpathy-skills | ⭐ 135,410 颗星 | 📜 未标注
Karpathy 2024年发了条帖子，总结AI写代码的三个通病：默认替你做决定、喜欢堆抽象、改A时顺手弄坏B。帖子没给解法。有人把这三个问题翻译成四条约束，写进一个叫CLAUDE.md的文件，放到GitHub上，拿了135k颗星。仓库叫multica-ai/andrej-karpathy-skills，里面没有一行可执行代码，全是规则。
我把它用在一个20个模块、200多个文件的Python项目上，试了两天。效果实打实：AI跑偏的频率从大概每3次一次降到7-8次一次。下面说它做了什么，以及为什么有效。
Karpathy指出的三个硬伤
原话（摘自帖子）：
“模型替你做了错误假设，直接执行，不核对。它们不管理自己的困惑，不寻求澄清，不暴露矛盾，不展示权衡，在该推诿的时候不推诿。”
“它们真的喜欢把代码和API搞复杂，堆抽象，不清理死代码…用1000行实现一个臃肿的构造，实际100行就够了。”
“它们仍然会改掉/删掉理解不够的注释和代码，即使这些改动和任务无关。”
三个问题对应三个场景：替你决策、过度设计、改A带歪B。这些不是个例，是当前模型的一般行为。
一个文件，四条规则
项目不做任何自动代码生成，只是把下面四条规则写进CLAUDE.md，Claude Code会自动读取。
| 规则 | 对应问题 |
|---|---|
| 动手前先说假设 | 默认假设、隐藏困惑 |
| 最简实现 | 过度设计、堆抽象 |
| 只动该动的 | 改A带歪B、随意重构 |
| 测试先行 | 自验不可靠 |
规则1：动手前必须说出假设
文件原句：“State assumptions explicitly – If uncertain, ask rather than guess.”
我的真实案例：让Claude Code改一个API返回字段名，从user_name改成username。
不加规则时，它直接改了三个调用方的字段引用，还顺手改了测试用例的预期值。其中一个调用方藏在子模块里没被扫到，测试全红。
加上规则后，它先列出”发现4处直接引用，1处间接引用，是否一起改？有一个位置不确定是否与用户名相关，请确认。”
决策回到我手里。这条规则的机制很简单：把”我以为”转成”我怀疑”，由人做决定。LLM的”默认假设不澄清”问题被拆解成一条可执行指令。
规则2：200行能写成50行就重写
文件原句：“If 200 lines could be 50, rewrite it.”
我让Claude Code写一个支持多环境配置的日志收集器。不加规则时，它生成了工厂模式、策略模式、接口定义，七个文件。它设计了一个”可扩展的多环境配置框架”，尽管我只说了要日志收集。
加上规则后再来一次：它写了一个40行的函数，一个文件解决。
判断标准也写进了规则：“Would a senior engineer say this is overcomplicated? If yes, simplify.”
LLM天然倾向”扩展以防万一”，这条规则直接禁止了”可能有用”的预支设计。规则里还有更细的约束：
- 不实现没有要求的特性
- 不为单次使用的代码造抽象
- 不做没有要求的”灵活性”或”可配置性”
- 不为不可能出现的场景写错误处理
规则3：只动你该动的
文件原句：“Don’t ‘improve’ adjacent code, comments, or formatting. Don’t refactor things that aren’t broken. Match existing style, even if you’d do it differently.”
我试过让Claude Code重构一个类的构造函数，把参数提取成字典。没有规则时，它顺手把整个类的注释从”函数名加参数”格式改成了描述性段落，把私有变量命名从下划线改成驼峰。diff超过200行，真正需要改的只有5行。
加规则后，diff不到10行，只改了我指定的行。
规则还加了一条细节：如果你改动造成某些代码变成未使用（比如import、变量），你要自己清理掉。但前人的死代码不要碰，除非有直接冲突。文件原句：“Remove imports/variables/functions that YOUR changes made unused. Don’t remove pre-existing dead code.”
这意味着：该负责的地方负责，不该管的别管。
规则4：先写测试，再写代码
文件里这部分没有太多展开，核心是“Leverage through tests-first, verifiable success criteria”。
我试了一次：先写一个空的测试文件，里面列了三个测试用例，然后让Claude Code实现功能。第一次它通过了两个，第三个因边界条件失败。我补了一个检查后，它通过了。
以前的模式是AI自己设计测试、自己实现、自己验证，等于自己当裁判。外部测试的人为判断，比AI自我验证可靠。
其他值得注意的细节
文件里还写了一些具体的约束，不全是原则级，但都是实战经验：
- 不背”可能有用”的历史包袱。原文：“No error handling for impossible scenarios”。
- 当需要修改别人的代码时，保持原风格。即使你觉得原风格不好。
- 如果你注意到无关的死代码，可以”提到”它，但不要删除。
- 规则采用了Karpathy帖子的分类逻辑：每个问题对应一个解决方案。
适用边界
这四条规则解决的是Karpathy说的三类错误：默认假设、过度设计、改A带歪B。
它们解决不了B面的问题：需求本身错了、项目逻辑混乱、底层架构有根本问题。
另外，这个CLAUDE.md只对Claude Code生效。换成Cursor、GitHub Copilot不生效，因为提示词加载机制不同。项目也没有提供其他IDE的适配版本。
怎么用
把仓库里的CLAUDE.md复制到项目根目录，Claude Code启动时会自动读取。不需要写配置，不需要命令行。
如果你用Claude Code，这个文件值得试一下。它不会让AI理解你的业务，但能让一个盲干的AI学会先问、少做、只动该动的。这会省你大量重构时间。