> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 業界怎麼做 AI 多人協作：拿四原則對照自己的工具箱
- URL: http://localhost:2368/ai-teamwork-benchmark/
- Published: 2026-07-10T11:48:05.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 把業界（以 Anthropic 內部為主）的人機協作四原則——公開工作、明確角色、北極星寫下來、信任漸進——對照自己的 AI 協作工具箱。照出來的差距集中在讓 AI 產出流回團隊場域，另記三個此前沒用的方法。延續『問 AI 你怎麼做到的』的最佳化姿態，這次問的是業界。
- Author: yuchang23
- Tags: #wiki, #wiki-method

> **定義**：最佳化不只是悶著頭迭代自己的做法，也包括拿「做得最好的人怎麼做」當鏡子。這篇把業界（以 Anthropic 內部為主）的人機協作四原則，對照自己現有的一套 AI 協作工具箱，找出差距與補法。

背景是一個五人的製造業團隊，日常靠一位不寫程式的操作者提需求、做決策、驗收，實際的程式由 AI 實作。上一篇（[把規格決策做成團隊問卷：選載體的三個條件](https://yuchang23.com/spec-decisions-to-team-form/?ref=localhost)）把規格決策做成團隊問卷、由 AI 幫忙收斂答案，是自己動手做的一輪。做完之後的下一步，不是繼續悶頭迭代，而是先看看別人怎麼做。

## 這次的問法：從「問 AI」到「問業界」

[李佳達訪談那篇](https://yuchang23.com/right-problem-framing/?ref=localhost)裡有一個可帶走的習慣：看到 AI 或別人做出好東西，第一反應是追問「你是怎麼做到的」，把背後的思考路徑打包成可重複使用的指令，再拿自己的專案驗證。這次沿用同一個姿態，只是把追問的對象換成業界——「你們是怎麼做到的」，把答案帶回來對照自己。那篇也提醒過：別只抄工具，要問背後的思考；下面對照的重點因此放在原則，而不是照搬人家用哪個平台。

## 業界怎麼做

Anthropic 內部把 AI 當「頻道裡的同事」：團隊在 Slack 頻道 @ 它、開共享討論串，它看得到整串對話的脈絡。[官方數字](https://claude.com/blog/how-anthropic-teams-use-claude-code?ref=localhost)是產品團隊約 65% 的程式碼由內部版的這個 AI 產出，用途擴及產品指標、資料分析、客服工單。

[官方歸納](https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic?ref=localhost)的人機協作四原則：

1. **公開工作、給足脈絡**：Agent 只能用「寫下來、搜得到」的資訊，所以頻道預設公開、決策寫進文件、寫技術文件時把 AI 當成主要讀者。
2. **明確角色清單**：人和 Agent 都列在團隊名單上，各自的職責與工具權限寫清楚。
3. **北極星目標白紙黑字寫給 Agent**：把「這個系統為誰解決什麼、什麼不能妥協」寫下來給它看，而不是留在人腦裡。
4. **信任漸進**：初期人工審查一切，可靠了才逐步放權；用「執行者－驗證者」兩個 Agent 互查，並要求 Agent 定期寫「教訓與失誤」的回顧。

一個案例：工程團隊讓 Agent 獨立處理 500 個錯誤修復，從人審每一項，逐步演進到 Agent 主動標出「需要人介入」的決定。

其他公司走同一個方向：[Slack 開放 agent 平台](https://slack.com/blog/news/powering-agentic-collaboration?ref=localhost)，讓各家 AI 進頻道當隊友、吃即時脈絡；[Notion 的 Custom Agents](https://dust.tt/blog/slack-ai-agents?ref=localhost) 接進 Slack，自動找重複工單、產週報；Dust 的客戶把 agent 串起全公司工具，當成單一知識入口。共同趨勢是：AI 嵌進團隊既有的協作場域，而不是叫大家去用一個新工具。

## 對照自己的工具箱

以下對照表是的整理了現況與建議，「差距與補法」欄是採納的方向。

| 原則           | 現況                                      | 差距與補法                                                 |
| ------------ | --------------------------------------- | ----------------------------------------------------- |
| AI 進既有場域     | ✅ 問卷卡片發進 Teams、表單開在團隊本來就在用的 monday      | —                                                     |
| 給 AI 寫下來的脈絡  | ⚠️ 規格與決策記在 repo 文件和 AI 的專案記憶，但團隊看不到全貌   | 決策日誌同步到團隊看得到的地方；AI 的產出（問卷彙整、進度）用 webhook 發回頻道，形成閉環    |
| 明確角色清單       | ⚠️ AI 側有分工（規格展開、驗證、寫作各有 agent），人的側只在默契裡 | 每個專案寫一份角色表：誰訂規格、誰實作、誰是領域代表、哪類決策發問卷給誰                  |
| 北極星寫下來       | ❌ 在人腦和對話裡                               | 每個 repo 放一份專案說明檔（系統為誰解決什麼、不能妥協的事），任何 AI session 進來就讀到 |
| 信任漸進＋執行者－驗證者 | ✅ 最強項：規格先行、實作與驗收分開、預覽環境驗過才上線            | 補一個小習慣：每輪完成報告固定含「失誤與教訓」段                              |

## 三個此前沒用的方法

我還請Claude提出幾個可以應用的方法，還在評估採納：

1. **會議逐字稿萃取決策**：AI 連線讀得到線上會議的逐字稿，會後抽出「決策了什麼、誰要做什麼、什麼沒定案」寫進文件。正好對應「把口頭的變成寫下來的」這條原則。
2. **多專案、不同成員組合的脈絡隔離**：AI 記憶按專案資料夾隔離是現成機制；跨專案共用的「人物地圖」（哪個專案跟誰討論、誰拍板）放進全域設定，讓所有專案繼承。
3. **沒接的服務不等於不能用**：例如沒接某雲端陣營的服務，它的線上表單一開始被判出局；但接上該陣營的雲端硬碟連接器後，「AI 讀得回答案」就成立，只是「AI 建表單」仍缺；同陣營的另一組替代品反而一條連接器都不用加。工具判斷要按「能建 × 能讀回 × 帳號門檻」三條件，隨連接狀態重新評估。

## 比較之後的差距

這次的差距集中在「公開工作」：AI 跟單一操作者之間的協作已經順了，強項是信任漸進與執行者－驗證者這一塊；還沒補上的，是讓 AI 的產出流回團隊看得到的場域。最佳化的鏡子照的不是「我做得好不好」，而是「做得最好的人多做了哪一步」。

## 相關條目

- [把規格決策做成團隊問卷：選載體的三個條件](https://yuchang23.com/spec-decisions-to-team-form/?ref=localhost)
- [問對問題：分清障礙與限制](https://yuchang23.com/right-problem-framing/?ref=localhost)
- [讓 AI 互相把關：多角色分工](https://yuchang23.com/multi-agent-review-roles/?ref=localhost)