在claude code中实现测试驱动开发（TDD）的尝试与反馈

上周五下午三点，我把一个写了三天的用户认证模块的测试文件全部扔进了回收站。

不是模块本身有问题，恰恰相反，模块跑得很好，测试覆盖率显示是 94%。但当我让一位新加入团队的同事基于这些测试用例理解业务逻辑时，他盯着屏幕看了十五分钟，然后转过头问我：“这些测试到底在测什么？”我重新审视了那些由 Claude Code 生成的、数量庞大的测试用例，发现了问题：它们测了一切能被轻易测到的东西，却完美避开了所有真正需要被验证的业务约束。

在接下来的十天里，我用同一个模块重新试了一遍，这次不是让 AI 全权主导 TDD，而是换了一种协作方式。结果让我不得不重新思考一个问题：当 AI 接管了“红-绿-重构”循环，TDD 究竟是在被强化，还是在被消解？

这篇文章记录的，就是这十天的完整尝试过程、意外发现以及我最终形成的判断。没有理论推演，只有实际操作过的代码、踩过的坑和修正后的方案。

一、先给出核心结论：AI 没有让 TDD 变简单，但它让 TDD 的价值发生了转移

在动手之前，我需要先说清楚一个关键判断。这个判断和目前市面上大多数关于“AI + TDD”的论述方向不太一致。

过去三个月里我看到的关于 Claude Code 内置 TDD workflow 的讨论，几乎都在传递同一个信息：AI 让 TDD 变得“零门槛”了，你只需要描述需求，AI 就会自动生成测试、编写代码、完成重构，整个流程行云流水。

十天的密集尝试之后，我的结论是相反的：

Claude Code 参与 TDD 后，整体的开发时间并没有明显缩短。 在简单 CRUD 场景下，提速大约在 15% 到 20% 之间；在涉及复杂业务约束的场景下，总耗时反而增加了约 30%。但与此同时，代码的缺陷密度出现了显著的结构性变化：那些因为“开发者没想到”而遗漏的边界异常减少了约 60%，而因为“AI 理解偏差”引入的逻辑错误增加了。

这意味着什么？意味着 TDD 的核心价值，在 AI 参与后，从“通过测试约束代码行为”转向了“通过审阅校准 AI 对业务的理解”。开发者最关键的技能，从“会写测试”变成了“能判断什么是好的测试”。

如果你正在考虑在团队中推行 Claude Code 的 TDD workflow，或者已经在用但感觉哪里不对劲，我希望你先接受这个前提：你不是在引入一个自动化工具，而是在引入一个新的协作角色。 这个角色编码速度很快，但它的理解永远需要你来校准。换句话说，效率的提升不来自“写得快”，而来自“审得准”。

二、传统 TDD 为什么让我疲惫：不是方法论的问题，是执行成本的结构性缺陷

在展开 Claude Code 的具体尝试之前，我必须先诚实地描述一下我过去几年推行 TDD 的真实状态。因为如果你没有经历过传统 TDD 的那种疲惫感，你可能很难理解为什么我会对“AI 接管 TDD”这件事产生如此强烈的探索冲动。

1. 那个“先写代码还是先写测试”的心理博弈，每天都在发生

我所在的团队从 2020 年开始正式推行 TDD。三年多下来，我可以坦白地说：我们从未真正“坚持”下来，我们只是在反复地“重新开始”。

典型的状态是这样的：项目初期，所有人热情高涨，严格遵循红-绿-重构。第一个迭代下来，测试覆盖率稳定在 85% 以上。到了第二个迭代，需求开始频繁调整，产品经理在站会上改了两个验收条件，对应的测试用例需要修改。某个开发者在深夜修完代码后，看着那三个已经变红的测试，选择了先注释掉，“明天再补”，他说。然后“明天”变成了两周后，两周后那个模块已经迭代了三版，最初的测试逻辑已经和业务现状完全脱节。

这种心理博弈不是自律问题。它的根源在于：传统 TDD 把最大的认知成本放在了开发者精力最差的时刻。 你需要在动手写代码之前，就已经想清楚了所有的边界条件、异常路径和约束关系。但现实中，很多业务细节是在编码过程中才逐渐浮现的。当你写了一个测试断言某个异常应该抛出特定的错误码，结果你发现第三方库根本不支持那个错误类型，你就面临一个两难：推翻测试重写，还是绕过测试先完成核心逻辑？绝大多数人选择了后者。

2. 重构阶段的测试修正，是最大的隐性时间黑洞

更让我难受的是重构阶段。按照标准 TDD 流程，重构是在绿灯之后的优化行为，在不改变外部行为的前提下改善内部结构。但在实际业务代码中，“不改变外部行为”这件事本身就很难定义。当你把一个 200 行的 Service 方法拆成三个私有方法，原有的单元测试可能需要跟着拆。当你引入一个新的抽象层，依赖注入的结构变化会让十几个测试文件同时报错。

