AI 團隊於 軟體專案(含Legacy)中的概念與實作
當你的 AI 助手看不懂你的 Legacy Code 時
你有沒有想過，為什麼 AI 可以寫出漂亮的 Hello World，卻搞不定你那個跑了五年的舊專案?
不是 AI 不夠聰明。是因為你的 Legacy 專案裡,藏著十幾個離職工程師的靈魂、三種不同的架構風格、還有一堆「當時為什麼要這樣寫」的謎題。
這就像你請了一個新人,然後丟給他一個沒有文件的專案,說「去修 Bug」。他能做什麼?到處翻程式碼、猜測原始設計者的意圖、小心翼翼地改一點點東西,然後祈禱不要炸掉整個系統。
AI 也一樣。它需要 context。更精確地說,它需要專案特定的 context。
但這裡有個更深層的問題:假設你把所有 context 都給了 AI,它就能自己工作了嗎?不行。因為你還沒告訴它「什麼叫做品質」。
問題的根源:技能需要 Context,品質需要意識
Generic AI Agent 很強大,但它不知道你的專案「正常」長什麼樣。
假設你有一個電商網站的 Legacy 專案: – 訂單系統用 Stored Procedure – 庫存系統用 ORM – 支付系統直接寫 SQL – 三種風格並存,但都能動
Generic Agent 會怎麼做?它可能統一成一種風格——這聽起來很好,但你確定現在要重構整個資料存取層嗎?
第一個決策點:Generic Team vs Dedicated Team
| 類型 | 適用情境 | 優點 | 缺點 |
| Generic Team | 新專案、實驗性任務 | 快速啟動、不需準備 | 不懂專案特性 |
| Dedicated Team | Legacy 專案、產品開發 | 理解專案脈絡 | 需要建置 context |
對於 Legacy 專案,你幾乎必然需要 Dedicated Team——但這代表你要先教會 AI 你的專案。
而更關鍵的是:你還要教會 AI 什麼叫做「好」。
品質意識的三層世界
在傳統開發流程中,品質意識存在三個層次:
第一層:工程師的品質意識
第二層:PM 的品質意識
第三層:客戶的品質意識
三層之間常常衝突。工程師想重構,PM 想趕進度,客戶想省錢。
那麼 AI 呢?AI 的品質意識是什麼?
答案是:沒有。除非你教會它。
如何教 AI 品質意識:Workflow 文件化
假設你的團隊處理 Bug 的標準流程是:
1. 確認 Bug 可重現
2. 寫單元測試 cover 這個 Bug
3. 修改程式碼讓測試通過
4. 確認沒有 regression 5. Code Review 後才能 merge
這些在你腦中是常識,但 AI 不知道。它可能直接改程式碼、跳過測試、甚至製造新的 Bug。
所以你需要把品質意識寫進 Workflow:
## Bug 修復流程
### 前置條件
– 確認 Bug 在 staging 環境可重現
– 確認 Issue Tracker 有完整描述
### 執行步驟
1. 建立 feature branch (格式: bugfix/TICKET-123)
2. 新增測試案例 (失敗狀態)
3. 修改程式碼讓測試通過
4. 執行完整測試套件
5. 本地驗證修復結果
6. 提交 Pull Request 並標註 Reviewer
### 品質標準
– 測試覆蓋率 ≥ 80%
– 沒有 console.log 殘留
– 符合專案 Coding Style
– 沒有引入新的 dependency
### 禁止行為
– 直接改 production database
– 跳過測試
– 硬編碼敏感資訊
這不是寫給人看的文件。寫給 AI 的行為準則。
當你把這些寫清楚,AI 才知道「在這個專案裡,什麼叫做做得好」。
實作流程:從 Legacy Code 到 AI Team
基於 A-Team 專案(reference:參考一個製作團隊的團隊專案: A-Team Framework)的概念,以下是建立 AI 團隊的六步驟實作流程:
1. 盤點 Codebase 並產生 Documents
假設你有一個三年前的 .NET 專案,第一步是讓 AI 理解它:
# 生成專案結構文件
tree src/ > docs/structure.md
# 提取 API 端點清單
grep -r “Route\|HttpGet\|HttpPost” src/ > docs/api-endpoints.md
# 列出資料庫 Schema
# (從 Migration 檔案或實際 DB)
# 整理 README、Wiki、任何現有文件
你需要回答這些問題: – 這個專案的核心功能是什麼?
– 有哪些關鍵的技術決策?(例如為什麼用 Stored Procedure)
– 有哪些已知的坑?(例如某個 API 的 timeout 要設 60 秒)
– 測試策略是什麼?(有整合測試嗎?假資料怎麼處理?)
這些資訊會成為 AI Team 的「專案記憶」。
2. 需求/願景 → Skills + Context = Team
定義需求清單與對應 Skills:
需求清單: – 修 Bug – 重構某個模組 – 加新功能 X
對應 Skills:
skills:
– name: legacy-bug-fixer
description: 修復 Bug 並確保測試覆蓋
context:
– docs/structure.md
– docs/known-issues.md
– workflows/bug-fixing.md
– name: module-refactor
description: 重構特定模組並保持向下相容
context:
– docs/architecture.md
– docs/refactor-guidelines.md
– name: feature-developer
description: 開發新功能並整合到現有系統
context:
– docs/api-design.md
– docs/database-schema.md
每個 Skill 都綁定特定的 context。像你給不同的工程師分配任務,並附上相關文件。
3. 決策:這個專案適合 Generic Team 嗎?
檢查清單:
– [ ] 專案架構是否標準?(例如典型的 MVC)
– [ ] 程式碼風格是否一致?
– [ ] 測試是否完整?
– [ ] 文件是否充足?
– [ ] 部署流程是否自動化?
如果五個問題有三個以上答「否」,你需要 Dedicated Team。
為什麼?
因為 Generic Team 假設「最佳實踐」,但你的 Legacy 專案可能根本不是最佳實踐。它可能是: – 「當年我們人手不足,先求有再求好」 – 「這個 Workaround 是為了繞過某個 bug」 – 「這段程式碼不要動,動了會炸」
這些潛規則,只有 Dedicated Team(帶著專案特定的 context)才能理解。
4. 設計團隊:Generic vs Dedicated 的實際結構
Generic Team 範例 (適合新專案):
Team: web-app-generic
├── Coordinator (project-manager)
├── Backend Developer (generic)
├── Frontend Developer (generic)
└── QA Engineer (generic)
Context: 無(依賴 AI 的預訓練知識)
Dedicated Team 範例 (適合 Legacy 專案):
Team: legacy-ecommerce-team
├── Coordinator (team-lead)
├── Order-System-Specialist
│ └── Context: docs/order-system.md, workflows/order-bug-fix.md
├── Payment-Specialist
│ └── Context: docs/payment-integration.md, docs/pci-compliance.md
└── Inventory-Refactor
└── Context: docs/inventory-schema.md, docs/refactor-plan.md
Context: 專案特定文件 + Workflows
Dedicated Team 的每個角色都有明確的職責範圍和context 邊界。Order-System-Specialist 不會去動 Payment 的程式碼,因為它的 context 裡沒有支付系統的資訊。
這種隔離很重要。它模擬了真實團隊中的「我不熟那塊,還是找負責的人來改」。
5. Workflow 文件化:定義品質標準
把「怎樣算做好」寫下來。
Bug 修復 Workflow:
## 輸入
– Bug Report (Jira Ticket)
– 重現步驟
## 輸出
– Fixed Code + Unit Test + Integration Test (if needed)
– Pull Request with description
## 品質標準
– 測試覆蓋率 ≥ 80%
– 沒有 console.log 或 Debug code
– 沒有引入新的 dependency (除非經過批准)
– Commit message 格式: “fix(module): description”
## 禁止行為
– 直接改 production database
– 跳過測試
– 硬編碼敏感資訊
Refactoring Workflow:
## 輸入
– 目標模組
– 重構目標 (可讀性/效能/架構)
## 輸出
– Refactored Code (保持 API 相容)
– 更新的測試
– 效能比較報告 (如果是效能重構)
## 品質標準
– 所有測試必須通過
– API 向下相容 (或提供 Migration Guide)
– 複雜度降低 (Cyclomatic Complexity < 10)
– 程式碼行數減少 ≥ 20% (如果可能)
## 禁止行為
– 改變公開 API 而不通知
– 刪除測試
– 引入 breaking change
這些 Workflow 會被嵌入到每個 Skill 的定義中。當 AI Agent 執行任務時,它會遵循這些規則。
6. 建立虛擬團隊 Retro 機制
就像真實團隊會開 Retrospective 會議,AI Team 也需要反饋迴圈。
建立 Retro Log:
## Retro: 2026-02-10
### 完成任務
– Fixed Bug #123 (Order calculation)
– Refactored Inventory module
### 遇到的問題
– Bug #123 的測試案例不足,花了額外時間補測試
– Inventory 重構時發現 undocumented dependency on Payment module
### 改善建議
– 更新 workflows/bug-fixing.md: 明確要求「每個 Bug 至少兩個測試案例」
– 更新 docs/inventory-schema.md: 加入與 Payment 的關聯說明
### Context 更新
– 新增 docs/cross-module-dependencies.md
這個 Retro Log 會被加回 context,讓 AI Team 下次遇到類似情況時更聰明。
真正的「學習」機制。
人類角色的轉變:從執行者到管理者
當你建立了 AI Team,你的角色會改變。
過去:你是工程師
現在:你是 Team Lead
但你必須更懂技術。
因為你要能判斷: – AI 產生的程式碼是否符合專案標準? – 這個重構是改善還是製造新問題? – 測試覆蓋是否充分? – 有沒有引入安全風險?
你從「寫程式碼的人」變成「教 AI 怎麼寫好程式碼的人」。
這個轉變不容易。有些人會覺得「我還是自己寫比較快」。也許在短期是這樣,但當你的 AI Team 建立起來、context 完善、workflows 明確之後,它可以處理的事情會越來越多。
而你可以專注在更高層次的問題: – 這個架構該往哪個方向演進? – 這個技術債要不要還? – 下一季的 Roadmap 是什麼?
你的選擇
所以,回到一開始的問題:當你的 AI 助手看不懂你的 Legacy Code 時,你要怎麼辦?
你有三個選擇:
- 短期有效,長期累死
- 硬做 — 可能做出來,但品質堪憂
- 前期投資時間,後期加速開發
如果你選擇第三條路,你會發現:教 AI 理解你的專案,本質上是在強迫自己把隱性知識顯性化。
那些「只有資深工程師知道」的眉角、那些「不知道為什麼但就是要這樣做」的慣例、那些「文件上沒寫但大家都知道」的規則——你必須全部寫下來。
這個過程很痛苦,但也很有價值。
因為最後,你得到的不只是一個 AI Team。你還得到了一份完整的專案文件、一套明確的開發流程、一個可以傳承的知識體系。
即使哪天你決定不用 AI 了,這些東西還是有價值的。
參考一個製作團隊的團隊專案: A-Team Framework
標籤: #AI開發 #LegacyCode #團隊管理 #軟體工程 #技術管理