Vincent5588 Wiki

AI 編程角色責任矩陣

閱讀時間約 5 分鐘

AI 編程角色責任矩陣

Vibe Coding 團隊規範 把 AI 編程責任明確分配到 5 個角色。每個 PR 都應該能對應到這 5 個角色的職責落實。

5 個角色

角色責任
Author扮演 Claude 的 PM；提供完整 context；自我驗證；如實標示 AI 產出範圍
Reviewer檢查流程是否落實；core code 逐行 review；leaf node 抽查
Module Owner守護核心架構；對觸及自己模組的 AI PR 有否決權
Tech Lead監督規範落實；定期 audit AI PR 品質；每季重檢 leaf / core 分類；決定模型升級時的政策調整
每位成員持續提升「向 AI 提問與驗證」的能力——這是未來的核心競爭力

各角色 deep dive

Author（PR 作者）

「像 PM 對 Claude」：

✅ 必做：

❌ 禁做：

  • 一句 prompt 直接 commit
  • 假裝 AI 沒參與
  • 只跑 happy path 就提 PR

Reviewer

「像 manager 檢查 PM 的工作」：

你不是在檢查 AI 的工作，你是在檢查送 PR 的人有沒有做好 PM 的工作。

Review 重點順序（依 Code Review 準則 (AI 編程)）：

  1. PR 描述完整性
  2. 計畫與實作一致性
  3. Leaf / Core 分類正確性
  4. 介面與測試清楚度
  5. Core code 逐行檢視
  6. Leaf node 抽查 + 看測試與邊界

Module Owner

「最後守門員」：

擁有對「觸及自己模組的 AI PR」的否決權。即使 reviewer 已 approve，owner 仍可退回。

  • 譬如：auth module owner 對任何動 auth 的 PR 有否決權
  • 否決理由不需 100% 量化（owner 經驗判斷算數）
  • 否決後 author 必須改 design / 拆 PR / 改成人類主導

Tech Lead

「規範長期演進的看守人」：

週期責任
每週 / 每月Audit AI PR 品質、找 anti-pattern 案例
每季重檢 leaf / core 分類清單（Leaf Node vs Core Code 的動態邊界）
模型升級時評估是否該調整政策（譬如新模型穩定性提升，可放寬哪些 core）
事故 retro每次 retro 加一題：「這次事故跟 AI 產出有沒有關係？」

每位成員

「長期能力建設」：

持續提升「向 AI 提問與驗證」的能力——這是未來的核心競爭力。

這條看似抽象但 Vibe Coding 團隊規範 §「結語」強調：

短期可能交件，長期會失去判斷 AI 對錯的能力。

→ 每位成員都該有「Vibe coding 能力成長軌跡」（不只是程式 skill，是 AI 協作 skill）。

跟 SDLC 各階段的對應

SDLC 階段AuthorReviewerModule OwnerTech Lead
需求 / 設計✅ 主導—諮詢諮詢
計畫產出 (Plan-then-Execute Step 1-3)✅ 主導—諮詢—
AI 執行 (Step 4)✅ 主導———
自我驗證 (Step 5)✅ 主導———
Code Review (Step 7)—✅ 主導✅ 否決權抽查
部署 / 維運諮詢—✅ 監督✅ 監督
政策演進——諮詢✅ 主導

落地建議

工具角色用途
GitHub CODEOWNERS自動指派 Module Owner 為 reviewer
Branch protectionForce 2 reviewers for core paths（核心由人嚴格 Review 法則）
AI PR audit dashboardTech Lead 每月 review
季度規範 retroTech Lead 主持，所有人參加
Onboarding 教材把這份矩陣寫進新人 onboarding

違反時的常見症狀

  • ❌ 「Module Owner 沒被指派 reviewer」→ 失守門員
  • ❌ 「Tech Lead 從沒 audit」→ 規範失效
  • ❌ 「Author 不填 PR 模板」→ Reviewer 無從 cross-check
  • ❌ 「Reviewer 只看 leaf 沒看 core」→ 層級錯配
  • ❌ 「事故 retro 從不問 AI 因素」→ 看不出趨勢

相關

關係圖譜

反向連結