/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
tdd Skill 深度研究报告 —— Matt Pocock 的 3.6KB 小文件，凭什么拿下 TDD 类 Skill 全球安装量第一？
免费基金定投助手全功能拆解：为什么你的基金定投还在亏钱？因为你的工具用错了。动态平衡仓位管理+8种智能定投策略引擎，会自己算买卖点的定投系统-CSDN博客
https://download.csdn.net/download/weitingfu/93448039?spm=1001.2014.3001.5503
写在前面：你被 AI 的 fix-break-revert 循环折磨过吗？
场景重演一遍，看看熟不熟悉。
你让 Claude 重构一个组件。 代码看起来干净了。 跑一下——坏了。 你让它修。 修完，另一个功能又坏了。 三个来回之后，你放弃，回滚一切。
更糟的是：你忘了先 commit。
眼熟吗？
这几乎是每个 AI 编程重度用户的日常。2026 年的残酷事实是：AI 写代码快 10 倍，破坏代码也快 10 倍。 而绝大多数人，手里没有任何安全网。
直到我遇到 tdd——Matt Pocock 出品的测试驱动开发 Skill。
它有多火？skills.sh 注册表显示：1,122,409 次安装，TDD 类目全球第一。它的母仓库 mattpocock/skills 在 GitHub 挂着 299K stars，是整个 Skills 生态的第二大仓库。
更离谱的是：整个 Skill 的核心文件 SKILL.md 只有 3,621 个字符。不到 4KB。
这篇文章，我带你把它拆透。
一、先复习：TDD 到底是什么？
TDD，Test-Driven Development，测试驱动开发。 一句话：先写测试，再写代码。
经典三步循环：
- RED：写一个会失败的测试，定义期望行为
- GREEN：写最少代码让它通过
- REFACTOR：在不改变行为的前提下，优化结构
听起来很简单？ 但人类几十年都没能坚持下来。因为人天生爱先写代码、后补测试——甚至不写测试。
而 AI 呢？
AI 更糟糕。 单独让 Claude 跑 TDD 时，它会先写完一整套测试、mock 掉所有内部依赖、再写出"永远不可能失败"的断言。测试是写了，但没有任何信息量。
这不是我的猜测，这是 tdd Skill 文档里的原话：
“Agents are good at writing tests and bad at writing tests worth keeping.” （Agent 很会写测试，但很不会写"值得保留"的测试。）
tdd Skill 存在的意义，就是治这个病。
二、杀手锏：接缝（Seam）先于测试
普通 TDD 教你怎么写。 tdd Skill 先逼你回答一个问题：测哪里？
它引入了一个核心概念：接缝（Seam）。
接缝是什么？公共边界。 在这条边界上，你能观察行为，而不需要扒开代码看内部。
规则只有一条：
测试只写在你和开发者事先确认的接缝上，永远不碰内部实现。
注意，这是整个 Skill 最硬的一条规则——写任何测试之前，Agent 必须先问你要测哪些接缝，得到你的确认才能动手。
听上去很繁琐？
答案不是洁癖，是预算。
你不可能测试所有东西。与其让 Agent 把测试撒在每一个边角料上，不如先把有限的精力锁定在关键路径和复杂逻辑上。接缝清单，就是测试资源的作战地图。 先定地图，再开枪，子弹才不会浪费。
这也顺带回答了一个哲学问题：什么才是好测试？ SKILL.md 里有一句话定义：“Tests verify behavior through public interfaces, not implementation details.” （测试通过公共接口验证行为，而不是通过实现细节。）
三、它封杀的三个反模式
tdd Skill 最出名的地方，是明确点了三个"反模式"的名字。每个都有可检查的特征（tell）——所以它们是规则，不是建议。
反模式一：实现耦合（Implementation-coupled）
测试 mock 内部协作者、调用私有方法、或者绕过接口去查数据库。
特征：重构后行为没变，测试却红了。 测试和实现绑死了，改实现结构就碎一地。
反模式二：同义反复（Tautological）
断言用和代码一模一样的方式重新计算期望值。
官方例子一针见血：expect(add(a, b)).toBe(a + b)。
这行测试靠"构造"通过，永远不可能和代码不一致。它测试的是自己，不是代码。
正确做法：期望值必须来自独立来源——已知正确的字面量、手工演算的例子、或者规格文档。
反模式三：横向切片（Horizontal slicing）
先一口气写完所有测试，再一口气写完所有实现。
特征：批量测试验证的是想象中的行为。你在还没理解实现之前，就锁死了测试结构，最后测的全是"形状"，不是"行为"。
四、垂直切片：一发一发的曳光弹
三个反模式的解药，是垂直切片（Vertical Slicing）：
一个接缝 → 一个测试 → 一个最小实现 → 重复。
每个测试都是一发曳光弹（tracer bullet）：上一轮教会你的，下一轮立刻用上。你是在"边打边校准"，而不是"先扫射一轮再检查弹着点"。
这里有个容易被忽略的设计细节：重构不在循环里。
tdd 刻意把重构路由到 code-review 阶段。为什么？
因为红绿循环只负责"行为正确"，重构是另一件事。职责单一，规则才不会稀释。它甚至会在项目有 GLOSSARY.md 时主动读取，让测试命名对齐你的领域语言，而不是通用命名——连命名风格都在向"领域真实"靠拢。
五、怎么装？怎么用？
安装就一条命令：
npx skills add mattpocock/skills –skill tdd
装好后，在支持 Skills 的 Agent（Claude Code 等）里调用 /tdd，它会接管整个红绿循环。
配套文件有两个，千万别当摆设：
- tests.md（2,214 字符）：好测试的具体标准
- mocking.md（1,481 字符）：什么情况下才允许 mock
SKILL.md 故意不重复它们的内容，而是"指向"它们。三个文件合起来，才是一个完整的 Skill。
六、同类对比：它不是唯一的选择
| tdd | mattpocock/skills | 1,122,409 | 接缝机制 + 三反模式，最严格、最硬核 |
| test-driven-development | obra/superpowers | 256,141 | 大方法论包内的组件，随 302K star 的 Superpowers 一起发 |
| test-driven-development | addyosmani/agent-skills | 58,281 | 轻量入门款，规则更宽松 |
| springboot-tdd / django-tdd | affaan-m | 各 ~11K | 框架定制循环，按技术栈拆分 |
如果想搭一套完整闭环，官方推荐的组合是：
- tdd（1.12M 安装）：红绿循环
- codebase-design（833K 安装）：决定接缝画在哪
- code-review（772K 安装）：接管循环外的重构
- diagnosing-bugs（818K 安装）：测试红了，先帮你定位 bug
四件套互相咬合，这才是 Matt Pocock 真正想让你用的"工程体系"，而不是一个孤零零的测试模板。
七、优点与坑
优点：
常见坑：
结尾：给 AI 一张安全网
FrontendJoy 有一篇爆款文章的标题，我记到现在：
“Your AI writes code 10x faster. It breaks it 10x faster too.” （你的 AI 写代码快 10 倍，破坏代码也快 10 倍。）
没有 TDD 时，你和 AI 困在 fix-break-revert 的死循环里：每次修复都引入新问题，三轮之后你已经忘了代码原本该干什么。
有了 TDD，规则反过来了：AI 一碰坏什么，测试立刻变红。 你一眼就知道它错在哪，不用等跑起来、等肉眼排查、等三个来回。
你的 AI 每小时都在产出代码，但它没有安全网。 装一个 3.6KB 的 Skill，让每一次"先红后绿"都变成可验证的工程事实。
别让你的 AI 继续盲写了。下一个需求，先跑一次 /tdd。
关键词：TDD；Agent Skill；Matt Pocock；测试驱动开发；接缝测试；红绿重构；AI编程安全网