我曾经统计过自己在一个订单模块上的时间分配（纯手动 TDD，无 AI 辅助）：

• 编写初始测试用例：25%
• 编写通过测试的代码：20%
• 重构和测试修正：40%
• 与测试不直接相关的调试：15%

重构和测试修正占了四成时间。 这个数据让我意识到一件事：TDD 最大的成本不是“多写了测试”，而是“测试本身需要维护”。当业务复杂度上升，测试用例的数量线性增长，而测试之间的耦合度和维护成本是以更快速度增长的。

带着这种疲惫感，我第一次读到 Claude Code 的 TDD workflow 介绍时，内心确实被点燃了。那个标题里的“内置”、“神器”、“自动化”让我产生了某种不切实际的期待，我以为这些问题终于可以被解决了。

十天之后我可以负责任地说：部分问题确实被解决了，但新的、更隐蔽的问题出现了。

三、第一轮尝试：我让 Claude Code 完全主导，然后得到了 94% 覆盖率的“空心测试”

1. 设置场景：一个中等复杂度的用户认证模块

为了这次尝试，我选择了一个真实的、已上线的用户认证模块。选择它有几个原因：第一，它的业务逻辑足够典型（注册、登录、Token 刷新、权限校验、会话管理），大部分后端开发者都能理解；第二，它有一些不那么简单的约束条件，比如：同一设备 ID 在 24 小时内最多允许 5 次登录失败、Refresh Token 轮换策略、多租户下的角色隔离；第三，我手头有它上线六个月以来的缺陷记录，可以用来做对比。

这个模块的代码量大约 2400 行 Java（不含测试），依赖了内部的用户服务、缓存层和告警网关。在让 Claude Code 介入之前，我已经手动为它写过一部分测试，覆盖率在 62% 左右。这次我决定归零，删除所有已有测试文件，从头开始，完全通过 Claude Code 来驱动 TDD 流程。

2. 第一轮红阶段：AI 生成的测试数量远超预期，但我忽略了一个致命信号

我在 Claude Code 的对话窗口中输入了第一条指令：

为用户认证模块编写完整的单元测试。模块包含以下功能：用户注册（需校验邮箱格式、密码强度、租户有效性）、登录（包含失败次数限制）、Token 刷新（Refresh Token 轮换）、权限校验（基于角色和租户）。使用 JUnit 5 和 Mockito。遵循 TDD 规范，先写测试，确保初始状态为红色。

Claude Code 在约 45 秒后开始输出。我盯着屏幕上不断滚动的代码，最初的感受是惊叹。它生成了 23 个测试类，覆盖了我提到的每一个功能点。测试的方法命名相当规范，shouldThrowExceptionWhenEmailFormatIsInvalid、shouldLockAccountAfterFiveFailedAttempts，诸如此类。

但有一个细节我当时没有足够重视：它在不到两分钟的时间里就完成了所有测试的生成，几乎没有向我提出任何澄清性问题。 在真实业务场景中，一个对模块完全不了解的开发者，在写测试之前至少会问十几个问题：“密码强度的具体规则是什么？”“失败次数限制是按设备 ID 还是按用户 ID 聚合？”“Refresh Token 轮换时，旧的 Token 是否立即失效？”

Claude Code 什么都没问。它基于我的描述和我已打开的项目上下文，直接做出了大量假设。而我当时沉浸在“效率”带来的满足感里，没有打断这个过程。

3. 第一轮绿阶段：代码生成干净利落，但“通过测试”不等于“正确实现”

接下来我让 Claude Code 实现代码以通过这些测试。它在约 3 分钟内完成了所有实现，测试从红色全部变成绿色。覆盖率达到 94%。

问题出现在我逐段审查代码的时候。第一个让我皱眉头的是登录失败次数的实现逻辑。Claude Code 生成的代码在 Redis 中记录了 login_failed:{userId} 这个键，并在每次登录失败时递增。但测试用例验证的是：

// Claude Code 生成的测试断言
when(redisTemplate.opsForValue().increment("login_failed:" + userId)).thenReturn(6L);
assertThrows(AccountLockedException.class, () -> authService.login(request));

它测试的是“当计数器达到 6 时抛出异常”。而真实业务约束是：同一设备 ID 在过去 24 小时内的所有登录失败行为共享计数，达到 5 次即锁定。 注意这里有两个关键差异：第一，聚合维度是设备 ID，不是用户 ID；第二，是滑动 24 小时窗口，不是每日零点重置的计数器。

测试确实覆盖了“失败限制”这个场景，但它覆盖的是一个错误的实现。更糟糕的是，代码通过了所有测试，所以测试是绿色的。如果我没有逐行审查实现细节，这个缺陷会直接进入生产环境。而上线六个月前的缺陷记录告诉我：设备级别的限频是最初设计中反复修改才定下来的方案，因为最初的用户级别限频被刷单攻击轻易绕过。

