「萬能工具」的誤解

「萬能工具」的誤解，是相信 AI 的自然終點是一個吸收所有工作的通用工具。

它通常以一句很實際的口號出現：「不如全部自動化。」這句話聽起來有野心，但它遮住了真正的設計問題。有用的 AI 系統，不是靠把每個 workflow 都變成自主行動而產生價值。它們的價值在於幫助機構判斷哪些工作可以自動化、哪些工作應該先準備給人審閱、哪些工作要升級，以及哪些工作仍然應該由人處理。

正確框架不是一個工具，而是一個 operating layer。

Operating layer 讓人和 AI 系統共用背景、權限、證據、工作流程、工具、審閱邊界和補救路徑。它讓自動化在條件成熟時發生，也防止團隊把自動化誤當成 readiness。

這個分別很重要，因為機構 AI 的難處，很少只是模型能否產生答案。真正難的是系統是否知道足夠背景、是否有足夠授權，以及一旦出錯是否有足夠補救能力去行動。

這個誤解是一種分類錯誤

「萬能工具」心態把 AI 看成覆蓋率問題：有多少任務可以被搬進同一個介面、同一個助手、同一個自主 agent？

這是錯誤的分析單位。工作不只是一串任務。工作有背景、風險、擁有人、時機、證據、政治、規管、客戶敏感度、商業判斷和例外處理。

同一個介面可以讓人感覺所有工作都被統一了，但統一介面不等於統一責任。專業工作真正困難的部分，往往不是找到一個地方輸入指令，而是知道這個指令屬於哪個客戶、哪份合約、哪個權限、哪條政策、哪個審閱點，以及哪位負責人可以承擔後果。把所有東西放進一個 assistant，未必令這些關係更清楚；有時只是把它們藏起來。

同一個表面任務，可以代表很不同的事情：

• 「發送客戶更新」可以是例行狀態說明，也可以是敏感的關係介入，甚至是法律陳述。
• 「審閱文件」可以是檢查格式、把條款跟 playbook 比對，或就風險作出專業判斷。
• 「處理續約」可以是發提醒、重新談判商業條款、檢查使用情況，或決定取消供應商。
• 「批准財務申請」可以是配對政策、解讀例外，或為預算決定承擔責任。

誤解不在於自動化不好。自動化很多時候非常好。誤解在於以為一個工具應該把所有這些情況壓成同一種行動模式。

這就是分類錯誤的核心：問題不是「有多少工作可以放進同一個工具」，而是「每種工作需要甚麼責任結構」。一個界面可以承載搜尋、草擬、審閱、批准和行動，但這些模式不能共享同一套權限和風險假設。把它們全部叫做自動化，會令治理變得含糊。

自動化、增強、編排和 Agentic 行動並不相同

團隊把「自動化」鬆散地用來指所有 AI-enabled 工作時，就會出事。至少要分清四種模式。

自動化取代已定義的人手步驟

IBM 把 workflow automation 描述為以軟件取代人手任務，執行整個或部分流程，很多時候使用規則邏輯或 workflow 軟件，而不一定需要 AI（IBM^{2IBM, "What Is Workflow Automation?"}）。

這個定義有用，因為它令自動化落地。當任務可重複、輸入足夠結構化、規則已知，而且成功可以檢查時，自動化最有效。

例子包括把已簽署文件送到正確資料夾、在到期前 90 日發出續約提醒、開支超過門檻時建立審批任務，或表格提交後更新 CRM 欄位。

增強改善人的工作，但不接管權限

增強保留人作為決策者或授權者。系統可以總結、草擬、比較、抽取、分類、搜尋或建議。它不聲稱自己作最終決定。

這往往是 AI 在知識工作中最有用的第一步。系統可以根據近期活動準備客戶更新、在文件包中標示缺失證據，或把續約跟去年的條款比較。人仍然決定輸出是否準確、合適，是否可以發出或使用。

增強的價值，通常來自把人的注意力移到更好的位置。與其花時間找文件、重複整理背景、手動比對欄位，專業人士可以更快進入判斷：證據是否足夠、例外是否重要、語氣是否合適、下一步是否需要更高權限。這不是把人移走，而是把人放回更值得他們負責的位置。

編排協調系統和人之間的工作

編排關乎流動。它連接步驟、工具、擁有人、審閱點和截止日期。它可以包含自動化，但主要價值是令整個 workflow 更一致。

例如續約 workflow 可以把合約、使用數據、供應商擁有人、預算項目、上次談判筆記、安全審查狀態和審批鏈放進一個受治理流程。部分步驟可以自動化。其他步驟應該被分派、審閱或升級。

