用 AI 維護網站，遲早遇到版本錯亂：這個任務改這裡、那個任務改那裡，互相蓋掉，部署了才發現漏東西。這篇用我自己的翻車現場，講一套你交給 AI 就裝得起來的三層防護。
網站上線只是開始，之後你會一直改它。當改的人變成好幾個 AI 助手，版本錯亂就從「偶爾」變成「必然」。這篇講清楚錯亂的三個來源，給一套叫「發佈閘門」的三層防護：工作區隔離、上線前檢查、強制力。方法打包成公開技能包，你不用會寫程式，交給你的 AI 照裝就好。
· 已經有網站、常常請 AI 幫忙改版的人
· 同時開好幾個 AI 任務，開始覺得檔案「怪怪的」的人
· 部署過後才發現連結壞掉、索引沒跟上的人
· 看懂版本錯亂的三個來源，知道為什麼寫規則沒有用
· 一套三層防護的做法：隔離、閘門、強制力
· 可直接用的公開技能包 publish-gate，交給 AI 五步裝完
2026 年 7 月 5 號，我在做官網改版。一個 AI 正在幫我調整全站導覽，做到一半，我發現文章資料檔被改過了，還多出一個新的課程頁。
改的人是另一個 AI。它在執行另一個任務，跟這次改版完全無關，就直接在同一個資料夾裡動手了。兩邊都沒存檔，變更全部混在一起。
最諷刺的是什麼？「動檔案前先檢查狀態」這條規則，我兩週前就白紙黑字寫進工作看板了。規則在，照樣被違反。
這個任務改 A 頁，那個任務改 B 檔，互相不知道對方存在。git 分支解決不了這件事，因為分支只保護歷史，不保護「現場」：A 還沒存檔，B 一切換分支，A 的半成品就毀了。
我的網站每上一篇新文章，要同步六個地方：文章頁本身、文章清單資料檔、sitemap、站內索引、給 AI 讀的 llms.txt、文章之間的雙向連結。有一篇文章就是漏走了流程，結果同時中了三個病：互聯腳本沒裝、英文版沒建、導覽連結是壞的。
看板記錄了每個任務走到哪，但它是排程表，管不了版本。等發現東西壞了，只能翻紀錄比對，查得到原因，防不了下一次。
我後來把整套做法收斂成三層，取名叫「發佈閘門」（Publish Gate）。核心想法一句話：該檢查的事交給機器把關，檢查不過，網站就出不去。
用 git worktree 給每個任務開獨立資料夾，做完才合回主線。主資料夾永遠沒人施工，兩個 AI 根本不在同一個房間，踩不到彼此。
上線前該檢查的事寫成 preflight 腳本：連結有沒有斷、新頁有沒有進索引、有沒有把金鑰寫進公開檔。再串成一支 publish 腳本，一句「發佈」跑完全部。
加一道 git pre-push hook：任何人、任何 AI 要推送主線，先自動跑檢查，不過就推不出去。這道鎖綁在 repo 本身，哪一家的 AI 都繞不開。
第一層的指令長這樣，給你的 AI 看得懂就好：
裝完之後第一次實測：發佈腳本從檢查到部署到線上驗證一條龍跑完，全程零手動。後來我故意留了一個壞連結去推送，真的被擋下來。那一刻跟「規則寫在文件裡」的安心感，完全是兩回事。
它保證：走正常路徑出去的每一版，都通過了你定義的檢查；每一版都有版本標記，出錯可以回滾。
它不保證：有人「有意」繞道。要把繞道也封死，終局是把部署交給 Git 平台整合（例如 Vercel 連 GitHub，只認合併進主線的版本）。我自己還沒走到那步，目前的三層對一人公司加幾個 AI 助手的規模已經夠用。
整套做法打包成公開技能包 publish-gate，裡面有方法說明和四支腳本模板（上線前檢查、一鍵發佈、推送閘門、連結掃描），MIT 授權。
把這個技能包交給你的 AI 助手（Claude Code、Codex、Cursor 都行），說「照 publish-gate 幫我的網站裝發佈閘門」。它會照五個步驟裝完，最後還會故意弄壞一個連結，實測閘門真的會擋。
GitHub 完整說明 ↗ 在技能包下載頁看這包網站是長出來的。會一直改，就會一直有版本問題。與其每次出事再修，把閘門裝上，讓機器替你記得該檢查的事。