AI Coding正在把开发速度推到一个新量级，但很多团队很快发现：代码写得越快，返工不一定越少。交付中的核心矛盾已经变了，需求里的模糊判断，正在被更快做成一个看起来可以上线的产品。SDD与TDD的价值，就藏在这个变化里。

图1：SDD与TDD双驱动闭环，制图：知序

来看一个团队里很常见的功能评审。

需求只有一句话：“支持手机号验证码登录。”研发把需求交给Agent，不到30分钟，页面、接口、倒计时和错误提示都出来了。现场演示很顺，大家甚至开始讨论能不能当天上线。

第二天，测试只问了几个问题：验证码几分钟过期？新验证码发出后旧码还能不能用？连续输错多少次锁定？两台设备同时请求，以哪一个为准？短信服务没有受理，倒计时还要不要开始？

会议突然安静了。

这些问题，产品没写，研发没问，Agent却不能停在那里等答案。它只能沿着训练数据和当前上下文，替团队补上一套“最像答案的答案”。于是，一个30分钟完成的功能，在第二天变成了三方重新对规则、改接口、改页面、补测试。

问题并不在Agent能力不够。恰恰相反，是它执行得太快了。

一、AI写得越快，模糊需求越危险

过去，一份模糊需求进入开发，问题会在原型、接口讨论和联调中慢慢暴露。过程很低效，但也给了团队很多次停下来追问的机会。

Agent把这段缓冲压缩掉了。它可以在几分钟内生成页面，在几十分钟内串起接口，在一天内完成过去一周的代码量。需求里每一个没有被确认的词，也会跟着这条流水线一起加速。

“尽快”可能被实现成60秒，也可能是5分钟；“验证码失效”可能只是在前端提示，也可能是服务端真正拒绝；“防止频繁发送”可能按手机号限制，也可能按设备或IP限制。只看正常路径，它们都能跑通。到了边界场景，产品、研发和测试才发现，三个人理解的根本不是同一个功能。

所以，AI Coding带来的第一个工程变化，不是代码成本归零，而是歧义的复制成本大幅下降。以前模糊需求会产生一段模糊代码，现在它可以迅速扩散成页面、接口、数据结构、测试用例和埋点。

图2：AI如何放大需求歧义，制图：知序

返工也因此变了。过去常见的是“这个功能还没做完”，现在更常见的是“它看起来做完了，但做的不是我们真正想要的”。前一种问题容易看见，后一种问题最容易骗过评审。

当实现速度不再稀缺，团队最贵的能力就从“把东西做出来”，转向“更早确认究竟要做什么，并且持续证明没有做偏”。这正是SDD与TDD重新受到关注的原因。

二、SDD要解决的，不是文档长度

SDD通常被译为规格驱动开发。不同团队对它的流程定义并不完全相同，但放到AI协作中，可以先抓住一个实用判断：让经过确认的规格成为开发过程里的共同事实，不再把聊天记录交给Agent自由发挥。

这里的“规格”不追求更长的PRD，更不只是给原来的需求文档换个英文名字。它需要回答那些会改变实现结果的问题：谁在什么状态下做什么，系统应该出现什么变化，失败时如何处理，这次明确不做什么，以及用什么现象判断完成。

还是手机号登录。如果规格只写“输入手机号，获取验证码，验证成功后登录”，Agent当然能写。但它会被迫替团队决定验证码时效、重发冷却、输错上限、旧码失效、多端覆盖、风控频率和异常提示。每一个默认值都像一个小问题，叠在一起就是整个账号系统的业务规则。

SDD的作用，是把这些隐形决定提前摆到桌面上。产品负责确认用户结果和业务边界，研发补充技术约束，测试指出可验证性，Agent再依据当前版本的规格拆计划、写代码、补检查。实现过程中发现新限制，也要回写规格，避免它只留在某一轮对话里。

说白了，SDD不要求大家比拼文档长度，它要减少的是“每个人都以为对方知道”的时刻。

三、TDD要解决的，也不只是覆盖率

很多产品经理听到TDD，会立刻把它归到研发内部：先写测试，再写代码，和产品有什么关系？

关系比想象中更直接。

TDD最经典的节奏是Red、Green、Refactor：先写一个会失败的测试，确认当前行为还不存在；再写刚好让它通过的最小实现；最后在测试保护下整理代码。它首先是一种小步反馈机制，测试资产是这个过程留下的结果。

