標準化基礎設施，而非工具

資料來源#

• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers
• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot
• September 2026 Ramp AI Index: Cracks in the AI thesis, part 2
• Startup ARR is less secure than ever, new research shows
• The state of AI in 2026: On the road to ROI
• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering

摘要#

Farhan Thawar（Shopify 工程副總裁暨主管）將這項規則描述為刻意例外於他所屬組織慣例的做法：

"At Shopify, we always have one tool for one job, except for with AI. Since we don't know yet which company, workflow, or model is going to win."

其機制是內部 LLM proxy——所有 AI 請求都會先經過同一個閘道，再送往模型，不論請求來自 Claude Code、Copilot、Cursor、Codex 或其他工具。組織標準化的是工具底下的那一層；工具本身仍不受控。

這是 case-study 等級的材料，來自具名公司具名領導者的第一手陳述，但未經測量：沒有提供成本數字、分析結果或反事實比較。

這一層帶來什麼#

根據來源，主要有三項；值得分開看，因為它們能維持的時間各不相同：

1. 集中式成本控管，以及依團隊和專案區分的使用分析。這是較持久的一項，也是 vault 目前缺少的組織層級工具。Cost-per-Task Over Cost-per-Token 指出，AI 成本的正確單位是已完成的任務，而且 harness 的選擇比模型的選擇更能左右成本——但若要按任務計帳，就得看見每一筆請求；閘道能做到這點，由各自計費的工具組成的整個工具群則做不到。
2. 模型可攜性——「隨著能力演進而切換模型，不必迫使工程師採用單一工作流程。」proxy 讓模型成為可替換的相依項，而非每位工程師工具鏈的一部分。
3. 保留工具實驗空間。工程師不會被導入單一工作流程，因此在選擇尚未定案時，組織仍能持續探索各種可能性。

核心主張談的是不確定情況下的選擇權，而非效率。一項工作配一種工具的標準論點是，工具分散的成本高於其效益；Thawar 的反駁是，分散帶來的成本只是暫時且有上限，但押注在最後落敗的工具上，代價既無法限定，也不會消失。這套推理只有在勝出者確實未知時才成立——這是明確標示時間點的立場；市場一旦塵埃落定，規則就會反轉。

同一原則如何套用到內部系統#

Shopify 將這種做法延伸到模型存取以外：透過MCP 伺服器，工程師可以從 AI 助理查詢 Salesforce、Slack、GitHub 和內部 wiki，「並沿用正常驗證流程中的相同存取控制」。

這裡最關鍵的一句，是來源用來總結此做法為何能擴展的話：「基礎設施控管存取，而非個別工程師。」 這和 proxy 是同一種架構安排——將控制放在組織擁有的關鍵節點，讓受控項目（支出，或觸及內部系統的能力）由結構來治理，而非仰賴每位工程師遵守政策。這也與 Zero Trust for AI Agents 在通訊協定層級提出的組織做法相呼應；前者出發點是成本與分析，後者是安全性，但最後形成相同架構。

值得注意的是，「沿用正常驗證流程中的相同存取控制」究竟解決了什麼、又留下什麼：它讓代理程式能觸及的範圍等同工程師的權限，這是合理的預設值，也正是 Agent Identity and Authentication 所視為難題的特性。來源將其說成已解決的實作細節，卻沒有提供機制。

但大規模人口資料先驗指向相反方向（2026-05）。 Remote MCP Authentication in the Wild 盤點了 7,973 個線上遠端 MCP 伺服器，發現40.55% 提供的工具完全沒有驗證機制，29.00% 使用靜態 token 或 API 金鑰，而119 個可進行端對端測試的 OAuth 部署，每一個都至少帶有一項已確認的驗證缺陷。這並不與 Shopify 的案例矛盾——由內部營運、位於企業身分提供者後方的伺服器，正是公開普查看不到、也很可能做得好的情況。但這表示該主張描述的是罕見結果，而非預設情況；也正因 MCP 本身並不提供存取控制，「基礎設施控管存取」才如此關鍵：在受測群體中，透過第三方 MCP 伺服器將助理接上 Salesforce 或 Slack，完全不會自動繼承任何存取控制。practitioner-opinion 主張某項特性，卻與周遭生態系的 empirical 測量結果對照；來源沒有說明的機制，正是整個問題所在。

