「應該自建還是外購？」這個問題困擾了技術領導者數十年。但在AI時代，這種非此即彼的思維方式已經顯得危險且不合時宜。如今，企業平均同時推進十個AI計劃，其中43%的企業同時運行五到十個——在這樣的規模下，採購策略一旦失誤，代價前所未有地高昂。
多年來，我以解決方案架構師的身份，輾轉於核心銀行平台、雲原生基礎設施，到如今的組合架構領域，親眼目睹了企業在這一問題上的掙扎。現實是，大多數企業不需要選定一條路線，他們需要的是一個「光譜」。「買、建、混合」框架超越了傳統的二元對立，提供了我所見過最清晰的思維模型，幫助架構師思考這個問題。
傳統的買與建二分法暗示了一條清晰的邊界：要麼購買商用現成軟件（COTS），要麼自己動手開發。但在實踐中，這條邊界幾乎已經不存在了。從純粹配置COTS產品到從零開始構建自定義應用之間，存在著一整個選項光譜：通過市場插件擴展供應商產品、用低代碼或專業代碼構建自定義集成、在相關應用之間創建自動化和連接器，以及——越來越普遍地——在已購買的平台上構建AI代理和自定義用戶界面。這個「混合地帶」正是當今大多數企業實際工作發生的地方，它恰好對應著從無差異化到差異化業務能力的光譜。架構層面的含義很直接：將你的工程能力留給真正能讓你脫穎而出的能力，其餘的交給供應商生態系統。
在深入探討AI特定的考量之前，值得先錨定五個應該驅動所有應用採購決策的因素，因為它們在AI場景下的重要性有增無減。第一個是關鍵性與商業價值——這項技術是你的核心價值主張，還是解決業務問題的工具？如果AI是你產品的核心，天平就會大幅傾向自建。如果它只是運營改進，購買或混合可能更為合理。第二個是風險與內部能力，這迫使你誠實地評估知識產權暴露和供應商鎖定風險，同時坦率地審視你的組織是否真正具備構建和維護所計劃方案的技能。在AI領域，這個問題尤為尖銳——人才市場競爭異常激烈，擁有幾名數據科學家和擁有生產級ML工程能力之間的差距是巨大的。
第三個因素——總擁有成本（TCO）——是企業最常自欺欺人的地方。任何應用的TCO都橫跨四個階段：上線成本（設計、開發、測試、初始許可證費）、年度經常性成本（包括經常性的運營/支持和非經常性的維護）、未來成本（運營成本變動、可預見的升級、潛在的增強）以及退役成本（尤其是數據保留）。我見過太多自建決策，僅僅是拿初始開發成本與多年許可費用相比較就草草通過，而刻意忽略了持續維護、適應性維護以及最終退役的負擔。第四個因素是合作夥伴的能力——他們的執行力和願景的完整性——在AI供應商從研究階段的初創公司到超大規模雲平台的市場中，這一點至關重要。第五個是機會：你是否將內部產能部署在最高價值的工作上，還是在供應商早已大規模解決的問題上消耗精力。
如果框架傾向於為無差異化能力選擇購買，那就值得理解為什麼企業仍然猶豫不決。關於COTS挑戰的調查數據揭示了一個耐人尋味的故事。排名前三的擔憂——供應商鎖定（15%）、集成問題（14%）和有限的定制能力（13%）——本質上都關乎控制權和靈活性。緊隨其後的——隱藏成本、對更新缺乏控制、安全顧慮——進一步強化了同一主題。對架構師來說，這是一個熟悉的模式。COTS承諾的是速度和減輕工程負擔。現實卻是，你只是在用一組問題（構建和維護軟件）換取另一組問題（集成複雜性、供應商依賴和靈活性降低）。問題不在於哪組問題更小——而在於你的組織更擅長管理哪一組。
具體到AI，決策框架變得更加豐富。CIO在選擇買、混合還是建時，需要權衡九個重要因素。前三個是戰略性的：外部差異化（這項AI能力是否能讓你從競爭對手中脫穎而出？）、合規性（解決方案能否滿足監管要求？）和安全性（風險影響是什麼？）。接下來三個與生態系統相關：供應商生態系統的成熟度、數據來源及其對模型準確性的影響、以及可用技能。最後三個是經濟和運營層面的：短期實施成本、長期維護成本、以及對員工的影響。這個框架之所以強大，在於它承認這些因素的權重會因戰略意圖的不同而變化——而這正是「防守/延伸/顛覆」分類法真正發揮價值的地方。
這個框架中最具可操作性的洞察，是按戰略意圖對AI用例進行三分類。「防守」型用例旨在維持競爭平衡——想想用競爭對手也在採用的工具來增強個人生產力。對於這類用例，偏向應該強烈傾向從已有供應商購買嵌入式AI，因為目標是快速可靠地交付通用能力。這裡的決策本質上是一系列關於現有供應商能否處理該用例的「是/否」問題，在大多數情況下，答案應該有利於現有供應商。最小化定制，利用現有的供應商關係，然後把精力投入到更高價值的問題上。
「延伸」型用例旨在差異化——轉型流程或團隊以創造競爭優勢。在這裡，買/混合/建的決策變得真正複雜。「這是否提供了超越輕微差異化的價值？」和「自建的前期成本是否因擺脫未來供應商漲價而值得？」這樣的問題沒有簡單的答案。框架中頻繁出現的「是，但是…」回答本身就很說明問題。它承認延伸型決策本質上是情境化的，需要審慎判斷而非公式化的答案。
「顛覆」型用例旨在破局——創造新的價值主張、產品或市場。對於這類用例，框架傾向於混合或自建，但有重要的附加條件。上市速度可能仍然可以作為暫時購買的理由，供應商擁有你無法複製的數據可能使混合成為必要，而在陌生地區的合規和安全要求可能要求供應商合作。關鍵洞察是：即使對於顛覆性的AI計劃，純粹自建也很少是最優選擇。
將企業AI技術棧可視化的最佳方式之一是將其想像成一個分層的三明治。底層——你的集中化數據和自建AI——在你的控制範圍內。頂層——外部數據和來自供應商產品的嵌入式AI——在你的控制範圍之外。信任、風險和安全管理（TRiSM）以及自帶AI（BYOAI）處於中間，在你擁有的和你消費的之間起著調節作用。對企業架構師而言，這轉化為一個實用的設計原則：投資於堅實的基礎（數據基礎設施和治理），構建保護層（TRiSM），並有意識地決定哪些AI能力自建、哪些外購。能正確處理這些分層的組織，將是那些能夠吸收AI創新快速步伐而無需不斷重構技術棧的組織。
這一切還有一個有趣的成熟度維度。高成熟度組織採用混合供應商管理策略的可能性是低成熟度組織的三倍（33%對11%）。低成熟度組織壓倒性地默認採用集中式方法（61%），而高成熟度組織在集中式（41%）、分散式（26%）和混合式（33%）之間分佈更為均勻。這表明，隨著組織在AI方面日趨成熟，它們自然會從一刀切的供應商策略轉向更為細緻、因地制宜的方法。這與我在實踐中的觀察一致：早期AI採用受益於集中協調，但在企業範圍內擴展AI則需要在保持護欄的同時賦予業務單元更多自主權。
架構師還需要直面一個採購現實。近期90%的軟件採購都包含了GenAI功能，但只有25%的受訪者認為他們在這些採購中獲得了高質量的交易。這個差距揭示了當前的市場動態——GenAI正被捆綁進幾乎所有產品中，但買家在評估價值和有效談判方面舉步維艱。對於參與採購諮詢的架構師來說，這意味著需要對供應商推銷中的GenAI組件施加額外的審查。這些AI功能是否真正對你的用例有用，還是為了證明溢價合理而打的勾？供應商的AI是否真正利用了你的數據來交付差異化的成果，還是任何競爭對手都能獲取的通用能力？
如果要將所有這些提煉為對架構師同行的實用指導，我會這樣說。首先，將每個AI計劃分類為防守、延伸或顛覆。僅這一步就能通過為每個計劃建立正確的默認傾向，大幅簡化你的採購討論。對於防守型計劃，抑制過度工程化的衝動。你的現有供應商幾乎肯定會添加你需要的能力，而引入新供應商的集成成本很少能證明邊際改進的合理性。對於延伸型計劃，投資於「混合」能力——低代碼定制、API集成和連接器架構——讓你能夠將供應商平台與專有邏輯結合起來。這正是你的架構實踐增加最大價值的地方。對於顛覆型計劃，對你組織的準備程度保持無情的誠實。顛覆性AI的數據、技能、合規和安全要求是巨大的，低估它們是通往昂貴失敗的最快捷徑。而對於所有三種類別，在承諾走上某條路之前，都要對完整的TCO建模——包括退役成本和數據保留。最昂貴的決策，是你不得不推翻的那個。