重構是最想交給 coding agent 做、也最不敢交給它的工作。重構不該帶來任何新功能，所以每一個改動都可能弄壞原本好好的東西。
2026 年 10 月 17 日，我們用 Clawdline 重構了 Clawdline 自己：一台機器、一天、二十多個 Claude Code Session 動手，一個人做決定。不需要信任任何一個 agent，因為沒有一個 agent 能批准自己的工作。
第一份計畫被整份退回，退得有道理
那天從一次架構審查開始。我們開了六個唯讀 Session，各自讀自己程式碼的一個部分再回報。它們找到的問題都是真的，負責協調的 Session 把看起來最糟的幾個整理成五個看板項目。
使用者讀了第一個項目，五個步驟全部否決，理由很短：改了也沒有人感覺得到。那份計畫是照「程式看起來多錯」排的，不是照「誰付出了什麼代價」排的。
接著使用者自己訂了標準：daemon 跑得快不快，以及同一段邏輯散在幾個地方、重複寫了幾份。從此每一個提案都要附數字。第一個數字就改寫了計畫：daemon 自己的 CPU 將近一半，花在每 2 秒重建一次 817 筆早已凍結的 task。這些 task 屬於一個月前就退役的舊 app。
一個目標一個看板項目，一次落地一個步驟
所有工作都放在看板上。一個目標一個項目，例如「清掉沒有人用到的程式碼與資料」；項目底下列著步驟，每一步小到一次就能審完，也一個 revert 就能退回。
那天真正派上用場的是看板的三條規則：
- 項目沒有驗收條件，就不能進入實作。協調 Session 有一次忘了寫，看板直接拒絕切換，於是在任何程式合併之前，驗收條件就先補上了。
- Plan 不能由 agent 認領。把 Plan 轉成可執行的工作、取消項目，都是使用者在看板上的動作。範圍一直握在使用者手上，因為沒有 agent 改得動它。
- 步驟要驗證過才算完成，不是寫完就算。commit 要在
main上，而且要使用者點頭。
寫程式的 Session，從來不審自己的程式
每一個步驟都走同一條流水線。每個 Session 都用一個內建角色啟動，在自己專用的 checkout 裡工作。
| 角色 | 做什麼 | 能寫入什麼 |
|---|---|---|
| 協調者（architect 角色） | 回到原始碼核對事實、寫每份 brief、合併、安裝、量測 | 只有它能合併到 main |
| 實作（backend、performance 或 minimal-change 角色） | 完成一個步驟的改動，跑相關的測試 | 只有事先宣告過的路徑 |
| 審查（code-reviewer 角色） | 讀 diff，在拋棄式 checkout 重跑檢查 | 什麼都不能寫 |
| 寫測試（test-automation 角色） | 在動手之前，先寫測試把現在的行為釘住 | 只有測試檔 |
| 使用者 | 決定範圍、決定不可逆的步驟、親手跑 E2E | — |
那天一共用了 12 個實作 Session、10 個審查 Session，另外還有一次唯讀稽核和一次量測。實作 Session 做完會主動通知協調者，沒有任何東西靠輪詢在等。會寫到同一批檔案的兩個實作一前一後跑，唯讀的工作則同時進行。
審查找到了測試抓不到的東西
審查改變了最後出貨的內容，因為每一條發現都寫明審查者看過哪個檔案、哪一行。
有一個審查發現，某個改動可能讓手機的 Session 列表在手機明明還連著的時候，最多四分鐘不更新。測試全部通過，因為沒有一個測試涵蓋「手機還連著，relay 卻短暫把它算成離開」的情況。這個問題在合併前就修好了。
另一個審查為了檢查一個守衛測試，寫了八種繞過它的寫法，結果守衛一種都沒抓到。第三個審查則發現，一個等價測試從來沒有單獨跑過增量更新的那條路徑。測試要親眼看過它變紅，綠燈才算證據。每一個修正，都有 Session 故意把錯誤改回去，確認新測試會失敗，才相信它。有一次第一次的錯誤放錯了位置，測試仍然是綠的。
每次落地都先安裝、量測，才做下一步
每次合併之後，協調 Session 都會在同一台機器上安裝 dev 版本；動到已存資料的步驟，安裝前先備份資料庫。裝好之後，再量一次 daemon。
那天下午使用者大半時間不在。要使用者親手做的 E2E 累積起來，等使用者回來時整理成一份八項的清單。沒有任何東西只憑 agent 一句話就進 main。審查的結論、本機檢查全綠、安裝後正常啟動，三樣都要先到位。
犯錯的 Session，不是發現錯誤的那一個
小隊確實犯了錯，最嚴重的一次是我們自己。協調 Session 把一個舊的設定資料夾移進垃圾桶，但裡面還放著另一個專案的排程在讀的憑證。那個專案的 Session 發現排程失敗，把檔案放回原位，再傳訊息通知協調者。整個過程沒有人介入。
另外兩次，問題來自別處。做到一半，介面忽然變成英文：原因是另一個 Session 寫的文案裡有一段選單路徑，被 daemon 自己的文案檢查擋掉了。現在有一個測試會在提交前抓到這種情況。後來推送到 main 時被拒絕，因為主分支的 CI 是紅燈。協調者在本機把失敗的測試重跑五次，只重跑 CI 上失敗的那個 job，兩邊都綠了才推送，沒有用任何方式跳過檢查。
這次重構，Clawdline 幫我們做到的事
使用者這一天花的時間在做決定，不在盯進度。拆解、實作、審查、合併、安裝與量測，全部由 Session 分工完成。
- 範圍一直握在使用者手上。 看板讓 agent 規劃、執行，但只有使用者能把 Plan 變成工作，或取消一個項目。
- 沒有人看著，工作也照樣往前走。 使用者整個下午都不在：看板記著每一步做到哪裡，Session 做完會通知協調者，每一次落地都留下紀錄。
- 每一個改動都有第二個讀者、都有一個數字。 所以一天就能淨刪 4,383 行、把 CPU 降到十分之一，不需要使用者逐一讀過每一份 diff。
派工、審查與落地的完整順序在工作流程指南。為什麼不能只看那顆綠燈，可以讀「做完了」其實有四種意思；派出去的 Session 怎麼及早喊停，則在還來得及在第三分鐘喊停的工作。
第二輪是使用者回來之後，一邊用手機回報 bug、小隊一邊修，寫在一邊重構，一邊修你從手機回報的 bug。