昨天我們確立了 Capstone Project 的事件驅動架構。今天，我們正式進入實作的第一道關卡：攔截 GitHub PR 事件，並為 AI 準備乾淨的審查資料。

在開發 AI 應用時，工程師最常犯的錯誤就是「把拿到手的資料原封不動地全塞給大模型」。以 GitHub 的 Pull Request 為例，如果你直接把整個 PR 的變更內容餵給 AI，系統絕對會迎來災難。

1. 剖析痛點：為什麼不能直接把 Git Diff 餵給 AI？
一個真實專案的 PR 變更中，往往充斥著大量的「非業務邏輯」雜訊：

自動生成的檔案： 像是前端的 package-lock.json 或 Java 的 mvnw，這些檔案動輒上萬行，瞬間就會撐爆 LLM 的 Context Window（上下文限制），並消耗極度昂貴的 Token 費用。

二進位與靜態資源： .svg, .png 或編譯後的 .class 檔案變更，對純文本的程式碼審查毫無意義。

失焦的幻覺 (Hallucination)： 當雜訊過多時，AI 的注意力機制 (Attention Mechanism) 會被干擾，導致它花費大量篇幅在評論 pom.xml 的版本號，卻漏看了核心 Controller 裡的 SQL Injection 漏洞。

2. 在 n8n 中建立清洗管線 (Cleaning Pipeline)
為了解決這個問題，我們在 n8n 中建立的工作流不能只是單純的轉發器，而必須是嚴格的「海關」。

節點一：GitHub Webhook 監聽器
設定 n8n 的 Webhook 節點，監聽 GitHub Repository 的 pull_request 事件。我們設定只在 PR 狀態為 opened 或 synchronize (推上新 commit) 時觸發流程。

節點二：抓取純文字 Diff
Webhook Payload 預設只包含 PR 的 Metadata（標題、作者）。我們需要透過 n8n 的 HTTP Request 節點，帶上 GitHub Token 呼叫 API，並在 Header 設定 Accept: application/vnd.github.v3.diff，藉此取得該 PR 原始的 Git Diff 字串。

節點三：Regex 雜訊過濾 (核心濾網)
我們在 n8n 中加入一個 Code 節點（允許撰寫少量的 JavaScript），利用正規表達式 (Regular Expression) 來剔除無用資訊。例如：

JavaScript
// 範例邏輯：過濾掉 lock 檔與圖片的 Diff 區塊
let rawDiff = $input.item.json.raw_diff;
let cleanDiff = rawDiff.split('diff --git')
    .filter(chunk => !chunk.match(/\.(svg|png|lock|min\.js)$/i))
    .join('diff --git');
return { json: { cleanDiff: cleanDiff } };

透過這段輕量的腳本，我們可能將原本 50,000 Tokens 的垃圾資料，瞬間壓縮成只剩 3,000 Tokens 的核心業務代碼。

3. Context 注入：為 Dify 準備標準化 Payload
清洗完畢後，我們要把這些珍貴的程式碼送往 Dify。回呼我們在 Day 3 學到的「防呆機制」，我們在 n8n 的最後一個 HTTP 節點中，將清理過的 Diff 用 XML 標籤嚴格包裹起來，組裝成 JSON Payload：

JSON
{
  "inputs": {
    "pr_title": "{{ $json.title }}",
    "pr_diff": "<diff>\n{{ $json.cleanDiff }}\n</diff>"
  }
}

資料前處理是 AI 工程中最枯燥，卻也最決定成敗的環節。現在，我們已經成功把極度純淨、經過 Token 最佳化的程式碼變更準備好了。

明天 [Day 27]，我們將進入 Dify，撰寫決定系統靈魂的 多維度 Code Review Prompt，並探討如何強制 AI 輸出能與 Jira 完美連動的 JSON 審查報告！