設計迴圈 (designloop) 是做什麼的？

一個迭代循環，透過反覆捕捉、評分與修正來提升現有使用者介面或相關文字的品質，而非憑藉猜測。每一輪：以相同方式捕捉 UI（或文字的內容快照），讓全新的評審員根據固定的評分標準進行評分，根據他們的發現進行修正，然後重複這個過程。其模型借鑒自 dream-loop 的評審方法（每輪使用新的評審員、挑剔、對品質倒退給出較低分數），並應用於 UI 打磨而非匹配目標圖像；同時也借鑒了 Theo (t3.gg) 在 Agents Sucked At UI (Until Today) 影片中提出的爬山演算法 UI 設計方法。

這個循環有效，是因為三個分離原則。請務必遵守：

評審員永遠不負責實作，實作者永遠不負責評審。 一個寫了修正方案的代理，會給自己的成果慷慨打分。
每一輪都是全新的評審員。 一個看過上一輪的評審員，會錨定在自己先前的判決上。給新評審員的是評分標準、新的捕捉內容以及上一輪的評分結果（這樣評分才能保持一致，並能指出哪些地方退步了），而不是整個對話。
捕捉的內容組合是固定的。 只有當第 N 輪展示的畫面、狀態和主題與第 0 輪完全相同時，分數才具有可比性。

三種模式

這三種模式的循環機制相同；不同的是評審員的衡量標準。首先確定模式，因為這決定了評分標準、值得提出的問題以及預期的變更幅度。

專業打磨 — 一個客觀的檢查，資深產品設計師會關注的項目：一套統一使用的 tokens 和表面、更少的字體大小和粗細、一致的間距尺度、可讀性和對比度、點擊目標和游標區域、狀態覆蓋、淺色/深色模式一致性、動畫品質。目標是應用程式自身的最佳表現；不涉及個人品味的改變。請閱讀 references/mode-polish.md。
藝術指導 — 一個朝向特定外觀和感覺的主觀檢查：指定的風格名稱（如「圖形寫實主義」、「帶有 ASCII 藝術和野獸派動態佈局的霓虹流行風格」）、一組參考資料、一個生成的目標圖像或一個需要比對的 Figma 設計。評審員根據 UI 對該方向的展現程度進行評分。預期會有較大的視覺變化，因此字體、顏色和佈局特性都將被調整。請閱讀 references/mode-art-direction.md。
寫作 — 將循環應用於文字：UI 文案（標籤、錯誤訊息、空白狀態、引導）、文件、產品頁面或獨立的文章。評審員根據清晰度、簡潔度、語氣、一致性和準確性進行評分，並針對指定的讀者進行評估，輔以讀者測試（一個全新的代理會冷讀文字，然後說出它會如何操作）。語意保持不變；僅優化文字本身。請閱讀 references/mode-writing.md，其中說明了以下每個步驟的變化（用文字取代表面、用內容快照取代捕捉、用詞彙表取代 tokens）。

若請求中的模式很明確，則從中推斷（「嚴謹」、「一致」、「鬆散」→ 打磨模式；「讓它看起來像」、「更有藝術感」、風格名稱、Figma 連結 → 藝術指導模式；「文案」、「措辭」、「文件」、「錯誤訊息」、「這篇文章」→ 寫作模式），否則請詢問使用者。使用者可能想要多種模式：先執行藝術指導模式設定外觀，再執行打磨模式使其一致，最後對文案執行寫作模式。每一次都作為一個獨立的循環，擁有各自的評分標準。不要將它們混合成一個評分標準，否則評審員會在一致性和風格之間權衡，導致分數失去意義。

步驟 1：與使用者面談

確定模式，然後使用 AskUserQuestion（兩次呼叫，每次最多提出四個問題）詢問其餘事項。跳過使用者訊息中已經回答的問題，並先提供一個推薦選項。答案將寫入簡報檔案（步驟 3），所有子代理都會閱讀該檔案。