流量計量值多少？以數據定價（Accenture《Tokenomics》，2026 年 9 月）#

Shopify 主張了上述效益 1，但沒有測量。《Deploying AI from pilot to production》（Anthropic × Accenture，vendor-claim）提供本資料庫中首批與此主張相關的數字，出自 Accenture 2026 年 9 月的《Tokenomics》研究：

• 42% 的組織依賴 IT 與財務部門共同負責，卻沒有單一負責人掌管 AI 成本與成果。
• 對 AI 支出實施正式分攤成本問責制的組織，每一美元 token 支出中有 32 美分連結到可量化的業務成果——是沒有成本分攤組織的六倍。

請仔細理解，這並不是在主張閘道本身能帶來這些結果。proxy 能提供依團隊區分的使用分析；6 倍的數字屬於成本分攤，也就是讓某人的預算實際吸收帳單的會計政策。Shopify 的基礎設施層是前提（無法歸屬的成本就無從分攤），而文件自己的建議——指定一名具決策權、升級處理權限並獲得高層支持的負責人——則是另一半。因此，資料庫如今在一端有看似合理的機制，在另一端有聲稱的成果，兩者之間卻沒有連結：沒有來源顯示任何組織建置流量計量後，是否將其轉化為成本分攤。

42% 也是兩個數字中更值得注意的一個，且與本文通常的解讀相反。預設的失敗情況不是採用錯誤工具，而是根本沒有人負責帳單；無論基礎層管理得多好，都無法修正這個問題。兩個數字都來自 Accenture 自行發布、沒有方法說明的調查；應將它們視為論點的輪廓，而不是精確規模。周邊藍圖及其證據限制請見 Pilot-to-Production Gap。

透過示範推動採用，而非強制要求#

同一論述中關於組織的一面，也是能推廣至工程以外的部分：Thawar「沒有強制推行 AI，而是親自示範」，分享自己使用 AI 協助完成工作的例子，並將其描述為槓桿，而非能力展示——

"I didn't say look at how much work I did and how smart I am. I said, 'Look how lazy I am.'"

據稱，這種效果擴散到工程以外：業務代表製作儀表板、財務人員不必提出工程工單就能建立工作流程工具、人資產生「n-of-1」軟體。最後這個說法，正是 Implementation Abundance Inverts Product Work 和 Printing Press Software Democratization 從供給面描述的現象——值得為單一使用者撰寫的軟體——此處則將它視為工具決策的後續影響。沒有提供測量；「提升整個工程組織的生產力」是這項主張最有力的表述。

不同來源獨立得出相同機制。 Anthropic × Accenture 對企業導入提出相同做法，並更精確地說明理由：找出推動者，並刻意設計示範時刻，而不是等它自然發生，因為「一位投資組合經理示範如何在三分鐘內摘要一份 200 頁的申報文件給合規專家看，能說服更多懷疑者，勝過任何有架構的推行計畫。」兩個來源來自不同領域（單一工程組織與跨產業企業部署），卻都得出示範勝過強制推行的結論；兩者也同樣沒有測量。值得保留的補充，是「刻意」一詞：Thawar 的說法讀起來像領導者以身作則；藍圖則將示範視為有專人負責、有經費支持的推行步驟。

從未建置閘道的團隊，實際標準化了什麼（2026 年 9 月）#

Shopify 對此原則的實踐，是一支大型平台團隊、具備建置 proxy 預算的供應商周邊案例。Stolze & Strässle（ESEM 2026 SEIP，case-study，訪談對象包括 CTO 企業團隊、能源公用事業前端小組、建築軟體團隊、數位代理商與工業科技團隊，共五次訪談）則從非供應商角度，觀察沒有平台層的組織如何做出相同選擇；結果也呈現相同模式，只是落在更下一層。

五個團隊都沒有標準化工具選擇。五個團隊中有三個的 AI 工具治理非正式或根本不存在；相關調查在整個受訪群體中也幾乎平分：50 位受訪者中，24 位表示組織有明確的 AI 工具使用準則，23 位表示只有非正式安排，或完全沒有監督。所有描述實務做法的參與者，都刻意標準化了限制層：lint 規則、CI 檢查、架構一致性檢查、建置失敗慣例，以及共用的引導文件。其中一位參與者對規則的表述，正是本文會認同的說法——「如果一項規則攸關重要，就必須透過 linting 強制執行」[P4]；另有兩位表示，建置系統成為裁決者，違規會讓建置失敗，而不是交由審查者辯論。

