一份来自 Karpathy 的 AI 编程 skill

一份来自 Karpathy 的 AI 编程 skill

2026 年 1 月底的一个清晨，Andrej Karpathy 在 X 上发了一条很长的 post

他坦白：过去两个月自己已经从「80% 手写 + 20% agent」彻底翻转成「80% agent + 20% 手写」，

一、Karpathy 的那条长贴：大神承认自己被 agent 接管了

Andrej Karpathy 是谁不用多介绍——OpenAI 创始成员、特斯拉 AI 总监、Stanford 那门 CS231n 课程的传奇老师。一个把人类怎么训练神经网络这件事手把手教给整整一代 ML 工程师的人。这种背景的人，过去十年里基本没怎么"被工具改变过"——他是定义工具的人。

但 1 月底那条 post 里他说的是另一件事——他在复盘 2025 年 11 月到 12 月这两个月的转变：

I rapidly went from about 80% manual+autocomplete coding and 20% agents in November to 80% agent coding and 20% edits+touchups in December. ...This is easily the biggest change to my basic coding workflow in ~2 decades of programming and it happened over the course of a few weeks.

翻译过来——一个写了 20 年代码的人，用了几周时间，写代码方式被彻底翻转。他自己加了一句"a bit sheepishly"（有点不好意思）。

这条 post 的真正价值不在"agent 厉害"这个判断，那是个老生常谈了。它的价值在于 Karpathy 接下来花了相当大的篇幅，列出 agent 现在还在犯的所有错：

• 它们不会管理自己的困惑（don't manage their confusion）
• 它们不主动澄清（don't seek clarifications）
• 它们不暴露不一致（don't surface inconsistencies）
• 它们不呈现 tradeoff（don't present tradeoffs）
• 它们该 push back 的时候不 push back，还有点谄媚（still a little too sycophantic）
• 它们喜欢过度复杂化代码和 API（really like to overcomplicate code and APIs）
• 它们让抽象层膨胀（bloat abstractions）
• 它们事后不清理死代码（don't clean up dead code after themselves）
• 它们会做错的假设并一路狂奔（make wrong assumptions on your behalf and just run along with them without checking）
• 它们会顺手改掉它"不喜欢或没看懂"的注释（sometimes change/remove comments and code they don't like or don't sufficiently understand as side effects）

这一连串描述，让我想到一个比喻：

一个聪明、勤奋、永远不累、但有点鲁莽和爱面子的实习生。

如果你管过这种实习生，你大概也经历过——他不是不行，是需要被管。Karpathy 后面几段反复强调"watch them like a hawk"——你得像鹰一样盯着它。

我把他这条 post 通读三遍后，最深的感受不是"AI 多强"——而是当一个最有能力训练 LLM 的人都开始用一种"管教初级工程师"的语气在描述 LLM 的时候，"驯服 LLM"这件事就从一个工程话题，变成了一个组织话题。

skills 仓库就是在这个组织话题里冒出来的。

二、karpathy-guidelines：100 行的 markdown 长什么样

先把出处说清楚，免得后面读得稀里糊涂——

GitHub 上有个仓库叫 multica-ai/andrej-karpathy-skills，把 Karpathy 那条 post 里的观察直接提炼成了一组 skills，最核心的一个就叫 karpathy-guidelines。

这个仓库不是 Karpathy 本人维护的。Karpathy 的 GitHub 账号是 karpathy，和这个仓库无关。仓库 README 自己写得很坦诚——"derived from Andrej Karpathy's observations"（衍生自 Karpathy 的观察）。真正的整理者是一个叫 forrestchang（Jiayuan） 的开发者，仓库早期路径还是 forrestchang/andrej-karpathy-skills，后来转入了他自己的组织 multica-ai——这个组织还在做一个同名的 agent 平台产品 Multica，这份 skill 仓库一定程度上带有产品推广性质。

为什么我还要花一整篇文章拆它？两个原因：

