做 AI 工作流一年，90% 的時間在做這件事——直到我換了思路
你有沒有做過這種事：用了 AI 工具，結果發現，自己花最多時間的，不是在「做」，而是在「確認它做對了沒有」？
我統計過一段時間自己做 AI 工作流的時間分配，結果得到了一個有點刺眼的數字：真正在設計新東西、在建立新流程上，大概只佔一成。剩下的九成，全部耗在手動驗證——打開頁面、輸入測試資料、盯著輸出、用肉眼判斷這次到底是變好了還是變壞了。
這還不是最讓人崩潰的部分。
最麻煩的是，AI 系統本身就存在不確定性。有時候我只是改了一個很小的地方，整個流程就跑不對了。更讓人沒底的是，光看輸出，很多時候根本沒辦法一眼判斷到底有沒有出錯——只能再跑一遍，再跑一遍，再跑一遍，靠感覺去評估。
做到這一步，我才意識到：我的工作已經不是在「建 AI 工作流」，而是在反覆手動驗證一個連自己都有點快看不懂的系統。
這正常嗎？這值得嗎？有沒有更好的辦法？
驗證的不對稱性：你的時間為什麼會被這樣吃掉
帶著這個問題，我後來找到了一個概念，精準解釋了為什麼這個問題不只是我個人的毛病。
2025 年，OpenAI 和 Meta 的研究員 Jason Wei 提出了一個觀察，叫做「驗證的不對稱性（Verification Asymmetry）」：很多事情做起來很難，但要驗證它做得對不對，卻相對容易。例如，解一道數學題很難，但確認答案對不對只要幾秒鐘；寫一篇文章很難，但判斷它有沒有偏題只要讀一遍。
順著這個觀察，他提出了一條定律，叫做 Verifier’s Rule：任何可解且易於驗證的任務，終將被 AI 解決。
第一次讀到這句話，我覺得它很抽象。但帶入自己的情況之後，我發現它在說的，正是我的核心問題：
在我建的 AI 工作流裡，生成變得很便宜——AI 幫我產出、速度快、幾乎不需要成本。但驗證還很貴——要靠人眼盯著看、靠感覺判斷、靠人腦評估好壞。這就是那個不對稱。
換句話說：如果我能把「判斷這個工作流做得對不對」這件事，從一個靠感覺的難題，變成一套可以自動執行、可以重複、可以產生數字的驗證機制——那我就是把一個難驗證的問題，親手改造成了一個容易驗證的問題。
一旦它變得容易驗證，按照這條定律，剩下的工作就可以交給 AI 了。
我的角色，就從「那個一直盯著螢幕跑測試的人」，變成了「設計那套可驗證架構的人」。
一個三十年前就解決了同樣問題的行業
這個思路轉換聽起來還是很抽象？我找到了一個更具體的類比，來自一個意想不到的地方。
晶片設計。
做晶片的人有一個外界很少知道的現實：在一個晶片設計團隊裡，負責「驗證」的人，往往比負責「設計」的人多。驗證工程師可能是設計工程師的兩倍、三倍，甚至更多。整個行業的工作比例，大概是設計佔三成，驗證佔七成。
為什麼？
因為晶片一旦流片出錯，沒有補救的機會。幾百萬美金直接打水漂。沒有「改一個 bug、重新部署一下」這種好事。所以整個行業，被現實倒逼著，把大部分精力壓在同一件事上：在它真正上線之前，把所有可能出錯的情況全部找出來。
他們怎麼做到的？
回歸測試（Regression Testing）：每次有任何改動，就跑一遍全套測試。確認新的改動沒有讓舊的東西壞掉。不靠感覺，靠數字。
斷言（Assertion）：在系統裡埋下一組硬性檢查點——到了某個步驟，某件事情必須成立。不成立就直接報警，不需要人眼掃描輸出。
覆蓋率（Coverage）：有一個指標衡量「我到底測了多少種情況」，主動尋找測試的盲區，而不是假設自己測得夠全了。
記分板（Scoreboard）：追蹤每次跑完的分數，看趨勢，看哪個版本比哪個版本好了多少，而不是靠感覺判斷這次跑起來感覺比上次順。
這套框架，整個晶片行業用了三十年。
當我第一次把這個行業的工作框架對應到自己在做的 AI 工作流開發，我有點被震到：形狀幾乎一模一樣。
我做的 AI 工作流，和晶片設計面對的問題是同一個：如何在一個複雜的系統上，可靠地找出問題，而不是靠人眼、靠感覺、靠反覆手動跑？
當 AI 讓「建一套工作流」變得越來越容易——就像當年 EDA 工具讓「寫晶片程式碼」變得越來越容易一樣——你的價值就不只在於「會用工具做出東西」，而在於「能不能設計出一套讓每一次改動都可以被驗證的架構」。
第一步不是寫測試，而是讓你的系統對 AI 友好
知道了「需要建驗證架構」之後，我面對的第一個問題，其實出乎我意料。
問題不是「怎麼寫測試程式碼」，而是更根本的一件事：我現在這套工作流，另一個 AI 有辦法直接讀懂它、操作它、取得它需要的資訊嗎？
我之前的 AI 工作流，入口是一個網頁介面——是給人用的。要測它，就得有個人在那邊點一下、輸入一下、盯著看一下。這個系統從第一天起，就是為人的眼睛和手設計的。
普林斯頓大學的 SWE-Agent 研究裡有一個概念叫做「Agent Computer Interface（ACI）」，指出：AI agent 是一類全新的使用者。它不是人，所以你不能假設為人設計的介面對 AI 也有用，你需要為它們專門設計介面。
更讓我在意的是他們實驗的結論：介面設計的好壞，對 AI agent 的表現影響，甚至大過換一個更強大的模型。
換句話說：你的工作流能不能被 AI 自主操作、自主取得它需要的資訊，這是一個比「選哪個模型」更根本的問題。
在這個基礎上，我做了一個決定：把我的工作流前後端徹底分離。
後端變成一個可以獨立執行的系統，所有的呼叫都能透過命令列控制，不需要網頁介面；前端退到一邊，只負責把資訊呈現給人看、讓人操作，不是主要的執行入口。這樣，我用來跑測試的 AI 工具（例如 Codex），就能直接讀到整條工作流跑了哪些步驟、呼叫了哪些工具、中間狀態是什麼、最後拿到了什麼輸出——不需要靠人眼轉譯。
這步做完，系統才真正對「另一個 AI」開放。
兩層裁判：確定性邏輯加上 AI 判斷
系統對 AI 友好之後，才輪到真正建驗證機制。
AI 工作流的輸出，很多都是一大段自然語言，或者一條執行路徑——它不是一個可以直接數字相比較的東西，所以傳統的「通過或不通過」型測試，不夠用。
我的辦法是把「裁判」拆成兩層：
第一層：確定性斷言。
這是一組硬性檢查，針對那些有明確答案的問題：在某個輸入條件下，某個工具應該要被觸發嗎？跑到某個步驟，資料記錄的數量是否在預期範圍內？某條關鍵路徑有沒有跑到？這一層的特點是完全可靠、確定性的、幾乎零成本。不需要動用 AI，就能卡住大部分明顯的錯誤。
第二層：AI 裁判（Supervisor）。
第一層卡不住的模糊部分，才交給一個獨立的 LLM 來判斷。這個 LLM 的上下文要非常乾淨——它不參與工作流的開發，不知道程式碼的來龍去脈，它眼裡只有一件事：這次的輸出，符合我對「正確」的預期嗎？
重要的細節是：面對那些沒有標準答案的輸出，我不讓它做「對或錯」的二元判斷，而是讓它量化打分——這次比上次好了多少？差了多少？
有了分數，就有了趨勢。有了趨勢，就不需要靠感覺。
這套兩層設計，確定性的卡硬性規則，AI 裁判處理模糊地帶，讓整個驗證架構既可靠又能處理 AI 輸出天生的不確定性。
功能開關：讓你能比較「之前」跟「之後」
有了驗證機制，還有一個讓整件事大幅加速的做法：每加一個新功能，就配一個開關（feature flag）。
開關的好處是什麼？
你有了「開」跟「關」兩個版本，讓它們跑同一套回歸測試，就能清楚地看到：這個新功能到底帶來了什麼改變？哪些地方變好了？有沒有悄悄弄壞了其他東西？
沒有開關的情況下，每次改動，你對比的是「現在」跟「記憶中的之前」——有誤差、不可靠、容易騙自己。有了開關，對比是在同一個測試環境下、同一套標準下進行的——數字說話，不靠感覺。
閉環的最後一步：讓 AI 收拾自己造成的問題
有了對 AI 友好的系統、有了兩層驗證架構、有了功能開關，最後一步是把整件事閉環。
具體做法是這樣：
當 AI 工具（我用的是 Codex）需要開發一個新功能，它不只是去寫程式碼。它按照一個固定的流程走：
- 先設計這個新功能的回歸測試，定義什麼叫「成功」
- 配上功能開關
- 才去寫程式碼
- 打開開關，跑一遍測試，看結果
- 根據測試結果，修改程式碼
- 反覆執行，直到測試通過
整個過程，不需要人盯著。AI 工具透過那套可驗證的架構，把迴圈自己收斂起來。
到這一步，我做的事情不再是「寫程式碼」，也不再是「手動測試」。我做的是：把「什麼算對」定義清楚，然後讓閉環自己運作。
那個九成的手動驗證，就這樣真的變成自動的了。
這對你意味著什麼
我說這麼多技術細節，並不是要你照著我的做法複製一套一模一樣的架構。
每個人的工作流不同、工具不同、問題不同。
我想讓你帶走的，其實只有一個問題：
在你自己的 AI 工作流裡，那個九成在哪裡？
你用 AI 做了很多事，但有沒有一個環節，你每次都在反覆手動確認？有沒有一個步驟，你靠感覺評估好壞，卻說不出一個可以追蹤的指標？有沒有一個瓶頸，讓你覺得「AI 好像沒有真的省到我的時間」？
如果有，那就是你的那個九成。
一年前，大家在討論「要不要用 AI 來做事？」今天，這個問題已經消失了，因為大家都在用。
現在的問題是：你怎麼用，才能比別人的效率更高？
如果你用了 AI，結果原本十分鐘的事情，你花了兩個小時，輸出一樣——那這不是效率的提升，是換了工具但沒有改變系統。
AI 把「做事情」這個動作的成本壓低了。你真正的價值，在於你能不能設計出一個讓「做對事情」這件事也變得自動、可重複、有指標的架構。
找到你的那個九成，然後問自己：有沒有辦法讓它從「靠肉眼靠感覺」，變成「可以自動、可以量化、可以追蹤趨勢」？
一旦做到，那九成的時間，就真的回到你手裡了。
我是 Ray Kuo（raykuo.aiflow）——一個人 × 一套 AI 工作流的實踐者。我們下一篇見。
本文方法與案例為本人實作，草稿由 AI 協助整理。