團隊協作

提示工程曾經是個單打獨鬥的手藝：一個人、一個對話視窗、一串巧妙的文字。但認真做 AI 開發的團隊已經不是這樣運作了。進入 2026 年，建構與營運 AI 輔助的軟體是一項團隊運動，而且團隊成員還包含了 AI 編碼 agent，牠們是實際參與工作的夥伴，而非單純的工具。Agent 會讀你的儲存庫、遵循你的慣例、提出變更，甚至互相審查彼此的產出。這徹底改變了「協作」這個詞必須涵蓋的範圍。

這份文件的核心設計原則是：你的共享慣例必須同時服務人類與 agent。 一位新進工程師和一個剛開啟的 agent session，都帶著對團隊運作方式「零背景知識」的狀態到場。讓新人快速上手的那些產物（一份慣例檔、一座提示庫、一組成功範例與失敗紀錄）正好就是 agent 用來表現得像個團隊成員所讀取的東西。把這些產物做好一次、像對待程式碼一樣版本控制它們，兩種受眾就都能受益。

本文涵蓋團隊如何安排角色、共享情境、提示庫、審查、上手與擴展。更深入的主題交給姊妹篇處理：測試與評測機制在 測試與優化、治理與當責在 安全與倫理、部署與推出機制在 生產部署，而委派、平行化、驗證等 agentic 工作流程層面則在 Agentic 工作流程。

角色與責任

小團隊會把以下好幾個角色合併到同一個人身上；大團隊則拆得更細。重點不在組織圖，而是對下列每一項責任，都有一個指名的負責人。一項沒人認領的責任，就是一場等著發生的事故。

提示／AI 工程師。 負責驅動模型行為的提示、系統訊息與情境檔。設計模板、依評測調校模板，並決定特定任務的情境該如何界定範圍。實務上，這個人花在「決定哪些東西進入情境視窗」的時間，和花在「措辭請求」的時間一樣多，這正是 Vibe Coding 總覽 所描述的、從提示工程到情境工程的轉變。決策權：一個提示或模板如何結構化、何時變更、其驗收標準為何。

領域專家。 提供模型欠缺、而工程師也無法假裝擁有的專業判斷：在這個領域裡正確答案長什麼樣、哪些邊界案例重要、哪裡會出現「流暢但錯誤」而造成實際傷害的輸出。他們策劃 few-shot 範例、審查有重大後果的輸出，並為評測集定義「好」的標準。決策權：一個輸出「在這個領域裡是否正確」，這往往會推翻工程師眼中看似合理的結果。

QA／評測負責人。 負責評測集與品質門檻。建立並維護一個提示必須通過的測試案例、在每次變更時執行它們，並在生產環境中盯著回歸與漂移。這個角色是「它在我那一個範例上能跑」與「它在我們實際服務的各種案例上都能跑」之間的守門人。建構這些測試套件的機制（基準、A/B 測試、穩健性、失敗模式分析）歸 測試與優化 處理；在協作上的重點是：每個提示模板都有一個評測集，而且有一位指名的負責人。 決策權：一項變更是否已通過它的門檻。

平台／DevOps。 負責提示賴以運行的基礎設施：版本控制、CI 流水線、部署、監控、機密、以及提示庫周邊的存取控制。他們讓審查與推出流程真正落地（也就是 生產部署 裡的分階段推出、金絲雀與回滾路徑），並為無頭執行與 CI agent 設定護欄（界定範圍的權限、有上限的回合數、沙箱化）。常用工具上，版本控制以 Git／GitLab 為主、協作平台如 HackMD／Notion、專案管理用 Jira／Redmine；若採用本土雲端（如中華電信、遠傳），則須遵循「資料不出境」原則。決策權：一項變更如何、何時抵達生產環境，以及自動化 agent 被允許碰觸什麼。

治理／當責負責人（法務合規）。 負責回答「當模型出錯時，誰要負責？」，答案不是模型，而是一位指名的人或團隊。這個角色決定哪些資料可以送出、使用者會得到什麼揭露、哪裡必須保留真人在迴圈中、以及升級路徑通往何處。在台灣脈絡下，這往往牽涉個資法、特定產業的主管機關（例如金融、通訊）規範，因此法務部門宜常態參與、而非事後才被叫來補簽。這個角色在 安全與倫理 有深入著墨，包含「指名負責人」的紀律；在協作上的要點是：這位負責人會為有重大後果的 AI 輔助功能背書，並在其中之一出錯時找得到人。決策權：某項用途究竟是否被允許。

