我們不是由採用 AI 開始

我們不是由採用 AI 開始。

這句話聽起來有點不合潮流，但很重要。我們見過最有用的 AI 系統，並不是由全公司匆忙把工具加到每個地方開始。它們先更仔細地看工作本來如何流動：背景在哪裏、誰擁有決定、人們審閱甚麼、哪些來源重要，以及 handoff 在哪裏斷開。

當工作周邊有足夠形狀，AI 才變得有用。

這是我們現在帶給專業團隊的經驗。問題不是「我們應該買哪個 AI 工具？」更好的問題是「我們哪一部分工作足夠重要、足夠重複、足夠可審閱，以至更好的準備會改變決策質素？」

工具先行的錯誤

常見 adoption 模式由 access 開始。

團隊給大家一個模型，連接文件庫，做幾個示範，然後等生產力出現。通常確實會有些價值。人們草擬更快，總結更快，面對空白頁和例行分析時得到幫助。

但更深層工作仍然未解決。

• 哪份文件才是權威版本？
• 誰擁有下一步？
• 哪個決定需要在行動前審閱？
• 證據缺了甚麼？
• 這屬於哪個客戶、案件、供應商、項目或關係？
• 系統可以用這個答案做甚麼？

如果這些問題不清楚，AI 就只能繞過機構工作，而不是在機構內工作。它可能產生流暢文字，但不能可靠地知道這些文字在團隊營運背景中代表甚麼。

這也是很多 tool-first rollout 只能帶來零散效率的原因。個別同事可能更快寫到第一版，但公司仍然不知道哪個來源最可信、哪個決定需要審批、哪些承諾已經被追蹤、哪些客戶訊息需要更小心。工具改善了個人輸出，卻沒有改善共享工作狀態。

所以 AI transformation 主要是營運工作。能力強的模型不足夠。周邊 workflow 必須變得可理解。

由已經重要的工作開始

最佳起點很少是一套宏大的 AI 策略，而是一個團隊已經重視的真實 workflow。

對法律團隊，可能是每週案件審閱。對財務，可能是續約審閱。對項目團隊，可能是現場決策會議。對顧問業務，可能是客戶跟進。對研究密集團隊，可能是對供應商、precedents、政策或市場參考的第一輪梳理。

這些 workflow 是好起點，因為它們已有節奏。人們本來就收集來源、準備筆記、審閱選項、分配擁有人，並決定下一步。AI 可以協助準備這個節奏周邊的工作。

系統不需要取代專業人士。它需要令專業人士準備得更好。

由已經重要的工作開始，亦令價值更容易被審閱。團隊可以比較 AI 準備的 review packet 和舊方法，看到哪些來源以前經常漏、哪些 follow-up 以前靠人記、哪些 handoff 以前要靠長會議重建。這些改善比抽象「每人節省幾分鐘」更可信，因為它們直接出現在負責人本來就要審閱的工作中。

第一個有用輸出往往不是行動

很多團隊把 AI 價值想像成行動：發電郵、批准續約、更新紀錄、完成任務。

在專業工作中，第一個有用輸出往往更早。它是 first draft、review packet、source map、open-question list、comparison table 或 handoff note。

這些輸出重要，因為它們可審閱。人可以檢查、修正，然後決定下一步。

例如，一個準備客戶跟進審閱的 agent 可能收集：

• 近期筆記和承諾；
• 未完成任務和承諾日期；
• 相關文件和過往決定；
• 影響語氣的關係背景；
• 應該阻止對外聯絡的缺失資料；
• 下一步負責人。

即使 agent 永遠不發送客戶訊息，這仍然有用。價值不是對外自主，而是團隊更快到達準備充分的審閱。

這就是 the first draft 的實際意思。草稿不是最終結果，而是幫助負責任的人更快、更有證據地思考的材料。

這種輸出還有另一個好處：它能把 tacit knowledge 逐步變得可見。很多專業團隊的工作依賴資深同事腦中的背景，例如哪些客戶特別敏感、哪些供應商過去出過問題、哪些政策例外需要主管批准。AI 不能憑空知道這些，但 first draft 和 review packet 會迫使團隊把這些背景寫出來、連到來源、分配擁有人，並在下一次工作中重用。

先令工作可讀，再擴大自主

隨着 AI 能力上升，誘惑是很快授予更多自主性。

我們認為更好的次序較慢，但更耐用：

這個次序不是拒絕自動化，而是自動化取得信任的方法。

