「看起來正常」還不夠：AI 工作流需要的三種證明
一個週報排程沒有寄出，系統卻沒有報錯；一個 agent 回報過去三十天只發了一篇文章，實際數字是六十一篇；一個驗證腳本收到 HTTP 200，打開的卻只是網站首頁。
這不是三個假設案例，而是台灣 Ultra Lab 公開的一人加 AI 運作事故。
它們最危險的地方，不是系統崩潰，而是系統看起來仍然正常。排程顯示成功、儀表板保持綠色、agent 交出一個看似合理的答案；直到錯誤數字被用來做決定，人才發現流程其實沒有完成。
第一眼的答案很直覺：加監控、加告警。
這些案例顯示，真正的問題不只是「怎樣監察自動化」。當 AI 開始參與發文、研究、驗收與決策，一條工作流至少需要回答三個不同問題：
- 事情真的完成了嗎？
- 關掉 AI 後，我仍然懂得判斷嗎？
- 下一次，系統還會不會重新發明同一個錯？
這是 AI 工作流需要的三種證明：完成證明、判斷證明，以及學習證明。
它真的做了嗎？
Ultra Lab 把一人加 AI 的工作分成幾層：上層負責策略、規格與否決，下層負責施工並證明完成；上線、對外承諾與破壞原有規格，仍要由人批准。
這是一位 practitioner 公開的治理方式，不是所有一人公司都必須照搬的標準。Ultra Lab 同時經營相關 AI 產品，案例也主要來自自己的工作流。
但它指出了一個容易被忽略的問題：系統回報成功，與工作真的完成，是兩件事。
一個排程可能成功觸發，卻沒有寄出郵件；一個 API 可能回傳 200，內容卻是錯的；一個 agent 可能正常產生答案，取數範圍卻少了一個 collection。
所以，驗收不能只問「有沒有報錯」，至少還要問三件事：
- 流程有沒有觸發？
- 有沒有產生預期產出？
- 產出內容是否正確？
Ultra Lab 使用 heartbeat 區分「沒有觸發」與「觸發後失敗」，再用 positive control 驗證檢查工具本身是否真的有效。
Positive control 的意思是：先給驗證工具一個你已知一定存在的答案。如果連已知答案也找不到，問題可能不是內容不存在，而是你的檢查方法根本沒有工作。
因此，較窄的結論不是「所有上線都必須由人手按按鈕」，而是：
每個不可逆出口，都需要一個清楚的責任人，以及獨立於系統自我回報的完成證據。
這正是 SOLO 裏的 Outcome 與 Ownership：先定義甚麼叫真的完成，再定義誰對最後的不可逆結果負責。
AI 可以執行，排程可以觸發，程式可以驗證；但責任不能因為工具變強而消失。
關掉 AI，我還會判斷嗎？
完成證明處理的是系統有沒有做事。第二種證明處理的是另一個容易被綠燈掩蓋的問題：有 AI 時交付變好，是否代表使用者真的變得更專業？
Autor 等人在 2026 年發表一項預先註冊的三個月隨機對照試驗。研究涵蓋十一家美國知識產權律師事務所、共一百三十三名執業專利律師。部分律師獲得 Google Labs 尚未公開的專利起草助手 InFlow，其他人作為對照組。(NBER Working Paper 35720；VoxEU 解說)
在有 AI 協助的專利起草任務裏，處理組的草稿品質在第 10 天提高 0.34 個標準差，第 90 天提高 0.38。改善主要來自減少低品質草稿，而 junior 律師在品質與節省時間方面得到的即時幫助最大。
到這裏，很容易得出「AI 幫助新人學得更快」的結論。
但研究還加入了一個重要對照：三個月後，所有律師都要在沒有 AI 的情況下，審改一份有缺陷的專利申請。
處理組整體仍比對照組高 0.32 個標準差，但提升集中在擁有七年以上經驗的 senior 律師；junior 律師平均沒有進步，分數反而出現兩極化。
換句話說，獲得最多即時交付改善的人，不一定留下最多可獨立使用的判斷能力。
這項研究的範圍很窄：樣本只有一百三十三人，觀察期只有三個月，對象是專利律師，反映的是約 2024 至 2025 年的模型能力。研究由 Google 提供直接成本，數名作者受僱或承包於 Google。它不能證明 AI 普遍削弱新人能力，也不能直接推論到所有行業。
我們最多可以說：
量度 AI 是否有用，不能只看有工具時的作品；還要另外測量沒有工具時，使用者能否獨立完成需要判斷的任務。
對一人公司來說，這點尤其重要。很多時候，我們同時是交付者與學徒：今天需要把工作完成，也需要累積明天可以獨立使用的判斷。
因此，可以把兩個目標分開量：
- 交付表現： 有 AI 時，成果是否更快、更完整、更準確？
- 能力保留： 關掉 AI 後，我是否仍能指出風險、解釋原則、覆核例外？
AI 可以參與 REACTOR 的 Create，但 Examine、Assess 與 Test 不能只剩下一個「接受」按鈕。
下次還會犯同一個錯嗎？
即使工作真的完成、人的判斷仍然存在，還有第三個問題：系統是否從錯誤中留下了可以重用的知識？
很多人建立 agent 記憶的方法，是把過去所有對話、筆記與成功步驟塞進下一次的 context。資料愈來愈多，但真正需要的答案反而更難找到：
- 這種錯以前有沒有發生過？
- 上次判斷錯在哪裏？
- 哪個修正已經試過但沒有改善？
- 哪些策略在甚麼條件下成功？
Google Research 與 Virginia Tech 的 WikiSkill 研究，把 agent 的經驗分成三層：
- Raw layer： 保存完整執行紀錄，包括工具呼叫、輸出與最終答案。
- Wiki layer： 從成功與失敗紀錄中整理模式、成因、可行策略及被否決的修改。
- Skills layer： 保留 agent 執行當前任務真正需要的簡短程序。
候選 skill 修改要先經過驗證。表現改善才保留；沒有改善就退回上一個版本。但即使修改被退回，wiki 仍然保存這次嘗試、驗證結果與拒絕原因，讓下一輪不必重新提出同一個失敗方案。
這項研究測試的是數學推理、搜尋、試算表、長文件問答與互動任務等 benchmark，不是企業營收，也不是已被普遍驗證的公司知識管理方法。
不過，我從這個架構抽出的實務原則是：
執行時需要的指示應該短；從經驗累積的學習可以長。成功方法要留下，已被否決的錯也不應消失。
一條成功 SOP 只告訴我們現在怎樣做。失敗記憶則回答另一個問題：為甚麼不能走回那條看起來合理的舊路？
如果 agent 只記得「正確流程」，卻沒有保存「週報漏寄但沒有警報」「HTTP 200 其實只是首頁」「統計只讀了一個 collection」這些診斷，下一次仍可能用一套看似合理的方法重複失敗。
這就是 REACTOR 的 Refine 不應只做版本更新的原因。真正的 Refine 還包括留下：
- 錯誤在甚麼條件下發生；
- 當時為甚麼看起來正常；
- 哪個修正已被否決；
- 下一次用甚麼證據較早發現。
一張二十分鐘的「三種證明卡」
不用先建立新的 dashboard，也不用一次重寫整套工作流。
選一條你已經使用 AI 或自動化的流程，例如發文、週報、資料整理、研究或驗收。用二十分鐘回答下面四個問題：
| 問題 | 寫下一個具體答案 |
|---|---|
| 完成證明 | 除了綠燈或「成功」訊息，甚麼可觀察產出證明它真的完成？ |
| 判斷證明 | 關掉 AI 後，我仍能獨立完成哪一個需要判斷的子任務？ |
| 學習證明 | 最近哪個失敗模式已被記錄，下一次不應再從零診斷？ |
| 責任人 | 哪個不可逆出口需要我明確批准？ |
不要在同一天修好所有問題。
如果「完成證明」答不到，就先補一個 heartbeat 或 positive control。
如果「判斷證明」答不到，就保留一次不使用 AI 的對照練習。
如果「學習證明」答不到，就記錄最近一個真實失敗，包括成因與被否決的修正。
如果「責任人」答不到，就暫時不要擴大自動化範圍。
AI 工作流最大的風險，不一定是模型突然犯下一個明顯的大錯。更常見的情況是：每一個畫面都看起來正常，直到你把錯誤結果當成事實。
所以，在增加下一個 agent、排程或 dashboard 之前，可以先問：
它真的完成了嗎？
沒有它，我仍然懂得判斷嗎？
下一次，我們還會重新發明同一個錯嗎？
三個問題未必令工作流看起來更先進，卻比多一盞綠燈，更接近一套可以信任的系統。
來源
Practitioner 經驗
研究
- Does AI Assistance Enhance or Erode Expertise? — NBER Working Paper 35720
- Better work, not always better workers — VoxEU／CEPR
- WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution — arXiv
DISCUSSION
讀者留言