試行到正式上線的落差

資料來源#

• Adoption Telemetry: Measuring Enterprise AI Adoption from Production Signals
• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders
• 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

摘要#

《Deploying AI from pilot to production》（Anthropic × Accenture，2026-09-11，38 頁，vendor-claim）主張，企業 AI 試行計畫是一種在結構上會誤導人的工具：它之所以成功，是因為正式環境不會重現那些條件，因此試行成功並不能證明任何人實際會運行的系統可行。

「這種隔離讓試行計畫得以成功，但也讓它無法可靠反映企業 AI 在正式環境大規模運作時的表現。」

主張並不是試行計畫執行得不好，而是試行計畫的隔離條件本身就是被測量的對象；解方是在試行之後才做決策之前，就先把正式環境的決策移到試行之前——也就是把試行從能力展示重新定位為準備度演練。這是實務工作者對 Organizational Complements to AI 從經濟學角度提出論點的表述：試行計畫人為提供了各項配套，因此配套落差直到配套撤除後才會顯現。

隔離條件清單#

這份文件最值得移轉應用的貢獻，是將不具代表性的原因逐項列明。文件指出以下六項條件是試行成功的原因：

試行條件	正式環境實際提供的條件
為演練準備好的精選資料集	真實資料資產：分散、格式不一致、受並非為 AI 設計的規則管理，且由時程不同的團隊持有
特別挑選的 AI 原生工程團隊	一般交付團隊，「無法代表更廣泛的企業員工」
免於一般組織動態影響的受保護預算	穩態營運經濟效益
範圍狹窄且明確、時程清楚	碎片化的企業系統與雙向整合
高程度人工介入	系統在無人看管時實際會做的事
下游利害關係人參與有限	IT、法務、財務、人資與法遵，各自對「能運作」有不同定義

第五項最具普遍性，也被明確列為設計原則——「將隱藏的人工介入降到最低」。若試行計畫暗中仰賴人工修補輸入資料，它衡量的就是一個混合系統，而其中的人力部分並未編列進正式環境預算。這是企業部署版的 Failures That Look Like Success 所指出的失敗類型：展示看起來能運作，但讓它能運作的那一部分並未包含在交付成果中。

建議是將正式環境的條件納入試行設計：事先定義正式環境的成功標準、在具代表性的企業條件下測試、將隱藏的人工介入降到最低、驗證交付能力能否超越 AI 原生專家團隊、及早納入治理與可觀測性，並衡量長期營運經濟效益，而非短期模型表現。

將決策提前#

結構性論點關乎的是先後順序，而非內容——文件主張，每一項延到試行之後才做的決策，都會累積影響：

「每一項延到試行之後才做的決策，都會形成工程債務：平行系統、永遠無法標準化的整合模式，以及總在重新協商的平台基礎。」

最鮮明的例子是基礎設施上的兩手準備：組織無法決定自建或採購，於是用代管 API 執行試行計畫，同時讓平台團隊自建一套系統，「以備我們需要更多控制權時使用」；六個月後便得維護兩套系統，而且每個新用例都會重新引發辯論。文件主張，大多數基礎設施問題來自從未做出承諾，而非做錯承諾——這與 Standardize the Infrastructure, Not the Tools 以相反方式解決的選擇權問題相同：將底層基礎定為承諾採用的層次，並刻意保留工具選擇的彈性。

部署藍圖#

涵蓋四個生命週期階段的七項決策，每項都指定一位負責人。七項之中有四項在試行開始前完成，而試行階段本身不新增負責人或決策——它只測試已做出的決策。

階段	#	決策	範圍	負責人
試行前 — 試行開始前先決定	01	策略與權責	成功標準、投資報酬門檻、繼續／停止關卡	高階主管贊助人
	02	資料與整合	稽核資料資產，指派來源資料與管線負責人	資料與 IT 變更負責人
	03	基礎設施	讓平台選擇符合用例需求	CIO／平台主管
	04	安全與信任	資料分類；確認安全、法規與存取要求	安全與法遵主管
試行 — 驗證，不延後	—	不新增負責人或決策	試行測試已做出的決策	—
正式環境前 — 為組織做好準備	05	組織準備度	安排推出順序、投入技能再培訓資金、指定倡議者	高階主管贊助人／變革主管
正式環境 — 依風險治理	06	治理與風險	風險分類、監控門檻、審查權限	風險與監控負責人
擴大部署 — 作為一種能力來營運	07	擴大規模與演進	從簡單開始，有計畫地擴大；擴大前先了解失敗情況	AI 計畫負責人

（來源 PDF 第 35 頁。此頁以頁面圖像呈現，因此 docling 與 pdftotext 都無法擷取文字——上表是從匯入時的頁面圖像手動謄錄；詳見來源中的解析註記。）

每項考量最後都附上兩欄問題，文件依決策類型區分：**「共同釐清」問題需要跨職能投入，且有多位負責人；「指派」**問題則是 CIO 或業務主管必須獨自做出的權責決策。這種區分是文件的實務核心——它主張哪些部署問題需要共同審議、哪些屬於高階主管決策；把「指派」問題當成「共同釐清」問題處理，便會讓權責逐漸分散。

權責分解為三個不可互相取代的部分#

指定的負責人需要決策權（無須召開會議即可做決定）、升級處理權限（障礙能在幾天內而非幾個月內引起高階主管注意），以及高階主管支持（傳達組織重視程度，決定其他職能是以合作夥伴還是旁觀者的身分參與）。

「決策權、升級處理權限與高階主管支持彼此不可互換；缺少其中任何一項，都足以讓計畫停擺。」

這種失敗模式多少有些量化依據：Accenture 於 2026 年 9 月發布的《Tokenomics》研究指出，42% 的組織由 IT 與財務共同負責，卻沒有任何單一負責人對 AI 成本與成果負責。對照 AI Employee Framing：該文發現，問責漏洞來自代理程式的定位方式，而非組織圖（代理程式被稱為「員工」時，個人問責下降 9 個百分點，升級通報增加 44%）——兩條獨立途徑導向同一種無人負責的結果，一條是結構性的，一條是語言上的。

部署不等於採用#

文件將系統上線與員工使用區分開來，並直言光靠領導層施壓無法弭平落差：

「一位投資組合經理向合規專員展示她如何在三分鐘內摘要一份 200 頁的申報文件，比任何有組織的推行計畫都更能說服懷疑者。」

