13-SDD/TDD 并非万能：复杂需求下流程反成累赘

SDD/TDD 不是银弹：复杂需求里，流程也可能成为负担

准备开始写 SDD 教程之前，我觉得有些话必须先说在前面。

因为如果只讲 SDD 有多好、TDD 有多稳、AI 有多强，很容易给人一种错觉：

但我最近一段时间踩下来的真实感受是：不是这样。

SDD、TDD、AI 都是工具。

工具一定有适用边界。

当场景合适时，它们可以极大提升稳定性和协作效率；但当场景不合适时，它们也会制造额外负担，甚至比人工手写更慢。

这篇文章不是反对 SDD/TDD，也不是唱衰 AI。

相反，我后面还会继续写 SDD 相关教程。

但在开始教程前，我想先把一个前提讲清楚：

一、我为什么开始反思 SDD/TDD 的适用边界？

最开始接触 SDD、TDD 和 AI 编程时，很容易被一种叙事吸引：

• 先写 Spec，需求就清晰了；
• 先写测试，代码质量就稳了；
• 交给 AI，开发效率就上来了；
• Agent 自动拆任务，复杂项目就可控了。

这些说法都没错。

但它们隐含了一个前提：

可现实里，很多复杂需求并不是这样。

有些需求一开始就是模糊的。

有些业务规则要写着写着才知道不合理。

有些边界要接入真实数据后才暴露。

有些历史逻辑没有文档，只能靠看代码和调试慢慢摸。

这种情况下，如果一上来就要求自己写完整 Spec、完整测试、完整任务拆解，很可能会出现一个反效果：

Spec 改一遍，实现改一遍。

测试改一遍，任务清单改一遍。

AI 再根据旧上下文生成一版不匹配的代码。

最后你会发现，流程很完整，但人很累，效率也没有想象中高。

二、SDD 的价值不是“写很多文档”

我现在对 SDD 的理解发生了变化。

以前容易把 SDD 理解成：

现在我更愿意把它理解成：

这两个理解差别很大。

如果把 SDD 当成“文档优先”，就很容易写出大量自然语言描述。

这些文档看起来完整，但不一定真的降低风险。

真正有价值的 Spec，应该锁住这些东西：

• 不能错的业务规则；
• 不能随便改的状态流转；
• 对外暴露的 API 契约；
• 金额、库存、权限、安全等高风险规则；
• 未来接手的人最容易误解的边界。

也就是说，SDD 本质上不是为了让流程显得正式，而是为了降低关键路径上的错误成本。

一句话：

三、什么时候适合用 SDD？

我现在会优先在这些场景使用 SDD，而且通常是轻量 SDD，不是一上来写长篇大论。

1. 规则确定，而且不能错

比如：

• 支付；
• 结算；
• 库存；
• 权限；
• 状态机；
• 审批流；
• 合规规则。

这些场景一旦错了，代价很高。

这时，提前写清楚规则是值得的。

2. 对外契约稳定

比如 API 输入输出、字段语义、错误码、事件格式。

这些东西一旦被别人依赖，就不能随便改。

提前用 Spec 固化下来，可以减少后续扯皮和返工。

3. 多人协作，且生命周期较长

如果一个模块未来会有多人维护，或者会存在几个月甚至更久，那么 Spec 的价值会变高。

因为它不仅服务当前开发，还服务未来交接。

4. 规则容易被误解

有些代码本身看不出业务意图。

比如：

• 为什么这里不能 early return；
• 为什么这个状态不能回退；
• 为什么这个异常不能吞；
• 为什么这个字段为空时不能用默认值。

这类地方非常适合写点状 Spec。

不需要长，只要把“为什么不能乱改”讲清楚。

四、什么时候不适合重型 SDD？

不是所有需求都值得上完整 SDD。

下面这些场景，我现在会非常克制。

1. 探索期需求

如果需求本身还在试错，比如新业务方向、交互方案、算法策略、运营活动，重型 Spec 很容易变成负担。

因为今天写下来的设计，明天可能就被推翻。

这时候更适合：

• 快速拆小；
• 快速验证；
• 跑通最小闭环；
• 稳定后再回填关键规则。

2. 单人短周期任务

如果是你一个人做，而且生命周期很短，比如一次性脚本、临时工具、小范围修复，完整 SDD 往往不划算。

你写 Spec 的时间，可能已经够把功能写完并验证了。

3. UI 和体验型需求

很多 UI 需求不是靠 Spec 推出来的，而是靠看、试、调。

比如间距、动画、交互反馈、页面节奏。

这类需求可以有设计规范和验收标准，但不一定适合写很重的 SDD。

4. 高频变化的业务

如果需求每天都在变，重型 Spec 会迅速过期。

过期的文档比没有文档更危险。

因为它会给人一种“这里已经被定义过”的错觉。

五、TDD 也一样，不是所有场景都要先写测试