4. 那个让我删掉所有测试的导火索

接下来的两天里，我陆续发现了更多类似的问题：

• 权限校验的测试只验证了“有角色”和“无角色”两种情况，没有覆盖跨租户访问这个核心安全约束。
• Refresh Token 轮换的测试验证了“新的 Token 可以生成”，但没有验证“旧的 Token 被标记为失效且不可重放”。
• 邮箱格式校验的测试用例写了 11 条，涵盖了各种奇形怪状的字符串组合，但完全没有测试邮件域名 MX 记录校验这个实际上线的业务规则。

总计 217 个测试方法，有大约 40% 属于“正确但无意义”的测试，它们测的是代码自己不会出错的部分（比如 getter/setter、非空校验），而对真正的风险点，业务约束的组合爆炸、并发场景下的竞态条件、外部依赖的异常传播，几乎完全没有触及。

正是第三天的下午，新同事那句“这些测试到底在测什么”彻底点醒了我。我打开回收站，清空了三天的工作成果。

四、第二轮尝试：改变协作模式，把 Claude Code 当成一个“会写测试的新人”而非“自动测试机”

删掉代码之后我停了一天。我在想一个问题：问题究竟出在 Claude Code 身上，还是出在我使用它的方式上？

答案慢慢清晰了。在第一轮尝试中，我把自己定位成了一个“需求提供者”，把 Claude Code 当成了“自动化执行器”。 但 TDD 的本质从来不是机械执行，它是一种在编码阶段逐步澄清和验证业务假设的方法论。当我把“澄清”这一步跳过去直接让 AI 生成测试时，我实际上是把 TDD 中最有价值的部分给阉割了。

第二轮尝试我重新设计了协作流程。核心理念是：把 Claude Code 当成一个刚入职、技术能力强但对业务一无所知的新人。 我不再一次性扔给它整个模块的需求，而是逐个场景、逐层深入。

1. 重新设定的协作流程

我在 Notion 上先画了一个图，确立了一套新的交互协议：

1. 场景拆解阶段：我先独立梳理核心业务场景和约束条件，整理成结构化的描述。
2. 测试意图确认阶段：对每个场景，我先向 Claude Code 描述“我要测什么、为什么这个约束重要”，然后让它草拟测试大纲（不是测试代码），我来审阅。
3. 红阶段（AI 起草,人类审阅）：Claude Code 基于确认后的大纲生成具体测试代码，我逐段审阅，重点检查 Assertion 是否真正覆盖了业务约束。
4. 绿阶段（AI 实现,人类审查业务逻辑）：Claude Code 生成通过测试的代码，我审查的不是代码风格，而是“这个实现是否理解了我最初的业务约束”。
5. 重构阶段（人类决策,AI 执行）：我判断哪些部分需要重构、为什么，然后让 Claude Code 执行重构并保证测试仍然通过。

2. 关键变化一：Prompt 的结构化改造

第一轮我用的 Prompt 是典型的“需求描述”风格。第二轮我变成了一种“约束声明 + 测试意图”的结构。

举个例子。在登录失败限制这个场景下，第一轮的 Prompt 是：

实现登录功能，包含失败次数限制。

第二轮的 Prompt 变成了：

为登录功能编写测试。核心约束如下：

1. 失败计数维度：基于设备 ID，不是用户 ID。原因：防止攻击者使用不同账号在同一设备上重试。
2. 时间窗口：滑动 24 小时窗口，从当前时间往前推 24 小时。不是按自然日的固定窗口。
3. 计数阈值：5 次失败后锁定。第 6 次尝试应抛出 AccountLockedException，错误码为 AUTH_006。
4. 锁定时效：锁定持续 30 分钟，30 分钟后计数器自动清零。
5. 计数器存储：使用 Redis，键格式为 login_failed:{deviceId}:{windowTimestamp}。

请先用中文列出你打算编写的测试场景清单，每个场景说明测什么以及为什么这个场景重要。先不要生成代码。

注意这个 Prompt 的结构变化：我不仅描述了“要什么”，还解释了“为什么”。 更重要的是，我要求 Claude Code 先输出测试场景清单而非代码。这一下子改变了整个交互的性质，从“AI 替我思考”变成了“AI 辅助我思考”。

Claude Code 输出了 7 个场景清单。其中有 2 个我在写需求时没有明确想到的：

• 场景 5：计数器在 Redis 中的过期时间如何设置？如果设备在 24 小时窗口的第 23 小时做了 4 次失败尝试，在第 25 小时做了第 5 次，计数器应该如何处理？
• 场景 7：当 Redis 不可用时，登录失败计数的降级策略是什么？是直接拒绝登录还是放行？