建議是刻意設計這些示範時刻，而不是等待它們自然發生——找出倡議者、騰出實驗時間、公開表揚早期採用者。這與 Standardize the Infrastructure, Not the Tools 引述 Shopify 的採用機制相同（靠示範而非強制），只是獨立得出了相同結論。

文件主張，隨著採用擴大，工作會從執行任務轉向監督系統：找出錯誤輸出、決定哪些情況需要升級處理，以及在偏移變成正式環境問題之前偵測出來。這項轉變只有主張，沒有衡量，而且直接牴觸 The Tragedy of the Cognitive Commons 所描述的機制——如果初階執行工作正是培養監督角色所需判斷力的來源，那麼把所有人都轉為監督者的組織，就移除了培養自身仰賴技能的訓練途徑。文件沒有提出這一點。

Copilot 的吞吐量上限#

規模化階段主張端到端自動化優於輔助工具，清楚說明了輔助型 AI 何時不再帶來效益：

「Copilot 的吞吐量上限仍由使用它的人決定。協助分析師加快撰寫報告的工具，仍受限於該分析師能審查並核准多少份報告。」

只有當 AI 完成整項工作——例如端到端處理發票並將例外情況升級處理，或將第一線客服案件從開啟處理至結案——「吞吐量才會隨業務量而非人力編制擴大」。這是企業工作流程版的轉變，對應 Conversation-to-Delegation Shift 在開發者工具中衡量的結果（三個族群的委派輸出占比分別為 99.8%／63.3%／16.5%）；它承接的張力也與 Verification as the New Bottleneck 所指出的相同：將人從迴圈中移除，只會把瓶頸從產出移到驗證，而非消除瓶頸。

文件也明確提出一項平衡原則——從簡單開始。設計良好的提示詞測試快速，失敗模式也可預測；多步驟代理程式系統能力更強，卻更難除錯、維護成本更高，失敗方式也較難預料。只有在較簡單的方法明確碰到極限時，才增加複雜度。（文件引用 Anthropic 自家的《Building effective agents》支持相同論點。）

還有一項比準確率更敏銳的準備度檢驗：了解錯誤模式的分布，而不只是錯誤率。「系統在有限業務量下準確率達 95%，聽起來已準備好正式上線。但剩下的 5% 很重要」——審查者幾秒內就能發現的格式錯誤，可能適合自動化；錯誤的財務計算或漏掉法遵標記，則會讓每增加一單位業務量都增加風險。關鍵問題是，在正式環境的完整業務量下，每一類錯誤的代價是多少。這是 AI-Assisted Error Analysis 用於評估投資的後果分級方法，如今改用於自動化決策。

數據及其支持範圍#

這裡所有數據都由供應商發布。調查至少有名稱與日期；部署軼事則完全無法查證。

有來源歸屬的調查（Accenture 自行發布，未附方法說明）：

數據	來源
23% 的高階主管表示 AI 持續帶來全企業影響	《Pulse of Change》，2026 年 7 月
64% 已跨多個職能從試行進入正式環境，或已開始全企業推行；但只有 7% 的資料準備度足以擴展進階 AI	《AI-Ready Data for Advanced AI》，2026 年 5 月
「資料革新者」相較業界同儕，EBIT 利潤率提升最高達 1.6 倍	《AI-Ready Data for Advanced AI》，2026 年 5 月
42% 由 IT／財務共同負責，卻沒有任何單一負責人對 AI 成本與成果負責	《Tokenomics》，2026 年 9 月
設有正式成本分攤責任制的組織，其 AI token 支出每一美元中有 32 美分可連結至量化業務成果，是沒有分配機制組織的 6 倍	《Tokenomics》，2026 年 9 月

第三方資料：Gartner 於 2025 年 2 月預測，到 2026 年，組織將放棄 60% 缺乏 AI 就緒資料支援的 AI 計畫——這是一項今年就會到期的 prediction，而文件引用時並未核對實際結果。

64% 對 7% 是最關鍵的一組數據，因為這是唯一區分已進入正式環境與有能力擴大規模的數字，也是整份文件論述的算術基礎。引用時應附帶說明：兩個數字都來自同一家供應商對其潛在客戶所做的自家調查，而「資料準備度」門檻由該供應商自行定義。

未具名的軼事——沒有公司名稱、方法或衡量規範：一家全球保險公司將核保審查時間縮短「超過 5 倍」，同時把資料準確度從「75 提高至 90%」；一家製藥公司將臨床研究報告製作時間從「十週縮短至不到十分鐘」；一家電信公司在不到一年內部署「超過 13,000 個客製化 AI 解決方案」。具名客戶案例作為證據更薄弱，因為它們是附有高階主管引述的 Anthropic 案例研究連結：StubHub（經並列模型 A/B 測試後，客服成本降低 30%、回覆時間從超過 20 分鐘縮短至接近即時）；Novo Nordisk（歸因於該公司的十週縮短至十分鐘說法）；TELUS（Fuel iX 多模型平台、13,000 個客製化解決方案、節省超過 500,000 小時、每月 1,000 億個 tokens、「Claude 成為壓倒性的首選」）；Palo Alto Networks（功能開發速度提升 20–30%）；NBIM（兩個月內有 600 多名活躍使用者、由 50 位專家組成的 AI 大使網絡、內部調查顯示每週節省 20% 以上時間）。

**應將這些視為存在性證明，而非效果量。**案例由供應商挑選，處處缺少反事實；同一數字在 p.3 以匿名統計出現，之後又以具名案例出現的兩個情況（Novo Nordisk、TELUS），匿名呈現的方式讓證據看來比具名案例實際能支持的範圍更廣。

這份文件沒有做什麼#

讀者不應期待它做到以下三件事：

1. **沒有失敗分析。**所有案例都成功；文件標題統計指出約有 77% 的計畫尚未持續產生影響，但文件只將原因歸結為它們略過了哪些考量。這是在重述論點，而非提供證據。
2. **沒有對決策本身提供先驗指引。**藍圖只說明誰決定與何時決定，從不說應該決定什麼。自建或採購、單一或多模型、雲端或地端，都被歸結為「有意識地做出承諾」——這讓文件成為流程產物，而非技術文件。唯一例外是下文的檢索架構註記。
3. **沒有估算流程成本。**試行前先完成七項決策，會耗費行事曆時間與高階主管注意力，文件完全沒有估算——這點很重要，因為建議的前提正是「AI 正將這段時程壓縮至數月甚至數週」。