編排亦令 AI 的邊界更清楚。系統可以知道某一步只是收集資料，下一步要由 owner 回覆，再下一步要由 finance 批准。這比把整個續約交給一個「請處理」指令安全得多。工作流本身保留了擁有人、時間、狀態和審閱點，AI 只在合適位置加速或準備。

Agentic 行動讓軟件透過工具追求目標

Agentic 系統不只是產生文字。它們會選擇步驟、使用工具、檢查結果並作調整。Anthropic 的建議區分 workflows 和 agents：workflows 遵循預先定義的程式路徑；agents 則由模型動態指揮自己的流程和工具使用（Anthropic^{5Anthropic, "Building Effective AI Agents"}）。

這個分別提高了治理門檻。一旦系統可以透過工具行動，機構就要定義它可以讀甚麼、改甚麼、何時必須先問、如何驗證成功，以及如何控制錯誤。

Anthropic 的例子亦顯示，readiness 取決於任務結構。Coding agents 在有自動測試提供回饋、問題空間清楚時較可行；即使如此，人手審閱對更廣的系統要求仍然重要（Anthropic^{5Anthropic, "Building Effective AI Agents"}）。

同樣道理放到商業或專業工作，問題就更尖銳。很多工作沒有自動測試可以即時判斷好壞，亦沒有單一正確答案。客戶關係、法律風險、採購談判、內部政治和專業責任，都不是模型靠流暢文字就能自行驗證的東西。Agentic action 可以有用，但它更需要窄範圍、明確工具、可見證據和停下來的規則。

所以，agentic action 不應被視為「更高級的自動化」而自動套用到所有場景。它只是其中一種模式，而且通常需要更強的邊界：可呼叫哪些工具、可改哪些紀錄、何時必須先問人、如何確認成功，以及錯誤如何被控制。

能力不是 readiness

模型能力回答一個問題：它在某些條件下能否完成任務？

Readiness 回答一個更難的問題：這個系統是否應該在這裏、帶着這些背景、這種權限、這種失敗模式和這條補救路徑，執行這個任務？

這個落差並不新。Lisanne Bainbridge 1983 年的論文 "Ironies of Automation" 是 human factors 研究中的重要警示：自動化可以移除人日常練習的機會，卻仍然要求人在罕見而困難的情況中負責介入（Bainbridge）。

這就是「萬能工具」問題更尖銳的版本。系統可能有能力產生可信的東西，但機構未必準備好承受營運後果。

Capability 和 readiness 的落差，亦解釋為甚麼 demo 容易令人興奮，部署卻容易令人失望。Demo 通常展示模型在一個乾淨例子中完成輸出；實際工作則要求系統面對不完整資料、互相矛盾的來源、模糊權限、不同部門的責任和出錯後的補救。前者是能力展示，後者才是營運 readiness。

Readiness 需要背景

系統需要正確來源材料，而不只是一般知識。客戶更新需要最新會議筆記、未完成承諾、過往語氣、商業敏感度、未解阻礙和受眾。

沒有這些背景，模型仍然可以寫出流暢文字。流暢不是 readiness。

Readiness 需要信心

系統需要一種方式估計任務是否在可靠操作範圍內。信心不應是含糊的自我肯定，而應建基於證據：來源覆蓋、新鮮度、一致性、規則匹配、測試結果或成功 retrieval。

如果財務批准取決於一張缺失的採購單或政策例外，低信心就應該把模式由自動化改成準備或升級。

Readiness 需要權限

系統需要行動許可。權限不只是技術存取。它也包括機構權限：誰可以批准開支、向客戶作陳述、接受合約風險，或改變案件狀態。

NIST 的 AI Risk Management Framework 在這裏有用，因為它把可信 AI 視為治理和風險管理問題，而不只是模型品質問題。該框架旨在協助機構把可信度納入 AI 系統的設計、開發、使用和評估（NIST^{3NIST, "AI Risk Management Framework"}）。

Readiness 需要補救路徑

系統需要方法偵測、停止、逆轉、補償或從失敗中學習。這可以包括審計日誌、批准、版本歷史、rollback、例外隊列、人手通知、事故檢討和行動後對帳。

NIST AI RMF 亦強調，在營運 AI 設定中，人手角色和責任應被清楚定義，而 human-AI 配置可因情境由完全自主到完全人手不等（NIST AI RMF 1.0^{4NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)"}）。

更好的決策規則

實用規則是：

只有在系統具備背景、信心、權限和補救路徑時，才自動化。

如果其中一項缺失，不要硬把任務推進完全自動化。改變模式。

這條規則比「萬能工具」產生更有用的架構。它創造不同工作模式。

