在現代軟體工程團隊中，資深工程師的時間是最寶貴的資產。然而，在日常開發中，資深工程師經常被兩大痛點分散注意力：

無止盡的 PR Review： 花費大量精力抓出語法風格錯誤、缺乏單元測試、或是明顯的安全漏洞（如 SQL Injection 風險）。

資訊不同步： 開發者開了 PR，但 Jira 上的任務狀態依然停留在「In Progress」，未即時流轉到「Code Review」，甚至 PR 合併後忘記關閉工單。

為了徹底解決這個研發流程的阻礙，我們在最後的 Capstone 階段將打造一個企業級的 AI 自動化審查與工單同步代理人系統。

1. 系統資料流架構設計 (Event-Driven Architecture)
這個系統採用事件驅動架構，完美展示「大腦」與「神經系統」的解耦分工：

[Developer]
    │ (1) git push / Open PR
    ▼
[GitHub Webhook]
    │ (2) Event Payload (via ngrok)
    ▼
[n8n 流程總線] ──(3) 提取 Diff & 格式化──▶ [Dify Code Review Workflow]
    │                                              │ (含團隊規範 RAG)
    │ ◀──(4) 取得結構化 JSON 審查報告與評分─────────┘
    ├─────────────────────────────┬─────────────────────────────┐
    ▼                             ▼                             ▼
[GitHub REST API]           [Jira REST API]           [Langfuse 監控平台]
回寫 PR 行內評論與總結        更新 Issue 狀態至 In Review    記錄 Token 消耗與審查 Trace

2. 各模組職責拆解

• GitHub (事件來源與回顯終點)： 負責發出 PR 建立或更新的 Webhook，並接收 AI 生成的審查建議與 Check Run 狀態回傳。

• n8n (自動化排程與總線)： 負責接收 GitHub Webhook，驗證簽名金鑰以確保資安，協調各服務間的資料流向，並處理 HTTP 逾時與錯誤重試。

• Dify (程式碼分析大腦)： 負責執行程式碼審查。透過掛載專案的「團隊代碼規範知識庫 (RAG)」，結合多模態/程式碼分析模型，對變更的代碼進行安全性、效能與架構評估，並嚴格輸出標準 JSON。

• Jira (專案管理系統)： 透過 REST API 接收來自 n8n 的指令，動態更新工單狀態、指派負責人，並將 AI 審查摘要同步至工單 Comment。

• Langfuse (觀測性後台)： 即時追蹤每一次 PR 審查的 Latency、Token 成本，並分析審查結果的品質指標。

3. 系統核心設計原則

• 非同步解耦： GitHub Webhook 必須在 10 秒內收到回應，否則會判定逾時。因此 n8n 接收到請求後，會立即回傳 200 OK，接著在背景非同步執行耗時的 AI 審查與 API 呼叫。

• 嚴格的資料邊界： 敏感的金鑰（GitHub Token、Jira API Token）全數隔離在 n8n 憑證模組中，絕不裸露給 LLM，恪守企業級系統的資安防護要求。

架構藍圖已經繪製完成。明天 [Day 26]，我們將進入實作的第一步：如何從龐大的 Git Diff 中精準擷取關鍵代碼，並優化 Token 消耗以符合模型輸入限制。