合著者後來還以另一種方式處理這個落差：三個月後，Accenture 與 Google Cloud 宣布將為 Gemini Enterprise 組建一支1,000 人的前線部署工程師團隊（Accenture and Google Cloud Deepen Partnership with Formation of New Accenture Gemini Enterprise Business Group，2026-09-08，vendor-claim）——這是將同一落差包裝成有人力配置的交付能力，而非決策紀律；這是該文件建議的商業替代方案，詳見 Forward-Deployed Engineering as a Delivery Layer。

唯一的架構主張#

考量 03 是文件唯一實質的技術建議，而且是一項減法式建議：檢查檢索層解決的是眼前的問題，還是早已過時的問題。

「許多現有管線正在解決一個已不復存在的上下文視窗限制。」

分塊、傳送前摘要與分階段檢索，過去都是為小型上下文視窗設計的權宜作法；現代模型能一次處理完整合約、程式碼庫或研究報告。文件承認，若資料新鮮度或存取控制是主要考量，檢索仍有價值——這與 Document Parsing as the Retrieval Bottleneck 從相反方向指出的殘餘價值相同（長上下文沒有消滅 RAG；成本、治理與稽核需求仍使其必要），也與 Context Window Smart Zone 所補充的到期邏輯相同：可用上下文遠低於標示的視窗容量。

視窗期內的人口規模數據（McKinsey，2026 年 8 月）#

McKinsey 2026 年 AI 現況調查（97 個國家的 1,719 位受訪者，調查時間為 2026 年 5 月 4 日至 6 月 8 日，以 GDP 加權，屬於 empirical，但資料完全來自自我回報）是本知識庫持有的唯一一份人口規模調查，時間落在 Gartner 放棄預測所涵蓋的期間內，也是對上述 64%／7% 數字最接近外部核對的資料。正在使用 AI 的組織，其 AI 使用階段如下（圖表 1）：

階段	2025	2026
試驗中	32	22
試行中	30	34
至少已開始擴大規模	38	44

此外，89% 的受訪者表示至少有一項職能定期使用 AI，56% 表示至少三項職能使用（高於先前的 51%）。整體分布都往前推進：試驗中的占比下降十個百分點，後兩個階段皆增加。無論 2026 年發生了什麼，這個族群並沒有在這一年退場。

這項調查也用自己的數據重述了本文件的核心問題，而且表述得更鮮明。80% 的受訪者表示 AI 提升了個人生產力；37% 表示 AI 對組織 EBIT 有正面貢獻，與 2025 年幾乎沒有變化——但同一年已開始擴大規模的占比上升六個百分點。部署範圍擴大，財務歸因卻沒有增加。這份藍圖要彌補的落差，在整體族群規模上並未縮小；這是目前最有力的證據，說明瓶頸在於本文件建議的組織變革，而不是部署本身。

調查公布的區分變數是 AI 高績效者與其他組織之間的實務差距：高績效者占受訪者的 6%，他們表示 AI 帶來至少 5% 的 EBIT，且認為影響重大；這個占比與 2025 年相同（圖表 11，棒棒糖圖未標示數字；以下各值依格線讀取，皆為約數）：

實務	其他組織（約）	高績效者（約）
因 AI 而徹底重新設計工作流程	25	72
預期將運用 AI 推動全企業轉型	15	62
高階主管展現真正的所有權意識與承諾	32	65
AI 支出占 IT 預算 >15%	16	35
已判定輸出需要人工驗證的情況與時機	25	35
積極管理 AI 解決方案成本（tokens、運算、儲存）	25	34
有公司資料的語義層／知識圖譜	13	26
已制定量化 AI 計畫影響的流程	17	25
已完成策略性人力規劃	13	24
有權移除瓶頸的轉型辦公室	20	22

依序有兩點解讀。第一，這個族群是按成果定義的，因此每一列都是在依據變數篩選出的群組內觀察到的關聯——這是在排列哪些做法伴隨自陳成功，而非提出因果藍圖；且每個組織只有一位受訪者同時回報實務與結果。第二，排名的形狀才是可用之處，也與本文件自身的排序一致：差距最大的是工作流程重新設計與轉型企圖（藍圖的考量 01–02），領導者以身作則排名第三，資料層那列的差距則屬最小之列。圖表 10 從目標面向說明了相同情況：高績效者追求成長（74% 對 47%）與創新（65% 對 49%），也追求效率；效率目標本身在兩個族群間則沒有差異（78% 對 82%）。近四分之三的高績效者表示已徹底重新設計工作流程，高於一年前的 55%。

落差的階段模型及其證據邊界（NANTE，2026 年 8 月）#

Adoption Telemetry（Damon A. Young，PolyWise Partners；arXiv 2608.23617，2026-08-22，23 頁，practitioner-opinion）是本知識庫中第一個將本頁診斷視為既定事實，並追問該用什麼工具來定位失敗的來源。其論點是：企業 AI 失敗的原因在於組織而非技術，「已不再有人爭論」；「圍繞這個現象已出現大量術語：試行泥淖、試行疲勞、GenAI 落差、AI 作秀……診斷之後卻沒有跟上相應的工具。」

**先交代來源，再談內容，因為這篇很重要。**作者只有一位，來自一家會部署此工具的顧問公司（PolyWise Partners），並以徵求設計合作夥伴作結。**論文中的任何數據都不是來自真實組織。**所有結果都由作者自建的模擬器以固定 seed 產生，而且論文用了不少篇幅說明此事——見下方對循環論證的坦承。論文開頭的失敗統計全是二手資料：MIT NANDA 的「95% 無損益表影響」說法（論文本身指出，v0.1 初步報告「依二手說法的不同，計數方法也不同」，只將其引用為方向性數據）；S&P Global 指出，公司在一年內放棄大部分 AI 計畫的比例從 17% 升至 42%；以及 Gartner 預測到 2027 年底，超過 40% 的代理式計畫會遭取消（論文指出 Gartner 沒有公布 40% 的推導方式）。本文未逐一核對任何一項原始發布資料。

NANTE——源自 Twi 語 nante，意為「行走」——是一個五階段模型；每個階段都是可計算的判定條件，作用於包含工作階段 id、每個工作階段的回合數與任務結果的呼叫事件串流，並與已配置使用者名冊合併。名冊是關鍵的結構性設計：「只有事件的資料庫無法呈現 Notice，因為從未出現的使用者不會產生任何資料列——最需要計入的族群，恰恰是完全沒有留下痕跡的族群。」