有些工作自動化。有些工作先準備。有些工作升級。有些工作保留給人。

實務上會是怎樣

客戶更新

萬能工具會嘗試撰寫並發送更新。

受治理的 operating layer 會先問：這是甚麼類型的更新？如果是例行每週狀態說明，有完整項目資料、已批准語氣，而且沒有敏感問題，系統可以草擬，甚至在輕量審閱後發送。如果涉及預算憂慮、客戶不滿、錯過承諾、法律風險或關係風險，系統應準備證據並升級給負責人。

有用的系統不是永遠發送的系統，而是知道何時適合發送的系統。

文件審閱

對標準文件包，自動化可能足以檢查檔名、必需附件、缺失簽署、重複版本、metadata 和條款是否存在。

對實質審閱，增強通常更安全。系統可以把條款跟 playbook 比對、標示偏離、抽取義務，並引用來源段落。人手審閱者仍然決定重要性、談判立場和最終意見。

失敗模式是把語言模型總結文件的能力，誤當成準備好承擔審閱責任。

續約 workflow

續約很少只是一個日曆提醒。它可能涉及使用情況、預算、供應商風險、採購規則、安全狀態、內部負責人意見和商業替代方案。

自動化可以建立續約任務、收集合約、抽取通知期和提醒負責人。編排可以把財務、採購、安全和業務負責人帶進同一個 workflow。AI 可以準備續約摘要。

Agentic 行動只應在有邊界的步驟中使用：要求補交使用數據、草擬供應商電郵，或開 ticket。除非機構明確授權並建立補救路徑，否則它不應自行續約、取消或重新談判。

財務批准

小額、符合政策、有完整收據和已知預算代碼的開支，可能適合自動化。

較大申請、缺失發票、預算例外、關連方憂慮，或策略供應商承諾，不應被視為同一任務。系統可以準備 approval packet、檢查政策、標示異常，並轉交正確批核人。

重要分別是責任。軟件可以減少摩擦，但不應假裝自己擁有判斷。

這些例子有一個共同點：同一個 workflow 裏可以同時存在自動化、增強、編排和有限 agentic action。客戶更新可以自動收集近期活動、由 AI 草擬摘要、由 workflow 指派審閱者，最後由負責人發送。文件審閱可以自動檢查缺件、由 AI 比對條款、由律師判斷風險。成熟設計不是選一個模式覆蓋全部，而是為每一步選合適模式。

這亦解釋為甚麼 readiness 比 capability 更重要。模型可能有能力草擬一封有說服力的客戶電郵，但如果它看不到最新承諾、不知道客戶敏感度、沒有發送權限，或沒有錯誤補救路徑，系統仍然不應自動發送。能力回答「能不能做」，readiness 回答「應不應該在這裏做」。

甚麼時候自動化已足夠

「萬能工具」批判並不平均適用於每個 workflow。

有時自動化正是正確答案。如果任務頻繁、低風險、定義清楚、可回復並可驗證，受治理的機構應該自動化。

好候選包括：

• 把文件移入標準資料夾結構。
• 按日期和狀態發提醒。
• 由結構化表格提交建立任務。
• 在容許誤差內把發票跟採購單配對。
• 由已批准來源系統更新 dashboard。
• 根據類型把文件交給已知審閱者。

在這些情況下，堅持人手審閱可能是浪費。重點不是拖慢工作，而是避免把每個 workflow 都當成同一風險輪廓。

當系統有背景、信心、權限和補救，而且人的判斷價值相對於延誤成本較低時，自動化已足夠。

相反，如果任務需要關係判斷、例外解讀、專業責任或外部承諾，自動化就算技術上可行，也未必是合適模式。這不是因為 AI 弱，而是因為工作本身的責任不能被一個通用工具吞掉。系統可以準備 evidence pack、列出選項、標示不確定和建議 escalation，但最後行動是否發生，仍然要看授權和問責。

Operating layer 取代通用工具幻想

萬能工具吸引，是因為它承諾壓縮。一個地方。一個助手。一個介面。一句指令：全部自動化。

但認真的機構需要的不是通用工具，而是受治理的營運能力。

這代表：

• Ingestion：承諾、文件、事件、批准、訊息和紀錄進入系統。
• Processing：原始材料被清理、連結、分類、套用權限和標準化。
• Storage：營運狀態存放在可審計和有存取控制的持久系統。
• Retrieval and tools：人和 agents 可透過受控介面尋找、準備、更新、轉交和審閱工作。

這一層可以支援很多工具和很多類型工作。它不需要假裝一個助手應該擁有一切。

