AI 写代码比你快 10 倍你还剩什么——读 mattpocock/skillsMatt 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 看得懂的指令。传统 Prompt Skill ───────────── ───────── │ │ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ │ 教 AI 做一件事 │ │ 教 AI 在一类场景下 │ │ 一次性、无状态 │ │ 遵循一种纪律 │ └──────────────┘ └──────────────────┘ │ ▼ 可复用·可迭代·可传承prompt 是一次提问skill 更像一种习惯。Matt 做的就一件事把工程纪律这种过去只能靠师徒慢慢传的东西变成可以 git clone 的东西。这个原语我个人觉得被严重低估了往大里说它的潜在影响不亚于 2008 年 GitHub 把代码协作变成可 fork 的事。三、AI agent 的四种失败模式Matt 真正在解决的问题skills 仓库的 README 里Matt 列了 AI agent 的四种典型失败模式每种对应一组 skill。这是整个仓库的灵魂我把它们和我自己在团队里看到的现象对照写一下。失败模式 1Agent 做的不是我想要的根因是需求模糊而且双方都没意识到模糊。人类工程师有个不太自洽的习惯对做的不是我想要的容忍度很低但对我没说清楚的容忍度也很低。换成 AI 这个问题被进一步拉开——AI 默认不会反问除非你强迫它反问。Matt 的解法是/grill-me和/grill-with-docs在 AI 动手之前先让它质询你。背后是《Pragmatic Programmer》那句被引用了二十年但很少人真做的话——“No-one knows exactly what they want.”把这句话编码成 AI 的开场白是 skills 的第一个反共识动作AI 不是回答机器是逼你想清楚的镜子。失败模式 2Agent 太啰嗦根因是缺少共享语言。Matt 给了一个我特别喜欢的例子❌ “课程中某节(lesson)被赋予文件系统位置时出现的问题”✅ “materialization cascade出问题了”第一种说法 AI 也能听懂但代价是它每次都要重新理解上下文token 烧得多行为也容易漂。第二种说法是领域语言——团队包括 AI共用的一套词汇。Matt 的解法是在仓库根目录维护一份CONTEXT.md把领域概念、模块名、关键决策的短语显性写出来。背后是 Eric Evans 的Domain-Driven Design——一本 2003 年的书过了二十多年第一次被用在它本来该用的地方。我在 04 那篇讲过团队层的 AI 熵增——同一个工具函数被 AI 在 5 个文件里重新发明错误处理一会 try-catch 一会 Result。那篇我没给的解法这一节是其中一半AI 没有 memoryCONTEXT.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.mdL3 不再是一个抽象的管理动作它就是一个 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、有人 Copilotskills 跨工具兼容是个真问题工程师对 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 时代的三层杠杆从个人提效到团队提效到业务提升》——本文反复引用的中层塌陷和 L1-L5 五级模型来源《AI 重塑软件工程》——AI 时代工程范式变化的整体框架《复杂系统视角下的软件架构》——为什么 AI 会加速大泥球Pragmatic Programmer (20th Anniversary Edition)——Matt 多次引用的经典A Philosophy of Software Design——John Ousterhout 关于深度模块化的小书关注「coft」获取更多 AI 时代的深度思考。
AI 写代码比你快 10 倍，你还剩什么？——读 mattpocock/skills
发布时间：2026/5/26 23:11:48
AI 写代码比你快 10 倍你还剩什么——读 mattpocock/skillsMatt 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 看得懂的指令。传统 Prompt Skill ───────────── ───────── │ │ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ │ 教 AI 做一件事 │ │ 教 AI 在一类场景下 │ │ 一次性、无状态 │ │ 遵循一种纪律 │ └──────────────┘ └──────────────────┘ │ ▼ 可复用·可迭代·可传承prompt 是一次提问skill 更像一种习惯。Matt 做的就一件事把工程纪律这种过去只能靠师徒慢慢传的东西变成可以 git clone 的东西。这个原语我个人觉得被严重低估了往大里说它的潜在影响不亚于 2008 年 GitHub 把代码协作变成可 fork 的事。三、AI agent 的四种失败模式Matt 真正在解决的问题skills 仓库的 README 里Matt 列了 AI agent 的四种典型失败模式每种对应一组 skill。这是整个仓库的灵魂我把它们和我自己在团队里看到的现象对照写一下。失败模式 1Agent 做的不是我想要的根因是需求模糊而且双方都没意识到模糊。人类工程师有个不太自洽的习惯对做的不是我想要的容忍度很低但对我没说清楚的容忍度也很低。换成 AI 这个问题被进一步拉开——AI 默认不会反问除非你强迫它反问。Matt 的解法是/grill-me和/grill-with-docs在 AI 动手之前先让它质询你。背后是《Pragmatic Programmer》那句被引用了二十年但很少人真做的话——“No-one knows exactly what they want.”把这句话编码成 AI 的开场白是 skills 的第一个反共识动作AI 不是回答机器是逼你想清楚的镜子。失败模式 2Agent 太啰嗦根因是缺少共享语言。Matt 给了一个我特别喜欢的例子❌ “课程中某节(lesson)被赋予文件系统位置时出现的问题”✅ “materialization cascade出问题了”第一种说法 AI 也能听懂但代价是它每次都要重新理解上下文token 烧得多行为也容易漂。第二种说法是领域语言——团队包括 AI共用的一套词汇。Matt 的解法是在仓库根目录维护一份CONTEXT.md把领域概念、模块名、关键决策的短语显性写出来。背后是 Eric Evans 的Domain-Driven Design——一本 2003 年的书过了二十多年第一次被用在它本来该用的地方。我在 04 那篇讲过团队层的 AI 熵增——同一个工具函数被 AI 在 5 个文件里重新发明错误处理一会 try-catch 一会 Result。那篇我没给的解法这一节是其中一半AI 没有 memoryCONTEXT.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.mdL3 不再是一个抽象的管理动作它就是一个 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、有人 Copilotskills 跨工具兼容是个真问题工程师对 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 时代的三层杠杆从个人提效到团队提效到业务提升》——本文反复引用的中层塌陷和 L1-L5 五级模型来源《AI 重塑软件工程》——AI 时代工程范式变化的整体框架《复杂系统视角下的软件架构》——为什么 AI 会加速大泥球Pragmatic Programmer (20th Anniversary Edition)——Matt 多次引用的经典A Philosophy of Software Design——John Ousterhout 关于深度模块化的小书关注「coft」获取更多 AI 时代的深度思考。
