一月底，Andrej Karpathy 在 X 上发了一段 claude coding 的随手记。没标题，没分章节，一整段意识流。
三天之内被疯转，Hacker News 八百多条评论，GitHub 上有人专门给它做了一份配套的 CLAUDE.md，三个月攒下 149K stars。仓库叫 multica-ai/andrej-karpathy-skills。
我会把 Karpathy 给 LLM 总结的 3 个老毛病和 multica-ai/andrej-karpathy-skills 的 4 条规则一起拆开来看 - Karpathy 描述的体感是什么、对应的 CLAUDE.md 怎么写、贴进项目根目录之后该看哪几个信号判断它生效。期望对大家有所帮助。
一条把所有 20 年老程序员都点了的推
Karpathy 这条推开篇就是一记重锤。他说，11 月份还是 80% 手敲、20% 让 Agent 写；到了 12 月，直接颠倒了 - 80% 让 agent 写，自己只做 20% 的收尾。
"I'm mostly programming in English now."
他没回避那种感觉，原话有三句挺有意思的 - 第一，有点伤自尊；第二，像在作弊；第三，过去 20 年没见过比这更大的工作流变化。
那种感觉相信很多人都体会过。坐在那儿看 agent 唰唰唰把两小时的活儿在两分钟里交了。理智上知道这是工程进步，情感上还是想问一句 - 我这 20 年是不是白学了。
LLM 这 3 个老毛病，至今没改
不过 Karpathy 没只夸，他给 LLM 总结了 3 个老毛病。
第一桩，沉默地假设。 模型替你做错误假设，然后一路跑下去 - 不验证、不澄清、不暴露不一致，该反推时也不反推。说白了，它不是没看到歧义，它是装没看到。
第二桩，过度复杂化。 100 行能搞定的事，它写成 1000 行的臃肿建筑。你说“做个待办应用”，它默认给你交一份企业级解决方案。
第三桩，顺手乱改。 修一个 bug，它顺手把没读懂的注释删了，把它觉得风格不对的函数重构了 - 哪怕跟你的任务毫不相关。
Karpathy 也给了处方，这句话挺核心的：
"Don't tell it what to do, give it success criteria and watch it go. Change your approach from imperative to declarative to get the agents looping longer and gain leveRAGe."
别下命令，定标准，让它自己跑。把命令式改成声明式。
但 Karpathy 并没有分享如何编写这么一份 CLAUDE.md 文件。
一个 149K stars 的仓库复现了它
仓库名字叫 multica-ai/andrej-karpathy-skills。一个文件，65 行 markdown，文件名就叫 CLAUDE.md，贴进项目根目录就能用。3 个月，149K stars，28 天 GitHub trending 第一。
爆火不是因为它发明了什么新东西，而是因为它把那种“我也这么觉得”的集体认同，蒸馏成了 4 条命名规则。这 4 条规则正好对症前面那 3 个老毛病。
先思考，再编码
对症“沉默地假设”。不假设，不藏起困惑，把权衡摊到桌面上。英文名 Think Before Coding。
举个例子，用户说，加个用户登录，你怎么接？
烂的反应是这样：“收到，我用 email + password 默认 hash 一下，加个 JWT，顺便把 users 表建了，加了 6 个字段。” - 认证方式、加密、过期时长、数据库结构，4 个假设它已经替你拍板了，全程你一句话没说。
好的反应是：“开始之前我得确认 3 件事 - email/password 还是 OAuth？session 还是 JWT？数据库里 users 表已经存在吗？” - 不确定就先问，别先写。
先求简单
对症“过度复杂化”。解决问题的最少代码，没要的别加，推测的别上。英文名 Simplicity First。
# BAD - 你只是想读个 JSON 文件class JSONLoaderFactory:def __init__(self, strategy, cache):self.parser_pool = ParserPool()def load_async(self, path, **kw):return self._with_retry(...)# 200 行,只被调用 1 次# GOOD - 就这两行with open(path) as f:data = json.load(f)
判据很简单：senior 看一眼会不会皱眉。会，就重写。
外科手术式修改
对症“顺手乱改”。只动你必须动的，只清理你自己制造的烂摊子。英文名 Surgical Changes。
修一个 token 过期的 bug，两种 diff：
# BADauth.py | +248 -187login.tsx | +92 -84utils.py | +34 -29PR 标题:"修 token 过期 bug" - review 的人根本不知道动了啥# GOODauth.py | +3 -1PR 标题:"修 token 过期 bug" - 每一行 diff 都能解释为啥要改
看见 utils.py 有死代码？在 PR 里提一句，但不动它。判据 - 每一行 diff 都能追溯到那个用户请求。
目标驱动执行
对症“标准模糊靠反复问”。先定成功标准，然后自己跑一轮验证。英文名 Goal-Driven Execution。
“加个邮箱校验”不是一个能让 agent 独立跑完的指令。弱标准的反应是写个 validate_email，return "@" in e，然后停在那儿等你确认。
强标准的反应是把指令翻译成可验证目标：
写 test_invalid_email()，verify 它失败实现 validate_email()，verify 测试通过跑全套 pytest，verify 0 failures
全绿就是“做完了”，它自己能判定。这就是 declarative，不是 imperative。
怎么用，以及一个 tradeoff
用法很简单。cd 进项目目录，把那份 CLAUDE.md 拉下来，跟你已有的合并，或者直接放到项目根目录：
curl -O https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
要说一个 tradeoff - 这套规则偏向谨慎而非速度。琐碎任务你自己用判断力就好，不必每次都让 agent 走完整套澄清流程。
判断它有没有在生效，看三件事：diff 更小，重写更少，澄清出现在动手之前。这三件事变成常态，它就在干活儿了。
Karpathy 那条推打动人的不是论点新鲜 - 而是它把一种大家都隐约感觉到的体感写明白了。LLM 是会替你做决定的实习生。你不告诉它哪些决定该问、哪些该等，它就一路替你拍板。multica-ai/andrej-karpathy-skills 这份 CLAUDE.md 做的事，就是把这条边界写出来给它看。65 行，贴进项目，你跟你那位“实习生”的合作，就上一个台阶。
