技能使用指南

test-driven-development（测试驱动开发）Skill 是什么？如何下载安装？

测试驱动开发Skill 让 AI 先写失败测试再写实现，严格执行 RED-GREEN-REFACTOR 循环，内置测试路径规范、验证命令与常见陷阱清单，有效避免假阳性测试。本文详解技能功能、安装启用步骤、真实使用场景与竞品对比，帮你把 TDD 纪律固化进 AI 编码流程，马上了解并启用。

测试驱动开发Skilltest-driven-development
8 个章节 约 14 分钟阅读 AI 智能生成

测试驱动开发Skill：让 AI 写代码前先写测试，交付质量可控

  • 一句话定位：把「先写失败测试 → 再写实现 → 最后重构」的 TDD 纪律固化进 AI 编码流程，避免 AI 直接堆代码、事后补测试。
  • 核心机制：严格遵循 RED（失败测试）→ GREEN（最小实现）→ REFACTOR（重构）三步循环，每个需求重复一次。
  • 明确边界：新函数、新特性、bug 修复、重构、API 变更一律走 TDD；UI 样式调整、配置更改、文档更新可直接跳过。
  • 关键约束：测试必须先运行并确认失败（防止假阳性）、一个需求对应一个测试、测试行为而非实现细节、提交前跑完整测试套件。
  • 适用人群：用 AI 辅助编码的开发者、需要保证交付质量的技术负责人、正在推行 TDD 但团队执行力不足的工程团队。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能中文名：测试驱动开发Skill 技能英文名：test-driven-development 技能ID：14078

它解决的问题非常具体：在使用 AI 编程助手时，模型往往倾向于「一次性把功能写完」，测试要么不写，要么写成「跟着实现倒推出来的测试」，导致测试永远通过、永远发现不了问题。这个技能把 TDD 的流程规则、判定边界、常见陷阱和验证命令写进技能的指令描述中，让 AI 在写代码之前先产出失败测试，并在实现后运行命令验证。

从技能详情看，该技能声明的可用工具为 Write、Read、Edit、Bash、Grep——也就是说它不仅能读写代码文件，还能通过 Bash 执行测试命令、通过 Grep 检索现有测试文件，形成「写测试 → 跑测试 → 看失败 → 写实现 → 再跑测试」的闭环。

一键安装的思路与步骤（具体命令与入口以官方说明为准）：

  1. 确认前提：使用支持 AI 技能（Skill）机制的编程客户端或插件，并已能正常调用模型；本地项目具备可执行的测试命令（如 Elixir 项目的 mix test、前端项目的 yarn test）。
  2. 找到技能：在所用平台的技能市场或技能仓库中，通过英文名 test-driven-development 或技能ID 14078 检索。
  3. 一键安装/启用：按平台提供的安装入口完成添加，安装方式与具体命令以官方说明为准；不需要额外配置复杂参数。
  4. 验证是否生效：安装后向助手提出一个带测试要求的需求，例如「为 Calculator 增加 calculate_total 方法，请按 TDD 流程进行」。若助手先输出测试文件并在运行测试后确认失败，再写实现，说明技能已生效；同时可检查测试文件是否落在技能约定的路径模式中（后端 test/path/module_test.exs，前端 ComponentName.test.tsx）。
  5. 兜底验证：让助手执行 mix test path/to/test.exs 或 yarn test path/to/test.tsx，观察是否能看到「先失败、后通过」的完整过程记录。

该技能的主要功能和特点

  • 强制 Red → Green → Refactor 循环：先写失败测试，再写「刚好够通过」的最小实现，最后重构改进代码质量，并对每个需求重复该循环。
  • 清晰的适用性判定：技能内置了「何时应用 TDD」清单，新函数/方法、新特性、bug 修复（先复现）、重构现有代码、API 更改必须走 TDD；UI 样式调整、配置更改、文档更新可以跳过，避免形式主义拖慢进度。
  • 按技术栈给出测试模式：后端（Elixir）文件位于 test/path/module_test.exs，例如 apps/api/test/your_app/task/task_test.exs；前端（TypeScript）使用 ComponentName.test.tsx，例如 mobile/libraries/atorasu/atoms/Button/Button.test.tsx。这解决了 AI 常见的「测试文件乱放、命名不统一」问题。
  • 可执行的验证路径：技能直接给出验证命令——后端 mix test path/to/test.exs，前端 yarn test path/to/test.tsx，让「测试是否真的失败/通过」可被检查，而不是靠模型自述。
  • 内置常见陷阱清单：明确列出「在测试前写实现」「测试未实现就通过（假阳性）」「测试实现细节而非行为」「未运行测试以验证先失败」等高发问题，相当于给 AI 附了一份自查表。
  • 与普通 AI 编码的关键差异：普通对话式编程是「需求 → 代码 → 也许补测试」，本技能是「需求 → 失败测试 → 最小实现 → 重构」，把质量动作前置，而不是事后补救。

