昨天我們在 Dify 的大腦中注入了嚴格的審查靈魂，並成功強制 AI 產出了一包極度標準化的 JSON 審查報告（包含 status, summary 以及 issues 陣列）。

然而，如果這包完美的 JSON 只是躺在資料庫裡，對開發團隊來說毫無價值。真正能解放生產力的 AI 系統，必須具備「雙向連動」的能力。今天，我們將回到 n8n 的自動化總線，把這包 JSON 化為真實的操作，讓 AI 代理人正式成為團隊裡的「虛擬資深工程師」與「虛擬專案經理」。

1. 虛擬資深工程師：回寫 GitHub PR 狀態與行內評論
我們在 n8n 中接續昨天 Dify 回傳的結果，接下來要使用 n8n 的 GitHub 節點（或 HTTP Request 節點呼叫 GitHub REST API）來進行回寫。

這個步驟的核心，是將 Dify 產出的 JSON 動態對應到 GitHub 的 Review API 規格：

PR 總結 (Review Body)： 將 JSON 中的 summary 填入 PR 審查的主留言區，讓作者一眼看出這次提交的整體品質。

審查決策 (Review Event)： 如果 JSON 中的 status 是 APPROVE，就發送批准指令；如果是 REQUEST_CHANGES，就亮起紅燈，阻擋這支 PR 被合併。

精準狙擊 (Line Comments)： 這是最驚豔的一步。我們透過 n8n 的 Item Lists 節點或是撰寫簡單的迴圈，把 JSON 中 issues 陣列裡的每一個 Bug，轉化為 GitHub 的「行內評論」。AI 不再只是泛泛而談，而是直接在有 SQL Injection 風險的「第 42 行」留下精確的修復建議 (suggestion)。

當開發者推上程式碼的 1 分鐘後，立刻看到 GitHub 上出現針對特定行數的精準 Code Review，這種開發體驗是極度震撼的。

2. 虛擬專案經理：Jira 工單狀態流轉與同步
   完成 GitHub 的回寫後，我們不能忘記專案管理的痛點：工程師常常忘了更新 Jira 狀態。
   現在，我們讓 AI 幫忙做這件事。在 n8n 畫布的下一站，我們牽一條線連接到 Jira Software 節點：

• 萃取工單編號： 利用 Regex（正規表達式）從 Webhook 傳來的 PR 標題或分支名稱中，自動萃取出 Jira Issue Key（例如 PROJ-123）。

• 狀態流轉 (Transition)： 發送指令給 Jira API，將該張工單的狀態從「In Progress (開發中)」自動拖曳至「Code Review (代碼審查)」。

• 資訊同步 (Add Comment)： 將 AI 產出的 summary，同步寫入該張 Jira 工單的留言板。

從此之後，PM 只需要看 Jira，就能立刻知道「PROJ-123 已經開發完成，目前 AI 初審給了 Request Changes，因為有潛在的效能問題」。研發端 (GitHub) 與管理端 (Jira) 的資訊壁壘，被 AI 徹底打通。

至此，我們的 Capstone Project 已經完成了 90% 的「理想狀態 (Happy Path)」。這套系統一旦上線，將為團隊省下無數個小時的溝通與審查成本。

但資深工程師的直覺告訴我們：如果 AI 幻覺發作，回傳了不存在的程式碼行號導致 GitHub API 報錯怎麼辦？如果我們想量化這隻 AI 審查官的準確率呢？

明天 [Day 29]，我們將迎接這個系統上線前 (Production-ready) 的最後一次加固：導入 Langfuse 追蹤與錯誤重試機制，打造堅不可摧的企業級管線！