前幾天我陸續完成了內部規範知識庫（RAG）、問題分類器分流、DuckDuckGo 即時搜尋，以及讓連續對話更聰明的指代消解。

整個系統的基本架構已經成型，但我在實際使用時發現了一個很現實的問題：
當我問模型一些版本相容或寫法衝突的問題時，它給的回答大多是純文字的技術分析，例如「建議使用 2.0-style 語法」、「建議開啟相容模式」。這類回答在方向上沒有錯，但對於每天在趕專案、趕著提 Pull Request（PR）的工程師來說，光看這些觀念依然要花時間去翻文檔，自己摸索程式碼該怎麼改，甚至改完了還是不知道會不會踩到內部規範的雷。

因此，我今天要做的事情很明確：升級系統中負責綜合比對的大腦（LLM 4），讓它在比對出內部規範與新技術的衝突點時，不要只講道理，而是必須直接產出「重構前」與「重構後」的具體程式碼範例（Code Diff），並附上能直接給 Reviewer 參考的說明。

今天的修改內容
這次在工作流畫布的結構上，先前拉好的節點路徑已經很完整，所以我保留了既有的連線架構，主要是針對LLM4（LLM綜合比對節點）的System Prompt進行針對性的升級調整。

原本的LLM4已經定義了四個分析結構（內部現況、外部特性、核心衝突、漸進升級建議）。為了解決只說不練的問題，我在提示詞的要求最後新增了第 5 項規則，強制要求它必須產出程式碼範例：

你是一位資深軟體架構師與 Code Review 顧問。
請仔細比對【內部團隊規範】與【外部技術動態/使用者提問】，針對兩者的衝突進行深度技術診斷，並產出可直接落地的重構建議。

【核心診斷要求】
1. 內部規範現況診斷：明確指出團隊內部的版本約定與架構限制。
2. 外部技術特性分析：說明外部最新版本的關鍵變更與推薦用法。
3. 兩者核心衝突點：精準指出語法、執行環境或相容性上的主要矛盾。
4. 漸進升級與 Code Review 落地建議：提供如何兼顧內部規定與平滑升級的具體步驟（如 future 標誌、相容層等）。
5. 漸進式重構程式碼範例（Refactoring Diff）：
   - 針對衝突的寫法，提供【🔴 舊版/違反規範寫法（Legacy Code）】與【🟢 合規且相容新版寫法（Refactored Code）】。
   - 使用 Markdown 程式碼區塊（標明語言如 python），並加上清楚的註解說明關鍵變更點。

【輸出結構要求】
### 1. 內部規範現況診斷
### 2. 外部技術特性分析
### 3. 兩者核心衝突點
### 4. 漸進升級與 Code Review 落地建議
### 5. 漸進式重構程式碼範例（Refactoring Diff）

除了LLM4之外，我也同步更新了旁邊的LLM_Backup（備援顧問節點），放上相同標準的提示詞。這樣做是為了確保即使主模型遇到網路波動或重試時，備援路徑輸出給使用者的格式也能維持一致，不會缺漏程式碼區塊。其他節點包含問題分類器、知識檢索、外部搜尋等，都保持先前的穩定配置，沒有做額外變動。

實測過程與驗收
調整完成並按下發布後，我開始進行實際測試。為了模擬工程師日常開發的真實情況，我故意不用生硬的學術名詞提問，而是直接用工程師在 PR 被退件時常會有的抱怨與口吻來問：

我的提問：
「我們團隊規範寫死 ORM 只能用 1.4，結果我新寫的批次更新被主管退件說不合規。但我之後想直上 2.0 啊，有什麼過渡期的寫法兩邊都能跑？貼給我改寫前跟改寫後的範例就好。」

送出這段提問後，我首先觀察畫布歷程的執行軌跡：

1. 開始節點：順利接收並傳遞原生 sys.query
2. 問題分類器：雖然問題文字很口語，但分類器成功辨識出「被主管退件（內部規範）」與「未來想直上 2.0（外部新寫法）」的矛盾，精準分流到了「複合交叉比對」路徑
3. 知識檢索與內部分析：系統快速調出內部規範手冊中關於 ORM 版本與操作的條款
4. LLM4綜合比對：結合了內部規範手冊與提問意圖，順利進入最終分析
5. 直接回覆：完成整份結構化報告的渲染

整個歷程節點全部亮綠燈通過，沒有出現任何中斷或型態不合的錯誤。

系統產出成果解析
模型最終產出的回答非常扎實，結構完全按照我設定的五個維度展開。其中最核心的第5點，確實老老實實給出了兩段程式碼對比：

1. 舊版/違反規範寫法（Legacy Code)

# 只適用於 1.4，將於 2.0 被棄用
session.query(User).filter(User.is_deleted == False).update(
    {User.status: 'active'},
    synchronize_session=False
)
session.commit()

模型指出了這段寫法的痛點：這是傳統 SQLAlchemy 1.4 的舊語法，雖然目前環境能跑，但在 2.0 中這類 API 會直接被拋棄，未來升級時會引發大量錯誤。

2. 合規且相容新版的重構寫法（Refactored Code）

# 前提：Engine 與 Session 初始化時，請啟用 future 模式
# engine = create_engine(..., future=True)
# session = Session(engine, future=True)

from sqlalchemy import update

stmt = (
   update(User)
   .where(User.is_deleted == False)
   .values(status='active')
)

session.execute(stmt)
session.commit()

更貼心的是，模型不只貼了程式碼，還主動標註了先決條件：要在 1.4 環境中執行這種 2.0 樣式的 session.execute(update(...))，必須在建立 Engine 和 Session 時帶入 future=True 參數。

此外，它還在文末直接附上一段「供 PR 使用的說明草稿」，告訴開發者可以直接向主管解釋：
「這段程式碼採用了 SQLAlchemy 1.4 的 future 模式相容語法，在維持現行 1.4 規範運作的同時，已經對齊了 2.0 的 API 規格，未來系統升級時不需要再次重構這部分邏輯。」
這段說明正好切中了一線開發者和主管溝通時的痛點。

今日成果回顧
今天最重要的進展，是把Agent的產出能力從「文字分析」推進到了「可執行程式碼」。回顧先前的版本，模型雖然知道問題在哪裡，但往往把最後一里路留給工程師自己去查文檔。今天透過在提示詞中明確規範 Code Diff 的格式要求，讓它直接承擔了 Code Review 顧問的角色：

• 不僅能精準解讀隨性、口語的提問意圖
• 能同時考量內部手冊的限制與外部升級的需求
• 最重要的是直接給出修改前與修改後的對比範例，以及兼顧兩邊相容性的設定細節

這樣的改善讓這個對話機器人不再只是空談規範的審查員，而是真正能幫團隊解決 PR 卡關、加速程式碼重構的得力助手。接下來幾天，我會繼續往生產級應用的方向邁進，把輸入邊界、防護機制與對外串接逐一補齊！