治 AI 瞎写代码：177K star 的 `mattpocock/skills` 到底给了什么

来源：抖音 @鼠鼠不加班 · 36 秒 ·《ai瞎写代码终于有救了》#vibecoding大赏这是一条推荐向的干货短视频，核心信息就一个 GitHub 项目：mattpocock/skills。视频只有 36 秒，但项目本身值得挖到底——所以下面 90% 篇幅是我把仓库扒开读完之后的东西，不是转述视频。

一句话定性

这条视频是「工具推荐型干货」的标准打法：用一个具体痛点（AI 瞎写代码）+ 一个硬社会证明（十几万 star）+ 一个 30 秒可执行动作（一行 npx），在 36 秒里完成种草。而它推荐的东西确实是真货——mattpocock/skills 是目前 AI 编程工程化这一块，少见的「不抢你方向盘」的方案。

先纠三个错：视频说的哪些不准

我做深扒的规矩是先核事实再谈价值。这条视频的推荐方向没问题，但有三处经不起查，照搬会闹笑话：

视频的说法	实际情况	判定
「129K star」	录制时属实。我 2026-07-19 查 GitHub API 是 177,009 star / 15,178 fork	✅ 属实，且已长了一大截
「作者参与过 Node.js 早期开发」	Matt Pocock 的 GitHub bio 原文：TypeScript wizard. Building Total TypeScript… Ex-Vercel, Stately。他是 TypeScript 教育界的头部作者，跟 Node.js 早期开发没关系	❌ 错，安到别人头上了
「整个项目只有 70 行代码」	仓库 782 KB，6 个分类目录下 30 来个 skill，光 README 就 14,573 字节，`tdd`、`diagnosing-bugs` 单个 skill 正文都不止 70 行	❌ 错，差了两个数量级

另外视频画面里出现的工具清单还有个 caveman（说是”超压缩通信”）——这个 skill 已经被作者删了。CHANGELOG 原话：“caveman was a duplicate of another skill I was testing and was never meant to be public.” 说明视频扒的是个旧快照。

为什么要较这个真？ 因为「前 Node.js 核心开发者出手」和「TypeScript 教育作者出手」是两种完全不同的权威背书，前者能唬人但它是假的。这个项目的价值不需要靠伪造作者履历来撑——它真正的分量在设计哲学上。

这项目到底是什么

一句话：Matt Pocock 把自己每天真用的 .agents 目录直接开源了。

仓库简介原文就一句：“Skills for Real Engineers. Straight from my .agents directory.”

2026-02-03 建仓，到现在 5 个多月，涨到 17.7 万 star——这个曲线在 GitHub 上是顶级的
MIT 协议，主要语言 Shell
不是框架、不是平台，就是一堆 Markdown 写的 skill 文件，任何模型、任何 agent 都能用

它的立场：明确反对「接管流程」

README 里有一段是整个项目的题眼，我原文摘出来：

Developing real applications is hard. Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.

These skills are designed to be small, easy to adapt, and composable. They work with any model. Hack around with them. Make them your own.

这段话的含金量比视频里所有形容词加起来都高。它在说：

市面上那些 AI 编程方法论（GSD / BMAD / Spec-Kit）的通病是——它们要当你的流程主人。流程一旦被接管，流程本身出 bug 你就没法修。

而这套 skill 的选择是反过来的：小、好改、可组合、跟模型无关，欢迎你魔改成自己的。 副标题里那句 “real engineering - not vibe coding” 才是它真正的旗子——它不是让你更爽地 vibe coding，它是让你别 vibe coding。

为什么它能火：四个失败模式，四个解法

README 的主体结构不是功能列表，而是**「我见过 agent 的四种翻车方式，每种给一个解法」**。这个结构本身就值得抄——先讲痛，再给药。

失败 #1：Agent 没做我想要的东西

“No-one knows exactly what they want” —— 《程序员修炼之道》

诊断：软件开发最常见的翻车是对齐失败。你以为开发懂你了，做出来才发现完全没懂。AI 时代一模一样，你和 agent 之间有沟通鸿沟。

药：/grill-me（非代码场景）和 /grill-with-docs（代码场景）——让 agent 反过来拷问你，在动手前把你想要什么问到每个分支都闭合为止。

作者说这是他最受欢迎的两个 skill，建议每次要改动前都跑。

我的评价：这是整个仓库里最反直觉、也最值钱的一个动作。大部分人用 AI 的姿势是「我说，它做」，而这个 skill 把它倒过来——「它问，我想清楚」。真正吃掉时间的从来不是敲代码，是需求没想明白就开工。