如何使用该技能？

以下为可直接参考的分步使用流程：

  1. 明确需求边界：先用一句话说清要做什么，并说明属于哪类改动。例如：「新增后端函数 Calculator.calculate_total/1，输入价格列表，返回含 8% 税的金额，属于新函数，请走 TDD。」
  2. 让技能先产出失败测试：技能会先生成测试代码并运行。参考示例：
test "计算含税总额" do
  result = Calculator.calculate_total([100, 200])
  assert Money.equal?(result, Money.new(:USD, 324))
end

随后执行 mix test，此时测试应当失败——这一步是验证测试有效性，不能跳过。 3. 确认失败原因：检查失败信息是不是「函数不存在 / 行为不符」，而不是语法错误或环境问题，避免无效失败被误认为 RED 阶段完成。 4. 生成最小实现：技能会给出「仅足够通过」的代码，例如：

def calculate_total(prices) do
  prices |> Enum.sum() |> Kernel.*(1.08) |> Money.new(:USD)
end
  1. 再次运行测试确认转绿：执行同一条测试命令，观察是否通过；如果通过，进入下一步，不通过则回到实现环节。
  2. 重构阶段：在测试保护下提取常量、改进命名、消除重复，重构后再跑一次测试确认仍然全绿。
  3. 重复循环：每新增一个需求，重复第 2–6 步，坚持「一个需求一个测试」。
  4. 前端场景同理：在 ComponentName.test.tsx 中先写断言，再跑 yarn test path/to/test.tsx，最后补实现。
  5. 提交前收尾：运行完整测试套件，确认没有遗留失败测试；技能明确要求「绝不跳过失败测试」。

输出说明：正常情况下你会得到三段式产物——一份先失败的测试文件、一份最小实现代码、一次重构后的代码，以及每一步的命令执行结果。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
测试驱动开发Skill（本技能） 固化 TDD 纪律的 AI 编码技能 Red-Green-Refactor 循环约束、适用性判定、按技术栈的测试路径规范、验证命令、陷阱清单 需支持 Skill 的客户端并一键安装，具体以官方说明为准；几乎零配置 新函数、新特性、bug 修复、重构、API 变更 优势：把「先写失败测试」变成强制流程，防止 AI 事后补测试；不足：UI 样式、配置类改动会显得冗余，需要按清单跳过
通用 AI 编程助手（无 TDD 技能） 对话式代码生成 直接生成实现代码，可被要求补测试 门槛最低，无需安装 快速原型、一次性脚本 优势：出活快；不足：测试常被跳过或倒推生成，容易假阳性，缺少流程约束
开发者手工 TDD 依靠个人纪律的经典实践 人工写测试、跑测试、重构 无需安装，但要求开发者熟练 TDD 重视质量的团队 优势：理解最深、可控性最强；不足：强依赖自律与经验，节奏紧张时最容易被跳过，AI 参与时无法约束模型行为
测试覆盖率/静态检查工具 事后质量度量 统计覆盖率、静态规则校验 需接入 CI 与配置文件 流水线质量门禁 优势：可量化、可阻断合并；不足：只能「发现结果」，不能约束「先写测试」的过程，覆盖率数字也可能被低质量测试刷高

该技能的典型应用场景与实际体验情况

场景一：后端新增业务函数（Elixir 开发者） 痛点：用 AI 写业务函数很快，但测试经常缺失，或者测试是照着实现写的、永远通过。使用方式：提出需求时说明走 TDD，技能先在 test/.../xxx_test.exs 生成「计算含税总额」的失败测试，跑 mix test 确认失败，再产出最小实现并用 Kernel.*(1.08) 这类最简写法通过测试。 实际体验：上手难度低，因为技能已经把文件路径与命令都写死；效果最明显的是「先失败」这一步——能立刻暴露测试没有真正被执行的假阳性问题。注意：首次运行可能需要确认本地依赖与 Money 之类的库已就绪。

