需求前置为什么省时间：一个 HMI 项目的过程复盘

二

需求前置的理论依据是一条被广泛引用、但方法论本身有争议的曲线

1981 年，Barry Boehm 在《Software Engineering Economics》中提出：缺陷在项目周期中发现得越晚，修复成本越高。他基于 63 个大型软件项目的数据估算，需求阶段发现的缺陷成本记为 1 个单位，设计阶段为 5 到 10 倍，编码阶段为 10 到 20 倍，开发测试阶段为 50 到 100 倍，验收测试阶段为 100 到 200 倍，交付后的运维阶段为 200 到 1,000 倍[1]。这条曲线后来被简化传播为「1:10:100 法则」，一个常被引用的类似估算来自 NASA 对需求错误的研究：设计阶段 3 到 8 倍，制造/构建阶段 7 到 16 倍，集成测试阶段 21 到 78 倍，运维阶段最高可达 1,500 倍以上[2]。

这条曲线不是没有争议的定论。Laurent Bossavit 在《The Leprechauns of Software Engineering》中系统检验了 Boehm 曲线的原始出处，认为「支撑这条曲线的证据达不到任何合理的研究标准」——他发现 Boehm 引用的部分研究被转述时失真，其中至少一项研究实际显示的是相反方向的 2:1 比例，即后期修复反而更便宜[3]。Menzies 等人 2016 年对 171 个软件项目（2006 至 2014 年）的复核研究，也没有找到「延迟问题效应」的证据——即没有一致证明后期修复系统性地更耗时[4]。

两种解读都值得认真对待。Bossavit 的批评指向的是原始曲线的实证基础薄弱，尤其是它被过度传播为「自然法则」；Menzies 的研究则指向另一个可能性——这条曲线曾经成立，但现代工具、自动化测试和敏捷方法已经把曲线「压平」了。本文不裁定这场争论，但认为这场争论本身就是需要写进来的证据，而不能假装它不存在。本案例接下来的分析，把「缺陷发现点前移」当作一个可能有效、但本身证据强度有限的解释框架，而非一条已被证明的定律。

三

周期压缩来自等待、转述和晚期返工的减少，不是生成速度本身

旧流程要求销售先理解客户，再把理解交给产品经理。产品经理补齐业务规则后，研发人员继续追问变量地址、异常状态和验收条件。每次交接都可能删掉一个条件，也可能加入一个未经确认的解释。

新流程把原始材料直接保留下来。生成工具完成第一次整理，产品经理检查每条需求的出处、缺口和优先级，再生成可点击或可浏览的界面初版。客户开始对着具体页面回答问题：谁可以改参数，报警恢复后是否保留记录，通信中断时页面显示什么。

原型改变了沟通的精度。客户面对一句"需要报警管理"时，很难一次说清所有状态；看到报警列表、确认按钮和历史记录后，才容易指出权限、保留时间和恢复逻辑。产品经理也能把每个界面元素对应回一条原始需求，发现没有来源的设计假设。

这背后有一个更基础的认知机制可以解释"为什么看图比听描述更准"。John Sweller 提出的认知负荷理论指出，人类工作记忆处理新信息的能力有限；纯文字或口头描述一个复杂系统时，听者要同时在脑内构建结构、填补细节、并检查是否理解正确，这个过程本身消耗大量认知资源，越复杂的需求，遗漏和误解的概率越高[11]。团队协作研究中的"共享心智模型"概念，则描述了另一半问题：即使每个人都以为自己理解了需求，不同角色（客户、销售、产品经理、工程师）脑内构建的模型也可能并不一致，这种隐性错位往往要到后期才会暴露[12]。原型的作用，是把语言描述转成一个大家可以同时"看着说话"的具体对象——它不需要客户和工程师在脑内独立构建同一个模型再互相校对，而是直接给出一个外部化的共同参照物，认知负荷从"想象和推断"降到了"识别和判断"，这也是可用性工程里"原型工具本身在原型化什么"这一研究方向反复验证的观察[13]。

这种工作方式符合 ISO 9241-210 强调的持续用户参与，也符合软件原型研究中"用可见产物澄清需求"的作用[5][6]。生成工具降低了制作原型的成本，使团队能够更早进行评审。产品经理仍要确认业务规则，工程师仍要判断实现条件，客户也必须投入时间给出反馈。缺少这三方参与，快速原型只会更快地产生一版未经确认的猜测。