1. 观察源头是真的——所有 4 条原则都能在 Karpathy 那 3000 字原帖里找到出处，不是凭空发明。
2. 整理动作本身比内容更值得讲——一个社区开发者把大神散落在长贴里的零碎吐槽，整理成 100 行 markdown，让 LLM 能直接执行——这件事的范式意义比"Karpathy 说了什么"本身大得多。

带着这层背景，再看正文。整个 SKILL.md 文件不到 100 行，我把它的结构原样贴出来，再逐行解释——

---
name: karpathy-guidelines
description: Behavioral guidelines to reduce common LLM coding mistakes.
license: MIT
---# Karpathy GuidelinesBehavioral guidelines to reduce common LLM coding mistakes,
derived from Andrej Karpathy's observations on LLM coding pitfalls.**Tradeoff:** These guidelines bias toward caution over speed.
For trivial tasks, use judgment.## 1. Think Before Coding
## 2. Simplicity First
## 3. Surgical Changes
## 4. Goal-Driven Execution

四个章节，每章十几行字。注意 description 这一行——

Behavioral guidelines to reduce common LLM coding mistakes.

它没说"让 AI 写更好的代码"，它说的是减少 LLM 的常见错误。一字之差，定义了整个 skill 的姿势：不是积极进攻，是消极防御。

这个姿势比看起来反直觉。过去一年大量的 prompt engineering 都是"让 AI 表现得更好"——给它角色、给它示例、给它思维链。这份 skill 反过来——它假设 AI 已经够强了，问题是它的下限太脆弱。

它还有一句话很有意思：

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

直译：这些指南偏向审慎而非速度。对琐碎任务，自己判断。

把 tradeoff 显式写在 skill 开头，本身就是一种纪律的姿态——它不假装自己是普适真理。这一点对 Matt 那批 skills 也成立，是 skill 这种原语的共性：它接受自己有适用边界。

下面我把这 4 条原则一条条拆开看。

三、四条原则，逐行拆

原则 1：Think Before Coding——别假设、别藏困惑、把 tradeoff 摆出来

原文（我做了直译）：

不要假设。不要隐藏困惑。把 tradeoff 摆出来。

在动手实现之前：

• 显式说出你的假设。如果不确定，就问。
• 如果存在多种解释方式，把它们都呈现出来——不要默默选一个。
• 如果有更简单的方法，就说出来。该 push back 时就 push back。
• 如果有什么不清楚，停下。指出哪里令你困惑。问。

对照 Karpathy 原文那段——

they don't manage their confusion, they don't seek clarifications, they don't surface inconsistencies, they don't present tradeoffs, they don't push back when they should

完全一一对应。skill 这一节做的事情很简单——把 Karpathy 列出来的 5 条缺陷，一条条翻面写成 5 条要求。

我自己有个直观的统计：过去半年我让 Claude Code 处理过的中等复杂度任务里，70% 以上的错，根因不是"它写错了代码"，而是"它在某个分叉处默默选了一条路，然后一路狂奔"。等你看见结果时，它已经在错的方向跑了 200 行。

举个真实场景。我前阵子让它"把这个接口加上鉴权"。它默默假设我想用 JWT，默默假设要写一个中间件，默默假设要落库 session。三个假设里只要一个不对，整段代码就要重写。

但如果它一开始就停下来问：

我看到这里有两种鉴权风格的痕迹（中间件 / 装饰器），我倾向用中间件。同时我假设你希望使用 JWT 而不是 session——是这样吗？

这两句话的成本是 3 秒。但它能省你 200 行后再 git reset 的痛苦。

这条原则在 4 条里最容易被低估——它没什么花哨的内容，就是逼 AI 把"沉默的假设"变成"显式的提问"。但实操上，它救我命的次数最多。

原则 2：Simplicity First——能 50 行别写 200 行

原文：

解决问题所需的最少代码。不做任何投机性的事。

