AI 写代码比你快 10 倍，你还剩什么？——读 mattpocock/skills

AI 写代码比你快 10 倍，你还剩什么？------读 mattpocock/skills

Matt Pocock 把自己 .claude 目录里的十几个 markdown 推到了 GitHub。三个月，6.9 万 star。

我前两天翻这个仓库，翻完心里冒出来一句话------ AI 写代码比我快这么多了，那我这个工程师还要干嘛？

TL;DR ：在 AI 编程工具迭代越来越快的今天，prompt engineering 和 multi-agent 框架都在被快速贬值。真正与模型升级正交、能持续复利的能力是 skills ------把工程纪律（TDD、DDD、调试 SOP、反熵增节奏）以 markdown 形式编码给 AI 执行。本文以 mattpocock/skills 仓库为锚点，拆解 AI agent 的四种典型失败模式，并给出工程师 / 团队 Leader / CTO 三种角色的具体动作。

一、最热的 AI 仓库 mattpocock/skills，里面没有一行 AI 代码

打开 mattpocock/skills，会愣一下：

语言占比 100% Shell，而且只是几个安装脚本
核心内容全是 markdown
没训练模型，没 fine-tune，没 RAG，没 vector DB
作者明确说他不喜欢 GSD、BMAD、Spec-Kit 那一套"接管整个流程"的方案

一个全是文字的仓库，2025 年底冲到 7 万 star。同样的东西放到 2022 年发，多半没人看。它今天能起来，是因为很多工程师隐约感到，模型本身的提升空间这一年开始边际递减了，而怎么把模型嵌进自己的工作里，才是更大的那块没解决的事。

skills 不是一个产品，更像一个早期信号。

二、Skill 是个啥：把工程纪律编码成 AI 可执行的指令

一个 skill 就是一个文件夹，里面放一份 SKILL.md。这份 markdown 写的是：在某一类场景下，AI 该怎么干活、该停在哪里检查、该问哪些问题。

Matt 仓库里的几个真例子：

Skill	文件夹里写的是什么
`tdd`	红-绿-重构的纪律：先写一个失败测试、最小化让它通过、再重构。`SKILL.md` 实际不到 40 行，核心就是三段模板加三条禁令------不许直接写实现、不许跳过失败测试、重构时不许改行为
`diagnose`	调试 SOP：先复现、再二分、再形成假设、再验证。禁止直接动手猜
`grill-with-docs`	拷问式质询：在写代码前，用一连串问题把模糊需求逼出来
`to-prd`	把对话变成 PRD：在生成 PRD 之前先问清楚涉及哪些模块
`improve-codebase-architecture`	反熵增任务：每隔几天跑一次，找代码深度化的机会
`caveman`	超压缩沟通模式，省大概 75% 的 token

注意一件事：没有一个 skill 是"教 AI 怎么写代码"的。它们都在教 AI 怎么干活------怎么提问、怎么调试、怎么对齐、怎么和团队共享语言。

这不是 prompt engineering，是把工程纪律写成 AI 看得懂的指令。

markdown 复制代码

   传统 Prompt                       Skill
  ─────────────                    ─────────
        │                              │
        ▼                              ▼
  ┌──────────────┐              ┌──────────────────┐
  │ 教 AI 做一件事 │              │ 教 AI 在一类场景下 │
  │ 一次性、无状态 │              │   遵循一种纪律     │
  └──────────────┘              └──────────────────┘
                                         │
                                         ▼
                                  可复用·可迭代·可传承

prompt 是一次提问，skill 更像一种习惯。

Matt 做的就一件事：把"工程纪律"这种过去只能靠师徒慢慢传的东西，变成可以 git clone 的东西。这个原语我个人觉得被严重低估了，往大里说，它的潜在影响不亚于 2008 年 GitHub 把"代码协作"变成可 fork 的事。

三、AI agent 的四种失败模式：Matt 真正在解决的问题

skills 仓库的 README 里，Matt 列了 AI agent 的四种典型失败模式，每种对应一组 skill。这是整个仓库的灵魂，我把它们和我自己在团队里看到的现象对照写一下。

失败模式 1：Agent 做的不是我想要的

根因是需求模糊，而且双方都没意识到模糊。

人类工程师有个不太自洽的习惯：对"做的不是我想要的"容忍度很低，但对"我没说清楚"的容忍度也很低。换成 AI 这个问题被进一步拉开------AI 默认不会反问，除非你强迫它反问。

Matt 的解法是 /grill-me 和 /grill-with-docs：在 AI 动手之前，先让它质询你。

