很多人在建立 AI 系統的初期，都會有一個很自然的想法：只要把規則寫得夠清楚、夠完整，模型應該就能按照指示完成任務。
這個做法在簡單情境下確實有效。例如，要求模型使用繁體中文回答、以條列方式整理重點，或將內容限制在 300 字內，通常都能得到相對穩定的結果。
但當任務開始涉及資料查詢、工具呼叫、條件分支、錯誤處理與多步驟執行時，單靠 Prompt 就會逐漸碰到極限。
Prompt 可以告訴模型它的角色、任務與期待行為，卻無法保證每一個步驟真的被執行。這也是聊天型 AI 與企業級工作流程之間最重要的差異之一。
假設你在 System Prompt 中寫下以下規則：
你是企業數據助理。當使用者提問時，請遵守以下規則：
1. 先查詢 Google Sheets 取得相關數據
2. 如果 Google Sheets 找不到，再查詢 Confluence 文件
3. 最終回答必須附上資料來源
4. 如果資料不足，請說明無法確認，不可以自行推測
乍看之下，這段 Prompt 已經把步驟、工具順序、引用要求與錯誤處理都交代得很清楚，似乎足以形成一套完整流程。
但實際執行時，模型可能出現許多不一致的行為。
它可能按照規則查詢 Google Sheets，也可能直接根據語言模式產生一個看似合理的答案，完全跳過工具呼叫。它甚至可能先回答「好的，我來查一下」，卻沒有真的送出任何工具請求。
當規則數量增加、任務變得更複雜時，模型也可能只遵守其中一部分。例如，它確實查詢了資料，卻忘記附上來源；或是在第一個工具沒有結果時，直接回答找不到資料，而沒有繼續查詢第二個來源。
更麻煩的是，同樣的問題在不同對話中，可能產生不同的執行路徑。有時模型會查工具，有時卻直接回答。這種不確定性在一般聊天中或許可以接受，但如果回答涉及營運數字、專案進度或企業決策，就會成為嚴重的可靠性問題。
Prompt 描述的是「期待的行為」，而不是「被保證的行為」。
大型語言模型是機率性的系統，同一段指令在不同問題與上下文中，可能產生不同的執行結果。
要理解為什麼 Prompt 無法取代工作流程，需要先區分企業 AI 系統中的四個不同層次：Prompt、Policy、Tool 與 Workflow。
這四個概念經常被混在一起，但它們解決的是完全不同的問題。
Prompt 用來告訴模型它應該扮演什麼角色、完成什麼任務，以及如何呈現回答。
例如：
Prompt 很適合處理語氣、格式、角色與一般性的行為指引。它描述的是「希望模型怎麼做」，但並不能強制模型在所有情境中都完整遵守。
Policy 是系統必須遵守的業務規則與安全邊界。
例如：
這些規則如果只寫在 Prompt 中，仍然有被忽略的可能。因此，重要的 Policy 通常需要透過程式進行驗證，例如檢查工具結果是否存在、使用者是否具備權限，以及回答中是否真的包含來源。
Tool 是讓 AI 能夠取得外部資料或執行操作的介面。
如果沒有 Tool，Prompt 中寫著「請查詢 Google Sheets」也沒有意義，因為模型根本沒有能力連接資料來源。它只能根據既有上下文，模擬一個查詢後的回答。
常見工具可能包括：
Tool 解決的是「系統能不能做這件事」，但它仍然不負責保證工具何時被使用，以及不同工具應該按照什麼順序執行。
Workflow 用程式控制步驟順序、條件分支、工具執行、錯誤重試與結束條件。
它處理的是：
Workflow 的價值在於，將關鍵流程從模型的自由判斷中抽離，改由程式保證。
Prompt、Policy、Tool 與 Workflow 不是互相取代，而是彼此疊加。
一套可靠的企業 AI 系統，需要清楚的 Prompt、明確的 Policy、可執行的 Tool，以及能控制流程的 Workflow。最常見的錯誤，是以為只要把 Prompt 寫得夠長，就能取代其他三個層次。
Workflow 的核心不是把步驟寫成一段文字，而是讓程式實際控制每個步驟能否執行。
以「回答今年需求工單趨勢」為例，一套真正的 Workflow 可能按照以下流程運作。
系統先分析使用者的問題，判斷這是一個數據查詢、文件查詢，還是需要跨來源整合的複合任務。
例如，「今年需求工單有多少張」主要需要查詢 Google Sheets；「需求工單分類如何定義」可能需要查詢 Confluence；而「哪一類需求最多，以及相關專案進度如何」則可能同時需要 Google Sheets、Confluence 與 Trello。
這個判斷會決定後續的執行路徑。
當系統確認需要查詢工具後，程式會發出工具呼叫，並等待工具真正返回結果。
在這個階段，系統不應允許模型先產生最終答案。即使模型輸出「好的，我正在查詢」，也不能把這段文字當成任務已經完成。
必須等到工具結果存在後，流程才能進入下一步。
工作流需要檢查模型是否真的產生了工具呼叫，而不是只輸出一段看似正在執行的文字。
如果模型說：
好的，我先幫你查詢今年的需求工單資料。
但輸出中沒有實際的工具請求，工作流就不應直接結束。它可以要求模型重新選擇工具，或由程式直接切換到指定的查詢節點。
這個驗證機制非常重要，因為模型生成「行動描述」並不等於系統真的完成了行動。
工具返回結果後，系統還需要確認資料是否有效。
例如：
只有在工具結果通過驗證後，模型才能根據真實資料產生最終回答。
如果查不到資料，則應依照 Policy 明確說明無法確認，而不是讓模型自行補上一個合理數字。
任何工具都有可能失敗。例如，API 沒有回應、資料庫連線逾時、使用者沒有權限，或查詢語法錯誤。
因此，一個真正的 Workflow 還需要定義：
沒有明確的結束條件，系統可能不斷重試；沒有錯誤處理，系統則可能直接中斷，或在沒有資料的情況下產生錯誤答案。
在 Data Machi 的設計中，我將規則依照重要性拆成三個層級：
L1｜Workflow
程式強制執行：工具呼叫、步驟順序、條件分支、錯誤處理與結束條件
L2｜Policy
系統驗證規則：查不到資料時的處理方式、來源引用與權限限制
L3｜Prompt
模型行為偏好：回答格式、語言風格、內容長度與說明方式
這樣的分層可以避免把所有需求都塞進同一段 System Prompt。
例如，「請使用繁體中文回答」屬於表達偏好，即使偶爾出現英文術語，也不會直接影響資料正確性，因此適合放在 Prompt。
但「回答數字前必須查詢 Google Sheets」會直接影響答案可信度，就不能只依賴模型自覺遵守，而應由 Workflow 檢查工具是否真的被呼叫。
同樣地，「查不到資料時不得自行推測」屬於重要的 Policy。系統可以在產生最終答案前，檢查是否存在有效的工具結果；若沒有，就只能回覆資料不足，而不能進入一般生成流程。
一個實用的方法，是在 AI 系統中加入執行日誌，記錄每次任務實際走過的步驟。
例如：
如果日誌顯示許多需要企業資料的問題，最後卻是「零次工具呼叫」，就代表模型經常跳過查詢流程，直接產生答案。
這類問題如果沒有日誌，很難從最終回答中察覺。因為模型可以用非常自然的語氣，讓使用者誤以為資料已經被查詢。
因此，可觀測性不只是工程團隊除錯的工具，也是企業 AI 可信度的重要基礎。
可以把 Prompt 想成一份員工手冊。
手冊上寫著：
報帳前，請先取得主管簽核。
員工看過手冊後，理論上應該遵守規定，但他仍然可能忘記、誤解，或因為趕時間而直接送出。
Workflow 則像一套報帳系統。當主管簽核欄位是空白時，系統會直接擋下送出操作，顯示：
尚未完成主管簽核，無法提交。
員工手冊只能描述期待行為，報帳系統則能保證必要條件沒有完成時，流程無法繼續。
企業工作流程的可靠性，來自後者，而不是前者。
當 System Prompt 變得愈來愈長時，模型需要同時處理角色設定、語氣要求、輸出格式、工具規則、安全限制與大量例外情況。
這些規則之間可能互相衝突，也可能因為問題複雜度增加，使模型更重視表面上的回答需求，而忽略程序要求。
例如，使用者要求「請直接告訴我結果，不要解釋過程」，但 System Prompt 又要求「查詢工具後才可以回答」。如果沒有程式控制，模型可能為了滿足使用者對速度與直接性的期待，而跳過工具查詢。
又例如，Prompt 前段要求「必須附上來源」，後段又列出大量格式與風格規則。模型可能成功生成一篇結構完整的回答，卻漏掉最關鍵的來源。
這並不是模型故意違反規則，而是機率性生成系統的本質限制。
解決方法不是持續增加 Prompt 長度，而是把不能被違反的規則，移到 Policy 與 Workflow 層面。
傳統自動化通常是完全確定性的。
例如：
如果申請金額小於 10,000 元
→ 交由部門主管核准
如果申請金額大於或等於 10,000 元
→ 交由部門主管與財務主管共同核准
每一個條件與下一步都事先寫死，系統不需要理解任務，也不會自行改變執行路徑。
Agentic Workflow 則允許 AI 在一定範圍內自主判斷。例如，它可以根據使用者問題選擇工具，或根據第一個查詢結果決定是否需要補充另一份文件。
這種設計比傳統自動化更有彈性，特別適合處理自然語言、非結構化文件與無法事先列出所有路徑的任務。
但彈性也會帶來不確定性。因此，好的 Agentic Workflow 不是完全放任模型自行決定，也不是把每一步都寫死，而是在兩者之間取得平衡：
當系統規則愈來愈多時，不要第一時間把它們全部加進 Prompt。可以先判斷這條規則屬於「偏好」，還是「必要條件」。
這類規則通常與表達方式有關，即使偶爾沒有完全遵守，也不會直接破壞答案的可信度。
例如：
這類規則如果被違反，會影響答案正確性、安全性或可信度。
例如：
一個簡單的判斷標準是：
如果這條規則被違反，會不會影響答案的正確性、安全性或可信度？
如果答案是會，就不應只寫在 Prompt 中，而需要由程式層面的機制保證。
今天只需要記住一件事：
Prompt 提供方向，Workflow 提供確定性。
Prompt 可以描述模型應該扮演的角色、使用的語氣與期待行為；Policy 負責定義不能違反的業務與安全邊界；Tool 提供存取資料與執行操作的能力；Workflow 則負責控制整個執行順序、驗證結果與錯誤處理。
企業 AI 系統要可靠，不能只問「Prompt 寫得夠不夠完整」，還必須確認：
下一篇，我們會正式介紹 Data Machi 如何從一個單純的分析工具，逐步演進成企業知識工作流系統，以及這段過程中真正困難的部分是什麼。
iThome鐵人賽
看影片追技術