昨天我們完成了 GitHub 與 Jira 的雙向連動，看著 AI 自動在 PR 程式碼上留言並更新工單，成就感不言而喻。但如果我們要把這個專案放進履歷，去面試頂尖外商或申請海外研究所，面試官絕對不會只看「Happy Path（理想狀態）」。

他們會問一個致命的問題：「大語言模型是非確定性 (Non-deterministic) 的，如果 AI 產生幻覺，回傳了一個不存在的程式碼行號，導致 GitHub API 報錯，你的系統會崩潰嗎？」

真正的軟體工程師，必須假設「任何外部依賴都會出錯」。今天，我們要為這個 Capstone Project 進行生產級 (Production-Ready) 的加固，導入防禦性設計與系統觀測性。

1. n8n 的防禦性設計：優雅的降級機制 (Graceful Degradation)

當 Dify 的 AI 產出 JSON 報告時，有時會發生行號計算錯誤。例如，原本的變更只有 10 行，AI 卻在 JSON 裡回傳了 "line": 42。當 n8n 拿著這個行號去呼叫 GitHub 的 Create a review comment API 時，GitHub 會立刻回傳 422 Unprocessable Entity 的錯誤，導致整個工作流中斷，Jira 也不會被更新。

為了解決這個問題，我們在 n8n 中導入 Try-Catch 機制 與 Fallback（降級）策略：

• Error Trigger 節點： 在 n8n 中建立一個全局的錯誤捕捉節點。當回寫行內評論的 API 失敗時，流程不會死當，而是跳轉到這個錯誤處理分支。
• 降級回寫 (Fallback Comment)： 既然無法精準在「第 42 行」留言，我們就降級為在「整個 PR 的主留言區」發佈警告。透過 n8n 重新發送 API：

「 AI 審查官發現了一個潛在問題，但無法對齊具體行號。請開發者自行檢查：[帶入原本的 Issue Description]。」

• 重試與警報： 對於單純的網路 Timeout（如 500 錯誤），設定 API 節點的 Retry 參數（如指數退避重試 3 次）。若依然失敗，則自動發送 Slack 訊息給 DevOps 團隊排查。

這樣一來，無論 AI 發什麼神經，或是 GitHub 伺服器波動，我們的系統都能保證最低限度的運作，絕不卡死開發流程。

2. 點亮黑盒子：Langfuse 觀測性 (Observability) 導入

當系統發生上述的幻覺時，工程師的下一步就是去「抓蟲 (Debug)」。但在 AI 應用中，我們無法用傳統的 Log 知道 LLM 當時在想什麼。這時，Day 24 提到的 Langfuse 就成了救命稻草。

在 Dify 的後台設定中，我們可以一鍵開啟 Langfuse 整合（只需填入 Langfuse 的 Public/Secret Key）。整合後，這個自動化系統將獲得企業級的監控能力：

• 完整 Trace 還原： 當發現 AI 漏看了一個資安漏洞，你可以打開 Langfuse，找到該次 PR 審查的 Trace。你會清晰地看到 n8n 傳給 Dify 的完整 Git Diff 長什麼樣子、系統掛載的 RAG 團隊規範是否被正確檢索出來，以及隱藏的 System Prompt。這能讓你瞬間釐清是「資料清洗沒做好」還是「Prompt 寫得不夠嚴謹」。
• 成本與 Latency 監控： 每一次 PR 審查耗費了多少 Token？換算成美金是多少？回覆延遲了幾秒？這些指標 (Metrics) 對於日後系統上線的預估成本評估極具價值。面試時能講出「這套系統平均每次 PR 審查耗時 8 秒，成本約 $0.02 美元」，將展現你極高的 Engineering Sense。