階段	問題	建議門檻
Notice	使用者知道這項功能存在且適用於自己嗎？	已配置，但沒有符合資格的活動
Attempt	他們是否至少試用過一次？	首次呼叫
Navigate	試用是否已變成重複使用？	至少 3 個不同週有活動
Transform	工作型態是否已改變？	至少 6 個活躍週，且至少 60% 工作階段為多步驟，且任務成功率至少 55%
Embed	若撤除，是否會造成干擾？	自首次使用以來，至少 90% 的週都有活動

三項設計選擇構成了模型的核心。Notice／Attempt／Navigate 是廣度；Transform／Embed 是深度，而已發表的證據將典型企業失敗定位在這條分界上。Transform 與 Embed 會將同一個合格族群劃分成兩類，而不是層層疊加的篩選條件——符合 Embed 分類者也符合 Transform 的標準；區分兩者的是持續性，「因此，歷史使用量無法取代目前的整合程度」。至於「多步驟」則以至少 12 回合的工作階段作為代理指標；論文稱這是「在事件結構中沒有任務類型欄位時，對工作流程深度的誠實代理指標」，接著也列出已知失敗模式：「深度整合工具的使用者與使用工具時遇到困難的使用者，都可能產生很多回合。」至少 55% 的成功門檻則是刻意新增的，因為沒有這項門檻，「一個常常使用、多步驟操作卻大多失敗的族群，也會被分類為已轉型。」

誠實地設定上限，是論文中最有意思的判斷。停滯狀態是沿著階段邊界逐一檢查，找出第一個未能晉級的階段。在廣度邊界，至少 90% 晉級才算健康，低於 80% 才算失敗。在兩個深度邊界，門檻刻意設在不可能達到的範圍之外：健康下限設在高於 1.0——沒有任何族群能達到的比例，所以不會有任何族群在這裡被判為「健康」；風險警示下限則設在 0.01，低於此值的族群會被判定為失敗，因為其低於已發表證據所示約 2% 的工作流程整合基準。理由是，越過 Navigate「到處都很罕見……這是全產業的懸崖，而非特定族群的缺陷」，依照沒有人能達到的理想目標校準警報，就會讓警報一直響個不停。這是一種在設計時就承認，本頁所述的落差是整個領域常態的衡量工具。

四種失敗特徵會以停滯點之後的旗標計算，每種都搭配一項「不是這個」的介入方式對照——論文的理由是「投資方向錯誤是企業失敗的常見類型」：

• 淺層停滯（分歧指數 > 0.3——留存率高、工作階段深度持平）：工作流程適配失敗。重新設計工作流程，讓工具嵌入任務序列中——不是增加授權數量。「這正是每個使用儀表板都會報告為成功的族群所呈現的特徵。」
• 任務成功率低（某族群中已歸類為 Navigate、年資符合資格的使用者，有至少 75% 未通過成功門檻，但未通過多步驟門檻者不超過 90%；僅在停滯於 Navigate 且有至少 20 名此類使用者時才計算）：技能培訓與啟用——不是重新設計工作流程。「這個族群已把工具帶入深度工作；工作正在失敗，而非根本沒有發生。」
• 仰賴倡議者（在活躍使用者的個人活動量上，Gini > 0.5）：刻意分散集中度——不是表揚重度使用者，他們的集中程度正是風險所在。
• 使用量回落（後期觀察窗口的呼叫率低於既定早期觀察窗口呼叫率的 40%）：高階主管支持與重新整合——不是重新導入培訓；「這個族群以前知道怎麼做；一定是有什麼因素不再鼓勵這種行為。」

當停滯階段與特徵旗標不一致時，以特徵旗標為準：「停滯定位的是族群目前所在的位置，而特徵則指出造成這個結果的流程。」停滯在 Notice 代表能見度與存取問題，而非訓練問題——但論文坦承：「零活動資料列在行為上存在歧義，可能代表使用者從未知道這項能力存在，也可能是他們知道但選擇不使用。」

**設計綜合分數，就是為了讓人對它存疑。**各階段以 0／25／50／75／100 加權，將分布壓縮成 0–100 分；「應與階段分布、停滯點及旗標一併呈現，絕不可取代它們。」論文自己的表 1 就是論據：淺層停滯族群與能力落差族群的階段分布完全相同，分數也同為 49.9，但診斷卻相反（一者停滯淺層但能成功，另一者深入使用卻失敗）；認知落差族群與強化衰退族群的分數僅差 0.6 分（分別為 41.0 與 41.6），但前者從未開始使用，後者則曾經使用後又離開。推出後未滿 60 天或使用者少於 50 人時，工具會回報不可用，而不進行計算。

評估內容為何，以及論文說它不代表什麼。六種合成情境——一種健康、五種病態——每種參照族群皆包含 167 位已配置使用者，觀察期間為 149 天；採用單一固定 seed、預設門檻，並以程式碼庫的 CI 測試套件執行（agent-adoption-kit，Apache 2.0）。核心的數據對照正是這套框架要區分的情形：兩個名冊都有超過 98% 的使用者進入重複使用階段，差異只出現在深度。健康族群向上分布（73.7% Navigate、7.2% Transform、18.0% Embed；深度轉換率 25.1%、分數 60.5，沒有停滯）；淺層停滯族群則有 99.4% 停在 Navigate，無人晉級（深度 0.0%、分數 49.9、停滯於 Navigate，分歧指數 0.67，高於 0.30 門檻）。「若只看活躍使用者，使用儀表板對第二個族群的評價會略高於第一個族群。」讓分類法具有實質意義的區分對照是：能力落差族群有相同的 99.4% 使用者停在 Navigate，但任務成功率為 34.5%，低於健康族群的 69.5%；淺層停滯族群的成功率則是 69.6%——「淺層停滯不等於失敗，失敗也不等於淺層」，兩種旗標不會同時觸發。（表 1 已逐格對照 pdftotext -layout，內容完全一致；健康族群的 25.1% 深度是以未四捨五入的分數計算，與顯示的 7.2 + 18.0 相差 0.1，依照論文自己的註腳。）