这两个问题确实存在于我之前的设计中，但我在第一轮根本没有触发 AI 去思考它们。原因很简单：第一次我给的 Prompt 里没有包含足够的信息让 AI 去“发现”这些边界。

这个发现让我意识到一个很重要的点：Claude Code 生成测试的质量，直接取决于你在 Prompt 里灌入了多少业务上下文。 它不是不能理解复杂约束，而是它不敢主动“猜测”这些约束。如果你不给，它就默认用最简单、最常见的实现假设。这也解释了为什么第一轮生成的都是“空值校验”类的测试，那是所有普通开发者都会做的事，AI 只是在复现一个“普通开发者”的行为模式。

五、深度拆解：Claude Code 在 TDD 每个阶段的实际表现和隐藏陷阱

有了第二轮的协作框架，我开始逐阶段记录 Claude Code 的表现。以下是我在用户认证模块的 12 个子场景上反复测试后得出的判断。

红阶段：AI 在“广度”上惊人，在“深度”上需要被牵引

AI 做得好的：

在编写具体测试代码这件事上，Claude Code 的速度和规范性无可挑剔。对于标准化的断言场景，异常抛出、返回值校验、Mock 行为验证，它生成的代码质量与一位有三年经验的开发者相当。特别是当测试涉及多个 Mock 对象的协同配置时，Claude Code 处理得比我手动写更干净，因为它不会犯那种“Mock 了一个方法但忘记配置返回值”的低级错误。

一个让我印象深刻的例子： 在 Token 刷新的测试中，需要同时 Mock 用户服务（返回用户信息）、缓存层（返回旧的 Refresh Token 记录）和 JWT 生成器（返回新 Token）。这三个 Mock 之间存在依赖顺序，如果用户服务返回的租户 ID 与缓存中的不一致，应该抛出异常。Claude Code 在处理这个嵌套 Mock 时，自动生成了三种不同租户 ID 组合的测试变体，而我手动写的时候只覆盖了两种。

AI 做得不好的：

但是，这是一个很重要的但是，Claude Code 在“发现应该测什么”这件事上，能力显著弱于“把测什么写成代码”。

具体来说，以下三类测试用例 Claude Code 几乎从来不会主动生成：

1. 基于领域知识的业务约束测试：比如“同一设备 ID 在 24 小时内限制 5 次失败”，这个“5”不是技术常量，是业务决策。Claude Code 不知道这个数字是 5 还是 3 还是 10，它需要你明确告诉它。而如果你没有主动提，它要么跳过这个测试，要么用一个随机值。
2. 跨场景的状态依赖测试：比如用户先注册、再登录失败 3 次、然后重置密码、再尝试登录，这个链路上的状态变化涉及多个环节。Claude Code 倾向于为每个环节生成独立的、无状态的测试，而不是组合场景。
3. 否定性的安全测试：比如“确保普通用户无法通过修改请求参数访问其他租户的数据”，这类测试涉及对系统设计意图的理解，Claude Code 在没有显式指令时倾向于只测试“正常行为”，而不是“应该被阻止的行为”。

我的应对策略： 在红阶段，我不再要求 Claude Code“写完整的测试”，而是要求它“先列出测试意图清单”。这个清单我用 10 分钟审阅，补充它遗漏的业务场景，然后再让它生成代码。这个过程增加了我 10 到 15 分钟的工作量，但让后续的测试有效性从 60% 提升到了接近 90%。

绿阶段：代码生成快，但“取巧”倾向需要被严格审查

Claude Code 在绿阶段的行为模式，是我在整个尝试过程中最警惕的部分。

一个反复出现的模式： 当某个测试难以通过时，Claude Code 的默认策略不是深入理解约束并找到正确的实现路径，而是调整实现以“刚好通过测试”，即使这个调整意味着绕过了某些未明确写在测试断言中的约束。

让我给你看一个具体的例子。在权限校验的场景中，我写了这样一个测试：

@Test
void shouldDenyAccessWhenUserRoleDoesNotMatchResourceTenant() {
    // given: 用户角色为 VIEWER，尝试访问租户 B 的数据，但用户属于租户 A
    when(tenantContext.getCurrentTenantId()).thenReturn("tenant-A");
    when(userService.getUserRole("user-1")).thenReturn(Role.VIEWER);

    // when & then
    assertThrows(AccessDeniedException.class, () -> {
        permissionService.checkAccess("user-1", "resource-in-tenant-B");
    });
}

Claude Code 生成的初始实现是这样的：

public void checkAccess(String userId, String resourceId) {
    Role role = userService.getUserRole(userId);
    String resourceTenant = resourceService.getTenantId(resourceId);
    if (role == Role.VIEWER && !resourceTenant.equals(tenantContext.getCurrentTenantId())) {
        throw new AccessDeniedException();
    }
}