场景二：bug 修复先复现（后端/全栈工程师） 痛点：修 bug 时直接改代码，改完不知道是否真的修好，也不知道是否引入回归。使用方式：让技能先写一个能复现该 bug 的失败测试，确认「在修复前确实失败」，再改实现让测试通过。 实际体验：这是该技能价值最高的场景之一，因为「先失败」天然证明了测试有效。注意事项：复现测试要针对行为而非实现细节，否则重构时会误报。

场景三：前端组件开发（TypeScript 前端团队） 痛点：组件测试文件命名与位置随意，Button.test.tsx 有时被塞进业务目录，长期难维护。使用方式：按技能约定的 ComponentName.test.tsx 模式落地，例如 mobile/libraries/atorasu/atoms/Button/Button.test.tsx，先写渲染与交互断言，再跑 yarn test path/to/test.tsx。 实际体验：路径规范带来的团队一致性是意外收益；难点在于前端样式类改动较多，需要主动判断哪些属于「UI 样式调整可跳过」，避免为纯样式写无意义测试。

场景四：老代码重构（技术负责人/资深开发） 痛点：重构最怕「改坏了没发现」，而 AI 重构往往一次性改太多。使用方式：先用测试锁住现有行为，再在测试保护下逐步重构，每轮重构后跑完整测试套件。 实际体验：节奏会比直接重构慢，但换来确定性；技能中「提交前运行完整测试套件」「绝不跳过失败测试」两条规则，能有效阻止「先注释掉测试再说」的坏习惯。

该技能能为用户带来的价值

  • 质量动作前置，减少返工：把测试从「事后补」变成「事前写」，缺陷在编码阶段就被拦截，减少联调与线上问题排查的时间成本。
  • 消除假阳性测试：通过「测试必须先失败」这一条硬规则，直接掐掉「测试没实现就通过」这类最隐蔽的质量漏洞。
  • 降低 TDD 的执行门槛：很多人知道 TDD 好但坚持不下来，技能把流程、路径、命令、陷阱一次性写清，开发者只需描述需求，纪律由技能保证。
  • 统一团队测试规范：后端 test/path/module_test.exs、前端 ComponentName.test.tsx 的路径模式，让不同成员、不同 AI 会话产出的测试文件天然一致，长期可维护性显著提升。
  • 可控的适用边界：明确的「可跳过清单」避免了为文档、配置、样式强行写测试的时间浪费，让质量投入集中在真正有风险的地方。
  • 长期价值：测试套件本身就是可复用的回归资产，随着需求累积，重构与迭代的安全边际持续变大。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：在支持 AI 技能机制的客户端中，通过英文名 test-driven-development 或技能ID 14078 检索并一键启用即可；安装入口、命令与是否需要付费以官方说明为准。安装后建议用一个新函数需求验证是否先输出失败测试。

Q2：它和「直接让 AI 写代码再补测试」有什么区别？ A：区别在顺序不可颠倒。本技能要求先写测试、运行并确认失败，再写最小实现，最后重构；事后补的测试往往是照着实现写的，很容易永远通过，无法发现缺陷。技能还内置了假阳性、测试实现细节等陷阱清单用于自查。

Q3：所有改动都必须走 TDD 吗？会不会太慢？ A：不需要。技能明确列出了可跳过的场景：UI 样式调整、配置更改、文档更新。新函数、新特性、bug 修复（先复现）、重构、API 更改才必须走 TDD。用对边界，速度与质量可以兼顾。

Q4：只支持 Elixir 和 TypeScript 吗？ A：技能详情中给出的测试路径模式与验证命令分别是后端 Elixir（test/path/module_test.exs、mix test）与前端 TypeScript（ComponentName.test.tsx、yarn test）。其 Red-Green-Refactor 规则与陷阱清单是通用的，其他技术栈可参考同样流程，但具体命令与目录需按你项目的实际情况调整。

Q5：适合谁用？和普通 AI 编程助手怎么选？ A：适合用 AI 辅助编码、且对交付质量有要求的开发者与团队，尤其是正在推行 TDD 但执行力不足的团队。若只是写一次性脚本或快速原型，普通 AI 助手的「先出代码」更高效；若代码要长期维护、要重构、要修 bug，建议优先启用本技能以保证测试先行。