UNIT 5 | WORKSHOP
單元五 | 實作工作坊
A hands-on guide for turning one business process into a clear workflow map: what starts the work, which data is needed, what AI should help with, and where people review the result.
本單元會帶你把一個商業流程整理成清楚的工作流程圖：什麼啟動工作、需要哪些資料、AI 可以協助哪一段，以及人應該在哪裡審查結果。
Before AI output reaches a customer-facing channel, the workflow should pass through a confidence check, rule check, or human review point. This keeps the final delivery channel separate from raw model output.
AI 產出進入客戶接觸管道之前，應先經過信心度檢查、規則檢查或人工審查點。這樣能避免把模型原始輸出直接送到最終交付管道。
Core Concept 1
In enterprise settings, a single prompt is rarely enough for critical business work. Tasks such as credit risk review or compliance checking require stable inputs, clear rules, and visible review points. The goal of workflow blueprinting is to turn a broad idea into a structured agentic workflow that a business team can evaluate.
在企業情境中，關鍵業務通常不能只靠單一提示詞完成。像信用風險審查或合規檢查這類任務，需要穩定輸入、清楚規則與可看見的審查點。工作流程藍圖的目的，是把一個寬泛構想整理成業務團隊能評估的結構化 agentic workflow。
Workflow blueprinting decomposes a business goal into smaller tasks, data inputs, decision boundaries, and review rules. The point is to know when AI is reading, comparing, drafting, or asking for help, so the process remains explainable and easier to improve.
工作流程藍圖會把商業目標拆成較小的任務、資料輸入、判斷邊界與審查規則。重點是看清楚 AI 何時在讀取、比對、草擬或請人協助，讓流程能被說明，也更容易逐步改善。
A useful rule of thumb: if an experienced person cannot explain the decision process step by step, AI will not automate it reliably. Start by mapping the business logic, the input variables, and the expected output at each node.
一個實用判準是：如果有經驗的人也無法一步一步說清楚決策過程，AI 就很難可靠地自動化。請先畫出商業邏輯、輸入變數，以及每個節點的預期輸出。
Core Concept 2
Every workflow begins with a business need, often expressed as a user story. For instance: "As a procurement manager, I want to verify supplier invoices against internal guidelines and purchase orders so we can catch billing discrepancies." To turn this story into a workable blueprint, identify the relevant data sources and decide how they should be organized.
每個工作流程都始於一項商業需求，通常可以用使用者故事表達。例如：「身為採購經理，我希望比對供應商發票、內部規範與採購單，以便找出帳單差異。」若要把這段需求轉成可操作的藍圖，先找出相關資料來源，並決定它們應如何整理。
For this class exercise, separate inputs into three types: structured data such as vendor master records, semi-structured data such as purchase-order line items, and unstructured data such as scanned invoice PDFs. The blueprint should explain how these inputs become one shared context before AI begins reading, comparing, or drafting.
在這次課堂練習中，可以先把輸入分成三類：結構化資料，例如供應商主檔；半結構化資料，例如採購單明細；非結構化資料，例如掃描發票 PDF。藍圖要說明這些輸入如何被整理成同一份共同脈絡，再交由 AI 讀取、比對或草擬。
{
"transaction_id": "TXN-90211",
"invoice_metadata": {
"vendor_name": "Acme Industrial Ltd",
"raw_ocr_text": "Invoice total: $12,500. Due date: 2026-08-30..."
},
"purchase_order": {
"po_number": "PO-2026-883",
"allowed_amount": 12000.00,
"line_items": [
{ "item_id": "A01", "quantity": 100, "unit_price": 120.00 }
]
},
"compliance_rules": "Page 14: All transactions over $10,000 require manual sign-off if the variance exceeds 3%..."
}Reference Architecture
The six-stage layout below gives you a practical way to describe an AI workflow from the first trigger to final recordkeeping. Each stage asks a simple management question: what starts the work, what information is read, what judgment is made, who reviews it, and what gets recorded?
以下六階段架構，提供一個描述 AI 工作流程的實用方法，從最初觸發到最後留下紀錄。每個階段都對應一個管理問題：什麼啟動工作、讀取哪些資訊、做出什麼判斷、誰來審查，以及最後留下什麼紀錄？
The entry point of the workflow. This can be an event-driven webhook (e.g., an invoice received in an email inbox), a scheduled cron job (e.g., a nightly batch audit), or an active user query via a frontend interface.
工作流的進入點。這可以是事件驅動的 Webhook（例如電子郵件信箱收到發票）、定時任務（例如每晚的批次審計），或是使用者透過前端介面進行的即時查詢。
Programmatic scripts retrieve data from databases, API integrations, and document repositories. The system dynamically packages these raw feeds into a structured context object based on the pre-defined JSON schema.
透過程式化腳本從資料庫、API 串接與文件庫中檢索數據。系統會根據預先定義的 JSON 結構綱要，動態將這些原始數據封裝為結構化的上下文對象。
The workflow routes the context payload through a chain of specialized agents. An Extraction Agent extracts data points, a Comparison Agent cross-checks values, and a Drafting Agent creates the report.
工作流程會把同一份脈絡資料分派給一系列專業代理處理。例如，提取代理負責擷取數據點，比對代理負責交叉核對數值，草擬代理負責產出報告。
An automated validation layer inspects the outputs. It applies programmatic rule checks (e.g., verifying mathematical totals add up) and utilizes an "LLM-as-a-Judge" agent to evaluate the factual alignment and confidence score of the generated draft.
由自動化驗證層檢查輸出。它執行程式化規則檢查（例如驗證數學總和是否正確），並利用「LLM 裁判」代理評估生成草稿的事實一致性與信心度分數。
If the confidence score falls below the required threshold, or if the transaction involves high-risk decisions, the system suspends automatic propagation and routes the task to a human-in-the-loop review interface for manual verification.
若信心度分數低於指定門檻，或交易涉及高風險決策，系統將暫停自動傳播，並將任務派送至人工協同（HITL）審查介面，進行手動驗證與調整。
The approved asset is delivered to its destination (e.g., an ERP write or an automated email dispatch). The entire execution trace, including the human edits, is logged to database records for operational monitoring and future model fine-tuning.
經核准的資產會傳遞至目的地（例如寫入 ERP 系統或自動發送電子郵件）。整個執行追蹤軌跡（包含人工編輯內容）皆會記錄至資料庫，以供營運監控與未來模型微調之用。
Risk Governance
A common design mistake is treating Human-in-the-Loop (HITL) as a simple binary switch where humans review everything. In high-volume operations, this creates severe bottlenecks. A professional workflow blueprint utilizes dual-review gates. The First Review (AI confidence) operates programmatically. For example, using structured JSON outputs with schema validation, we check if the model extracted all required fields. We can also ask the model to output its own confidence score or use a secondary, low-cost evaluator model to critique the draft. If the confidence is high (e.g., > 95%) and no business rules are violated, the draft bypasses human review.
常見的設計錯誤是將人工協同（HITL）視為簡單的二元開關，要求人工審查所有內容。在高業務量的營運中，這會造成嚴重的瓶頸。專業的工作流藍圖採用雙重審查關卡。第一階段審查（AI 信心度）以程式化方式運作。例如，透過結構化的 JSON 輸出與結構綱要驗證，檢查模型是否提取了所有必要欄位。我們也可以要求模型輸出自身的信心度分數，或使用次要且低成本的評估模型來批判草稿。如果信心度很高（例如 > 95%）且未違反任何商業規則，該草稿將直接跳過人工審查。
Guardrails are rules placed around LLM inputs and outputs. They help the workflow follow policy and keep the output in a usable format.
防護欄是放在 LLM 輸入與輸出周圍的規則，協助流程遵守政策，並讓輸出維持可使用的格式。
Complete autonomy is rarely appropriate. Identify risk thresholds where the Agent pauses and asks a person to review the case.
完全自主運作在商業場景中十分罕見。我們需要定義風險閾值，在達標時強制作業暫停並交回人工決策。
Meta-Prompting system pattern for structuring complex multi-agent workflows. Decomposing broad instructions into specialized sub-agents prevents hallucination and establishes reliable review gates.
用於建構複雜多代理工作流的元提示詞（Meta-Prompting）系統模式。將宏觀指令拆解為專業的子代理，能防範幻覺並建立可靠的審查關卡。
If the confidence score drops below the threshold, the Second Review (Human verification) is triggered. This escalation path presents the human reviewer with the original context, the AI draft, and the reason for the warning. By capturing the human's corrections directly within the workflow application (e.g., saving "original draft" vs. "final human-edited text"), the platform gathers highly valuable, context-specific fine-tuning data. This turns the operational pipeline into a flywheel of continuous optimization.
如果信心度分數降至門檻以下，則會觸發第二階段審查（人工協同確認）。此升級路徑會向人工審查員呈現原始上下文、AI 草稿以及警告原因。藉由在工作流應用程式中直接擷取人工修正內容（例如儲存「原始草稿」與「最終人工編輯文本」的對照），平台得以收集高價值且具備特定上下文的微調數據。這將營運管道轉化為持續優化的飛輪。
Hands-on Practice
In this exercise, choose one business process and map its workflow blueprint. Use the profile below to describe the data, AI tasks, review rules, and expected business value. The vendor risk audit example is a reference you can adapt.
在這個練習中，請選擇一個商業流程並畫出工作流程藍圖。你可以用下方表格描述資料、AI 任務、審查規則與預期商業價值。「供應商風險審查」範例可作為改寫參考。
| Blueprint Component 藍圖元件 | Planning Notes 規劃說明 |
|---|---|
|
1. Workflow Trigger Trigger source & event type 觸發源與事件類型 |
Event-driven Webhook: Triggered when a new vendor onboarding request is submitted in the corporate CRM (Salesforce) or a vendor risk questionnaire PDF is uploaded to Google Drive. 事件驅動 Webhook：當企業 CRM (Salesforce) 提交新的供應商註冊申請，或將供應商風險問卷 PDF 上傳至 Google Drive 時觸發。 |
|
2. Sourced Inputs Dynamic context payloads 動態上下文載荷 |
- Structured data: Vendor credit scores and transaction limits from SQL databases. - Unstructured data: OCR text extraction from the vendor's questionnaire PDF. - Policy reference: Risk compliance guidelines (Section 4: Financial Stability). - 結構化數據：來自 SQL 資料庫的供應商信用評等與交易額度限制。 - 非結構化數據：從供應商問卷 PDF 中提取的 OCR 文字內容。 - 政策參考：風險合規性指南（第四章：財務穩定性）。 |
|
3. AI Task Types Specialized LLM nodes 專業 LLM 節點 |
- Extraction Agent: Extracts key metrics (Debt-to-Equity, current ratio) from raw text. - Evaluation Agent: Evaluates values against risk compliance rules. - Synthesizer Agent: Drafts a risk assessment summary report in standard markdown format. - 提取代理：自原始文本中擷取關鍵指標（負債比率、流動比率）。 - 評估代理：對照風險合規性規則評估各項數值。 - 合成代理：以標準 Markdown 格式起草風險評估摘要報告。 |
|
4. First Review (AI Gate) Automated quality metrics 自動化品質指標 |
- JSON validation: Ensures all fields in the risk report schema are populated. - Confidence metric: Target evaluator confidence score is ≥ 90%. - Calculated fields check: Programmatic verification that mathematical calculations are accurate. - JSON 格式驗證：確保風險報告結構綱要中的所有欄位均已填寫。 - 信心度指標：評估模型的信心度目標值為 ≥ 90%。 - 計算欄位核對：程式化驗證數值計算是否完全正確。 |
|
5. Second Review (HITL) Manual escalation rules 手動升級規則 |
Escalate to the Risk Management Team if: - Evaluator model confidence is < 90%. - Vendor's debt-to-equity ratio exceeds 2.5 (High risk). - Discrepancy detected between database credit rating and self-reported risk score. 在以下情況升級至風險管理團隊審查： - 評估模型的信心度 < 90%。 - 供應商的負債比率超過 2.5（高風險）。 - 資料庫信用評等與自我申報的風險分數之間偵測到不一致。 |