第一章：需求困境——为什么原型到规格的鸿沟是项目失败的根源？
说实话，我做了十几年产品架构，见过太多项目栽在同一个坑里——原型做得漂漂亮亮，开发也热火朝天，结果交付时客户来一句：「这不是我要的。」
为什么会这样？
因为原型和规格之间，隔着一道看不见的鸿沟。
1.1 原型不是规格，别搞混了
很多人觉得，原型都有了，写规格不就是把界面描述一遍吗？
大错特错。
原型是「视觉表达」，规格是「逻辑契约」。原型告诉你界面长什么样，规格告诉你系统该怎么行为。我见过一个团队，原型画了100多页，开发照着做，结果上线第一天就崩了——因为原型里没画「用户连续点击5次提交按钮」的情况。
嗯，这就是典型的「原型陷阱」。
核心区别：
- 原型回答「看起来怎样」
- 规格回答「行为上怎样」
- 原型是沟通工具
- 规格是契约依据
1.2 鸿沟到底在哪？我总结了三个层面
这些年我复盘过不少失败项目，发现原型到规格的鸿沟，主要集中在三个方面：
第一层：信息缺失
原型不会告诉你——
- 数据从哪里来？
- 异常怎么处理？
- 边界条件是什么？
- 性能要求多高？
说白了，原型只展示了「阳光路径」。而软件系统80%的代码，都在处理「非阳光路径」。你想想看，如果规格里不写这些，开发只能靠猜。
我的经验：有一次项目延期了两个月，原因就是原型里没标注「加载状态」。开发默认用转圈，客户要求用骨架屏。就这一个细节，前后返工三次。
第二层：理解偏差
同一个原型，不同人看到的东西不一样——
- 产品经理看到的是「用户流程」
- 设计师看到的是「视觉细节」
- 开发看到的是「数据结构」
- 测试看到的是「操作路径」
我曾经在一个评审会上，产品说「这里弹个窗」，设计师理解成模态框，开发理解成轻提示，测试理解成确认对话框。结果吵了半小时才发现，大家说的根本不是同一个东西。
注意：不要以为「大家都看到了同一个原型」就等于「大家理解一致」。原型是二维的，需求是多维的。缺少规格这个「翻译层」，误解是必然的。
第三层：逻辑断层
原型是静态的，需求是动态的。原型展示的是「某个时刻的界面」，而系统需要处理「所有时刻的状态变化」。
举个例子：
- 原型画了「提交成功」的页面
- 原型画了「提交失败」的页面
- 但原型没画「提交中」的状态
- 也没画「提交后网络断开」的情况
- 更没画「重复提交」的防重处理
这些逻辑断层，就是项目后期bug的重灾区。
1.3 为什么说这是项目失败的根源？
我直接说结论：原型到规格的鸿沟，本质上是「沟通成本」向「返工成本」的转化。
你想想看——
- 前期少花1小时写规格
- 后期可能多花10小时改代码
- 更可怕的是，改完代码发现架构不支持，得重构
- 重构完发现需求又变了
这就是典型的「需求债务」。
数据说话：根据我参与过的项目统计，原型阶段发现需求问题，修复成本是1倍；开发阶段发现，成本是10倍；测试阶段发现，成本是50倍；上线后才发现，成本是100倍以上。
1.4 怎么填平这道鸿沟？
方法其实不复杂，但需要坚持。我把它总结成三个步骤：
- 从原型中提取「行为点」——每个界面元素，都问一句「它应该怎么动？」
- 用规格描述「行为规则」——不是描述界面长什么样，而是描述系统在什么条件下做什么事
- 建立「原型-规格」对照表——确保每个原型元素都有对应的规格条目
举个例子，一个简单的登录按钮：
| 原型元素 | 规格描述 |
|---|---|
| 登录按钮 | 点击后校验用户名和密码非空 |
| 登录按钮 | 校验通过后调用登录接口 |
| 登录按钮 | 接口调用期间按钮置灰，显示加载状态 |
| 登录按钮 | 接口返回成功，跳转首页 |
| 登录按钮 | 接口返回失败，显示错误提示，按钮恢复可用 |
| 登录按钮 | 连续5次失败，锁定账号30分钟 |
你看，一个简单的按钮，在原型里就是一张图。但在规格里，它变成了6条行为规则。这就是差距。
避坑指南：我曾经犯过一个错——觉得「这么简单的东西不用写规格」。结果开发把「登录失败」做成了弹窗，客户要求的是行内提示。就这一个细节，改了3天。从那以后，我坚持「再简单的功能也要写规格」。
1.5 小结
原型到规格的鸿沟，说白了就是「你以为你懂了」和「你真的懂了」之间的距离。
填平这道鸿沟，不是增加工作量，而是减少返工量。这门课后续的内容，就是手把手教你如何系统化地完成这个「翻译」过程。
记住一句话：原型是起点，规格是终点。中间的路，一步都不能省。
下一章，我们来聊聊「需求精炼的核心框架」——怎么把模糊的想法，变成可执行的规格。