這與「治理基礎層，而非工程師」是同一原則，只是用在限制，而非模型存取；來源也沒有產品要賣。它印證的是原則的普遍性，而非本文的任何數字：只有五次訪談，調查採便利抽樣且未經試測，也沒有測量。還要注意它沒有觸及什麼——下方兩個開放問題都未涵蓋。論文沒有閘道、模型組合決策、proxy、使用分析或任何成本資料；因此，可攜性問題與遙測用途問題都原封不動。完整討論請見 Layered Supervision。

模型組合決策在市場規模下付諸實行（Ramp，2026 年 9 月）#

下方兩個開放問題都源於資料庫記錄了閘道聲稱帶來的效益，卻從未記錄有組織因此採取行動。Ramp 2026 年 9 月 AI Index（Ara Kharazian，empirical，約 70,000 家美國企業的公司卡與帳款支付紀錄；測量工具與 COI 請見 Ramp）是第一個記錄整個群體中可攜性決策成果的來源；值得注意的是，它仍未記錄機制。

觀察到的現象。 每週各模型級別的 token 占比：前沿模型（Opus、Fable、Sol）在 8 月 2 日當週占 52.5%，至 8 月 30 日當週降至 44.7%——該文將其四捨五入為「token 占比 45%……從 8 月的 53% 高點下滑」；標準模型（GPT-5.6 Terra、Claude 的 Sonnet 系列）則在同一五週內從 25.7% 上升至 35.8%。lite 與其他級別大致持平（16.3% → 14.2% 和 5.4% → 5.3%），因此這項變化是直接從前沿模型轉向標準模型，而非全面轉向最便宜的選項。Kharazian 引述買家的回報，說明背後機制：

"We've heard from businesses who are imposing company-wide defaults that reduce usage of frontier models, saying standard models are still highly performant and also more cost effective."

「全公司預設值」正是本文所談的原則，只是由沒有閘道可賣的人說出來。 適用於全公司的預設值能治理基礎層：除非工程師主動改變，否則預設值就會約束他們可用的選項；這與上文的 proxy，以及 Layered Supervision 中五個團隊選擇標準化 lint 規則，而非工具選擇，是同一做法。而且這確實是已採取的模型組合決策；採用該做法的企業數量足以讓市場整體 token 占比序列在五週內移動八個百分點。

它沒有觀察到什麼，以及為何下方 Q1 仍未解答。 Ramp 看到的是透過支付管道流動的金額，卻看不到預設值如何實施：可能是閘道政策、共用 harness 的設定預設值、採購規則、替人做決定的預算，或只是在供應商自己的控制台選擇較便宜的模型。信件完全沒提 proxy、router 或閘道；「我們聽企業說」則是附在整體數字上的軼聞。因此，資料庫如今有了成果（組織確實有意識地整批切換模型組合），卻沒有機制（可攜性層是否讓切換變得便宜）。企業透過供應商端預設值，在完全沒有可攜性層的情況下抵達相同結果，是更簡單的假設；這項測量工具無法排除它。

同一期資料提供的混淆因素。 綜合有效成本從 2026 年 3 月高點每百萬 token 1.15 美元降至 0.68 美元，跌幅 41%；出版前一個月，OpenAI 和 Anthropic 都宣布降價。閘道旨在影響的價格槓桿自行大幅變動，讓歸因模型組合轉變是否由任何組織端機制造成變得更困難，而非更容易——請見 Cost-per-Task Over Cost-per-Token，其中同一組數列被解讀為買家對「預設先用最強模型」做法的裁決。

成本成為設計限制：大規模人口資料（McKinsey，2026 年 8 月）#