• 不实现没要求的功能。
• 不为一次性代码做抽象。
• 不加任何没要求的"灵活性"或"可配置性"。
• 不为不可能发生的场景写错误处理。
• 如果你写了 200 行，而它本可以是 50 行，重写它。

问问自己："一个资深工程师会觉得这过度复杂了吗？" 如果是，简化它。

对照 Karpathy 原文那段——

They will implement an inefficient, bloated, brittle construction over 1000 lines of code and it's up to you to be like "umm couldn't you just do this instead?" and they will be like "of course!" and immediately cut it down to 100 lines.

一千行变一百行，10 倍。这不是夸张——任何用过 Claude Code / Codex 的人都见过。

为什么 LLM 这么爱过度工程化？我觉得有两个原因：

1. 训练数据偏 senior——它读过的大部分代码是企业级框架，不是脚本。它的"默认审美"自带一层 over-engineering。
2. 没有"代价感"——人写 200 行代码累，累就会想"能不能少写点"。LLM 不累，写 200 行和写 50 行对它一样。它没有那个本能的偷懒驱动力。这听起来反直觉——人之所以能写出简洁的代码，恰恰是因为人懒。

所以这条 skill 在做的事，是把人类的"懒"显式注入回去。"如果你写了 200 行，而它本可以是 50 行，重写它"——这是一句外部约束，因为内部约束（懒）没了。

这条原则有一个特别值得拎出来的小尾巴：

不为不可能发生的场景写错误处理。

LLM 写 try/except 的频率，可以用"病态"来形容。它会给一个内部函数包三层 try，处理一些根本不可能抛出的异常。这种代码不是"防御性"，是噪音——它会让真正重要的错误处理淹没在垃圾里。

我有时候觉得，"少写代码"这件事，是 LLM 时代第一个需要被重新发明的工程美德。过去十年我们一直在跟"代码膨胀"作斗争——但那是和人类的 boilerplate 习惯斗，和企业级框架的过度抽象斗。LLM 把这场战争翻新了一遍——它的"膨胀"不是因为它在偷懒，恰恰是因为它太"勤快"。

原则 3：Surgical Changes——只动你必须动的，只清理你自己造的烂摊子

这是我最喜欢的一条。原文：

只动你必须动的。只清理你自己造的烂摊子。

编辑现有代码时：

• 不要"改进"邻近代码、注释或格式。
• 不要重构没坏的东西。
• 匹配现有风格，即使你会用不同的方式写。
• 如果你注意到无关的死代码，提一下——别删它。

当你的修改产生孤儿代码时：

• 删除你的修改导致未被使用的 imports / 变量 / 函数。
• 不要删除已存在的死代码，除非被要求。

测试方法：每一行变更都应能直接追溯到用户的请求。

对照 Karpathy 原文：

They still sometimes change/remove comments and code they don't like or don't sufficiently understand as side effects, even if it is orthogonal to the task at hand.

这条对应的现象其实是 LLM 编程里最阴险的一种：漂移修改（drift edits）。

你让它修一个 bug，它顺手把旁边的注释改了，把一段它"看不顺眼"的代码重写了。它做这些事的时候不会告诉你，因为它觉得这是顺手的好事。

但漂移修改的代价远超它的善意：

• 你 review 的范围被无端放大
• diff 里掺进 N 个无关变更，code review 时你抓不住重点
• 多人协作时，一个 PR 改了五个无关的人的代码，merge 冲突地狱
• 最致命的——它"看不懂所以删掉"的那段代码，可能正是某个边角逻辑

skill 给出的判断标准非常硬核：

每一行变更都应能直接追溯到用户的请求。

这一条标准如果落到团队的 code review 模板里，几乎可以当作 AI 时代 PR 评审的第一条铁律。它简单、可执行、不容狡辩——你拿不出"这一行为什么改"的理由，那就回滚。

更妙的是 skill 对"死代码"的处理方式：

• 你的修改产生的孤儿，必须删
• 已经存在的死代码，不许动

