7.7
深览指数
产品人人都是产品经理·知序··AI 生成
AI写代码越来越快，为什么返工反而更多？产品经理要理解SDD与TDD
文章核心观点：AI Coding 加速了代码产出，但模糊需求中的歧义也以同样速度被复制到完整功能中，导致返工从“没做完”变为“看起来做完了但做错了”。作者提出，产品经理应理解 SDD（规格驱动开发）和 TDD（测试驱动开发）的组合价值：SDD 在开发前将隐性决定变为显性规则，TDD 用短反馈确保每一步未走偏。区别于纯技术讨论，文章聚焦于产品经理在 AI 交付时代的新角色转变——从“交出需求”变为“持续维护意图”，并给出轻量化的六步闭环操作方法。适合正在经历 AI 编码工具落地、面临返工问题的产品经理和研发管理者阅读。原文 ↗
核心观点
- ▍AI Coding 的核心工程变化不是代码成本归零，而是需求歧义的复制成本大幅下降——模糊需求会被快速扩散成页面、接口、测试用例等完整功能，形成“看起来做完了但做错了”的新型返工模式。
- ▍产品经理的核心职能应从“把需求交出去的人”转变为“持续维护产品意图的人”，而理解 SDD 与 TDD 的组合是应对这一转变的关键。
- 01一个典型返工案例：需求“支持手机号验证码登录”由 Agent 30 分钟完成，但第二天测试发现验证码时效、重发冷却、输错上限、多端并发等 6 个关键规则的默认值未被确认，导致三方重新对规则、改接口、改页面。
- 02Agent 在模糊需求下会自行补全默认值：例如“尽快”可能被实现为 60 秒或 5 分钟；“防止频繁发送”可能按手机号、设备或 IP 限制。不同默认值在正常路径下都能跑通，但边界场景下产品、研发、测试理解的可能是三个不同功能。
- 03SDD 的核心不是写更长文档，而是让“规格”成为共同事实，回答谁在什么状态下做什么、失败时如何处理、明确不做什么以及用什么判断完成。
- 04TDD（Red-Green-Refactor）是一种小步反馈机制，它在每步实现前先写一个会失败的测试，确认新行为确实发生。反馈范围越小，Agent 越容易定位问题，人也越容易审查。
- 05作者给出了一个从“手机号登录”需求到可交付规则的完整实例：跳过页面，先写结果（未登录用户完成验证）、非目标（不做注册补全、换绑等）、核心规则（5 分钟过期、新码失效旧码、短信未受理不启动倒计时等），再挑高风险行为（如 5 分钟边界）进入短反馈。
- 06SDD 与 TDD 的有效组合并非机械套用模板，作者建议压缩为 6 个轻量动作：写结果和非目标、找出最贵歧义、规则写成可观察场景、按场景拆实现、短反馈推进、发现写回规格。
- 07判断投入多少 SDD/TDD 力度的三个变量：歧义有多大、出错有多贵、影响范围有多广。三者都低则轻量，其中一项高则值得加深规则和检查。
反方 / 局限
- — 文章承认方法一旦进入团队容易变成新流程负担——需求必须写 20 页、所有场景开评审会、每个改动套完整模板，结果反而先增加表单。
- — 作者指出三个“假动作”：假规格（只写页面字段而无结果边界）、假测试（测试照实现写，只能证明代码和自己一致）、假闭环（规则改了但规格没更新）。
- — 文章隐含的前提是团队有能力且有意愿推行 SDD/TDD，但在快速迭代、以“快”为第一目标的创业团队中，前期的“显性化规则”投入可能被视为额外成本，与短期交付速度形成张力。
12 分钟 · 4 卡片 · 11 资料
读原文 →