背后是《Pragmatic Programmer》那句被引用了二十年但很少人真做的话------

"No-one knows exactly what they want."

把这句话编码成 AI 的开场白，是 skills 的第一个反共识动作：AI 不是回答机器，是逼你想清楚的镜子。

失败模式 2：Agent 太啰嗦

根因是缺少共享语言。

Matt 给了一个我特别喜欢的例子：

❌ "课程中某节(lesson)被赋予文件系统位置时出现的问题"
✅ "materialization cascade 出问题了"

第一种说法 AI 也能听懂，但代价是它每次都要重新理解上下文，token 烧得多，行为也容易漂。第二种说法是领域语言------团队（包括 AI）共用的一套词汇。

Matt 的解法是在仓库根目录维护一份 CONTEXT.md，把领域概念、模块名、关键决策的"短语"显性写出来。

背后是 Eric Evans 的 Domain-Driven Design------一本 2003 年的书，过了二十多年，第一次被用在它本来该用的地方。

我在 04 那篇讲过"团队层的 AI 熵增"------同一个工具函数被 AI 在 5 个文件里重新发明，错误处理一会 try-catch 一会 Result。那篇我没给的解法，这一节是其中一半：AI 没有 memory，CONTEXT.md 就是你给它的"第二大脑"，每次对话都从那里加载。

失败模式 3：代码跑不起来

根因是反馈回路不够快。

这条最朴素，但最容易被 AI 时代的人忘。AI 让"打字"快了 10 倍，但没让"验证"变快。结果就是，你飞速地往一个错的方向推进了 100 步，然后才发现第一步就错了。

Matt 的解法是 /tdd 和 /diagnose，把红-绿-重构循环和调试 SOP 注入到 AI 的工作方式里。

引用又是《Pragmatic Programmer》------

"Your feedback rate is your speed limit."

这句话过去更像一句格言，今天变成了硬约束。AI 把上限打开 10 倍，反馈如果还是过去的速度，你只是 10 倍速地撞墙。

失败模式 4：构建出了"大泥球"

根因是 AI 加速了编码，也加速了软件熵增。

这条最阴险------它不会立刻发作，会在三个月、六个月之后让你的代码库变成无人能动的黑洞。

Matt 的解法是三件事：

/zoom-out------逼 AI 在整个系统的视角下解释一段代码
/improve-codebase-architecture------每隔几天主动找深度化机会
/to-prd------在写需求前先问清楚涉及哪些模块

引用是 Kent Beck 和 John Ousterhout------XP Explained 与 A Philosophy of Software Design。

这条解法的核心姿势我特别想强调一下：它不是"出事了去修大泥球"，是平时主动地、持续地反熵增。一个干净的代码库不是一次大重构换来的，是每周花两小时反复抚平褶皱换来的------这件事 AI 时代之前就成立，AI 时代变得更要紧。

四条加起来，Matt 整个仓库其实在说同一句话：

AI 时代的工程问题，绝大多数不是新问题，是被加速的旧问题。

旧问题的解法散在过去四十年的经典里------Pragmatic Programmer 、DDD 、XP Explained 、A Philosophy of Software Design。skills 做的事，是把这些书里的原则第一次工程化地落地到 AI 工作流。

这就是为什么这个仓库会爆。它不是给 AI 用的，是给被 AI 时代搞糊涂了的工程师用的------你过去信的那些东西没过时，你只是没把它们用在正确的地方。

四、skills 是和模型升级正交的能力

讲到这里可以说我自己的判断了。

我在前一篇《AI 时代的三层杠杆》里讲过：个人层的杠杆是时间，团队层的杠杆是协作，业务层的杠杆是判断。这个三层模型还成立，但 skills 这个原语让我看见个人层和团队层之间还有一个夹层------纪律的杠杆。

4.1 三种押注，三种折旧曲线

他把精力押在哪里	押的是什么	工具换代时发生什么
prompt 技巧	某个模型当下的脾气------它喜欢什么开场、讨厌什么 token、怎么哄它给长输出	模型换代后这些脾气重置一半。不会清零，但每次换代都要重学
agent 框架	某个框架当下的抽象------Supervisor、Planner-Executor、Graph	框架迭代太快，半年前的 best practice 今天已经被官方 deprecated
工程心法	工程纪律本身------TDD、DDD、调试 SOP、反熵增节奏	纪律不随模型或框架换代折旧；模型越强，执行越到位

当然这不是三种互斥的人，现实里很多人三样都做。区别只在于他把最多的时间留给了哪一样------那一样决定了他三年后的位置。押前两样不是错，它们是短期生产力；但如果一个工程师这一年只在押前两样，他在攒的是会折旧的资产。

