AI 编程如何把需求澄清、TDD 与 Bug 诊断串成闭环

让 AI 直接开始编码时，最常见的返工并非代码写得不够快，而是需求中的关键选择尚未确认、测试验证了错误的行为，以及故障发生后没有可重复的失败信号。三类问题会相互放大：模糊需求让实现方向漂移，漂移后的测试难以说明预期，无法复现的故障又诱发大范围猜测性修改。本文给出一套可落地的质量闭环：先把影响设计的选择写入决策记录，再以单个行为推进 TDD，最后用机器可判定的反馈循环诊断故障。

先把需求转成可确认的决策

需求评审的目标不是尽可能多地提问，而是消除会改变实现边界的未知项。开始编码前，先读取现有实现、测试、接口约束和任务描述，然后区分两类信息：能够从仓库或运行环境直接确认的事实，以及必须由需求方选择的决策。

对于后者，一次只确认一个问题，并记录推荐方案、备选方案和影响。例如，新增导出功能时，先确认导出文件是同步生成还是异步生成；这个选择决定接口响应、错误处理和测试策略。确认后再讨论文件格式或权限范围，避免将互相依赖的选择混在同一轮问答中。

每个需求在进入实现前至少应留下以下记录：

目标行为：用户能够从已筛选的数据中创建导出任务。
范围边界：不修改既有筛选条件的语义。
成功标准：任务创建后返回可查询的标识；失败时返回可识别的错误。
停止条件：不处理异步通知和历史任务清理。
未决选择：无。

当仍有可能改变接口、数据模型或失败语义的未决选择时，继续编码只会把决策成本转移到返工阶段。

用单个行为推进 TDD

对 AI 编程而言，TDD 的关键不是先生成大量测试文件，而是让每次修改穿过一个完整、可观察的行为边界。一个切片只覆盖一个输入、一个可判定结果和实现它所需的最小改动。

可以按以下顺序推进：

Red：为尚未实现的行为写一个会失败的测试。
Green：只增加让该测试通过的最少实现。
Refactor：在测试保持通过的前提下整理重复或命名。
Repeat：选择下一个行为，而不是扩展当前改动的范围。

测试应围绕系统对外承诺的接缝，例如函数的输入输出、HTTP 请求响应、命令行退出码或消息处理结果。优先断言独立的期望值，而不是在断言中重复实现逻辑：

// 不应把计算逻辑再次写进断言
expect(add(2, 3)).toBe(2 + 3);

// 期望值独立于实现
expect(add(2, 3)).toBe(5);

复杂规则可使用人工确认的 fixture 或数据表来固定期望结果。这样测试失败时，团队能区分是需求改变、实现错误，还是测试数据需要更新。

诊断 Bug 前先建立反馈循环

没有稳定复现方式时，任何根因判断都只是猜测。AI 很容易在猜测基础上同时修改多个文件，使故障边界和真正原因更加模糊。诊断工作的第一项产出应当是一个可重复运行、能够给出明确成功或失败信号的反馈循环。

反馈循环可以是失败的回归测试、固定输入的命令、最小化脚本、HTTP 请求，或自动化浏览器场景。无论形式如何，都要满足三项条件：

1. 相同输入可以重复触发相同现象。
2. 成功和失败由退出码、断言或结构化响应判定，不依赖人工目测。
3. 修复后可以用同一条命令重新验证。

在得到反馈循环后，再按最小范围排查：

1. 缩小到最小输入、最少配置和最小文件范围。
2. 写下可被证伪的根因假设。
3. 用日志、测试或对照实验逐一排除假设。
4. 只修改与证据相关的部分。
5. 将复现方式保留为回归测试或可执行检查。

例如，接口偶发返回错误时，先固定请求体、运行环境和响应断言；如果现象不能稳定出现，就先调查输入、时间和外部依赖等变量，而不是直接调整重试或改写业务逻辑。

把闭环写进交付记录

一次 AI 辅助修改的交付记录应同时覆盖需求、实现和验证，而不只是一句“已完成”。可以使用如下模板：

需求决策：已确认的目标、范围和停止条件。
行为测试：新增或更新的测试名称，以及它覆盖的用户行为。
复现证据：故障输入、失败信号和复现命令。
修改范围：实际变更的文件与原因。
验证结果：运行的检查、结果和未覆盖的边界。
剩余风险：仍依赖人工确认或外部环境的事项。

这份记录使评审者能够追溯每项修改为何存在，并让后续排查有可复用的起点。对于涉及写入、删除或外部系统变更的任务，仍应明确人工确认点，不能把模型输出本身当作验证结果。

结论

需求澄清、单行为 TDD 和可复现诊断分别约束了“做什么”“如何证明实现正确”和“如何定位失败”。将它们串成闭环后，AI 编程的每次改动都有可确认的输入、可运行的验证和可追溯的范围。

本文适用于需要持续修改代码、处理缺陷和进行评审的开发任务；它不替代领域规则、集成环境验证或人工授权。面对依赖不稳定的外部服务时，仍可能无法立即获得稳定复现，此时应先记录变量与证据边界，再决定是否扩大调查范围。