材料显示，团队重新安排了需求确认、界面评审和工程实现的顺序。生成工具压缩了第一版产物的制作时间，更多周期收益来自参与者更早围绕同一个对象做决定。现有证据不支持"模型用几十分钟完成了 27 天开发"这种解释。

四

其他软件工程研究给出相反结果，因为它们测量了不同任务和完成标准

公开研究没有给出一个统一的"AI 开发提速率"。GitHub Copilot 的控制实验使用边界清楚的编程任务，参与者借助工具完成得更快；对 4,867 名开发者的组织研究也观察到平均任务完成量增长。METR 让资深开发者处理自己熟悉的大型代码库，结果却是耗时增加。DORA 从组织层观察到，采用率提高与吞吐量和稳定性变化同时出现。

四项研究的差异主要来自上下文和验收标准。边界清楚、反馈即时的任务能快速判断输出是否可用；成熟代码库包含历史约束、文档、测试和维护规范，生成之后需要更长审查。组织研究还会把评审排队、发布稳定性和跨团队依赖纳入结果。模型生成了多少代码，无法单独说明项目交付得更快。

工控屏案例把 AI 放在需求整理和界面初版，客户可以马上评审，产品经理能够追溯来源，工程师也能在接入控制系统前拦住错误假设。反馈周期短，错误容易修改，风险低于直接生成并部署控制逻辑。这种位置选择比模型本身更能解释为什么案例可能获得收益。

五

界面只是可见层，工程师要为权限、通信和设备行为负责

客户看到的是屏幕，工程团队面对的是设备、协议和现场条件。鑫通态 Apus IDE 手册包含组态控件、PLC 通信和部署[7]。ISA-101 还要求团队处理报警、安全、历史数据以及服务器和网络接口[8]。

一个参数输入框还要对应变量地址、数据类型、读写权限和允许范围；报警界面背后包含触发条件、确认逻辑、优先级和历史记录；通信中断时，屏幕需要显示可信状态，并避免操作员把旧数据当成实时数据。生成界面可以提出结构，无法替项目团队确认这些工程事实。

团队若跳过人工确认，错误假设会从页面进入代码、变量表和测试。越靠近设备控制，修正成本和安全风险越高——这正是图 1 那条曲线在本案例中最有说服力的应用场景：不是「越晚发现成本越高」这个全局法则一定成立，而是「界面层的错误传导到设备控制层」这件具体的事，成本确实会指数上升。适合生成的范围应随风险逐层收窄：需求整理可以大范围使用，界面初版需要产品评审，重复工程代码要经过工程师检查，真机控制和最终验收必须由有责任的人完成。

六

反向证据：如果曲线不成立，本文的核心解释会怎样

本文第二节已经说明 Boehm 曲线本身存在争议。这里进一步追问：如果 Menzies 等人的复核是对的——现代工具、自动化测试和敏捷方法已经压平了这条曲线——那么本案例的解释还站得住吗？

本文认为，即使曲线被压平，需求前置仍然可能有价值，但价值的来源会不同。如果修复成本不再随阶段指数上升，那么周期收益主要不再来自"避免了昂贵的后期返工"，而更可能来自更直接的一点：减少了沟通轮次本身的等待时间——这与图 2 里"等待、转述、补问"占用 23.5 天中的大部分是一致的，且这个解释不依赖 Boehm 曲线是否成立。换句话说，本案例的周期收益可能有两条并行的解释路径，一条依赖有争议的成本曲线，另一条只依赖"减少沟通延迟"这个更朴素、争议更小的机制。

这也是本文没有把"缺陷成本曲线"当作唯一或确定性解释的原因。本文更审慎的表述是：需求前置至少通过减少沟通延迟带来了周期收益；它是否额外通过"提前拦截了原本会指数级增长的修复成本"带来了更多收益，取决于读者对 Boehm 与 Menzies 两方证据的采信程度，本文不代读者做这个判断。