押工程心法是另一个故事------这是模型升级杀不死的东西。我自己最近的一个直观感受：模型越强，好心法和差心法的差距反而被放大得越离谱。同一个 Claude，给一个把心法写下来的人和一个没写的人用，产出差距很容易到 3-5 倍，过去一年这个倍数还在往上走。

模型把下限拉高了，而心法把上限拉得更高------这是过去没有过的结构。

skills 真正的含金量在这里：它和模型升级是正交的。你今年练的东西，三年后越来越值钱，不会被 GPT-6 或 Claude 5 抹平。

4.2 skills 是可以共享的"心法"

skills 还有第二层潜力------它天生可以共享。

一个工程师的 .claude/skills/，本质上是他工程心法的一份可执行快照。这个东西过去只存在于他大脑里，现在能以 markdown 形式落地。这意味着：

对个人：换公司、换语言、换技术栈，这份东西不丢
对团队：新人来了，git pull 一下就能用上团队的约定
对组织：核心工程师走了，他的"打法"留下了一份

我前一篇讲过"中层塌陷"------AI 时代中级工程师长不出来，因为初级活被 AI 干了，他们没机会接触完整问题。skills 是这个问题的一个结构性解法：把资深工程师的纪律编码成 skills，让 AI 在初级工程师身边模拟出一个资深前辈，逼他先质询需求、先写测试、先 zoom out 看架构、先写 PRD 再写代码。中级工程师不再需要从"完整的混乱问题"里硬熬出来，他可以在"被纪律保护的混乱"里长出来。

这不是用 AI 替代师徒制，更准确的说法是把师徒制写成代码。

4.3 skills 是 L3 团队的最低成本抓手

我前一篇给了一个 AI 成熟度的五级模型：

复制代码

L0  没开始
L1  个人层      : 工程师自发使用 AI
L2  团队层(工具): 统一工具与规范
L3  团队层(结构): Review/基建/时间再分配都做了
L4  业务层(优化)
L5  业务层(重塑)

绝大多数公司卡在 L1 到 L2 的过渡------不是不知道要做 L3，是不知道 L3 长什么样。"重构 Review 流程""建立 AI 友好的代码基建""规定省下的时间用来做什么"------这些话听起来都对，但落地时找不到抓手。

skills 给了一个出乎意料具体的抓手：把 L3 的所有结构性纪律，写进一个文件夹。

团队的 Review 标准 → code-review.md
团队的调试 SOP → diagnose.md
团队的领域语言 → CONTEXT.md
团队的反熵增节奏 → improve-codebase-architecture.md
团队"省下的时间用来做什么" → tech-debt-budget.md

L3 不再是一个抽象的管理动作，它就是一个 PR------能被讨论、被评审、被合并、被回滚。

这一点的意义比看起来的大。它把"组织变革"从一件只有 CTO 才能干的事，变成团队里任何一个有手感的工程师都能开第一枪的事。

五、它不是银弹，是放大器

任何被吹得太狠的东西都得泼一桶冷水。skills 也不例外。

5.1 skills 不替代理解，只放大理解

一个对系统没有深度理解的工程师，写不出有用的 skill。他写出来的东西要么太空（"写好代码"），要么太死（"必须用 try-catch 不许用 Result"），要么自相矛盾。

skills 不是 AI 时代入门工程师的捷径------这个角色在 AI 时代基本不存在了，AI 已经把"入门"那一段完全吃掉。skills 是给已经有真实工程经验的人，把这些经验外化、共享、复用的工具。

如果你试图用 Matt 的 skills 替代你自己的思考，你只是在用一种更精致的方式 vibe coding。

5.2 skills 自己也会熵增

skill 文件夹本身也是代码，会过时，会和现实脱节。

一个团队第一年沉淀 20 个 skills 是好事；如果第三年还是这 20 个，但里面 8 个已经和现实不符，那 skills 反而成了拖累------它会让 AI 按一份"过期的纪律"工作，比没有 skills 更糟。

所以 skills 自己也需要版本、Review、Owner、定期清理。它不让你逃离"维护"这件事，只是把你的活从"维护代码"变成"维护代码 + 维护 skills"。后者对你更值钱，但它不会消失。

5.3 不是每个团队都到了能用 skills 的阶段

一个还在 L1 的团队，硬塞 Matt 的 skills 进去大概率会失败：

