在過去幾天的實戰中，我已經陸續為 Agent 裝上了內部知識庫 RAG、DuckDuckGo 外部搜尋、多輪指代消解，以及重構程式碼（Code Diff）的生成能力。

但在真實的開發場景中，工程師來找架構顧問諮詢時，提問往往不會一開始就寫得鉅細靡遺。很多時候大家隨手丟出來的問題非常簡短、籠統，例如：「我們 API 命名要怎麼訂比較好？」、「快取要怎麼做？」。

面對這種模糊、缺乏技術上下文的提問，如果系統直接隨機腦補一大堆通用教科書理論，往往回答了半天都不是提問者真正要的痛點。因此，我今天要做的事情，就是測試並強化系統在面對「模糊提問」時的情境收斂能力：讓顧問在上下文不足的情況下，能快速對齊團隊最常見的痛點架構，給出明確的診斷與範例，並在最後主動引導使用者補充細節。

今天的修改內容
為了解決模糊提問容易引發無效回答的問題，我主要針對審查鏈路中的提示詞進行了防護與引導機制的微調。

在負責內部規範分析的 LLM 節點中，我在原本的審查指引底下新增了「主動澄清機制」，要求模型在遇到提問過於簡短時，先給出大原則，並條列引導問題：

你是一位專業的軟體架構與開發規範審查顧問（Dev-Advisor）。
請嚴格依據下列「內部規範手冊」內容，針對使用者的提問進行審查：

【內部團隊規範】
{{#context#}}

【使用者提問】
{{#開始.query#}}

審查指引：
1. 若使用者的做法違反內部規範（如 RESTful 命名、GET 冪等性、密碼儲存、PR 門檻等），請直接指出錯誤並給出具體合規的修改建議。
2. 回答需條理分明、語氣專業且具建設性。
3. 【主動澄清機制】：若使用者的提問過於籠統、簡短或缺乏具體情境（例如僅問「API 怎麼命名？」卻未提供具體資源、端點用途或 HTTP 方法）：
   - 禁止盲目展開大篇幅的通用教科書內容。
   - 請先簡述內部最核心的大原則，並主動列出 2~3 個問題請使用者補充情境，引導其提供完整資訊後再深入審查。

同時，由於先前在 LLM 4（綜合比對節點）中已經建立了五大診斷結構（現況、外部趨勢、衝突點、落地建議、Code Diff），這兩個節點的搭配剛好能涵蓋「純內部模糊諮詢」與「跨架構模糊比對」的場景。

實測過程與驗收
修改完成並發布後，我故意輸入了一句完全沒有上下文、極度籠統的問題來做驗收：

我的提問：
「我們 API 的命名要怎麼訂比較好？」

送出後，我打開工作流歷程面板檢視系統的決策路徑：

• 開始節點：接收系統原生輸入
• 問題分類器：分類器將這句籠統提問識別為需要對照內部規範與外部 RESTful 標準，因此導流至「複合交叉比對」
• 知識檢索 ➔ LLM ➔ LLM 4：鏈路依序檢索內部規範手冊，並傳入中央的綜合比對大腦LLM4進行情境收斂
• 直接回覆：完成最終輸出渲染

系統產出成果解析
在提問資訊極度有限的情況下，系統產出的回答展現出很高的水準，主要有以下三個亮點：

1. 主動收斂情境，直擊真實開發痛點
   模型沒有輸出空泛的網路文章，而是開門見山以團隊最典型的衝突情境作為假設切入：

   • 內部習慣：傳統動詞命名方式（如 /getUserInfo、/updateOrderStatus）
   • 外部標準：RESTful 資源導向命名（如 /users/{id}、/orders/{id}/status），透過 HTTP 方法（GET/POST/PUT/DELETE）區分行為

2. 給出具體的漸進式重構範例（Code Diff）
   針對這個痛點，系統直接給出 Node.js/Express 的重構範例：

   • 舊版寫法（Legacy Code）：指出動詞直接寫在 URL 上的缺點（如 app.get('/getUserInfo')）
   • 合規新版（Refactored Code）：改為標準資源型路由 app.get('/users/:userId')

相容過渡方案：貼心地寫出如何在舊路徑保留301轉向或共用 handler，避免前端畫面因為後端改網址而直接壞掉。

3. 文末主動引導追問
   在回答的最後，模型並沒有把話說死，而是主動提出：

「若有更具體的框架、語言、內部規範條文等，請補充，我能給出更精細的 Refactoring diff！」

這段收尾成功建立了一個良好的引導循環：即便提問者一開始講得不清不楚，系統也能先用典型範例穩住回答質量，同時把追問的主動權拋回給使用者，引導進入第二輪深入對話。

今日成果回顧
今天透過這輪測試，我驗證了 Agent 面對「開放式、模糊提問」時的穩健度：

• 不會因為提問過短而出現幻覺或直接報錯
• 具備將模糊概念（API 命名）自動映射到具體衝突場景（動詞路徑 vs 資源型路徑）的推論能力
• 保留了清晰的追問開口，為後續多輪深度溝通打下基礎