讓 AI 的 Observability 與不確定性共舞

李智樺 (Ruddy 老師)／集英信誠 顧問

2026-04-23 09:20 - 10:00 @ 張榮發基金會國際會議中心 11F

議程

簡報

當 LLM 與 Agent 系統全面進入生產環境時，由於它們的本質是機率性而非確定性：相同的 prompt 可能帶來截然不同的輸出，幻覺、漂移、成本失控、無限迴圈隨時可能發生。

而傳統的 Logs、Metrics、Traces 只能告訴你「系統在跑了」，卻無法回答「跑出來的東西可不可靠？為什麼突然變笨？會不會造成公司嚴重的損害？」

這場演講將帶你直面 AI 的核心挑戰: 不確定性，並探索如何透過現代 AI Observability 與它「共舞」而非對抗。

讓我們一起學會與不確定性共舞，讓 AI 從黑盒變成可信賴的生產力引擎！

聽眾收穫：

進一步了解AI的不確定性、認識不確定性的多重來源、運用結構思維設計出具有韌性的系統、從被動監控走向主動「不確定性管理」與自我優化的閉環迴路。

前言：從 UX 可觀察性到 DX 可觀察性

傳統的 UX 可觀察性，主要透過 analytics 分析使用者如何與機器互動，追蹤使用者的行為路徑與操作回饋。

常見觀察指標包括：

  • 轉換率（Conversion Rate）
  • 操作卡關點
  • 任務完成率

這種可觀察性關注的是「從行為中看見人」。

進入 AI 時代後，可觀察性的焦點開始從 UX 延伸到 DX，也就是工程與開發體驗的可觀察性。AI 時代的 DX 可觀察性不只是分析系統行為，而是更進一步探究 AI 生成結果背後的邏輯，驗證輸出是否達成設計者的意圖與預期目標。

換句話說，傳統 UX 可觀察性偏向 analytics，而 AI 時代的 DX 可觀察性更接近 psychology：透過數據理解 AI 的行為模式、生成邏輯與不確定性。

從 Vibe Coding 到 Vibe Story

AI 協作開發不只是讓 AI 寫程式，而是要建立一套能夠觀察、理解與驗證程式行為的機制。

其演進可理解為：

Vibe Coding → 情境 → Vibe Story

核心元素包括：

  • Logs
  • Traces
  • Metrics
  • 意圖
  • 數據
  • 整合
  • 特徵
  • 可觀察性依據

整體流程可整理為：

  1. 以意圖引導 AI 生成
  2. 將觀測能力埋入程式碼
  3. 取得感知數據
  4. 構建情境
  5. 錨定數據特徵
  6. 形成可觀察性依據

目標不是單純得到 AI 產出的程式碼，而是讓 AI 產出能被觀察、被驗證、被理解。

一、讓可觀察性撥開系統運行的迷霧

同一個 Prompt，為何會產生不同答案？

例如同樣輸入：

寫一個冒險的故事

AI 可能產生不同方向的內容，例如：

  • 冒險
  • 科幻
  • 探索

造成差異的原因包括：

  • 文字接龍式的機率生成機制
  • 溫度參數控制
    • 溫度較低時，輸出較嚴謹、穩定
    • 溫度較高時，輸出較多樣、發散
  • 微小的計算差異
  • 模型版本更新

因此，AI 的輸出天然具有不確定性。這種不確定性不是錯誤，而是生成式 AI 的本質之一。

Harness Engineering：讓 Agent 可靠運作

Harness Engineering 是讓 AI 代理能夠可靠、可控、可維護地串接與運作的工程實務。

參考概念來自 Martin Fowler 網站上 Birgitta Böckeler 關於 Harness Engineering for Coding Agent Users 的討論。

核心觀念是：

Agent = Model + Harness
  • Model 負責思考
  • Harness 負責讓它可靠地做事、不亂跑、不崩潰

