在 Day27，我成功為 Dev-Advisor 接上 RESTful API，證明外部系統、自動化腳本或伺服器可以透過程式化方式與其互動。然而，如果希望整個工程團隊（包括後端、前端、甚至非技術主管）都能無門檻地享用這套架構顧問的能力，直接提供 API Key 或終端機指令顯然不是最友善的做法。

一般使用者需要的是一個零安裝、免登入 Dify 後台、點開連結就能像使用 ChatGPT 一樣自然對話的獨立介面。

因此，我今天在 Day28 的任務，就是將 Dev-Advisor Chatflow 正式發布為面向全團隊的獨立 Web 應用（Web App），完成品牌客製化配置，並透過真實使用情境驗收端對端的使用者體驗。

今日配置重點：打造團隊專屬的前端入口
在 Dify 的「存取點（Access Points）」架構下，系統不僅提供 API Endpoint，更原生內建了「Web 應用程式」的分發能力。今天我完成的配置如下：

1. 啟用獨立託管網址
   直接啟用 Dify 託管的獨立前端頁面，獲得團隊專屬的存取 URL（如 https://udify.app/chat/...）。這意味著團隊成員無需註冊或登入 Dify 帳號，只要在公司內網或瀏覽器貼上網址，就能直接開啟審查對話視窗。

2. 前端介面品牌化與引導設計（Brand & UX Settings）
   為了讓同仁進入系統時能立刻明白這台顧問的職責與能力邊界，我在「品牌設定」中進行了客製化調整：

   • Web App 名稱：設定為具備辨識度的 Dev-Advisor 架構審查顧問。
   • 應用描述與導引：填入清楚的使用指引——「團隊專屬 AI 架構審查顧問。支援內部技術規範檢索、外部新版架構比對、自動化 Code Diff 重構建議與代碼安全性審查。」
   • 保留工作流詳細資訊：選擇開啟工作流追蹤功能。這讓終端使用者提問時，能即時看見 AI 當前正在執行的思維步驟（例如知識庫檢索中、聯網比對中），大幅降低黑盒子感並提升對回答專業度的信任。

實測驗收：口語化提問與工作流全鏈路追蹤
介面設定完成後，我以一般工程師日常對話的口吻進行了線上即時測試。

提問測試
「欸，我們團隊現在密碼加密到底是要用哪種做法？Salt 要加幾碼才算合格？」

這類提問的特點在於：語言口語、帶有疑惑，且同時牽涉到「團隊現行內部標準」與「密碼學安全最佳實踐」的雙重比對。

系統執行歷程分析

在獨立 Web App 介面上，可視化面板忠實記錄了底層 Chatflow 的執行過程：

1. 開始節點：接收前端對話輸入
2. 問題分類器：模型快速將此口語提問歸類為內部標準與外部安全規範的交叉審查問題
3. 知識檢索節點：瞬間命中並抓取後台向量資料庫中的內部資安規範手冊
4. 雙核心 LLM 推論：分別完成內部規則解析、外部 OWASP/NIST 標準對比，並合成結構化的改善策略與代碼重構
5. 直接回覆：將完整內容渲染至前端聊天視窗

審查回覆產出成果
系統在獨立介面上給出的答覆極具專業深度，完全符合企業級架構審查標準：

• 內部現況診斷：點出團隊內部可能殘留的過時作法（如 SHA1/MD5 單純雜湊、未規範 Salt 長度與隨機度）
• 外部標準對齊：對標 NIST 與 OWASP 主流標準，明確指出現代密碼學要求的 Salt 必須大於等於 16 bytes（128 bits）且必須由 CSPRNG 產生，推薦採用具備 Key stretching 特性的 Argon2 或 bcrypt。
• 漸進升級落地策略：給予具體的工程指引——不強求一次性刷庫重雜湊，而是建議在用戶成功登入驗證時實施「自動平滑升級 hash」
• 代碼重構比對（Diff）：直接給予 🔴 舊版 Legacy Code 與 🟢 新版合規 Code（利用 secrets 與 argon2 實作），工程師可直接複製參考

今日成果回顧
今天完成的配置，將整個專案向前推進了一大步：

• 免除金鑰外洩風險：使用者透過 Web 介面互動，後端 API Key 與敏感資料庫設定完全隱藏在 Dify 引擎內部
• 團隊協作即刻生效：一個網址即可讓團隊所有角色即開即用，免去複雜的環境配置
• 黑盒轉白盒：前端完整呈現工作流執行路徑，兼顧了簡潔的聊天體驗與工程級的追蹤透明度