接著是免責聲明，內容異常完整，值得直接引述而非改寫：「合成病態情境與建議門檻是共同開發的，因此評估結果顯示，這套工具能區分它原本就要區分的失敗模式——這是必要條件，也是實際的工程成果，但並不能證明依照這些門檻分類的真實族群也會被正確診斷。」其中一種情境明確是刻意設計成不具代表性：健康族群 **25.1% 的深度轉換率「約為已發表證據所示 ~2% 工作流程整合率的十倍，屬於刻意建構的上限對照參考，而非典型實際族群。」**因此，本知識庫的解讀是：**NANTE 是一份規格與分類法，不是研究發現。**它不會取代本頁的任何內容，其數字也沒有一項能用來主張任何真實組織的情況。

有兩處結果會直接影響本頁自身的論點。第一是端到端自動化的吞吐量上限論點：這套工具恰好在該建議指向的情況下失靈。對自主運作的代理程式而言，「框架的核心訊號會反轉：採用深化反而會減少由人啟動的呼叫，因此成功推動委派的組織和放棄工具的組織會呈現相同的下降曲線；依照目前的規格，NANTE 會將前者診斷為強化衰退，並建議重新啟用。」論文將此視為真正的適用邊界，而非可修補的缺陷——完全委派的工作流程代表「組織轉移流程的所有權」，而非某個族群逐步經歷變革。因此，遵循本頁自動化建議的組織，會在同一時刻失去採用衡量工具。第二，§8.5 規定了處置方式的延伸欄位——每次呼叫有五種狀態（自主完成、經審查並接受、遭推翻、升級處理、放棄）——並指出現行資料結構看不到的四種失敗特徵，包括橡皮圖章式核准（「大量完成、少量升級、完全沒有推翻」），這是「目前工具評分最高的情況」。這正是 Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping? 提出的問題，如今以遙測資料結構的形式重新表述；論文也拒絕模擬這種情況：目前沒有已發表的代理程式處置基準率，因此若要設定參數，「就等於先發明參數，再驗證我們的工具能否重現自己發明的結果。」這種拒絕相當誠實，也揭示了真實缺口。

還有一項值得延續的規律，雖然同樣未經驗證：§8.4 指出，只有在組織建立真正的代理程式，而非只是分發使用席位時，才會有 Transform 階段所需的遙測資料——席位型助理的管理匯出資料包含廣度與持續性，卻沒有任務結果，因此無法計算 Transform 階段的門檻——「所以能否取得深度衡量資料本身，就是部署成熟度的一種粗略指標。」

關聯文章#

• The Enterprise AI Adoption Gradient — 這篇文章的論點有了係數佐證。 OpenAI 的企業研究以「採用只是部署的開始」作結，並拆解其中的落差：在 ChatGPT Enterprise 採用者中，大型企業的「每位員工」使用量明顯較低（WAU/emp −0.032***、tokens/emp −0.667***），但「每位活躍使用者的訊息數」持平（−0.002，n.s.）。部署不足完全來自廣度——成為活躍使用者的員工比例較低——而非那些已活躍者使用較少
• Telemetry vs. Survey Measurement — 測量工具的論點在這裡。 該文提出相同來源的主張：四種測量傳統（可觀測性、使用量儀表板、產品分析、變革管理）各自測量的是採用的相鄰面向；ActivTrak 在同一份遙測資料集中，因定義不同而出現 82% 對約 2% 的落差；也說明為何平台供應商不會打造不偏向任何特定產品組合的採用測量工具。分工如下：階段模型及其證據界線放在本文，因為它們關乎「部署失敗」；至於正式環境日誌能否承載變革管理構念，則是關於「測量工具」的主張，放在該文
• Usage-Telemetry Classifier Validation — NANTE 設計所需的測量成本，詳見評估替代方案成本的文章。上述階段判定條件是確定性的計數，測量流程中完全沒有 LLM，因此沒有分類器準確度可供公布——但語意判斷並未消失，而是轉移到 12 輪多步驟代理指標和部署方回報的成功標籤上，兩者都未經任何人驗證。一邊是已公布但未驗證的門檻，另一邊是未公布但經驗證的分類器：兩種不同的失敗，而這類型研究沒有同時具備兩者的測量工具
• Layered Supervision — 考量 05 的轉換，另一種去向。 本文讓操作人員轉為監督同一項產出（發票稽核員現在稽核的是發票稽核系統）；該來源指出，監督工作實際上是往上重新界定，不再針對產出本身，而是轉向架構推理，放棄逐行理解，改為確保系統有需要時能接受診斷。它也點出這份藍圖沒提到的人力配置問題：若廣泛採用 AI，卻未按比例配置資深監督人力，團隊內部會累積難以察覺的風險
• Organizational Complements to AI — 同一主張背後的經濟學。 該文主張，AI 生產力提升有賴互補的工作流程、技能與組織設計變革；本文則從實務角度解釋為何這種依賴會被隱藏：試點會人工提供互補條件（精選資料、熟悉 AI 的員工、受保護的預算），因此無法測出正式上線後將遭遇的落差。「已超越試點」64% 對「資料已就緒」7% 的差距，是以調查統計呈現的互補落差——但須注意，這是單一供應商的調查；該文的核心證據（Codex 三族群自然實驗）並非如此
• Risk-Tiered Auto-Approval — 考量 06 提出的第四種分級依據，依據的是「輸出」可能造成的後果，而非變更、異常或應對方式的可逆性：四級監督階梯（自動化／抽樣／審查／諮詢），各級附有審查頻率，並提出檢查點稽核紀律，以及說明審查層為何會不斷累積的「結構性阻力」。詳見該文
• Standardize the Infrastructure, Not the Tools — 同一層成本治理，並補上本文提供的成本分攤數字（正式採用成本分攤時，每一美元 AI token 支出中有 32 美分能連結至成果；完全沒有成本分攤的企業，比例是其 6 倍；42% 沒有單一負責人），也提出相同的示範式採用機制。不過，兩者對承諾問題的結論相反：本文將未承諾的自建或採購決策視為工程債務的主要來源；Shopify 則藉由只標準化底層基礎設施，刻意保留選擇空間
• Failures That Look Like Success — 「盡量減少隱藏的人工介入」描述的是位於部署流程中的這類失敗，而非代理程式執行軌跡中的失敗：試點看似成功，而讓它成功的人工作業修補，既未記錄在產出中，也未編入正式環境的預算
• Conversation-to-Delegation Shift — 本文從企業工作流程的未來角度，主張副駕駛模式的吞吐量終有上限；該文則從事後角度，在開發者工具中測量這種轉變。兩者的不對稱值得留意：本文主張人類離開迴圈後，吞吐量會隨產量擴大，卻沒有提供任何實測案例；該文提供了委派產出的占比，卻沒有聲稱存在這種上限
• AI Employee Framing — AI 成果無人負責的第二條路徑。本文將責任漏洞定位在組織結構（42% 沒有單一負責人），並要求指定一位具備三種不可互相取代權限的負責人；Kropp 等人則將問題定位在用詞，發現稱代理程式為「員工」會使個人責任感下降 9 個百分點，採用率卻沒有提升。修正其中一種問題，另一種仍會存在
• The Tragedy of the Cognitive Commons — 尚未提出的張力。 本文考量 05 建議工作從執行任務轉向監督系統，因而需要「以判斷為基礎的技能」；Lovett 則主張，這些技能正是透過如今將被自動化取代的初階執行工作再生。本文將監督能力視為培訓投資；該文則視為一種失去再生機制的公地。兩文都未引用對方，而這是知識庫中對這份藍圖最尖銳的反駁
• Document Parsing as the Retrieval Bottleneck — 從相反做法得出對檢索剩餘任務的相同結論：本文採取扣除式論證，稽核管線是否仍在解決已過時的上下文視窗限制；該文則從 2024→2026 的回顧指出，長上下文沒有讓 RAG 消失，因為成本、治理與稽核需求都比這項限制長久。兩者都認同殘存需求在於新鮮度與存取控制，毫無分歧
• Verification as the New Bottleneck — 端到端自動化論點走到盡頭之處。本文以錯誤模式分布檢驗（在完整產量下，各「類型」錯誤的代價為何，而非錯誤率是多少），從部署端表達了該文提出的問題；而只升級處理例外的設計，假設例外偵測是成本低廉的部分
• AI-Assisted Error Analysis — 將同樣以後果為先的推理用於另一種決策：該文預先推演最糟的使用者結果，以決定評估投資；本文則用同樣方式設定自動化界線。兩者都反對所有功能一律套用相同門檻
• Anthropic — 與 Accenture 並列的出版者。本文「開始使用」一節列出 Anthropic 的產品與工程資料，包含 Claude Enterprise 管理員指南、在組織中擴大代理式程式碼開發、Claude Cowork 企業控制、打造有效的代理程式、有效的上下文工程及 MCP，是最明確指出這份文件用途的單一線索
• Psychological Costs of AI Adoption — 考量 05 的轉換讓轉型者付出的代價。 這份個案研究是知識庫中唯一一個監督團隊已運作夠久、能描述工作內容的部署案例：工程師在 AI 撰寫程式碼一年後，仍須為其負責，並閱讀這些程式碼。轉型不是培訓問題，也不是免費的——保留責任卻不再負責撰寫，會帶來驗證成本（「如果我們不必為它產生的程式碼負責，速度就會快得多」）；對於原本的專業技能就是被取代的執行工作者而言，也會造成身分認同與意義感的損失，而監督訓練無法觸及這些問題。藍圖為能力定價，卻未為轉型定價
• Build Instead of Buy Under Agentic Coding — 本文主張「審慎做出承諾」所要解決的唯一決策，而如今有一群人正未經審慎考量就做出這項決策：1,719 名受訪者中有 32% 表示，曾至少一次因代理式程式設計可在內部提供該功能，而放棄購買一項軟體產品。警示是雙向的——不購買的決策正是試點隔離式成功條件可能促成、正式環境卻無法支撐的承諾
• Forward-Deployed Engineering as a Delivery Layer — 將同一落差變現，而非設法消除：買方若不採納前置決策紀律，便會購買由嵌入式工程師組成的人力；知識庫中規模最大的案例，正是由本文共同作者之一配置人力
• Claude Code — 作為領先指標與落後指標論點的具體範例：開發者使用 Claude Code 時，PR 週期是價值的領先指標；業務價值則是落後指標（營收、淨營收留存率、客戶流失率），必須根據實際交付的成果來歸因