它和“功能做完以后补一批测试”最大的差别就在反馈节奏。实现每走一步，都要面对一个具体问题：我现在新增的这条行为，真的发生了吗？

比如“验证码超过5分钟后失效”。如果直接让Agent完成整套登录，它可能一次改动十几个文件，最后再跑一遍全量测试。出错时，团队很难知道是哪一个判断偏了。用TDD推进，可以先写过期前有效、恰好到边界失效、过期后失效这几个可观察行为，再补最小判断。反馈范围越小，Agent越容易定位问题，人也越容易审查。

这也是产品经理应该理解TDD的原因：一条好的验收标准，往往就是一条好的行为测试的上游。产品写不清“发生什么才算对”，研发也很难写出真正保护业务的测试。

四、两个D放在一起，才是一条完整交付链

SDD和TDD经常被放在一起讨论，但它们分别处理两个层面。

SDD关心方向：团队确认的意图是什么，边界在哪里，哪些决定已经生效。TDD关心步长：当前要新增的下一条行为是什么，怎样用一次短反馈确认它没有走偏。

一个防止“做错产品”，一个减少“把正确产品做错”。

图3：SDD与TDD双环协作，制图：知序

只做SDD，可能得到一份写得很完整、实现时却没人持续核对的规格；只做TDD，也可能得到一套全部通过、却忠实验证了错误需求的测试。真正有效的组合，是外层用规格校准意图，内层用测试缩短实现反馈，最后再用验收结果更新规格。

这里还有一个很容易踩的坑：不要把所有验收场景都机械地写成单元测试。页面反馈、服务契约、跨系统状态和业务指标，需要不同层级的检查。TDD适合推动一个可被快速验证的小行为，SDD则负责保证这些行为仍然指向同一个用户结果。

五、把一句登录需求，变成可以交付的规则

现在回到那句“支持手机号验证码登录”。如果按照SDD与TDD的组合方式推进，产品经理第一步先跳过页面，把一句功能描述改写成一个结果：未登录用户能够用本人可接收短信的手机号完成验证；失败时知道原因和下一步；系统能够限制明显的高频请求，并保留必要的排查信息。

紧接着，要写非目标。本次不做注册资料补全、不做换绑手机号、不做密码登录、不做营销短信授权，也不顺手重构整个账号体系。对Agent来说，非目标就是一道围栏，防止它根据上下文主动扩大范围。

再往下，团队需要确认真正影响实现的规则。验证码从服务端受理短信请求开始计时，5分钟后失效；新码发出后旧码失效；有效验证码只能成功使用一次；连续输错5次后当前验证码失效；短信没有受理时不启动倒计时；受理后60秒内不能重复发送；多台设备同时申请时，同一手机号只有最新验证码有效。

这时，需求从一张页面，变成了一组可以讨论、可以修改的产品决定。

接下来挑一条高风险行为进入短反馈。比如“恰好到达5分钟边界时按过期处理”。研发先写一个当前会失败的检查，再补服务端时间判断，让检查通过，然后整理时间和状态代码。页面倒计时只负责提示，不参与决定验证码是否有效。这样即使用户修改设备时间、把页面切到后台，服务端规则也不会改变。

最后，验收还要超过一段顺利演示。产品需要看到：接口没有创建登录态，页面明确提示验证码已过期，重新获取入口仍然可用，事件记录能说明拒绝原因。成功、失败和临界点都留下可复查的结果，才算真正完成。

图4：登录需求如何变成验收证据，制图：知序

从一句话到规则，再到测试和验收，这个过程看似比“直接让AI生成”慢了一步，实际是在最便宜的阶段消灭返工。改一句规格只要几分钟，等页面、接口和数据结构全部完成后再改，成本就完全不同了。

六、团队真正需要的，是一条轻量闭环

方法一旦进入团队，很容易被做成新流程：需求必须写20页，所有场景都要开评审会，每个改动都要套完整模板。结果还没减少歧义，先增加了一批表单。

更实用的做法，是把SDD与TDD压缩成6个动作。

第1步，写结果和非目标。先回答用户或业务状态要发生什么变化，以及这次明确不处理什么。

