💡 核心結論速覽 (TL;DR)
- AI 驗收的重點不是事後檢查，是交辦當下就寫進去：Claude Code 創造者 Boris Cherny 建議只講三件事——要什麼成果、不能碰哪些界線、怎樣算做完，步驟讓模型自己決定。
- 放手的門檻不在 AI 有多強，在你驗收有多快：Andrew Ng 明說「懶人提示」是進階技巧，只適用於你會逐一檢查輸出的場合；寫死在程式裡反覆呼叫的情境不適用。
- 最危險的不是 AI 出錯，是它不會說「我不確定」：人類同事卡住會來問你，AI 會挑一個最像對的答案繼續做完，錯誤被包裝成完整交付。
- 下一步：先用 5 道關卡裡的第 1 道（可執行性）跟第 4 道（反向抽查）試一週，這兩道不花錢也不用改設定，是投報率最高的起手式。
你有沒有過這種經驗：把一件事丟給 AI，回來一看，格式漂亮、段落工整、該有的都有，結果真正拿去用的時候才發現——中間有一段是它自己編的。
我每天用 AI 的時間超過 10 小時，從查資料、跑排程到整理素材都靠它。踩久了我得到一個結論：AI 出的包，九成不是「它做錯了」，而是「我沒講清楚怎樣才算做完」。所以這篇要談的不是怎麼下指令，是AI 驗收——當你決定放手不盯了，用什麼標準接住它的產出。
最近 Claude Code 的創造者 Boris Cherny 在一場活動上說了一句被瘋傳的話：別站在 AI 背後盯螢幕。但很多人只轉了前半句。真正難的是後半句：你要拿什麼來接住它的產出？
「別盯著 AI 做事」的後半句：AI 驗收才是真正難的部分
Boris Cherny 的完整建議其實是三件事，不是一件：具體描述你要的成果、設定必要的防護界線、定義怎樣才算成功完成——至於要用哪些步驟達成，交給模型自己判斷。他的原話是「接著就放手讓模型發揮，過一會兒再回來看看」，還補了一句「我想它會讓你感到驚訝」。
注意這三件事的性質：成果是入口，護欄是邊界，完成標準是出口。它們全部都是驗收條件，沒有一項是執行步驟。
他觀察到的常見錯誤，是使用者把工作拆得極碎，要求模型先做第一步、再做第二、第三、第四步。「對現代模型來說，這種做法其實真的不太適合。」這句話值得記下來——因為多數人學到的「提示詞技巧」，剛好就是教你把步驟拆細。
更有意思的是，同一時間有另外兩個人在講同一件事。Andrew Ng 提出過「懶人提示」（lazy prompting）：先丟一句簡短、甚至不夠精確的指令，看模型能不能完成，再依實際需要補充。
另一位是《Clean Code》作者 Uncle Bob Martin。他在 X 上表示，自己現在完全不讀 AI Agent 寫出來的程式碼，改用單元測試、行為測試、QA 流程、程式碼品質指標與測試覆蓋率去約束產出（此段轉引自中文媒體對其貼文的報導）。
三個人的做法看起來不一樣，底層是同一個轉向：把控制點從「過程」搬到「入口和出口」。以前你靠盯著它做來確保品質，現在你靠交辦時講清楚、交付後驗得準。
我帶團隊那幾年最深的體會也是這個。一個主管如果要靠每天站在同事後面看螢幕才能安心，問題通常不在同事身上，在於這個主管自己沒有能力定義「什麼叫做好」。盯過程是驗收能力不足的替代品，不是管理方法。
下一步：把你最近一次交給 AI 的任務調出來看，數數看你寫了幾個「步驟」、幾個「完成標準」。如果步驟多於標準，這篇後面的內容對你會很有用。
為什麼盯著 AI 做事，反而讓它表現更差？
盯著 AI 一步步做事有兩個代價，而且都是你當下感覺不到的。第一個代價是你的指令會佔掉模型的注意力預算，第二個是你把它能想到的更好解法提前封死了。
先講第一個。以 Claude Code 為例，官方在 記憶檔說明文件裡把話講得很白：專案規則檔建議控制在 200 行以內，因為「更長的檔案會消耗更多脈絡，並降低遵守度」。Anthropic 官方部落格講得更狠——每一行都會載入每一個工作階段，這會消耗 token，並且稀釋掉那些真正重要的指令的遵守度。
白話翻譯：規則不是寫越多越保險。你多寫的那三十行瑣事，是在跟你真正在乎的那兩條紅線搶注意力。
這裡還有一個很多人不知道的陷阱。官方文件明講，用匯入語法把規則拆成好幾個檔案，對整理有幫助，但不會減少脈絡佔用——因為被匯入的檔案一樣會在啟動時全部載入。所以「我已經拆檔了應該有省到」這個安心感，很多時候是假的。
第二個代價更隱形。你規定它先做一、再做二、然後三，等於是把你自己想得到的解法上限，變成它的天花板。Cherny 的說法是，使用者這樣做通常是低估了現代模型已有的能力；他也坦言，Anthropic 內部到現在都還在陸續發現模型的新用途。
我自己吃過這個虧。有陣子我習慣把資料整理任務寫成十幾個步驟，某次懶得寫，只丟了一句「我要一份能直接判斷的對照表，來源必須是官方頁面，查不到的欄位寧可留空也不要猜」。
結果它自己去做了交叉比對，還主動標出兩個官方頁面互相打架的地方——那是我原本的步驟清單裡根本不會有的動作。我那份「很完整」的步驟清單，其實是在幫它降級。
如果你想更完整了解脈絡怎麼被吃掉、怎麼看它花在哪，我把 Claude Code 每天真正省時間的設定整理在這篇隱藏功能與指令心法，裡面那招 /context 可以直接看到你的規則檔佔掉多少空間。
下一步：打開你的專案規則檔數一下行數。超過 200 行，先砍掉「AI 自己看程式碼就知道」的那些描述，留下它猜不到的地雷。
AI 驗收非做不可的理由：它不會說「我不確定」
AI 驗收之所以非設不可，關鍵在一個很少被講明的差異：人類同事卡住的時候會來問你，AI 不會。
帶過人的都知道，新人交件前那句「這邊我不太確定，想跟你確認一下」有多寶貴。那是一個免費的警示燈，它讓你知道風險落在哪一段。AI 沒有這盞燈。它遇到資訊不足的時候，會用最像對的方式把空缺填起來，然後把整份東西完整地交給你。
錯誤被包裝在一份看起來很完整的交付裡——這才是真正的風險所在。它不是「做壞了一半停在那」，而是一份 95% 正確、5% 是編的、而且你看不出接縫在哪的成品。
這也解釋了為什麼「感覺它做得不錯」完全不能當驗收標準。感覺只驗得到表面的完整度，驗不到內容的真偽。我測過讓 AI 做需求估算，同一份需求給不同模型，出來的數字差距大到必須打對折才敢用，這個實測我寫在AI 產品估算到底準不準這篇——結論是它給的數字很有自信，但自信跟準確度沒有關係。
Andrew Ng 對「懶人提示」設的那個但書，正是同一件事的另一面。他明確說這是進階技巧，能不能偷懶的前提，是你有能力快速判斷模型的輸出好不好；他還特別排除了一種情境——寫死在程式裡、反覆呼叫 API 的提示詞不適用，因為你不會去逐一檢查每一個輸出。
把這句話反過來讀，就是本篇最重要的判準：能不能放手，取決於你驗收有多快，不是 AI 有多強。驗收速度跟不上，放手就只是把問題延後爆炸而已。
下一步：下次收到 AI 的產出，先別問「這做得好不好」，改問「這裡面哪一句話是我沒辦法立刻查證的」。那句就是你的風險點。
AI 驗收要從交辦寫起：成果、護欄、完成標準
真正有效的 AI 驗收，不是等東西回來才開始，而是在交辦的那一刻就把驗收條件寫進去。這是 Cherny 那三件事的實用價值——它們不是客套話，是可以逐項填空的模板。
我自己現在交辦任務的寫法大概長這樣，三個欄位缺一不可：
❶ 成果：我最後要拿到什麼東西、什麼形式、給誰用。不是「幫我研究一下 X」，而是「一份我能直接拿去做決定的對照表」。
❷ 護欄：哪些事絕對不能做。這裡要寫的是不可逆的動作和你的紅線，不是操作偏好。例如「不要動這個資料夾以外的檔案」「查不到官方來源的數字就留空」。
❸ 完成標準：怎樣算做完。這是最多人漏掉、也最關鍵的一欄。標準必須是可以被驗證的，不能是「做得完整一點」。
下面這張對照表是同一個任務的兩種寫法，差別很明顯：
| 寫法 | 細拆步驟（舊習慣） | 成果＋護欄＋完成標準 |
|---|---|---|
| 交辦內容 | 先搜尋 5 個來源，再整理成表格，然後寫摘要，最後加上結論 | 我要一份能直接判斷「該不該換方案」的對照表 |
| 界線 | （通常沒寫） | 只引官方頁面；查不到的欄位留空，不要推測 |
| 怎樣算做完 | （通常沒寫） | 每個數字都附得上來源連結，且我能在 3 分鐘內抽查任一格 |
| 驗收時你要做的事 | 從頭讀一遍，憑感覺判斷 | 抽查來源連結，對不上就退回 |
差別在哪？左邊那欄，你交出去的是流程，收回來的時候手上沒有任何客觀依據，只能整份重讀。右邊那欄，你交出去的是標準，收回來時你知道要抽查什麼。
這個框架跟寫給不同工具的規則檔可以搭著用。如果你同時在用別的程式開發代理，我把四要素框架跟規則檔的寫法整理在Codex 提示詞與 AGENTS.md 這篇；至於一般聊天視窗裡怎麼把需求講得讓它聽懂，則整理在Claude 提示詞的 8 個技巧與 12 組模板，那篇偏「怎麼交辦」，跟這篇的「怎麼驗收」剛好是一頭一尾。
還有一個很現實的提醒：如果你發現自己寫不出完成標準，那通常不是 AI 的問題，是你自己還沒想清楚要什麼。這種時候硬丟出去，收回來一定是失望。我帶團隊時最怕接到這種需求，現在角色對調，我才知道當年那些同事有多辛苦。
下一步：把「怎樣算做完」這一欄，加進你今天要交辦的下一個任務裡。只加這一欄，你會立刻感覺到差別。
我留下的 5 道 AI 驗收關卡
AI 驗收要有效，關卡必須排在「最省力的檢查」前面、「最花時間的檢查」後面，任何一關沒過就直接退回，不要往下走。以下五道是我留下來每天在用的，順序有意義。
❶ 可執行性：先讓它自己撞牆
能跑的東西就先跑一次，能開的連結就先開一次，能對的數字就先對一格。這一關幾乎不花你的時間，卻能篩掉大部分的問題。Uncle Bob 的做法就是這個邏輯的極端版——他不讀程式碼，改用測試和覆蓋率當第一道閘門。能讓機器驗的，絕對不要用眼睛驗。
❷ 來源可追溯：每個數字都要問「你哪裡看到的」
凡是它給的具體數字、日期、規格，都要有對得上的出處。這一關專門對付前面說的「95% 正確、5% 是編的」。實務上我不會每個都查，我查最關鍵的那兩三個——通常是會影響決定的那幾個。
❸ 完成標準逐條對
把交辦時寫的完成標準拿出來，一條一條打勾。這一關的重點是不要憑印象。人在看到工整的排版時會不自覺放鬆標準，逐條對是唯一的解藥。
❹ 反向抽查：挑它最有把握的地方查
這是我覺得最有用、也最少人做的一關。多數人會去查自己看不懂的部分，但錯誤最常藏在它講得最流暢、最有自信的段落——因為那正是它在填空的地方。挑一段它寫得最漂亮的，往下追一層問「這個結論的依據是什麼」，很多問題會在這裡現形。
❺ 副作用檢查：它有沒有動到你沒叫它動的東西
最後看一次範圍。有沒有多改了檔案、多寄了東西、多開了權限。這一關在自動化流程裡特別重要，因為代價通常不可逆。
我自己就在這關上摔過一次：用瀏覽器自動化去批次檢查頁面，結果一路觸發了不該被觸發的紀錄。那次的教訓我寫在這篇無效流量的踩坑紀錄裡——問題不在腳本寫錯，在我沒有事先想清楚「它跑起來會碰到什麼」。
這五關的排序邏輯很簡單：越便宜的檢查排越前面。第 1 關讓機器做，第 2、3 關花你幾分鐘，第 4、5 關需要你動腦。任何一關沒過就退回重來，不要抱著「後面再補救」的心情往下走——那通常會變成你自己重做一遍。
如果你的任務是持續性、會重複跑的，那就值得把前三關固定下來變成自動檢查。這種「讓機制去守規則、而不是每次靠交代」的思路，我在迴圈工程那篇談得比較完整，非工程師也看得懂。
下一步：這週先固定做第 1 關跟第 4 關就好。這兩關不用改任何設定、不花錢，卻能擋掉最多問題。
哪些事我到現在都不放手？3 條紅線
放手是有邊界的，而且邊界的判準不是「這件事難不難」，是「做錯了能不能救回來」。我自己有三條線，到現在都不讓 AI 全自動跑完。
第一條是不可逆的動作：刪檔、覆蓋、送出、付款、公開發布。這類事情的共同點是沒有復原鍵。真實案例不少見——有工程師連喊 11 次「不要動」，資料庫還是被清空了。我把這類災難跟該設的防線整理在AI agent 刪檔事件與 5 道防線那篇，如果你已經開始讓 AI 碰你的檔案，建議先看那篇再往下做。
第二條是對外的東西：任何會被別人看到、且掛你名字的產出。不是因為 AI 做不好，是因為出錯的代價落在信任上，而信任修不回來。
第三條是我沒有能力驗收的領域。這條最容易被忽略。如果一個領域我自己完全不懂，我根本沒辦法判斷它有沒有在編——這種時候放手不是效率，是賭博。Ng 那句「前提是你有能力快速判斷輸出好壞」就是在講這個。
反過來說，適合放手的任務長這樣：
- 結果可以被機器驗證：能跑、能對、能比，錯了會自己報錯
- 錯了可以還原：有版本控制、有備份、有草稿狀態
- 你懂這個領域：看得出哪裡怪，抽查得動
- 重複性高：值得花一次時間把驗收條件寫好，之後一直複用
不適合放手的則是：一次性、不可逆、對外、而且你自己也不熟的任務。這四個條件湊齊兩個以上，我就會退回去用「它做一段、我看一段」的模式，寧可慢一點。
如果你還在猶豫要不要把工作流交給這類工具，非工程師的評估角度我整理在Claude Code 值得學嗎這篇，裡面有比較完整的取捨判斷。
下一步：拿一張紙把你想交給 AI 的任務分成「能還原」跟「不能還原」兩堆。不能還原的那堆，先留著自己做。
放手之後，成本和方案會怎麼變？
放手會讓單次任務變貴、總時間變便宜，這是必須先講清楚的取捨。當你不再一步步下指令，模型會自己去讀更多檔案、跑更多輪，token 用量通常是上升的。
這件事很現實：你省下的是自己的時間，付出去的是用量。所以放手前值得先算一下你的使用強度落在哪個區間。
| 使用情境 | 適合的做法 | 要注意的成本 |
|---|---|---|
| 偶爾用、任務短 | 不用急著放手，一段一段看反而快 | 免費或入門方案通常夠用 |
| 每天用、任務重複 | 值得把驗收條件寫成固定模板 | 用量會明顯上升，注意額度重置週期 |
| 整天掛著跑、多線並行 | 把前三道關卡自動化 | 方案等級是主要成本，需要實算回本點 |
如果你正在考慮要不要往上升方案，我把 Claude 各檔的實際差異算過一輪，包含哪些情況多付錢其實買不到你以為的東西，整理在Claude 訂閱方案怎麼選這篇；純粹想先把用量壓下來的話，砍半 token 的心法那篇會更實用。
我的判斷是這樣：先確定你的驗收流程順了，再考慮升級。驗收沒設好就升方案，只會讓你更快地產生更多不能用的東西——而且是用更貴的價格。這順序反過來的人，我看過不少。
另外一個常被忽略的成本是你自己的注意力。放手的真正好處，是讓你在它跑的時候可以去做別的事；如果你放手了卻還是每三分鐘去看一眼，那你其實兩邊的好處都沒拿到。
下一步：這個月先不要升級。把 5 道關卡跑順，再回頭看用量報表決定要不要加錢。
FAQ 常見問題
放手讓 AI 自己做，跟一步步下指令，我該選哪一種？
判準是你的驗收速度，不是任務難度。如果這個任務的結果你能在幾分鐘內驗完（能跑、能對、能查證），就放手；如果驗一次要花的時間比自己做還久，那就一段一段來。
Andrew Ng 特別提醒過，「懶人提示」是進階技巧，前提是你有能力快速判斷輸出好壞。他也說多數人的問題其實是脈絡給太少而不是太多，複雜任務他自己也會花 30 分鐘寫兩頁的提示詞。所以這不是非黑即白，是看你手上有沒有接得住的網子。
我已經寫了很詳細的規則，為什麼 AI 還是不照做？
因為規則檔的性質是「脈絡」而不是「強制設定」。Claude Code 官方文件講得很清楚：這些內容會被讀進去參考，但不保證嚴格遵守，寫「絕對不要動某個檔案」比較接近一個請求，而不是一道保證。
要真正擋住某個動作，得改用會在事件發生時強制觸發的機制（例如權限設定或 hook），而不是靠文字交代。官方也提到，如果兩條規則互相矛盾，模型可能會任意挑一條執行——所以規則不是越多越安全，定期清掉過期和打架的條目更重要。
驗收 5 道關卡全部都做，會不會比自己動手還慢？
第一次會，之後不會。這五關裡面，第 1、2、3 關都是可以固定下來重複使用的，尤其是任務會重複發生的情況——把完成標準寫成模板，之後每次交辦直接複製。真正花時間的是第 4 關的反向抽查，但那一關通常只需要挑一到兩個點深追。如果你發現每次都要全篇重讀才敢用，那代表問題出在交辦階段的完成標準沒寫清楚，不是驗收關卡太多。
不會寫程式的人，這套驗收方法用得上嗎？
用得上，而且更需要。這五道關卡裡只有第 1 關偏技術（讓機器先跑一次），其他四關——來源可追溯、完成標準逐條對、反向抽查、副作用檢查——完全不需要寫程式，套用在整理資料、寫文件、做簡報、查資訊上都成立。反而不會寫程式的人更需要第 2 關和第 4 關，因為你沒辦法靠讀原始碼來判斷它有沒有在編。
怎麼知道我的規則檔是不是太肥了？
官方給的參考值是單一檔案控制在 200 行以內，超過會消耗更多脈絡並降低遵守度。實際檢查方式是用 /context 這個指令，它會列出這次工作階段實際載入了哪些記憶檔、各佔多少空間——不要用猜的。
順帶提醒一個很多人誤會的點：用匯入語法把規則拆成好幾個小檔案，對整理有幫助，但那些檔案一樣會在啟動時全部載入，拆檔本身並不會省下空間。真正該做的是把「只在特定情況才需要」的內容移出去，而不是換個地方放。
結論：先設得出驗收條件，才談得上放手
回到最開始那句被瘋傳的話。「別站在 AI 背後盯螢幕」聽起來像是在講信任，其實在講能力——你必須先有能力定義什麼叫做好，才有資格不看過程。
我帶團隊學到的那套，套到 AI 身上幾乎沒有變：講清楚要什麼、講清楚底線在哪、講清楚怎樣算做完，然後在收件時老實地逐條對。唯一不同的是那盞警示燈——同事會舉手說「我不確定」，AI 不會。所以那盞燈得由你自己來當。
如果這篇對你有幫助，歡迎訂閱我的部落格，會不定期收到信；我也把 AI 工作流的其他實測整理在Claude Skills 的 8 大情境推薦跟Codex／Claude Code 常見問題大全，想少踩點坑可以順著看下去。關於我怎麼一邊帶產品一邊經營這個站，可以看我的自我介紹。
參考資料
- Claude Code 官方文件：How Claude remembers your project（記憶檔規格、200 行建議、匯入不省脈絡、/context 檢查法）
- Claude Code 官方文件：Extend Claude Code（各機制的脈絡成本與取捨判準）
- Anthropic 官方部落格：Steering Claude Code（規則稀釋遵守度的說明）
- Y Combinator：Boris Cherny 談打造 Claude Code
- Business Insider：Claude Code 創造者建議停止微管理 AI（原始報導）
- DeepLearning.AI The Batch：Andrew Ng 的來信專欄（lazy prompting 出處）
- 未來商務：Claude Code 之父曝新提示詞心法（中文報導）