開放問題#

• Gartner 在 2025 年 2 月的預測指出，組織到 2026 年將放棄缺乏 AI 就緒資料支援的 AI 專案中的 60%；這項預測今年就會迎來檢驗期，而本文引用它時並未查證。放棄率是否接近 60%？資料就緒度是否如預測所言，是區分成敗的變數？若能驗證這項預測，就能讓本文核心的資料就緒度主張從供應商調查，變成可評估的命題。部分解答（2026-09-22）來自 The state of AI in 2026: On the road to ROI（McKinsey/QuantumBlack，empirical，但屬自陳資料；97 個國家共 1,719 名受訪者，於 2026 年 5 月 4 日至 6 月 8 日間調查，正值預測窗口內，也是知識庫中最有力的窗口內群體資料）。它確立了方向，卻沒有解答比率；問題的兩部分必須分開看。關於放棄率：整體資料看不出 60% 的撤退跡象。仍停留在試驗階段的 AI 使用組織占比，年減 32% 至 22%；試點占比則從 30% 升至 34%，至少已擴大規模的占比從 38% 升至 44%；89% 回報至少在一個職能中定期使用，56% 則在三個或更多職能中定期使用。但這項調查從未詢問專案是否遭放棄、取消或暫停，因此其中完全沒有任何放棄率；無論如何，調查單位也不符合預測：階段問題是詢問「組織」，所以一家在兩個職能中擴大規模、卻在其他職能中扼殺五個專案的企業，在這項測量中不會留下痕跡。Gartner 的數字是以專案為單位的比率；這項調查呈現的是組織分布，兩者無法透過任何運算互相換算。關於資料就緒度是否為區分變數：公布的資料層實務只有組織是否具備語意層或知識圖譜；高績效者約占 26%，其他組織約占 13%（圖表 11，依格線估讀，為近似值）。差距達 2 倍，但這也是圖表中最小的差距之一——工作流程重新設計約為 72% 對 25%、轉型目標約為 62% 對 15%、高階主管以身作則約為 65% 對 32%。因此，在這項測量中，資料就緒度確實有區辨力，但三個組織層面的變數區分效果更強，而群體資料並未顯示預測所暗示的資料層因果優先性。兩項折扣都仍然成立：高績效群體是依據要解釋的結果來定義，而整份調查是 McKinsey 對自己招募的受訪小組所做的自陳調查，且 McKinsey 也販售 AI 轉型服務。若要真正補上本項問題所需的證據，必須有能計算專案的測量工具——例如整體專案清冊，或供應商端的取消統計序列；知識庫中兩者皆無。再補一筆資料，單位正確，證據權重不足（2026-09-22）：Startup ARR is less secure than ever, new research shows 報導 Madrona 對 150 位企業 IT 專業人士的調查，發現不到一半的 AI 試點最終能正式上線——這是以「專案」為單位，符合 Gartner 的單位而非 McKinsey 的單位；但樣本數僅 150，來自創投調查，透過新聞文章進入維基（practitioner-opinion，未讀原始資料），而且測量的是未升級上線，而非 Gartner 預測的放棄率；試點未上線不一定代表專案遭到終止。這項發現方向上符合 60% 流失率，卻無法區分實際數字是 60% 還是 40%。第三種單位，二手資料（2026-09-22）：Adoption Telemetry: Measuring Enterprise AI Adoption from Production Signals 引用 S&P Global Market Intelligence 的資料，指出放棄大多數 AI 計畫的公司占比在單一年內從 17% → 42%。這是放棄行為，不同於 McKinsey 的階段分布；但它計算的是「放棄大多數計畫的公司」，而非遭放棄的專案，沒有資料就緒度的區分，且知識庫是從一篇 practitioner-opinion 論文中間接取得；該論文只將其稱為「對失敗共識的方向性證據」。本項目需要的專案清冊，仍不存在於知識庫中。

