這篇寫給讓不只一個 AI 助理碰同一批檔案的人，也寫給跟同事、跟 AI 共用 Notion、Google 文件或 Obsidian 資料夾的人。這是「AI 助理實戰」系列第 9 篇。五個助理怎麼分工，看第 4 篇；怎麼把規矩變成自動檢查，看第 8 篇；AI 的記憶該放什麼，看第 10 篇。
內容是到 2026-11-02 為止的狀況，工作上的例子都改寫成一般情境。不寫程式的人，可以直接跳到最後的〈不寫程式也用得上〉。
先講幾個詞
我的筆記放在一個 Obsidian 資料夾（下面叫知識庫），用 iCloud 在幾台電腦之間同步。會寫進去的除了我，還有 Claude Code、Codex、Antigravity、Hermes 這幾個 AI 助理。開一次 AI、做一段工作，下面叫一個工作階段。
| 詞 | 白話 |
|---|---|
| 衝突副本 | 同步工具分不出該留哪一版，就把其中一份改名留著，例如「PROGRESS 2.md」 |
| 雲端項目 | iCloud 在伺服器上替每個檔案記的一個編號，跟檔名是兩回事 |
| 登記、鎖 | 在一張大家都看得到的表上寫「這個檔我正在改」，別人就先不碰，改完再解除 |
| git | 版本控制工具，把每次修改記成一筆歷史，可以退回任何一版，也可以推到 GitHub 備份 |
| 指紋 | 用檔案內容算出來的一串碼。內容差一個字，指紋就不同，拿來確認兩份是不是同一版 |
撞起來是什麼樣子
| 日期 | 發生什麼 | 後果 |
|---|---|---|
| 2026-08-01 | 同一個工作階段裡，連改一份專案索引頁 8 次 | iCloud 三度把它改名成「…… 2.md」，原檔名每次都消失。要是沒發現，有 12 個連結會斷 |
| 2026-08-08 | 另一份專案索引頁只改了 2 次 | 一樣被改名，連到它的連結全斷。是後來一個不相干的搜尋剛好撞見，才發現 |
| 2026-08-09 | 兩個 Claude 工作階段把各自的發現寫回同一批檔 | 沒有副本。同一個章節編號出現兩次，當天的日誌被後寫的一方整份蓋掉 |
| 2026-10-15～17 | 另一台 Windows 電腦從 10-14 晚上起收不到別台寫的進度檔，期間自己寫了 15 次 | 它在自己那台的檢查每次都過；同一時間，Mac Studio 上的進度檔停在舊版 17 個小時 |
Obsidian 的連結靠檔名接。檔名一變，指向它的連結全變成空連結，Obsidian 不會報錯。
8 月 8 日那次讓我改了判斷方式：會不會被改名，跟改幾次有關；傷害多大，跟有多少檔連到它有關。改 20 次的日誌斷掉沒人痛，改 1 次的索引頁斷掉，是幾十條連結一起斷。
做法一：先登記再動手
我在進度檔 PROGRESS 裡放了一張「誰正在寫哪裡」的表。要改一個已經存在的檔，先查這張表。表上有列，就代表有別人在寫，交回之前一律不碰，連順手改個錯字都不行。
這張表是 2026-08-09 為 Antigravity 設的：它要直接在我的文件裡寫指定的那一節，Claude 就得先停手。隔天推到所有助理。表上記五欄：鎖住的檔案或專案、指派哪一節、指派給誰、指派日、狀態。
- 鎖放在進度檔，不放在被鎖的檔裡。iCloud 合併兩個版本時，會連檔案開頭的設定一起合併，寫在檔案裡的鎖會被合併掉。
- 只有我和 Claude Code 可以登記、解除，被指派去寫的助理不行。
- 一個窄例外（2026-08-13 我同意的）：被指派做複核的 Codex，可以自己登記、解除它被指派複核的那個範圍，其他列不能碰。不開這個口，每次複核都得等人開鎖，流程遲早會被跳過。
- 一次只指派一個範圍。同時開好幾條，兩邊都容易忘記交回。
什麼時候登記，什麼時候只要查
查表一律要做，幾乎不花成本。登記有門檻：
| 情況 | 怎麼做 |
|---|---|
| 很多檔連過來的檔：專案索引頁、有目錄的 README、知識庫的入口頁和進度檔（拿不準時，5 個以上的檔連到它就算） | 登記 |
| 要分好幾輪的長編輯，或已經知道另一個工作階段在同一個範圍 | 登記 |
| 寫的不是 Claude Code，例如 Antigravity、Codex 直接在檔裡寫 | 登記 |
| 一次改完、很少檔連過來（日誌後面加一段、小修一支工具） | 只查不登記。寫之前重讀一次，確認不是剛被人動過 |
| 新建的檔 | 不用鎖，新建不會跟別人搶同一個檔 |
為什麼要有門檻？登記本身就是對進度檔寫一次，而進度檔正是最多人寫、最多檔連過去的那一份。什麼都登記，等於為了防撞而製造撞。流程太煩，就會被整條跳過。
這不是空想。10-19 上午 11:02，另一台 Windows 電腦上的 Claude 寫下一筆登記，進度檔的原檔名就不見了，留下「PROGRESS 2.md」（它剛寫的）和「PROGRESS(1).md」（另一個工作階段 10:49 交回時寫的）。它以後者為底補進自己的紀錄、重建原檔名。那是同一天第二次被改名，這個工作階段就停止再寫進度檔。
門檻寫下十分鐘後，寫它的 AI 第一次碰到就漏了：對話裡明講「先登記再動」，接著直接改了規範檔。所以現在 AI 改我的四份規範檔時，表上沒有登記，寫入當下就會被提醒。專案索引頁還只靠文字規矩，沒有自動檢查。
鎖整個專案，不只鎖一個檔
登記的單位原本是單一檔案，2026-08-13 改成整個專案資料夾，加上它的索引頁。
原因在另一條規矩：動專案裡任何一個檔，都要回頭更新那個專案的索引頁。只鎖被改的那個檔，索引頁就落在「一定會去寫，鎖卻沒罩到」的縫裡。
那天就是這樣撞的。登記的是專案裡一份進度看板，改完照規矩去更新索引頁，而索引頁正被另一個寫者在改。結果 iCloud 上那份索引頁的原檔名不見了，49 個檔連到它的連結全部斷掉。那次寫完也有掃描，但只掃了子資料夾，沒掃到在專案最上層的索引頁。現在寫完的掃描也包含專案最上層和索引頁。
不在專案裡的檔，例如規範檔，仍然一檔一鎖。另外，鎖只解決「兩個寫者同時改同一份」。該連帶更新的檔照樣要更新，做的人和驗收的人照樣要分開，寫完照樣要掃衝突副本。
做法二：在 iCloud 上就地存檔
程式改檔有兩種常見寫法。一種是打開原檔直接寫進去，叫就地寫入。另一種是先寫一個暫存檔，確認沒問題再拿它蓋掉原檔。第二種在一般硬碟上比較安全，寫到一半出錯，原檔還是好的，我的規範裡也有一條這樣要求。
放進 iCloud 資料夾，它卻出了問題。2026-10-19，另一台 Windows 電腦上有一份工作專案的開發日誌一直停在舊版。翻 iCloud for Windows 的紀錄：10-14 到 10-18，那份日誌每寫一次就換一個新的雲端項目，前後大約 40 個編號，每次寫完大約 2 分鐘就被改名成「…… 2.md」；10-18 10:14:36，伺服器拒收了那台的版本（紀錄寫 path-match conflict）。
AI 在知識庫外面開了一個測試資料夾做實驗：
| 寫法 | 雲端項目編號 |
|---|---|
| 就地寫入 | 不變 |
先寫暫存檔再蓋掉（我的 AI 改檔用的編輯工具、程式常用的 os.replace 都是這種） |
每寫一次換一個新的 |
從結果看，iCloud 把第二種寫法當成「舊檔被刪掉，來了一個同名的新檔」。這是我從編號變化推的，不是 Apple 文件寫的。實驗裡只有一個寫者、每 40 秒寫一次，Mac Studio 都收到了最新版，沒有出現副本。我的紀錄把結論記成：這種寫法會被伺服器拒收，在 iCloud 資料夾裡要就地寫入。
11 月 2 日又來一次
2026-11-02 換 Mac Studio 出狀況。上傳錯誤從 120 個（訊息是「無法取用你的 iCloud 帳號」）、127 個，一路到 144 個，錯誤碼 4355。查 Apple 的開發文件，4355 是連不上 iCloud 伺服器。空間還剩大約 1.4 TB，不是滿了。
我看了 Apple 帳號，沒有任何提示。重啟 macOS 在背景負責 iCloud 的兩個系統程式（bird、cloudd），沒用。最後重開機。重開後一個一個檔查，原本卡住的檔變成排隊上傳：105 個上傳中，38 個已上傳。
那天的紀錄裡，AI 也記了自己的一個原因：它當天寫知識庫，用的正是先寫暫存檔再改名。之後它改成就地寫入，寫完讀回來比對。上傳錯誤有多少來自伺服器、多少來自寫法，紀錄沒有分開算，我也不硬分。另外，一次列出整個資料夾的上傳狀態，會比逐檔查來得舊，要判斷同步好了沒，得逐檔查。
到這篇寫的時候，「就地寫入」還只記在工作紀錄裡照著做，沒有寫進正式規範；規範裡那條「先寫暫存檔再替換」也還在，兩條誰讓誰還沒寫清楚。
做法三：git 不放進同步資料夾
git 會在資料夾裡放一個 .git，裡面是一堆它自己用的小檔，每做一次動作就改一批。雲端同步工具不懂這些檔之間的關係。
2026-05-11 以前，我的 .git 就放在 iCloud 資料夾裡，兩台電腦都會推上 GitHub。結果 Windows 那台累積了 70 多個衝突檔，連 .git/index 2、refs/heads/main 2 這種 git 的核心檔都有副本；Mac 上也有，只是比較少。對照組是另一個放在 Dropbox、只有一台電腦寫 git 的專案：0 個衝突。
所以現在的規矩（我叫它規則 N）是：知識庫在 iCloud 裡只放檔案，不放 .git，哪一台電腦都可以改筆記；只有一台電腦跑 git，它在 iCloud 以外另放一份副本，我手動把知識庫同步過去，再從那裡推上 GitHub；其他電腦不放 git。
只有多了第二個人一起寫、負責 git 的那台一週以上不在身邊或壞了，才破例；破例時每台的 git 也都放在 iCloud 外面，改之前先拉、改完馬上推。
做法四：每次結束前，掃一遍衝突副本
前面三個是預防，防不住的靠事後找。我在 Claude Code 上掛了一個自動檢查（Claude Code 叫它 hook），每次 AI 做完一輪、要停下來之前跑一次：
| 檢查 | 為什麼 |
|---|---|
| 有沒有「檔名 2」到「檔名 99」，或「檔名 (1)」「檔名(1)」 | iCloud 的副本從 2 起跳；下載或複製產生的常是 (1)，括號前不一定有空格 |
| 原檔名還在不在 | 原檔名不見，代表連到它的連結已經全斷，比兩份並存更急 |
| 最近 72 小時封存的副本，是不是比原檔名新、又多出原檔名沒有的內容 | 抓兩台電腦分岔。寫的那台一切正常，只有另一台看得出原檔名落後 |
掃到之後，照這個順序處理：
- 先看副本的內容。「檔名 2」常常就是剛寫的最新版，不要預設它是舊的。
- 原檔名還在，代表真的有兩個版本，要逐行比對，由人決定；原檔名不在、副本內容完整，才把副本改回原檔名。內容一模一樣的副本才可以刪。
- 封存了不代表結案。別台電腦離線時拿著舊狀態，上線後可能把副本推回來。9 月就有一次：三份副本 09-03 封存，隔天又回到原處，封存的資料夾整個不見。所以封存時記下每份副本的指紋，隔天再掃一次。
- 接回之後，原檔名的指紋要等於這次寫完的指紋，才算處理完。同一個檔同一天第二次被改名，就停止寫它，到另一台電腦確認。
這支檢查自己也漏過。10-14 iCloud 一口氣產生 20 份副本，它只報出 13 份，因為當時只認編號 2 和 3，漏掉的正好是編號最大、該留下的最新版。
它也有看不到的地方。兩個寫者同時改同一份、iCloud 直接合併或互相蓋掉時，不會留副本，只能靠寫之前重讀、寫完搜一下有沒有重複的章節編號。另外，它只能證明「這台電腦上是我的版本」，兩台分岔時要到另一台再跑一次。
不寫程式也用得上
只要你跟同事或 AI 工具共用 Notion 頁面、Google 文件或一個 Obsidian 資料夾，下面這幾條都用得上：
- 同一份文件，同一時間只讓一個寫者改。人和 AI 都算一個寫者。
- 換工具之前，先讓上一個存好、同步完，再開下一個。不要一邊讓 AI 改，一邊自己在另一台電腦上改同一份。
- 開一份「誰正在改什麼」的便條，放在大家都看得到、但不是被改的那份文件裡。改之前看一眼，改完劃掉。改一份會連帶改到目錄或總表，就把整組一起寫上去。
- 看到「檔名 2」「檔名 (1)」或檔名帶「衝突」的檔，先別刪。兩份都打開比對，比較新的那份常常就是副本。
- 先知道版本紀錄在哪裡。Google 文件和 Notion 都有版本紀錄，可以看舊版、還原；Obsidian 有內建的 File recovery（檔案復原）外掛，預設兩份快照至少隔 5 分鐘、保留 7 天，但官方說明它不是完整的備份。
- 一台電腦說好了，不代表另一台也好了。重要的東西，到另一台打開確認一次。
參考資料
- Apple Developer Documentation，〈NSUbiquitousFileUbiquityServerNotAvailable〉，錯誤碼 4355，連不上 iCloud 伺服器時回報。https://developer.apple.com/documentation/foundation/nsubiquitousfileubiquityservernotavailable-swift.var
- macOS 內建說明手冊：在終端機輸入
man bird、man cloudd，可以看到這兩個背景程式負責 iCloud 文件同步和 CloudKit。 - Google 文件說明中心，〈Find what’s changed in a file〉。https://support.google.com/docs/answer/190843
- Notion 說明中心，〈Delete & restore content〉的 Version history 一節。https://www.notion.com/help/duplicate-delete-and-restore-content
- Obsidian Help，〈File recovery〉。https://obsidian.md/help/plugins/file-recovery
- Git 官方網站。https://git-scm.com
- 整套協作方法見AI 協作開發方法。文中的日期和數字來自我的知識庫工作紀錄與維護規範。