团队还没建立"我们要怎么写代码"的共识------skills 写出来谁都不服
AI 工具的统一程度不够------有人 Cursor、有人 Claude Code、有人 Copilot，skills 跨工具兼容是个真问题
工程师对 AI 的态度还在两极------拥抱派会过度依赖，怀疑派会全盘否定

skills 更像是 L2 团队的进阶工具，不是 L1 团队的入门工具。一个团队连"统一用哪个 AI 工具"都没解决，急着写一打 skills，是在跳过该走的路。

5.4 skills 的迁移成本远比看起来高

Matt 的 skills 对 TypeScript 教育场景做了大量隐含适配，migrate-to-shoehorn、scaffold-exercises 这种你拿来基本没法直接用。哪怕是 tdd、diagnose 这种看起来普适的，照搬也会发现：你团队的 TDD 节奏、调试工具栈、代码组织方式，都和他不一样。

skills 不是 npm 包。它的迁移成本更接近"读懂他的思路 + 重写"，而不是 npx skills add 一行命令。这个仓库的真正价值是示范，不是直接复用。

六、给三种角色的具体动作

我不打算列一份"试试看 Matt 的 skills"的清单------清单读完就忘。给三段话，按你的角色挑一段。

如果你是工程师 ------今年最该做的事，不是再多学一个 AI 工具，是给自己建一个 .claude/skills/，哪怕里面只放 3 个文件。第一个写你最得意的那个调试 SOP，第二个写你 review 别人代码时会问的那 5 个问题，第三个写你怎么决定一段代码该不该写测试。意义不在 AI 因此快了多少（虽然真的会快），在于你第一次把自己的工程心法显性化------这个动作本身就是从"有经验的工程师"到"能传承经验的工程师"的分水岭。写得好坏不重要，有没有写才重要。

如果你是团队 Leader------你比谁都清楚团队里"最资深的那个工程师"的真实价值。他不是写代码最快的，是做决定最准的。他要离职的时候，团队的不安远远超过"找个人接他的 PR"。skills 是你第一次有机会把这种人的打法留下来的工具------别等他递辞呈那天才想起。从下个月开始，每周抽两小时，让最资深的两个人各写一个 skill，可以是"我们怎么 Review"、"我们怎么定 API"、"我们怎么处理一个生产事故"。一年下来 24 个 skills，这本身就是团队的文化资产。它的 ROI 不会出现在下个季度，但它决定你三年后还能不能把团队带到 L3。

如果你是 CTO / 研发老板 ------把 skills 当作组织级议题来对待，而不是"一群工程师在玩的新玩具"。三件具体的事：第一，建一个公司级的 skills/ 仓库，和代码同等优先级地维护；第二，把"贡献 skills"加进资深工程师的考核------这是组织记忆的固化，比多写 1000 行代码值钱；第三，最难也最重要------在新员工入职流程里加上"读 skills 仓库"这一项，让 skills 真正进入组织的日常，而不是停在某几个工程师的本地目录。这三件事单看每件都不难，合起来能让你的组织在两年后结构性地领先一个身位。然后接受一个事实：第一年看不见效果，第二年开始有效果但说不清是不是 skills 的功劳，第三年别人发现你团队的代码质量明显甩开同行的时候，已经追不上了。这是慢性复利，给那些愿意为三年后的自己今天就开始攒东西的人。

七、写在最后

那些过去被认为"老掉牙"的东西------TDD、DDD、XP、模块化设计------在 AI 时代不是过时了，是第一次有了能落地的载体。它们过去靠工程师自己的自律执行，大多数时候执行得很差。它们现在能靠 skills 让 AI 帮你执行，一致、不疲倦、可以版本化和迭代。

Kent Beck、Eric Evans、John Ousterhout、Andrew Hunt 这些人写的书，过去二十年里被引用得最多，被实践得最少。AI 让这件事第一次有可能反过来。

写代码本身会越来越容易，懂得"为什么这样写"会越来越值钱。skills 是这两件事中间的桥。

mattpocock/skills 给我最大的启发不是它具体写了什么，而是它顺手提醒了一件被几乎忘掉的小事：真正吃饭的工夫从来都在纪律里，不在工具里。AI 不会改变这一点，AI 只会让这一点比过去更要紧。

那个把自己 .claude 目录推到 GitHub 的人，做的事情看起来不大。但他踩中的点，可能比这一年所有那些更"AI 化"的项目加起来都要深------因为他没在追 AI，他在用 AI 把工程师做回工程师。

本文写于 2026 年 5 月。仓库地址：mattpocock/skills

AI 写代码比你快 10 倍，你还剩什么？——读 mattpocock/skills