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 帮忙；
• 哪些地方人必须自己判断。

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

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