前言：能寫程式碼，不等於能交付
用 AI 寫一段程式碼，現在沒什麼難的。難的是用 AI 交付一件有人在等、有期限、出錯會被看見的東西。
這兩件事的差別，在第三週才會顯現。
前兩週你會覺得一切順利：AI 產出快、你改得動、進度看起來很好。到了第三週，你開始發現有些檔案不知道是哪個版本、有些決定不記得為什麼那樣定、有兩條線各自改了同一份文件而你不知道哪份是對的。再過一週，你花在「搞清楚現在到底是什麼狀態」的時間，超過你花在推進的時間。
我最近用 36 天交付了一件這樣的東西——一場實作型工作坊，包含課程設計、環境建置、教材、簡報、示範影片，以及現場帶場。全程用 AI 協作，最後 162 次版本提交、38 條平行工作線、54 份交接文件。
它沒有在第三週崩解。這篇文章拆解為什麼。
一、五個階段：交付鏈的骨架
先講骨架。任何有交期的交付，都會走過這五個階段——差別只在你有沒有把它們分開。
Phase 1 · 設計（Design）
這階段 AI 的職能是：選項生成、矛盾偵測、規格收斂。
不是「幫你想」，是「陪你想」。差別在於：AI 提出選項並指出它們之間的矛盾，決定仍然是你做的。
實務上最有價值的一件事，是 AI 會發現你自己看不到的衝突。當你說「這一段要壓在 20 分鐘」，同時又說「這三件事都要講清楚」，它會把這個矛盾攤在你面前，而不是默默把三件事都寫進去然後產出一份 35 分鐘的稿子。
這階段我改了四次整體結構，最後一次是把整套教學主軸推翻重來。每一次改版都留下一份定案紀錄，包含「為什麼廢掉上一版」。 這件事在第五週救了我一次——當我想把某個舊設計改回來時，那份紀錄告訴我當初為什麼放棄它。
Phase 2 · 建置（Build）
這階段 AI 的職能是：多線平行執行。
這是 AI 協作跟傳統工作最不一樣的地方。我同時推進四條線：教材、簡報、環境、影片。四條線各自有自己的工作目錄、自己的交接檔，互不干擾。
平行的前提是隔離。 沒有隔離的平行不是平行，是混亂——兩條線改到同一份檔案，你要花的時間比循序做還多。
這階段還有一個關鍵決定：有三種技術路線可以選時，不要用推理選，用實測選。 我在 agent 的設定架構上卡了很久，三條路各有理由。最後的做法是三條都實際搭一次最小可行版本，跑跑看，然後選那條真的跑得動的。花了半天，省下後面兩週的返工。
Phase 3 · 演練（Rehearse）
這階段 AI 的職能是：缺口盤點與時間帳記錄。
這是最容易被跳過、也最不該跳過的階段。
我做了四輪演練：先是全程走查（紙上），然後是分線試跑，然後是錄影下來用學員視角看一遍，最後是真人完整走一遍。
四輪的價值完全不同。前三輪抓到的是「流程有沒有斷」，第四輪抓到的是「人會不會照你想的那樣做」。
最刺痛的一次發現是：機器複驗過、標記全過的項目，真人一跑就翻案了七項。 因為機器會照著你寫的路徑走，人不會。人會在你沒想到的地方停下來、會用你沒預期的方式理解一句話、會在應該往下的時候往回捲。
從那次之後我的判準改了：機器驗過的只能算「沒有明顯壞掉」，不能算「可以了」。
Phase 4 · 修補（Remediate）
這階段 AI 的職能是：根因定位。
演練會產出一張翻案清單。修補階段的重點不是「照清單改」，而是先問每一項的根因是什麼。
這裡有個反直覺的發現，我認為是這次最有價值的一課：
問題往往不是規則缺漏，而是規則位置錯誤，或與同一段落裡的另一條指令衝突。
我遇到的具體狀況是：agent 沒有照規則停下來等授權。第一反應是「規則沒寫清楚，補一條」。但實際去看，那條規則本來就在——寫得清清楚楚，只是位在整個段落的最後面。而段落開頭有另一句話寫著「一次做完再一起回報，中間不要停下來問」。
兩條指令直接打架，而 agent 讀到前面那句就開始執行了。
如果當初直接「補一條規則」，會補出第三條互相矛盾的指令，然後問題照舊。 真正的修法是把它移到段落最前面當前置關卡，並拆掉那句衝突的話。
這件事後來實跑驗證過：改完之後，agent 會先列出計畫、講出缺了哪幾項、然後停下來等一句「可以，動手」才繼續。同一個環節的耗時也從十分多鐘降到五分鐘——因為它不再做那些沒被要求的事。
Phase 5 · 交付（Deliver）
這階段 AI 的職能是：即時監控與異常回報。
現場的重點是把「感覺不太對」變成「具體是誰、卡在哪、多久沒動」。
我在開場前做了一個即時儀表板，掃描每個人的進度、教出來的技能數、產出的檔案數、最後一次動作距今多久。超過五分鐘沒動作的自動標色並列進警示區。
這東西的價值不在技術，在於它把注意力從「全場」收斂到「這三桌」。帶場的人只有一雙眼睛，儀表板決定那雙眼睛該看哪裡。
二、五道機制：讓平行不崩解的東西
階段是骨架，機制是讓骨架不散開的韌帶。沒有這五項，38 條平行工作線會在第三週變成一團無法收拾的東西。
機制一：工作線隔離
每條工作線一個獨立目錄，以時間戳命名。跨線的檔案不共用，要共用就明確走「交付」而不是「兩邊各改一份」。
聽起來很基本，但真正的價值在於：當你回頭問「這件事當初是怎麼決定的」，你有一個明確的地方可以找。
機制二：交接檔接力
這是整套機制裡最重要的一項。
AI 的記憶會斷。 不管是 context window 滿了、session 重開、還是隔天回來，那個「知道整件事來龍去脈」的狀態不會自動延續。
解法不是想辦法讓它記得更多，是把狀態寫進檔案。每條工作線收工時留一份交接檔，寫三件事：
- 做完了什麼（帶證據，不是「已完成」三個字）
- 還沒做什麼
- 下一個接手的人從哪裡開始
54 份交接檔聽起來很多，但那正是 38 條線能平行推進的原因。檔案不會忘記。
機制三：實查優先於回報
這一條是整篇文章我最想留下的。
「執行回報成功」與「結果真的存在」是兩件事。
AI 會告訴你「已完成部署」。這句話的意思是「我執行了部署指令而且沒有收到錯誤」，不是「東西真的在那裡而且是對的」。
這兩者之間的落差，是所有 AI 協作事故的溫床。
我的做法是把它寫成硬規則：所有驗收一律回到系統逐項查證，不接受執行回報當證據。 要確認 30 個環境的設定，就去讀那 30 個環境的實際設定，而不是看部署腳本回報了幾個成功。
這條規則的代價是慢，收益是你不會在最後一刻才發現東西根本沒生效。
機制四：決策權保留
AI 攤開選項、後果、以及反悔成本；人做決定。
「反悔成本」這一項常被忽略，但它其實是最重要的資訊。同樣是兩個選項，一個改錯了五分鐘能還原、另一個改錯了要重做兩天——這個差別應該在做決定之前就攤在桌上，而不是事後才發現。
交付的最後 24 小時裡，我做了 9 次這樣的決定。每一次 AI 都給了建議，但沒有一次是它自己執行的。
機制五：可逆設計
改動之前先備份。這句話太老套，但在 AI 協作的情境下它有新的意義：
AI 的執行速度快到你來不及後悔。 傳統上你手動改 30 個地方要花一小時，中間有很多次機會發現不對勁。現在一個指令 30 秒改完，等你發現不對，已經全改完了。
所以備份不是好習慣，是必要的基礎設施。
實際發生過：一項改動同時套到 30 個地方，事後發現方向是錯的。因為改動前備份了原文、而且改動腳本本身就寫了還原模式，五分鐘全部還原。
三、最真實的一課
上面那些都是可以寫進投影片的東西。這一節不是。
交付前 12 小時，我做了一個看起來完全合理的修正。
情境是這樣：使用者登入之後，落點不對——會停在一個不該停的畫面。我判斷是路徑沒指定清楚，於是在 30 個地方的網址後面補上明確的目標路徑。
理由充分、邏輯通順、改完自己也驗過了。
然後它是錯的。
那段路徑沒有指定「在哪個應用程式底下」，於是系統自己挑了一個預設的——結果反而把使用者從我精心配置的環境裡踢出去。改之前落點是對的，改之後才變錯。
發現它的方式，不是 AI 自我檢查，不是我重讀一次自己的邏輯。是一個人看了一眼實際畫面，然後問了一句「為什麼這裡長這樣？」
我回頭去查那 30 個環境的實際設定，才發現它們本來就會落在正確的位置——那段路徑從頭到尾就不需要，是我多做的。
五分鐘後全部還原。
這件事我後來反覆想。真正可怕的不是 AI 會出錯，是：
AI 會很有把握地做錯事，而且理由聽起來完全成立。
它不會表現出不確定。它會給你一段推理，每一步都對，結論卻是錯的——因為推理的前提是它自己補上去的，而那個前提沒有被驗證過。
這正是「實查優先於回報」這條規則存在的原因。它不是為了防範 AI 說謊——AI 不說謊。它是為了防範一段看起來很有道理、但沒有人去現場看過的推理。
結語：機制是給第三週的自己準備的
如果只能從這篇文章帶走一件事，我希望是這個：
前兩週你不需要這些機制，第三週你會需要，而第三週才開始建就來不及了。
交接檔、工作線隔離、實查規則、可逆設計——這些在專案初期看起來都像多餘的儀式。它們的價值不在當下，在於三週後那個記不得任何細節、面對 38 條線的自己。
AI 讓產出變快了。它沒有讓「搞清楚現在是什麼狀態」變快。
這中間的落差，就是機制要填的東西。