AI 賦能下的系統演化：一人抵一軍的跨專案協作之道

Dec 02, 2025

前言：從工具到系統的演化陣痛

在軟體開發的生命週期中，我們常看到這樣的軌跡：一開始只是一個簡單的「工具」（Tool），為了解決特定的小問題；隨著需求增加，它長成了一個「單體應用」（Monolith）；最後，為了擴展性與解耦，它不得不拆分為「多個服務」（Multi-Service）甚至微服務架構。

在 「前 AI 時代」，這個演化過程往往伴隨著巨大的組織成本：

溝通成本爆炸：當專案從一個 Repo 變成三個 Repo（前端、後端、共用庫），你需要協調的人力可能從 1 人變成 3 人，甚至 3 個團隊。
角色分工的代價：為了同步規格（Spec）與進度，我們引入了 PO（產品負責人）、PM（專案經理）。他們花費大量的時間在開票（Jira）、寫文件（Confluence）、喬時程、喬資源。
上下文切換（Context Switch）：工程師在不同專案間切換，腦袋需要重新暖機，效率大打折扣。

這就是為什麼以前「把系統拆分」是一個需要深思熟慮的決定，因為拆分意味著協作難度的指數級上升。

現在，我們有了 AI（如 Gemini, Claude Code, GitHub Copilot 等 Agentic AI）。這不僅僅是寫程式變快了，而是協作的維度被改變了。

AI 讓「一個人維護多個服務」變得不再是天方夜譚。AI 不會因為切換 Repo 而感到疲憊，它能同時理解前端的 React 程式碼與後端的 Python 邏輯——只要你給它足夠的上下文（Context）。

然而，這也帶來了新的挑戰：我們該如何設計工作流程，才能駕馭這支 AI 大軍？ 如果我們還用舊的方法（口頭溝通、散落在各處的文檔），AI 也會迷失方向。

謎之音：其實控制 AI 的我迷失方向，會不知道該怎麼控制和管理…XD

有了這個苦，我最近就是在摸索，如何在多個單體服務逐步成形的過程中，產生一套新的「協作作業系統」。以下是幾個關鍵的思維轉變：

傳統上，我們將不同服務放在不同的 Git Repo 中，這導致了物理上的隔離。但在 AI 協作中，我們應該在 IDE 層面建立一個 「上帝視角」。

作法：將所有相關的 Git Repos（後端、前端、文件）放在同一個 Workspace 下。
優勢：AI Agent 可以跨越 Repo 的邊界。當你要求「新增一個 User 欄位」時，AI 可以同時去後端修改 Model，去前端修改 Component，並更新 API 文件。它打破了「前端工程師」與「後端工程師」的界線。當然你也可以用一個超級大 Mono Repo 但是管理起來會更複雜，尤其是你怕 AI 去亂改 ~ :P

以前文件是寫給人看的，過期了也沒關係，反正人會去問人。但在 AI 時代，文件是寫給 AI 看的 Prompt。

單一真理來源 (SSOT)：建立一個獨立的 Repo（如 coach-product-specs），專門存放業務邏輯、資料模型與流程圖，然後下游再個別用 SDD 產生更 detail 的文件，再由上游視角來驗證文件的內容是否自洽。
嚴格執行：AI 必須被指示「先讀 Spec，再寫 Code」。如果 Spec 沒寫，AI 不應該擅自發揮。這取代了傳統 PM 的「需求確認」會議。
BDR/PSR 機制：用輕量級的 Markdown 記錄決策（BDR）與狀態（PSR），取代冗長的會議記錄與 Jira 看板。AI 可以自動讀取這些狀態，知道現在進度到哪裡。

在舊時代，PO/PM 是上下文的載體，他們負責在不同團隊間傳話。現在，AI 是上下文的載體。

雖然很想說我們不再需要好幾個 PO/PM 來「喬事情」，因為程式碼與規格的距離被無限縮短了。

但真實是，當沒有那樣的人力和規模下，我們能怎樣讀自運做和升級，這也不代表我們可以偷懶都交給 AI。相反的，身為人類開發者（或稱之為「系統架構師」），我們的責任變成了：

這是一場新的磨合。我們不再是單純的「寫程式的人」（Coder），我們是 「AI 軍團的指揮官」。我們透過精心設計的檔案結構與文件，指揮 AI 在多個戰場（Repo）上同時作戰，實現以往需要龐大團隊才能完成的系統演化。