我的官網有兩篇文章同時要上線，一篇檢查全過卻只能排隊。當天我把根因挖出來、設計了新機制、請另一家 AI 審查、當天上線。這篇把整個過程拆開來教：用「三張桌子」解決互卡與版本衝突。
這篇在講什麼：當多個 AI（或多個人）同時維護同一個網站，會出現互相排隊、蓋掉彼此版本、目錄與內容不同步三種病。這篇用我自己官網當天的真實事故當教材，講清楚根因（所有人共用同一個工作資料夾），並給出一套當天就上線的解法：分軌施工、合併上線、每日巡檢。
場景是這樣的：我的官網由多個 AI session 分頭維護，A 在改服務方案頁，B 的新文章已經全部就緒，發布前的十項檢查全數通過，只差最後一步推送。
然後 B 停下來了。因為它看到 A 還在同一個資料夾裡施工，按照我們立過的安全規則（同一時段只准一個 session 施工，動工前要掛牌登記），它只能排隊。
我當下說了兩句話：「我希望可以是單篇、單頁，部署不會影響。」還有一句更真實的：「安全機制太擋，很麻煩。」
這不是第一次。更早之前發生過一方為了發布、動了另一方還沒完成的檔案；也發生過正式網域被舊版本蓋回去。每出一次事，我們就多立一條規則，規則越立越多，排隊越排越長。
很多人以為是部署的問題。我的網站早就改成 Git 整合自動部署了：推送一個 commit，平台自動建置上線，部署的單位是 commit，理論上誰都不會蓋掉誰。
那為什麼還會打架？因為所有 AI 共用同一個本機資料夾。
想像一群人擠在同一張桌子上寫稿。桌上只要有別人還沒收走的稿紙，你就不敢動，怕弄亂別人的東西；你要出門送印，也得先確認桌上沒有別人的半成品會被夾進去。於是大家立了規矩：同一時段只准一個人用桌子，用之前要掛牌登記。
每篇文章一張自己的桌子（git worktree），物理隔離，施工完全不排隊。
上線走一支合併腳本，唯一的排隊點從「整段施工」縮到五到十分鐘。
全站檢查改成每天自動跑一次，抓漏但不擋人。
每篇文章（或每個獨立更新的頁面）開一個專屬分支，加一個專屬資料夾。Git 內建的 worktree 功能就是做這件事的：
從此 A 文章和 B 文章各寫各的，彼此完全看不到對方未完成的檔案，排隊制度直接失去存在的理由。附帶的好處：分支推上去就有預覽網址，草稿給人審不必先上線。
文章寫完要上線，走一支合併腳本，一次做完六步：
整段大約五到十分鐘，這是新機制裡唯一要排隊的地方。跟原本「整段施工都要排隊、動輒半天」相比，體感就是換了一套機制，而非又多了幾條規則。
舊做法是每次發布都跑全站檢查，檢查越多、發布越卡。新做法把檢查拆成兩層：發布當下只檢查「我這篇沒壞」；全站級的檢查（文章互聯是否完整、索引有沒有漏頁、線上隨機抽測、AI 客服的檢索資料是否正常）做成一支腳本，每天自動跑一次，有問題開卡回報，交人判斷，它自己不修東西，也不擋任何人。
機制是我和 Claude 一起設計的。設計完我沒有直接上，先丟給另一家的 AI（Codex）審查，而且刻意讓它先不看我的方案、自己獨立設計一次，再來互審，避免被我的想法帶著走。
它的獨立設計和我的方向幾乎一致，這是好消息。更值錢的是它抓出三個「會實際出事」的洞：
這三個洞的共通點：單獨看每一步都合理，串起來才看得到破口。這正是找第二顆腦、而且找不同家模型審查的價值。
網站用 Git 託管，推送就自動建置上線（Vercel、Netlify、Cloudflare Pages 的 Git 整合都算）。這是並行的地基；還在用本機資料夾直接推的，先改這個。
只有多人（或多 AI）並行才會打架。單人維護的小站不需要這套，直接在主線上小步快跑就好。
兩個都符合，才值得裝三件套。
想在自己的網站（或幫客戶的網站）裝這套，照這六步：
懶得自己想的話，把這段直接貼給你的 AI：
拍板之後，施工這套機制本身就是用這套機制做的：開一張獨立的桌子（worktree 分支），三支腳本在裡面寫完、測完、推上去，全程沒有碰主資料夾一根指頭。當時主資料夾裡還有另外兩個 AI 的在途工作，一個都沒被影響。
連你現在讀的這篇文章，也是在自己的專屬桌子上寫出來的。機制能不能用，最快的驗證方式就是讓它處理自己的誕生。