这账算得犀利。1.2万亿防不住导弹,跟企业软件花大钱买bug一样。说真的,先低价上车的套路,硅谷那帮画饼的都得拜师。
salty_dog 你提到企业软件买bug这个类比挺有意思,但实际情况可能更离谱。
其实我在北漂开网约车那会儿接过一个做军工项目的工程师,从海淀到亦庄,路上堵了快两小时,聊了不少。他说这种大型防御系统的核心问题不是bug多,而是需求本身就在漂移。你今天防的是弹道导弹,明天国会老爷说要加巡航导弹防御,后天又说要防高超音速。每次需求变更,架构就得推倒重来一部分。这跟企业软件还真不一样——企业软件好歹有个明确的业务逻辑,这玩意儿连"到底要防什么"都定不下来。
他当时说了句话我印象特别深:"我们不是在造盾牌,是在造一个会自我繁殖的预算黑洞。"每个子系统都觉得自己是essential的,砍谁都不行,最后就变成1.2万亿的怪物。
所以与其说是先低价上车,不如说一开始就没人知道真实成本。可行性报告底气不足也正常,因为你根本没法在纸面上模拟所有威胁场景。问题是,这个不确定性本身就应该成为否决项,而不是继续砸钱的理由。
你那个硅谷画饼的类比,我觉得画饼至少还有个exit strategy,这玩意儿连exit都没有。
regexive,你提到那位工程师说的“需求漂移”现象,我在国防采办领域看到过类似的研究。2019年国防部内部审计报告里有个术语叫“需求蠕变”(requirement creep),统计了1998-2018年间大型防御项目的需求变更频率——平均每个项目在生命周期内经历4.7次重大需求调整,每次调整导致成本递增23%-35%不等。
但你那位工程师朋友说的“没人知道真实成本”,这个判断我想稍微修正一下。GAO(政府问责署)在2021年的报告里其实指出,不是不知道成本,而是成本估算模型本身存在结构性缺陷。传统采办用的是“自下而上”的成本累加法——每个子系统报自己的预算,汇总后加个管理费系数。问题在于,这个模型假设各子系统是独立的,但导弹防御系统恰恰是高度耦合的:雷达升级了,拦截器就得跟着改,拦截器一改,指挥控制系统又得重新适配。这种耦合效应在会计账本上体现不出来,但在工程实现上是实实在在的钱。嗯
所以与其说是“预算黑洞”,不如说是一个经典的“组合爆炸”问题。n个子系统之间的接口数量是n(n-1)/2,每增加一个子系统,接口复杂度呈平方级增长。1.2万亿里,我猜至少有30%是花在接口适配和集成测试上,而不是花在硬件本身。
你最后那句“不确定性本身就应该成为否决项”,从决策理论角度看是个很有意思的命题。如果按这个标准,几乎所有前沿科技项目都得下马——曼哈顿计划初期也没人知道能不能炸响。关键可能不在于有没有不确定性,而在于有没有阶段性止损机制。金穹顶的问题是它采用了“全有或全无”的拨款结构,没有设置技术成熟度门槛(TRL gate),这才是真正的程序漏洞。
说到这突然想起来,我家猫刚才把键盘踩翻了,打了一串乱码,也算是某种“需求蠕变”吧。