本文主張設置流量計量，是為了讓有人能根據讀數採取行動。《The state of AI in 2026》（McKinsey / QuantumBlack，2026-08-25，empirical 但為自陳資料，n=1,719）指出，約五分之一的組織已走到讀數會改變行為的階段：約 20% 受訪者表示，包含 token 成本在內的 AI 相關營運成本已限制組織使用 AI——「不同規模組織的比例大致一致」；依產業區分，從 12%（消費品與零售、公共部門）到 25%（科技）（圖表 8）；若分別檢視聊天機器人、代理程式與程式設計代理程式，各約有十分之一的組織受到限制。

兩項交叉分析讓情況更清楚。第一，成本限制並非集中在最不成熟的組織：AI 高績效組織中，有 18% 表示程式設計代理程式使用受成本限制，而其他組織只有 6%——這是圖表 14 中唯一一種工具，領先群體回報的限制比例高於其他組織。第二，管理成本本身也是調查評分的實務之一：「積極管理 AI 解決方案成本（token、運算、儲存）」在高績效組織與其他組織之間只差約 34% 比 25%（圖表 11，沒有標示數值的啞鈴圖；依網格線讀取，屬約略值），是圖中差距最小的項目之一。因此，成本管理不是成功群體的區別所在；它是約四分之一受訪者表示採行、且僅與成果微弱相關的基本作法。

這才是對本文論點誠實的詮釋：中央閘道讓組織得以看見帳單，而看見帳單的組織正在增加；但到目前為止，看見帳單還不是區分能否取得價值的變數。

延伸閱讀#

• Pilot-to-Production Gap — 這項決策所處的企業部署框架，對於是否承諾採用給出了相反答案。該藍圖將未承諾的自建或採購決策，列為工程債務的主要來源（「每一項拖到試點之後才決定的事，都會產生工程債務：平行系統、永遠無法標準化的整合模式」）；Shopify 則刻意不承諾，而是保留選擇權。兩者可以並存——Shopify 確實做出承諾，承諾的是基礎層，只讓可替換的層保持開放；兩者相容的關鍵，在於承諾約束的是哪一層。此文也提供上述成本分攤數字，以及相同的示範式採用機制
• Layered Supervision — 沒有平台預算時的相同原則。五個沒有閘道的團隊標準化了限制層（lint、CI、造成建置失敗的慣例、共用引導文件），但其中三個團隊的 AI 工具選擇與治理仍屬非正式；這是非供應商來源的佐證，說明組織實際標準化的是約束輸出的基礎層，而非產出內容的工具。文中沒有閘道或成本資料，也無法回答下方任何一項開放問題
• Firm AI-Spend Intensity and Headcount Growth — 上述市場規模分析所用支付管道測量工具的主要說明，以及數字應解讀為走勢而非水準的原因：Ramp 測量的是自身客戶，客戶群偏向創投支持企業；其美元數列在首次公布後幾個月仍會向上修正
• Cost-per-Task Over Cost-per-Token — 這個閘道讓計算成為可能的成本方法：只有每一筆請求都經過同一個流量計量工具，才能測量每項任務的成本
• Orchestration Sets Token Economics — 模型可攜性比模型選擇更重要的原因：決定帳單的是 harness，而非模型
• AI-Native Organization — 本文這項基礎設施決策所處的組織設計框架；此處將閘道而非技能庫編碼為組織運作層
• Agentic Work Systematization — 同一種標準化基礎層的思路再下一層，從模型存取延伸到可重複使用的技能
• Zero Trust for AI Agents — 「基礎設施控管存取，而非個別工程師」這項原則以安全為出發點的版本
• Remote MCP Authentication in the Wild — 對上方 MCP 存取控制主張提出的實證反例：在 7,973 個線上遠端 MCP 伺服器中，40.55% 完全沒有驗證；119 個可測試的 OAuth 部署則全都帶有驗證缺陷。因此，「沿用正常驗證流程中的相同存取控制」描述的是自行建置關鍵節點的組織，而不是 MCP 內建的特性
• Agent Identity and Authentication — MCP 主張略過的難題：代理程式的存取權與操作者驗證流程相同，但只描述了特性，沒有說明機制
• Implementation Abundance Inverts Product Work — 基礎層到位後聲稱會出現的下游效果：非工程師開始建立「n-of-1」軟體
• Build Instead of Buy Under Agentic Coding — 計量基礎層夠便宜後，支出可能流向何處：1,719 位受訪者中有 32% 表示，因為代理式程式設計能打造該功能而拒絕購買軟體。自建決策與 token 帳單會落在同一條預算項目上，而本文的閘道讓組織得以看見兩者
• Outsource Your Thinking, Not Your Understanding — 同一來源對此速度代價的提醒：閘道能計量 token 和回復率，卻無法呈現理解債務

