在确保系统稳定的前提下开发创新软件

多年来，学术界和企业界一直将学生引导至两大阵营。其中一类学生学习的是构建惊艳消费级技术的技能，其成果大多体现为智能手机上的各种应用。另一类开发人员则专注于创建企业级（B2B）商业应用，这些应用大多部署在云端。

遗憾的是，无论是消费级还是企业级开发人员，他们所积累的经验都无法直接套用到任务关键型（Mission-critical）应用领域。在这些系统中——例如高级驾驶辅助系统（ADAS）、医疗手术设备以及通信卫星——失败是绝对无法容忍的。

想想硅谷那句“快速行动，破旧立新”的信条。其合理的初衷是：研发团队应当不断迭代，尝试新事物，从错误中汲取教训，并在每一次迭代中寻求进步。

敏捷开发实践通过逐步累积的方式增加经过严密测试的功能。但“快速行动，打破常规”这一信条则暗示，为了创新而犯错或颠覆技术是值得的，而不是为了稳妥而保持缓慢、平稳的节奏。这一信条影响了整整一代软件开发人员，让他们觉得速度高于稳定性。它宣扬一种观念：相比于构建长期稳定的系统，变革永远是件好事。而且，整个行业生态系统都在为这种开发模式推波助澜。

再来看看杰夫·贝佐斯（Jeff Bezos）著名的“API 宣言”。二十年前，贝佐斯强制要求亚马逊所有的内部系统必须通过 API 对外开放数据和功能。这一举措对亚马逊云服务（AWS）的创立和成功至关重要，但它同时也培养了一批新的开发者，让他们习惯于在拥有近乎无限资源的云端环境下构建系统。

现在，将这两大趋势结合起来看：绝大多数开发者在职业生涯初期，都默认代码编写是不受任何约束或限制的。他们坚信可以动用整个云端的力量来支撑应用，并默认获得了“快速行动，破旧立新”的许可。

这些前提在开发消费级移动应用或企业级信息技术项目时行之有效，但对于那些绝不允许出错的系统构建者来说，这简直是行业大忌。

任务关键型应用的不同之处

任何项目都会受到硬件条件和预算费用的制约。但“任务关键型”软件有着更为特殊的需求，而这些需求往往与上述两种开发模式背道而驰。

大多数云端 B2B 应用和消费级软件都可以定期更新。然而，对于在低带宽或有限存储环境下运行的边缘计算设备，推送修复补丁的可行性极低。在针对医疗器械、便携式 POS 机和远程传感器等硬件进行设计时，开发者必须通盘考虑存储空间、重量、功耗以及工作周期等因素。这类设备显然无法拥有云端那种近乎无限的算力，也无法保证网络连接的绝对稳定性。

这类复杂系统的项目周期通常很长，从设计到正式发布往往耗时数年。到产品上线时，最初选定的硬件可能已经落后了几代，因此系统设计必须具备极强的适应性，以确保不被时代淘汰。

任务关键型系统通常需要通过严苛的安全测试和其他合规认证，以确保在极端恶劣的情况下仍能完美运行。任何改动或更新，哪怕再微小，都可能面临重新认证的流程。

迭代开发模式在这些领域确实可行，但其所谓的“快速”与传统互联网行业的节奏完全不可同日而语。一款监测血糖的消费级 App 可以在必要时每天更新，但用于手术的病人监护设备绝不可能如此频繁变动。此外，开发者习以为常的“无限云端存储”，对于那些必须在断网环境下也能正常工作的设备来说，几乎从不是一个选项。

AI 使事情变得复杂

任务关键型系统必须保持运行的一致性与可预测性。在输入相同且初始条件一致的情况下，应用程序应当始终产生相同的输出。

任务关键型应用程序必须能够察觉空中更新（OTA）带来的变化。软件的更新会改变其原始配置，导致安全验证失效。自 OTA 更新出现以来，这始终是一项挑战，但经验丰富的嵌入式系统开发人员已经相应地调整了他们的流程。

而 AI 本身就不具备确定性——并且其不确定性还将日益增加。

想要一个实际的例子吗？试着向 ChatGPT 提出一个问题，两天后再问它完全相同的问题，观察答案是否会改变。有时会变，有时则不会。在默认情况下，由于受到各种变量、刺激因素以及不同排列组合的影响，大语言模型的设定并非以确定性的方式运行。因此，集成到任务关键型应用中的 AI 也必须能够适应这种变化。

这使得开发工作——以及旨在对其性能提供保障的法规和认证——变得更加困难。

构建第三条路径

那种追求快速迭代并充分利用无限云端算力的开发方式并没有错，也没有过时。正是这些方法推动了我们在特定行业中所见证的创新。但随着智能向边缘端转移，以及机器变得更加智能、更加自主，业界将日益需要一种“第三类”系统开发方法——在这里，可靠性与稳定性是核心准则。那些能够在这些环境中实现创新的组织，将成为下一批市场领军者。