TDD 的价值也很大。

它能逼你先思考输入输出，能让重构更安全，也能把关键规则变成可执行文档。

但它同样不是银弹。

如果需求还没稳定，你一开始写太多测试，后面会频繁改测试。

这时候测试不再是安全网，而会变成变化阻力。

我现在更倾向于这样使用 TDD：

适合先写测试的场景

• 纯函数；
• 规则引擎；
• 金额计算；
• 状态流转；
• 权限判断；
• bug 复现；
• 已经稳定的核心逻辑。

不必强行先写测试的场景

• UI 探索；
• 原型验证；
• 需求快速试错；
• 一次性迁移脚本；
• 临时运营逻辑。

当然，不先写测试不代表不测试。

而是说：

高风险逻辑必须测。

低风险、高变化的逻辑，可以先验证闭环，稳定后再补测试。

六、我更推荐的方式：核心硬化，外围敏捷

现在我更认可一种混合策略：

也就是说，不要把所有地方都按同一种强度管理。

核心路径：用 SDD/TDD 锁住

比如：

• 业务不变量；
• 状态机；
• 金额计算；
• 权限规则；
• 对外契约；
• 数据一致性。

这些地方可以更严谨：

• 写轻量 Spec；
• 写类型约束；
• 写 Schema；
• 写测试；
• 让 AI 按规则生成代码；
• 再人工 review。

非核心路径：快速拆解，动态推进

比如：

• 页面展示；
• 胶水代码；
• 临时流程；
• 简单数据转换；
• 原型验证。

这些地方不必一开始就写重型 Spec。

可以先拆成小任务，人工判断方向，AI 辅助铺代码。

等稳定后，再把真正重要的规则沉淀下来。

七、一个更实用的判断清单

以后遇到一个需求，我会先问自己几个问题。

1. 这件事错了，代价高吗？

如果会造成资损、数据不可逆、安全问题、合规问题，就值得上 SDD/TDD。

如果只是 UI 展示不对、文案有误、可快速回滚，就不一定要重流程。

2. 规则现在稳定吗？

如果规则已经明确，适合先写 Spec 和测试。

如果规则还在探索，先别急着把它文档化。

3. 未来会被多人维护吗？

如果会，写清楚很重要。

如果只是一次性任务，文档成本要谨慎。

4. 这个规则能不能变成可执行约束？

比起写一大段自然语言，我更推荐优先用：

• TypeScript 类型；
• JSON Schema；
• OpenAPI；
• 单元测试；
• 状态机表；
• 数据库约束。

因为这些东西不只是给人看，也能被工具和 AI 消费。

5. 我现在是在解决问题，还是在维护流程？

这是最重要的问题。

如果你发现自己花大量时间在同步 Spec、同步任务、同步测试，而业务没有推进，就要停下来重新评估。

流程应该帮你前进，而不是拖着你走。

八、AI + SDD/TDD 的正确关系

AI、SDD、TDD 不是互相替代的关系。

更合理的组合是：

• SDD 用来钉住关键规则；
• TDD 用来验证高风险逻辑；
• AI 用来执行、补齐、批量同步；
• 人负责判断边界和取舍。

如果顺序反了，就容易出问题。

比如：

这看起来很自动化，但风险很高。

因为一开始的 Spec 可能就是错的。

更稳的方式是：

AI 可以提高产出速度，但不能替你判断什么是正确方向。

九、我给自己的实践原则

后面继续写 SDD 教程时，我会遵循这些原则。

1. 不追求全量 SDD

只在关键规则、关键契约、关键风险点上使用。

2. 不把 Spec 写成作文

能用类型、Schema、测试表达的，就不要只写自然语言。

3. 不在探索期过早重流程

先跑通，后沉淀。

4. 不为了 TDD 而 TDD

高风险逻辑优先测试，低风险高变化逻辑先保证反馈速度。

5. 不让 AI 替我做最终判断

AI 可以建议，可以生成，可以 review，但最终边界由人负责。

十、结语：方法论的价值，在于用对地方

这篇文章作为 SDD 教程的前言，是想先把一个底层观点说清楚：

不要因为外面都在说 AI 多厉害，就把所有任务都交给 AI。

不要因为 SDD 看起来更工程化，就给所有需求都套完整流程。

不要因为 TDD 代表质量，就在需求还没稳定时写一堆很快过期的测试。

真正成熟的做法，是承认每种方法都有成本，然后判断这份成本是否值得。

我的阶段性公式是：

后续的 SDD 教程，我也会基于这个前提来写。

不是教大家把流程做重，而是教大家：

• 哪些地方必须写清楚；
• 哪些地方可以轻一点；
• 哪些地方该让 AI 帮忙；
• 哪些地方人必须自己判断。

因为工程方法的目标，从来不是让流程看起来完整。

而是让我们更稳定、更清醒、更高效地把事情做成。