AI Code Review 步驟拆解與工具選型考量

前言

昨天我們分析了 Code Review 的痛點，今天要來拆解具體的解決步驟。
做任何技術專案前，我習慣先進行步驟拆解和工具(技術)選型，
跟團隊有共識，這樣能確保後續的實作方向正確，
也避免中途發現選錯工具而重來。

步驟拆解

取得 Merge Request 的 Diff  → AI 分析並產生回饋 → (可選)將回饋寫入留言區

步驟 1: 取得 Merge Request 的 Diff

• 方式: 用 IDE 的 diff 複製貼上 / 串接 API / 使用 MCP
• 解析程式碼變更內容

步驟 2: 讓 AI 分析並給出回饋

• 設計適當的 Prompt 範本
• 將 Diff 內容傳送給 AI 模型

步驟 3: (可選)將回饋寫入留言區

• 自動發布到 GitLab/GitHub 的 MR 討論區

工具選型

技術選型不只看技術本身，更要考慮使用情境和資源限制。

1. IDE 選擇：為什麼是 VSCode？

• 團隊調查結果: 70% 使用 VSCode，20% 使用 Cursor，10% 使用 JetBrains 系列
• 結論：VSCode 涵蓋最多使用者，適合作為範例

2. AI 工具選擇：為什麼是 Copilot？

• 實務考量: 公司已有 GitHub Copilot 的預算補助
• 成本效益分析
  • GitHub Copilot: $10/月，公司補助
  • ChatGPT Plus: $20/月，個人負擔
  • Claude Pro: $20/月，個人負擔
• 結論：既然有補助，當然選擇 Copilot

3. MCP 選擇：為什麼現在導入？

• 技術趨勢觀察
  • 2024年11月 Anthropic 推出 MCP 協議
  • 參加研討會發現 MCP 生態快速發展
  • GitHub、Figma、天氣等各種 MCP 工具湧現
• 實際應用場景
  • 剛好換到新團隊，有機會嘗試新技術
  • MCP 讓 AI 工具整合變得標準化
  • 符合「取得外部資料 + AI 分析」的使用模式

成本與資源考量

個人實務原則

身為一個「免費仔」，我傾向優先選擇：

1. 開源工具
2. 公司有預算補助的服務
3. 有豐富社群資源的技術

這次的選擇符合原則

• VS Code: 人數較多
• GitHub Copilot: 公司補助
• MCP: 開源協議
• GitLab: 公司既有服務

小結

雖然這次的工具選型沒有像架構架構那麼複雜，但透過系統性的分析，我們能夠：

• 清楚了解要解決的問題步驟
• 基於實際使用情境選擇工具
• 考慮成本與資源限制
• 規劃可行的實作路線

明天我們將深入介紹 MCP (Model Context Protocol) 的技術細節，了解它如何讓 AI 工具整合變得更簡單！