先做原型还是直接开发？老板多花 7 天，可能省掉后面 3 个月返工

不是每个项目都要安排完整原型阶段。老板可以先看四类信号。

可以直接进入开发的情况

• 只改一个范围清楚的小功能；
• 有正在使用的旧页面，调整目标明确；
• 用户、字段、流程和权限已经固化；
• 接口和数据结构已验证；
• 验收样例能够直接写出来；
• 开发团队和业务人员对现状有共同理解。

例如，在现有报修系统中增加一个已经确认的导出字段，通常不需要重新做整套原型。把变更范围、权限和验收数据写清即可。

建议先做原型的情况

• 老板能说出目标，但说不清用户如何完成任务；
• 多个部门对同一流程有不同说法；
• 新系统将替代 Excel、微信群或多套旧软件；
• 涉及客户、供应商、员工等多个角色；
• 移动端、管理端和大屏之间需要协同；
• 审批、价格、库存、绩效等规则复杂；
• 首次建设新业务，需求会根据用户反馈调整；
• 项目一旦开工，改变方向的代价很高。

如果会上经常出现“这个以后再说”“到时候应该能改”“我理解的不是这样”，原型阶段几乎不是额外成本，而是避免盲目开工的保险。

很多原型会议最后变成审美讨论：按钮用蓝色还是绿色、首页卡片要不要阴影。视觉当然重要，但在开发前更应该验证的是以下七件事。

1. 用户是否能完成核心任务

从哪里进入、先填什么、下一步找谁、完成后看到什么。不要只展示首页，要完整走通“发起—处理—异常—结束”。

2. 业务规则是否有唯一解释

谁可以修改金额？退回后回到哪一步？审批人请假怎么办？数据跨月后能否修改？同一客户怎样判重？这些规则需要在页面动作和状态变化中看得见。

3. 权限是否跟职责一致

能查看不等于能编辑，能编辑不等于能导出。原型应说明不同角色能看到哪些菜单、数据范围和操作按钮，尤其要验证越权风险。

4. 异常场景能否处理

数据缺失、接口失败、重复提交、审批超时、库存不足、账号停用时，系统怎样提示、怎样恢复、是否允许人工介入。只画“顺利成功”的原型，最容易把复杂度留到开发后期。

5. 数据从哪里来、最后到哪里去

每个关键字段是用户录入、系统计算、旧系统同步还是第三方返回？修改后影响哪些报表？原型不需要完成数据库设计，但必须暴露数据来源和去向。

6. 系统边界是否清楚

登录、支付、电子签章、短信、地图、ERP、财务等能力由本系统完成，还是调用外部服务？在原型上标出边界，才知道哪些接口要提前验证。

7. 验收结果能否被描述

关键任务走完后，页面、数据、消息和报表应该出现什么结果。如果原型阶段无法说明“怎样算完成”，开发完成后也很难验收。

“原型”并不等于一套接近成品的精美界面。应根据要消除的风险选择精度。

多数企业项目可以先用低保真梳理主流程，再把最关键的两三条任务做成可点击原型。只有当风险来自技术本身，例如旧设备能否连接、第三方接口是否支持某种场景、AI 对真实样本能否达到可接受效果，才需要写少量验证代码。

原型越精美，参与者越容易误以为方向已经确定，也越舍不得推翻。早期重点是得到真实反馈，不是制造“已经完成 80%”的错觉。

以下安排适合边界中等、核心参与人能够及时到场的项目。复杂平台可以把它延长为两到四周，或按业务模块分批执行。

第 1 天：锁定目标和参与人

只回答四个问题：为什么做、给谁用、首期必须解决什么、用什么结果判断有价值。指定一位最终决策人，并列出业务、技术、数据和合规联系人。

当天交付：一页项目说明、角色清单、首期目标和不做事项。

第 2 天：画出现状和关键任务

选择频率最高、价值最大、风险最高的三到五条任务，画出现有做法、痛点、输入和输出。不要试图把未来三年的功能全部塞入首期。

当天交付：现状流程、目标流程、关键任务优先级。

第 3 天：确认规则、权限和异常

逐条回答谁发起、谁处理、什么条件通过、什么情况退回、哪些数据能改、哪些动作要留痕。把没有答案的问题单独列入待决策清单，不能用页面占位掩盖。

