夜雨聆风
AI 写代码总跑偏?把＂老工程师的脑子＂写成一份文件就行——拆解本周 GitHub 两个爆款 Skill 项目
你有没有过这种崩溃时刻：
让 AI 改一个 bug，它顺手把你三个不相关的函数也”优化”了一遍。
让它加个校验，它给你写了 200 行抽象层，说是”为了未来扩展”。未来在哪？没人知道。
让它修一个报错，它没复现就开始猜，猜了三轮，最后告诉你”应该没问题了”。你跑一下，原报错还在。
如果你天天和 AI 写代码，这些场景大概率你都中过。
很多人的反应是：换个更强的模型。Claude 4.7 不行换 GPT-5.5，再不行用 Opus，再不行……
但这周 GitHub 上发生了一件事，可能会改变你的判断。
两个项目同时冲上 GitHub Trending 前列，一周各自涨了 2.4 万 stars。它们做的不是模型，不是 IDE，不是 Agent 框架。
它们做的是一件特别朴素的事：把老工程师脑子里的”行规”，写成一份 AI 能读懂的文件。
一个叫 forrestchang/andrej-karpathy-skills（10.1 万 stars，一周 +24,129），一个叫 mattpocock/skills（4.8 万 stars，一周 +24,702）。
我把这两个项目都扒了一遍，发现它们指向同一个结论——
AI 写代码总跑偏，不是模型笨，是你没给它”规矩”。
说白了，Skill 不是让 AI 多知道一点，而是让 AI 少犯那些你已经踩过的坑——把你脑子里那些”不能那样写”的隐性知识，写成它能直接读懂的文件。
这篇文章我们就来聊聊：这个”规矩”到底长什么样，为什么 60 行的一个文件能改变 Claude Code 的行为，以及你今天就能抄走的最小实践。
一、Karpathy 的那条推文：捅破了一层窗户纸
事情起源于 Andrej Karpathy 在 X 上的一条吐槽。这位 OpenAI 早期员工、Tesla 前 AI 总监，平时不太骂人。但他在用 Claude Code 写代码的时候，连写了几段对 LLM 编程毛病的总结，被开发者圈广泛转发。
开源开发者 forrestchang 把这些观察整理出来，提炼成了大概这几条（下面是 README 里的转述，不是 Karpathy 原推文逐字翻译）：
模型会自己替你做错误假设，然后不检查就一路跑下去。它们不管理自己的困惑，不寻求澄清，不暴露不一致，不呈现权衡，该反驳的时候不反驳。
它们特别喜欢把代码和 API 复杂化，让抽象层膨胀，不清理死代码——本来 100 行能搞定的事，给你写成 1000 行。
它们有时候会改掉或删掉自己没完全理解的注释和代码——哪怕这些和当前任务八竿子打不着。
读完你大概会笑。这不就是每个用 AI 写过代码的人都遇到过的事吗？
Karpathy 还有一句话被 README 专门拎出来，是整套规则的核心：
LLM 极其擅长在明确的目标下循环。不要告诉它做什么，给它成功标准，看着它跑就行了。
forrestchang 做的事很简单——
把这些观察对应的解法，提炼成了一份 60 行的 CLAUDE.md 文件。
就这么一份文件。一周涨了 2.4 万星，总数冲到 10.1 万。
二、60 行的文件，凭什么值十万星？
我把这份文件完整看了一遍，核心就四条原则。
但这四条原则之所以让人眼前一亮，是因为它们每一条都精确对应了 AI 写代码的一个常见毛病。
原则一：先想清楚再写（Think Before Coding）
对应的毛病：AI 看到模糊指令，从不问，自己挑一个解释就开干。
文件里的规定是这样的：
不确定就明确说出来——拿不准就问，不要猜
有歧义就把所有理解列出来——别自己默默选一个
该反驳就反驳——如果有更简单的方案，请说出来
困惑就停下来——讲清楚什么不明白，然后问
你看这四条，没一条是技术活。全是”沟通规矩”。
但 AI 默认就是不遵守这些规矩的。它倾向于”显得有用”——哪怕代价是猜错方向。
原则二：能简单就别复杂（Simplicity First）
对应的毛病：AI 喜欢”过度工程”，能写 50 行的事写 200 行。
文件里直接列了五条禁令：
不写没要求的功能
不为一次性代码做抽象
不加没人要求的”灵活性””可配置性”
不为不可能发生的场景写错误处理
200 行能写成 50 行的，重写
最后还有一句话特别狠：
“测试方法：一个资深工程师看完会不会说这写得太复杂？会，那就简化。”
这是把”工程师品味”翻译成了”AI 能执行的检查项”。
原则三：精准修改（Surgical Changes）
对应的毛病：让它改 A，它顺手把 B 和 C 也”优化”了。
规定：
不”改进”无关的代码、注释、格式
不重构”没坏”的东西
即使你看不顺眼，也要匹配现有风格
看到无关的死代码？提一句，但别动手
“测试方法：每一行被改的代码，都应该能直接追溯到用户的请求。”
这条原则，劝退了一批”AI 强迫症式重构”。
原则四：目标驱动执行（Goal-Driven Execution）
对应的毛病：AI 干完活儿不会自己验证，”应该可以了吧”就交差。
规定是把命令式任务，全部翻译成”可验证的目标”：
| 模糊指令 | 翻译成目标 |
|---|---|
| “加个校验” | “先写测试覆盖非法输入，然后让测试通过” |
| “修这个 bug” | “先写一个能复现 bug 的测试，然后让它通过” |
| “重构 X” | “保证重构前后测试都通过” |
这就是 Karpathy 那句话的具体化——给 AI 成功标准，而不是命令。
这四条原则，没有一条用到了什么前沿技术。没有 RAG，没有 fine-tuning，没有多 Agent 架构，没有 MCP。它就是一份用人话写的、给 AI 看的工程守则。
但它解决了一个真问题：AI 不是没能力写好代码，是它没有”自我约束”。 它需要一个外挂的、显式写出来的”老工程师的脑子”。
这就是为什么 60 行的一份文件能在一周内涨 2.4 万星——绝大多数人不需要更聪明的模型，需要的是让现有模型”别犯老毛病”。
三、另一个爆款项目：把”工程纪律”做成了一整套工具箱
如果说 karpathy-skills 是”哲学层面的四条戒律”，那 mattpocock/skills 就是”工程层面的工具箱”。
Matt Pocock 是 TypeScript 圈很有名的教育者，做过 Total TypeScript 等多个广为流传的课程。他做这套 Skills 的动机更直白——
他在用 Claude Code、Codex 这些 agent 的时候，反复遇到四种失败模式。
他把每一种失败模式都做成了一个或一组 Skill。
失败模式 1：Agent 没干你想要的事
根本原因：人和 agent 之间的对齐缺口。你以为你说清楚了，结果它做出来的完全不是你要的。
他的解法：/grill-me、/grill-with-docs。
这两个 Skill 干的事很奇葩——它会反过来”拷问”你。
你说”我想加个搜索功能”，它会一连串问你：
搜什么？全文？标题？
命中后排序规则是什么？
多语言怎么处理？
用户搜不到结果时显示什么？
这个功能什么时候应该被关掉？
直到每一个分支都被你确认完毕。
mattpocock 说这是他最常用的两个 Skill。理由很简单——绝大多数 AI 写出来的烂代码，问题不在”写”，在”开始写之前没问清楚”。
失败模式 2：Agent 太啰嗦
根本原因：agent 不懂你项目里的”行话”，所以它用 20 个词描述一个能用 1 个词说清楚的概念。
他的解法：让 agent 帮你建一套项目级共享语言（CONTEXT.md）。
每次重要的设计决策都记录到 ADR（架构决策记录）里。
这件事的妙处是：共享语言一旦建立，agent 写出来的变量名、函数名、文件名都会自动对齐——它不再是个项目门外汉，token 消耗也会显著下降。
mattpocock 在 README 里说：
“这可能是这个仓库里最酷的一个技巧。试试看，你就知道了。”
失败模式 3：Agent 写出来的代码不工作
根本原因：agent 没有可靠的反馈循环。它在盲飞。
他的解法：/tdd、/diagnose。
/tdd 强制走”红-绿-重构”循环——先写一个失败的测试，再让它通过。
/diagnose 把调试拆成一套纪律：
code
复现 → 最小化 → 假设 → 加埋点 → 修 → 回归测试
每一步都不能跳。
为什么这个有用？因为 AI 默认的调试方式是”猜”。你不强制它复现，它就直接开始改代码。改三轮还在猜。
把”先复现、再最小化、最后修”写进 Skill，AI 就会按流程走。这听起来像废话，但效果差到天上去。
失败模式 4：项目变成一坨烂泥
根本原因：agent 让写代码变快了，但同时也让代码熵增加快了。一周时间，能搞出别人三个月的”屎山”。
他的解法：/improve-codebase-architecture。
这个 Skill 的定位很清晰——每隔几天跑一次，专门帮你”救”那些已经开始烂的部分。
它会去看你的 CONTEXT.md（共享语言），看 ADR（决策记录），然后告诉你哪些模块开始变得”过浅”——意思是，这块代码做了很多事，但接口设计没体现出来。
这是 John Ousterhout 在《A Philosophy of Software Design》里讲的”deep modules”思想——好模块是深的：用简单接口暴露复杂功能。
mattpocock 把这条工程哲学，做成了一个 AI 能跑的 Skill。
四、对比一下：两个项目，一个共识
如果你现在去看这两个项目，会发现它们风格完全不同：
| karpathy-skills | mattpocock/skills | |
|---|---|---|
| 形态 | 一份 60 行的 CLAUDE.md | 十几个独立 Skill 文件 |
| 风格 | 哲学戒律 | 工程工具箱 |
| 对应的痛点 | AI 思维方式不对 | AI 执行流程不对 |
| 怎么开始 | 5 分钟抄过来就能用 | 按需挑一两个 Skill 装上 |
但它们在同一周内一起爆火，指向的是同一个共识：
AI 写代码的胜负手，已经不在模型的能力上，而在你给它套了什么”行为约束”。
karpathy-skills 解决的是“想”的层面——让 AI 不要乱猜、不要乱加、不要乱删。
mattpocock/skills 解决的是“做”的层面——让 AI 在关键流程节点上走纪律，而不是凭感觉。
两件事合起来，才是一个完整的”老工程师的脑子”。
五、Skill 的本质：把工程经典做成 AI 能读的接口
我看 mattpocock 的 README 的时候，注意到一件事——他每讲一个失败模式，都先引一段几十年前的工程经典：
讲对齐，引《The Pragmatic Programmer》：”没人确切知道自己要什么”
讲共享语言，引 Eric Evans 的《Domain-Driven Design》
讲反馈循环，引”反馈频率决定你的速度上限”
讲架构，引 Ousterhout 的《A Philosophy of Software Design》、Kent Beck 的《Extreme Programming Explained》
这些书全是 2000-2018 年之间出版的，在 AI 出现之前就存在很多年了。但这两年才开始写代码的人，大多没读过。
AI 默认也不懂这些。它需要你显式地把这些原则写下来，喂给它。
这就是 Skill 的本质——把人类几十年积累的工程纪律，做成 AI 能直接读取的接口。它不是 prompt（一次性的），也不是 RAG（被动检索的），它是主动加载的、行为级的约束。
▲ Skill 本质：把工程经典变成 AI 可读接口
模型趋同了。Claude 4.7、GPT-5.5、DeepSeek V4、Qwen 3.6，能力其实差不多。真正拉开差距的，是你有没有把团队/个人的工程经验，沉淀成 AI 能直接读懂的文件。
六、你今天就能抄的最小实践
讲了这么多，给你三个今天就能用的动作。
第一步：先抄 karpathy-skills 的 CLAUDE.md
这是成本最低的事。一行命令搞定：
bash
curl -o CLAUDE.md \ https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
如果项目已经有 CLAUDE.md，把这份内容粘贴到末尾就行。
立刻就能感受到 AI 行为的变化——不该改的不改了，会问问题了，会先看代码再动手了。
第二步：建一份你项目的 CONTEXT.md
不需要写得很完整。先列清楚：
这个项目是干什么的（一句话）
项目里高频出现的”行话”和它们的定义（比如”订单”特指什么、”用户”和”客户”的区别）
几条铁律（比如”所有 API 都必须有测试””日志必须用结构化格式”）
让 AI 每次开始干活前先读这份文件。它的话痨问题、瞎猜问题，会肉眼可见地下降。
第三步：把你最常踩的坑，做成一个 Skill
这一步是最值钱的。
回忆一下，你跟 AI 协作时最常重复说的那句话是什么？
“先复现 bug 再改”
“改完跑测试”
“不要写没要求的功能”
“用 TypeScript 严格模式”
“提交前过一遍 lint”
这些重复说的东西，全都应该被写进一个 Skill 文件，而不是每次重新打字。
mattpocock 把这件事提炼成了 /write-a-skill——一个专门用来生成 Skill 的 Skill。你也可以直接抄。
七、最后说一句
你公司里那个最让你放心的老工程师——
他比新人强的地方，从来不是脑子转得快、打字快、能抗996。
他强在脑子里有一肚子”不能那样写”的隐性知识：哪段代码不能轻易动，哪种命名是项目的惯例，哪个边界条件历史上踩过坑，哪种”看起来更好”的重构其实会引爆三个下游模块。
这些东西没写在任何文档里。它们存在于他的肌肉记忆、他的代码品味、他对项目的理解里。
AI 现在缺的，就是这一肚子东西。
它不是不能写好代码，它是没人把这肚子东西显式地抄给它。
Skill 这个事，本质上就是把老工程师的隐性知识，逼成显性的、可执行的、AI 能直接读懂的文件。
写一次，AI 永远记得。比任何”换更强的模型”都管用。
如果你也被 AI 写代码的奇怪行为折磨过，今天就动手试试。
先抄 60 行的 CLAUDE.md，再写一份属于你项目的 CONTEXT.md，最后把你最常对 AI 重复的那句话，变成一个 Skill。
三步搞完，你会发现一件事——
那个让你天天崩溃的 AI，其实从一开始就听话，只是没人告诉过它规矩。