Spec-First 与敏捷开发：冲突还是互补？

几乎每次我向团队介绍 spec-first 时，都会听到这个问题：「这不就是套了连帽衫的瀑布模型吗？」简短答案是否定的——spec-first 和敏捷根本不在系统的同一层。敏捷决定的是接下来要做什么，spec-first 决定的是「完成」意味着什么。把两者混为一谈，就是让两者同时失败的原因。

发布于 2026-02-25 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Spec Coding 编辑团队 · 审校：编辑政策

层次混淆

敏捷是一个排期和反馈系统。它说：小步交付、收集用户反馈、调整计划。它关心的是接下来做哪个功能、何时做。

spec-first 关心的是：一旦决定要做某件事，你怎么处理这件具体的工作。它说：在你开始写代码之前，先写下系统需要做什么，以及你怎么知道它做对了。

这两者是正交的。你可以完全敏捷同时照样写规格，也可以不写规格却还是瀑布。两者工作在不同的层次。

人们说「敏捷」时实际指的是什么

大多数公司里的「敏捷」并不是 2001 年那份宣言。它指的是：两周一个 sprint、站会、Jira 工单、大小刚好塞进一个 sprint 的 PR，以及对长文档的反感。跟 spec-first 产生冲突的，正是这份对文档的反感。

但这种反感通常针对的是错误的文档：40 页的 BRD、写成散文的 6 个月路线图、批准当天就开始过时的架构图。那些都不是规格。一份好的功能规格只有 2 到 4 页，几个小时内写完，要么准确要么作废。它更接近一份 PR 描述，而不是 BRD。

真正的冲突出现在哪里

冲突不是意识形态的，是实操层面的。在敏捷味道浓的团队里，有三件事让 spec-first 显得沉重：

• Sprint 压力。「这个 sprint 我们规划了 10 个点——花 3 小时写规格塞不进去。」公平。但规格本身就是工作的一部分，不是额外加在上面的开销。把写规格作为工单的一部分一起估时。
• 「边做边想」的文化。敏捷团队常常以适应能力自豪。规格让人觉得是过早承诺。换个角度看：规格不是承诺要交付什么，而是承诺在实现撞到边界情况之前已经想过它。
• 评审瓶颈。每多一个评审步骤都像在制造摩擦。但规格评审发生在代码评审之前，在同一份文档里异步进行。它不是新增一轮评审——而是把一轮评审前移到成本更低的时候。

spec-first 如何融入敏捷仪式

我在标准敏捷交付的团队里这么跑过：

• Backlog grooming：复杂度超过某个阈值的工单会被打上「需要规格」的标签。
• Sprint planning：下个 sprint 要用到的规格在规划会议之前就异步写好并评审完。规划会议讨论的是产能，而不是对工作内容的理解。
• Sprint 执行：需要规格的工单先写规格（1-3 小时），然后做规格评审（1 天异步），再开始实现。从领票到完成的总时间通常和以前一样甚至更快，因为实现中途的澄清变少了。
• Retro：回顾上个 sprint 的事故、返工和实现中途的提问。有没有哪一次最后追溯到规格里缺失的内容？用这个结果去校准「需要规格」的阈值。

这里面没有任何东西跟两周 sprint 相冲突。只是在复杂工作上多插入了一个产物而已。

两者各自擅长什么

敏捷真正的强项——响应用户反馈、不对路线图过度承诺、增量交付——都还在。spec-first 不碰这些。它只在单个工单内部起作用，不在路线图层面。

spec-first 真正的强项——提前暴露边界情况、对齐评审方预期、让验收标准可测试——也不需要你放弃敏捷。它只要求你为每个复杂工单多一份产物。

两者确实会冲突的场景

有两种。值得诚实面对。

Spike 和原型

如果工单是「探索一下我们能不能做 X」，提前写规格没有意义。你还不知道 X 是什么。Spike 应该跳过规格，然后把规格作为它的产出——一份用来指导真正工单的规格。

真正的敏捷实验

如果你在跑一个为期一周的 A/B 测试，打算把输掉那一方直接丢掉，那就不需要给每个变体都写规格。你需要的是这个实验本身的验收标准。变体是一次性的，测试才是重点。

「但这是瀑布」的反对意见

有人会说：「先写规格就是回到瀑布。」不是。瀑布是指把所有功能的所有规格一次性全写完，然后设计，然后构建，然后测试——一个阶段完成才能开始下一个。

spec-first 是逐功能进行的。你只为你马上要做的那件事写规格。下一个功能还没有规格，因为你还不知道它是什么。这仍然是敏捷——你只是把每个工单当成一段短瀑布，而不是一场随心所欲。