Harness 的目的，是讓 coding agents 能看見：

  • Logs
  • Metrics
  • Traces

並透過以下機制逐步改善：

  • refine rule
  • bug telemetry
  • verification pipeline
  • iterate

換句話說，模型本身只是一部分；真正讓 AI Agent 可用、可信、可維運的，是圍繞在它周圍的工程約束、觀測機制與驗證管線。

讓 Coding Agents 可靠運作的三個實務能力

1. 模組化思維（Computational Thinking）

不應直接要求 AI：

幫我寫一個電商網站。

這類大型、模糊的任務很容易讓 AI 出錯。

比較好的方式，是將需求拆解成微小、功能明確的單元，也就是原子化。

例如：

  • 先要求 AI 寫「身分驗證模組」
  • 再要求 AI 寫「庫存扣除邏輯」
  • 接著要求 AI 補上測試、錯誤處理與觀測點

關鍵在於：你寫的不是程式碼本身，而是邏輯流程圖與任務結構。

2. 從撰寫者轉向評論家（Code Reviewer）

在 AI 協作開發中，工程師未必需要親手寫每一行程式碼，但必須具備更強的系統觀察與判斷能力。

工程師需要負責驗收 AI 產出，判斷是否符合：

  • 安全性需求，例如 SQL Injection 風險
  • 效能需求
  • 架構一致性
  • 可維護性
  • 可測試性
  • 可觀察性

可以要求 AI 為自己生成的程式碼撰寫單元測試，並以 TDD 或自動化測試流程輔助驗證。

3. 建立自動化管線（AI Pipelines）

人類的角色會從寫程式，轉向設計一個讓 Agent 團隊能自我修正、自我演化的環境。

例如透過 Agentic Workflow：

  • 一個 AI 負責寫 code
  • 一個 AI 負責找 bug
  • 一個 AI 負責部署
  • 一個 AI 負責檢查 logs / metrics / traces
  • 一個 AI 負責產出修正建議

此時，工程師管理的不是程式行數，而是整體工作流。

克服「完全不動手」的障礙，不是因為缺乏能力，而是因為缺乏可行動的結構。這個結構包含：

  • 模組化思維
  • 好的 Code Review 能力
  • 自動化管線

Observability 的三層能力

可觀察性不只是收集資料，而是讓我們能逐步理解系統。

1. 深度觀察：Seeing

對應關聯（Association）。

關注問題包括：

  • 我看到了什麼？
  • 有哪些現象？
  • 有哪些模式？
  • 有哪些變化？

2. 干預：Doing

對應干預（Intervention）。

關注問題包括：

  • 我做了什麼？
  • 這個改變帶來了什麼後果？
  • 哪個行動造成哪個結果？

3. 反事實：Imagining

對應反事實（Counterfactuals）。

關注問題包括：

  • 如果我當初沒這樣做，現在會怎樣？
  • 還有沒有更好的選擇？
  • 如果換另一種策略，結果是否會不同？

AI 時代的工程師角色轉變

在舊時代：

  • 工程師寫 code
  • code 是成果
  • debug code 是主要工作

在 AI 時代：

  • 工程師設計，AI 生成
  • 理解是成果
  • 驗證行為成為核心工作

因此，工程師的知識資產會逐漸從 Coding 轉向 Judgment。

判斷力的重要性會超過單純撰寫能力。

二、情境 vs. 不確定性

AI 的產出其實是一種假設

AI 的輸出不應被直接視為答案，而應該被視為一種假設。

整體流程可以理解為：

問題 / 需求 → 假設 → 觀察 → 驗證 → 知識資產化

相關概念包括：

  • HDD：Hypothesis-Driven Development
  • HITL：Human In The Loop
  • 真相來源
  • 決策：用、不用、再試
  • 人類守備區

從開發流程來看：

Prompt → 產出答案 → 驗證 → 建立信任

「驗證 AI 給的對不對」會成為開發的核心行為。