Agent 也部分擔任角色

一個審查 subagent 可以做第一輪審查；一個寫測試的 subagent 可以草擬評測集；一個研究 subagent 可以蒐集領域事實。但牠們都不擁有那份責任，仍然是由真人擁有。把 agent 的貢獻當成「落進某位指名真人佇列裡的工作」，絕不要當成「一個會替自己簽核的角色」。

人與 agent 的共享情境

這是 2026 年的現代化重點，也是大多數團隊能取得「最大、最便宜」槓桿的地方。有兩項產物承載著你團隊的工作知識，兩者都納入版本控制：

1. 一份共享慣例檔：Claude Code 用 CLAUDE.md、Codex 與愈來愈多的跨廠商工具用 AGENTS.md（見 總覽 對 AGENTS.md 作為新興標準的說明）。這是 agent 在每個 session 開始時讀的檔案，也是新人第一天讀的檔案。同樣的內容、兩種受眾。
2. 一座提示與評測庫：經過測試的模板，以及它們必須通過的案例（見下一節）。

該檔放什麼

放那些你本來就得對每位新同事、每個剛開啟的 agent session 反覆交代的事情：如何跑測試、專案的慣例、地雷在哪、以及不要碰什麼。Claude Code 指南 與 OpenAI Codex 指南 涵蓋各工具的機制（檔案放置位置、範圍、匯入方式），所以本文聚焦在這份檔案周邊的團隊紀律。

# Project: Acme API   (CLAUDE.md / AGENTS.md)

## Commands
- Test:  用專案的測試指令跑測試套件
- Lint:  跑專案的 linter
- Dev:   啟動本地開發伺服器

## Conventions
- 嚴格型別；不留逃生口。
- 測試與原始碼放在一起。
- 絕不手動編輯產生的檔案。

## Prompt & eval library
- 模板放在 prompts/templates/ 底下，每個都有負責人與評測集。
- 透過小而聚焦的變更修改模板；審查者見 CODEOWNERS。

## Out of bounds
- 不要把客戶個資送進模型；先去識別化（見 security-ethics）。

有三條規則能讓這份檔案成為團隊資產，而不是一份過時的 README：

• 保持精簡並持續修剪。 一份臃腫的慣例檔，會在每個 agent session 都耗掉情境；超過某個大小後，模型實質上就會忽略它。對略讀它的人類也一樣。高訊號的規則勝過鉅細靡遺的規則，Claude Code 指南 把這條列為這份檔案最重要的單一規則。
• 用 CODEOWNERS 認領它。 指派一位審查者（或一個小組）負責慣例檔，讓變更有人看。當一條慣例改變時（新的測試指令、改名的模組、新的「不要碰」），就在同一筆變更裡更新檔案，而不是幾週後再憑記憶補上。
• 把漂移當成 bug。 當一個 agent 或同事踩到一個「這份檔案本該事先警告」的坑，修法就是當下在檔案裡加上一行。慣例檔是團隊累積下來的「早知道就好了」清單。

提示與評測庫管理

這座庫是團隊「經過測試的提示」與「證明它們有效的案例」之共享清單。把既有的 /prompts 樹狀結構，改造成有結構、有歸屬、找得到的東西。

prompts/
├── templates/
│   ├── customer-support.md
│   ├── content-generation.md
│   ├── data-analysis.md
│   └── legal-compliance-tw.md       # 法務合規（台灣）
├── evals/
│   ├── customer-support.cases        # 此模板必須通過的測試集
│   ├── content-generation.cases
│   └── data-analysis.cases
├── examples/
│   ├── successful-cases.md
│   ├── failure-analysis.md           # 出了什麼錯、為什麼
│   ├── privacy-law-prompts.md        # 個資法相關
│   └── ncc-compliance.md             # 通訊主管機關相關
└── CODEOWNERS                        # 每個模板／目錄一位負責人

有幾項做法能避免共享庫腐爛：

