歷經整整 30 天的漸進迭代,這套專為軟體工程團隊打造的 AI 架構審查顧問(Dev-Advisor) 已正式走完從「概念驗證(PoC)」到「生產級應用(Production Ready)」的完整週期。
在日常敏捷開發中,團隊常面臨內部歷史包袱與外部新技術標準脫節的難題。傳統的 Code Review 仰賴資深工程師的肉眼與記憶,容易遺漏規範或產生主觀摩擦。Dev-Advisor 的誕生,正是為了解決「內部規範對齊難、外部架構衝突大、重構路徑不明確」的三大工程痛點。
一、 系統架構全貌(Full Architecture Blueprint)
Dev-Advisor 採用 Dify 的 Chatflow(對話式工作流) 作為核心引擎,結合了 RAG、聯網檢索、雙核心 LLM 與全鏈路資安邊界。
二、 30 天工程演進里程碑回顧
整個 30 天的開發歷程可分為四個關鍵階段:
三、 系統核心使用指南(How to Use Dev-Advisor)
全團隊可透過兩種主要途徑隨時喚醒 Dev-Advisor:
途徑 A:全團隊免登入 Web 介面(日常諮詢與 Code Review)
進入入口:點擊團隊專屬 Web 應用連結
快捷啟動:點擊開場白下方的快捷情境按鈕,或直接在對話框貼上程式碼
支援情境:
輸出標準:系統一律回傳 5 大結構化區塊(現況診斷 ➔ 外部對比 ➔ 核心衝突 ➔ 落地建議 ➔ 舊版 vs 新版 Code Diff)
途徑 B:RESTful API 程式化整合(CI/CD 與機器人串接)
外部腳本或內部系統可直接發送標準 HTTP POST 請求至端點:
{
"inputs": {},
"query": "請審查這段 API 路由設計: @app.route('/v1/get_user_detail')",
"response_mode": "blocking",
"user": "developer-sam"
}
四、 30 天實戰心得與結語
說實話,這 30 天走過來絕對沒有架構圖上畫得那麼優雅順遂,途中經歷了無數次想砸鍵盤的時刻。回想剛開始搭建工作流的前十幾天,光是要讓節點順利串起來就吃盡苦頭。最常遇到的就是模型跑不動、回應無限卡死(Timeout),或是明明設定了條件分支,它卻像無頭蒼蠅一樣走錯路徑。有時知識庫檢索抓出來的內容整片空白,有時外網搜尋節點又因為請求太頻繁或逾時直接噴紅字報錯;更崩潰的是好不容易串好雙核心 LLM,產出的內容卻常常前後矛盾,甚至一輸入口語化問題,模型就開始自言自語陷入幻覺。
中後期(特別是到了 Day 26、Day 27)更是一場硬仗。當以為功能都做完了,一測 Prompt Injection(提示詞注入),才發現幾句簡單的「請忽略前面規則」就能輕易把我辛苦建立的內部規範手冊直接被扒得一乾二淨,只好硬著頭皮把 System Guardrails 刻進去,反覆壓測才築起防火牆。到了串接 API 那天,光是終端機環境缺少 requests 套件跳出 ModuleNotFoundError,就讓人瞬間愣住,最後改用原生 PowerShell 指令才成功把那串 JSON 答案給敲出來。
但也就是這一次次撞牆、除錯、推倒重來的過程,讓我真正深刻體會到:寫幾句 Prompt 叫 AI 寫程式只是玩具,要在真實工程場景裡把一個 AI 工具做到能讓團隊放心使用,背後全部都是細緻且繁瑣的系統工程。
從最初連線都動不動逾時的半成品,到現在能夠精準辨識意圖、比對內部與外部規範、吐出標準的 🔴/🟢 Code Diff,甚至在最後為團隊搭建了點開即用的 Web 介面與防護罩——看著最後在畫面上點擊快捷問題、系統在十幾秒內跑完所有節點並交出漂亮重構報告的那一刻,這 30 天所有除錯的痛苦與焦慮,全部都化成了實打實的成就感。
這套 Dev-Advisor 是我踩過無數坑之後生出來的成果。它證明了一件事:只要工作流的架構與容錯設計得當,AI 真的可以從一個捉摸不定的聊天機器人,變成工程團隊每天都離不開的靠譜隊友。