讓 Claude Code 連續寫三個小時的程式，不停下來
這支 Reels 紀錄的是一個亂玩的 project — 有前後端的 prototype，整包 spec 跟 acceptance criteria 寫好之後，丟給 agent 自己去跑。
實際上是分兩段：第一段跑了 1 小時 43 分，把我當天的 usage 額度燒光；換帳號接著跑第二段，又跑了 1 小時 19 分。第二段主要在補 E2E test — 因為這是亂玩的 project，前期我 spec 轉 test case 沒轉得很完整，有些 case 沒做對，有些卡進了 defer queue，後面再讓它補一輪 😭
即使是這樣的條件，agent 整體還是一路自己 plan、implement、跑 E2E test、寫 hand-off，完全沒人為介入，跑完才來找我做最後驗收。
這套流程最適合的場景就是長時間任務 — 打 prototype、做 MVP、實作一個全新的 feature。這類任務的特性是：方向相對明確、acceptance criteria 可以提前寫死、不太會卡在歷史 codebase 的奇怪 constraint 上，agent 可以一路跑下去而不需要中斷問人。
真正決定產出可不可用的，是這三件事
跑完之後最有感的不是「它真的能跑三小時」這件事，而是要讓這套流程穩定運作，模型本身已經不是瓶頸。
1. 跨 session 的 context 傳遞
長時間執行最大的敵人是 context 累積，到某個臨界點一定會做 compaction，準確率就會掉。解法是 — 即使在同一個 session 裡，也要用「跨 session」的方式去設計。
每完成一個 feature，就把當下的決定、改動、未解問題、下一步寫進一個 machine-readable 的 hand-off log。下一個 feature 開始時，從這個 log 重新讀進來，而不是從污染的 context 繼續 — 把 context window 當 RAM，filesystem 當 disk。
2. 自己設計的 scaffolding
不能讓 agent 隨意走它想走的路。
開發類型、任務類型不一樣，scaffolding 也會長得不一樣 — 沒有一套通用的範本。但結構上要綁死的東西是一樣的：planning 用一套 skill、implementing 用一套、reviewing 一定要換另一個 agent（agent 自評永遠太正面）、E2E test 又是另一套。每一步的 input、output、acceptance criteria 都要明確，不留空間給 agent 自己詮釋。
scaffolding 寫一次可以跑很多次 — 這是現在最該投資的東西。
3. First-pass acceptance rate
Martin Fowler 在《reduce friction ai》裡面提到：與其追蹤「time to first output」，不如追蹤「first-pass acceptance rate」 — 第一次產出就直接可用的比例。
如果這個數字不夠高，跑得再快都是假的，最後還是要花同樣的時間在改 code。要把這個數字拉高，靠的是 spec 寫得夠精準、acceptance criteria 夠明確、測試項目有抓到關鍵情境。
像我這次第二段要回頭補 E2E，本質就是 first-pass 沒做夠。
人類的瓶頸要往前移、往後移
跑完這三個小時，更具體的感覺是 — coding agent 的速度已經快到一個地步，人類完全跟不上。也不需要跟上，幹嘛跟紡織機比紡織速度🤣
那人類的瓶頸就不能再放在「打字產出 code」這一段，要往前移到 spec 撰寫、設計決定，往後移到 review 跟驗收。實作那段交給 agent。
我覺得未來的開發型態會分成兩條軸線。
新功能開發這一邊，前期會花非常多時間在建構一份精確而且明確的 spec。什麼叫精確而且明確？至少要包含兩件事：完整的 User Experience 設計、以及最重要的 Acceptance Criteria。把這兩件事做夠細，後面 agent 就有辦法一路跑到底，第一次就交出可用的結果。
維護這一邊也會變成同一套流程；當一個需求或 bug 進來，系統會自動進入 fix 流程：
- 找出 Root Cause
- 設計幾個修正方案
- 設計對應的 End-to-End test
跑完之後甚至直接走自動部署 — 整個 fix 流程從進單到上線，中間人類只需要測試跟做最終決策。
這兩條軸線指向同一件事 — 嚴謹度沒有消失，只是從「寫 code 那一刻」移位到「定義問題」跟「驗收結果」這兩端。
這是 2026 年的 Rigor Relocation。