W
AI-Wiki
ENTITY

tdd

定义

tdd 是一个工程类技能，属于 Model-invoked 技能，用于在代码工作中执行 测试驱动开发。它的核心工作方式是使用 red-green-refactor loop，让 agent 先写失败测试，再实现代码使测试通过，最后重构。

该技能既可用于构建新功能，也可用于修复 bug。原文明确说明它可以 slot into any project，即并不依赖某个特定项目结构或单一开发流程，可以作为通用工程纪律嵌入不同项目中使用。

身份与角色

tdd 在技能体系中的定位不是高层编排器，而是可复用的底层工程纪律。与只在用户显式输入时触发的 User-invoked skills 不同，tdd 作为 Model-invoked 技能，既可以由用户直接调用，也可以在任务适配时由 agent 自动采用。

它的角色主要有三层：

  • 为 agent 提供稳定、频繁的自动化测试反馈回路，避免“盲飞”式编码。
  • 约束实现节奏，要求以 red-green-refactor 的小步循环推进，而不是一次写完大块代码。
  • 提供关于什么是好测试、什么是坏测试的指导，提升测试质量，而不只是机械增加测试数量。

核心工作方式

red-green-refactor loop

tdd 的核心是 red-green-refactor loop：

  1. Red：先写一个失败的测试。
  2. Green：编写最少量的实现代码，让测试通过。
  3. Refactor：在测试保持通过的前提下整理实现与设计。

原文特别强调，对于自动化测试来说，这个循环是 critical。原因不是形式主义，而是它能给 agent 提供持续且一致的反馈水平，使产出的代码明显更可靠。

一次只处理一个 vertical slice

tdd 不是鼓励大爆炸式开发，而是强调 one vertical slice at a time。也就是每次只完成一个可验证、可闭环的小切片：从测试、实现到通过，形成一个完整增量，再进入下一个切片。

这种做法的边界很明确：

  • 不应一次吞下过大的任务。
  • 不应在缺少可运行反馈的情况下堆积大量实现。
  • 不应把测试延后到“代码差不多写完再补”。

这与原文中“反馈速率就是速度上限”“永远不要接过大的任务”这一工程原则一致。

解决的问题

原文讨论的场景是：即使你和 agent 已经对要构建的内容达成一致，agent 仍然可能产出不能工作的代码。此时问题往往不在需求描述，而在反馈回路不足。

如果 agent 无法获得代码真实运行结果的反馈，它就会“flying blind”。针对这个问题，原文提出应具备一组常规反馈回路，包括：

  • 静态类型
  • 浏览器访问能力
  • 自动化测试

其中，tdd 对应的是自动化测试这一环，而且不是任意测试，而是强调 red-green-refactor 的测试驱动方式。

关键信息

  • 属于 Model-invoked 技能。
  • 可由用户调用，也可在任务适合时被 agent 自动采用。
  • 使用 red-green-refactor loop。
  • 可用于构建功能或修复 bug。
  • 可以 slot into any project。
  • 一次处理一个 vertical slice。
  • 为 agent 提供关于好测试与坏测试的指导。

细节与边界

它不只是“写测试”

tdd 的重点不是给现有代码补几条测试，而是把测试作为实现的起点。原文明确写到：agent 先写一个 failing test，然后再去修复它。这意味着测试先于实现，测试本身承担了澄清行为、建立反馈和限定变更边界的职责。

它服务于反馈回路，而不是替代全部反馈

tdd 很重要，但原文并没有把它说成唯一答案。它与静态类型、浏览器访问等反馈手段并列，属于“usual tranche of feedback loops”的一部分。因此，它适合与其他工程机制配合，而不是单独承担所有质量保证职责。

它是可复用纪律，不是项目专属流程

原文特别指出 tdd 可以 slot into any project，这说明它被设计成跨项目可迁移的技能。它不是只适用于某个仓库、某个框架或某种任务模板的特殊流程。

它强调测试质量判断

原文不仅说它鼓励 red-green-refactor，还说它会给 agent plenty of guidance on what makes good and bad tests。也就是说，这个技能不仅规定“要写测试”，还试图区分：

  • 什么样的测试能提供有效反馈；
  • 什么样的测试只是噪音、脆弱或误导；
  • 什么样的测试切片适合推动下一步实现。

虽然给定片段没有展开这些判断标准的完整清单，但“提供好测试/坏测试指导”本身是该技能的重要身份特征，必须保留。

在技能体系中的关系

tdd 位于工程技能列表的 Model-invoked 分组中，和 diagnosing-bugs、research、domain-modeling、codebase-design、code-review 等并列，代表可被复用的专门纪律。

它也会被更高层的用户触发型流程调用。原文明确指出，implement 会在预先约定的接缝处驱动 /tdd，并在提交前再经过 code-review。这说明 tdd 通常是实现阶段中的一个核心执行机制，而不是项目入口或规划入口。

适用场景

tdd 适用于以下场景：

  • 需要逐步实现新功能时；
  • 需要修复 bug 且希望先建立复现与回归保护时；
  • agent 已理解目标，但产出质量不稳定时；
  • 需要通过小步反馈降低改动风险时；
  • 希望把实现拆成一个个可验证 vertical slice 时。

相关条目