这是一种很微妙的克制。LLM 的本能是"看见死代码就想清理"，但 skills 的设计者大概是想到了——别人代码库里的死代码，你不知道它为什么死，可能它在等某个 feature flag 复活。

我自己最怕 LLM 的不是它写错代码，而是它"出于好意"改我没让它改的东西。它的善意比它的恶意更难防——恶意至少会被你的 review 抓住，善意会被你"哦它顺手帮我整理了一下"地放过。

原则 4：Goal-Driven Execution——给目标，让它自己 loop

最后一条，原文：

定义成功标准。循环直至验证通过。

把任务转化为可验证的目标：

• "加上校验" → "为非法输入写测试，然后让测试通过"
• "修这个 bug" → "写一个能复现 bug 的测试，然后让它通过"
• "重构 X" → "确保重构前后测试都通过"

对多步任务，给一个简短的计划：

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

强成功标准让你能独立 loop。弱成功标准（"让它能跑"）需要不断回头澄清。

这一条对应的，其实是 Karpathy 原文里最重要的一段——

LLMs are exceptionally good at looping until they meet specific goals and this is where most of the "feel the AGI" magic is to be found. Don't tell it what to do, give it success criteria and watch it go. Get it to write tests first and then pass them. Put it in the loop with a browser MCP. ...Change your approach from imperative to declarative to get the agents looping longer and gain leverage.

我想把这段单独拿出来强调一下，因为它是整条 post 里我读了 4 遍的那段。

Karpathy 在说一件特别根本的事：LLM 编程的最大杠杆，不在于"你怎么把指令说得更好"，在于"你能不能把任务变成一个可被验证的循环"。

「让它能跑」不是一个可被验证的循环——LLM 不知道什么算"能跑"，你也不知道。它跑了一次没崩你就接受了，但你没验证任何具体的不变量。

「为非法输入写测试，然后让测试通过」是一个可被验证的循环——LLM 写测试、跑测试、看红、改实现、看绿。这个循环它能自己 loop，你不在场也不会跑偏。

这是 imperative → declarative 的本质：你不是在告诉 AI 怎么做，你是在告诉 AI 什么算做完了。

我自己最近用 Claude Code 越多，越觉得这一条比技术上的 prompt 技巧重要 10 倍。同一个任务：

• 弱目标版：「把这个函数的性能优化一下」——它会改 10 个无关的地方，跑也不知道有没有变快。
• 强目标版：「写一个 benchmark，测出当前版本耗时；优化函数；让 benchmark 提速 50% 以上；保持原有所有单测通过」——它能自己跑 30 分钟，回来交给你一个真的快了 60% 的版本。

差别不在 AI，差别在你的目标长什么样。

我自己越用 Claude Code 越觉得，这一条比任何 prompt 技巧都重要。技巧的天花板很低，目标定义的天花板很高——前者顶多让 AI 在你画好的地图里走得更利索一点，后者直接决定地图有多大。

四、四条原则的合奏：一个能被 AI 听懂的"资深工程师"

把这 4 条原则放在一起看，会发现它们其实在合奏一件事——模拟一个资深工程师的工作姿势：

原则	对应的资深工程师习惯
Think Before Coding	动手前先把模糊点暴露出来，逼客户/PM 想清楚
Simplicity First	"简单到不能再简单"是审美，是经过痛苦学到的
Surgical Changes	"只改你必须改的"是 PR 卫生，是十年血泪经验
Goal-Driven Execution	"TDD/可验证目标"是工程纪律的核心

四条加起来，就是一个有手感的工程师在 review 一个聪明初级实习生时，会不断重复的那 4 句话。

这一点和我上一篇讲 mattpocock/skills 时说的完全一致——skills 的本质是把工程心法编码成 AI 可执行的指令。区别只是：

• mattpocock/skills 是面向流程的——TDD、Diagnose、Code Review、PRD
• karpathy-guidelines 是面向纠错的——4 条防错原则，反向 derive from LLM 的典型缺陷