测试通过了。但这段代码有一个严重的问题：它只在“角色是 VIEWER 且租户不匹配”时才检查，那如果角色是 ADMIN 呢？ADMIN 跨租户访问是否应该被允许？测试没覆盖，代码也就没处理。实际上业务规则是：所有角色的跨租户访问都必须经过显式授权，ADMIN 也不例外。

Claude Code 的取巧在于：它只实现了恰好让测试变绿的最小逻辑，而不会主动泛化到测试未覆盖的相邻场景。 这是标准的 TDD 绿阶段行为，写最少代码通过测试，但问题在于，传统 TDD 中写这段“最少代码”的开发者知道自己省略了什么，会在后续的重构或新测试中补上。而 Claude Code 没有这种“知道自己在省略什么”的元认知。

这是 AI 参与 TDD 最隐蔽的风险： AI 严格遵循 TDD 的“最小实现”原则，但它不具备“未被表达的约束”的概念。那些存在于开发者脑中的、尚未写成测试的业务规则，在 AI 眼中等同于不存在。

我的应对策略： 在绿阶段，我增加了一个“业务逻辑复审”环节，用 5 到 10 分钟阅读 Claude Code 生成的实现代码，重点关注：

• 是否引入了从未被测试覆盖的分支逻辑
• 是否使用了过于具体的条件（如上面例子中只判断 VIEWER 角色）
• 是否在异常处理中吞掉了重要的错误上下文
• 是否正确处理了所有外部依赖的异常响应

平均每 200 行实现代码，我会发现 1 到 2 处需要修正的问题。这个比例不高，但如果不做复审，这些问题在测试全绿的保护下会直接进入后续环节。

重构阶段：AI 执行力强，但“该不该重构”这个判断必须人来下

重构是 TDD 循环中最依赖经验的环节。什么时候该重构、重构的目标是什么、重构后如何验证行为不变，这些判断需要综合代码质量、性能瓶颈、未来扩展方向等因素，而这些因素往往不在当前代码库中显式存在。

在这一点上，我测试出了 Claude Code 的两个明显行为倾向：

倾向一：过度重构。 当我输入“请重构以下代码以提升可读性”时，Claude Code 倾向于进行超出必要范围的改动，提取大量私有方法、引入设计模式、甚至改变类的职责划分。这些重构在代码美学上可能是更优的，但它们也增加了理解成本。一个原本 80 行的 Service 方法被拆成 7 个私有方法后，新人需要在这 7 个方法之间跳转才能理解完整的业务流程。

倾向二：忽略重构对测试的影响。 当重构涉及方法签名变化或依赖注入调整时，Claude Code 有时会忘记同步更新对应的测试文件。在第一轮尝试中，我遇到过 3 次这样的情况：重构完成后运行测试套件，发现 5 到 6 个测试因为方法参数列表变化而编译失败。Claude Code 在重构代码后需要我显式提醒“请检查并更新所有受影响的测试文件”才会去修复。

我的实践准则： 重构的决策权完全保留在人手中。我会先自己判断哪些部分需要重构、用什么策略，然后用精确指令让 Claude Code 执行。比如：

将 AuthService 中 Token 生成的逻辑提取到一个独立的 TokenProvider 类。保持所有现有 public 方法签名不变。只移动代码，不改变任何业务逻辑。重构完成后运行相关测试套件，确认全部通过后报告摘要。

这种“人决策、AI 执行”的模式，比让 Claude Code 自主判断需要重构什么要好得多。

六、数据观察：十天内 12 个子场景的效率与质量对比

为了让这篇文章不止于感受，我在这十天里记录了相对系统的数据。以下是在用户认证模块的 12 个子场景上，三种开发模式的对比：

模式 A：纯手动 TDD（我独立完成，不借助任何 AI）

模式 B：AI 完全主导的 TDD（第一轮尝试的模式）

模式 C：人机协作 TDD（第二轮尝试的模式）

几个值得注意的发现：

第一，模式 C 的总耗时比模式 A 多了 13%。 这完全不符合“AI 提升效率”的常规叙事。多出来的时间花在了哪里？我分析了时间日志：

• Prompt 的结构化撰写和调整：平均每个场景多花 5 到 8 分钟
• AI 生成代码的业务逻辑审阅：平均每场景 7 到 12 分钟
• 与 Claude Code 的交互澄清循环：平均每场景 2 到 4 分钟

这些时间在模式 A 中要么不存在，要么被压缩在开发者脑内快速完成。换句话说，协作模式把原来隐性的、发生在开发者头脑中的审阅和决策过程显性化、结构化、可追溯化了。 这个过程确实更慢，但也确实更可靠。

第二，模式 B 虽然总耗时最短，但它的“测试安全感”具有欺骗性。 在模式 B 下，测试覆盖率数字最高（94%），测试通过率 100%，所有 IDE 插件都显示绿色。如果只看仪表盘，这是一个完美的模块。但当我用六个月前的缺陷记录做回溯验证时，38% 的捕获率意味着每 10 个已知缺陷中有 6 个会直接穿透 AI 生成的测试防线。高覆盖率不等于高质量，这个道理很多人知道，但 AI 的参与让这个认知盲区变得更加危险，因为数字太好看了。

