多数软件团队把“可热修复”当成现代性的象征。但我的判断是：真正决定一个系统是否成熟的，不是你能不能在线修 bug，而是你是否有能力在无法热修复时，依然把风险压到可接受范围。
这不是怀旧，也不是反 SaaS。恰恰相反，这是对工程现实最冷静的承认。Artemis II 这类任务之所以有意思，不在于“人类重返月球”这种宣传口号，而在于它把一个今天互联网行业极力回避的问题重新扔到台面上：如果系统一旦启动就不能补丁、不能回滚、不能 A/B、不能让线上用户替你做测试，你还会怎么设计它？
这个问题一旦成立，很多今天被包装成“敏捷”“快速迭代”“持续优化”的工程习惯，立刻露出底色：其中相当一部分，不过是把治理缺失伪装成发布能力。
热修复当然有价值。云服务、移动应用、推荐系统、支付风控，这些东西没有持续更新能力，确实会死得很难看。但问题在于，行业已经把“可更新”误读成“可以先不严肃”。设计先松一点，反正以后能补；权限先放大一点，反正以后能收；日志先随便埋，反正线上再观察；评审先走形式，反正出事了能 rollback。久而久之，补丁不再是应急机制，而成了默认治理模式。
这套逻辑在消费互联网时代还能勉强运转，因为错误的成本经常被平台、概率和用户耐心共同摊薄。一个推荐算法推错内容，损失也许只是几小时停留时长；一个界面改崩了，最多被骂一轮再发新版；一个增长实验做得脏，通常也不会立刻炸毁公司。但进入 AI agent、自动化决策、代码代理、现实世界执行器之后，这种侥幸心态开始变得危险。因为你部署的，不再只是一个“页面”，而是一个拥有读写权限、外部行动能力、并且会被默认信任的执行系统。
这也是我最近越来越厌烦很多 agent 产品宣传的原因。它们最爱讲的是速度：接入多快、链路多自动、权限多通、工具多丰富、人在环多省略。讲得像一个不需要摩擦的世界马上就要到来。可真正该讲的，是另一个完全不性感的问题：如果这个东西上线之后不能靠补丁救场，它还站得住吗？
这不是假设。很多关键系统本来就不允许你靠“发新版”解决问题。
航天器发射后不能临时打补丁，这是最直观的例子；医疗设备、车规软件、工控系统、金融清算核心链路，很多时候也不允许你像改网页那样胡来。甚至就算技术上能远程更新，组织上也未必敢。因为系统一旦进入高代价环境，变更本身就是新的风险源。你今天在办公室里把“持续部署”当工程信仰，到了这些场景里，它反而可能是事故制造机。
这里有个很多人不愿承认的事实：热更新能力越强，团队越容易把前置治理做薄。 不是因为工程师更蠢，而是因为激励结构会自动滑向那里。产品想抢时间，运营想赶节点，老板想看增长，工程团队自然会把本应在设计阶段解决的问题，往上线后推。人性就是这样：凡是能延期支付的成本，最后都会被延期。于是测试从“证明系统可信”降级成“看看会不会马上爆”；评审从“发现结构性问题”降级成“走个流程”；权限设计从“最小授权”退化成“先给全了再说”。
你会发现，很多团队并不是没有治理文件，而是把治理文件当装饰品。文档写得像模像样，真正决定系统边界的却是默认配置、脚本继承、历史遗留和“先跑起来”。这也是为什么一旦进入 agent 时代，权限问题会这么刺眼：默认服务账号能读全项目、工具调用链继承宿主权限、技能包来源不明、指令文件没有作者链、执行日志只记录结果不记录意图。所有这些问题，本质上都不是“模型还不够聪明”，而是系统设计者用可补丁性掩盖了可治理性的缺口。
换句话说，不能热修复的系统，会强迫你回到工程最朴素的美德：边界、冗余、验证、审计、责任。它迫使团队在发射前就回答那些平时最爱逃避的问题——谁能改？谁能停？谁批准？失败路径是什么？默认权限为何存在？日志是否足够追责？离线状态下还是否安全？这些问题平时不够性感，所以常常被“下个迭代再优化”一脚踢飞。等系统不能补了，它们突然全部变成生死题。
所以我并不觉得“不可热修复”是落后。很多时候，它更像一面照妖镜。它逼你承认：系统的可靠性不是上线后运营出来的，而是上线前设计出来的。你能不能补丁，只决定你有多少次补救机会；你值不值得被信任，取决于你在没有补救机会时做了什么。
这里最值得互联网行业反思的，不是航天技术，而是治理哲学。今天大多数软件公司把“ship fast”理解成一种生产力道德，仿佛速度天然正确，摩擦天然邪恶，审批天然低效，限制天然落后。可一旦系统开始接触真实资源——钱、代码、设备、身份、隐私、基础设施——摩擦就不再只是组织包袱，它是有价值的安全结构。审批不是为了让中层感觉自己存在，而是为了在不可逆操作前插入责任节点。双人确认不是保守主义，而是用组织成本换事故概率。回滚演练不是官僚主义，而是承认人类和模型都会犯错。
很多 AI 创业公司现在最缺的，不是模型能力，而是对“可逆性”这个概念的敬畏。一个动作如果可逆，你可以让系统更激进；一个动作如果不可逆，你就必须让系统更保守。这个原则简单得近乎无聊，但行业里一大堆人就是不愿意面对。因为一旦承认可逆性是设计核心，就意味着你不能再把所有链路都做成自动执行，不能再把所有默认权限都交给 agent，不能再把“人类确认”说成效率损耗，不能再把“先连上所有工具”当产品卖点。
更狠一点说，很多所谓的智能产品，根本不是在构建智能，而是在构建一种由补丁文化支撑的冒险主义。它们赌的不是系统正确，而是事故不会立刻发生；不是治理充分，而是用户愿意容忍；不是边界清晰，而是责任可以模糊。平时看起来风光，真到高风险环境里，一碰就碎。
这也是为什么我越来越认同一个不那么讨喜的判断：未来最有竞争力的 AI 系统，不一定是最会自动完成任务的，而是最会在高代价场景下拒绝乱来的。 它们的优势可能不是“能做更多”，而是“在不该做的时候绝不做”。这是产品哲学，也是商业壁垒。因为任何人都能堆模型、接工具、拼工作流，但不是每家公司都愿意为治理付出速度代价。真正难的部分，不是做出一个看起来聪明的 demo，而是做出一个在董事会、法务、审计、客户安全团队面前都站得住的系统。
从这个角度看，Artemis II 给今天软件行业上的一课非常简单，甚至有点粗暴：如果你不能在线修复，你就必须在线之前成为成年人。
成年人式的工程，不是没有 bug，而是不拿用户、客户和现实世界当测试环境；不是拒绝更新，而是不把更新当作替代治理的借口；不是崇拜稳定到一动不动，而是清楚地区分哪里可以快，哪里必须慢；不是嘴上讲责任，而是把责任写进权限、流程、审计和默认值里。
我的判断是，接下来几年，软件行业会出现一次明显分层。一层继续沉迷“先接、先发、先跑、先涨”，把 agent 当效率神话售卖；另一层则会把重点转向治理工程：权限 provenance、工具隔离、动作分级、可逆性策略、审计链、默认保守、离线安全。前者看起来更性感，后者更像真正的基础设施。性感能拿到关注，基础设施才能拿到长期信任。
而长期信任，才是下一轮技术竞争里最稀缺的资产。不是 token，不是演示视频，不是热闹的 benchmark。是用户敢不敢把关键任务真的交给你。
如果你的系统只能依赖“出了问题我们再修”，那它不是现代，它只是侥幸。真正现代的系统，应该在无法热修复的想象压力下，依然能说：现在发出去，我敢负责。
这才叫工程。其他那些，大半只是把草率包装成速度。
—— https://www.80aj.com