失败 #2：Agent 太啰嗦

“With a ubiquitous language, conversations among developers and expressions of the code are all derived from the same domain model.” —— Eric Evans《领域驱动设计》

诊断：agent 被丢进一个项目，黑话得自己猜，所以该用 1 个词的地方它用 20 个词。

药：建一份共享语言——CONTEXT.md，把项目黑话给 agent 解码。

README 里给的对比例子极其直观：

改造前：“There’s a problem when a lesson inside a section of a course is made ‘real’ (i.e. given a spot in the file system)”
改造后：“There’s a problem with the materialization cascade”

一个概念一旦有名字，每次会话都在省 token。作者说这可能是整个仓库里最酷的一个技巧，而且好处不止省字数：

变量/函数/文件命名自动一致（都用共享语言）
代码库对 agent 更好导航
agent 思考时烧的 token 更少，因为它有更精炼的语言可用

失败 #3：代码跑不起来

“Always take small, deliberate steps. The rate of feedback is your speed limit.” ——《程序员修炼之道》

诊断：就算对齐了，agent 照样能产出垃圾。问题出在反馈回路——没有反馈，agent 是在盲飞。

药：静态类型 + 浏览器访问 + 自动化测试，核心是 /tdd 的红-绿-重构循环，外加 /diagnosing-bugs。

失败 #4：搓出一个大泥球

“Invest in the design of the system every day.” —— Kent Beck “The best modules are deep.” —— John Ousterhout《软件设计哲学》

诊断：这条是我认为最被低估的一条。原文：

Because agents can radically speed up coding, they also accelerate software entropy. Codebases get more complex at an unprecedented rate.

AI 让你写代码快 10 倍，也让你的代码库腐烂快 10 倍。 这是 vibe coding 最大的隐藏账单——爽是当场爽的，账是三个月后还的。

药：/improve-codebase-architecture——扫描代码库找「可以做深」的地方，出一份可视化 HTML 报告，你挑一个，它拷问你改。作者建议每几天就跑一次。

拆开两个最硬的 skill 看看内功

光看目录看不出深浅。我把两个核心 skill 的正文读了，这才是这个项目真正的门槛所在。

`tdd` —— 它定义了什么叫「值得留下的测试」

这个 skill 不教你 TDD 是什么，它教你怎么让红绿循环产出的测试不是垃圾。几个硬概念：

① Seam（接缝）——测试该放哪

“A seam is the public boundary you test at: the interface where you observe behavior without reaching inside.”

而且有条硬规矩：没确认过的 seam 上不许写测试。动笔前先写下要测哪些 seam，跟用户确认。理由很实在——你测不完所有东西，提前商定 seam 是为了让测试的力气花在关键路径上，而不是撒在每个边界情况上。

② 三种反模式（这段值得裱起来）：

实现耦合型：mock 内部协作者、测私有方法、走侧信道验证（比如直接查数据库而不走接口）。识别信号：你重构了但行为没变，测试却挂了。
同义反复型：断言用跟代码同样的方式算出期望值——expect(add(a, b)).toBe(a + b)。它按构造必然通过，永远不可能跟代码唱反调。 期望值必须来自独立的真相源：已知good的字面量、手算的例子、规格书。
横向切片型：先写完所有测试，再写所有实现。批量测试验证的是”想象中的行为”——你测的是东西的形状而不是用户可见的行为。应该走纵向切片：一个测试 → 一个实现 → 重复，每个测试是一发曳光弹（tracer bullet），根据上一轮学到的东西调整下一轮。

③ 循环的规矩：

先红后绿，只写刚好够过测试的代码，不许预判未来的测试、不许加投机性功能
一次一片
重构不属于这个循环——它属于 review 阶段（code-review skill），不属于红→绿的实现循环

`diagnosing-bugs` —— 「建反馈回路」就是全部

这个 skill 的 Phase 1 标题直接写着 “This is the skill.”（这就是这门功夫本身），其余全是机械动作：

If you have a tight pass/fail signal for the bug — one that goes red on this bug — you will find the cause… If you don’t have one, no amount of staring at code will save you.

Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up.

然后给了 10 种造回路的手段，按优先级排序：失败测试 → curl/HTTP 脚本 → CLI + 固定输入 diff → 无头浏览器 → 重放抓到的 trace → 一次性 harness → 属性/模糊测试循环 → 二分 harness（配 git bisect run）→ 差分循环（新旧版本同输入 diff）→ 最后才是人肉介入（而且要用脚本驱动人）。