敏捷迭代内部跑若干短瀑布，是我见过的每个成熟敏捷团队实际运作的方式。spec-first 只是把「短瀑布」这一部分显式化而已。

诚实的答案

spec-first 在敏捷流程内部运转得最好，而不是在它之外。敏捷给你反馈回路和排期；spec-first 给你每个工作单元的内部纪律。只采用其中一个的团队有两种失败模式：纯敏捷团队交付快但返工不断，纯规格团队交付慢因为把本来不需要规格的事情也规格化了。

甜点区是：路线图层面用敏捷，功能层面用 spec-first。如果你的团队已经把敏捷跑得不错，想要减少返工，那就在复杂工作上加上 spec-first，观察 4 到 6 周看会发生什么。如果没帮助，就放弃。这也是敏捷。

评审时看什么

这篇文章适合用在敏捷团队引入 Spec-First 时。别从“原则”聊起，直接拿一条真实改动来对照，看看规格里还缺什么。

• 定义哪些 ticket 需要规格。
• 把规格评审放在 sprint planning 前。
• 异步评论解决行为问题，不在会议里现场补课。
• 复盘返工时回查缺失的规格决策。

Spec-First 不该变成第二套审批。它只是让敏捷里的复杂工作少一点临场猜测。

例子：文案调整、样式微调可以跳过规格；账单状态、权限模型、数据迁移不能跳过。把这个阈值写进团队约定，sprint planning 才不会每周重新争论一次。评审时只问两件事：这张 ticket 是否超过阈值；如果超过，规格里的决策是否已经足够让工程和 QA 独立推进。

落地例子

可以把团队工单分成两条线：文案、样式、小的配置调整走普通敏捷流程，只保留简短验收标准；涉及契约、计费、权限、迁移、跨团队依赖的改动，必须在 sprint 开始前完成规格评审。这样低风险任务不会被流程拖慢，高风险任务也不会等到 PR 阶段才讨论产品行为。

评审记录里最好保留一个简单字段：本工单为什么需要或不需要规格。几周后复盘返工时，这个字段会很有用。它能帮团队分辨是阈值太低、阈值太高，还是某类风险一直被低估。

如果团队担心流程变慢，可以先只选一类高返工工单试 4 周，例如权限、计费或跨服务契约。不要一开始要求所有需求都写完整规格。小范围试点能看清楚 Spec-First 到底是在减少返工，还是只是多了一层文档。

试点结束时不要只问大家感觉如何，要看返工票、澄清评论和延期原因有没有减少。

Spec-First 和敏捷的交汇点在 sprint 前半段

它们不冲突，但位置要摆对。规格不是 sprint 之前写三个月的大文档，而是在开始实现前把这次迭代的行为边界说清楚。写完就评，评完就做，变了就改 spec。

Sprint agreement:
- day 1: PM and tech lead draft one-page spec
- day 2: async review by backend, frontend, QA
- day 3: implementation starts after open questions are closed
- during sprint: scope changes update spec before code
- review: PR links to spec section and test evidence
- retro: unclear criteria become template changes

边界：探索性 spike 不一定需要完整 spec。目标是学习时，用问题清单；目标是交付用户行为时，用 spec。

变更进入 sprint 后仍然能改 spec

敏捷不是拒绝修改，Spec-First 也不是冻结需求。区别是：需求变了先改 spec，再改代码。这样测试、API fixture、回滚计划和验收标准一起移动，不会只改实现而忘掉证据。

在迭代里使用 spec 时，最重要的是轻量更新。需求变化后，更新目标、非目标、API 字段、测试证据或回滚 owner，然后继续开发。不要把 spec 当审批墙，它应该是当前事实的记录。

团队还可以把 spec review 放进 Definition of Ready，把测试证据放进 Definition of Done。前者保护开始实现的质量，后者保护合并前的质量。两条都很轻，但能让敏捷节奏和规格纪律咬合起来。

实际操作里，每张 story 只需要几个字段：spec link、acceptance owner、test evidence、API impact、rollback note、current status。字段少，团队才会填；字段够具体，reviewer 才能判断能不能开工、能不能合并。

看板上也可以显示 API 字段、测试状态、回滚 owner 和发布状态。

可复制产物：交付评审包

当文章要进入计划、设计评审或发布准备时使用。它让责任人、证据和停止条件保持可见。

交付评审包：Spec-First 与敏捷开发：冲突还是互补？

本次要做的决策：
- 把责任人、门禁、证据和止损条件写到交付流程里。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

流程边界：实现前必须写明责任人、决策记录、证据和止损阈值。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。