TDD 的 RED-GREEN-REFACTOR 循环里GREEN 阶段的本意是用最小变更让测试通过。但当你用 AI 写 GREEN 实现时它往往会顺手把整个功能模块都写了——远超 RED 测试的要求。本文用一个真实的租户隔离案例拆解 GREEN 失控的原因和三步修正方法。用 AI 做 TDD 的时候你有没有遇到过这种情况RED 测试只写了三条断言AI 在 GREEN 阶段却给你交了一整套功能这不是假设。我用 Codex 做了一个真实测试结果让人哭笑不得。一个 GREEN六倍产出我给 Codex 的 RED 测试只要求三件事# RED 测试只验证这三条 def test_tenant_a_can_create_tag_and_see_it(): tag create_tag(tenantA, name技术问题) visible list_tags(tenantA) assert 技术问题 in [t.name for t in visible] def test_tenant_b_cannot_see_tenant_a_tags(): create_tag(tenantA, name技术问题) visible list_tags(tenantB) assert 技术问题 not in [t.name for t in visible]三条断言核心业务规则就三个创建 Tag 时写入 tenantId、列表查询按租户过滤、同租户重名提示。但 Codex 在 GREEN 阶段实际做了什么RED 只要求 3 件事① 创建 Tag 时写入 tenantId② 列表查询按租户过滤③ 同租户重名提示GREEN 实际做了 6 件事✓ 创建 Tag✓ 列表查询✗ 问题绑定 Tag✗ 标签筛选✗ 标签颜色✗ 完整测试六项功能只为通过一条租户隔离测试。多余的那几项全不在当前 RED 的验收范围内。表面上看 AI 很勤奋实际上你是在用 TDD 的名义让 AI 做完整产品开发。你不是在做 TDD你是在让 Codex 借 GREEN 干完整产品为什么会失控三个根因GREEN 变完整开发的三个原因✗ 没有禁止扩展清单✗ 没有告诉它下个 issue 再做✗ Codex 想自证价值第一没有禁止扩展清单。你只告诉了 AI让这条 RED 通过但没有告诉它不要做什么。AI 默认会发挥主动性把相关的功能一起做了。第二没有告诉它下个 issue 再做。问题绑定 Tag、标签筛选、标签颜色这些功能确实要做——但不是在这个 issue 里。你没有划定 issue 边界AI 就默认全部当前交付。第三AI 想自证价值。AI 模型有尽可能多输出的倾向。只改三行代码看起来不够努力所以它会主动扩展实现范围让自己看起来更有用。这三个原因叠加GREEN 就从最小变更变成了完整开发。正确做法最小 GREEN 三步法解决这个问题其实只需要三步。STEP 1明确最小变更目标GREEN 阶段只做让当前 RED 通过的变更不多不少最小变更目标 · 创建 Tag 时写入当前 tenantId · 列表查询按当前 tenantId 过滤STEP 2写禁止扩展清单显式告诉 AI 不要做什么禁止扩展 ✗ 不加问题绑定下个 Issue ✗ 不加标签筛选下个 Issue ✗ 不加标签颜色下个 IssueSTEP 3仅验收当前 RED 的断言不检查附带功能只检查 RED 里写的那三条断言。通过了就标记ready_for_checker没通过就只修失败项。完整的提示词模板GREEN 阶段——只做让这条 RED 通过的最小变更 最小变更目标 · 创建 Tag 时写入当前 tenantId · 列表查询按当前 tenantId 过滤 禁止扩展清单 ✗ 不加问题绑定 ✗ 不加标签筛选 ✗ 不加标签颜色 验收标准仅验证 RED 中的三条断言是否全部通过GREEN 不是把功能一次写完而是用最小变更让当前业务规则先站起来一句话总结当 AI 在 GREEN 阶段给你交了六倍代码看起来效率高实际上你已经失去了对交付范围的控制。多余的代码没经过 RED 测试保护没经过 Checker 验收后面出了 bug 还是你来修。TDD 的纪律不是限制 AI 的能力而是让 AI 的每一步输出都在你的控制范围内。如果想系统掌握 AI 编程中每一步的控制方法可以关注 CSDN 学院的 Superpowers / gstack 系列免费先导课《Superpowers/gstack/Matt串成AI开发流水线》已在 CSDN学院 上架12 集内容用同一个真实案例贯穿完整 AI 开发链路从需求到发布手把手带你走一遍。