大多數企業AI舉措都死在試點階段。它們交出一份令人信服的演示、一場滿意的匯報，然後在沒人負責「通往生產」的路徑時悄然停擺。下面這套90天路線圖，是我們用來把「拿到資金的試點」變成「受治理、被採用的能力」的方法——並根據2026年做了更新，因為智慧體與對話式分析已經改變了「生產」的含義。
為什麼AI舉措總在試點之後停擺？
試點是為了打動人而設計的；生產是為了活下來而設計的。演示跑在乾淨的數據、友好的問題集和單一用例上；生產跑在混亂的數據、刁鑽的問題和五十個沒人排期的用例上。兩者之間的鴻溝，就是大多數專案消亡的地方，而原因很少是模型——而是缺乏針對數據、所有權與採用度的計畫。
三種失敗模式佔主導。第一種是數據未就緒：試點悄悄用了一份精心整理的抽取數據，但生產需要的是即時、受治理的數據，而那套管線並不存在。第二種是所有權真空：試點由卓越中心跑起來，卻沒有指派任何業務負責人來日常營運它。第三種是缺失語意層：每個新問題都要一次新整合，於是每個新用例的成本都和第一個一樣高。90天計畫的存在，正是為了迫使這三個問題盡早暴露。
90天路線圖長什麼樣？
計畫分三個階段，每個階段都有明確的出口門檻。第一階段（第1–30天）是發現與定義：挑選三個高價值、低風險的用例；搭建它們所需的數據與語意層；並為每個用例指派一名業務負責人。出口門檻是一份簽字確認的「好」的定義，以及一份數據就緒評估，而不是一個能跑的模型。
第二階段（第31–60天）是構建與驗證：接入受治理的數據，把助理或智慧體部署到語意層之上，並在一小羣真實用戶中運行。出口門檻是在真實問題上的可衡量準確率，以及一份書面記錄的權限模型。第三階段（第61–90天）是擴展與交接：擴展到更廣的團隊，對採用情況做埋點，並把「日常營運」的所有權移交給業務。出口門檻是一個穩定的週活躍數字，以及一名在顧問離場後仍會讓它活下去的負責人。
一個有用的紀律是：每週向贊助人做演示。不是一張狀態投影片——而是一個用生產數據現場回答的真實問題。當演示崩壞時，缺口當週就可見，而不是到第120天。我們發現，每週用真實數據演示的專案能交付；用腳本演示的專案則不會。
如何選對第一個用例？
本能是先從價值最高的問題入手。請剋制。先從高頻、低風險、自包含的問題開始——一個內部知識助理、一個受治理的分析問答、一個文件摘要器。這些能在不把專案暴露於營收關鍵流程的可見失敗的前提下，證明這套模式。
用三個維度給候選者打分：價值、風險、數據就緒度。價值帶來用戶；風險決定幹係人對早期錯誤的容忍度；數據就緒度決定你能多快交付。甜區是高價值、低風險、高就緒。一個常見錯誤是選擇價值高但就緒度低的用例，這必然導致時程滑移，並在模式被證明之前就失去動能。
到了2026年，我們還增加「智慧體就緒度」這一權重：這個用例能否表達成一個清晰、有邊界、智慧體可用受治理工具去追求的目標？能乾淨地映射到語意層的用例，纔是那些能在生產考驗中存活下來的。
語意層扮演什麼角色？
語意層是把「一次整合」變成「無數答案」的乘數。沒有它，每個問題都是一個專案；有了它，每個新問題都只是一次配置。在90天計畫裡，第一階段就搭起哪怕一層很薄的語意層，正是讓第三階段可行的關鍵——到第60天，你可以透過「加定義」來新增用例，而不必重建管線。
具體而言，語意層給生產帶來三樣東西：每個指標的唯一可信定義、隨數據一起流動的行級權限，以及一份智慧體可以推理的機器可讀地圖。跳過它，你會在第61–90天忙著重建連接器，而不是擴展用量。我們把「語意層已存在」當作離開第一階段的硬門檻。
如何在生產中治理AI？
治理不是速度的敵人；它正是讓速度變得安全的東西。我們使用的模型把三件事分開。模型治理決定可以使用哪些模型、如何評估它們。數據治理強制執行每個用戶能看到什麼，最好放在語意層裡。交互治理記錄每一個問題與答案，使行為在事後可審計。
對智慧體而言，還要加第四道控制：工具治理——智慧體可以呼叫哪些系統、需要什麼審批、爆炸半徑有多大。一個只能從受治理語意層讀取、只能透過經過審查且限流的工具有寫入的智慧體，是安全可運行的；一個擁有原始資料庫寫入權限的智慧體則不是。90天計畫應當讓工具治理與生俱來，而不是在事故之後才補。
受監管行業會為高影響動作加一道人在迴路的門檻。這套模式依然能在90天內交付；區別只在於某些決策要等人確認。這正因為治理是前置設計的，所以是一個配置項，而非重建項。
到第90天如何衡量成功？
抵制虛榮指標。「我們建了一個智慧體」不是結果。真正重要的指標是採用度（週活躍用戶）、準確率（真實問題上的答案採納率），以及「下一個用例的時間」（支援一個新問題要多久）。最後一項是語意層的紅利：隨著層成長，這個時間應從數週降到數小時。
我們還跟蹤一個大多數團隊忽略的先行指標：受治理回答與未受治理回答的比值。如果助理隨時間從可信數據回答的問題越來越多，專案就在複利成長；如果它悄悄退回到猜測，它就在腐爛，而第90天會暴露出一個漂亮演示、卻沒有地基。把這個比值做成贊助人每週可見的儀錶板。
第一週應該做什麼？
不要寫程式碼。第一週，定下三個用例，為每個指派一名業務負責人，並對你要先建的那個做一份數據就緒檢查。把這個用例的指標定義寫成契約——負責人、計算邏輯、來源——並取得簽字。這一週的定義工作，正是「90天成功」與「9個月漂移」的分水嶺。
如果你想要一個經過驗證的起點，預約蜂啟諮詢的演示：我們會把你的第一個用例映射到語意層與對話式助理上，在一場現場會話中完成，讓你在第一週結束時帶走寫好的定義和一份贊助人可批准的90天計畫。贏的專案不是模型最好的那些，而是把試點當作生產的第一週、而非一樁獨立事件來對待的那些。
最常見的90天錯誤有哪些？
第一個錯誤是「工具優先」思維：第一週就買一個花俏的平台，之後才發現數據還沒就緒。平台是容易的部分；語意層與定義纔是困難的部分，而且它們買不來。我們正是把定義工作放在第一週，好讓工具選擇變得顯而易見且靠後，而不是過早又錯誤。
第二個錯誤是跳過業務負責人。卓越中心可以搭建試點，但只有指名的業務領導才能讓它活下去、排定下一個用例的優先級、並捍衛預算。如果第三階段沒有負責人，專案會在顧問離場的那一週退回到一個演示。
第三個錯誤是衡量模型而非使命。團隊慶祝模型準確率，卻忽視採用度，然後奇怪為什麼沒人用。採用度是結果；準確率只是贏得它的許可。每週用生產數據做現場演示讓兩者都誠實，因為一個準確但無人使用的模型，和錯誤的模型一樣會在演示中失敗。
第四個錯誤是把治理當作第四階段的馬後砲。第60天之後才補權限與日誌的團隊會發現，事後補齊治理往往意味著重新架構數據通路。第一階段就設計好的治理更便宜，而且在受監管行業裡，是唯一能交付的路徑。
第90天之後如何保持動能？
第90天是一次交接，不是終點線。業務負責人接手儀錶板，語意層變成團隊的職責，卓越中心轉向輔導下一批用例。維繫動能的唯一習慣是每週生產演示：它讓「受治理與未受治理回答」的比值持續可見，並把「我們下一步該建什麼」變成一份有數據支撐的待辦，而非一份政治願望清單。
最後，不要低估變革管理。一個受治理的助理改變了人們的工作方式，沒有賦能，舊的電子表格就會勝出。從第一天起就為培訓和每個團隊的指名推廣人預留預算；在我們的數據裡，有賦能與無賦能團隊的採用差距約為三比一。90天計畫贏得了擴展的權利；賦能才把這項權利轉化為用量。
重點問答
真正的AI舉措真能從試點到生產只用90天嗎？
對於一個聚焦的首個用例，可以。90天足夠定義三個用例、搭起受治理的數據與語意層、部署到一小羣真實用戶，並把所有權移交給業務。塞不進90天的是「把海洋煮開」——試圖同時做所有用例。收窄到一個，證明模式，再擴展。
AI試點無法進入生產最常見的原因是什麼？
缺乏針對數據、所有權與採用度的計畫。演示跑在精心整理的數據和單一用例上；生產需要即時受治理的數據、指名的業務負責人，以及讓新問題變便宜的語意層。這三者缺失時，專案就在匯報的掌聲之後停擺。
為什麼語意層對90天AI路線圖很重要？
沒有語意層，每個新問題都是一次新的整合專案；有了它，每個新問題只是一次配置。第一階段就搭起哪怕一層很薄的語意層，正是讓第三階段擴展可行的關鍵，因為你是透過加定義而非重建管線來新增用例。
生產中應如何治理AI智慧體？
把模型治理、數據治理（語意層裡的權限）、交互治理（記錄每個問題與答案）與工具治理（智慧體可呼叫的系統、所需審批與爆炸半徑）分開。受監管工作應加一道高影響動作的人在迴路門檻——前置設計時，這是一個配置項而非重建項。