這一層也令 AI strategy 從「買哪個 assistant」轉成「哪些工作狀態需要被看見」。如果承諾沒有被捕捉、文件沒有權威版本、審批路徑不清楚、來源權限混亂，任何 assistant 都只能在混亂上面生成文字。Operating layer 的價值，是把工作整理到 AI 和人都可以可靠使用的形狀。

對管理層而言，這會改變投資邏輯。與其追求一個會做所有事的工具，不如投資在可審計資料、權限模型、review queues、例外處理和可重用 workflow patterns。這些基礎能力不只支援一個 AI use case，而是支援很多不同程度的自動化、準備、建議和人手判斷。

這也是更可信的 enterprise AI 路線。第一步不是要求所有工作進入一個 agent，而是讓重要工作有清楚狀態：誰負責、來源在哪裏、下一步是甚麼、甚麼需要審閱、甚麼可以自動。然後 AI 可以逐步放進這些狀態中。某些地方只做搜尋，某些地方做 draft，某些地方提出 recommendation，某些低風險地方才執行 action。

「萬能工具」幻想把成熟度想像成工具越來越大；operating layer 把成熟度理解成工作越來越清楚。這個差異很實際。前者容易產生一個無所不包但難以治理的介面；後者讓機構逐步建立可審閱、可升級處理、可補救的工作能力。對需要信任、審計和專業責任的團隊，後者通常才是 AI 真正落地的路。

如果沒有這個分層，機構很容易在兩個極端之間搖擺。一邊是過度樂觀，覺得 AI 既然能寫、能查、能用工具，就應該全部接手；另一邊是過度保守，因為某些高風險場景不能自動化，就否定所有 AI 工作。Operating layer 提供中間路徑：把工作拆開，讓每一步按背景、信心、權限和補救能力選擇模式。

這也解釋為甚麼「一個 universal assistant」即使體驗漂亮，也不足以成為企業 AI 架構。企業需要的是持久狀態、可追蹤來源、角色權限、審批路徑、例外處理和跨系統紀錄。Assistant 可以是入口，但不應是唯一治理結構。否則，工作看似集中在一個地方，實際責任卻仍然分散而不透明。

結果是一個更冷靜、更可信的 AI 策略。自動化已準備好的部分。準備需要判斷的部分。升級帶有風險的部分。把責任、關係、倫理或歧義最重要的部分保留給人。

這比「全部自動化」少一點戲劇性，但更接近有用 AI 系統真正變得可靠的方式。

從治理角度看，operating layer 亦讓限制變得可執行。政策可以落到 permission、source requirement、approval state、audit log 和 escalation queue，而不只是寫在 PDF 裏。這正是專業機構需要的：不是阻止 AI 使用，而是讓 AI 使用有可見邊界。

這種成熟度也比較容易量度。團隊可以檢查 review packet 是否更完整、例外是否更早升級處理、批准是否更清楚、錯誤是否更容易回復、重複修正是否變成 checks。這些指標比「assistant 回答了多少問題」更貼近組織價值，也更能顯示 AI 是否真的進入工作方式。

從使用者角度看，這也更容易建立信任。員工不需要相信一個無所不能的工具；他們只需要看到某個 workflow 的準備確實更好，某個審閱確實更清楚，某些低風險步驟確實更快。信任由具體工作開始，而不是由品牌式承諾開始。

這也是為甚麼「automate everything」不是一個好的工程要求。它沒有說明哪些東西可以自動、哪些要準備、哪些要升級處理、哪些要保留給人。好的要求應該更像：把低風險重複步驟自動化；把需要判斷的工作準備成 review packet；把不確定和高風險情況交回負責人；把責任保留在清楚的人和角色上。

這樣的策略少一點口號感，但更容易被測試、審計和持續改善。它讓 AI 不是一個吞下所有工作的工具，而是一層幫工作變得更清楚、更可控的營運能力。

這也是「萬能工具」幻想最需要被修正的地方。真正成熟的 AI 系統不一定看起來更大，而是更清楚知道自己在每個 workflow 裏的角色：有時執行規則，有時準備材料，有時提出建議，有時停下來交給人。這種分工比一個無所不包的助手更容易治理，也更容易在專業工作中取得信任。

換言之，價值來自清楚的工作結構、責任邊界和可重複的控制方式，而不是把所有工作壓進同一個通用工具裏面，然後假裝責任已經自然解決。

資料來源

1. Lisanne Bainbridge, "Ironies of Automation", Automatica, 1983
2. IBM, "What Is Workflow Automation?"
3. NIST, "AI Risk Management Framework"
4. NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)"
5. Anthropic, "Building Effective AI Agents"
6. Auste Simkute et al., "Ironies of Generative AI", arXiv, 2024