GLM 5.2 + GPT-5.5 分層 AI 編程工作流筆記¶

來源：GLM 5.2 + GPT-5.5 (My Workflow): This is the BEST WAY TO CODE RIGHT NOW! 整理日期：2026-07-03

1. 大綱分類¶

一、當前 AI 編程的痛點與挑戰
二、四大核心工具鏈與技術架構
三、系統化的分階段開發工作流
四、開發限制與核心注意事項

2. 詳細說明¶

一、當前 AI 編程的痛點與挑戰¶

工具與點數碎片化：過去的開發流需要切換多個工具（設計、編程、API 額度管理、部署），必須頻繁確認哪家模型還能用、哪個 API 密鑰還有餘額，過程十分繁瑣 [00:00:18]。
同質化的 AI 生成界面：跳過設計直接讓 AI 編程，容易導致產出的 UI 缺乏特色（相同的卡片設計、巨大的漸層色、隨機的儀表板佈局及間距問題） [00:01:23]。
單一 Prompt 貪多必失：許多人試圖在一個 Prompt 裡讓 AI 同時扮演設計師、產品經理、前後端及運維（DevOps），這會導致產出的代碼達不到生產環境標準 [00:03:50]。

二、四大核心工具鏈與技術架構¶

層級	工具	職責
設計層	Open Design	編程前梳理界面、決定核心畫面的視覺走向，為 Coding Agent 建立約束條件 `[00:01:36]`
編程代理層	Open Code	終端機編程代理，不綁定單一模型，可依任務自由切換模型 `[00:02:42]`
模型路由層	Requesty	集中管理 API 點數、單一界面追蹤 Token 花費、支援 Fallback 策略 `[00:06:07]`
部署層	Railway	快速與 GitHub 連接，配置環境變數、資料庫與背景作業，適合快速上線測試 `[00:10:21]`

Requesty 的關鍵能力： - 集中化管理：將所有模型供應商的點數集中在同一帳戶，單一界面追蹤花費 [00:06:07], [00:08:26] - 備援機制（Fallback）：主模型設為 GLM 5.2，遇降速/限流自動切至 GPT-5.5，確保工作流不中斷 [00:06:19] - 工作類型導向策略：將模型選擇邏輯從「挑模型」轉為「挑工作類型」（前後端開發、架構審查、寫文件等） [00:07:53]

三、系統化的分階段開發工作流¶

步驟 1：視覺與邏輯約束
  └─ 在 Open Design 內完成核心重要畫面的設計

步驟 2：前端界面實現
  └─ 將設計上下文餵給 Open Code，嚴格限定僅專注 UI，不碰後端邏輯

步驟 3：後端架構規劃
  └─ 不直接寫後端代碼，先要求 AI 產出「後端計畫書」
     （資料模型、API 路由、驗證流程、Edge Cases），經人工審查後再放行

步驟 4：分塊分層實作
  └─ 順序：資料庫 Schema → API 路由 → 服務層 → 前後端串接 → 驗證與測試
     模型搭配：GLM 5.2 初版實作 → GPT-5.5 架構審查與代碼清理

步驟 5：自動化部署
  └─ 本地測試完畢，透過 Railway 部署上線

四、開發限制與核心注意事項¶

人工審查不可或缺： AI 消除枯燥重複工作、加速建置，但絕非取代人類技術判斷 [00:12:30]
潛在 AI 錯誤：
遺漏邊緣安全驗證
不小心暴露敏感數據
寫出多用戶環境下崩潰的資料庫查詢
無故將業務邏輯過度複雜化
涉及支付、用戶資料、檔案上傳時，必須由開發者親自把關 [00:11:57]

3. 全文總結¶

核心價值¶

這套分層工作流的核心在於「靈活性」與「控管力」。透過將設計、前端、後端、路由與部署拆解成獨立層級，擺脫單一 AI 廠商的 Vendor Lock-in 與當機風險。GLM 5.2 的實作效率 + GPT-5.5 的架構審查深度 + 中央化額度與策略路由（Requesty），既能滿足快速驗證的 Vibe Coding，也具備擴展至嚴謹商業專案的工程潛力。

行動建議¶

改變提問習慣：停止使用「幫我寫一個 SaaS 系統」之類的單一巨型 Prompt，改為「設計 → 前端 UI → 後端計畫審查 → 分塊實作 → 測試」的漸進式開發
建立點數與路由層：引入 Requesty 等模型 Gateway，配置 2-3 個模型的 Fallback Policy，防止關鍵交付時刻卡關
保持批判性審查： AI 產出的後端、資料庫查詢及安全相關代碼一律視為「待審查草稿」，針對高併發效能與隱私安全進行人工 Code Review