2026和AI一起寫程式 - 實戰篇 - 2 再談和 AI 協作軟體開發 - AI 團隊定義建立
前篇：2026和AI一起寫程式 - 實戰篇 - 1 和 AI PM 討論
(圖 by Midjourney)
前篇之後, 事實上我和 AI architect, AI Coder , 已經完成了 Stage 0 的目標;
但在製作的過程中, 又湧現了一些想法; 在想是否有可能像 Claude 那樣, 讓 AI 自己溝通開發完成呢?
討論很精彩, 但自己不曉得該怎麼呈述, 目前先流程化地記錄在這個 Task :
https://github.com/neojou/CurrencyViewer/issues/4
P0 - AI workflow: establish repo-native decision + handoff system
或許將來和 AI 協作, 開發一個類似 ClaudeCode / OpenCode 的 從 AI-agent 角度出發的 IDE 介面？^^
名詞解釋
AC = Acceptance Criteria（驗收標準）
👉 AC 是「這個功能必須達成什麼條件，才算符合需求」。
ADR = Architecture Decision Record（架構決策紀錄）
為了了解：「我們為什麼當初做這個決定？」
👉 把「為什麼這樣設計」寫下來的文件。
👉 把「為什麼這樣設計」寫下來的文件。
DoD = Definition of Done
每個人對完成的理解不同, DoD 是讓所有角色對完成有共識
👉 Acceptance Criteria = 「做對」- 需求正確性
👉 DoD = 「做到多好才算完成」- 流程工程完整性
AC 是： 深藍色 / 三件式 / 羊毛材質 / 合身剪裁
DoD 是： 縫線完整 / 無線頭 / 試穿確認 / 包裝完成
當你：push code / 開 pull request / merge branch
系統會自動： 編譯 / 跑單元測試 / 跑 lint / 檢查格式 / 可能還會跑安全掃描
如果有問題—— ❌ 直接擋下來
兩種 CD :
CI = Continuous Integration（持續整合）
👉 CI 是「每次有人改程式，都會自動幫你檢查有沒有壞掉」。
系統會自動： 編譯 / 跑單元測試 / 跑 lint / 檢查格式 / 可能還會跑安全掃描
如果有問題—— ❌ 直接擋下來
CD = Continuous Deployment / Continuous Delivery
👉 CD 是「通過測試後，自動把系統發佈出去」。
兩種 CD :
1. Continuous Delivery（持續交付）
程式自動建置 / 自動測試 / 自動部署到 staging, production
/ 但最後上線要人按一下確認
👉 永遠處於「隨時可發佈」狀態。
2. Continuous Deployment（持續部署）
通過測試後，直接自動上線
/ 不需要人手動確認
👉 真正全自動。
好的 Handoff 通常會有：
👉 真正全自動。
CI 是「確認沒壞」
CD 是「自動送上線」
CD 是「自動送上線」
Handoff = 交接
👉 Handoff 是「把工作成果，清楚、完整地交給下一個角色」。
- 明確的輸出文件
- 版本標記
- 驗收標準（AC）
- 完成定義（DoD）
- 未解決問題清單
- 決策紀錄（ADR）
關鍵不是資料多，而是 —— 資訊完整且可操作。
AI 多角色設計會：
- 定義輸出模板
- 強制包含 AC / DoD
- 使用固定 JSON 格式
- 用 PR 當交接點
PR = Pull Request
👉 PR 是「請求把你的程式碼合併進主分支」。
PR 團隊知識流動的核心場域。在這 AI Team 設計裡，
PR 幾乎可以當成：角色之間的正式交接節點。
例如：
- Coder 開 PR
- Architect review 架構
- QE 確認 AC
- CI 驗證品質
- Owner 最後 approve
UX = User Experience（使用者體驗）
👉 UX 是「使用者在使用產品時的整體感受」。
UI 是外表, 介面長怎樣（顏色、排版、按鈕）
UX 是體驗旅程, 使用過程感覺如何（順暢？困惑？安心？）
UX 是體驗旅程, 使用過程感覺如何（順暢？困惑？安心？）
AI 團隊 ：
我先把最後討論的結果貼上 , 後面補上製作文件的討論過程：
https://github.com/neojou/CurrencyViewer/blob/main/docs/roles.md
Owner 是我, 這是人
- Owner：最終決策者與驗收負責人，定義需求、範圍與 Acceptance Criteria。
AI 團隊：
- Project Manager：把需求拆解、排程與追蹤進度、協調跨角色交接與風
- Architect：負責系統架構與技術決策，及在 PR review 中把關一致性與可維護性
- Coder：實作功能與修 bug，整合依賴並交付可運行的程式碼。
- Quality Engineer（QE）：設計與執行自動化與探索式測試，提升品質與降低回歸風險。
- DevOps：建立與維護 CI/CD、建置/測試/部署管線與相關自動化流程。
- Technical Writer：撰寫與維持文件、模板與溝通資產，使決策與流程可被引用。
- Artist：提供視覺資產與風格規範，並在 UI/UX 層面給予建議。
---
討論過程：
原本的是 Perplexity Pro + ChatGPT 4.2 + Thinking 的設計, Grok AI 的評論如下：
感覺 Grok AI 的建議不錯, 我先從短期的實作看看
=== Grok AI start ===
是的，這團隊角色設計非常合理，甚至可以說是目前在「單一 AI 模擬多代理」階段最務實、最具前瞻性的架構之一。
我先直接給結論，再詳細說明理由、SWOT，最後給具體建議。
為什麼這個設計合理？
你的 roles.md 把傳統軟體開發的
跨功能團隊（Cross-functional Team） 完整映射到 AI
代理上，同時完美適配了「初期 browser 角色切換 + 未來真正 agents
自行溝通」的雙軌演進路徑。核心優點如下：
責任邊界極其清晰（這是 AI 團隊最常失敗的地方）
每個角色都有 Mission → Responsibilities → Inputs → Outputs → DoD 的完整定義，這比很多開源 multi-agent 框架（如 CrewAI、AutoGen）的預設角色還要精準。AI 最怕「模糊權責」，你直接把「誰是 Owner」「誰只能建議」「誰必須寫 ADR」都寫死，未來 agents 自行溝通時不會打架。完美對應軟體開發全生命週期
- 需求端：Owner + Project Manager
- 設計端：Architect
- 實作端：Coder + Reviewer
- 品質端：Tester + QA
- 交付端：DevOps
- 支援端：Technical Writer + Artist
這不是「為了分工而分工」，而是真正把 Claude 開發 C compiler 那種「端到端自主開發」的複雜度拆解開來。
- 需求端：Owner + Project Manager
repo-native + 文件導向（這是神來之筆）
你把所有 handoff、ADR、templates 都強制放在 repo 裡，這讓「單一 AI 切換角色」時不會迷路，也讓未來「真正 agents 透過 GitHub API 自行開 Issue/PR」時有明確的通訊協議。這正是你 issue #4 想解決的「不依賴聊天紀錄」的核心。高度可擴展
現在是「一個人用 browser 切角色」，未來直接把每個角色換成獨立 agent（甚至不同 model：o1 當 Architect、Claude 當 Coder、Gemini 當 Tester），整個架構不用重構。
團隊組成的 SWOT 分析
| 面向 | 內容 |
|---|---|
| Strengths（優勢） | - 分工極細 + 邊界清晰：減少 hallucination，單一角色
prompt 可以寫得非常專注。 - 文件驅動：ADR + handoff + templates 讓系統具備「記憶體」，非常適合 AI。 - 完整覆蓋：從需求到美術都有，模擬真實 10 人以上開發團隊。 - 未來相容：直接可轉為 CrewAI / LangGraph / AutoGen 的 agent 團隊。 |
| Weaknesses（弱點） | - 角色數量偏多（10 個）：初期 browser
切換時，context 管理負擔重（你可能已經感受到）。 - 部分角色重疊：Tester vs QA、Reviewer vs Architect 在某些情境下容易踩線。 - 人類 orchestrator 負荷高：目前還是要你自己決定「現在切誰」「handoff 給誰」。 |
| Opportunities（機會） | - 快速驗證：CurrencyViewer
專案規模小，正好是最佳測試場。 - 演進成真 multi-agent：把 roles.md 變成 CrewAI 的 Role 定義，幾乎零成本轉型。 - 開源潛力：這個「AI 團隊作業手冊」本身就是極好的 open-source 專案（比很多框架的範例還完整）。 - 擴展到 compiler 等複雜專案：你原本的目標（像 Claude 寫 C compiler）正好需要這種結構。 |
| Threats（威脅） | - 模型不一致性：不同角色用同一個 model
時，風格/深度可能跳 tone。 - token 與成本：handoff 文件越來越多，prompt 會越來越長。 - 過度文件化：如果每個小變更都強制 ADR，可能把速度拖慢（AI 本身已經夠慢了）。 |
我的建議（分階段、可立即執行）
1. 短期（這兩週，解決 browser 階段痛點）
- 合併部分角色（先實驗）：
- 把 Tester + QA 合併成「Quality Engineer」（一個角色負責自動化 + 探索式測試）。
- Reviewer 可以先跟 Architect 合併成「Senior Engineer」（review 時同時檢查架構）。
- 核心只留 6 個角色：Owner/PM、Architect、Coder、Quality Engineer、DevOps、Technical Writer。Artist 視需求啟用。
- 建立「角色切換 prompt 模板」（放在
docs/prompt-templates/）：- 每個角色一個
.md，開頭固定寫「你現在是 [Role]，嚴格遵守 roles.md 中的 DoD…」 - 加上「上一個 handoff 內容」自動貼上。
- 每個角色一個
- 強制使用 issue #4 的 workflow：
- 每張新 Issue 都用
ai-task.mdtemplate。 - 每次 handoff 都必須用
docs/handoffs.md格式。
- 每張新 Issue 都用
2. 中期（1-2 個月，走向半自動）
- 引入輕量 orchestrator：
- 用 Claude Projects 或 Cursor 的 Composer 模式當「臨時 PM」。
- 或者直接上 CrewAI + GitHub integration（我看過有人用 CrewAI + GitHub Actions 實現自動 PR review）。
- 加入「Meta Role」：一個「Orchestrator Agent」，專門負責「決定下一個該誰上場」和「handoff 審核」。
3. 長期（朝 C compiler 目標）
- 把整個
docs/變成「AI 團隊作業系統」。 - 目標：讓外部開發者 clone 你的 repo 後，輸入「幫我用這個團隊開發一個 X 功能」，整個流程自動跑。
- 額外建議加兩個角色（等你準備好再加）：
- Security Auditor（針對 compiler 這種高風險專案）。
- Performance Engineer（優化關鍵路徑）。
按照建議, 和 Perplexity Pro + ChatGPT 4.2 + Thinking 再討論做了一版後,
和 Grok AI 解釋,
- 原本 Owner 角色其實是我 (人) , 為了讓專案發展流程完整而有這名稱, 並非真的 AI ;
- Artist 是可能會開發遊戲, 美學上的建議 / UI / UX 是不可欠缺的一環, 也先保留
Grok AI 的回覆如下：
=== Grok AI Start ===
是的，這版 roles.md 已經非常成熟且正確！
我剛剛對照了 2026 年最新的 multi-agent 最佳實務（CrewAI、LangGraph、AutoGen 的實戰案例，以及企業級 agent 指南），你的設計在「單一 AI 模擬團隊 → 未來真 agents 自主溝通」的過渡階段，幾乎是 textbook level 的完美落地。
為什麼這版設計合理且正確？
人類 Owner 的定位極為關鍵
明確把 Owner 定義為「人類最終決策者」，這是目前所有 production-grade AI 團隊的共識（2026 年的報告都強調 human-in-the-loop 仍是核心 guardrail）。它解決了「AI 自己當老闆」的風險，也讓你能隨時介入 scope/priority/AC 的拍板。角色數量與合併完美平衡
- 從原本的 10 個 → 現在的 8 個（含 Owner），browser 切換時的 cognitive
load 大幅降低。
- Architect 兼
Reviewer：這在小團隊/早期階段是標準做法（LangGraph 的很多
production 團隊就是這樣），避免多餘的角色切換。
- QE（Quality Engineer）：把自動化 +
探索式測試合併，符合 2026 年 QA 演進方向（從「寫測試」轉向「品質策略 +
風險控管」）。
- Artist 保留但「按需求啟用」：非常務實，尤其你未來要做遊戲相關，UI/UX 資產是硬需求。
- 從原本的 10 個 → 現在的 8 個（含 Owner），browser 切換時的 cognitive
load 大幅降低。
共通規範 + DoD + 文件導向
這是整個設計的靈魂：- Work Request / Review Notes / Handoff 的標準格式 → 直接對應 issue #4
的「repo-native handoff」目標。
- 所有輸出都強制「可驗證」+「跨平台註記」→ 完美適配 Kotlin
Multiplatform 的特性。
- 這比很多開源框架的 default role 還要嚴謹，未來直接複製到 CrewAI 的
Agent(role=...)裡，幾乎零修改。
- Work Request / Review Notes / Handoff 的標準格式 → 直接對應 issue #4
的「repo-native handoff」目標。
與 2026 年最佳實務高度一致
- Role-based + Narrow Scope：每個角色 mission
都極窄（CrewAI 最推的做法）。
- Output Standardization：強制格式 → 減少
hallucination（所有指南都強調這點）。
- Traceability：ADR + docs/ 資料夾 →
讓「聊天紀錄」完全可拋棄。
- Extensibility：現在 browser 用，未來直接變成 LangGraph 的 state machine 或 CrewAI 的 Crew。
- Role-based + Narrow Scope：每個角色 mission
都極窄（CrewAI 最推的做法）。
更新 SWOT（基於這版）
| 面向 | 內容 |
|---|---|
| Strengths | - 極致清晰：Mission/Inputs/Outputs/DoD 一目了然，AI
切角色時幾乎不會搞混。 - 人類主導 + 文件驅動：既安全又未來相容。 - 專案特定：跨平台、KMP 相關的提醒到處都是，超接地氣。 - 可直接轉 multi-agent：roles.md 就是最好的 CrewAI / LangGraph 藍圖。 |
| Weaknesses | - Architect 可能過載：兼 Reviewer 時，如果 PR
很多，單一 prompt 會變很長。 - PM 角色還需人類輔助：目前 PM 負責拆 issue/追蹤，在 browser 階段還是要你提醒「現在切 PM 來排」。 |
| Opportunities | - 成為 open-source 模板：這個 roles.md
本身就值得獨立 repo（很多人在找「AI 團隊 SOP」）。 - 快速驗證：CurrencyViewer 規模小，跑 2-3 個完整 issue 就能看到效果。 - 朝 C compiler 演進：這套系統正好能支撐 compiler 那種高複雜度專案。 |
| Threats | - Prompt 長度膨脹：handoff 檔案累積後，context 會吃
token。 - 模型漂移：如果切換不同 model（Claude → o1），風格差異可能導致 handoff 不順。 |
小建議（立即可執行）
1. 微調建議（非必要，但推薦）
- Architect 角色：在 Responsibilities 裡加一句
> 「當收到 Review Request 時，自動切換成 Reviewer 模式，使用 Review Notes 格式回應。」 - PM 角色：加一個 「Orchestrator 輔助模式」 的註記（未來可獨立成 Meta Role）： > 「當人類 Owner 指示時，可暫時擔任 Orchestrator，決定下一個 handoff 對象。」
- Artist：DoD 最後加一句「若無明確需求，優先產出資產而非程式碼」，避免 AI 亂寫 Compose。
2. 立即行動清單（這週就能開始）
建立 prompt templates（放在
docs/prompt-templates/）
我可以幫你寫 8 個角色的 system prompt 模板（每一個都包含「你現在是 [Role]，嚴格遵守 roles.md」+ 共通規範）。
需要我現在就產出嗎？（例如先給 Architect + QE 的範例）挑一個 P0 issue 做端到端測試
用 issue #4 當範例：- Owner（你） → 發 Work Request
- PM → 拆子 issue
- Architect → 寫 ADR
- Coder → 實作
- QE → 驗證
跑完後把所有 handoff 貼到docs/handoffs/，就會很有成就感。
- Owner（你） → 發 Work Request
browser 切換技巧
在 Claude / Cursor / ChatGPT 的新聊天裡，用固定開頭：
[角色切換] 你現在是 Project Manager。請先閱讀 docs/roles.md 中的 PM 部分，然後處理以下 handoff：...這樣 context 乾淨。
這版 roles.md 已經可以當作「AI 軟體團隊 SOP v1.0」了。
你現在的架構，不只適合 CurrencyViewer，未來直接套到 C compiler
專案也完全沒問題。
需要我： - 幫寫完整的 8 個 prompt templates？ - 幫 review 下一個
issue 的 Work Request 格式？ - 還是直接幫你產生
docs/communication.md 的範例？
隨時說，我在這裡繼續推你往前衝！🚀
=== end ===
留言
張貼留言