• 每個模板都配一個評測集。 沒有案例的模板只是口耳相傳的傳說。評測集是審查者在核准變更前會跑的東西，也是日後抓出回歸的東西。這些測試集的結構（基準、邊界案例、穩健性、偏誤檢查）歸 測試與優化；庫只負責把案例放在它所測試的模板旁邊，讓兩者不會各自漂移。
• 把一切都放進 Git 版本控制。 模板、評測案例、範例與慣例都是版本控制下的純文字，帶有變更歷史，並在變更說明裡記錄每次改動為什麼這麼做。這就是同事（或 agent）理解「一個模板如何演變成今天樣貌」的方式。
• 以小而聚焦的變更進行審查。 寧可多次小變更，也不要偶爾來一次大變更，這就是 Small-CL 紀律。一筆只改一個模板及其評測集的變更，幾分鐘就能審完；一筆重寫整座庫的變更則否，而且只會被橡皮圖章式地通過。小變更也讓「出問題時的回滾與二分定位」變得輕而易舉。
• 讓它找得到。 一個沒人找得到的模板，會在某個對話視窗裡被重新發明一次，而那個複製品完全跳過了你的評測。扁平、可預測的路徑、好懂的命名，加上慣例檔裡一份簡短索引，勝過一套巧妙的分類學。若你的儲存庫支援，跨 prompts/ 的快速搜尋就是發現工具；要避免的失敗模式是「一層又一層、沒人記得住的深層資料夾結構」。
• 每個模板指名一位負責人。 每個模板（或目錄）在 CODEOWNERS 裡都有一位負責人，審查它的變更並回答關於它的問題。這是「凡事都去問那唯一的提示專家」瓶頸的解藥：把能力分散並寫下來，而不是握在某一個人的腦袋裡。
• 刻意界定存取範圍。 對庫的讀取權限應該很廣（這正是重點所在），但寫入權限要走審查。平台／DevOps 設定存取控制；治理負責人則判斷某個模板是否敏感到該加以限制。

審查與變更流程

無論作者是人類或 agent，每一筆對提示、評測或慣例檔的變更，都走同一條路：

1. 需求：這筆變更解決什麼問題、成功長什麼樣。對任何比微調更大的事情而言，這就是一份規格賺回它身價的地方（見 Agentic 工作流程 談規格作為較大工作的交接物）。
2. 設計：提議的模板或情境變更。審查一份計畫很便宜；審查一百行錯誤的 diff 則否，這就是治理 agent session 的那套「計畫與執行分離」紀律。
3. 測試／評測：跑該模板的評測集。在它的測試集通過之前，變更不得前進。這道門檻屬於 QA 負責人，其機制在 測試與優化。
4. 同儕審查：CODEOWNERS 審查者就變更本身的內容來審。保持小（Small-CL），讓審查是真的審查、而非橡皮圖章。
5. 分階段推出：依 生產部署，搭配監控與回滾路徑逐步上線。新的提示行為會先抵達一小部分流量，再擴及全部。
6. 回饋：生產訊號與使用者回饋流回評測集與下一筆變更。一個在生產環境抓到的回歸，會變成一個新的測試案例，使它無法再悄悄重演。

審查 AI 生成的變更

如今 agent 撰寫了很大一部分的變更，而誘惑就在於：因為 diff 看起來乾淨、agent 又聲稱它能跑，就揮手放行。要抵抗這股誘惑。驗證與安全 與 Agentic 工作流程 的紀律在此直接適用：

• 要證據，不要斷言。 「我修好了」不算通過審查。要求 agent 提供牠跑的指令與牠看到的輸出：一次通過的評測、一次乾淨的建構、一份行為差異的對照。
• 用一位在全新情境裡的獨立審查者。 一個審查自己作品的 agent，早已在腦中說服自己越過了那些缺口。換一位獨立審查者（真人，或一個從沒看過撰寫者推理過程、在乾淨 session 裡的 agent）能抓到更多。把審查範圍限定在正確性與既述需求上，免得它無中生有地堆砌臆測性的潤飾。
• 作者的身分不改變門檻。 真人撰寫與 agent 撰寫的變更，通過同樣的門檻。因為 agent 產出得快，就替它降低門檻，正是「把 vibe-coding 的速度與生產環境的賭注搞混」的失敗模式。

知識分享與上手

最便宜的上手，是你的共享產物替你完成的那一種。當慣例檔與庫都健康時，一位新成員（無論是人類或 agent）靠讀它們就能進入狀況，而不必去打擾資深工程師。