当天交付：规则表、权限矩阵、异常场景清单。

第 4 天：制作低保真可点击原型

覆盖完整任务路径，不追求视觉包装。关键按钮、字段、状态、提示和跳转应能够让参与者理解系统行为。

当天交付：第一版可点击原型及页面说明。

第 5 天：让真实用户完成任务

不要由设计师一路讲解。给用户一个任务和代表性数据，让他自己操作。观察他在哪停顿、误解、返回或寻找帮助。记录行为，而不只记录“感觉不错”。

当天交付：测试记录、问题严重度和修改建议。

第 6 天：修改并核对系统边界

根据测试修正流程，同时邀请开发或架构人员核对接口、数据、性能和安全风险。页面上看似简单的“一键同步”，可能依赖尚未开放的外部接口，必须在此时暴露。

当天交付：第二版原型、接口盘点、技术风险清单。

第 7 天：决策，而不是举行展示会

业务负责人逐条确认首期范围、待定事项、暂不实现内容和验收口径。技术团队据此估算，而不是根据最初一句需求报价。

当天交付：确认版原型、范围基线、优先级、风险与下一阶段计划。

如果关键决策人无法参加，7 天并不会自动产生好结果。原型周期短的前提，是问题能够被及时回答。

返工从来不只是“重画一个页面”。假设开发后期才发现审批流程理解错了，影响链条可能是：

1. 产品重新梳理规则；
2. 设计调整多个角色的页面；
3. 后端修改状态机和权限；
4. 数据库增加字段或迁移已有数据；
5. 前端重做按钮、列表和消息；
6. 对接系统重新联调；
7. 测试用例和自动化测试更新；
8. 报表口径重新核对；
9. 用户手册、培训和验收计划重写；
10. 已经完成的其他功能重新回归测试。

如果错误涉及系统底层数据结构或多个外部接口，返工还会向其他模块扩散。真正被浪费的不是某个工程师三个月，而是多个角色在等待、重做和重新确认中的总周期。

原型的价值，就是在代码、数据和组织安排尚未绑定之前，让大家用低成本版本发现这类错误。

老板必须防止三个常见误会。

误会一：原型里有，就默认报价里有

原型可能包含用于说明方向的页面，也可能省略后台配置、异常处理和管理功能。进入开发前，必须把原型页面映射到正式范围清单，标出首期、后续和不包含内容。

误会二：原型能点击，就已经开发了一半

可点击原型通常没有真实数据库、权限、安全、并发、接口、日志和错误恢复。它证明用户路径可以讨论，不代表生产系统已经完成。

英国政府数字服务手册明确提醒，代码原型是为了测试假设，不是生产代码，不应简单复制进正式服务。技术验证中的“能跑”与生产环境中的“可长期负责”是两种标准。

误会三：确认原型后，任何细节都不能变

原型确认锁定的是当前基线，不是禁止合理变化。合同应说明变更怎样提出、评估和批准。否则团队要么拒绝必要调整，要么重新回到无边界修改。

一页需求说明可以参考《不会写需求文档？老板只要写清这一页，开发公司就能报价》，再与原型、规则表和验收样例一起使用。

一套只有设计链接、没有解释的原型很难成为开发依据。建议至少保留：

1. 项目目标与成功指标；
2. 用户角色和核心任务；
3. 现状流程与目标流程；
4. 可点击原型及版本号；
5. 业务规则、状态和权限矩阵；
6. 数据来源、接口与外部依赖清单；
7. 待决策、风险和不包含事项；
8. 首期范围、优先级和验收样例。

每次评审还应记录谁确认了什么、哪些问题暂缓、下一次由谁回答。否则设计文件在变化，会议结论散落在聊天记录里，开发人员仍然不知道哪个版本有效。

评审时，不要问“大家觉得怎么样”，而要给每个角色具体任务：

• 销售：新客户重复时怎样处理？
• 财务：金额修改后怎样追溯？
• 主管：超出权限的审批怎样升级？
• 一线员工：三分钟内能否完成高频操作？
• 管理员：人员离职后数据和任务怎样接管？
• 技术人员：外部接口失败后怎样补偿？
• 安全或法务：哪些敏感数据不应被普通角色查看或导出？