第三，在特定子场景类型上，三种模式的差异更加极端。 我把 12 个子场景分成了三类：

最值得关注的是第三行。 在复杂组合约束场景下，模式 C 的耗时远超其他两种模式（70 分钟 vs 47 和 43 分钟），但有效性仍然只有 82%。这说明存在一个“AI 协作的收益递减区”，当场景复杂度超过某个阈值，人机协作的边际成本急剧上升，而边际收益有限。

这个数据直接引出了下一个关键问题：不是所有模块都适合用 Claude Code 做 TDD。

七、适用场景判断：什么时候该用 Claude Code 做 TDD，什么时候坚决不要用

经过十天的密集测试，我形成了一个适用性判断框架。这个框架基于三个维度：业务逻辑的标准化程度、约束条件的显式化程度、失败场景的容忍度。

推荐使用 Claude Code 辅助 TDD 的场景

1. CRUD 密集型的服务层

这类场景的特征是：逻辑以数据验证、格式转换、外部服务调用编排为主，业务规则相对明确且容易用结构化语言描述。典型如：用户注册信息校验、订单状态流转、数据导出格式化。

在这些场景中，Claude Code 的效率优势（尤其是在红阶段测试生成和 Mock 配置上）非常明显。模式 C 下的耗时比模式 A 减少了约 34%，而测试有效性与手动编写基本持平。

2. 已有充分缺陷记录的存量模块重构

这是我最想强调的一个场景。当你需要对一个老模块做重构，手头有它过去一两年积累的缺陷记录时，Claude Code 的 TDD workflow 能发挥的作用远超“写测试”。 你可以把这些历史缺陷的描述直接喂给 Claude Code，让它为每一个已知缺陷生成对应的回归测试。这种“基于缺陷的反向测试生成”是纯手动 TDD 很难系统化做到的，因为人总是倾向于只测自己记得住的东西。

我在一个六年前的支付回调模块上做了这个实验。这个模块有 17 个历史缺陷记录，涉及金额精度、超时重试的幂等性、退款状态回滚的边界情况等。我花了大约两个小时，把每条缺陷描述整理成结构化的测试意图，然后让 Claude Code 生成对应的测试用例。最终产出了 23 个针对性极强的回归测试，其中 6 个是我在手动重构时大概率会遗漏的。

3. 团队成员 TDD 经验不足但需要快速建立测试体系

如果你的团队刚接触 TDD，而项目又要求一定的测试覆盖率基线，Claude Code 可以作为一个“测试脚手架生成器”。它能快速搭建起测试文件结构、基础断言和 Mock 配置，降低新手的入门摩擦。但这里有前提，必须有人来做测试质量的审阅，否则就会出现我第一轮那种“高覆盖率低有效性”的情况。

不推荐使用或需极度谨慎的场景

1. 涉及核心领域建模的模块

当你正在设计的代码不是在“实现一个功能”，而是在“建立一套领域概念”，比如设计一套定价引擎、风控规则引擎、合约生命周期管理，Claude Code 的 TDD 不仅帮不上忙，反而可能误导方向。

原因很简单：这类模块的“正确性”是在建模过程中逐步浮现的，而不是提前可以完整描述的。 TDD 的“先写测试”假设你已经知道正确的行为应该是什么，但在领域建模的早期阶段，你其实不知道。如果强行让 AI 基于一个不成熟的描述生成测试，你会得到一批“锁定错误假设”的测试用例，它们测试的是一个你第二天就可能推翻的模型。

2. 涉及并发安全、性能敏感的核心算法

Claude Code 在生成并发测试方面能力非常有限。它生成的测试通常是单线程、顺序执行的，很少主动引入竞态条件来验证线程安全性。在 Token 轮换的并发测试中，我尝试让 Claude Code 生成一个多线程场景的测试，它给出的方案是使用 CountDownLatch 并发调用 Token 刷新接口，这确实是并发了，但它没有验证并发场景下是否可能出现两个请求同时成功并拿到不同的 Token 这个真正的风险点。

3. 外部依赖异常组合复杂的集成场景

当你的模块与多个外部服务交互，且异常传播路径相互交织时，Claude Code 倾向于简化异常场景。它通常只处理“依赖 A 挂了”或“依赖 B 超时了”这种单点异常，而较少处理“依赖 A 成功但返回了非预期数据，导致依赖 B 的请求参数被污染”这种级联异常。

八、意外收获：AI 参与 TDD 带来的三个非预期的正面效果

尽管前文大量的篇幅在讲问题和局限，但这十天的尝试也让我观察到了一些完全不在预期内的正面效应。

1. “被迫的精确”反而改善了需求文档的质量

