1977年8月12日，一架航天飞机被送上约7000米高空。
但送它上去的不是火箭，而是一架改装过的波音747。
到达预定高度后，航天飞机与波音747分离。没有发动机，也没有重新起飞的机会，两名宇航员驾驶它独立滑翔，最终安全降落。
它就是“企业号”。
有意思的是，这架航天飞机后来从未真正进入太空。
它没有完整的推进系统，也不具备执行轨道任务的全部能力。严格来说，它甚至不是一架具备完整任务能力的航天飞机。
但这恰恰是它存在的意义。
当时 NASA 需要回答一个非常具体的问题：
这么大的航天飞机从太空返回后，究竟能不能像滑翔机一样安全降落？
如果等第一次真正执行太空任务时再验证，代价太高。
所以工程师没有先造一个完整系统，而是先造了一个足以验证关键问题的版本。
发动机可以没有，轨道飞行能力可以没有，很多正式设备也可以暂时没有。
只要它能回答“能不能安全降落”，第一步就够了。
做软件这些年，我越来越喜欢这种工程思路。
我们经常习惯把一个想法一路做完整：需求、架构、开发、数据、部署，全部准备好以后，再去验证最开始的假设。
问题是，如果那个假设本身就是错的，后面做得越完整，浪费反而越大。
更好的问题应该是：
这个项目现在最大的不确定性是什么？
不知道用户会不会用，就先做原型；不知道架构能不能撑住，就先压测；担心技术方案不可行，就先做 PoC；如果 AI 工作流最大的风险是准确率，就先拿 100 条真实数据验证，而不是先把整个平台搭出来。
这和 MVP 很像，但又不完全一样。
MVP 更关心：“用户要不要？”
企业号代表的思路则是：
“我们最担心的那个假设，到底成不成立？”
我更愿意把它叫作“最小可验证系统”。
它不追求完整，不追求漂亮，甚至不要求最后能够直接投入使用。
它只负责一件事：
用尽可能低的成本，把最大的不确定性变成一个确定的答案。
企业号一生没有进入太空。
但它提前验证的那些答案，最终成为后来真正飞向太空的航天飞机能够执行任务的重要基础。
很多工程项目也是如此。
真正昂贵的，从来不是第一版做得不够完整。
真正昂贵的是，把一个未经验证的假设，完整地做了出来。
易浅小站
EACHEN STUDIO / ARTICLE END