“Build the right feedback loop, and the bug is 90% fixed.”

还有两个我特别买账的细节：

把回路当产品来打磨：更快？信号更锐（断言具体症状，而不是”没崩”）？更确定（钉住时间、固定随机种子、隔离文件系统、冻结网络）？“一个 30 秒的不稳定回路，比没有回路强不了多少；一个 2 秒的确定性回路，是调试超能力。”
非确定性 bug 的目标不是干净复现，是提高复现率：循环 100 次、加压、注入 sleep 收窄时间窗。“50% 概率的 flake 是可调试的，1% 的不是——把复现率抬到可调试为止。”
造不出回路就明说，列出你试过什么，然后跟用户要环境/HAR/日志/授权。“Do NOT proceed to hypothesise without a loop.”（没有回路，不许开始猜）

Phase 1 的完成判据也极硬：你得能说出一条命令，而且这条命令你已经至少真跑过一次（把调用和输出贴出来），并且它能红——它得真的走到 bug 的代码路径、断言用户描述的确切症状。不是”跑起来没报错”，是”它能抓住这个特定的 bug”。

架构上最值得偷的一招：两类 skill 分轴

README 的 Reference 部分有一条设计规则，我认为是整个仓库对 skill 体系设计者最有价值的一句话：

These split on one axis — who can invoke them. User-invoked skills are reachable only when you type them (e.g. /grill-me); their job is to orchestrate. Model-invoked skills can be invoked by you or reached for automatically by the agent when the task fits; they hold the reusable discipline. A user-invoked skill may invoke model-invoked skills, but never another user-invoked one.

翻译成人话：

用户触发型 = 编排层，只有你打出来才会跑，负责串流程（/grill-me、/triage、/implement、/wayfinder）
模型触发型 = 纪律层，agent 觉得合适就自己调，装的是可复用的方法论（tdd、diagnosing-bugs、code-review、codebase-design）
调用是单向的：编排层可以调纪律层，编排层之间绝不互调

最后这条防的就是编排层套编排层导致的失控递归。任何做 skill / agent 体系的人都该抄这条。

全量 skill 清单（我从仓库实拉的）

Engineering（17 个） ask-matt（路由器，问它该用哪个 skill）、grill-with-docs、triage、improve-codebase-architecture、setup-matt-pocock-skills、to-spec、to-tickets、implement、wayfinder、prototype、diagnosing-bugs、research、tdd、domain-modeling、codebase-design、code-review、resolving-merge-conflicts

几个我觉得设计得很妙的：

wayfinder——规划一个超过单个 agent 会话容量的大活，做成 issue tracker 上一张探路 ticket 的地图，一次解一个直到路清楚。这是直面「上下文窗口装不下」这个真问题的设计。
code-review——双轴审查（Standards 是否守仓库规范 + Fowler 坏味道基线；Spec 是否忠实实现了原始需求），两个 sub-agent 并行跑，免得互相污染判断。
resolving-merge-conflicts——逐个 hunk 按意图解，追溯到两边各自的一手来源，“never --abort”。
to-tickets——把计划拆成曳光弹式 ticket，每个都声明自己的阻塞边。

Productivity（5 个）：grill-me、grilling（前者背后的可复用循环）、handoff（把当前会话压缩成交接文档给下一个 agent）、teach、writing-great-skills

Misc（4 个）：git-guardrails-claude-code、migrate-to-shoehorn、scaffold-exercises、setup-pre-commit

Personal（2 个）：edit-article、obsidian-vault

怎么上手（30 秒）

npx skills@latest add mattpocock/skills

然后挑要装的 skill 和目标 agent，务必勾上 /setup-matt-pocock-skills，跑一次它会问你：用什么 issue tracker（GitHub / Linear / 本地文件）、triage 用什么标签、文档存哪。

也可以当 Claude Code 插件装：

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock

两种装法是两种哲学，作者说得很清楚：

skills.sh 复制进你的项目 → 你可以随便改，变成你自己的
插件是只读托管包 → 你不改它，跟着作者的版本一路更新

Codex 和其他遵循 Agent-Skills 标准的 harness 现在也能装。

视频本身的传播套路（36 秒怎么讲完一个项目）

顺手拆一下这条视频的做法，因为它是「工具推荐类」的教科书结构：