目標 — 完成後什麼應該會變得更好，用他們的話來說？（「Chrome 感覺不一致」、「選單很馬虎」、「感覺卡卡的」。）同時詢問哪些是 禁止觸碰 的：他們想自己處理的表面，以及他們能接受的變更幅度（微調 vs. 重新設計 vs. 重新設計）。大多數使用者想要的是微調，而不是重新設計；在每個簡報中都這麼說，否則實作者會做得過頭。
重點（可複選）— 哪些方面最重要；這將設定評分標準的權重。選項取決於模式，並列在其參考檔案中（打磨模式：一致性與 tokens、字體排版、間距與佈局、可讀性、互動與點擊目標、動畫、效能；藝術指導模式：所選外觀的特徵，以及 UI 的哪些部分應該承載這些特徵；寫作模式：清晰度、簡潔度、結構、語氣與語調、一致性、實用性、準確性）。在寫作模式下，還要詢問 references/mode-writing.md 中的額外問題（讀者與目的、語氣範例、固定不變的內容、長度與本地化限制）。
基準 — 今天的 UI 處於什麼水平？使用者給出一個滿分 10 分的分數，或者讓評審員先評分。當使用者有自己的看法時，建議兩者都做：他們的分數可以校準評審員（如果使用者說 6 分而評審員說 8 分，說明評分標準太寬鬆了——在第 1 輪之前先收緊它）。
停止條件 — 目標分數（例如每個組別和主題 ≥9/10）、回合數，或者兩者中以先達到者為準。建議「目標分數，上限為 N 回合」。警告使用者，無上限的循環可能會消耗大量 tokens。
子代理智慧等級 — 評審員和實作者使用的模型和努力程度。提供選項：最佳可用（最慢，最徹底）、平衡（使用會議本身的模型和努力程度）、快速（使用較便宜的模型進行捕捉和機械性修正，使用強大模型進行評審）。評審工作是智慧投資回報最高的地方；如果使用者想節省，應優先節省捕捉和機械性實作。
參考資料 — 使用者是否有他們喜歡或必須符合的設計？網站、應用程式、截圖、Figma 連結、設計系統，或指定的指南或技能（平台 HIG、設計工程技能）。詢問他們喜歡每個參考資料的哪一點（密度、選單、動畫），因為單純「喜歡這個網站」而不給理由，會被直接複製。在打磨模式下，參考資料是可選的，通常是指南。在藝術指導模式下，循環需要一個目標：風格描述、參考資料、Figma 設計或生成的圖像；如果使用者沒有，主動提出要收集或生成一些（請參閱「參考資料與目標」）。
交付方式 — 僅一個分支、一個 PR（不合併），和/或一個他們可以執行的建置版本。預設：分支 + 未合併的 PR。除非使用者要求，否則永遠不要合併或發布。

將使用者提供的所有內容放在 .designloop/references/（步驟 3）中，並將其列在評分標準中，這樣每個評審員和實作者都基於相同的來源工作。

步驟 2：研究專案的設定

在撰寫任何規則之前，先了解這個專案實際上是如何執行、測試和發布的，這樣循環才能遵循使用者的習慣，而不是強加自己的規則。先查看，再詢問：閱讀儲存庫和機器能告訴你的資訊，只對仍然不清楚或屬於偏好問題的事項進行詢問。

尋找：

已經寫好的說明文件： CLAUDE.md / AGENTS.md、README 和 CONTRIBUTING、記憶筆記，以及任何先前的代理規則檔案。這些的優先級高於任何推斷。
應用程式的執行方式以及如何驅動它： package scripts、Makefile、開發環境與生產環境建置，以及能夠捕捉它的工具（瀏覽器/CDP、Playwright、模擬器或設備工具、現有的截圖或 e2e 設定）。如果沒有工具可以自動驅動應用程式，請告知使用者並詢問他們希望如何進行捕捉。
專案信任的檢查項目： 型別檢查、lint、測試、建置，以及這些檢查目前是否通過。
Git 習慣： 預設分支、分支命名、是否已在使用 worktree、commit 訊息慣例、工作是否通過 PR 進行。
執行時可能觸及儲存庫以外的任何東西： 真實帳戶、付費 API 或 AI 後端、訊息系統、生產資料、使用者自己的應用程式設定檔或設備。找出是否有 mock、示範或沙盒模式。
是否連接了設計工具： 如果使用者提供了 Figma 連結（或其他設計工具連結），檢查此工作階段中是否有可用的連接器或 MCP 伺服器，以及是否已登入。
此處是否可以生成圖像： 檢查此工作階段實際可以呼叫什麼，而不是假設。有些執行環境內建了圖像生成功能（例如 Codex）；其他的則來自已安裝的技能、外掛或 MCP 伺服器（Higgsfield 或任何其他圖像模型）。瀏覽可用的工具和技能來尋找。如果沒有，循環仍然可以運作；目標圖像是可選的。
對平行工作很重要的機器限制： 可用磁碟空間、已被佔用的埠、正在運行的其他代理或開發伺服器。