还有一个更根本的反例需要正面回应："提前把需求做完整"这件事本身是否可靠？美国联邦调查局（FBI）2000 年至 2005 年间开发的"虚拟案件档案"（Virtual Case File，VCF）系统，是软件工程史上最常被引用的需求前置失败案例之一。项目最终耗费近 1.7 亿美元后被放弃，美国司法部监察长办公室的审计报告将其归因于设计需求定义模糊且持续变化、进度过于激进等多项因素；独立机构 Aerospace Corporation 的报告则认定交付的软件"不完整、不充分，设计拙劣到在真实条件下基本无法使用"[14]。这是一个"提前定义了大量需求，最后仍然彻底失败"的真实案例，如果不正面处理，本文的核心论点会显得站不住脚。

但仔细拆解 VCF 的失败原因，会发现它恰恰印证了本文的框架，而不是推翻它。VCF 采用的是"大设计前期"（Big Design Up Front）模式：团队在编码开始前，把需求写成详尽的静态规格文档，随后长期闭门开发，直到项目后期才第一次把可运行的软件交给用户看。这套流程里"前置"的是文档，不是可交互、可验证的原型——用户和开发团队从未在早期围绕一个具体、可点击的对象达成一致，管理层的多次更替和范围蔓延，进一步让最初的文档假设逐渐偏离现实，却没有任何早期反馈机制能够发现这种偏离[14]。这与本案例的情况正好相反：本案例前置的是可评审的界面初版，客户在收到材料后 40 分钟内就能看到并回应一个具体对象，而不是在项目尾声才第一次看到成品。

这个反例真正精化了本文的论点，而不是被简单反驳掉："提前投入时间"本身不是收益的来源，"提前产出可被验证的具体对象"才是。如果一个团队把需求前置理解成"花更长时间写一份更详尽的文字规格"，反而可能重复 VCF 的错误——把大量精力投入一个直到后期才会被验证的假设里。本文第三节引用的认知负荷与共享心智模型研究，说明的正是为什么原型（而非文档）才是有效的前置形式：原型把语言描述转成可以被立即检查的外部对象，文档做不到这一点，充其量只是把"未来才会暴露的误解"换了一种更详细的措辞提前写下来。

七

企业复制这条路径前，需要把案例线索变成自己的项目证据

本文的几项判断并不处在同一证据水平上，读者有必要区分。HMI 项目包含界面之外的工程约束、原型有助于澄清需求——这两项有公开手册与国际标准支持。AI 的效果取决于任务与工作环境，这一点有多项同行评议研究佐证。周期从 27 天变为 3.5 天，只有项目材料这一个来源。而"需求前置解释了大部分周期变化"是我们基于流程顺序与沟通延迟所作的推断，其中一部分依赖尚有争议的缺陷成本曲线。至于同类企业能否复制相同幅度的收益，现有材料完全不足以回答。

这份单案例可以解释一种可能有效的工作机制，无法给出行业平均效果。27 天来自原排期，没有记录同一项目按旧流程实际完成所需的时间；行业公开资料显示，同类工业 HMI 与 SCADA 定制项目的典型周期跨度从约 21 周到 30 周以上不等[10]——这个跨度本身就说明"27 天"和"3.5 天"都远短于多数公开报价的整体项目周期，本案例很可能只覆盖了界面设计这一个子环节，而非全部工程周期，这是解读这两个数字时必须加上的边界。现有材料还缺少聊天原文、任务日志、代码提交和验收文件。团队经验、客户配合与模板复用也可能影响结果。本文没有独立测试 EasyCode，也没有比较其他生成工具。

企业可以选择需求分散、相似定制反复出现、客户能够提前评审界面的项目进行试点。第一项指标是首个可评审原型时间，从收到材料到客户可以逐页评论。第二项是开工前需求关闭率，统计工程师正式开发前有多少关键条件得到确认。随后记录开工后变更、返工工时和最终验收轮次，并与复杂度接近的历史项目比较。

每个项目还要保留客户原话、需求版本、原型修改和人工确认记录。这样才能区分周期变化来自工具、模板复用还是客户响应速度。几个项目连续采用同一记录口径后，团队才有条件判断平均收益、适用任务和质量风险。

现有材料支持一项谨慎结论：生成工具适合先把散乱沟通整理成可评审对象，客户、产品经理和工程师借此更早关闭关键条件。业务含义、控制逻辑和真机结果仍由专业人员负责。企业无需先相信 3.5 天的案例数字，也无需先站队 Boehm 曲线的争议，可以用自己的项目日志检验这套分工。