让参与人使用真实但脱敏的样例完成任务，并记录完成率、耗时、错误点和疑问。意见冲突时由明确的决策人处理，不用“回头再议”把矛盾带进开发阶段。

1. 只找管理层看，不找真实用户试

管理层熟悉目标，但未必知道一线每天绕过哪些流程。没有用户测试，很多操作成本到上线后才暴露。

2. 追求全系统覆盖，迟迟不验证核心路径

原型页面越来越多，关键业务仍没有走通。应先验证高价值、高频和高风险任务。

3. 页面确认了，规则仍写“按实际情况处理”

这等于把最难的问题留给开发人员猜。无法决定的事项要有负责人和截止时间，不能假装已确认。

4. 不让技术团队提前参加

业务和设计确认了漂亮方案，开发时才发现接口不存在、数据拿不到或性能成本过高。技术可行性必须在范围锁定前检查。

5. 把原型确认当作供应商免责条款

客户确认原型，不代表供应商可以忽略明显的安全、数据和工程风险。双方仍要分别对业务决策与专业交付负责。

建议把项目拆成两个决策点。

第一个决策点是“是否值得做”：完成关键用户验证、技术风险盘点和粗略成本范围。若价值不足或关键接口不可用，可以小成本停止。

第二个决策点是“怎样做”：根据确认版原型形成开发清单、排除项、里程碑、验收标准和正式报价。需求明确的模块可以总价，仍需探索的部分可以按迭代或单独验证。

付款节点应对应可检查的成果，例如范围确认、首个可运行版本、核心流程联调、试运行和最终交接，而不是只按自然月份。项目为什么会延期以及双方如何减少等待，可继续阅读《软件项目为什么总延期？很多时候不是开发慢，而是这 5 件事没人拍板》。

只有页面漂亮、以上问题却回答不了，这套原型仍不具备降低返工的能力。

做原型一般需要多久？

小型、边界清楚的项目可以用 3 至 7 个工作日验证核心流程；多部门、复杂数据或多端系统可能需要数周。时间取决于要验证的问题和决策效率，不应以固定天数承诺所有项目。

原型越精细越好吗？

不是。早期用低保真更容易推翻错误方向；在核心流程稳定后，再提升交互和视觉精度。精细程度应服务于当前问题，而不是制造完成感。

做完原型可以拿给任何开发公司报价吗？

可以，但不能只交一个设计链接。还应提供范围说明、规则、权限、接口、数据、质量要求和验收样例，才能让不同公司的报价可比较。

原型费用是不是会被重复收取？

如果原型交付物可以直接支持需求基线、估算和验收，它就是独立的风险控制成果。合同应说明设计源文件和文档归属，以及进入开发后哪些成果会复用。

已经开发了一半，再补原型还有意义吗？

有。不要为所有页面补图，而应针对争议最多、返工风险最高的流程制作原型，先停止继续扩散，再确认修改影响和优先级。

• GOV.UK Service Manual：Making prototypes：用于说明原型应在正式投入前探索、分享和测试设计，且可以从草图逐步发展到代码原型。
• GOV.UK Service Manual：How the alpha phase works：用于说明早期阶段应优先验证风险最大的假设，并预期丢弃部分原型代码。

文中的“7 天”和“3 个月”是用于解释早发现、低成本修改的管理示例，不是对所有项目周期或节省金额的保证。实际安排应根据系统范围、参与部门、外部依赖和决策效率确定。

直接开发看起来少花了一周，但如果团队连用户怎样完成任务、规则由谁决定、异常怎样处理都没有共同答案，省下的只是最便宜的一周，赌上的却是后面最昂贵的开发和上线阶段。

好的原型不会把所有页面画完，而会优先把最值得做、最容易错、改起来最贵的部分拿出来验证。确认方向后再开发，报价更有依据，验收也更少争议。

如果你正在启动企业软件项目，可以先查看华茂思捷的软件原型、定制开发与系统集成服务，也可以通过联系页面提交现有流程、样表和系统情况。我们会先判断哪些问题需要原型验证，再决定是直接开发、先做短期梳理，还是先完成技术验证。