# 我的自動化全都運作正常，然後它們一起讓我吃了一記回馬槍 > 發一篇文章，照理三十分鐘，實際花了三小時。過程撞出六個系統問題：bot commit 讓三鏡像永遠對不齊、自動翻譯蓋掉人工翻譯、文章上線了首頁卻不知道、每個 AI 視窗拿到的規範各不相同。最諷刺的是：每一個元件都在正確運作。這是一份一人公司的韌性工程 postmortem：當 AI 與自動化開始介入需求、資料、畫面與測試，人真正要管理的已經不是單一任務，而是一整套新的工作秩序，以及自己還握著多少判斷權。 - Author: Paul Kuo（郭曜郎） - Date: 2026-06-04 - Pillar: 智能與秩序 / Intelligence & Order - Tags: 韌性工程, 自動化治理, 多代理協作, 判斷權, AI 主體性, postmortem, 一人公司 - Canonical: https://paulkuo.tw/articles/automation-bites-back/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：原本只是發一篇文章，卻花了三小時，還撞出一連串系統問題：bot commit 讓三個鏡像對不齊、自動翻譯蓋掉人工翻譯、首頁快取卡住新文章、不同 AI 視窗之間出現規範漂移。最諷刺的是，每個元件都在「正確」運作。真正需要修復的，不是把自動化拆掉，而是給每個自動化一份所有參與者都讀得到的契約：觸發條件、副作用、opt-out 標記、查證入口，四項缺一不可。而契約背後還有一個更根本的問題：未來的工作風險，不是自動化壞掉，而是自動化全都正常運作，卻沒有人知道它們彼此正在影響什麼。
▶ 聽摘要
AI 合成語音・作者本人聲線克隆
昨天深夜，我發了一篇文章。 四個語言版本的檔案，十分鐘就放好了。封面圖生成、確認、定稿，順利。然後我按下 push。接下來的三個小時，我都在跟自己的系統搏鬥。 不是跟 bug 搏鬥。三個小時裡，我沒有修到任何一個壞掉的東西。SEO bot 正確地登錄了新網址，翻譯 bot 正確地翻譯了文章，快取正確地快取了頁面，排程腳本正確地記錄了數據。每一個元件，拿出來單獨檢查，都在做它該做的事。 但合在一起，它們一起讓我吃了一記回馬槍。 我原本只是想測試一個新的發佈流程，最後卻發現，自己其實站在一場工作方式變革的門口。 ## 測試的是工具，撞上的是新的工作秩序 過去這段時間，我試著把幾個 AI 協作工具接進自己的工作流程。表面上只是測試工具，實際上我碰到的是另一個更深的問題：當需求、資料、畫面、測試與修正都開始由 AI 介入時，人真正要管理的，已經不是單一任務，而是一整套新的工作秩序。 一開始，我以為 AI 只是幫我補上幾段程式、提交幾次 commit，或整理一些重複性的工作。但做著做著，我開始意識到，AI 並不是單純加速原本的流程，而是在迫使我重新理解「流程本身」。 接下來的六個坑，就是這堂課的學費。其中四個最有代表性，值得逐一解剖；其餘兩個較偏操作層，最後也歸入同一個問題：自動化沒有被寫成所有參與者都讀得到的契約。 ## 為什麼 push 完，三個鏡像永遠對不齊？ 先交代背景。這個網站經歷過[一次 GitHub 帳號無預警停權](/articles/resilience-engineering-after-github-suspend/)，那之後我把 repo 鋪成三鏡像：Codeberg、GitLab、GitHub 對等並存，本地 git 是唯一事實來源。前一天，GitHub 恢復了，三鏡像加本地端的部署系統剛接回來。而我是在發文的當下，才真正體會到這個新系統的脾氣。 文章 push 上去之後，GitHub 端的自動化開始工作：一個 bot 把四語版網址登錄進 SEO 索引清單，追加一個 commit；另一個 bot 產出社群貼文素材，又追加一個 commit；然後是一個自動 merge。結果就是：我每 push 一次，GitHub 就比另外兩個鏡像多出一兩個 commit。 我的第一反應是把它們追平。錯了。force-push 把 bot 的 commit 蓋掉，下一輪它又重新追加，於是再蓋、再追加，標準的打地鼠。打了兩輪我才停下來想：bot 不是干擾，它在替我工作，它的 commit 是工作成果。正確的姿勢是 `fetch` 加 fast-forward，把它的成果吸收進本地，再把另外兩個鏡像補齊。 這個坑的本質：**我建立了一個會自己長 commit 的系統，但我的肌肉記憶還停留在「遠端只有我會動」的時代。** ## 自動翻譯為什麼蓋掉了人工翻譯？ 第二記回馬槍，來得更深。 這篇文章的英文、日文、簡體版，是事前人工打磨過的：用語、語感、在地化都調過。我把四個檔案放好、push。幾分鐘後，GitHub 端的自動翻譯管線醒來，發現翻譯紀錄裡沒有這個新文章的條目，於是忠實地執行任務：重新翻譯三個語言版本，蓋掉我放上去的檔案。 更有意思的是品質方向。比對之後發現，機器重翻的簡體版反而在地化倒退了：人工版寫「进化生物学」「集群」，是大陸讀者的慣用語；機器版寫「演化生物学」「丛集」，那是台灣用語直接轉字。自動化不只蓋掉了人工成果，還蓋出了一個更差的版本。 修復本身不難：恢復檔案、在 commit 訊息加上 `[skip-translate]` 標記、把翻譯紀錄的雜湊值對齊，讓管線知道「這篇已經翻好了，別動」。真正的教訓在前面：**這條管線有 opt-out 機制，但知道它存在的只有管線自己。** 我（以及替我工作的每個 AI 視窗）的操作手冊裡，根本沒有這一條。 ## 文章上線了，首頁為什麼不知道？ 第三記，來自快取。 文章頁面四個語言版本全部回 200，標題正確，封面正常。我以為收工了。然後發現首頁的「最新思考」區塊，還停在上一篇文章。 排查的過程像剝洋蔥。先猜 CDN 快取，用 Cloudflare 的 API 對首頁網址做 purge，成功，沒效。再看回應標頭，`cf-cache-status: DYNAMIC`，根本不是 CDN 層在快取。最後翻到網站自己的 middleware：它用 [Workers Cache API](https://developers.cloudflare.com/workers/runtime-apis/cache/) 在邊緣節點快取每一頁 HTML，存活二十四小時，而且 cache key 帶了一個版本號後綴。版本號不變，快取就不變；因為 key 跟網址長得不一樣，連 zone purge 都比對不到它。 設計這個機制的人，也就是幾週前的我自己（透過某個 AI 視窗），在程式碼註解裡寫得清清楚楚：「內容更新後 bump 版本號來清快取」。但這句話只活在程式碼註解裡，從來沒有進入發文流程的檢查清單。於是「部署成功」和「讀者看得到」之間，隔了一道誰也想不起來的牆。 ## 為什麼每個 AI 視窗拿到的規範都不一樣？ 前三個坑修完，我以為結束了。直到我回頭檢查「為什麼這些坑會存在」，才挖到第四層：規範漂移。 我的工作方式是多個 AI 視窗並行：有的負責寫作、有的負責工程、有的負責偵察，各自載入同一份寫作規範作為開工前提。這套[一個人帶四個 AI 視窗的治理架構](/articles/governance-harness-engineering/)，我之前寫過。當一個產品開始進入真實運作，問題就不再只是「能不能做出來」，而是不同任務如何被拆解、交付、回收與再判斷。某些 AI 負責文件，某些 AI 負責介面，某些 AI 負責測試與回饋；人則退到更高的位置，開始扮演架構設計者與判斷者。 問題在於：那份規範有好幾個副本。repo 裡的正本、文件鏡像、還有桌面應用程式載入用的副本。正本升級了，副本不一定跟上；更要命的是，文件裡宣稱「副本會自動同步」，但實際去翻 git hook，那條自動同步的線，寫好了，從來沒接上。 也就是說：規範文件本身，犯了它想要防止的錯。它描述了一個不存在的自動化，而每個讀到它的 AI 視窗，都以為同步會自己發生。 地圖與疆域的關係在這裡徹底反轉。不是地圖跟不上疆域，是地圖宣稱疆域長什麼樣子，然後所有人照著地圖走，走進了疆域裡根本沒有的橋。 在人類團隊裡，一份過期文件的殺傷力有限：新人照著做，撞牆，問一句，有人糾正，錯誤就停在那裡。但在 AI 協作的工作流裡，文件就是 agent 的行動依據。錯誤的文件不是靜態錯誤，它會成為下一輪自動化行動的共同來源。每個視窗都照著同一張錯的地圖行動，沒有人會撞牆後回頭發問，錯誤不會被稀釋，只會被忠實地同步執行。這已經不是文件管理問題，而是 AI 協作時代的知識治理問題：當 agent 依據過期規範行動時，文件本身就是系統風險。 ## 韌性的第二課：自動化需要契約 第一次寫[韌性工程](/articles/resilience-engineering-after-github-suspend/)，是 GitHub 停權教我的：不要讓單一平台掌握你的命脈。那是韌性的第一課：冗餘。 這次的第二課完全不同。出手的不是平台，是我自己建的東西。六個坑沒有一個來自外部依賴，全部來自「我建了自動化，然後忘記告訴所有參與者」。參與者包括未來的我，和替我工作的每一個 AI 視窗。前面沒展開的那兩個操作層小坑，拆到最後也是同一句話：有人改了系統的行為，卻沒有人更新所有參與者讀到的那份說明。 這時我才真正感受到，AI 帶來的不是工具升級，而是「分工邏輯」的重組。過去我們問的是：誰來做？現在我們問的是：哪一段交給 AI？哪一段仍然必須由人判斷？哪一段需要保留主權？ 修復清單其實很短。每個自動化補一份契約，寫進所有視窗開工都會載入的共享文件，內容四項： **它什麼時候動**：push 之後？commit 訊息含特定字眼？每十分鐘？ **它會動什麼**：改哪些檔案、追加什麼 commit、清哪層快取。 **怎麼讓它這次別動**：`[skip-translate]` 這類 opt-out 標記，沒有就補。 **事後去哪查證**：log 路徑、版本號、manifest，出事時三分鐘內能確認它動過沒有。 這四項合起來，就是一份最小可用的自動化契約。它不是事故後的個人筆記，而是一套可以直接搬進任何團隊的 workflow governance，搭配兩條執行紀律：新的自動化上線，契約沒寫齊就不准接進管線；契約一旦修改，所有參與者（人與 AI）開工載入的文件必須同步更新。團隊規模不是門檻。只要系統裡有兩個以上的參與者會動到同一份狀態，這份契約就該存在。 當 Google 這類大型平台開始把 [postmortem 文件](https://sre.google/sre-book/postmortem-culture/)、AI 協作流程與開發系統整合在一起，我們看到的不是單一產品功能，而是一種新的組織形態正在成形。AI 開始不只是協助工程師，而是進入組織的記憶、修復、回饋與決策迴路之中。一人公司只是把這個趨勢壓縮到極限：沒有「另一個值班的人」可以咎責，所有的坑都是自己埋的，所有的修復也都直接變成下一個視窗的開工規範。你寫下的每一條教訓，第二天就會被某個視窗載入、執行、驗證。postmortem 的投資報酬率，反而比團隊更高。 未來的團隊邊界，可能不再只由人員編制決定，而是由人、模型、資料、流程與權限共同構成。產品也不再只是被開發出來的物件，而是一個持續學習、修正與演化的系統。 ## 交出去的是任務，還是判斷權？ 契約解決的是「看不見」的問題。但這三個小時還留下一個更深的問題，契約解決不了。 當我們把 prompt 丟出去，看似只是發出一個指令，其實是在把一部分判斷權交給系統。這裡真正值得思考的，不是 AI 能不能完成任務，而是我們是否知道自己交出了什麼。 這次實作給我最大的提醒是：AI 不只是替人完成工作，它正在進入人的思考前段。它不只回應需求，也開始影響我們如何描述問題、切分任務、設定優先順序，以及理解一個產品該如何被完成。 因此，真正的問題或許不是 AI 會不會取代人，而是人會不會在追求效率的過程中，逐步放棄自己的判斷位置。當工具變得越來越像器官，我們就必須重新確認：這個器官是服務於我，還是我正在成為某個系統的延伸？ 這裡我想給一條具體的判斷標準，不只是比喻：當一個系統開始自行觸發、自行改寫狀態，並且影響下一輪決策時，它就不再只是工具，而是進入了治理範圍。鎚子不會在半夜自己動工，但會自己翻譯、自己追加 commit、自己決定首頁該長什麼樣的系統會。前者只需要保養，後者需要契約、權限與問責。這條線劃在哪裡，決定了你對系統的態度：線的這一邊，你是使用者；線的那一邊，你是治理者。 這也回到我前一天才寫過的問題：[AI 到底只是外部工具，還是正在成為我們工作生命體中的一個器官](/articles/organism-or-organ/)？如果它只是工具，人仍然是主體；但如果它成為器官，我們就必須問清楚，這個生命體到底由誰來支配。 所以，這件事表面上是科技問題，深層其實是治理問題。AI 的關鍵不只在模型能力，而在於權限、資料、流程、責任與主體性如何被重新安排。 ## 會反作用的，都是活的 三小時的混戰結束後，我重新看了一眼這個系統：會自己長 commit 的 repo、會自己翻譯的管線、會自己記帳的排程、會在邊緣節點記住每一頁的快取。 它確實越來越像個活物。而活物就是這樣：它不會等你下指令才動，它有自己的節奏、自己的反射、自己的新陳代謝。你餵養它、擴充它，總有一天它的行為超出你的地圖，然後在某個深夜，給你一記反作用，提醒你：該更新地圖了。 我會繼續往這個方向探索，因為我越來越確定，這不是一場單純的效率革命，而是一場工作文明的改寫。真正重要的，不是我們用了多少 AI 工具，而是我們是否還能在 AI 逐步成為器官的時代，保有人的主體性、判斷力與治理能力。 說到底，未來的工作風險，不是自動化壞掉，而是自動化全都正常運作，卻沒有人知道它們彼此正在影響什麼。壞掉的東西會報錯、會留下痕跡、會逼你停下來修；正常運作的東西不會，它們只會安靜地疊加，直到某個深夜一起現形。 吃了一記回馬槍，不是失敗，而是系統演化的必然。錯誤會繼續出現，也不可怕；《老子》說「禍兮福之所倚，福兮禍之所伏」是對的。真正重要的，是讓每一次錯誤都留下痕跡、推動修正，讓地圖更準、契約更清楚，也讓下一輪迭代比上一輪更成熟。