支援團隊的日常，往往不是單一重大故障，而是無數小效率問題層層疊加：文件永遠追不上流程、工單進來的速度比找到指引快、資深同事變成瓶頸、主管只能看落後指標。AWS Machine Learning Blog 在 2026 年 9 月 2 日發布的文章〈Modernizing and scaling support operations with generative AI on AWS〉，提出一套以 Amazon Bedrock 為核心的兩層式架構，試圖從流程層面解決這些問題，而不是只最佳化單張工單或單份文件。
這篇文章不是理論推演，而是直接面對支援營運的痛點：知識分散在 SOP、錄影和資深員工的腦袋裡，導致分析師花大量時間搜尋，而非解決問題。AWS 的解法是結合影片轉 SOP、RAG 引導工單處理，以及 ML 預測 SLA 風險，並用 agentic workflows 自動化標籤、留言、狀態更新等操作，同時保留 human-in-the-loop 確保準確性。
問題的本質：知識沒有累積，流程看不見
AWS 文章點出幾個關鍵現象，值得產品 builders 深思。首先，SOP 通常以「功能」為單位撰寫，每個團隊只記錄自己的片段，缺乏跨部門的端到端視野。當流程變更時，文件更新往往跟不上，於是文件與現實的差距愈來愈大。更糟的是，大量營運知識存在於訓練錄影和 troubleshooting 會議中，會議結束後知識就被鎖在長影片裡，團隊常常要重看舊影片才能重建做法。
其次，工單處理高度依賴個人經驗。新進人員只能靠 escalation，資深人員則被 routine 問題綁住，形成瓶頸。即使找到 SOP，通常也只涵蓋單一功能視角，分析師必須自行拼湊多份文件和 tribal knowledge。最後，管理層看到的報表是落後指標，無法反映即時的工作流狀態，導致瓶頸發現太晚、容量決策延遲。
這些問題環環相扣：知識碎片化導致 workload 不均，workload 不均又讓 mentoring 取代標準化，最終 scaling 只能靠加人，而非改善流程。AWS 的切入點是：先讓知識能從營運活動中自動被捕捉，再讓系統根據工單內容自動找出對應指引，最後讓流程可視化，管理者才能看到 handoffs 與 dependencies。
兩層式架構：執行與分析不再分離
AWS 提出的解決方案分為兩個緊密耦合的層次，而不是各自獨立的工具。第一層是 operational intelligence workspace，主要給分析師日常使用，包含三個能力：
- Video-to-SOP：自動將訓練錄影和系統 walkthrough 轉換成結構化 SOP，透過 Amazon Bedrock 上的多步驟 model invocations，把視覺內容、口頭指示和介面操作變成逐步程序，並嵌入截圖和驗證指引。
- Ticket analyzer：用 NLP、semantic retrieval 和 RAG 分析 incoming tickets，找出相關程序並產生情境化的解決指引。它結合檢索到的 SOP 和 policy documents 與 foundation models，生成符合組織標準的建議。此外，它用 AWS Strands Agents SDK 建立 agentic workflows，讓多個 autonomous agents 協作執行 ticket tagging、commenting、status updates，但都在 human-in-the-loop 框架下運作。
- Value stream intelligence：將解決流程呈現為互動式 swim lane maps，顯示工作如何跨團隊和系統流動，凸顯瓶頸，讓 stakeholders 快速看到 delays、approval friction 和 coordination gaps。
第二層是 analytics and decision intelligence layer，以 Amazon Quick 為基礎，提供給分析師和主管即時洞察。它包含 workload management dashboards（顯示工單如何按 volume 和 complexity 分配）、ML-based ticket categorization 和 SLA risk prediction（為高風險案件打分數），以及 embedded agentic experience（Amazon Quick agent 提供 workload rebalancing 建議，經 supervised workflows 執行並留有 audit trails）。
關鍵在於，這兩層不是獨立運作，而是形成一個 compounding loop：Video-to-SOP 捕捉原本鎖在錄影和 tribal expertise 的知識，Ticket analyzer 將這些結構化知識應用於即時解決，Value stream intelligence 則揭露原本在 function-by-function SOP 下看不見的端到端流程模式。
對 product builders 的啟示：先解決流程，再談 AI
這篇文章對正在評估生成式 AI 的團隊有幾個實用啟示。第一，不要急著導入 AI 工具，而是先盤點知識是否被有效捕捉。AWS 的 Video-to-SOP 之所以有價值，是因為它把「重看錄影」這個隱性成本變成自動化流程，讓知識能持續累積。如果你的團隊還在用 wiki 和 shared drives 散落文件，AI 只會加速混亂。
第二，RAG 不是萬靈丹，它需要搭配良好的知識結構。Ticket analyzer 能產生準確建議，前提是 SOP 和 policy documents 有系統性地被組織，而不是一堆過時文件。AWS 強調「從營運活動中捕捉知識」，這比事後人工整理更可靠。
第三，agentic workflows 的價值在於自動化 routine 操作，但必須設計 human-in-the-loop。AWS 讓 agents 執行 tagging、commenting、status updates，但保留人類審核，這在合規要求高的產業尤其重要。
最後，analytics 層的 SLA risk prediction 提醒我們：與其等工單 breach 才發現，不如用 ML 預測風險，讓團隊能 proactive 地 prioritization。這需要資料品質支撐，AWS 也承認 intake 時資料不完整是挑戰，所以解決方案必須能處理 messy data。
落地考量：從單一 use case 開始
AWS 文章以一個真實營運 use case 示範，並表示可適應金融服務、醫療保健、物流、製造和能源等產業。對多數團隊而言，導入這套架構不一定要一步到位。可以先從 Video-to-SOP 或 Ticket analyzer 其中一個能力開始，驗證知識捕捉與檢索的效益，再逐步串接 analytics 層。
值得注意的是，文章並未提供具體的效能數據或成本估算，這對評估 ROI 是關鍵。此外，AWS Strands Agents SDK 和 Amazon Quick 都是 AWS 生態系服務，若團隊已採用 AWS，整合會較順暢；否則需評估遷移成本。
總體而言，這篇文章提供了一個值得參考的藍圖：用生成式 AI 不是為了取代人，而是讓知識流動、流程可視、風險可預測。對 product builders 來說，重點在於先設計知識捕捉與流程對齊的機制，再讓 AI 在其中扮演加速器，而非憑空創造價值。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。