為什麼閱讀 AI 的產出這麼累？我現在 review AI 的產出，有些部分會直接跳過不看，就讓它做下去。
欸？開玩笑？
聽起來很不負責任，但這背後要做一個關鍵判斷：「沒發現的錯誤修起來多貴」，決定我們要讀多細。以前實作很貴，spec 錯一個地方，下游全部重來，所以上游必須逐字精讀。現在 coding agent 把實作壓到分鐘級 — 很多錯誤與其花十分鐘 review 防它，不如讓它先跑下去，跑出來再修，前後可能不用三分鐘。
這是我 review AI 產出的第一個操作：問，這裡的錯誤如果漏掉了，修起來貴不貴。
便宜的，掰，先走； 貴的，來，討論。
但「貴的部分」還是很多啊。spec、planning、feature list，每一份都又長又密，從 AI 開始流行寫 markdown，我很少能真正讀完。所以第二層問題才是重點：在必須讀的範圍裡，怎麼決定哪些東西該燒腦、哪些不該？
我目前作法把「認知負擔」管理，套上去 review AI 的產出。
一、我們一天只有 100 點
先給一個我自己很常用的比喻：每個人一天就只有 100 個「認知點數」 — 一天能消化資訊、做出判斷的總額度。點數燒完，再重要的東西到面前，我們也只剩「隨便啦，先跑看看」。
所以 review 效率的問題，可以重新定義成一個資源分配問題：這 100 點，該怎麼花。
教育心理學有一個 1988 年的理論可以直接拿來用 — Sweller 提出的 Cognitive Load Theory（認知負荷理論）。它把人處理資訊時的負荷分成三種：
- Intrinsic load（內在負荷） — 白話：這件事「本來就難」的部分。資料結構怎麼設計、模組/業務邊界切在哪，難度在問題本身，換誰來讀都一樣難
- Extraneous load（外在負荷） — 白話：不是內容難，是包裝爛，是呈現爛，是「欸你好不會講」。用散文寫系統架構，我們得自己在腦中重建結構；教 AI 畫成一張圖，一眼就懂，何苦？這裡多燒的點數，就是浪費的負荷
- Germane load（有效負荷） — 白話：搞懂這個系統實際上怎麼運作所花的點數 — 在腦中建立起一套「它是怎麼動的」的模型（mental model）。三種點數裡面最重要，真正貢獻產能的
拆開之後，分配策略就出來了：減少 Extraneous、分層 Intrinsic、提前準備 Germane。
二、減少 Extraneous：在 session 開始前，就把 review 邏輯定義好
AI 生成的 spec 讓人累，大部分時候不是內容真的難，是它常用散文在包裝結構。我們的腦在做的事情是解析 — 從一堆文字裡重建出資料流、依賴關係、決策點。這個解析成本就是外在負荷，而它本來可以小很多。
怎麼把它降下來？我的做法是：在專案或 session 開始的時候，就先定義好接下來每個階段的 review 邏輯。比方說：
- Spec 階段 — 用 conceptual diagram（概念圖，把結構跟資料流畫成一張圖），不要散文
- Planning 階段 — 用「表格」，不要散文
- 產出階段 — 直接附上對照 checklist，跟 acceptance criteria
這樣做有兩個效果。第一，輸出從一開始就長成我們要的樣子。第二，這套 review 邏輯可以複用，它就是我們的記憶。
判斷有沒有做對也很簡單：同一份資訊換個形式之後 review 時間大幅下降，省下來的就是原本被包裝吃掉的點數。三種負荷裡這一種的壓縮空間最大，所以工具跟 workflow 的優化預算，放這裡最划算（但我看模型商也會慢慢做掉）。
三、分層 Intrinsic：用抽象的方式讀，不要用細節的方式讀
內在負荷砍不掉 — 該我們做的決策，畫成再漂亮的圖還是得自己決策。能做的只有控制「同時面對多少」。
十幾年前資工研究所的時候，洪逸老師（就是立委洪毓祥啦～）他常說的，你們的思考一定要是「樹狀的」。
具體做法是分層：把抽象層級由上往下切開，一次只面對一層，每一層只問一個問題：
- Spec 層：解的是對的問題嗎
- Planning 層：拆的方式對嗎 — 順序、依賴、風險
- 細節層：做法對嗎
而且老實講，連 planning 層的順序跟依賴，有時候我也直接讓 AI 自己排 — 呼應開頭講的，這類錯誤的修正成本夠低，先往下推進就好，跑出問題再調。
review 到很累的人，常常是用細節層的眼睛在讀 planning，每一行都想驗證。但是抱歉，推石頭上山，這不是 AI 工具的最佳實踐。planning 階段根本不該驗證細節 — 軸錯了，細節再對也沒用；軸對了，細節錯了 AI 下一層自己會修掉。
一份 spec 裡九成的內容 AI 自己就填得對。內在負荷真正集中的地方，是那 5% 到 10% 的不可逆決策 — 資料結構、模組邊界、對外介面。我會直接要求 AI 把它們標出來：「這幾個是我做的決策，請你確認」，其他掃過就好。
這裡再加一個判斷：分清楚「不變的核」跟「可變的殼」。資料結構跟行為意圖是核（這就是物件導向設計的兩大關鍵），動了就是大事；UI/UX 是殼 — 它有大量現成參考、隨時可以被置換，本身只是一層操作體驗的優化。所以 UI/UX 我會放到最後看，甚至先不看，把點數留給核。
四、前置 Germane：我們的工作是做判斷，不是做閱讀
這是我覺得最關鍵、但最少人意識到的一步。
「我們的工作是做判斷，不是做閱讀」
Germane load 的重點在於「做判斷」。而做判斷的具體做法，是差異比對，不是閱讀理解。
什麼意思？在請 AI 生成 spec 之前，先花一兩分鐘在腦中形成預期 — 預期它會提到哪三件事、不該出現哪兩件事。沒有預期就開始讀，我們是在用 AI 的結構重建自己的腦袋，那是閱讀理解，當然慢。有了預期再讀，我們只是在比對「它哪裡跟我想的不一樣」 — 差異跳出來，判斷，下面一位～～
我們需要的不是閱讀理解，是閱讀差異。
五、做好這些之後 — 讓它自己跑完
把前面三件事做好，會發生一件有趣的事：long-running agent 就在那，放手就好。
因為現在的 AI 能力其實已經夠強了，多數時候它不是做不到，是不知道我們要什麼。只要前期把 intention（意圖 — 我們到底要它解什麼問題、做到什麼程度）確認清楚，再把 Acceptance Criteria（驗收標準 — 白話講就是「這個系統要怎樣才算 work」：哪些功能要達標、用什麼操作方式驗證）先寫好，讓 agent 自己用對應的方式去測 — 網頁就跑網頁、手機就接 simulator — 它是可以一路自己跑完 end-to-end 的。
這時候我們追求的指標會變成 first-pass acceptance rate（一次就通過驗收的比率）：它交出來的東西，每一項都一次達標。前面 intention 設計得越乾淨、驗收定義得越清楚，這個數字就越高 — 而 review 本身，從「讀」變成「對答案」。對答案不可能燒你多少點數的。
學會降低自己的認知負擔
如果你最近覺得 review AI 的內容負擔很重，先講一句：這非常非常正常。AI 的產出速度對每個人都是毫秒級，人腦的頻寬有限，大家都一樣（痾，大眾、平民的話）。
差別只在於，有沒有學會降低自己的認知負擔。
認知負擔不會因為 AI 變快而消失， 但必須靠我們來分類、搬家。
包裝太爛造成的消耗，搬給 AI；問題本身的難，一層一層來；理解系統要做的功課，搬到最前面先準備。
下次累的時候，先不用怪自己讀太慢。問一個問題就好：我現在燒的這些點數，是哪一種負荷？
我更慘，每天點數還要留一些給小孩燒。hello? AI age? Come on!