KORTRESS
2026-03-30 ai

Claude Code TDD Skill,拆到一半就不拆了

by Ko

说来惭愧,我从来没认认真真写过测试代码。天天忙着写功能,测试永远排在最后。直到有一天听到"先写测试"这个说法,才动了试试的念头。正好 Claude Code 有个叫 Skill 的功能,就挑了个 TDD Skill 上手了。

先说结论:打开 Skill 文件想提炼要点,结果拆到一半就停了。原因很简单——原文写得太好了,我再怎么总结都是在打折扣。所以这篇文章就叫"拆到一半就不拆了"。

Skill 是什么?

用 Claude Code 的时候,是不是经常要在提示词里反复输入同样的指令?"先写测试"、"提交信息这样写"、"重构按这个顺序来"之类的。Skill 就是把这些指令提前写成 Markdown 文件注册好的功能。调用之后,Claude 就会按照文件里的指令执行。

只需整理一次,以后就不用反复输入了。相当省事。

选了什么

GitHub 上 112k Star 的 obra/superpowers 仓库。从里面的 Skill 中选了 test-driven-development。为什么?因为 Star 多啊。

🔗 obra/superpowers - test-driven-development

TDD 30 秒速览

给不了解 TDD 的朋友简单说一下。就是先写测试再写代码的开发方式。

传统做法:写代码 → 报错 → 修 → 又报错 → 无限循环

TDD:先定好验收标准 → 理所当然地失败 → 写刚好能通过的代码 → 整理

"用账号 admin、密码 1234 登录,应该成功"

先把这个测试写好,运行当然会失败(🔴 Red),然后写刚好能通过的最小代码(🟢 Green),最后做整理(🔵 Refactor)。方向先定好了,代码就不会跑偏。

打开 Skill 文件一看

MD 文件一打开,目录是这样的:

  • Overview
  • When to Use
  • The Iron Law
  • Red-Green-Refactor
  • Good Tests
  • Why Order Matters
  • Common Rationalizations
  • Red Flags - Stop and Start Over
  • Example: Bug Fix
  • Verification Checklist
  • When Stuck
  • Debugging Integration
  • Testing Anti-Patterns
  • Final Rule

14 个章节。想想如果每次都要手动把这些输进提示词里,光想就头大。瞬间理解了 Skill 功能存在的意义。

拆一下结构

粗略看下来,大体分三个板块。

第一块——立规矩。 什么时候用(When to Use)、怎么用(The Iron Law)、做什么(Red-Green-Refactor)、为什么要按这个顺序(Why Order Matters),先把 TDD 的骨架搭起来。

第二块——堵住 Claude 容易踩的坑。 Good Tests、Common Rationalizations、When Stuck 这些章节就是干这个的。为什么需要?因为 Claude 做 TDD 的时候,会冒出"这个太简单了,不用写测试吧……"之类的自我说服,或者想跳过步骤。这些章节就是提前把路堵死。

第三块——用实例再钉一遍。 Example: Bug Fix、Verification Checklist、Testing Anti-Patterns 等章节,把前面讲的原则用具体案例和清单再夯实一遍。

规矩 → 堵坑 → 实例钉死。这个行文节奏让我印象挺深的。

说实话,在大厂的语言模型里,Claude 算是比较"犟"的。一旦它觉得某件事没有生产力,你怎么说它都不太听。换个角度看,你得让它明白"这样做为什么合理",它才会乖乖配合。Skill 的作者显然深谙此道——整个文件的逻辑结构即便是人来读也很顺畅,以后自己写 Skill 的时候完全可以拿来当范本。

核心要点就这些

  • 新功能、Bug 修复、重构——一律 TDD
  • 用户说"就这一次跳过",那就跳过(还是挺听话的)
  • Iron Law:先让测试失败,再写代码。防止"测试全过了就没问题"的侥幸心理
  • 严格遵守 Red-Green-Refactor
    • 🔴 Red:先写一个会失败的测试
    • 🟢 Green:写刚好能通过的最小代码
    • 🔵 Refactor:整理(去重复、理命名)

为什么拆到一半就不拆了

老实说,本来想继续总结的,但还是放弃了。原文本身写得太好了,我再怎么转述都会打折。

实际用下来,光是"先写测试"这一条规则,开发节奏就完全不一样了。先定义好要做什么再动手,方向感清晰了很多。而且 Claude 在执行这个 Skill 的时候,真的老老实实按 Red → Green → Refactor 走,这点让我挺意外的。

剩下的建议直接去读原文。我停下来没拆的那部分,才是真正的精华。

🔗 去看原文

Comments (0)

Be the first to leave a comment.

Kortress Archive System

Claude Code TDD Skill,拆到一半就不拆了