两者互补。前者教 AI 怎么干活，后者教 AI 别瞎干。一个团队真正成熟时，两套都该有。

五、为什么是 100 行而不是 1000 行

我特别想唠一下：这份 skill 只有 100 行。

作为对比，Karpathy 的原帖是接近 3000 字的散文。社区做的事不是"把 3000 字浓缩成 1000 字"，是浓缩成 100 行 markdown，4 个章节，每章 4-5 个 bullet point。

为什么这么短？因为 skill 是给 LLM 看的，不是给人看的。

LLM 的 context window 是有限的——你写得越长，每次激活时占用的 token 就越多，模型对它的注意权重就越分散。一份 1000 行的 skill，模型读完后大概率只能记住一半。一份 100 行的 skill，每条原则都能成为它每次决策时清晰可见的约束。

skill 的密度比长度重要。这一点 Matt 那批 skills 也成立——他的每个 skill 文件平均也就 30-50 行。我现在越来越觉得，skill 这种原语的写作风格，最好的参照不是文档，是宪法——每一条都是不能再压缩的硬约束。

我自己第一次写 skill 时也是堆了 200 行各种边界情况，AI 一执行就出戏。后来砍到 40 行，反而稳定了。事后回头看那 200 行，里面大半是我自己写得爽的"老师腔"——不是 AI 需要的。

六、它没解决什么问题

任何东西被反复夸的时候，我都习惯反过来想想它哪里没解决——这份 skill 也一样。

第一，它处理的是 LLM 的"行为"，不是 LLM 的"能力"。

如果模型本身的能力不够——它就是不会写某种语言、不熟某个框架——这份 skill 救不了你。这 4 条原则的前提是模型已经"听得懂"，只是它"做不到自律"。模型听不懂的部分，要靠模型升级、靠 RAG、靠更好的 CONTEXT.md 来解决，不是 skill 的射程。

第二，它不能替代 review。

Karpathy 在原帖里反复说 watch them like a hawk。这份 skill 把 LLM 的失误率从 30% 降到 10%——但那 10% 还在。skill 是减负工具，不是免疫工具。我自己用 Claude Code 时，IDE 永远开着，每个 diff 都看一遍——这件事至少在 2026 年还没法省掉。

第三，它和模型适配性有关。

这 4 条原则在 Claude Sonnet/Opus 上效果非常好，因为 Claude 本身就比较听话。在某些更"嗨"的模型上，同样的 prompt 可能效果折半。跨模型迁移 skill 时最好做一下 A/B——拿来就用容易翻车。

第四，它会迟钝化你对模型脾气的感知。

skill 写得越好，你越不需要去琢磨"这个模型最近是不是变笨了"。这一般是好事，但有时候那种"贴着模型当下脾气来调整"的手感是有价值的——它能让你第一时间发现模型行为的微妙变化。我现在的折中是：把 skill 当默认基线，但保留自己 prompt 调优的能力，不完全外包给 markdown。

七、我从这条 post 里读到的两件更深的事

最后想跑一点题。Karpathy 那条 post 我读了 4 遍，前 3 遍我都被那 4 条 LLM 缺陷吸引。第 4 遍我才看见两件更深的事。

7.1 "stamina is a core bottleneck to work"

原帖里的这段话——

They never get tired, they never get demoralized, they just keep going... It's a "feel the AGI" moment to watch it struggle with something for a long time just to come out victorious 30 minutes later. You realize that stamina is a core bottleneck to work and that with LLMs in hand it has been dramatically increased.

"耐力是工作的核心瓶颈"——这句话过去你不会这么说，因为耐力是人类内置的。它就在那儿，你不会把它当作"工程问题"来看。但 LLM 让你第一次看清——很多过去你以为是"想不通"才放弃的问题，其实只是因为人类大脑撑不到第三个小时。