面對 AI 生成程式碼的兩種態度

不成熟的工程師可能會焦慮地想快速確認：

這能不能跑？

具備判斷力的工程師，則會接受「這答案可能有問題」的懷疑感，並利用這段間隙：

  • 設計實驗
  • 觀察數據
  • 驗證假設
  • 快速迭代

這種心態其實就是敏捷式學習。

沒有完美的 Prompt

AI 時代不存在所謂「絕對完美」的 Prompt。

好的 Prompt 必須具備三個核心屬性：

  1. 去歧義性（De-ambiguation）

    • 消除自然語言中的灰色地帶。

  2. 可預測性（Predictability）

    • 即使運行多次，結果的邏輯架構仍能保持一致。

  3. 可驗證性（Verifiability）

    • 輸出內容必須包含足以讓人判斷的證據或邏輯鏈。

好的 Prompt 不是祈求 AI 給你好答案，而是精確定義問題的邊界。

結構化 Prompt：Given / When / Then

可以用 BDD 的 Given / When / Then 來設計 Prompt：

  • Given：你的觀察與可觀察性設計
  • When：你的系統行為
  • Then：你的判斷力展現

這讓 Prompt 不只是指令，而是一份可驗證的行為規格。

可觀察性是治理 AI 不確定性的基礎

可觀察性（Observability）讓我們透過外部輸出推斷系統內部狀態。

對 AI 而言：

  • 可觀察性是治理 AI 不確定性的關鍵解藥
  • 沒有良好觀測機制的 AI 系統，就像一個情緒不穩定且無法溝通的天才員工
  • 有了可觀察性，才能將 AI 的不確定性納入可控的風險管理框架

不確定性本身不是問題，真正的問題是無法觀察、無法驗證、無法學習。

AI 會大幅加速系統變更與程式碼生成，也同時加速不確定性的累積。當產出速度超過人類逐行閱讀與理解程式碼的能力時，如果仍試圖靠肉眼掃 code 來掌握系統狀態，必然會超出認知負載。

因此，AI 時代的可觀察性重點，不只是輔助 debug，而是讓我們能在不完全閱讀所有程式碼的情況下，透過 logs、metrics、traces、測試結果與執行行為，理解系統與服務實際發生了什麼。

面對不確定性

不確定性是一種無法精確預知未來事件結果，或因資訊不足而無法量化的狀態。它普遍存在於：

  • 經濟
  • 物理
  • 心理學
  • 日常生活

不確定性具有三個重要意義：

認知的暫停鍵

當遇到無法立即分類、解決的新訊息時，大腦會進入一種不確定狀態。

神經塑性的契機

當大腦處於不確定狀態時，神經元連結會變得更具靈活性。

智慧的門檻

不確定性是從反應（Reaction）邁向反思（Reflection）的必經之路。

不確定性的反思

我們要害怕的，不應該是不確定性本身，而是自己越來越不願意辨別細微差別、尋找深度與視角。

不確定性讓我們感到不安，但這正是它送給我們的厚禮。

真正的危機是能力的退化，而不是環境的混亂。

「細微差別」是人類最後的防線。它包含：

  • 辨析能力：區分事實與觀點、真理與偏見
  • 深度與視角：看穿表面邏輯，理解脈絡與人性

AI 產出的不確定性並不可怕。可怕的是我們為了追求確定性，而把自己變成一個不再思考、不再挑剔、不再具備深度的人。

從寫程式到定義現實

AI 時代的工程師角色正在演進：

階段核心動作補充關鍵能力價值體現
Coder撰寫、語法、邏輯演算法、資料結構、單元測試執行力：將需求翻譯成機器懂的指令
Prompt Designer溝通、微調、引導Prompt 策略、情境脈絡設定、評估 AI 輸出、錯誤處理生產力：讓機器產出可用代碼，提升速度
System Designer拆解、組裝、治理API 介面合約、模組解耦、Agentic Workflow、可觀察能力穩定性：確保多個 AI 產出的組件能無縫對接
Reality Engineer定義、預測、驗證不確定性管理、複雜系統思考、商業價值校準決策力：將抽象商業問題轉化為可落實的技術路徑

