別全盤收下 AI 的交付：三欄點評法

給 AI 派活，最順的時候是它一次做對；最常見的翻車，是你嫌麻煩，直接點「採納」——然後錯誤跟著進了你的交付物。

說兩個真實的。上個月做合規檢查，AI 給我貼了段審計截圖，末尾寫了句「全部通過」。我手指停在滑鼠上想：截圖裡到底是 23 個 PASS 還是 20 個？一條提示中間是不是混了個 WARN？沒細看，這截圖就要進週報。再看一個：讓 AI 出封面圖，腳本明明報「HTTP 200」，我拿眼睛一 squint——載入出來是 502 報錯頁。200 也是騙人的。

這兩個坑有共同點：AI 把「看起來像結果的東西」打包給了你，而你省下的那 30 秒判斷時間，後面要翻數倍的本。

我的解法很簡單，把每次 AI 交付劃成三欄，先分揀再動手。

三欄長什麼樣

拿到交付，別急著貼，先在腦子裡過三檔：

**整段重寫**：方向錯了，或者與你原本的訴求衝突。比如你要的是「給老闆看的一頁紙」，它給你三千字小作文這種。這時候別改，丟回去重做，並且把「哪裡偏離了」說清楚。

**改一段**：大方向對，局部有問題——術語用錯、某段數據沒出處、格式跑偏。這檔是重頭戲：給出明確、完整的反饋，讓 AI 自己改。比如「第二段把『顯著提升』換成具體數字，沒有數據就寫『暫無』」。

**腦補**：AI 沒寫但你必須確認的缺口。工程交付裡這叫 missing edge case——報錯分支、邊界值、空數據；寫作则是「它答應過的第三部分根本沒寫」。這欄最常被人漏，也最容易要命。

兩個讓分揀變快的規則

一、內容優先於格式。先判「說的對不對」，再看「寫得好不好」。格式問題永遠可以最後統一收一次，內容錯了越晚發現越貴。

二、一次反饋只說 1-2 個點。人話：AI 的反饋吸收能力比你想像的低，五條意見打包過去，它經常只改第一條，剩下四條乾瞪眼。分批餵，每批看到改完的結果，再餵下一批。

什麼時候別用這套

也別神化它。兩種場景我不分揀：一是探索期讓它隨便試，目的是發散，挑肥揀瘦反而把討論掐死；二是你本來就要全權外包、按它的結構走的東西，分揀就是給自己加戲。還有，一次性的小任務（比如翻譯一句話），分揀的成本比省下的還高。

五步速查

1. 拿到交付先停 10 秒，不當場貼。

2. 過三欄：重寫 / 改一段 / 腦補。

3. 內容先於格式，先抓「對不對」。

4. 反饋一次只給 1-2 點，帶上原始訴求，別說「你懂的」。

5. 活過自己這關才准交付——AI 說「完成了」不算數，你得親眼核過。

三個常見翻車點

**信了它的「已完成」**。AI 說自己全部改完，不代表它改對了。上次它「修正」了一段 SQL，存下的一看，WHERE 條件整個被它刪了。它匯報的完成度和真實完成度是兩回事。

**攢著反饋最後一次性發作**。攢到收尾一股腦丟 10 條，AI 消化不動，你也忘了哪條是上次說的。反饋要像餵飯，小口、趁熱。

**「改一段」改兩次還沒好就硬掰**。同樣的偏差改兩輪還在，說明我對齊的不在一個頻道上——這時候該升級成「整段重寫」，把背景、訴求、約束重新交代一遍，比繼續修補快得多。

三欄法不玄乎：重寫、改一段、腦補，就這麼三格。配合這兩天寫的「接力筆記」（活太長才換會話）和「驗收陳述法」（收口前逐條報數），AI 交付這條線——接活、幹活、驗活——就閉環了。今天再交活給 AI 之前，先把這三格裝進腦子，省下的時間夠你多喝一杯咖啡。