本文内容
AI 编程需求要写多详细？瀑布开发会回来吗？
计划获批后，几个月过去，用户还没用上成果，优先级却变了。如果 AI 能缩短这段实现时间，我们就有理由重新评估前期规划的价值。
AI 编程需求要写多详细，应先看做错后要付出多少代价。实现越快，一份合理的计划就越有机会在假设过时前发挥作用。我们的建议是：重要改动先明确目标、约束和验收标准，再交给智能体实现；也保留根据证据修改假设的空间。
前期规划是在实现之前把决定做清楚；瀑布开发则把交付组织成依次推进的阶段。采用前者，并不要求把所有需求冻结到最终发布。
研究截至：2026年11月10日。本文依据一手研究和假设算例提出建议。Wavect 没有开展瀑布与敏捷的对照实验，下文的 100× 编码速度也只是模型输入，不是行业实测结果。
AI 为什么让前期规划更值得投入？
当实现足够快，尚未做出的决定就可能成为交付的主要障碍。此时，前期规划更有价值：智能体拿到明确需求就能动手；如果没人定义什么才算正确，生成得越快，也可能留下越多需要否决或重写的工作。
例如，两个智能体可以并行开发客户数据导出的界面和 API。事先约定租户边界、数据结构和错误处理约定，它们才能做出相互配合的实现。只说“做一个导出功能”，就把这些选择留给了各自的猜测。
在初始不确定性相同的前提下，本周就能让用户试用的改动，比一年后才能完成的改动，更少受到期间环境变化的影响。缩短实现时间可以提高规划的回报，却不能让预测永远正确。
我们的AI、规格与软件工厂回归讨论了工程工作的整体变化。这里聚焦下一次实现之前，究竟应该先决定多少事情。
瀑布开发的问题只是代码写得慢吗？
实现缓慢会让计划过时，太晚发现问题同样会。即使代码瞬间完成，也可能满足了错误的需求。规划必须包含检验假设的方法，让团队在投入过多之前发现偏差，并在证据变化时修订决定。
Royce 在 1970 年的论文中已经警告：如果到后期测试才发现系统约束，就可能需要大幅返工。他也描述了开发阶段之间的反馈。用这篇大型系统开发原始论文为僵化、一次通过的流程辩护，并不合适。
Agile Manifesto（敏捷宣言）同样承认计划有价值，只是更重视响应变化。有了反面证据还继续照旧执行，即使实现很快，也可能白费力气。
AI 写代码已经达到原来的 100 倍速度了吗？
本文查阅的研究尚未证明，AI 能普遍让软件实现速度达到原来的 100 倍。结果取决于任务、开发者、工具和衡量指标。完成一道编程任务的用时、代码活动、发布数量和用户价值，分别回答不同的问题。
| 研究 | 报告结果 | 适用边界 |
|---|---|---|
| 2022 年开展的 Copilot 对照实验 | 招募 95 名程序员；完成任务的参与者中，使用 Copilot 者平均少用时 55.8%。 | 任务是编写一个 JavaScript HTTP 服务器，未测量完整产品交付。 |
| METR 的 2025 年早期实验 | 16 名经验丰富的维护者处理 246 个任务；允许使用 AI 时，完成时间增加 19%。 | 对应特定代码库场景和当时的工具，不能视为当前通用的减速结论。 |
| Writing Code vs. Shipping Code，2026 年 9 月修订版 | 这项观察性研究覆盖超过 50 万名 GitHub 开发者，估计代码活动的增幅远大于发布数量的增幅。 | 产出数量不等于耗时缩短，也不等于用户价值。 |
METR 在2026 年 2 月的后续说明中指出，样本选择和多个智能体并行时的计时问题，使其新一轮生产率估计不可靠。早期的减速结果不应成为对今天所有工具的定论。
我们仍可以认真检验 100× 这个假设：某项实现真能这么快，整个项目又能快多少？
编码速度变为 100 倍，整个项目会怎样？
在一个各阶段依次进行的假设项目中，100× 编码速度会让规划占比上升，但整体交付速度远达不到 100×。结果取决于实现原先占多少时间，以及其他工作是否也加快。这个算式不能替你决定最佳规划预算。
假设范围与验收标准不变，规划用 10 天，实现用 80 天，验证与发布用 10 天。只有实现加速，各阶段不重叠，返工和排队等待也不变。这些天数表示假设的阶段历时，不是 Wavect 项目数据或行业平均值。
总天数 = 10 + 80 / 实现速度倍数 + 10
| 实现速度倍数 | 实现天数 | 总天数 | 整体速度倍数 | 规划占比 |
|---|---|---|---|---|
| 1× | 80 | 100 | 1× | 10% |
| 10× | 8 | 28 | 3.57× | 35.7% |
| 100× | 0.8 | 20.8 | 4.81× | 48.1% |
| 瞬间完成实现的极限情形 | 0 | 20 | 5× | 50% |
100× 情形下，规划占了将近一半，但没人多花一天做规划。占比上升，是因为实现时间缩短。这并不能证明，把规划天数翻倍就会更好。
分析自己的交付流程时，要找出决定完成时间的关键路径，不能把重叠的时长相加。如果 AI 也改变了测试、评审或返工，应分别估计。最终要看多久能交付一项通过验收、真正可用的改动。
AI 编程需求要写多详细？
先写清那些一旦做错，就难以低成本撤回的决定：用户目标、责任归属、数据边界、接口、失败处理和验收标准。细节应足以约束下一次实现。对于改起来无关痛痒的局部选择，不必因为 AI 能写长文档就提前规定。
重要改动应请负责人回答：
- 目标与范围：解决谁的问题，如何观察效果，哪些相邻需求暂不包含。
- 约束：系统能访问哪些数据、执行哪些操作，必须保留什么，已有何种兼容承诺。
- 接口：各组件接收和返回什么，失败时记录什么。
- 验收与恢复：凭什么证据发布，由谁判断，发布失败时如何停止或恢复。
Epoch AI 与 METR 的2026 年 4 月 MirrorCode 结果展示了在可执行的参考实现和详细测试辅助下，智能体能够自主完成相当规模的重新实现。这支持可检验规格的用途，但这个范围有限的基准不能证明瀑布更优，也没有测出相对人类的速度倍数。
“妥善处理失败”很难验收。“服务商响应不确定时，保留操作标识，先核对状态，再决定是否重试”，才是可以检验的行为。
不同改动应该投入多少前期规划？
规划深度取决于不确定性和撤回决定的代价。需求明确、做错后果重的改动，值得详细准备；行为尚不确定、又容易修改的改动，适合尽早实验。如果两项都高，应先设计安全的求证方式，避免直接让整个系统承担后果。
| 需求不确定性 | 撤回代价 | 下一步 | 例子 |
|---|---|---|---|
| 低 | 低 | 写清简短的验收约定，然后实现。 | 已有明确示例、不改变存储数据的展示调整。 |
| 低 | 高 | 执行前明确依赖、失败情形和恢复方式。 | 必须保留现有记录与集成的数据迁移。 |
| 高 | 低 | 提出待验证的问题，用可丢弃的版本实验。 | 让有代表性的用户试用两种引导流程。 |
| 高 | 高 | 通过模拟或隔离试验降低不确定性，再正式投入。 | 新分配规则先用合成数据评估，再考虑作用于真实账户。 |
如果智能体很快就能做出安全的原型，再花一周争论臆测中的界面，可能不划算。实现变快，既能提高明确已知约束的回报，也能降低提前猜测用户偏好的必要性，因为偏好可以直接观察。
撤回代价包括受影响的人、丢失的数据、已经做出的承诺、运营中断和工程投入。生成代码便宜，不代表所有后果都便宜。安全硬约束也不会因为收益表显示划算就失效。
规划做到什么程度就可以开始实现？
下一小步实现已有一致的目标、明确约束、负责人、可观察的验收标准和恢复办法，就可以考虑动手。把剩余未知及其验证方法记下来。只有当继续澄清一个决定预计能避免的损失，值得付出相应时间时，才继续增加规划。
看一个虚构示例：客服人员需要通过支付服务商发起全额退款。假设退款资格和审批规则已经确定。如果规则仍有冲突，先参考规格编写前如何解决业务规则冲突。
| 实现前要确定什么 | 可检验的要求 |
|---|---|
| 权限 | 只有获授权的客服角色，才能为自己所属租户发起已批准的退款。 |
| 操作身份 | 为这笔获批退款持久保存一个稳定的幂等键，并选择支持跨重试复用该键的服务商。 |
| 并发 | 同时点击或重复投递，不能为同一项获批请求创建多笔独立退款操作。 |
| 服务商响应不确定 | 超时后，操作进入待核对状态。不能只因响应丢失就发起新的退款操作。 |
| 验收与恢复 | 在测试环境中验证无权限时拒绝请求、重复请求和响应丢失的行为，并记录运维人员如何核对未决结果。 |
这些约定足以支持调查服务商行为，并实现一个范围有限的测试集成；它们不代表退款系统已经实现或验证。智能体可以选择辅助函数名，却不能悄悄改业务规则，或认定超时就意味着资金没有移动。
再开一次规划会，能否比这个小范围的安全实现更省成本地得到所需答案？如果只剩文档润色，就动手。
先规划再用 AI 开发，具体怎样推进？
先规划的 AI 开发流程，应让实现范围小到可以评审，让规格容易修订。先约定一项边界清楚的改动，再实现、依据独立审阅过的验收标准测试，并让用户或负责人检查结果，然后才开始下一次开发。
- 选定一个结果。写清用户是谁、可观察的变化是什么，以及谁有权验收。
- 澄清代价高的歧义。依据规划矩阵，检查约束与失败情形。
- 生成可评审的实现。按能够验证行为的边界拆分工作，记录偏离已批准约定之处。
- 检查实现与假设。测试正确性，审阅代码差异，并取得行为确实有助于目标用户的证据。
- 更新规格。下次开发之前，明确保留哪些行为、否定了哪些假设，以及下一个待解问题。
GitHub 的Spec Kit 介绍也主张持续修订规格，并拆成便于评审的小任务。具体工具见我们的Spec Kit 生产团队指南。规格有了结构，仍需独立判断其中的假设是否正确。
DORA 的小批次交付指南同样强调 AI 辅助开发中的快速反馈。每批工作应以能验证多少为限，不能只看智能体能生成多少。
怎样判断多做规划是否划算？
看通过验收的交付、返工和上线后缺陷。计时应从开始澄清需求到验收发布，包含规格评审和等待。编码用时缩短，只有在周边工作没有抵消收益、验收标准没有降低时，才对整体交付有帮助。
可以设计一个试点：对相似改动，分别使用简短任务说明和更明确的前期约定。记录规模、不确定性、撤回代价、团队熟悉程度与工具版本。条件允许时随机分配可比任务；否则只能作描述性比较，必须保留任务差异。
记录从启动到完成的时间，以及规划、实现、评审的人力投入。还要记录重开工作、发布后发现的缺陷，以及是否取得预期用户结果。这是建议采用的衡量方式，不是我们已经运行过的试点结果。
保持范围与质量标准一致。代码行更多，可能只说明生成量更多；发布次数更多，可能只说明每次打包更小。项目预算见AI MVP 成本指南。这里要判断的是，额外澄清是否值得占用交付时间。
应该重新采用瀑布开发吗？
需求能够澄清、做错后难以撤回的工作，值得重新重视前期规划。AI 让这种做法更值得试验，因为实现可能赶在假设过时前完成。控制范围，根据证据修订计划；只有通过验收的交付有所改善，才扩大规划投入。
面对已知流程，我们会先写准规格，再交给智能体。面对用户或价值主张尚未确定的产品，我们会先设计实验，尽早求证。
如果团队还无法就目标、约束或验收负责人达成一致，Wavect 的软件需求探索服务可以协助澄清这些决定。软件需求探索阶段指南介绍了工作范围。Quivr 协议交付与迁移案例仅提供相关工程背景，不能证明 AI 速度倍数或瀑布与敏捷的比较结果。
带一项具体改动来讨论需求：确定实现前必须做出的决定，以及什么证据足以支持发布。