我於2006年創立Software Tailor。十九年來，公司經歷了四個不同的經濟週期，服務了六家涵蓋製藥、金融、政府、法律、國防及能源的《財富》全球500強客戶，自2007年起零項目失敗。最後這個數字是投資者和採購審查員最常詢問的，也是唯一需要解釋的。以下是支撐這項紀錄的四條工程規則。
規則一：單一交付模式，無服務與產品模糊
每個Software Tailor項目均採用相同的交付模式——一個範圍嚴謹的試點階段，交付可運作的軟件，然後由客戶決定是否基於交付成果擴展資金。我們沒有分開「服務」實踐按需求文件交付，和「產品」實踐按路線圖交付。兩者會互相衝突，其中一方必然會補貼另一方。
單一模式意味著每位工程師在開始前都清楚「完成」的標準。這是避免失敗的先決條件。
規則二：客戶群紀律 — 僅限我們能交付的客戶
我們的客戶群是經過篩選的，而非機會主義。十九年服務六家《財富》全球500強客戶，並非銷售管道緩慢，而是有意識的選擇標準。每位客戶在啟動前必須通過三項測試：他們的問題是我們曾解決過的；他們的內部贊助人是軟件的最終使用者（非中間層）；他們的硬件/數據環境允許我們交付，無需六個月的採購延誤。
未通過任一測試的客戶會被轉介給其他人，而非成為項目。這條規則最常令我們損失收入，也是十九年來零例外的規則。
規則三：工程紀律對應公認框架
早於AI風險管理擁有專屬框架之前，我為Software Tailor制定的工程規則已與其模式相符：管理工作、識別風險、衡量結果、管理變更。NIST AI RMF 1.0於2023年正式化該模式，2026年4月的關鍵基礎設施配置文件將其擴展至受規管行業。閱讀這些文件，我們的內部紀律與四大功能完美對應。
這帶來的好處是：每個項目均可根據外部框架進行端到端審計，而非僅依賴我們自身習慣。當採購團隊詢問試點階段範圍如何決定時，答案與NIST風險管理的解釋一致，且客戶的合規團隊已內化該詞彙。
規則四：可記錄、可恢復、可重建
第四條規則早於我們現用於AI Suite的審計追蹤詞彙。每個Software Tailor項目均處於一種狀態，任何決策、任何產物、任何代碼版本均可從版本控制的輸入中重建。這對軟件工程而言並不罕見；不尋常的是我們將此應用於 項目，不僅是代碼庫。衝刺決策、範圍變更、客戶簽核——全部記錄，全部可恢復。
這種紀律正是我們的 無內容審計日誌 方法能讓 AI Suite 如此發佈的原因。審計行模式與我們已應用於專案的模式相同。詞彙借鑒自合規框架；實踐借鑒自我們的交付方式。
延續至 AI Suite 的
本地 AI Suite + AI Admin Console 系列——請參閱 為何我們將 AI 以可安裝二進位檔形式發佈，而非雲端 SaaS ——是將相同的工程紀律應用於產品線，而非定制專案。相同的單一交付模式（桌面安裝程式附帶免費一週試用）、相同的客戶群紀律（受監管行業且有明確數據駐留限制）、相同的框架映射（NIST AI RMF + 歐盟 AI 法案部署者義務）、相同的可記錄、可恢復、可重建的審計態勢。
自 2007 年以來零專案失敗並非口號，而是少數規則無一例外地被嚴格執行的結果。這些規則現在同樣管控 AI Suite 的構建。
參考資料
- NIST。《AI 風險管理框架（AI RMF 1.0）》。 https://www.nist.gov/itl/ai-risk-management-framework。存取日期 2026-07-15。