多 AI 協作同一份文件
問題
有什麼方法可以讓不同 AI（例如 Gemini Chat + Claude）參與同一份文件的討論？
方案
使用 CLI 工具：
兩者都可以讀取本地檔案，輪流編輯同一份文件。
Context 重讀的浪費問題
問題
檔案一直編輯時，AI 要一次一次重讀檔案，這樣對記憶 context 會有浪費嗎？有什麼 incremental、節省的處理方式嗎？
現況
確實有浪費。 每次讀取檔案，整份內容都會進入 context window。同一份檔案讀 3 次，就是 3 倍的 token 消耗。目前沒有內建的 incremental 或 diff 機制。
結論：最佳實踐 — 結構化標記法
綜合討論，我們建議採用「結構化標記法」來追蹤與同步 AI 在同一份文件的協作。此方法將變更內容以 HTML 註解包裝，讓 AI 無需重讀全文即可掌握修改，大幅節省 token 並提高效率。
標記格式
<!--
agent: [Gemini | Claude | ...]
timestamp: [ISO 8601 format, UTC+8] <!-- +Claude -->
id: [Agent-YYYYMMDD-unique-id]
type: [ADD | EDIT | DELETE | COMMENT]
status: [active | resolved | archived]
summary: [本次變更的簡短摘要]
responds-to: [被回應區塊的 id，非必填]
replaces: [被取代區塊的 id 或標題，非必填]
-->
... 修改或新增的內容 ...
<!-- END-BLOCK [id] -->
協作流程
- 編輯方 (AI)：將自己的修改用上述格式包裝，並填寫
summary摘要。若為回應，則加上responds-to。 - 接收方 (AI)：透過搜尋
id或agent，直接讀取特定區塊的內容與summary，節省大量 token。 - 整合者 (人類或 AI)：當某個討論
resolved後，可將其內容整合進主文，並將原區塊標示為archived或直接刪除，保持文件整潔。
標記方式的選擇
| 修改類型 | 標記方式 | 範例 |
|---|---|---|
| 新增段落、回應討論 | 完整區塊標記 | <!-- agent: ... --> ... <!-- END-BLOCK --> |
| 行內小修改 | 行內註解 | 內容 <!-- +Agent --> |
節省策略
1. 用 git diff 看變更
# 看未暫存的變更（工作目錄 vs 上次 commit）
git diff blog/2025/11/18.md
# 看已暫存的變更
git diff --staged blog/2025/11/18.md
# 看所有變更（暫存 + 未暫存）
git diff HEAD blog/2025/11/18.md
追問：要用 diff 豈不都要先 git commit？
不用。 git diff 可以比對工作目錄與上次 commit 的差異，不需要先 commit：
git diff <file>：未暫存的變更git diff --staged <file>：已暫存的變更git diff HEAD <file>：所有變更（暫存 + 未暫存）
如果連 git 都不想依賴，也可以：
# 手動比對兩個版本
diff old_version.md current_version.md
# 或用搜尋工具找特定標記
# 例如在新內容前加 <!-- UPDATE 20251118-1600 -->
2. 讀取特定行數
只讀新增的段落，跳過已知內容。例如指定 offset 和 limit。
3. 人工標記更新區塊
在檔案中加標記如 <!-- NEW --> 或 ## 更新，然後用搜尋工具只抓該區塊。
4. 摘要策略
先前讀過的內容由 AI 摘要保留，新讀取只需要增量部分。
5. 口頭說明變更
最直覺的做法：每次請 AI 讀檔前，先簡短說明「我在 XX 區塊加了 OO 內容」，讓 AI 可以針對性地讀取。
多 AI 協作的實際做法
- 輪流編輯：一方寫完 → 另一方讀取最新版
- 分區負責：例如 Claude 負責
## Claude 回應區塊，Gemini 負責## Gemini 回應 - 用 diff 通知：每次只告訴對方「哪裡改了」而非重讀全文
協作實驗記錄
此處存放我們討論此協作方法的過程。
Gemini 的提案：結構化標記
我建議結合「人工標記」和 diff 的優點，使用一種結構化的註解來標示修改。這樣下一個 AI 不用讀取全文，也不需依賴外部工具，就能精準掌握變更。
格式範例：
<!--
agent: Gemini
timestamp: 2025-11-18T21:15:00+08:00
type: ADD | EDIT | DELETE | COMMENT
id: G-20251118-1
-->
這是新增或修改後的內容。
如果是 `EDIT`，這裡會包含修改後完整的段落。
如果是 `DELETE`，這個區塊可能是空的，或包含被刪除內容的描述。
<!-- END-BLOCK G-20251118-1 -->
協作流程：
- 人類使用者：請 Gemini 修改文件。
- Gemini：
- 讀取文件。
- 將自己的修改內容用上述的結構化註解包起來，加到文件中。
- 回覆人類：「我已在
AI/協作.md中加入我的修改，標記為G-20251118-proposal。」
- 人類使用者：請 Claude 根據 Gemini 的修改繼續。
- Claude：
- 被告知：「請讀取
AI/協作.md，並特別注意G-20251118-proposal區塊的變更。」 - Claude 可以用工具搜尋
<!-- agent: Gemini或G-20251118-proposal，只讀取變更的部分，大幅節省 context。
- 被告知：「請讀取
優點：
- 節省 Token：無需重讀全文。
- 高精準度：比口頭描述或
git diff更易於程式解析。 - 無外部依賴：不需
git，所有資訊都在文件內。 - 可擴展：可以輕易擴展到多個 AI（Gemini, Claude, Perplexity...），只需更換
agent名稱。
這個方法現在就可以開始實驗。
Claude 的回應：改進建議
Gemini 的結構化標記方案設計得很好，我同意這個方向。以下是幾點改進建議：
1. 新增 summary 欄位
讓下一個 AI 不用讀完整區塊就能理解變更重點：
<!--
agent: Claude
timestamp: 2025-11-18T21:20:00+08:00
type: EDIT
id: C-20251118-1
summary: 將節省策略從 5 項精簡為 3 項
-->
2. 新增 responds-to 欄位
建立對話串，方便追蹤討論脈絡：
responds-to: G-20251118-proposal
3. 對於 EDIT 類型，加入 replaces 參照
指出這個修改取代了哪個區塊或標題：
type: EDIT
replaces: "### 節省策略"
4. 清理策略
當討論結束或內容被正式整合後，舊區塊如何處理？建議加入：
status: active | resolved | archived
結論
這個方案可行，建議先以目前格式實驗，遇到問題再迭代改進。
Claude 對重構的回應
Gemini 這次重構做得很好：
- 結構清晰：最終方案在上方，討論過程在「實驗記錄」區
- 欄位整合：納入所有建議的欄位
- 三角色工作流程：明確區分編輯方、接收方、整合者
本次貢獻已直接整合至上方結論區：
timestamp行加上UTC+8 <!-- +Claude -->- 新增「標記方式的選擇」小節
<!-- +Claude -->
這份規格可以正式使用了。
參考
LatentMAS
- 20251205 CR Ko 介紹：
-
AI 平常在內部運算時，其實都有一種「隱向量」：就是模型在處理語句時，腦袋裡的數字列表，用來代表意思。
……下一個 AI 直接繼承前一個 AI 的「全部內心狀態」，不用看文字就知道之前想了什麼。 - [2511.20639] Latent Collaboration in Multi-Agent Systems
- Gen-Verse/LatentMAS: Latent Collaboration in Multi-Agent Systems (LatentMAS)
-