1. 核心觀念與架構設計
在先前的實作中，我們建立了一個具備「平行雙軌分析」與「雙模型容錯備援（GPT-4.1 + GPT-4o-mini Fallback）」的自動化後端架構審查工作流。然而，純粹的 Workflow 本質上是單次批次處理引擎：使用者每發起一次審查，工作流就重新冷啟動執行一次，輸出也往往被封裝在程式化的 JSON 字典中，缺乏直覺的閱讀體驗與互動性。

為了打造真正能與工程師協同作業的「個人專屬 AI 架構顧問」，我們在第 20 天正式啟動架構遷移：將純 Workflow 轉換為對話型 Chatflow（Chatbot）。

架構轉型的核心差異

• 會話生命週期（Conversation Lifecycle）：純Workflow只有輸入與輸出，執行結束即釋放資源；Chatbot 則內建了會話上下文機制（Session Management），具備持續對話與狀態維持的潛力
• 介面渲染解耦：原本Workflow的「結束（End）」節點多以變數輸出為主，容易呈現 { "result": "..." } 的 Raw Text；轉型為Chatbot後，透過核心的「直接回覆（Answer）」節點，文字能直接以乾淨的Markdown格式逐行串流渲染至對話介面
• 幕後智囊與前台發言人分工：前置的「內部規範分析」與「技術特性分析」LLM 節點回歸為幕後的計算大腦，專心處理分析數據；而最終匯流的大腦（LLM4）則將報告交付給「直接回覆」節點，達成清晰的職責分離

2. 實作流程與節點配置
本次改造的重點在於畫布拓撲結構的調整，以及從Workflow到Chatbot的狀態銜接。

步驟一：節點搬移與角色重新定位

1. 將原本Workflow中的核心邏輯完整複製至Chatflow畫布中。
2. 保留原先的平行審查機制：上方節點負責團隊內部 RESTful 規範比對，下方節點負責外部 SQLAlchemy 2.0 變更分析。
3. 中樞大腦 LLM4（GPT-4.1）維持3次重試機制，並在失敗分支掛載 LLM_BACKUP（GPT-4o-mini）以確保極致的可用性。

步驟二：連線閉環與收攏（Join）配置

1. 在多分支並行時，若平行執行的節點未被明確宣告收攏終點，可能導致排程器死鎖。
2. 將主力的LLM4正常輸出線連接至「直接回覆」節點。
3. 將備援的LLM_BACKUP輸出線同樣接入「直接回覆」節點。
4. 將上方平行的分析節點同步連入回覆閉環，確保所有平行分支狀態皆能被執行引擎順利識別與釋放。

步驟三：端到端排版淨化
在「直接回覆」節點中，直接綁定彙整節點產出的文字變數，並移除所有額外包裝的JSON鍵值結構，讓系統直接吐出結構化 Markdown。

3. 實測驗證與成果展示
我們以一個具備強烈架構衝突的實務案例進行第一輪對話驗收：

審查請求：
*「我們團隊預計將後端系統的 ORM 從舊版升級至 SQLAlchemy 2.0，同時計劃新增一個批量更新訂單狀態的 API：POST /orders/bulk-update。請根據團隊內部開發規範與 SQLAlchemy 2.0 的技術變更，評估兩者的潛在衝突，並提供符合 RESTful 與漸進升級的具體落地建議。」
*

實測回傳結果（直接 Markdown 渲染呈現）

### 1. 內部規範現況診斷
- API 路由命名現況：提案採用 POST /orders/bulk-update。
- 開發規範衝突：團隊嚴格遵循 RESTful 原則，不允許 URL 中出現動詞（bulk-update），應以資源及其狀態表述為主。

### 2. 外部技術特性分析
- SQLAlchemy 2.0 變更：
  - 1.4 與 2.0 無法於同一環境並存。
  - 廢棄 bulk_update_mappings，批次操作推薦改用 session.execute(update(...))。
  - 推薦在 1.4 階段開啟 future=True 與 SQLALCHEMY_WARN_20 消除警告。

### 3. 兩者核心衝突點
- API 命名違規：/orders/bulk-update 屬於 REST 反模式。
- 語法不相容：舊版映射批次寫法在 2.0 被淘汰，不可直接搬移。

### 4. 落地建議
- RESTful 路由建議：
  - 方案一：PATCH /orders 搭配批次 payload。
  - 方案二：抽象為任務資源 POST /order-batch-operations。
- SQLAlchemy 建議寫法：
  from sqlalchemy import update
  session.execute(
      update(Order).where(Order.id.in_(order_ids)).values(status="canceled")
  )
  session.commit()

驗證結論
文字完整脫離先前的JSON字串與跳脫換行符號（\n），以乾淨易讀的工程文件排版直接呈現於對話框中，整體使用者體驗大幅提升！

4. 踩坑記錄與心得小結
在今天的架構重組過程中，我們踩到了兩個非常具有啟發性的工程細節：

• 工作流並行死鎖與強制閉環：
  在Dify的圖形化排程引擎中，平行分支（Parallel Nodes）的匯流需要嚴謹的拓撲終點。如果前置分析節點跑完後沒有明確的收攏路徑，流程容易因等待狀態未結束而卡死。實務上將前置節點共同接往終端「直接回覆」節點，能有效解除狀態等待，確保引擎平穩運算。

• 初始化輸入與對話框的雙重變數現象：
  剛從Workflow遷移到Chatbot時，原本自訂的「使用者問題」變數仍留在「開始」節點中，導致第一輪對話時系統要求輸入兩次問題（初始化參數 + 底部對話框）。這讓我們深入理解了Dify專案從靜態變數輸入邁向動態sys.query 的生命週期差異。

今日小結：
今天我們成功攻克了「工作流轉對話應用」的關鍵關卡，架構審查器已具備優良的Markdown排版能力！明天 Day 21，我們將在此基礎上正式引入「意圖分類器（Question Classifier）」，徹底啟動多輪追問上下文，並打通畫布上的DuckDuckGo聯網搜尋工具，讓Agent具備即時檢索外部最新技術文件的強大能力！