Artemis II把发射窗口藏进代码

2025年11月到2026年4月，NASA给阿尔忒弥斯2号（Artemis II，美国重返月球的载人绕月任务）留了整整6个发射窗口。每个窗口短则2天，长不过10天，错过就得等明年。但NASA官网只给了一张静态表格，工程师查一次要翻三层页面，还要手动比对月球轨道参数。

一位程序员花了周末两天，把6个窗口、24个关键时间点、3种轨道约束条件，全塞进了一个自动更新的追踪器里。上线当天，Hacker News 顶帖区炸了——不是夸界面多好看，而是在争论「NASA为什么自己不做个这」。

从PDF表格到实时追踪，中间隔着一个周末

这个追踪器的核心逻辑并不复杂。NASA公开的《Artemis II Mission Availability》PDF里，发射窗口由三个硬约束决定：地月转移轨道（TLI，Trans-Lunar Injection）的照明条件、溅落区白昼时长、以及服务舱推进剂温度阈值。程序员用Python扒了PDF里的时间戳，对接了JPL（喷气推进实验室）的星历API，再套了个前端框架。

真正的工作量花在「翻译」上。 NASA工程师用轨道力学语言写约束条件，比如「TLI必须在月球升交点经度λ=120°±15°时执行」。追踪器把它转成了人话：「11月22日凌晨2:17，佛罗里达上空，发射台能看到月亮刚从地平线爬起来」。

上线后48小时，追踪器捕获了第一波真实用户：航天博主、STEM教育从业者、以及至少两位NASA承包商的员工——他们在评论区认领了身份，顺便吐槽内部工具还没这个好用。

为什么官方不做？一个组织惯性样本

Hacker News 热评第一问了那个显而易见的问题：「NASA有预算造火箭，没预算做个网页？」

答案藏在NASA的信息架构里。阿尔忒弥斯计划由马歇尔航天中心主导发射窗口计算，但对外发布归肯尼迪航天中心管，公众沟通又由总部办公室负责。三个部门用三套系统，PDF是唯一的「最大公约数」。做个实时追踪器需要跨部门数据接口，而NASA的IT采购流程，按一位前员工的说法，「给服务器装个新硬盘都要走14天审批」。

更深层的原因是受众错配。NASA的公开数据首要服务对象是专业社区——其他航天机构、学术研究者、承包商工程师。他们习惯读轨道参数，不觉得PDF有什么问题。直到这个追踪器出现，才暴露出一个被忽视的需求层：每年数百万关注航天进展的普通公众，以及需要可视化素材的教育工作者。

追踪器的创作者在README里写了一句挺损的备注：「如果NASA想要这个域名，我可以转让。条件是送我一张发射现场门票。」

开源之后，意外成了「影子官方渠道」

代码托管在GitHub，MIT协议。但真正让它出圈的是两个衍生功能：邮件提醒和iCal订阅。

用户输入时区后，追踪器会在窗口开启前72小时发通知。这个功能直接抄了SpaceX发射追踪器的作业——后者由粉丝社区维护，已经成了航天爱好者的标配工具。区别在于，SpaceX的发射计划变动频繁，社区工具被迫进化出了实时性；NASA的窗口提前数年确定，反而让「官方更新滞后」的问题暴露得更彻底。

iCal订阅则踩中了一个精准场景。一位高中物理老师在评论区说，她把发射窗口同步到了学校日历，「学生问什么时候能看直播，我再也不用翻NASA官网了」。这个反馈被创作者置顶，成了项目事实上的使用说明书。

到第三天，追踪器的访问量曲线出现了一个小尖峰——对应NASA突然调整了一个窗口的备用日期。官方PDF更新了版本号，但社交媒体还没动静。追踪器因为自动抓取，成了最早反映变动的公开渠道之一。评论区有人半开玩笑：「现在压力给到NASA公关部。」

一个工具背后的权力让渡

这个案例的有趣之处不在于技术难度。用现代开发工具，一个中级工程师两天做出MVP（最小可行产品）是基操。值得玩味的是权力关系的微妙转移：当官方渠道的信息形态落后于用户预期时，民间工具会自发填补空缺，甚至反向成为信息源。

NASA不是没能力做，而是组织目标里没有「公众实时追踪」这个KPI（关键绩效指标）。它的公开数据是合规动作，不是产品思维。但当一位程序员用周末时间证明了这个需求真实存在，且愿意为之付费（邮件服务的API成本），它就变成了对官方叙事的一种温和挑战。

追踪器的最后一行代码是个注释，引用了一位阿波罗时代飞行主管的话：「失败不是一个选项。」下面跟着创作者自己的补充：「但错过发射窗口是。」

现在打开这个追踪器，倒计时组件显示距离第一个窗口还有147天。问题是：当官方数据和民间工具并排摆在你面前，你会信哪个先更新？