開 Project、Session、Worktree、PR 的時機——AI 輔助開發的五層隔離
判準不是「大小」，是「這一層要隔離什麼」
用 AI 同時開好幾條線寫程式時，很快會遇到一個問題：什麼時候該開新的一條，什麼時候該留在原地？
答案不是看改動大小，而是看這一層要隔離什麼。五層由粗到細：
層 它隔離的是 多久開一次 --- --- --- Project（repo） 產品／部署目標 幾乎不開，一年幾次 Work（工作項目） 一件能獨立驗收出貨的事 每天 1–3 個 Session AI 的 context（記憶） 1 個 work = 1 個 Worktree 磁碟檔案 + git 分支 只要動程式碼就要 PR review / CI 紀錄 只有風險改動才開 一、Project ＝ 什麼時候開新 repo
判準：它有沒有自己的部署目標？
開新的：自己的網域、自己的 CI、自己的客戶。 不開：同一個產品裡再多一個模組——它們共用 build 產物、共用後端、一起部署，切開只會兩邊都要改。 實際踩過的版本：某個子產品想從 monorepo 切出去，卡在共用的 packages/core。 共用碼還在，就別切 repo。 二、Work ＝ 最關鍵的一層，其他四層都跟著它走
一個 work＝「做完能獨立 commit、獨立驗收、獨立上線」的最小單位。
一個新模組是一個 work，即使它橫跨四層：
因為少任何一層都不能上線，它們必須一起驗收。
反例，這是兩個 work（不要混）： 「做意見回饋模組」 「順手修結算報表的日期 bug」
檔案不同、驗收不同、可以分開上線 → 分兩條。
work 沒切乾淨，後面四層全亂。 先切 work，再決定要不要 session／worktree／PR。 三、Session ＝ 什麼時候開新對話
判準：新的任務需不需要「忘掉」前面的 context？
情況 做法 --- --- 開始一個新 work 開新 session 同一個 work 的 debug、加欄位、改樣式 留原 session（有 context 最省，重開等於重讀一次檔） 同 work 但隔天回來改 開新的（舊 context 已過期，重讀反而準） 純問問題 / 查資料 不用開
同時活著的 session 建議 ≤ 3 個。 四、Worktree ＝ 什麼時候要隔離磁碟
判準：這次改的是「資料」還是「程式碼」？
改動 要 worktree？ --- --- 後台設定、開關功能、加使用者、改 DB 資料 ❌ 不用，直接改，完全不碰 git 任何 .js / .tsx / .prisma ✅ 一定要
沒有「這次很小所以不開」的例外——小改動照樣會跟別人改到同一個檔。
⚠️ 時機是「開始寫 code 之前」，不是「寫完要 commit 之前」——後者已經來不及了。 為什麼不能都擠在同一個 checkout：build 讀的是磁碟不是 git。 A session 未提交的工作被 B session 的 git checkout 蓋掉時，衝突不會在 merge 時安全浮現， 而是靜默覆蓋、部署才爆。真的踩過：production 掉了功能，900 多行未提交工作差點蒸發。 五、PR ＝ 什麼時候要走 review
判準：改壞了會不會擋登入／影響到所有人？
開 PR 不開 PR --- --- 動 auth / session / 權限 新增一個自成一塊的模組 動既有資料表的 schema 純前端文案、樣式 跨租戶／跨客戶的共用邏輯 資料改動 你自己也不確定對不對 你 100% 確定
⚠️ PR 不解決互蓋。 它解的是 review 和 CI；併發安全是 worktree 給的。 最容易被忽略的一件事：收比開貴
開一條線 10 秒、零決策，所以人會一直開。但收一條線只有你能做，而且沒辦法平行：
產出端可以無限平行，收尾端永遠是一條單線。
這件事會實際發生：某次盤點時，同一個 repo 上有 8 個 worktree、14 個 commit 卡著沒整合——這些 commit 已經花掉 token 做完了，但對使用者而言等於不存在。而且它還在變貴： main 每往前一步，舊分支的 cherry-pick 衝突就多一點 當初做的那個 session 早關了，context 沒了，回頭看得重讀一次才知道為什麼那樣改 放久了不敢動它（不確定還能不能 build），最後直接放棄重做
未整合的分支不是「暫存」，是會腐化的庫存。
所以節制的重點不是「少開幾個省資源」，而是開之前先問： 這條線我今天收得完嗎？ 收不完就先別開。 一次完整的流程
第 7 步是唯一的瓶頸。做的時候心裡想著它，就不會堆出 8 條收不完的線。