尚待解答的問題#

• 中央 LLM 閘道真的會改變模型組合決策，還是只負責呈報？宣稱的效益是可攜性；資料庫沒有來源記錄任何組織實際運用這項能力。部分解答（2026-09-22）：September 2026 Ramp AI Index: Cracks in the AI thesis, part 2 記錄了約 70,000 家美國企業的結果——五週內前沿模型 token 占比從 52.5% 降至 44.7%，標準級別占比則從 25.7% 升至 35.8%；買家告訴 Ramp，他們正「設定全公司預設值以降低前沿模型使用量」，因為標準模型「效能仍然很高，成本效益也更好」。有明確證據顯示，組織確實有意識地在全公司切換模型組合，而且規模大到足以影響市場整體數字。閘道這一面仍未觸及：支付管道測量工具無法看出決策是透過 proxy、共用 harness 設定、採購規則，還是供應商端預設值強制執行；信件也完全沒提閘道。剩下的問題正是機制：可攜性層是否讓切換變得便宜，還是企業不靠可攜性層也能達到同樣結果？答案還帶來混淆因素：同期有效 token 價格下降 41%，因此模型組合可能只因價格變動而改變。新增第三種機制，2026-09-22——這是全新面向，因為它既不是閘道，也不是價格。Startup ARR is less secure than ever, new research shows（practitioner-opinion，報導一項未讀取的創投調查）指出，Madrona 發現 150 位企業 IT 專業人士中有 77% 每六個月或持續性地重新評估 AI 供應商；Madrona 自己的解讀是「切換成本降低，重新評估的節奏十分密集」。這是採購日程，而非可攜性層：它透過讓決策成為例行且依期程進行，而非讓移轉在技術上更容易，降低切換成本；即使完全沒有基礎設施，也能促成供應商層級的更換。因此，此項目尚待回答的問題——可攜性層是否讓切換變得便宜，還是企業不靠它也能達到同樣結果？——如今有了「不靠可攜性層」的實際候選機制，但此來源同樣無法裁定：文中沒有提到任何基礎設施，沒問重新評估採取行動的成本，也只報告受訪者陳述的頻率，而非實際觀察到的切換。還要注意與 Ramp 資料的單位不同：Madrona 計算的是 AI 供應商（應用程式），Ramp 計算的是模型級別，沒有證據顯示同一種評估週期適用於兩者。
• 依團隊區分的 AI 使用分析存在之後，會被用來做什麼——控制成本、規劃產能，還是評估工程師績效？第三種用途會與 Telemetry vs. Survey Measurement 對儀表化產出資料能支持、不能支持哪些結論的分析相衝突。**部分解答（2026-09-22）：**三種用途中的第一種如今已經被觀察到，但粒度是企業而非團隊。September 2026 Ramp AI Index: Cracks in the AI thesis, part 2 報告企業根據 AI 支出可見度採取行動，設定全公司模型預設值，明確以成本效益為理由——也就是成本控管，也是資料庫中唯一有來源記錄的用途。兩項限制使問題仍未解答：粒度不符（支付卡管道上的企業供應商支出，而非依團隊區分的使用情形），且出版者銷售支出可見度產品，因此其說法同時是行銷呈現與測量。產能規劃和績效評估則完全沒有觀察到。2026-09-22 擴充，納入 The state of AI in 2026: On the road to ROI（empirical，自陳資料，n=1,719）；該研究補上 Ramp 信件無法提供的母群分母：約 20% 受訪者表示，AI 營運成本（包括 token）確實限制了組織使用 AI（圖表 8），依產業介於 12% 至 25%，且「不同規模企業的比例大致一致」。這是首次估計有多少組織已經到達成本讀數會構成限制、而不只是提供資訊的程度；這也是第三種測量工具觀察到的成本控管用途。兩項限制讓問題仍停留在原處。這項限制不是新手才遇到的問題——AI 高績效組織回報，程式設計代理程式使用受成本限制的比例為 18%，其他組織則為 6%（圖表 14）；更重要的是，調查詢問的是成本壓力的結果，完全沒有詢問測量工具：沒有任何問題提到閘道、proxy、成本分攤或依團隊區分的分析，因此組織在限制使用前看過什麼，仍無從得知。所有測量工具都沒有觀察到產能規劃或工程師績效評估。

