SDD、TDD 在真实项目中如何落地？

核心回答

在 AI 编码的语境下，这里的 SDD 指 Spec-Driven Development，规范驱动开发：先明确需求、约束和验收条件，再据此拆解任务、生成实现，并随变更维护规范。TDD 指 Test-Driven Development，测试驱动开发：针对下一小步行为先写测试，观察预期失败，用最小实现使其通过，再在测试保护下重构。

两者可以配合使用。SDD 解决“要实现什么、边界是什么”，TDD 把其中可确定验证的行为变成持续反馈。实际落地可以沿着四步展开：

1. 从现有业务和代码确定需求，写清输入输出、异常、权限与本次范围。
2. 把需求拆成能够单独验证的小任务，为关键规则准备测试数据和预期结果。
3. 每次选择一个行为，执行“红—绿—重构”，让 AI 辅助实现、补充边界用例或整理代码，由需求与测试约束修改方向。
4. 对接口、数据库及外部依赖做相应集成验证，检查实现与规范是否一致，并把缺陷转成回归用例。

例如，问数系统增加“按月汇总净销售额”时，先确定支付、取消和退款怎样计入，再用小数据集计算期望金额，随后实现聚合逻辑。这样可以把“数字看起来合理”变成可以运行检查的业务条件。流程的重量随风险调整：简单文案或已有字段展示通常只需明确改动与针对性验证，跨系统或关键业务规则才需要更完整的设计与测试。

用一个需求说明怎样落地

以下以新增月度净销售额统计为参考场景。

先把业务规则写到可验收

“统计本月销售额”仍然有歧义。需要明确金额口径、订单状态、时间范围、租户范围，以及无数据时返回什么。

假设业务约定为：按支付月份归属，只计成功支付订单，成功退款回冲原支付月，取消且未支付的订单不计入；月边界使用业务时区，开始时间包含、结束时间不包含；金额按分计算；只能汇总当前租户的数据。

这些是需求规则。技术设计再说明复用哪些订单和退款数据、在哪一层计算、接口返回哪些字段，以及怎样处理重复退款记录等实现问题。涉及其他服务时，先对齐字段含义、接口契约与兼容方式，再拆出各系统的修改任务，避免让模型自行补齐互相冲突的约定。

规范不必是一套固定文件名。一个小功能可以在需求单中写清上述内容；复杂功能再拆成需求、设计和任务清单。关键在于后续实现与验收确实使用这些约定，并能查到当前版本。

再把规则变成测试

准备一个独立的小数据集：同一租户、同一支付月中，两笔成功支付分别为 100 元和 200 元，一笔未支付的取消订单为 50 元，成功退款为 20 元。按上述规则，期望净销售额是 280 元。

这个结果来自业务定义与手工可复算数据，而不是把待测函数当前输出保存成标准答案。再逐步增加跨月边界、无订单、其他租户、重复事件和多笔退款等用例。对于时间、网络或模型调用等外部依赖，采用固定输入或测试替身控制单元测试；真实 SQL 的过滤、Join、金额类型与事务行为，再用隔离的测试数据库验证。

如果系统由模型生成 SQL，固定聚合组件的单元测试只是其中一层。还需要用业务问题及期望结果评测 SQL 生成与执行链路；一次确定性单测通过不能代表模型在所有表达上都能生成正确查询。

执行红—绿—重构，而不是一次生成全部代码

先为一个行为写测试，例如排除未支付订单。在功能尚未实现时运行，确认它因为缺少该行为而失败。若失败来自依赖未安装、测试数据损坏或无关配置，应先修好测试环境，才能判断这个测试是否有效。

随后实现足以满足当前行为的代码，让测试通过，再引入退款回冲、月份边界等下一组行为。实现过程中出现新边界，就补入用例清单。

当测试保持通过时再整理结构，例如提取金额处理、减少重复分支、明确查询接口。重构阶段重点保持行为不变，不能只做“红—绿”后不断堆补丁。AI 可以协助各步，但审查仍要关注它是否改错范围、弱化断言，或让测试与实现共享了同一个错误假设。

怎样把实践讲具体

介绍一项落地实践时，可以围绕一个需求说明：原先有哪些歧义、怎样确定规则、哪些测试先失败、实现改了什么、补了哪类回归，以及最后怎样验证交付。需求变更记录、代码差异和测试结果可以连成同一条线，比只列出使用过的工具更容易解释流程价值。

效果可以观察需求澄清后的返工、缺陷发现阶段、修复后的回归情况，以及完成一个可验收功能的总时间。比较时要考虑任务复杂度和评审投入；生成速度或测试覆盖率只是局部指标。没有量化对照时，也可以具体说明流程帮助发现了什么歧义或避免了哪次回归。

规范变化时，应先确认预期行为，再同步受影响的测试和代码；生产缺陷则先建立能复现问题的用例，修复后将其保留。规范由此参与日常迭代，而不是项目开始时生成一次就失去作用。

常见追问

先写测试，是否意味着测试能代替需求讨论？

测试只能验证已经表达出来的规则。若退款归属月份都没有确定，无论先写哪一份代码，都可能固化错误理解。SDD 与 TDD 分别补上需求对齐和运行反馈。

老项目没有测试，怎样开始？

先围绕本次修改路径识别现有行为，补必要的特征测试；对于明确要修复的缺陷，增加表达正确需求且当前会失败的用例。逐步提取难以测试的依赖，避免为一个局部修复先重构整个项目。现有行为测试与正确需求测试的目的需要区分，防止把历史缺陷当作约定永久保留。

所有 AI 功能都适合用 TDD 验证吗？

输入校验、金额计算、权限与状态转换等适合确定性测试。开放式回答、排序质量和随机生成还需要固定评测集、明确评分标准与多次运行评估。两类反馈可以共同用于交付，但不能相互替代。

参考资料