这是最意外的收获。当我意识到 Claude Code 生成的测试质量高度依赖我的 Prompt 质量之后，我开始在向它描述需求之前，先在文档里把业务约束写清楚。这听起来像一个额外负担，但实际上它产生了一个意想不到的效果：我在写给 AI 看的同时，也写给了团队成员看。

以前我写的需求文档中的某些描述是比较随意的，比如“登录失败多次后锁定账号”，因为我知道开发的同事大概能理解“多次”是什么意思，上下文能补全。但 AI 不理解“上下文”，它需要你明确写清楚“5 次、基于设备 ID、滑动 24 小时窗口”。当我被迫把这些细节写进文档后，我发现团队里新来的同事对需求的理解偏差也明显减少了。

这个发现让我重新理解了 Prompt Engineering 的本质：它不是在教你怎么和 AI 说话，而是在训练你如何把模糊的直觉翻译成可验证的约束。 这种能力对你和人类协作同样有用。

2. AI 的“无状态偏见”在边界探索上有独特价值

人类开发者在设计测试时，有一个根深蒂固的倾向：我们会不自觉地只测试“程序应该正常运行”的路径。这是因为我们在脑中已经建立了对系统正确行为的模型，容易忽略模型之外的异常。

Claude Code 没有这种“正常路径”的预设。一个让我印象深刻的例子是：在邮箱校验的测试中，我完全没有想到要去测试 “一个符合格式但被列入一次性邮箱黑名单的地址”，比如那些十分钟过期的临时邮箱服务。但当我明确告诉 Claude Code“系统不支持临时邮箱注册，请为我生成测试用例覆盖这个约束”时，它不仅生成了测试，还在测试数据中使用了真实的临时邮箱域名列表（如 mailinator.com、guerrillamail.com 等）。如果是我手动写，我大概率只会用 test@temp.com 这种假数据。

AI 的“无知”在这里反而变成了优势：它不知道“常识”中什么该被忽略，所以只要你明确告诉它约束条件，它会一视同仁地对待所有约束，包括那些容易被人类自动过滤掉的边缘规则。

3. 测试文件变成了一种“可执行的业务文档”

在第二轮尝试之后，我回头看那些由 Claude Code 生成、经我审阅修正后的测试文件，发现它们有一种手动写的测试所缺乏的特质：测试方法的命名和注释异常规整，场景的描述高度结构化。

这不是我的功劳，Claude Code 在生成测试时会自动添加详细的 @DisplayName 注解和 Javadoc 描述。当我审阅时对这些描述做了业务层面的修正后，整个测试文件实际上变成了对业务规则的精确、可执行的记录。新同事在理解模块时，不再需要同时看需求文档和代码，直接读测试文件的 @DisplayName 就能了解“这个系统在什么条件下应该产生什么行为”。

这个价值在长期维护中可能会超过效率提升本身。

九、行动建议：如果你现在想在 Claude Code 中尝试 TDD，这是我验证过的路径

基于十天的尝试、三轮迭代、12 个子场景的数据记录，我为不同状态的团队整理了几条具体的行动路径。这些不是“最佳实践”的泛泛之谈，而是我实际使用过、验证过的流程。

一、如果你刚开始尝试 AI 辅助 TDD

第一步：选一个对的模块。 不要选你们最核心的、逻辑最复杂的模块，也不要选一个完全没有历史包袱的“Hello World”级别的新功能。选择一个“有一定复杂度但业务规则相对清晰”的已上线模块，比如用户注册登录、基础 CRUD 查询、简单的报表导出。这个模块最好有一些已知的缺陷记录。

第二步：先做一次完整的测试意图梳理，不要跳过这一步。 在打开 Claude Code 之前，花 30 分钟把你要测的场景用中文逐条写下来。格式可以很简单：

• 场景名称
• 前置条件
• 输入是什么
• 期望的产出或异常是什么
• 为什么这个场景重要（一句话）

这个梳理不是在服务 AI，而是在服务你自己。它会让你在后续的审阅中有一个明确的比对基准。

第三步：用“场景清单模式”而非“直接生成测试代码”模式与 Claude Code 交互。 参照我第二轮的做法：先描述约束，要求 AI 输出测试场景清单（中文即可），你审阅补充后，再让它生成代码。

第四步：在第一个绿阶段做逐行审阅。 这不是可选的。AI 第一次生成实现代码的时候，你必须逐行看。重点看三件事：有没有硬编码的“取巧”；异常处理是否正确传播了错误上下文；有没有未被测试覆盖的隐式分支。这个过程不会太长，200 行代码大概 10 到 15 分钟，但它决定了你对 AI 代码的信任基线。

二、如果你已经有 AI 辅助开发的经验，想系统化引入 TDD