NIST 的 AI Risk Management Framework 把 AI 風險視為情境化和 socio-technical 的問題。重點不只是模型表現，而是系統在真實設定中，面對真實用戶、真實後果和真實治理時如何運作。這正是為甚麼專業 AI 應由有邊界的 workflows、可檢查來源和清楚審閱路徑開始。

每個階段都應該保留審閱證據。準備階段要記錄來源和缺口；建議階段要展示理由和不確定；經批准行動要記錄誰批准了甚麼；狹窄自動化要保留例外隊列和 audit trail。這些不是官僚程序，而是讓團隊知道何時可以安全擴大、何時應縮窄的操作資料。

這對專業團隊代表甚麼

實用建議很簡單：不要問 AI 可以灑在哪裏。問哪裏的準備最痛。

尋找那些人們反覆花時間重建背景的 workflows：

• 準備每週案件或項目審閱；
• 在批准開支前檢查供應商續約；
• 讓新分析員加入正在進行的客戶工作；
• 從分散舊材料準備 proposal；
• 審閱客戶關係中的未完成承諾；
• 比較供應商、材料、政策或 precedents。

這些是好的早期 AI workflows，因為即使在自動化之前，價值也可見。團隊可以把準備好的 packet 跟舊工作方式比較。它可以看到缺了甚麼、有用甚麼、應該修正甚麼，以及哪些可變成可重複做法。

這是我們信任的 adoption 模式：準備真實工作，讓負責任的人審閱，改善系統，然後只在證據支持時擴大。

這個模式也比較尊重專業團隊本身的節奏。它不要求所有人同一日改變所有工作，而是由一個具體 workflow 開始，把 AI 放進已經存在的責任結構。當團隊看到 prepared packet 真的令 review 更快、更清楚、更少漏事，adoption 才會由「被要求使用工具」變成「這個工作方法值得保留」。

這亦解釋為甚麼「採用 AI」本身不是足夠清楚的目標。團隊真正需要的是更少重建背景、更少漏掉承諾、更快到達審閱、更清楚知道誰負責下一步。AI 是達成這些目標的手段，不是目標本身。當機構先把工作變得可見，AI 才能接上真正的營運問題，而不是只在每個人的 prompt 裏重新發明一次流程。

所以開始時，問題應該非常具體：哪個 recurring review 最花時間？哪個 handoff 最容易漏資料？哪個 decision packet 最常缺來源？哪個客戶或供應商 follow-up 最容易靠記憶？這些問題會自然指向 AI 可以準備的材料，也會自然定義誰要審閱和如何量度改善。

這不是甚麼

這不是反對 AI 工具。通用 AI 工具有用。Chat 可以幫人思考、草擬、總結和探索。

重點是，專業 adoption 需要工具周邊有 operating layer。系統需要來源存取、權限、擁有人、審閱路徑和邊界。沒有這一層，用戶就要在每個 prompt 裏重建整個機構。

這也不是主張無止境人手審閱。有些 workflows 會穩定到足以作較狹窄的自動化。但它們應該透過反覆準備和審閱取得信任，而不是由示範直接跳到委派。

換句話說，AI adoption 的起點不是工具清單，而是工作清單。哪些工作值得準備得更好？哪些決定值得更清楚的來源？哪些 handoff 值得更少口頭補充？哪些承諾值得被系統記住？當這些問題被回答，AI 才有真正位置。它不是外加在工作之上的新玩具，而是進入已經被整理、可審閱、可問責的工作流。

這是較少戲劇性的開始，但通常是更有效的開始。因為它先改善團隊每天已經要做的事，再逐步增加 AI 的角色。信任不是靠宣布建立，而是靠每一次準備得更好、審閱得更清楚、少漏一件事而建立。

這種開始也讓機構避免「工具買了但工作不變」的局面。當 AI 被放進具體 workflow，團隊很快會看到真正阻礙在哪裏：可能是來源混亂，可能是權限未定，可能是審閱者沒有時間，可能是責任人不清楚。這些發現本身就是轉型工作。AI 只是把原本隱藏的營運問題照亮，然後迫使團隊把它們整理好。

所以，我們不是由採用 AI 開始，而是由令工作準備好被 AI 幫助開始。

一旦工作變得可見，AI 的角色也會自然清楚起來。它可以準備資料、整理來源、標示缺口、草擬 first draft、提醒擁有人和保留 handoff 記憶。這些都不是抽象 adoption，而是直接改善團隊每天已經要承擔的責任。