• 文件標準。 慣例、模板與範例要在「改變行為的那同一筆變更裡」保持更新，而不是當成另一件「之後再來更新文件」、結果永遠不會發生的工作。過時的文件比沒有文件更糟，因為它會主動誤導人類與 agent。
• 讓一位新人上手。 先把他帶到慣例檔，再到提示庫與其範例。一份好的慣例檔加上一份自足的規格，能讓新同事不必參與當初的設計對話就執行真正的工作，這正是讓全新 agent session 也能做到的那種自足性。
• 讓一個新 agent 上手。 一個全新的 agent session 就是一位失憶的新團隊成員。牠靠在 session 開始時讀慣例檔來上手。如果 agent 老是把某件事做錯，修法通常就是那份檔案裡缺了一行，讓 agent 上手與讓下一位新人上手，是同一筆編輯。
• 內部範例，包含失敗。 維護一份 failure-analysis 紀錄：出錯的提示、症狀是什麼、以及根本原因。失敗分析教得比成功展示廊更快，因為它指名了陷阱所在。把它連到 測試與優化 裡的失敗模式目錄。
• 事後學習。 當一個 AI 輔助功能在生產環境出錯時，把學到的東西變成耐久的產物：一個新的評測案例，讓該失敗無法再悄悄重演；以及一條慣例檔註記，讓下一個 session 避開那個陷阱。一個沒有產出任何產物的事故，必定會重演。
• 輕量工作坊。 短而規律的聚會，讓大家分享什麼有效、走過一個棘手的模板、或檢討一次值得一提的失敗。可以納入師徒制度（資深帶新人）、與台大／交大等學術機構的合作交流、甚至跨公司的經驗交流。保持輕量，目標是流通隱性知識，而不是建立一套認證制度。

無瓶頸的擴展

2026 年要擴展一個團隊的 AI 工作，意味著同時跨「人」與「agent」做平行化，同時讓每一條工作流都有一位真人當責。這些機制直接來自 Agentic 工作流程。

• 模組化、可重用的提示。 用共享、經測試的構件來組合，而不是每個任務都重寫一整塊。一個已經通過自身評測的可重用模板，比一個在對話視窗裡跳過所有門檻的全新提示，更快也更安全。
• 跨人與 agent 平行化。 互不相依的任務同時進行。讓 agent 能平行化的關鍵機制是 git worktrees：每個 agent 一個獨立的工作目錄與分支，於是並行的 agent 編輯不同的 checkout，在磁碟上永不相撞。沿著功能或領域邊界拆解：拆那些碰不同檔案的工作；不要拆碰同一批檔案的工作，那只會製造合併衝突。
• 把昂貴的閱讀委派給 subagent。 一個 subagent 在自己的情境視窗裡運行，只回報一份摘要：研究、某子系統運作方式的概覽、第一輪審查。雜訊留在 subagent 裡；主 session 與真人保持專注。這就是一個人如何在不被淹沒的情況下監督好幾條工作流。
• 避免「唯一提示專家」瓶頸。 如果只有一個人能改提示，那個人就是你的天花板，也是你的單點故障。分散式的 CODEOWNERS、一座找得到的庫、一份健康的慣例檔，能把這份能力散開，讓團隊擴展到超越任何單一專家。
• 衝突解決與升級。 當兩筆變更對一個模板的方向意見相左時，由該模板的負責人裁定；當一項領域判斷與一項工程偏好衝突時，正確性以領域專家的決定為準。當模型拒絕回應、產出違反政策的東西、或正確答案不明朗時，案件循治理負責人定義的升級路徑處理（見 安全與倫理），一條死路就是一種隱藏的失敗模式。
• 出事時的歸屬。 每個模板、評測集與 AI 輔助功能都有一位指名負責人，在它出錯時回應。「是 agent 幹的」不算一位負責人。把一次生產失敗追溯回一個人（而非一個模型），正是讓系統可改進、而非神秘莫測的關鍵。

下一步

• 測試與優化：建立每個模板與審查門檻所仰賴的評測集。
• 安全與倫理：治理、指名負責人的紀律，以及升級路徑。
• 生產部署：提示變更的分階段推出、監控與回滾。
• Agentic 工作流程：worktrees、subagent 與委派，用於跨 agent 的平行工作。
• 驗證與安全：如何審查 agent 撰寫的變更而不淪為橡皮圖章。
• Vibe Coding 總覽 · Claude Code · OpenAI Codex：你的團隊與其 agent 都會讀的共享 CLAUDE.md / AGENTS.md 慣例。