昨天我們在 n8n 中完成了資料清洗，成功把去蕪存菁的 pr_diff 送往了 Dify。今天，我們要在 Dify 的大腦裡，植入一套專業且嚴謹的程式碼審查邏輯。

許多初學者在寫 Code Review 的 Prompt 時，通常只會寫一句：「請幫我 review 以下的程式碼」。這種粗糙的指令，往往會換來 AI 一堆無關緊要的碎碎念，例如「這裡可以加個註解」、「變數名稱可以再短一點」，對於抓出真正的系統級 Bug 毫無幫助。

為了打造企業級的審查代理人，我們必須採用 多維度 (Multi-dimensional) 審查策略，並搭配 強制 JSON 輸出。

1. 拆解多維度審查 Prompt (System Prompt)
在 Dify 建立一個「工作流 (Workflow)」或是單次執行的「文本生成」應用。在最核心的 LLM 節點中，我們將 System Prompt 拆解成四個專業維度，確保 AI 帶著放大鏡檢視每一行變更：

角色設定：
你是一位極度嚴謹的首席軟體架構師。你的任務是審查夾在 標籤內的 Git Diff。

審查維度 (請嚴格依序檢驗)：

安全性 (Security)： 是否有 SQL Injection、XSS 漏洞、或是將 API 金鑰/密碼硬編碼 (Hardcode) 在程式中？

效能與資源 (Performance)： 是否有 N+1 Query 問題？是否有在迴圈內頻繁開啟資料庫連線或執行高耗時的 I/O？

例外處理 (Error Handling)： 是否有捕捉異常並給予合理的 Fallback？有沒有吞掉 (Swallow) 重要的 Exception Log？

邊界條件 (Edge Cases)： 傳入的參數是否可能為 Null？陣列操作是否會超出索引界線 (Index Out of Bounds)？

2. RAG 知識庫掛載：導入團隊規範 (Optional 但強烈推薦)
如果你的團隊有一份「Java 開發規範」或是「資安紅皮書」，這時就可以利用 Day 12 學到的知識，將這份文件作為 Dify 的 知識庫 (Knowledge Base) 匯入。
在 Prompt 中加入：「請優先遵循上文提供的團隊開發規範進行審查。若代碼違反規範，請特別標註。」
這樣 AI 的審查就不只是基於通用常識，而是真正符合你們公司標準的客製化糾察隊。

3. 為了 API 串接而生的強制結構化輸出
最重要的一步，是我們必須要求 LLM 給出 n8n 與 Jira 都看得懂的格式。如果在過去，我們要用 Prompt 費力地「威脅」AI 只能輸出 JSON。但在現代的 Dify 介面中，我們可以直接使用底層 API 支援的強大功能：JSON Mode (或 Structured Output)。

我們在 Dify 的 LLM 節點設定中，將輸出格式強制定義為以下結構：

JSON
{
  "summary": "一句話總結這次 PR 的品質與主要風險",
  "status": "APPROVE | REQUEST_CHANGES | COMMENT",
  "issues": [
    {
      "severity": "HIGH | MEDIUM | LOW",
      "file": "發生問題的檔案名稱",
      "line": "大概的行號 (可選)",
      "description": "具體的問題描述",
      "suggestion": "修復建議的程式碼片段"
    }
  ]
}

這個 JSON 結構堪稱完美。status 欄位將直接決定稍後 GitHub PR 要不要亮綠燈；而 issues 陣列，則能讓我們把每一個具體的 Bug，精準回寫到 PR 的特定行數 (Line Comment)，甚至同步去建立 Jira 的子任務。

今天我們在 Dify 內部完成了大腦的調教，確保了輸入純淨、審查嚴格、輸出結構化。

AI 已經給出了它心中的判決。明天 [Day 28]，我們將把 Dify 回傳的這包 JSON，接回 n8n 的自動化總線，實作這個系統最酷炫的環節：自動化回寫 GitHub PR 評論與 Jira 工單狀態的雙向流轉！