然後，在一通 AskUserQuestion 呼叫中，僅針對你無法從所發現的資訊中確定的選擇，與使用者進行確認。典型的選擇包括：

在哪裡工作： 目前分支、新分支，或每個實作者使用獨立的 worktree（當實作者平行執行時需要）。
如何測試： 僅開發伺服器，還是完成前也要測試生產/打包構建；哪些主題、視窗大小或裝置需要測試。
哪些東西不能碰或不能花費： 真實帳戶和付費服務，以及對捕捉來說 mock 模式是否可以接受。
一次執行多少工作： 平行執行多個實作者，還是逐一執行。

在問題中說明你的推斷（「我發現了 X，所以我計劃 Y」），這樣使用者可以快速修正。將結果寫入 RULES.md（下一步），並註明哪些規則來自使用者，哪些是你推斷的。

步驟 3：設定

在原始碼樹之外建立一個工作資料夾，或者在儲存庫中建立一個被 git 忽略的 .designloop/ 資料夾：

.designloop/
  BRIEF.md        # 面談答案：目標、範圍（包含/排除）、變更容忍度、重點、停止條件
  RUBRIC.md       # 來自 references/rubric.md，根據選擇的重點設定權重
  RULES.md        # 此專案的工作規則，來自步驟 2（參閱 references/briefs.md）
  references/     # 使用者喜歡的內容，以及任何目標圖像（見下文）
  capture/        # 捕捉腳本和表面列表
  round-0/ …      # 每輪：每個主題的靜態圖片、videos/、index.json、judge-*.md

在產生任何內容之前先寫好這些。子代理開始時沒有上下文，因此這些檔案就是上下文：將簡報指向它們，而不是重複輸入。

RUBRIC.md — 從模式參考檔案（references/mode-polish.md 或 references/mode-art-direction.md）中的評分標準開始，並包含來自 references/rubric.md 的共享標頭和評審員輸出格式。根據使用者的重點調整權重，明確寫出 IN 和 OUT 的範圍列表，並定義最高分數的含義。
RULES.md — 步驟 2 所確立的內容：如何執行和驅動應用程式、在 git 的何處工作、要執行的檢查、哪些東西不能碰或不能花費，以及如何清理。references/briefs.md 列出了它應涵蓋的項目。
表面列表 — 範圍內的每個畫面，每個畫面都帶有值得評審的狀態（靜止、懸浮、開啟、選中、空白、錯誤、忙碌）以及每個主題。將其分成兩到三個相關畫面的組別，這樣每個評審員可以仔細查看；一個評審員瀏覽五十張截圖只會走馬看花。

在開始之前，先檢查專案的檢查項目是否通過，這樣之後的失敗就是你造成的。

參考資料與目標

評分標準定義了普遍意義上的「好」是什麼；參考資料則定義了「好」在這個使用者看來是什麼樣子。藝術指導模式總是需要某種目標。打磨模式可以僅憑評分標準執行，以應用程式自身最好的畫面作為標準。

目標有三種，它們具有不同的權威等級。在 references/README.md 中說明每個檔案屬於哪一種，因為評審員和實作者必須區別對待：

一項規格（使用者要求比對的 Figma 設計）：權威性的。精確比對。
一項參考資料（使用者喜歡的網站、應用程式、截圖）：比對指定的特徵，而不是整個東西。
一個生成的圖像：僅指示整體感覺的方向。

使用者提供的參考資料。 將它們儲存到 .designloop/references/ 中，並附上一個簡短的 README.md：對於每個參考資料，說明它是什麼以及使用者喜歡它的哪一點。對於網站或應用程式，捕捉相關部分的截圖（如果吸引人的是動畫，則捕捉一個片段），這樣每輪評審員看到的都是相同的內容，而不是重新獲取一個可能變化的頁面。將喜歡的原因轉化為具體、可檢查的特徵，並寫入評分標準（「行高大約 28px」、「一個強調色」、「選單在 200ms 內淡入」），因為評審員可以對特徵評分，但無法對「氛圍」評分。

你自己收集的參考資料。 如果使用者想要一個方向但沒有範例，提出三四個其介面符合目標的知名產品，展示給使用者，然後讓使用者選擇。不要替他們選擇。

一個 Figma 設計。 如果使用者提供了 Figma 連結，檢查此工作階段中是否有可用的 Figma 連接器或 MCP 伺服器（步驟 2）。如果有的話，先載入它自己的技能或說明文件，然後為每個連結的影格拉取內容：一個重新

設計迴圈 (designloop)