AI 共用流程：同一套系統分頭用，改動前要先通知誰？

先講結論：AI 共用流程要通知誰，先看誰的工作會跟著變。提出修改的人，往往只知道自己的問題；沒提出需求的人，也可能正在用同一份東西。

2026 年 6 月 20 日，我那套網站系統出過一次很尷尬的事故。原本只想修好其中一個站，結果另一個站的產品頁變成 404，打不開了。出問題的那個站，當天根本沒改。

後來查到，四個站共用同一包執行程式。那次修改從一份落後兩天的工作版本送出去，連其他站都一起退回舊狀態。修的是一個站，送出去的卻是四個站一起用的東西。

故事還沒結束。把共同版本重新放回去，產品頁救回來了，另一邊剛做好的修改又退掉了。兩邊都在救火，兩邊都能把對方的工作蓋過去。這種效率，我實在不想再體驗一次。

先交代這篇的邊界：我帶過團隊，但沒有企業級 AI 導入實績，也沒有替企業建立過跨部門的改動通知制度。這裡能講的真實經驗，是我用 AI 協助維護自己的多站系統。後面的通知清單，是我從事故和官方實務指引整理出的建議；不是一套已經在企業裡證明有效的方法。

工作分開了，哪些東西還連在一起？

共用流程的影響範圍，要沿著實際共用的資料、設定和執行系統找，光看工作分給誰，很容易漏掉另一端。

我那次的問題就藏在這個落差裡：表面上，每個站有自己的網址、畫面和待修問題；底下，四個站卻跟著同一包程式一起變動。任務分開了，最後送出去的東西沒有分開。

所以當一個任務寫著「只修這個站」，那句話只說明了要修哪裡，沒有說明改動能不能只留在那裡。

Google 的《Site Reliability Workbook》在談發布測試時，也提醒過類似的限制：看似分開的測試端和對照端，仍可能共用後端、網路或資料儲存；隔離不完全，兩邊就可能一起受影響。這是軟體系統的實務說明，不是 AI 協作成效研究，但它提醒我的問題很直接：你分開的是任務，還是連底下的依賴也分開了？

放到辦公室，可以用一個假設情境理解。兩個部門各有自己的報表，卻都從同一張共用清單讀資料。你請 AI 協助把清單的一個欄位改得更好懂，自己的報表正常，另一張報表卻可能還在找舊欄位。

這是說明用的假設，不是我做過的企業案例。但要追的關係，跟我的事故很像：看起來是自己的修改，實際動到了別人也會讀取的東西。

如果你要找通知對象，可以先寫下那個「一起用的東西」：是同一份清單、同一個範本、同一個排程設定，還是同一套後台？只寫「業務流程」或「行政系統」太大了，還找不到人。

改動之前，要先找哪三種人？

共用流程改動前，至少要找出會直接用到它的人、會接到它的結果的人，以及正在修改同一份東西的人。

三種人可能是同一個人，也可能在不同部門。分成三種，是為了找漏掉的工作，不是多設三個職位。

第一種，是直接使用的人。 改完之後，他原本的操作還能不能做？需要換入口、重選項目，還是暫時不能用？

第二種，是接結果的人。 他可能從來沒開過你用的系統，只在固定時間收到一份資料。來源欄位或送出時點一變，他的工作照樣會被影響。只通知「有登入帳號的人」，就可能漏掉他。

第三種，是同時在修改的人。 他手上可能有一份你沒看過的修改。你以為自己拿的是最新版本，其實只是自己的最新版本。我六月那場事故，這一種尤其重要。

AWS 的終端使用者運算指引，也把使用者、管理員和支援團隊列入溝通對象，要求提前交代改動、預期影響和需要採取的動作，並與相關團隊協調。那份文件談的是運算環境，不是所有辦公流程；我借用的是先找受影響者的做法。

找到人之後，通知也不用寫成一份長公告。我會建議把下面五件事放在同一則訊息裡：

1. 這次動哪一份共用項目。 寫出能指認的名稱或位置，不只寫「優化流程」。
2. 哪些工作可能跟著變。 分別寫出操作端、接收端和其他修改者，不用先把整個部門都算進來。
3. 什麼時候切換。 哪一段時間需要暫停、哪一段還能照常做，要分清楚。
4. 切換前有哪些工作還沒合進來。 請正在改的人說明手上的狀態，避免別人的進度被當成不存在。
5. 切換後由誰確認哪個動作。 寫「確認能完成哪件事」，比寫「大家幫忙看一下」具體。

這份清單是我整理的，不是 AWS 的原文五步驟。它的用途很窄：讓你在按下修改之前，有機會發現「原來還有人在用」。