• 這份藍圖的核心主張是關於先後順序：試點前做的決策，成本低於試點後才做同樣的決策。本文沒有測量這點，但原則上可以取得反事實比較——兩個計畫使用同一案例，唯一差異是所有權、資料稽核、基礎設施及安全性是否在試點前就已確立。提早處理是否真的能縮短正式上線所需時間，還是只把相同的日曆時間往前挪，並增加本文未計價的主管注意力成本？The state of AI in 2026: On the road to ROI 於 2026-09-22 補充，但只從否定面提供關聯證據；值得記錄，以免下一位讀者重新推導。圖表 11 衡量的是十項實務在橫斷面中的存在與否，完全沒有測量其中任何一項是在何時採行。圖表中差距最大的兩項，正是重新表述後的藍圖試點前決策——轉型目標（策略決策，約 62% 對 15%）與工作流程重新設計（約 72% 對 25%）；這既符合先後順序主張，也完全符合相反的解釋：真正獲得效益的組織，之後才採行這些實務。一次性調查無法分辨兩種解釋，而這項調查沒有公布採行日期、正式上線所需時間或決策流程成本。本項所要求的反事實比較仍無法取得。

• 考量 05 建議把操作人員轉為監督者（「以前逐張審核發票的理賠人員，現在稽核的是審核發票的系統」），而 The Tragedy of the Cognitive Commons 主張，這個角色所需的判斷力，是透過如今將被移除的執行工作再生。是否存在某個部署案例，其監督團隊在底下沒有執行團隊的情況下配置人力，而且錯誤捕捉能力維持超過一年？這是可證偽分歧的核心，但兩份來源都沒有提供答案。部分解答（2026-09-22）來自 The Psychological Costs of Artificial Intelligence Adoption in Software Engineering（case-study，在一家 1,200 人的受監管軟體公司訪談 21 人，恰好是採用啟動一年後）：它提供了部署案例，也回答了一半問題。該公司的工程師轉為監督 AI 撰寫的程式碼，但對程式碼的責任維持不變；轉型也確實持續下來——監督者透過「逐行閱讀結果」及在同儕審查中特別仔細檢查 AI 撰寫的內容，確實能抓出問題。但這些條件正是讓研究結果無法套用到問題前提的原因。監督群體全都是前執行者：21 位參與者中有 19 位具備至少十年產業經驗，年資中位數為 20 年；因此，他們運用的判斷力是在執行工作被移除前累積的，而非移除後再生。此預測仍未受檢驗，而群體成員甚至在未受提示下指出了機制——他們擔心「技能退化」，可能導致從業者「甚至無法批判性地審查 AI 生成的解決方案」；私下則以刻意手動撰寫程式碼的習慣作為因應，儘管沒有人要求他們這麼做。還有兩項落差：研究完全沒有測量任何形式的錯誤捕捉率（這是關於經驗的訪談證據，並非準確度測量工具），而一年仍在問題所詢問的期間之內，尚未超過。研究確立的是，即使轉型奏效，也不是毫無代價——監督者必須負擔一筆組織既未測量也未編列預算的驗證成本。2026-09-22 加入第二個面向：When Review Alone No Longer Scales: Layered Supervision in AI-Assisted Software Engineering（case-study，五位實務工作者訪談，ESEM 2026 Software Engineering in Practice）。它沒有回答問題，卻改變了問題本身。考量 05 將操作人員轉成監督同一項產出的監督者——發票稽核員現在稽核的是發票稽核系統。這五個團隊則把監督移到別處：完全脫離產出本身，轉向架構推理、脈絡適切性與長期可維護性；他們明確放棄完整的逐行理解，改採運作層面的可解釋性，也就是要求生成系統能透過抽象層、視覺化呈現、日誌和高階解讀工具，隨時接受診斷並重建。這項區別與本文討論的認知公地分歧直接相關：稽核產出的監督者需要執行工作過去再生的判斷力；稽核架構的監督者則需要一種執行工作從未提供的判斷力——因此，雙方甚至可能不是在談論同一種人力。相同來源還補上藍圖未提到的人力配置預測，而且方向偏向悲觀：若團隊廣泛採用 AI 工具「卻沒有按比例配置資深監督人力，可能會累積團隊內部無法察覺的風險」；最常使用可執行限制條件的參與者，則具備最強的架構專業知識。缺口仍和之前相同，還多了一項更嚴重的問題：五位受訪者、完全沒有任何形式的錯誤捕捉率、沒有縱向研究組別，而且再次全是資深群體（架構師／CTO、資深經理、團隊主管、兩位資深工程師），因此再度無法檢驗技能再生的預測。2026-09-22 加入第三個面向：The state of AI in 2026: On the road to ROI（empirical，自陳資料，n=1,719）：首份以人口規模、按職級分析成本的資料；樣本比任一個案研究大三個數量級，並納入主管層作為對照組。圖表 5 按組織層級拆分 AI 的主觀影響，壓力集中在主管層以下——47% 的中階主管和個別貢獻者回報至少一項負面影響，主管及資深經理則為 31%。最貼近本項機制的項目是「影響我的批判性思考能力」：中階主管占 20%、個別貢獻者占 16%，C 級主管占 9%、高階主管／資深經理占 8%。職涯焦慮的分布也相同（19%／18% 對 6%／10%），心理疲勞亦然（14%／7% 對 7%／7%）。有三點需釐清：這不是錯誤捕捉率、不是縱向測量，也不是對任何人判斷力的觀察；它是單次的自我感受調查，而且完全沒有詢問監督人力。這筆資料補充的是：21 人訪談群體私下提到的成本，如今在 97 個國家的 1,719 位受訪者中都可見，且委託轉型的主管系統性地感受不到這些成本——這正是藍圖只為能力定價、卻未為轉型定價的結構性原因。同一圖表中有一列相反數據，能讓解讀更平衡：中階主管回報「思考更清晰」的比例也是所有職級中最高（54%，相較於 39／33／37），因此差異在於經驗分歧，而非 C 級主管以下一律悲觀。#oq/source 2026-09-22 加入第三種立場，但沒有部署案例佐證：When Does AI Augment Work? A Workflow-Level Framework for Human-Agent Collaboration（CIVIC-AI 工作坊白皮書，practitioner-opinion，無測量）反對考量 05 的原始寫法，並補上原本缺少的槓桿：審查者的能力「不會自動維持；組織必須刻意分配足夠實質的審查工作，並讓員工接觸足夠多的 AI 失敗案例，才能讓驗證技能保持熟練。」照此說法，有條件地配置監督人力是可行的，這使可證偽問題的核心變得更窄、成本也更低——問題不再是「是否曾經在沒有執行團隊的情況下配置監督人力」，而是「實質審查工作占比是否被刻意維持，錯誤捕捉能力是否因此持續」。論文也以自身的實作範例套用這項準則（初階人員必須親自完成初始流程設計與程式撰寫，理由是錨定偏誤及對 AI 產出進行「空洞驗證」的風險）。沒有部署案例、沒有一年期觀察，也沒有錯誤捕捉測量：證據沒有增加，但設計問題說得更清楚。

