2010年，SpaceX Dragon任务控制中心只有一个人负责训练团队。三年里，她埋头搭建操作流程，文档永远排在"稍后处理"的清单末尾。
直到公司需要扩张。接下来几个月，她被迫从记忆里挖掘那些本该被记录的细节：异常处理机制、任务启停节点、影响训练执行的数百个微小决策。运营债务的代价远超任何硬件返工，只是爆发得更慢。
本周NASA局长Isaacman在Ignition论坛宣布登月计划时，这段往事突然变得紧迫。美国要建永久月球基地，每半年两次载人着陆，2028年核推进火星演示——硬件蓝图清晰，但软件策略呢？
硬件狂飙，软件掉队
Isaacman的原话很直接：「请别为了脚印和旗帜重返月球。必须接上半个世纪前的进度，建基地，创造持久存在。」
愿景没错。NASA擅长的事也没变：指明私营市场无法自发凝聚的方向，召集60多个国际伙伴，押注代际赌注。但问题在于，雄心本身养不活月球基地。
阿波罗时代用4KB内存的计算机（AGC，阿波罗制导计算机）完成了登月。今天的猎户座飞船装了7500万行代码，是波音787的4倍。硬件迭代了50年，软件工程的方法论却还在原地打转。
作者亲历过这种撕裂。Dragon早期训练靠口口相传，文档是" overhead（ overhead，额外负担）"——直到规模扩张暴露了代价。NASA现在的处境更危险：商业载人、CLPS（商业月球载荷服务）、Gateway空间站、阿尔忒弥斯营地，四条线并行，每条都依赖不同的承包商生态。
月球软件的三种债务
作者把风险拆成三类。第一类是接口债务：SpaceX星舰、蓝色起源蓝月、SLS火箭、猎户座飞船，四家公司的飞行软件要对接NASA的任务控制系统。没有统一的数据标准，每次任务都是定制集成。
第二类是知识债务。阿波罗17号之后，美国失去了在月球表面操作的经验。现在的工程师要从零重建：月尘怎么处理？夜间-230℃的极端温度下设备如何休眠？这些答案分散在论文、退休工程师的记忆、以及从未被数字化的纸质档案里。
第三类最隐蔽：流程债务。NASA的认证体系为单次任务设计，阿尔忒弥斯却要转向"节奏性运营"——每半年一次着陆，像航班时刻表。旧流程撑不起新节奏，但改变流程比改变火箭更难。
作者举了个具体例子。Dragon训练后期，她被迫重建的不仅是文档，是决策逻辑——为什么某个异常要这样处理，而不是那样。月球基地的规模是Dragon的百倍，这种隐性知识如果不在建设初期固化，后期补课成本将指数级膨胀。
商业航天的悖论
Isaacman的计划高度依赖商业力量。CLPS要扩展到"激进"程度，让私营公司承担更多风险。这本身是进步——阿波罗模式太贵，不可持续。
但商业航天的强项是快速迭代，弱项是知识沉淀。SpaceX自己就是例子：星舰炸了再飞，从残骸里学东西，工程师的直觉比文档更重要。这种模式适合单一公司、单一产品，不适合多承包商协同的国家级基础设施。
作者没有否定商业化的意思。她明确说NASA"在做它最擅长的事"，也认可"最 capable（ capable，有能力）的商业航天生态"。但提醒了一个被忽视的变量：软件架构的公共品属性。
硬件可以竞争——你造你的星舰，我造我的SLS。但任务控制软件、数据标准、训练体系，这些是共享基础设施。如果每个承包商各自为政，NASA会变成最大的系统集成商，背负所有接口债务。
2028年的 deadlines（ deadlines，截止日期）陷阱
计划里有个关键节点：2028年核推进演示飞往火星。这个日期不是随便定的，是政治周期和预算窗口的产物。但作者警告，硬性截止日期会放大软件风险。
硬件可以赶工。软件不能——或者说，赶工的软件会在运营阶段反噬。Dragon的教训是，文档债务的利息在扩张期一次性清偿，痛苦但可控。月球基地的债务如果拖到人员驻留之后，代价可能是任务失败。
作者提了一个具体建议：NASA需要"软件战略"，与硬件计划并行。不是指写更多代码，是指建立跨承包商的知识管理体系、接口标准、以及适应节奏性运营的认证流程。
这听起来不够性感。相比核推进和月球基地，文档标准毫无视觉冲击力。但作者用亲身经历证明，运营债务的复利比硬件返工更致命。
Isaacman说"别为了脚印和旗帜回去"。作者补充：也别为了硬件里程碑回去。如果软件策略跟不上，月球基地会变成另一座国际空间站——昂贵、脆弱、依赖地面持续输血，而非真正自给自足的"持久存在"。
SpaceX早期工程师后来花了多久填补那三年的文档缺口？作者没提具体数字。但她说，那些被迫重建决策的夜晚，"比任何硬件重新设计都更昂贵"。现在，整个美国航天体系站在类似的岔路口——只是规模大了几个数量级，而时钟已经指向2028。
如果核推进演示如期发射，但任务控制系统还在用阿波罗时代的文档逻辑，我们会看到什么？作者没给答案，但问题本身已经悬在那里。
热门跟贴