如果你填到第二項就卡住，這次最需要補的可能還不是通知文字，而是找使用者。先問熟悉那份共用項目的人，也查一下使用紀錄；不要讓 AI 憑部門名稱猜一份名單，然後把猜測當盤點完成。

別人也在改，你手上的真的是共同版本嗎？

共同版本必須能交代各方已完成和尚未合入的修改，不能靠某一個人說「我這份最新」就決定。

回到六月那次事故。重新放回共同版本之後，另一個站的產品頁恢復了；但原本那個站的修改，只留在個別工作區，還沒有收進共同版本。於是恢復產品頁的動作，也把那邊已做好的功能從線上版本退掉。最後有四個功能需要重新補進共同版本。

請注意，這裡的麻煩不是「檔案全不見了」。原本的工作還留在個別工作區。麻煩是，救援時拿來當全體基準的那一份，沒有包含所有人的進度。

所以只加一則「我要更新，大家注意」的訊息，解不了這個問題。訊息送到了，版本還是舊的，一樣會互相覆蓋。

如果把這個教訓搬到團隊，我會把切換前的對話縮成三個問題：

• 這次大家要共同使用的是哪一份？
• 哪些已完成的修改，還只留在個別工作區或個人副本？
• 誰來決定這些修改先合進去，還是保留好、等這次切換完成再接著做？

這段我沒有企業團隊落地的實戰可講，以上是從個人系統事故延伸的原則。重點是讓未合入的工作被看見；至於誰有最後決定權，應該沿用你們原本的工作分工，沒必要為了 AI 再造一層簽核。

也別把「先合進去」誤讀成「現在全部一起改」。有些修改互相衝突，本來就該分開處理。至少要先知道它存在，才能決定順序；不知道它存在，才會把對方的工作整段退掉。

自己的畫面好了，別人的路也通了嗎？

共用流程恢復之後，應該回到不同使用者原本的操作路徑確認，不能只看提出問題的那一個畫面。

我的後台還出過另一種共用問題。後台可以切換正在管理的站台，但這個選擇被存在瀏覽器裡，而且會影響到公開頁。結果是：在後台切到甲站之後，用同一個瀏覽器開乙站的頁面，畫面竟然套上甲站的外觀，內文則顯示找不到。

更容易誤判的地方是，這個錯誤本來就藏著。早期兩個站的外觀接近，不容易看出來；等外觀開始區分，問題才變得刺眼。外觀變了，讓舊問題現形，不代表外觀改動就是問題的起點。

當時修正的是站台選擇的適用範圍：後台的選擇留在後台，公開頁依照自己的網址辨認站台。這跟六月舊版本覆蓋的事故，是兩種不同的故障。

但它們都提醒我：如果只照自己剛才的操作方式再走一次，很容易漏掉另一條路。

以那個後台問題來說，光確認「乙站直接打開正常」不夠，還要試「先切換後台，再打開乙站」。讀者看到的錯誤，是前後兩個動作連在一起才出現的。

我因此建議，前面通知清單寫的確認對象，要在修改後繼續用。誰會直接操作、誰會接結果，就各選一段有代表性的工作確認。需要對方配合的地方，也在改動前講清楚，別等系統改好了才臨時找人。

至於回復原版本，也要當作一次會影響別人的改動。六月那次就是證據：我救回了壞掉的頁面，卻同時退掉另一邊的修改。通知「已恢復」之前，得先知道恢復的是誰的正常。

每個小改動都通知，大家只會更不想看吧？

改動通知如果沒有分出需要行動的人，確實可能變成大家略過的背景訊息；這是我認為最值得認真對待的反對意見。

假設你只改自己的私人副本，沒有其他人讀取，也不會寫回共用系統。這時還要求填完整清單、找人確認，增加的很可能只有麻煩。我不建議這樣做。

但「只有我在改」和「只會影響我」是兩件事。要省掉通知，先回答後面那句：改動的結果會不會傳出去？如果會，誰會接到？

我會把處理方式分成三種：

• 可以確認只影響自己：自己處理，保留需要的紀錄即可。
• 別人會受影響，但不需要配合動作：告知改了什麼、何時生效、異常找誰，不必把收件人都拉進會議。
• 別人需要停手、切換或幫忙確認：事先約好時間與動作，不能只丟一則訊息就算完成。

通知後沒收到回覆，也要看你落在哪一種。只是讓對方知道，不代表每封都得等確認；但如果對方必須暫停工作，你就不能把沉默當成「他已經停了」。

這個方法的限制，是你可能還不知道有哪些人依賴那份東西。清單填滿，不代表影響找齊了。新的接法、沒有紀錄的個人習慣，以及藏在系統裡的共用狀態，都可能被漏掉。通知清單需要搭配使用紀錄、版本確認和技術上的隔離；它本身沒有阻止覆蓋的能力。