第2步，找出最贵的歧义。优先确认会改变数据、权限、资金、风控和用户状态的规则，不追求一次写完所有细节。

第3步，把规则写成可观察场景。给定什么状态，用户做了什么，系统应该返回什么，失败后还能做什么。

第4步，按场景拆实现。Agent每次只处理一个足够小的行为，避免一次生成整套功能后再集中排错。

第5步，用短反馈推进。适合自动化的关键行为先失败、再通过、再整理；不适合单元测试的场景，用契约、集成或页面验收保护。

第6步，把发现写回规格。实现中出现的新约束、评审后的规则变化和最终验收结果，都回到同一份当前版本里。

这6步可以反复往返。测试暴露规则冲突，就回到规格；实现发现第三方限制，就更新边界；验收结果不对，就判断偏差来自需求、检查还是代码。闭环的价值，正是在于团队随时知道当前依据是什么。

七、别把方法做成新一轮流程负担

SDD与TDD有效，不代表每一个需求都要用同样的力度。

改一个已经确认的错别字，一条变更说明加一次页面检查就够了。普通功能需要结果、非目标、核心规则和主要异常场景。涉及支付、权限、隐私、风控或跨系统状态时，再增加更完整的规格评审、服务契约、回滚条件和验收记录。

判断投入多少，可以看三个变量：歧义有多大、出错有多贵、影响范围有多广。三项都低，就保持轻量；其中一项很高，就值得把规则和检查做深。

团队还要警惕三个“看起来很规范”的假动作。

第一个是假规格。文档写了很多页面、字段和技术名词，却没有结果、边界和例外。它只是把原型说明写得更长，并没有减少关键决定。

第二个是假测试。测试完全照着当前实现写，代码怎么做，它就怎么断言。这样的测试通过，只能证明代码和自己一致，不能证明产品行为正确。

第三个是假闭环。规则改了，群里通知一下；代码和测试改了，规格仍停在旧版本。几轮之后，团队又回到“到底听谁的”，Agent也会继续读取过期上下文。

判断方法有没有生效，别数留下了多少材料。去看错误是否更早出现、影响范围是否更小、原因是否更容易被看见。

八、产品经理最该改的，是这5个动作

1.少写功能名，多写状态变化。“增加验证码登录”只是方案，“未登录用户完成身份验证，并在失败后知道下一步”才是结果。结果写清楚，页面和接口才有共同方向。

2.把边界情况提前到需求评审。过期、重复、失败、并发、限流、多端和回退，都要在测试开始前成为正式需求。它们往往才是一个功能真正的业务规则，也是Agent最容易自行补默认值的地方。

3.要求Agent先提问，再生成。把“直接完成这个需求”换成“先列出会影响实现的未决问题、默认假设和非目标”。这一步经常比换一个更强模型更有用。

4.评审可观察结果，不只评审文档。页面提示、接口状态、数据变化、第三方调用和关键记录，至少要能串起一条可复查的链。一次顺利演示只能证明正常路径走通，不能证明边界被保护。

5.让规格跟着产品一起活。需求变化时，同时标出受影响的规则、检查和任务；实现发现新限制时，也要回写规格。产品经理的维护范围已经超过开发前的一份输入，它应该覆盖团队当前有效的产品意图。

这5个动作背后，其实是同一件事：产品经理要从“把需求交出去的人”，变成“持续维护意图的人”。

九、写在最后

AI Coding没有消灭产品经理和研发之间的沟通成本，它只是把成本换了一个出现方式。

以前，团队担心代码写不完；现在，更需要担心一个没有被确认的假设，会被Agent多快写成完整功能。页面越像真的，接口越能跑通，越容易让人误以为产品已经完成。

SDD与TDD值得产品经理理解，和又流行了两个缩写无关。它们分别抓住了AI交付里最关键的两个问题：我们是否在做正确的事，以及每一步是否真的做对了。

规格让意图有了共同依据，测试让实现有了短反馈，验收让结果不再靠感觉。三者连起来，AI的速度才会真正变成交付速度，避免一路滑向返工速度。

下一次再把需求交给Agent之前，不妨先停一分钟：它现在缺的是代码，还是一个团队尚未给出的决定？

参考资料

• GitHub Spec Kit官方文档
• GitHub关于规格驱动开发的说明
• Kiro Feature Specs文档
• Martin Fowler：Test Driven Development