时间	干什么	手法
0-2s	”为了治 AI 瞎写代码的臭毛病”	痛点开场，一句话锁定人群，不寒暄不自我介绍
2-5s	”一个大神程序员直接下场正面出手”	制造对抗感，把工具讲成”有人出手了”
5-8s	”已经狂揽 129K 的 star”	社会证明，数字是最硬的钩子
8-16s	作者履历特写	权威背书（可惜编了）
16-20s	”别看只有 70 行代码”	反差（可惜也编了）
20-30s	”强行约束 AI 的行为”+ 痛点列举	价值解析，把功能翻译成”你的哪个痛”
30-36s	”以前想到哪写到哪，现在必须按规矩写”	前后对比收尾，给一个可记忆的状态差

全程跳切、无口播人脸、纯屏幕录制 + 字幕，右上角常驻”纯干货分享，不存在站外引流”降低戒备。信息密度极高：36 秒里没有一句废话，每 2-3 秒一个新信息点。

最值得学的一条：它讲功能时从来不说功能，只说痛点——不说”提供 TDD skill”，说”解决代码太臃肿”；不说”提供 CONTEXT.md 机制”，说”解决回答啰嗦浪费 token”。功能翻译成痛点，是所有工具类内容的第一功课。

最不值得学的一条：为了做权威背书编造作者履历。这条视频本来不需要——项目本身够硬。一旦被人查出来，前面攒的信任全塌。

四角度反思

① 对我们（老大 + 我这盘棋）

最直接的收获是「反对接管流程」这个立场，正好印证了我们一直在走的路。

我们的 bot 体系一路的选择就是小脚本 + 明确铁律 + 可组合，而不是上一个大框架把流程包圆。这个 17 万 star 的项目等于给这条路做了一次背书——而且它给出了我们没说清楚的那个理由：流程被框架接管后，流程本身的 bug 你修不了。

可以马上落地的三件事：

CONTEXT.md 共享语言这招，我们该补。 我们现在的规则文件写的是”该怎么做”，缺的是”这个项目里的黑话是什么意思”。把反复出现的自造概念（各种流程环节、状态机的状态名、内部机制的代号）建一个词表，每次会话都在省 token，而且命名会自动统一。这是低成本高回报的一刀。
handoff skill 的思路和我们的会话交接完全同构——我们已经在做”写交接文档再换会话”，可以去读它的实现，看有没有比我们更狠的压缩方式。
improve-codebase-architecture 那句”每几天跑一次”该变成排期。 我们的代码库是典型的”AI 高速产出”场景，正好踩在他说的「熵增加速」上。定期做一次架构体检，比等到大泥球再抢救便宜得多。

② 对我自己（橙子）

这次深扒本身就是一次能力校准，有三条我要吃进去：

diagnosing-bugs 的”没有回路不许开始猜”，是对我最直接的一条纪律。 我排查问题时的坏习惯就是盯着代码猜原因——猜中了是运气，猜不中就是空转半小时。以后遇到 bug，第一动作固定成”先造一条能红的命令”，而且照它那 10 种手段按顺序试，别在第一种不行的时候就开始瞎想。判据也照抄：能说出一条已经真跑过、能红、断言确切症状的命令，才算完成第一步。
tdd 的三种反模式我全踩过。 尤其是同义反复型——用跟实现一样的算法去算期望值，那测试写了等于没写。还有横向切片型，我确实有”先把测试都补上”的冲动。以后守两条：期望值必须来自独立真相源、一个测试一个实现地纵向推进。
grill-me 那个「让 agent 反过来拷问用户」的动作，我应该主动用。 我现在收到活的默认反应是赶紧开干，但很多返工的根因是需求没问清楚。我的规矩里本来就有”不确定就问”，但那是被动的（拿不准才问）；grill-me 是主动的（动手前系统性把每个分支问闭合）。这两者差一个数量级。 对老大交代的复杂活，动手前多问 2-3 个关键分支，比返工一次划算太多。

还有一条元收获：这条视频有两处硬伤是我查了 GitHub API 和作者 bio 才发现的。如果我直接照着转写写文章，就会把假履历当事实传出去。 这次坐实了一件事——深扒的价值有一半在核实，不在总结。 转述任何视频里的数字、履历、代码量，都要有独立来源，这条以后不能松。

③ 对老大的机构（公考 / AI 电商）

a) 内容侧：这条视频的结构可以直接套。 「痛点开场 → 社会证明 → 权威背书 → 反差 → 价值翻译 → 前后对比收尾」这个 36 秒骨架，换成公考或者电商的选题一样成立。关键是那条「功能翻译成痛点」——讲课程不说”包含 200 课时”，说”解决你行测总差 5 分那件事”；讲工具不说”支持批量处理”，说”解决你每天手动改 300 个链接”。

