工程思維 × 知識管理

用 AI 做決策這件事，其實是火箭工程的延續

從挑戰者號到多模型投票機制——容錯從電路搬到了語言層

Mr. τ／風雲網通系統  |  PCPiLOT 知識管理實驗室

最近在收斂一個客戶專案的解決方案規格時，我刻意做了一個設計上的決定：

不再依賴單一 AI 給答案，而是同時讓 3～4 個模型互相審查、主動挑錯、填補盲點，最後才收斂成可以落地的方案。

這件事乍看像是「AI 工具的用法選擇」，但它其實更像一個老到不能再老的工程問題：如何避免關鍵系統在最後一刻因為「大家都同意」而悄悄崩潰。

1986 與 2003：不是技術失誤，是裁決機制失敗

挑戰者號（1986）與哥倫比亞號（2003）的兩場災難，事後復盤都不是單點錯誤，而是暴露出同一種結構性缺陷：

真正的問題不是火箭的材料或設計，而是：錯誤被系統性地放行了。決策系統說服了自己「這次應該也沒事」。

火箭工程早就給過答案：TMR 三模冗餘

阿波羅任務與土星五號時代的導航電腦，採用了一個當時極為硬派的工程解法——TMR（Triple Modular Redundancy，三模冗餘）：

機制	說明
三套獨立系統	同時計算同一個問題，彼此不知道對方的答案
硬體投票裁決	少數服從多數，異常值直接被隔離
無 rollback 設計	太空中沒有重試機會，容錯必須在決策當下完成

這個設計的核心哲學不是「讓系統更聰明」，而是：假設任何單一系統都可能出錯，所以在架構上就不允許它單獨做最終裁決。

現在的 AI，重新打開了同一個問題

單一大型語言模型的問題不在於能力不足，而在於它有幾個結構性弱點：

這些弱點，幾乎跟 1986 年那次裁決機制的問題一模一樣。

所以我現在的做法，本質上是把 TMR 軟體化，把容錯從電路板搬到語言層：

角色	任務	對應 TMR 概念
模型 A	提出架構與初稿	計算單元 1
模型 B	主動攻擊、找漏洞、提出反例	計算單元 2（獨立驗證）
模型 C	約束條件與可行性收斂	計算單元 3
模型 D	讀取前三者分歧，做最終共識裁決	投票裁決器（Voter）

這不是「多問幾個 AI 看誰答得好」，而是在流程架構上刻意建立決策冗餘——讓任何單一模型都無法在沒有挑戰的狀況下獨自決定最終答案。

本質其實沒有變

從火箭導航到 AI 決策，底層邏輯一直都是同一件事：

差別只在於：我們把「容錯」，從電路搬到了語言層。工程問題的形式變了，但人類需要在高風險決策中建立異議機制的需求，從來沒有消失過。