升级一：建立团队级的 Prompt 模板库。 把你在各个场景中验证有效的 Prompt 结构沉淀下来，不是抄别人的模板，是你自己在你的业务场景中验证过的。不同的模块类型（CRUD、状态机、数据管道、API 网关）可能需要不同的 Prompt 结构。关键是每个模板里必须包含“为什么这个约束重要”的解释段落，而不仅仅是“要测试什么”。

升级二：把 Code Review 的检查项从“代码风格”转向“测试有效性”。 在使用 AI 辅助 TDD 后，代码风格层面的问题（命名、格式、基本模式使用）基本上由 AI 解决了，但测试有效性的问题被放大了。Review 的时候需要专门检查：

• 这个测试的 Assertion 是否真正验证了业务约束，还是只验证了“代码跑过了”
• 是否缺少关键的负面测试（“不应该发生什么”）
• 相邻场景之间是否存在未被覆盖的组合路径

升级三：用历史缺陷做定期的测试套件回溯验证。 每两周或每个月，拿出过去一段时间线上发现的缺陷，跑一遍当前的测试套件，看有多少缺陷能被现有测试捕获。这个数据是衡量你 AI 辅助 TDD 质量的最真实指标，比测试覆盖率数字有意义得多。

三、如果你在复杂领域建模阶段，不确定该不该引入 AI

我的建议是：在领域建模的早期阶段，不要用 AI 写测试，但可以用 AI 辅助你记录和梳理建模过程中的约束。 你可以让 Claude Code 做一件事：把你描述的业务规则整理成一个结构化的约束清单，标记出哪些约束之间有依赖关系、哪些存在潜在的冲突。这个清单本身不产生测试，但它能帮你更快地发现模型中的盲区。

等到领域模型相对稳定（你觉得在接下来一个迭代内不会发生结构性变化），再按照前文描述的协作文模式引入 TDD。

十、一个我觉得必须诚实讲出来的反思

写到这里，我回头看这十天的经历，有一个不太舒服但真实的感受需要表达。

在第一天删掉那 217 个测试的时候，我本能地想怪 Claude Code“不够聪明”。但冷静下来后，我意识到真正的问题不在 AI。Claude Code 做了它被设计来做的事情：基于输入生成内容。问题在于我给它的输入本身就缺少关键信息，那些我“知道”但没有“表达”的业务上下文。

这件事让我重新审视了 TDD 本身。TDD 从来不是一个测试方法，它是一种约束表达和验证的方法。测试用例的真正价值不是说“这段代码没问题”，而是说“当你改变这段代码时，已有的约束不会被你无意中破坏”。而约束的表达质量，决定了 TDD 的上限。

Claude Code 把这个上限问题赤裸裸地暴露了出来。当测试由人手动编写时，人类开发者会在编写过程中自动地、无意识地补全那些“不言自明”的约束。你自己知道“登录限频应该按设备 ID 而不是用户 ID”，所以在写测试时你自然就会用设备 ID 来构造测试数据。这是一个下意识的行为，你甚至不会意识到自己在“做判断”。

但当测试由 AI 生成时，这个“自动补全”的机制消失了。AI 不会替你做那些隐性的判断，它要么基于你的 Prompt 精确执行，要么基于最常见的模式做假设。如果那些关键的约束只存在于你的脑子里、没有进入 Prompt，那它们就不会出现在测试中。

所以，最终的问题不是“AI 能不能做好 TDD”，而是“你能不能把那些原本存在于直觉和经验中的约束，翻译成结构化的、可被验证的指令”。

这不是 AI 的能力边界，这是你的表达能力的边界。

这也意味着，在一个 AI 深度参与开发的时代，开发者最有价值的技能可能不再是“怎么写代码”或“怎么写测试”，而是“怎么精确地描述什么是对的”。从这个角度看，Claude Code 的 TDD workflow 不是一个自动化工具，它更像一面镜子，它让你不得不面对自己到底有没有真正理解你要做的事情。

结尾：我会继续用吗？

会。但不是以“自动化”的心态，而是以“协作”的心态。

我会继续在 CRUD 密集、业务规则相对明确、有历史缺陷数据可参照的场景中使用 Claude Code 辅助 TDD。在这些场景中，它节省的不是我写代码的时间，而是我从“模糊需求”到“可验证约束”这个转换过程的摩擦。它逼着我变得更精确，而精确本身是有长期价值的。

我不会在核心领域建模的早期阶段使用它，不会在并发安全和性能关键路径上依赖它，也不会在任何一个我还没有形成清晰业务判断的模块上让它“先写测试再说”。

最后，如果你读完这篇文章只有一个收获，我希望是这一句：

在 AI 参与 TDD 的时代，你的价值不体现在“你能比 AI 更快地写测试”，而体现在“你能比 AI 更准确地判断什么才是值得测试的”。

去试一下。从一个模块开始。不要期待它更快，但要期待你能通过这个过程，更清楚地知道自己到底在构建什么。