遇到必須立刻處理的故障，也不適合等全員回覆才救。至少先同步已知的影響與目前動作，讓能提供關鍵資訊的人接得上；其餘確認在處理過程中補齊。這是緊急協作的原則，不是叫你把事故也排成下週會議。

這份通知清單適合誰、不適合誰？

共用流程通知清單，最適合已經有不同工作接在同一份資料或系統上、卻常由各自單獨修改的情境。

適合你，如果：

• 你維護共用表單、範本、報表來源或後台，修改時不確定還有誰在用。
• 你和其他人分頭用 AI 處理工作，最後卻會寫回同一個地方。
• 你們遇過「我這邊修好了，另一邊怎麼壞了」，或恢復之後才發現別人的修改被退掉。

不適合你，如果：

• 工作確實停在私人副本，不讀寫共用項目，也沒有人接你的結果。
• 你期待一張清單解決共用系統的技術缺陷。該分開的狀態、該阻止的覆蓋，仍然需要實際修正。
• 你已經有能涵蓋這些問題的改動流程。把漏項補進現有做法，比另外再填一張 AI 專用表合理。

代價：

先找人，會拖慢眼前的修改。 尤其共用項目沒有使用紀錄時，光弄清楚誰接了資料，就可能比修改本身還費力。這段時間要算進工作，不能假裝沒有成本。

共同版本需要有人整理。 別人的修改還沒合入時，不能只把清單交出去，期待它自己消失。要分清楚先後順序，也可能得等另一份工作整理到能接手。

通知太多會稀釋重要訊息。 如果每次都寄給全部的人，很快就分不出哪一次真的需要停手。收件人和需要的動作要一起挑，不能只求名單完整。

確認恢復，也會占用別人的時間。 對方不是幫你看一眼畫面就好，而是要把受影響的工作再走一次。這個配合最好事前約，不要當作免費的善後。

找到共用的地方之後，工作要在哪裡分開做？

共用流程的影響者釐清之後，涉及程式開發的工作，才適合接著討論個別工作環境要怎麼分開、最後怎麼合回共同版本。

如果你的情境需要工程協作，我在自己的部落格整理過 Claude Code 雲端與本機執行環境的選擇，談不同環境的差異和工作安排，可以當作工具層的補充。

一般的共用表單或報表，不需要為了照這篇做而先換工具。先找出大家究竟共用了哪一份東西，就已經有具體的問題可以談。就算工作環境分開，最後若還是一起改到同一套系統，通知與共同版本的問題仍然存在。

FAQ 常見問題

共用流程改動前，先分清楚誰需要知道、誰需要配合，以及哪些影響還沒查明。

團隊只有兩個人，還需要寫通知清單嗎？

如果你們會改到同一份東西，就值得說清楚。但不必做成正式表單，一則訊息能交代共用項目、切換時間、對方要不要停手，以及改完怎麼確認，就可以開始。人少不代表版本不會互相蓋過去；也不代表每次都要開會。

AI 說這次只改一小段，我可以直接做嗎？

先看那一小段有誰共用。改動的行數或欄位數，只能說明動了多少內容，不能直接回答會影響多少工作。如果 AI 沒有讀到完整的依賴和使用情況，「只影響這裡」就仍然是一個待確認的判斷。

不知道誰還在使用共用項目，該從哪裡找？

從你看得到的輸入和輸出往兩邊找：資料從哪裡來、結果送到哪裡、誰在修改設定。再用使用紀錄和熟悉流程的人交叉確認。找不到的部分標成未知，先不要把「目前沒有找到」寫成「沒有人使用」。

緊急恢復後，該先通知原本報錯的人，還是所有使用者？

先讓受影響且需要採取動作的人知道目前恢復到哪裡，並找原本報錯的人確認那條路已通。同時檢查恢復動作有沒有退掉其他人的工作。我的六月事故就是後半段漏了；一句「已恢復」不能代替對不同工作狀態的確認。

參考資料

共用系統的影響與溝通原則參考以下官方指引，本文的通知清單是作者從事故延伸的建議。

AWS，EUCREL10-BP01：Implement communication plans with EUC environment stakeholders（End User Computing Lens，線上文件，2026-10-03 查閱）：支持先辨認受影響者，提前交代改動、預期影響與必要動作；適用背景為終端使用者運算環境，本文清單是作者延伸建議。

Alec Warner、Štěpán Davidovič 等，Canarying Releases（Google《Site Reliability Workbook》第 16 章，線上版，2026-10-03 查閱）：本文取用「Dependencies and Isolation」對共用底層及隔離不完全的說明；不是作者個別事故的調查報告，也沒有測試本文的通知方法。