LLM 不累。AI 把"耐力"这个隐形资源解耦出来，变成可调度的东西。这是过去十年里，agentic loop 这个概念真正落地的那一刻——不是因为它"更聪明"，是因为它不累。

我隐隐觉得，这条 post 之后，"stamina"这个词会越来越多地出现在工程话语里。它会和"context window""tool use""loop"一起，成为 AI 编程时代的基础术语。

7.2 "expansion" 远大于 "speedup"

另一段：

I do a lot more than I was going to do because 1) I can code up all kinds of things that just wouldn't have been worth coding before and 2) I can approach code that I couldn't work on before because of knowledge/skill issue. So certainly it's speedup, but it's possibly a lot more an expansion.

我把这段单独拎出来是因为，"expansion"远比"speedup"更重要。

speedup 是把过去能做的做得更快——节省时间。expansion 是把过去做不了的变得能做——创造新机会。两件事的复利曲线完全不一样：

• speedup 复利曲线是线性的——10 倍速度，10 倍产出
• expansion 复利曲线是指数的——能做的事多了，每件事会勾连出更多事

我自己最近就是这样。Claude Code 让我去碰 CUDA、碰 Rust、碰 SwiftUI——这三个我过去都属于"知道但不做"的范畴。现在我每周都在做。这三个新领域又会勾连出更多新东西——这是 expansion。

speedup 是把过去能做的做得更快——节省时间。expansion 是把过去做不了的变得能做——多出新机会。我不太确定这两件事在每个人身上的比例会一样，但我隐隐觉得，未来一两年内，"做同样的事更快"和"做以前做不了的事"之间的 gap，会越拉越大。

八、写在最后

我把这篇文章和上一篇放在一起想，意外地发现它们不是平行关系，而是分工——

• mattpocock/skills 在解决"AI 不知道怎么按工程纪律干活"
• karpathy-guidelines 在解决"AI 在干活时会犯哪些反复出现的具体错"

前者是"教育"，后者是"防错"。一个团队成熟到能两件事都做时，AI 就真的从一个"聪明的实习生"变成了一个"可以信任的初级工程师"。

这两个仓库都很短，加起来不到 2000 行 markdown。但它们指向的方向，可能是 AI 时代工程化最重要的那条岔路：不是把 AI 训练得更强，是把人类的工程经验编码到 AI 能听懂的形式里。

Karpathy 那条 post 的最后一句话，我想抄给你结尾：

2026 is going to be a high energy year as the industry metabolizes the new capability.

一个新能力从"被追捧"到"被消化进日常"，要花的远不止时间，还有结构、纪律、共同语言。skills 这种原语正是消化过程中的一种酶。

顺带一提，Karpathy 在原帖最后还创了个词——slopacolypse（slop + apocalypse），预言 2026 会是数字内容被粗制滥造淹没的一年。这正好是 skill 这种原语的反面——在 slop 越来越多的世界里，把"真东西"显式地保留下来。写代码如此，做团队大概也是如此。

我自己也在想，下一份属于我的"100 行"应该写些什么——是那些我每天都要给 AI 重复纠正的同一个错。我还没写出来，但我知道在哪儿。也许你心里也有一份。

要不要写下来，那是你的事。我只是想说，这件事比再装一个 AI 工具划算得多。

---

本文写于 2026 年 5 月。仓库地址：multica-ai/andrej-karpathy-skills；Karpathy 原 post：x.com/karpathy。

延伸阅读

• 《AI 写代码比你快 10 倍，你还剩什么？——读 mattpocock/skills》——本文的姊妹篇，讲流程型 skills
• 《Harness Engineering：当人类不再写代码，软件工程反而更"工程"了》——AI 时代工程化的整体框架
• Andrej Karpathy 原 post (x.com)——3000 字长贴，强烈建议读原文
• multica-ai/andrej-karpathy-skills——本文拆解的 skill 仓库
• mattpocock/skills——上一篇拆解的流程型 skill 仓库

---

关注公众号「coft」，获取更多 AI 时代的深度思考。