最終，工程師不只是寫程式，而是定義問題、設計現實、驗證假設。

AI 時代的敏捷開發

AI 時代的敏捷，不再只是傳統 Scrum 流程，而是一種持續修正的學習系統。

核心元素包括：

  • 開發節奏
  • 團隊共智
  • 假設思維
  • 快速驗證與回饋（Rapid Feedback）
  • AI 協作開發（AI-assisted Development）
  • 問題探索（Problem Discovery）

整體流程是：

使用者需求 → 假設 → 實驗 → 學習

AI 敏捷的核心可整理為：

開發節奏 → 共智 → 假設思維

在 AI 協作中，問題與回答也可以形成固定節奏：

  1. 問題描述
  2. 分析
  3. 回答
  4. 確認
  5. 完成
  6. 回顧檢視

與 AI 合作的四原則

參考 Ethan Mollick《Co-Intelligence》，與人工智慧合作可掌握四個原則。

1. Always invite AI to the table

永遠邀請 AI 入局。

不管你覺得它行不行，先讓它參與每一件事。

2. Human in the loop

成為「人在迴路中」的那個人。

人類的專業判斷、價值觀與責任感，仍然是最後一道關卡。

3. Treat AI like a person, but tell it what kind of person it is

像對待人一樣對待 AI，但要先告訴它「它是什麼樣的人」。

給它角色、個性與專業背景，效果會好很多。

4. Assume this is the worst AI you will ever use

假設這是你用過最爛的 AI。

因為未來的 AI 會進步得非常快。

Human In The Loop 與 BDD

BDD 可以為 Human-in-the-Loop 提供一套標準化作業系統。

語言的標準化：建立人機通訊協議

以 Given / When / Then 作為 AI 指令集，讓人與 AI 對需求、情境與預期結果有共同語言。

審核權的移轉：從「怎麼寫」到「對不對」

工程師不再只檢查 AI 怎麼寫，而是檢查 AI 交付的行為是否符合定義的實例。

責任邊界的釐清：誰該為錯誤負責？

BDD 規格書就像一份契約，用結構化方式定義功能與需求，並逐步邁向 Spec Coding。

從 Flow 到 AI-Augmented Flow

AI 時代的工作流，會從傳統 Flow 進一步變成 AI-Augmented Flow。

三個重要轉變包括：

  1. 認知轉移

    • 從語法細節轉向系統架構。

  2. 極速驗證

    • 建立即時回饋的閉環。

  3. 半人馬模式

    • 人與 AI 協作，守護不被中斷的開發節奏。

在這個流程中，Metrics、Logs、Traces 成為重要依據。

例如，當高併發下 Cache 可能失效，就需要透過可觀察性資料驗證問題是否真的發生、何時發生、影響範圍為何。

行動原則是：

Accept. Adjust. Iterate.

接受現況、調整策略、持續迭代。

三、假設思維與可觀察性

空、雨、傘：事實、假設與行動

「空、雨、傘」是一種將觀察、解釋與行動分離的思考框架。

空：Fact / 現況

代表客觀、可被所有人看到的事實與現狀描述。

範例：

  • 今天天空布滿烏雲
  • 上個月營收下滑 15%

重點是不帶解釋、不加主觀判斷，只描述事實。

雨：解釋 / 意義 / 假設

代表從事實得出的推論、含義或假設。

範例：

  • 看這樣子，短時間內很可能會下雨
  • 營收下滑可能是新功能上線後轉換率下降

假設思維的核心，是先提出最可能的解釋或假說，而不是無限制列出所有可能性。

傘：Action / 對策 / 結論

代表基於解釋後採取的具體行動。