資料來源#

• When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering — Stolze & Strässle（OST Eastern Switzerland UAS / smartive AG，arXiv 2608.26316，2026-08-26，ESEM 2026 SEIP），case-study：§4.2–4.3（限制層是標準化對象、lint 升級規則、以建置結果裁決）以及 §4.5 和 §3.3（治理方式的分布，24/50 對 23/50）。非供應商來源，但規模很小——五次訪談和便利抽樣、未經試測的調查；證據說明請見 Layered Supervision
• Inside AI-pilled engineering teams: Five lessons for scaling without losing the plot — Bessemer Atlas，2026-06-10（實務內容屬於 case-study）：§2「How Shopify enabled AI tool experimentation without chaos」。Thawar 的引言為第一手陳述；生產力與跨職能採用的效果是他的描述，未經測量。開頭的採用比例屬於另一個較低等級——請參見來源註記
• A First Measurement Study on Authentication Security in Real-World Remote MCP Servers — Zhou 等人（Fudan University；一位作者任職於 Central South University），A First Measurement Study on Authentication Security in Real-World Remote MCP Servers，arXiv 2605.22333，2026-05-21，empirical，無 COI。此處僅用作生態系先驗，對照本來源未說明機制的 MCP 存取控制主張——§3.2 的表 2 列出 7,973 個通過驗證的伺服器分布；Finding 3.1 顯示 119/119 有缺陷。解析警告及完整討論請見 Remote MCP Authentication in the Wild
• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders — Deploying AI from pilot to production，Anthropic × Accenture，2026-09-11，38 頁，vendor-claim。此處引用 Accenture 2026 年 9 月《Tokenomics》中的成本分攤與責任歸屬數字，並佐證透過示範推動採用的做法。兩項數字都來自出版者自行發布、未附方法說明的調查。完整分析與證據限制請見 Pilot-to-Production Gap
• The state of AI in 2026: On the road to ROI — Dan Tinkoff、Lieven Van der Veken 與 Michael Chui，與 Tara Balakrishnan 合著，The state of AI in 2026: On the road to ROI（McKinsey / QuantumBlack，2026-08-25，empirical，自陳資料；線上調查，97 個國家共 1,719 位參與者，調查期間為 2026 年 5 月 4 日至 6 月 8 日，依 GDP 加權）。此處引用圖表 8（各產業成本限制比例 20%）、圖表 14（高績效組織的程式設計代理程式成本限制）與圖表 11 的成本管理實務列——最後一項是依未標示數值的啞鈴圖網格線讀取，屬約略值。**COI：**McKinsey 銷售 AI 轉型顧問服務；調查採用其自有樣本，資料為自陳。完整討論請見 Build Instead of Buy Under Agentic Coding
• September 2026 Ramp AI Index: Cracks in the AI thesis, part 2 — Ara Kharazian，September 2026 Ramp AI Index: Cracks in the AI thesis, part 2（Ramp，2026-09-09，empirical）：每週依模型級別區分的 token 占比序列（從文章的 Datawrapper 資料集端點還原，因網頁沒有靜態圖表圖片），以及報告全公司預設值降低前沿模型使用量的文字段落。此處引用其組織行為資料，而非模型市場資料。**COI：**Ramp 測量的是自家公司卡客戶群，並販售支出可見度產品；本文第二個開放問題正是關於這類產品的用途。測量範圍與數值修正情形請見 Firm AI-Spend Intensity and Headcount Growth 和 Ramp
• Startup ARR is less secure than ever, new research shows — Julie Bort，TechCrunch，2026-09-03（practitioner-opinion，報導一項未讀取的 Madrona 調查，n=150 位企業 IT 專業人士）：此處僅引用 77% 每半年或持續性重新評估供應商的頻率，作為不涉及可攜性層、降低切換成本的採購日程機制。這是陳述的流程，而非實際觀察到的切換；單位是 AI 供應商，而非模型級別