今年早些時候，我們 8090 團隊拆解了一個大型實體的計費引擎。它包含了 1,800 萬行的 COBOL 和組合語言，這些程式碼在我們某些工程師出生之前就已經開始累積。沒有人能完全理解它，但透過使用我們的 Software Factory，我們在 40 天內將其逆向工程轉化為超過 10 萬條的純英文規則。完成這項工作後，我意識到為什麼「軟體工廠」這個詞突然被所有人掛在嘴邊。
這個概念之所以被借用，是因為它暗示了一種企業渴望卻未能獲得的工業級可靠性。軟體工廠背後有五十年的歷史，其最獨特的特徵正是企業比以往任何時候都更需要的東西——一個保證產出的生產系統。這與人們對一整套賦能個人、卻讓整個系統變得更加混亂的工具所產生的日益增長的不滿形成了鮮明對比。
這個詞的歷史比多數人想的還要悠久
日立（Hitachi）在 1969 年成立了「Software Works」，這是一個名副其實的工廠：一棟建築物，在其中以統計品質控管的方式生產軟體，缺陷率以每千行程式碼計算，流程標準化，並且有管理團隊對產出品質負責。東芝（Toshiba）、NEC 和富士通（Fujitsu）隨後跟進，在 1970 年代和 1980 年代，這些日本軟體工廠交付了有史以來最可靠的程式碼之一。它們生產的系統為銀行、鐵路和電力基礎設施服務了數十年。
2004 年，兩位微軟架構師出版了一本名為《Software Factories》的書，主張軟體應該像汽車一樣被建造：使用經過驗證的組件，在可重複的生產線上進行，並透過預先設計來控制變異，而不是依靠後端的英雄式修復。美國空軍如今也在運作軟體工廠。Kessel Run 為國防部建置和運作任務軟體，當該軟體出問題時，他們會負責。
在 AI 浪潮來襲之前，六十年來有一件事始終保持不變。工廠從來不是一個工具或生產力技巧，無論它多麼優秀。工廠是一個生產系統，它接收輸入，產出成品，並為這些成品的品質負責。換句話說，福特（Ford）從來不賣給你一把扳手、一些零件，然後祝你好運。福特賣給你一輛車，如果車子有問題，福特會召回，因為那是他們的工廠生產的。
這就是標準，我認為現代的軟體工廠也必須遵守這個標準。
五項測試
一個軟體工廠應該通過五項測試。只要任何一項沒通過，它就只是別的東西。那個別的東西很可能是一個開發者工具，雖然有用，但它是不同的產品，有著不同的義務。
測試一：工廠始於商業意圖。 工廠的輸入是業務需求，以業務的語言來表達：需求、規則、法規限制、期望的成果。如果輸入的是一個工程師寫給另一個工程師的 Jira 問題單，那麼你看到的只是一個附加在現有流程上的強力工具。工廠的重點在於，客戶描述產品，而工廠負責找出生產方法。
測試二：工廠能在持續變動中維持一致性。 這是最困難的測試，也是目前 AI 工具市場上幾乎沒有人談論的，因為他們的產品反而讓情況變得更糟。
撰寫新程式碼從來就不是企業軟體的瓶頸。真正的瓶頸在於，一個真實的系統每週都會被幾十個人修改。每一次修改都是系統分崩離析的機會。需求偏離文件，文件偏離程式碼，程式碼偏離測試。讓這種偏離累積二十年，你就會得到我開頭描述的計費引擎：1,800 萬行沒有人能完全理解的程式碼，一個每年以 5% 到 8% 幅度漲價的供應商維護合約，以及一個再也無法在不恐懼的情況下更改自家軟體的組織。
現實是，程式碼生成會加速偏離。如果你的 Agent 根據未保持同步的規格產生十倍以上的程式碼，你就是在以前所未有的速度誘發偏離。那個 1,800 萬行的問題花了四十年用手工打造，但若沒有治理，一群 Agent 將在幾年內就建構出同樣的問題。
一個運作正常的軟體工廠會將意圖、規格、程式碼、測試和生產行為保持同步，作為一個單一的受管對象。更改需求，程式碼就跟著變。緊急修復程式碼，需求也會跟著更新。請供應商在真實系統上即時展示這個閉環。如果他們做不到，他們就是在賣程式碼生成工具。雖然它有用，但那是兩回事。
測試三：工廠的運作獨立於任何特定個人。 一個工具的好壞取決於使用它的人。把同一個程式碼 Agent 交給兩個工程師，你會得到截然不同的結果，這取決於誰寫提示詞、誰審查差異、誰抓出錯誤。這種變異在工具中可以接受，但在生產系統中卻是致命的。一個工廠應該以可預測的速度和品質進行生產，無論當班的是誰，這正是日立的統計控管機制所要保證的：品質是生產線的屬性，而非操作員的屬性。
工廠實現這一點的方式是，知識在系統中累積，而不是在個人身上。當新人加入時，工廠會把已經學到的一切交給他們。當有人離開時，沒有知識會流失。大多數企業軟體在這項測試上徹底失敗。計費引擎變得難以理解的原因不是程式碼寫得差，而是對程式碼的理解存在於人們的腦中，而隨著時間推移，人員會變動。如果他們的知識從未被系統捕捉，系統就會慢慢變成一個黑箱。
澄清一下，這不代表人不重要，也不代表工廠不需要問責制。一個工廠總是有特定的人為產出負責。只是它永遠不依賴於任何一個人是不可取代的。一個需要英雄才能運作的系統，既沒有問責制，也不是工廠。它只有英雄，而英雄最終總會尋找新的冒險。
測試四：每個產出單位都可追溯。 在真正的工廠裡，每個零件都有一個「批號」。當某個東西出問題時，你可以沿著生產線追溯到批次、機器和班次。受監管的行業對軟體也有同樣的要求，這就是為什麼他們在採用 AI 程式碼工具上最為緩慢。「模型寫的」不是審計員能接受的答案。一個軟體工廠會將稽核軌跡作為生產本身的副產品產出：這條規則之所以存在，是源於這個需求，經由這個人批准，在這次變更中實作，由這個測試驗證，並在這個時間部署。來源追溯必須內建在生產線中，這意味著事後撰寫的文件不算數。
測試五：有人要為最終產品負責。 這項測試區分了軟體工廠和開發者工具，因為這是大多數工具供應商不願意滿足的。
一個工廠出貨的產品，它會為其負責。當計費引擎算錯理賠金額時，當交易系統產生錯誤數字時，當製造驗證批准了不良零件時，必須有特定的人負責、修復它並承擔成本。我現在讀過很多 AI 工具合約，智慧財產權部分洋洋灑灑好幾頁，但問責部分通常只有一句話，而且那句話說的是，輸出是「按現狀」提供的，驗證是你的問題。這完全不符合工廠的資格。
我們的一位客戶，一家上市的健康保險公司，將其應付理賠規則轉換為確定性的預過濾器，將轉給按件計酬供應商的理賠案件減少了 80% 以上，在四年內避免了超過 2,000 萬美元的支出。只有當執行工作的一方對結果負責時，才能達成這樣的數字。
什麼不是工廠
用這些測試來檢驗，許多自稱為工廠的，其實是別的東西。
程式碼 Agent，無論多優秀，都只是工具。它們以工程任務為輸入，產出程式碼，並將所有驗證和責任轉移給客戶的工程師。即使把一群 Agent 稱為工廠，也無法改變這一點。
Agent 編排儀表板是監督工具。它們讓觀察 Agent 工作變得更簡單。
基準測試是工具的測量工具。高分告訴你一個工具在基準任務上表現良好，但無法告訴你，在由人類和 Agent 組成的混合團隊進行兩年持續變更後，你的系統是否還能保持一致性。
為什麼這個定義現在很重要
生產軟體的成本正在急遽下降。當生產成本崩跌時，價值將轉移到能夠保證產出的一方。這在之前的每一次工業化過程中都發生過，現在在 AI 領域也會再次發生。
那些搶著抓住「工廠」這個詞的新創公司，直覺上明白這一點。但許多公司只是為了獲取工業生產的可信度，卻不願接受當初創造這種可信度的義務。
所以，忽略演示和基準測試，向每個軟體工廠問一個問題：當系統在生產環境中出問題時，誰來接電話？
對於一個軟體工廠來說，答案必須是「我們來接」。