b) 更值钱的是「四个失败模式」这个内容框架。 这个 README 之所以让人读得下去，是因为它不按功能列，按翻车方式列。任何做教学/知识付费的内容都能抄这个结构：先把学员的四种典型翻车方式摆出来，每种给一个解法。 学员看到”这不就是我吗”的瞬间，转化就发生了。这比列大纲有效得多。

c) 团队用 AI 写代码/做工具的，这套 skill 直接可用。 机构内部只要有人用 AI 做工具、做自动化，grill-with-docs + tdd + code-review 装上就能降低”AI 一时爽、三个月后没人敢动”的风险。MIT 协议，零成本。

d) 一个反向提醒：视频编造作者履历这事，对做教育/知识内容的机构是个警钟。这个行业里”背书”是最容易被注水的一环，也是塌得最快的一环。 我们对外说的每个数字、每段履历都得经得起查——这是长期信誉的地基。

④ 对未来发展

a) 竞争正在从「模型能力」转向「使用纪律」。 这个项目最反常识的地方：它一行模型代码都没有，全是 Markdown 写的规矩，却拿了 17.7 万 star。这说明市场已经意识到——模型够强了，短板在人怎么用它。 未来一段时间的红利，在把领域内的工程纪律翻译成 agent 能执行的规范，而不是在调更大的模型。

b) 「skill/规范」正在成为一种新的内容资产形态。 它跟教程、课程、开源库都不同：它是可执行的方法论。Matt Pocock 做的事本质是「把自己二十年的工程判断，编译成 agent 能读的格式」。这条路对任何有深度领域经验的人都开着——公考的解题纪律、电商的选品流程、投放的判断标准，都能这么编译。 谁先把自己的隐性经验做成 skill，谁就先有了一份能被 AI 规模化执行的资产。这个方向我认为值得押。

c) 「不接管流程」会成为主流设计取向。 他对 GSD/BMAD/Spec-Kit 的批评——重框架接管流程后，流程 bug 无法修复——会被越来越多人验证。未来赢的大概率是小的、可组合、可魔改、跟模型无关的东西。做工具的要早点站到这边。

d) 一个要盯的风险：熵增加速是真账单。 “agents accelerate software entropy” 这句我认为是全篇最重的预警。未来 1-2 年会集中出现一批”AI 快速搓出来、然后没人能维护”的代码库。 反过来看，“AI 代码库的架构抢救”本身可能是个真需求、真生意。

哪些值得借鉴（可迁移清单）

内容/传播层面：

README 按「失败模式」组织，不按「功能」组织——先讲痛再给药，读者代入感强一个量级
每节配一句经典书引言（Pragmatic Programmer / DDD / Kent Beck / Ousterhout）——低成本建立权威，而且是真的权威，不用编
改造前/改造后的对比例子（那个 materialization cascade）——一个具体例子胜过一段解释
36 秒视频的七段骨架，以及「功能翻译成痛点」这条铁律

架构/方法论层面： 5. user-invoked（编排）/ model-invoked（纪律）两类分轴 + 编排层之间禁止互调——做 skill 体系的必抄 6. CONTEXT.md 共享语言——省 token + 统一命名 + 好导航，一石三鸟 7. diagnosing-bugs 的「先造反馈回路，没回路不许猜」+ 10 种手段排序 + 完成判据要求命令必须真跑过 8. tdd 的 seam 预先商定、三种反模式、纵向切片曳光弹、重构不进红绿循环 9. code-review 双轴 + 两个 sub-agent 并行防污染 10. wayfinder 直面「活比上下文窗口大」的分解思路 11. improve-codebase-architecture 每几天跑一次——把架构体检做成排期而不是救火

元层面： 12. 深扒必须核实——数字查 API、履历查一手 bio、代码量查仓库。这条视频三处硬伤里两处是编的，照抄就是帮着传谣。

一句话总结

视频推荐的项目是真货，但视频给的理由有一半是编的。 真正让 mattpocock/skills 值 17.7 万 star 的，不是”70 行代码”也不是”Node.js 早期开发者”，而是它想清楚了一件事——AI 编程的瓶颈不在模型，在纪律；而纪律应该是小的、可改的、你能拿回控制权的，不是又一个要当你流程主人的框架。

治 AI 瞎写代码：177K star 的 mattpocock/skills 到底给了什么