範例：

  • 今天出門要帶傘
  • 建議優化 onboarding 流程並進行 A/B test

整體流程可整理為：

事實 → 分析 → 行動

或：

觀察 → 假設 → 驗證

強化 HITL 的判斷力訓練

AI 時代的 Code Review 焦點會發生轉變。

傳統 Code Review 焦點AI 時代 HITL 的焦點：判斷力
命名是否規範、縮排是否正確可觀察性：這段 code 出錯時，是否有足夠 log 可以追蹤？
演算法是否最優彈性與韌性：AI 寫的邏輯是否過於僵化？是否難以維護？
語法錯誤意圖對齊：這段 code 真的解決需求，還是只是看起來很專業？

Intent-Based Review 應包含：

  • 總結
  • 風險清單
  • 強化的測試思維

Prompt Refinement 本質上就是敏捷

在 AI 時代，真正的敏捷精神不只存在於傳統 Scrum 流程，也存在於每一次 Prompt Refinement。

透過 Iterative Prompt Refinement，我們可以把粗略的初始 prompt 視為 MVP，然後不斷進行：

  • 觀察輸出
  • 找出不足
  • 給出針對性調整指令
  • 讓結果一輪比一輪更好

這正是敏捷中的：

Inspect & Adapt

Progressive Refinement

第一次 Prompt 就像丟出一個粗略的 User Story，AI 快速交付一個 MVP 版本的輸出。

接著進行觀察與回饋，檢視：

  • 是否不夠清楚
  • 是否有邏輯漏洞
  • 是否風格不符
  • 是否細節不足

然後下達新的 prompt，例如：

  • 請根據上一個輸出，增加……
  • 優化……的部分
  • 用更專業的語調
  • 避免……

持續精煉，直到輸出接近理想結果。

每一次與 AI 互動，都是一次完整的敏捷循環：

假設 → 觀察 → 驗證 → 修正

AI 產出與可觀察性設計流程

可以將 AI 生成與可觀察性設計整合成以下流程。

Step 1：預設

  • 設定 AI 的監控規則
  • 準備具備 OpenTelemetry 的程式碼模板

Step 2：產出

  • 透過 Vibe Coding 生成功能
  • 功能與埋點一起產出

Step 3：觀察

  • 運行測試
  • AI 分析 log
  • 驗證邏輯正確性

Step 4：控制

  • 套用 Harness Feature Flag
  • 控制效能與觀察開關

Step 5：優化

  • 移除冗餘 probe
  • 建立乾淨且高效能的系統

也可以問 AI：

看著你產出的 Log，告訴我你那時候在想什麼？

這個問題的目的，是讓 AI 將自身產出的行為、log 與意圖進行對照，協助人類驗證：

  • 行為是否符合設計目標
  • 產出是否具備可解釋性
  • 系統是否具備可觀察性
  • 是否能從 log 反推 AI 的決策脈絡

觀測抽樣與效能控制

可觀察性不是越多越好，而是要依照環境與需求動態切換。

抽樣等級

等級採樣比例用途
偵錯級 Debug Level100%驗證與除錯
適應級 Adaptive / Intelligent Sampling5% ~ 50%捕捉隨機故障與分析異常
穩定級 Production Baseline0.1% ~ 1%健康監測
關斷級 Muted / Off0%停止觀察或關閉特定探針

觀察模式

模式效能損耗適用情境
Deep Trace極高驗證與除錯
Smart Watch中捕捉隨機故障
Eco Mode極低健康監測

原則是根據環境與需求動態切換，不要在不重要的地方埋太多探針或做過度優化。

阿姆達爾定律與觀測成本

阿姆達爾定律（Amdahl’s Law）用來計算：當你只優化系統中某一部分時，對整體效能提升的上限是多少。

公式為：

$$Speedup = \frac{1}{(1 - P) + \frac{P}{S}}$$

