在昨天（Day12）的進度中，我成功將內部規範手冊硬性嵌入管線。但我隨即發現一個系統缺陷：不論使用者問什麼，系統都會無差別地查內部知識庫。這不僅拖慢回應速度，更白白消耗運算資源。為了讓系統更聰明，我今天的核心任務是引入「問題分類器（Question Classifier）」，打造具備智慧路由能力的雙軌工作流，並在實測中完成了關鍵的分流邊界除錯。

一、 重構管線架構：搭建雙軌分流系統
為了讓提問能被分發到合適的處理通道，我重新設計了畫布架構：

• 開始節點：統一接收使用者的初始提問變數query
• 問題分類器節點（Question Classifier）：擔任智慧分流中樞，依據語意判定提問意圖
• 分支一（內部規範諮詢）：導向「知識檢索」節點與第一個LLM，專門依據團隊手冊進行架構審查
• 分支二（一般技術與其他諮詢）：導向獨立的第二個LLM節點，跳過知識檢索，專注解答通用的演算法與程式開發問題
• 輸出節點：同時承接兩個分支的產出變數（answer 與 answer2），完成統一的回應聚合
  

二、 雙向實測與分類器除錯實錄
在完成節點連線後，我進行了兩輪交叉測試，並記錄了邊界除錯過程：

1. 一般技術分支驗證
   我輸入了費氏數列（Fibonacci）的遞迴演算法提問，系統精準判定為一般技術，成功走LLM2分支，產出了具備型別標註與lru_cache快取的優質程式碼，完全沒有調用內部規範庫。

2. 分類器邊界識別與除錯
   在測試RESTful API命名問題時，最初提問過於簡短，被分類器誤判為通用概念而走向LLM2，後來我隨即針對問題分類器的分類描述進行語意強化，加入「合規審查、內部規範、架構檢查」等關鍵動詞，調整後再次測試，系統立刻精準切換至「內部規範諮詢」分支。

3. 內部規範審查產出成效
   成功走通分支後，模型確實吃到了知識庫的內容，沒有隨便給出含糊的答案，而是直接列出清單要求我提供路由表、.gitignore 與 CI 設定，並緊扣著我們手冊裡的規定，一項項比對憑證管理、bcrypt 雜湊參數以及 Git PR 門檻。

三、 今日成果
今天不僅成功實現了工作流的雙軌智慧分流，更體會到 Prompt Engineering 在「意圖路由分類」中的關鍵作用，分類器描述的精確度，直接決定了管線分流的穩定性。