Rex Tseng

作品

Building an AI Design Pipeline at Bitget

從 AI 讀得懂的設計系統，到決定下一個該誰上場的 Router

Growth 團隊的落地頁需要做得快，又要守住設計系統。我想知道 AI agent 能不能把一個頁面，從零散的需求帶到通過審稿的成品。我開始做的時候，身邊很少人用過 agent，模型要遵守設計系統也還不穩定。

當時沒有現成的做法，所以我用試錯的方式建立方法：把設計系統整理成 agent 讀得懂的 skill、決定怎麼分類與拆解工作，並在每次失敗後調整整條流程。現在是一個 Router 帶八個 agent。下方的示範會把路由規則套用在你輸入的內容上。

角色
研究Agent 架構工作流設計
平台
Claude Code

系統概覽

專職 agent，由同一個 Router 調度主流程五個，方向迴圈三個
8
平台 skillWeb 與 App，另有挑選元件與探索方向的指引
2
審稿維度從真人審稿的留言歸納而來
9 + 1
AI-slop 特徵頁面生成後，會用它們檢查自己的成品
12
每個維度的通過分數稽查為五個維度打分，五項都要達到
8 / 10

數字取自目前版本的系統組成。

一個 Router，加上讓路由成立的界線

入口 agent 自己不產出頁面。它確認有專案資料夾和需求、檢查哪些檔案已經存在，再把工作交給第一個還沒完成的步驟。已經有 brief 就跳過 brief 階段；只要求檢查，就直接交給檢查的 agent。

這能成立，是因為每個 agent 都寫明什麼時候不能上場。需求結構化只處理零散的筆記，已經有 brief 就不會觸發；Token 對齊會改數值，但不動版型；稽查只診斷，不修改。需求只會去到規則說它該去的地方。

試試 Router

輸入一個需求，或選一個範例。Router 會套用規則，顯示哪些 agent 上場、哪些被跳過，以及原因。這些 agent 實際是在 Claude Code 裡運作。

等待需求。

Router

page-pipeline

確認有專案資料夾與需求，檢查哪些檔案已經存在，再把工作交給第一個還沒完成的步驟。它自己不生成任何東西。

輸入 需求 + 專案資料夾輸出 一個決定：下一個該誰上場

主要流程

  1. 需求結構化
    brief-parser

    把零散的筆記、聊天紀錄和會議摘要整理成一份結構化 brief。不清楚的地方列進待確認問題，不自行腦補。

    輸入 原始需求輸出 brief.json

    人工確認點你先確認 brief，才會開始做頁面。

  2. 頁面生成
    page-builder-pro

    從 brief 直接做出可用的頁面：架構、版型與程式碼一次完成。先和你討論方向，再用十二條 AI-slop 特徵檢查自己的成品。

    輸入 brief.json輸出 index.html

    人工確認點你先選方向，做完後再決定接受、換方向，或只調整某個區塊。

  3. AI 味稽查
    ui-system-audit

    品質關卡。診斷層級、結構與響應式，標出套版預設的做法。只診斷，不修改。

    輸入 index.html輸出 問題清單

  4. Token 對齊
    design-system-enforcer

    把寫死的數值換成設計系統的 token，並遵守它的規則。不動版型。

    輸入 index.html輸出 index-refined.html

  5. 審稿標準
    ds-review-standard

    用真人設計系統審稿員的標準檢查頁面：九個維度加一個，每項標成必須改、建議或待確認，最後列出最優先修的三項。

    輸入 對齊後的頁面輸出 分級的審稿意見

方向迴圈

  1. 方向發散
    direction-explorer

    讀 brief 和已嘗試過的方向紀錄，提出一個新方向。六條軸線（密度、層級、語氣、色彩策略、形狀語言、大膽程度）至少要有兩條和過往不同。

    輸入 brief + 方向紀錄輸出 一個新方向

  2. 事實稽查
    auditor

    事實層。用五個維度為新版本各打 1 到 10 分，列出具體、可修的問題，五個維度都要到 8 分才算通過。不討論策略。

    輸入 頁面 + 截圖 + brief輸出 分數與修正清單

  3. 策略挑戰

    策略層，扮演資深 UED 總監。追問方向對不對、夠不夠大膽、對商業有沒有說服力，每個決策都要說得出為什麼。

    輸入 打過分的版本輸出 需要回答的質疑

↺ 重複到方向通過兩道檢查為止。

讓設計系統變成 agent 讀得懂的東西

為人寫的設計系統，模型很難照著做：規則散在各份文件，很多數值是隱含的，「看起來對」也沒有定義。我最初的嘗試常常偏離設計系統。回頭查，多半是知識整理得不好，再怎麼調 prompt 也補不回來。

我自己動手把設計系統從 Figma 抽取出來，改依 agent 工作時會問的問題重新整理：數值是多少、哪個元件適合、這樣做被允許嗎、該怎麼生成。基礎規範變成結構化資料，元件變成描述結構與狀態的規格，生成規則則獨立成一份指引。Web 與 App 各自成為一個 skill，另外有挑選元件、探索方向的簡短指引，讓 agent 每次只載入需要的那一塊。

索引會標出每條規則放在哪裡，而糾正記錄的優先級高於基礎規格，所以在一個頁面學到的教訓，會套用到下一個頁面。

試錯，並且留下紀錄

有一次 QA 沒過，我追到的根源是缺少一份參考範例。我補上範例，沒有去改 prompt。結構上也調整了幾個地方：

  1. 頁面結構規劃、畫線框和實作，原本是三個 agent 互傳檔案。我把它們併成一個直接讀 brief 的 agent，中間檔案也拿掉了。
  2. 診斷頁面、對齊 token、依審稿標準評斷，是三個獨立的 agent，每一個都寫明什麼時候不能上場，彼此不越界。
  3. 我把真人審稿的留言歸納成九個維度，再加一個美感判斷的維度，每個發現分成必須改、建議、待確認。
  4. 幾輪下來，方向總是長得很像。所以方向發散 agent 會先讀已經試過的方向紀錄，新方向至少要在兩條軸線上和過往不同。
  5. 一次對話裡學到的修正，下次就不見了。所以每個專案結束後，retrospect agent 會讀專案資料夾和對話紀錄，把學到的整理起來；頁面上做過的修正，也會合併回 skill。

人在哪裡做決定

這條 pipeline 不會無人看管地從頭跑到尾。它停在三個地方：brief 完成後，在還沒開始做之前就抓出對需求的誤讀；開始做之前，討論方向；第一版完成後，由設計師決定接受、換方向、只調整某個區塊，或改變設計哲學。之後才進入 token 與審稿階段。

Agent 負責提案、生成與檢查，方向與品味由設計師決定。

方向不對時的迴圈

有時整個方向就是錯的，修再多細節也沒用。方向發散 agent 會讀 brief 和已嘗試過的方向紀錄，提出的新方向必須在六條軸線中至少兩條和過往不同：密度、層級、語氣、色彩策略、形狀語言，以及敢多大膽。

接著由事實稽查用五個維度為結果各打 1 到 10 分，再由策略挑戰 agent 扮演資深 UED 總監，追問方向對不對、夠不夠大膽、對商業有沒有說服力。一個指出客觀上哪裡錯，另一個問這樣做值不值得，頁面不會因為符合規範就算過關。