其中：

  • $P$：系統中可以被優化的部分所佔比例
  • $S$：該部分被優化後的加速倍數

例如，如果你優化的部分只佔整體的 10%，即使把它加速到無限大，整體提升也不會超過約 1.11 倍。

這提醒我們，可觀察性與效能優化都應該聚焦在真正重要的瓶頸，而不是在低影響區域過度投入。

四、看板與可觀察性

看板方法與可觀察性

看板方法與可觀察性都在幫助我們「看見系統」，但兩者關注的面向不同。

看板：讓知識工作變得可見

看板關注的是「事情怎麼做」。

它協助觀察：

  • 現在有哪些工作？
  • 工作卡在哪裡？
  • 哪些事情在排隊？
  • 哪些步驟過載？
  • 從開始到完成花了多久？
  • 交付速度是否穩定？

可觀察性：看見系統內部狀態

可觀察性關注的是「事情做的結果」。

它協助觀察：

  • 系統現在是否健康？
  • 哪裡變慢了？
  • 哪個服務出錯？
  • 錯誤是偶發還是持續？
  • 問題影響哪些使用者？
  • 為什麼會發生這件事？

兩者結合後，可以同時看見工作流與系統行為，將人、流程與技術狀態連接起來。

假設思維與可觀察性

Douglas Hubbard 曾說：

量化並非追求絕對精準，而是為了減少不確定性。

這句話非常適合用來理解可觀察性。

可觀察性與量化的目的，不是得到完美答案，而是降低決策的不確定性。

練習題：估算早餐店三明治銷量

題目：估算明德捷運站附近早餐店的三明治銷量。

估算公式：

Total = 客流量 × 購買轉換率 × 三明治選擇比率

目標客群與流量：07:00–09:00

  • 學生族群：約 1,000 人，步行經過轉角
  • 通勤族群：約 2,000 人，尖峰時段經過店門口
  • 總潛在流量：約 3,000 人

假設推論與計算

  • 轉換假設：10% 潛在客流會進店購買早餐
  • 進店人數：約 300 人
  • 選擇比率：40% 進店者選擇三明治

計算：

300 × 40% = 120 個

預估一天的三明治銷量約落在：

120 到 150 個

這個練習的重點不是算出絕對準確數字，而是透過假設、估算與量化，逐步減少不確定性。

從多模型視角談與 AI 共智

AI 時代的開發與決策，不只是單一模型產出答案，而是人類與多模型共同思考、交叉驗證與持續學習。

關鍵能力包括：

  • 提出假設
  • 透過可觀察性驗證
  • 依據證據決策
  • 接受不確定性
  • 持續調整與迭代

人類在 AI 時代的價值，體現在：

  • 洞察力
  • 勇氣
  • 韌性
  • 決策力

總結

AI 的產出不是答案，而是假設

AI 生成的程式碼、文件或決策建議，都需要被觀察、驗證與修正。

可觀察性是治理 AI 不確定性的基礎

透過 metrics、logs、traces 與情境資料，才能理解 AI 與系統互動後的真實行為。

工程師角色正在轉變

工程師不再只是 coding 的執行者，而是：

  • 定義問題的人
  • 設計系統的人
  • 驗證假設的人
  • 管理不確定性的人

Prompt Refinement 就是敏捷循環

每一次與 AI 的互動，都是一次：

假設 → 觀察 → 驗證 → 修正

未來的核心能力是判斷力

在 AI 能大量產出內容的時代，人類最重要的能力不是更快地寫，而是更準確地判斷：

  • 這是否符合意圖？
  • 這是否能被驗證？
  • 這是否具備可觀察性？
  • 這是否真的解決問題？

讓 AI 的 Observability 與不確定性共舞，代表我們不再追求完全消除不確定性，而是建立一套能觀察、驗證、調整與學習的系統。

AI 時代的工程師，應透過可觀察性、假設思維與 HITL 機制，將不確定性轉化為可管理的風險與可累積的知識。