软件错误通常让人联想到宕机、错误操作或数据遗失，但你知道吗？在1980年代，一个医疗设备的程序漏洞不但没有被即时发现，甚至造成至少三人死亡、六人严重受伤，成为全球公认最早的致命软件Bug事件。
这起灾难的主角，是一款名为Therac-25的放射治疗机。这部机器原本是为了治疗癌症病患而设计，却因设计上的重大疏忽，造成了史上罕见的医疗灾难。
Therac-25在1983年问世时被誉为创新之举，因为它结合了两种治疗模式：
电子束疗法：适用于皮肤癌等浅层治疗
兆伏特X射线疗法：用于深层肿瘤照射
这两种疗法需要不同剂量与能量输出，但如果混淆模式，后果将非常严重。
为了精简设计，Therac-25放弃了前代机型常用的“硬件机械互锁设备”，完全依赖软件控制。换句话说，一旦程序出错，就没有实体设备能阻止错误发生。
根据加州州立大学硕士研究生Anne-Marie Poretto的报告，这起软件漏洞其实来自一个经典的“竞态条件（race condition）”：当操作人员快速变更治疗模式时，软件尚未完成前一举令的运算，下一个指令已被送出，导致错误堆栈与防护失效。
例如：
操作员误选了电子束模式，接着迅速更改为X射线模式
软件仍处于上一笔操作流程中，导致两种模式混合
电子束屏蔽未启动，病患因此直接暴露于高强度辐射下
这样的Bug曾在1985至1987年间至少造成六起事故，其中三位患者当场或数天内死亡，另三人重伤、留下永久伤害。
制造商AECL（加拿大原子能公司）最初否认系统有问题，反而归咎于操作人员。直到1986年，美国FDA（食品药物管理局）正式介入调查，才披露真相并要求全面停机整改。
最终，Therac-25被全面停用，成为医疗设备历史上的警世教材。
这起事件之后，医疗设备界与计算机科学领域都重新审视“软件就是安全核心”的概念。Therac-25成为促成以下改革的契机：
所有医疗软件需进行形式化验证（formal verification）
必须保留硬件层级的安全保护机制
强化用户操作界面的错误防护设计
撰写清楚完整的错误记录与文件
Therac-25的故事提醒我们，在医疗、交通、核能等高风险领域，软件错误不是小事。再精密的AI系统与自动化设备，都需要经过重重验证与交叉防护，才能避免悲剧重演。
