--- title: "AI 编程需求要写多详细？前期规划与瀑布开发" canonical: https://wavect.io/zh/blog/ai-waterfall-upfront-planning/ language: zh description: "AI 编程需求要写多详细？用不确定性与撤回代价决定规划深度，结合假设交付算例和退款验收要求，判断何时写清规格、何时做原型，以及何时停止规划。" image: "https://wavect.io/img/blog/headers/header_ai-waterfall-upfront-planning.png" author: ["Kevin Riedl"] published: "2026-11-10" updated: "2026-11-10" reviewed: "2026-11-10" --- # AI 编程需求要写多详细？瀑布开发会回来吗？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月10日 最近审核 2026年11月10日 [**下一篇**](/zh/blog/github-spec-kit-production-guide/) 要点速览 实现变快，明确目标与约束可能更划算，但规划深度仍取决于不确定性和撤回代价。重要改动先定负责人及验收证据，未知需求用安全实验求证。在假设的顺序模型中，编码速度为原来的100倍，整体速度也只有4.81倍。下一步通过实现能更便宜地得到答案时，就停止增加细节。 计划获批后，几个月过去，用户还没用上成果，优先级却变了。如果 AI 能缩短这段实现时间，我们就有理由重新评估前期规划的价值。 **AI 编程需求要写多详细，应先看做错后要付出多少代价。实现越快，一份合理的计划就越有机会在假设过时前发挥作用。我们的建议是：重要改动先明确目标、约束和验收标准，再交给智能体实现；也保留根据证据修改假设的空间。** 前期规划是在实现之前把决定做清楚；瀑布开发则把交付组织成依次推进的阶段。采用前者，并不要求把所有需求冻结到最终发布。 **研究截至：2026年11月10日。**本文依据一手研究和假设算例提出建议。Wavect 没有开展瀑布与敏捷的对照实验，下文的 100× 编码速度也只是模型输入，不是行业实测结果。 ## AI 为什么让前期规划更值得投入？ 当实现足够快，尚未做出的决定就可能成为交付的主要障碍。此时，前期规划更有价值：智能体拿到明确需求就能动手；如果没人定义什么才算正确，生成得越快，也可能留下越多需要否决或重写的工作。 例如，两个智能体可以并行开发客户数据导出的界面和 API。事先约定租户边界、数据结构和错误处理约定，它们才能做出相互配合的实现。只说“做一个导出功能”，就把这些选择留给了各自的猜测。 在初始不确定性相同的前提下，本周就能让用户试用的改动，比一年后才能完成的改动，更少受到期间环境变化的影响。缩短实现时间可以提高规划的回报，却不能让预测永远正确。 我们的 [AI、规格与软件工厂回归](/zh/blog/the-factory-returns/) 讨论了工程工作的整体变化。这里聚焦下一次实现之前，究竟应该先决定多少事情。 ## 瀑布开发的问题只是代码写得慢吗？ 实现缓慢会让计划过时，太晚发现问题同样会。即使代码瞬间完成，也可能满足了错误的需求。规划必须包含检验假设的方法，让团队在投入过多之前发现偏差，并在证据变化时修订决定。 Royce 在 1970 年的论文中已经警告：如果到后期测试才发现系统约束，就可能需要大幅返工。他也描述了开发阶段之间的反馈。用这篇 [大型系统开发原始论文](https://blog.marsen.me/assets/royce1970.pdf) 为僵化、一次通过的流程辩护，并不合适。 [Agile Manifesto（敏捷宣言）](https://agilemanifesto.org/) 同样承认计划有价值，只是更重视响应变化。有了反面证据还继续照旧执行，即使实现很快，也可能白费力气。 ## AI 写代码已经达到原来的 100 倍速度了吗？ 本文查阅的研究尚未证明，AI 能普遍让软件实现速度达到原来的 100 倍。结果取决于任务、开发者、工具和衡量指标。完成一道编程任务的用时、代码活动、发布数量和用户价值，分别回答不同的问题。 | 研究 | 报告结果 | 适用边界 | | --- | --- | --- | | [2022 年开展的 Copilot 对照实验](https://arxiv.org/html/2302.06590v1) | 招募 95 名程序员；完成任务的参与者中，使用 Copilot 者平均少用时 55.8%。 | 任务是编写一个 JavaScript HTTP 服务器，未测量完整产品交付。 | | [METR 的 2025 年早期实验](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) | 16 名经验丰富的维护者处理 246 个任务；允许使用 AI 时，完成时间增加 19%。 | 对应特定代码库场景和当时的工具，不能视为当前通用的减速结论。 | | [Writing Code vs. Shipping Code，2026 年 9 月修订版](https://www.mertdemirer.com/Papers/Demirer_Writing_vs_shipping_code.pdf) | 这项观察性研究覆盖超过 50 万名 GitHub 开发者，估计代码活动的增幅远大于发布数量的增幅。 | 产出数量不等于耗时缩短，也不等于用户价值。 | METR 在 [2026 年 2 月的后续说明](https://metr.org/blog/2026-02-24-uplift-update/) 中指出，样本选择和多个智能体并行时的计时问题，使其新一轮生产率估计不可靠。早期的减速结果不应成为对今天所有工具的定论。 我们仍可以认真检验 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 结果](https://epoch.ai/publications/mirrorcode-preliminary-results) 展示了在可执行的参考实现和详细测试辅助下，智能体能够自主完成相当规模的重新实现。这支持可检验规格的用途，但这个范围有限的基准不能证明瀑布更优，也没有测出相对人类的速度倍数。 “妥善处理失败”很难验收。“服务商响应不确定时，保留操作标识，先核对状态，再决定是否重试”，才是可以检验的行为。 ## 不同改动应该投入多少前期规划？ 规划深度取决于不确定性和撤回决定的代价。需求明确、做错后果重的改动，值得详细准备；行为尚不确定、又容易修改的改动，适合尽早实验。如果两项都高，应先设计安全的求证方式，避免直接让整个系统承担后果。 | 需求不确定性 | 撤回代价 | 下一步 | 例子 | | --- | --- | --- | --- | | 低 | 低 | 写清简短的验收约定，然后实现。 | 已有明确示例、不改变存储数据的展示调整。 | | 低 | 高 | 执行前明确依赖、失败情形和恢复方式。 | 必须保留现有记录与集成的数据迁移。 | | 高 | 低 | 提出待验证的问题，用可丢弃的版本实验。 | 让有代表性的用户试用两种引导流程。 | | 高 | 高 | 通过模拟或隔离试验降低不确定性，再正式投入。 | 新分配规则先用合成数据评估，再考虑作用于真实账户。 | 如果智能体很快就能做出安全的原型，再花一周争论臆测中的界面，可能不划算。实现变快，既能提高明确已知约束的回报，也能降低提前猜测用户偏好的必要性，因为偏好可以直接观察。 撤回代价包括受影响的人、丢失的数据、已经做出的承诺、运营中断和工程投入。生成代码便宜，不代表所有后果都便宜。安全硬约束也不会因为收益表显示划算就失效。 ## 规划做到什么程度就可以开始实现？ 下一小步实现已有一致的目标、明确约束、负责人、可观察的验收标准和恢复办法，就可以考虑动手。把剩余未知及其验证方法记下来。只有当继续澄清一个决定预计能避免的损失，值得付出相应时间时，才继续增加规划。 看一个虚构示例：客服人员需要通过支付服务商发起全额退款。假设退款资格和审批规则已经确定。如果规则仍有冲突，先参考 [规格编写前如何解决业务规则冲突](/zh/blog/enterprise-business-rule-conflicts/) 。 | 实现前要确定什么 | 可检验的要求 | | --- | --- | | 权限 | 只有获授权的客服角色，才能为自己所属租户发起已批准的退款。 | | 操作身份 | 为这笔获批退款持久保存一个稳定的幂等键，并选择支持跨重试复用该键的服务商。 | | 并发 | 同时点击或重复投递，不能为同一项获批请求创建多笔独立退款操作。 | | 服务商响应不确定 | 超时后，操作进入待核对状态。不能只因响应丢失就发起新的退款操作。 | | 验收与恢复 | 在测试环境中验证无权限时拒绝请求、重复请求和响应丢失的行为，并记录运维人员如何核对未决结果。 | 这些约定足以支持调查服务商行为，并实现一个范围有限的测试集成；它们不代表退款系统已经实现或验证。智能体可以选择辅助函数名，却不能悄悄改业务规则，或认定超时就意味着资金没有移动。 再开一次规划会，能否比这个小范围的安全实现更省成本地得到所需答案？如果只剩文档润色，就动手。 ## 先规划再用 AI 开发，具体怎样推进？ 先规划的 AI 开发流程，应让实现范围小到可以评审，让规格容易修订。先约定一项边界清楚的改动，再实现、依据独立审阅过的验收标准测试，并让用户或负责人检查结果，然后才开始下一次开发。 1. **选定一个结果。** 写清用户是谁、可观察的变化是什么，以及谁有权验收。 2. **澄清代价高的歧义。** 依据规划矩阵，检查约束与失败情形。 3. **生成可评审的实现。** 按能够验证行为的边界拆分工作，记录偏离已批准约定之处。 4. **检查实现与假设。** 测试正确性，审阅代码差异，并取得行为确实有助于目标用户的证据。 5. **更新规格。** 下次开发之前，明确保留哪些行为、否定了哪些假设，以及下一个待解问题。 GitHub 的 [Spec Kit 介绍](https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/) 也主张持续修订规格，并拆成便于评审的小任务。具体工具见我们的 [Spec Kit 生产团队指南](/zh/blog/github-spec-kit-production-guide/) 。规格有了结构，仍需独立判断其中的假设是否正确。 [DORA 的小批次交付指南](https://dora.dev/capabilities/working-in-small-batches/) 同样强调 AI 辅助开发中的快速反馈。每批工作应以能验证多少为限，不能只看智能体能生成多少。 ## 怎样判断多做规划是否划算？ 看通过验收的交付、返工和上线后缺陷。计时应从开始澄清需求到验收发布，包含规格评审和等待。编码用时缩短，只有在周边工作没有抵消收益、验收标准没有降低时，才对整体交付有帮助。 可以设计一个试点：对相似改动，分别使用简短任务说明和更明确的前期约定。记录规模、不确定性、撤回代价、团队熟悉程度与工具版本。条件允许时随机分配可比任务；否则只能作描述性比较，必须保留任务差异。 记录从启动到完成的时间，以及规划、实现、评审的人力投入。还要记录重开工作、发布后发现的缺陷，以及是否取得预期用户结果。这是建议采用的衡量方式，不是我们已经运行过的试点结果。 保持范围与质量标准一致。代码行更多，可能只说明生成量更多；发布次数更多，可能只说明每次打包更小。项目预算见 [AI MVP 成本指南](/zh/blog/ai-mvp-cost-austria-2026/) 。这里要判断的是，额外澄清是否值得占用交付时间。 ## 应该重新采用瀑布开发吗？ 需求能够澄清、做错后难以撤回的工作，值得重新重视前期规划。AI 让这种做法更值得试验，因为实现可能赶在假设过时前完成。控制范围，根据证据修订计划；只有通过验收的交付有所改善，才扩大规划投入。 面对已知流程，我们会先写准规格，再交给智能体。面对用户或价值主张尚未确定的产品，我们会先设计实验，尽早求证。 如果团队还无法就目标、约束或验收负责人达成一致，Wavect 的 [软件需求探索服务](/zh/services/software-discovery/) 可以协助澄清这些决定。 [软件需求探索阶段指南](/zh/software-development-guide/what-is-a-discovery-phase/) 介绍了工作范围。 [Quivr 协议交付与迁移案例](/zh/case-studies/quivr/) 仅提供相关工程背景，不能证明 AI 速度倍数或瀑布与敏捷的比较结果。 [带一项具体改动来讨论需求](/zh/contact/?intent=software-dev) ：确定实现前必须做出的决定，以及什么证据足以支持发布。 ## AI 编程、瀑布开发与前期规划常见问题 ### 需求规格和代码都能交给 AI 写吗？ 可以让 AI 起草规格、找出矛盾并提出失败情形。有权决定产品行为的人仍须确认目标。把假设与已确认需求分开，并让验收标准接受独立于生成实现的审阅。文档写得流畅，并不能说明它描述的产品就是用户需要的产品。 ### AI 辅助项目应该由谁验收？ 分别明确谁能接受业务结果、哪些工程评审者负责技术约束。同一项改动可能涉及不同人的决定。最终验收不应交给生成该实现的智能体。开始实现之前就约定所需证据，避免到评审时才争论原本想做什么。 ### 采用这种规划方式，需要放弃 Scrum 吗？ 我们建议的流程不要求更换项目管理框架。团队可以先澄清下一项重要改动，再按现有节奏评审结果。先改善决定和验收证据的质量。是否调整会议或角色，应由它能解决什么交付问题来判断。 ### 实现过程中需求变了，应该怎么办？ 暂停受影响的工作，找出哪些已批准的决定发生变化，评估对接口、数据、测试和发布的影响。与负责人更新规格后再继续，保留仍然适用的工作。需求变化可以带来有用证据；把旧计划视为永远正确，反而可能造成返工。 ### 这里讨论的是开发 AI 产品，还是用 AI 写代码？ 这里讨论 AI 辅助软件开发，所实现的产品本身可以完全不含 AI。如果产品使用模型，还须在实际用途下评估模型行为。代码生成变快，不能证明概率性输出符合产品验收标准，也不能证明用户需要这个功能。 ### 需求规格应该放进 Git 仓库吗？ 对规格做版本管理，有助于一起审阅改动、理由和测试。如果需求批准者能够访问并审阅仓库，可以放在其中；否则在其他位置保留有负责人维护的原件，并链接到准确版本。重点是可追溯和持续维护，复制一份不再更新的文档进 Git 并不能做到这两点。 产品战略 ## 接下来读什么 范围、产品市场匹配、可信版本与打造有用产品的关键决策。 [从这里开始**一条可衡量的产品市场契合之路**](/zh/blog/road-to-product-market-fit/) - [ChatGPT 搜索控制台：Business Hub 能测什么，企业现在该做什么？](/zh/blog/chatgpt-search-console-business-hub/) - [企业软件：让 AI 写代码前，先解决业务规则冲突](/zh/blog/enterprise-business-rule-conflicts/) - [Scope 与 Armature：衡量智能体 API 采用，而不只是品牌提及](/zh/blog/scope-vs-armature-agent-api-adoption/) - [AI MVP 范围：验收标准、评测集与 SoW](/zh/blog/ai-mvp-scope-template/) - [2026 年在奥地利做一个 AI MVP 要多少钱？](/zh/blog/ai-mvp-cost-austria-2026/) [下一篇文章**ChatGPT 搜索控制台：Business Hub 能测什么，企业现在该做什么？**](/zh/blog/chatgpt-search-console-business-hub/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月10日 最近审核 2026年11月10日 [**下一篇**](/zh/blog/github-spec-kit-production-guide/)