• NANTE 的實務主張是停滯類型是不同種類的問題：若 Navigate 停滯伴隨淺層平台期標記，就需要重新設計工作流程；若伴隨低任務成功率標記，就需要提供支援；把任一介入方式套到另一種停滯上都是浪費。目前沒有任何研究驗證這一點。被診斷出某一停滯類型的群體，是否會對其對應的介入類別產生不同反應，而非對其他替代方案產生不同反應？Adoption Telemetry: Measuring Enterprise AI Adoption from Production Signals 在 §8.1 將此列為它自己提出的驗證方法中最有力的一項，卻完全沒有執行——它的評估使用合成群體，而其中的病理問題與門檻是共同設計出來的；這只能證明方法可計算，不能證明方法正確。可透過真實部署加以證偽：預先分類群體，跨越對應關係分配介入方式，而不只依照對應關係分配，之後比較採用深度的轉變。

資料來源#

• 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 加權）。本文引用圖表 1（2025–26 階段分布）、37% EBIT／80% 個人生產力這組數字、圖表 10（各群體的目標）、圖表 11（高績效者實務差距）及圖表 5（各組織層級的主觀影響）。圖表 11 未印上數字標籤——本文所引各數值都是資料匯入時依圖表格線估讀，只能視為近似、方向性數值。**利益衝突：**McKinsey 銷售這項研究暗示有需求的 AI 轉型顧問服務；高績效者的定義依據的是此處試圖解釋的成果。完整證據處理方式見 Source Notes

• 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.4（監督工作向上重新界定及運作層面的可解釋性）與 §4.5（監督能力下限）。本文僅用來討論考量 05 的操作人員轉型為監督者；五場訪談，沒有測量成果——證據說明見 Layered Supervision

• Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders — Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders，Anthropic × Accenture，2026-09-11，38 頁，vendor-claim。共同品牌的企業宣傳資料：作者銷售指南推薦的產品，「開始使用」一節列出 Claude 產品連結，每項部署數字不是未註明來源的軼事，就是供應商案例研究頁面。規範性內容——隔離條件清單、Work-out／Assign 分流、所有權的三項構成、四級監督階梯、錯誤模式分布檢驗——屬於實務判斷，也是文件價值所在；數字則來自 Accenture 自行進行的調查（2026 年 7 月《Pulse of Change》、2026 年 5 月《AI-Ready Data for Advanced AI》、2026 年 9 月《Tokenomics》），自行發布且未附方法說明。**解析警告：**第 35 頁的部署藍圖以頁面圖形繪製——docling 只擷取到裝飾用的時間軸圓點，pdftotext 只擷取到頁首，因此頁面雖顯示存在，卻不含任何內容。本頁表格是匯入時依據渲染頁面手動謄錄，也是知識庫中該內容的唯一副本；原始文件的拼字錯誤（「No new owners or decsions」）在原始資料中以 [sic] 保留。九張擷取表格都已解析乾淨

• Adoption Telemetry: Measuring Enterprise AI Adoption from Production Signals — Damon A. Young（PolyWise Partners，唯一作者），Adoption Telemetry: Measuring Enterprise AI Adoption from Production Signals，arXiv 2608.23617（提交於 2026-08-22；論文自身標註日期為 2026 年 8 月 26 日），23 頁，practitioner-opinion——方法提案，完全沒有任何真實組織資料。 §1（二手失敗統計及其限制說明）、§4.1–4.6（階段模型、遙測特徵、停滯偵測、失敗特徵、介入對應、綜合分數）、§5.2–5.4（六種合成輪廓、結果與循環論證的承認）、§6.1–6.5（限制）、§8.4–8.5（匯出格式造成的資訊退化及處置面向）。**利益衝突：**這是一家顧問公司提出、準備實際部署的測量工具，並以招募設計合作夥伴作結；應把這套架構視為可銷售的產品，而非中立方法。表 1 已逐格對照 pdftotext -layout 核對，內容完全一致——沒有折疊或位移；唯一的換行痕跡是旗標欄中的「Champion depen- dency」。圖 1（階段圖）已依圖片閱讀，與本文敘述一致；圖 2 是工具產生的健康／淺層配對單頁圖，來源本身標示為「Illustrative synthetic data · thresholds proposed, not validated」。測量工具論點與四種傳統間的落差見 Telemetry vs. Survey Measurement。