AI 導入之後：傳統開發團隊的角色鬆動與開發新節奏

會議重點

• AI讓每位模組 owner 能從需求解析、設計到開發與驗證一條龍推進，但跨域工作仍需以既有 domain 與可理解的學習範圍為基礎。
• 非開發背景成員的關鍵不是直接接受 AI 產出，而是以小步拆解、提問與回顧，理解任務完成所需的脈絡。
• AI開發的治理重點在於前饋規範與後饋檢查並行：以共同 context 降低模組差異，並以確定性的測試與架構工具補足 AI 的不確定性。
• 需求確認應左移。利用 AI 快速產出逼真草稿，在投入完整規格與開發前先讓使用者確認方向，可降低需求錯誤的返工成本。
• AI是加速器也是放大器：熟悉 domain 時可將能力推向更高品質；跨入陌生領域時，較接近提供平均解的賦能工具。

AI agentClaude CodeClaude TeamsGitHub ProjectDiscordHarnessClean ArchitectureCQRSArchUnitSpring ModulithBDDGherkin Language

團隊配置與角色重組

專案團隊由六位真人與一位 AI 隊友組成，包括一位具十年經驗的小組長、兩位具一年經驗的後端工程師，以及原本沒有開發經驗的 BA、PA、UX 成員。此為真正上線的金融專案，因 domain 相對容易理解、功能開發需求較高，團隊在初期拆成五個模組，由組長以外的五位成員各自認領並完成開發。

傳統 SDLC 偏向瀑布式串接：BA先分析需求，後續角色等待交接。導入 AI 後，每位模組 owner 都必須具備從需求解析、設計、開發到後續流程的端到端能力；角色邊界雖然鬆動，但任務分派仍應優先靠近成員原有的專業與 domain。

非開發背景成員：從代做走向可理解的協作

非開發背景成員的風險在於，雖能請 AI 完成工作，卻不清楚中間做了什麼，後續也難以維運。團隊以小步增量、快速迭代降低學習壓力：將任務拆到成員足以理解的粒度，要求其釐清每一步的目的，並在 AI 說不清楚時向具開發背景的同事請教。

• 理解標準不是學完整套技術，而是理解完成當前任務所必要的部分；例如只需掌握當下 GIT 操作的意義。
• UX 成員可逐步承擔較接近自身 domain 的前端 code，並以「先形成想法、請 AI 執行、回顧驗證結果」取代純粹的 vibe coding。
• 另一種學習方式是先請 AI 從 A 到 B 完成工作，再回頭要求 AI 拆解其處理步驟。

開發治理：共同規範與確定性檢查

具開發背景的成員面對的問題則是發散：即使都使用 AI，各模組仍可能選擇不同框架、架構與 code 風格。團隊在五個模組外建立 Metadata workspace，集中放置共用規範，並以 CLAUDE.local.md 提供一致 context，使各模組的 AI 從相同規則進入開發。

治理採前饋加後饋。前饋是在開發前提供 Clean Architecture、CQRS 等規範，提升 AI 一開始做對的機率；後饋則使用 ArchUnit、Spring Modulith 等工具檢查架構與邊界，並由 AI 隊友依明確標準審查 PR、留下具體意見。

規則不是一次訂完，而是邊做邊補。錯誤與經驗會回寫為規範，逐漸形成 AI 的開發慣性；但規則、文件或既有 code 若本身不一致，也會將 AI 帶偏，因此必須持續檢視與校正。

新開發節奏：人機分工與需求驗證左移

需求解析目前由團隊與 AI 共同討論、拆解後分配至各模組；設計約以 AI 參考既有規範產生規格為主；開發則主要由 AI 執行。測試方面，單元測試用於保護必要邏輯，使用者測試案例仍由人設計與最終確認。若驗證發現錯誤，團隊會將經驗回寫至 Claude 的規範，降低下次重複犯錯的機率。

講者指出，錯誤越晚發現，成本越高，尤其需求方向錯誤時，後續仍會經歷規格、開發與測試等投入。因此應將使用者確認前移，以 OpenDesign、vibe coding POC 等 AI 草稿快速呈現需求輪廓。草稿不必一開始就完整，而應保留調整空間，如同組裝家具時先不要把螺絲鎖死。

需求與規格可適度脫鉤：以相對穩定的原始需求為核心，再透過 BDD 與 Gherkin Language 銜接功能性需求和規格。文件也應聚焦 code 或資料庫無法反推的設計脈絡與取捨，避免文件與 code 不一致，進而干擾 AI 判斷並拖慢迭代。

第七位隊友與專業放大效果

第七位 AI 隊友在團隊中屬實驗性做法，具備 PM 權限，可查看 issue 並每日回報進度、提醒 Sprint 結案與回顧、協助提醒未回覆事項，也可錄製站會並整理重大結論。AI 隊友僅提供建議與回饋，不直接修改 code，仍由人進行設定與操作。

團隊的經驗是：在不熟悉的領域使用 AI，通常只能得到約 60 分的平均解；在熟悉的 domain 中使用，專業知識能幫助人辨別高低價值工作，將低價值的重複產出交給 AI，把心力放在軟體架構與需求連結等高價值判斷，達到更接近 80 分的加成效果。

討論摘錄

「AI現在演進很快，但是我們團隊變最多其實不是這個速度，是我們的角色以及我們的節奏。」
— 陳仁傑

「AI其實只是幫他把他心裡的想法做出來，再驗證；想法是要在他自己腦袋裡面先形成的。」
— 陳仁傑

問答中，與會者關注 PM 與 RD 界線被打破後，是否犧牲了原有專長。陳仁傑回應，目的不是讓所有人取代彼此，而是理解 AI 能賦能到什麼程度及其代價；原本最熟悉 domain 的角色，例如 BA，仍可更早使用 AI 主導需求工作，其他成員則在需求帶回後共同討論，而非等待工作流到自身階段才開始。