不用 Figma 的 AI 產品設計工作流程

當產品已有成熟的設計系統時，不用 Figma 做產品設計是可行的。我的 AI 產品設計工作流程使用三個 agent 技能：ui-design 探索九個方向，ui-implement 將選定方向實作到產品中，ui-walkthrough 則透過內建的 Agent Browser 審查每個狀態。決策仍由我來做；agent 負責處理重複性的生產與檢查工作。

大多數產品功能並非從空白頁面開始。一旦產品運行一段時間，基本的設計決策就已存在於程式碼中。按鈕、輸入框、卡片、導覽、間距、顏色、文案、懸停狀態和行動裝置行為都已定義完畢。在 Figma 中重建這些元件，往往意味著先把相同的元件拖到另一個畫布上，再回頭在產品中重建一遍。

設計師仍然負責產品決策。agent 省去了大量重複的組裝與檢查工作。這之所以可行，是因為 Zero 已有相當成熟的設計系統。

1. 以設計系統為基礎，開始不用 Figma 的產品設計

不用 Figma 並不代表沒有設計規範，反而需要更清晰的規範。

對於 Zero，agent 可以檢視：

• 按鈕、輸入框、下拉選單、卡片、對話框和導覽的現有元件
• 已建立的間距、字體排版、顏色、邊框和圓角半徑
• 現有的懸停、選取、停用、空狀態和行動裝置狀態
• 文案慣例，例如句首大寫和簡短的使用者介面標籤
• 展示這些元件如何組合的真實畫面

這些參考資料能回答一般的設計問題。新的輸入框應該看起來像現有已上線的輸入框。新的卡片應使用與最接近的現有卡片相同的表面和圓角。圖示按鈕應與其他圖示按鈕有相同的懸停回饋。

這給了 agent 一個邊界。它可以探索功能的結構，而不必為每個畫面發明新的視覺語言。

當團隊正在建立新品牌、新元件系統，或沒有近似產品參考的互動時，Figma 仍然很有用。但一旦系統成熟，運行中的產品就能成為主要的設計介面。這是我們用來重建 Zero 的設計即程式碼工作流程在功能層級的應用版本。

2. 使用 ui-design 探索九個產品設計方向

每個功能仍然需要探索。我不希望 agent 接收到我的第一句話就立刻轉化為程式碼。

我從 ui-design 開始。我給 agent 目前的畫面、使用者問題、目標和主要限制條件。agent 讀取現有的產品模式，並回傳一個推薦方向加上九個替代方案。

簡單來說，這個技能會擷取目前畫面、建立一個推薦方向、探索九個截然不同的替代方案、呈現各方案的取捨，然後等待人類做出選擇。

這個指令背後的設計思維

這個指令不只是視覺規則的清單，它將設計師的正常流程轉化為可重複執行的步驟：

1. 先理解，再提案。 在做任何事之前，先擷取目前畫面並閱讀周邊產品。
2. 以系統思考。 將現有元件、範本頁面、互動模式和文案規則視為起始素材。
3. 防止重新發明。 當提示語模糊時，AI 傾向於建立新模式。這個指令告訴它要找到最接近的已上線元件或頁面並重用，而不是憑記憶近似。
4. 先探索，再選擇。 After 錨點提供一個可行方向。九個變體則開啟關於版面、層次、密度、進入點和揭露方式的不同決策。
5. 將探索與承諾分開。 agent 在呈現選項後停止。人類比較取捨並做出選擇，之後才開始寫程式碼。
6. 審查整體體驗。 文案、懸停回饋、狀態、行動裝置行為和視覺一致性都是設計的一部分，而不是實作後的收尾工作。

這就是我希望這個技能具備的系統思維：理解現有產品、在其中探索，然後做出明確的選擇。

以下是完整的原始指令，逐字複製自實際工作流程：

完整原始 ui-design 指令

# vm0 / Zero UI Design Rules

## Workflow — visuals first, code later

**Do not jump to code.** When this skill is invoked, the first deliverable is always a set of rendered mockups for Ming to look at. Implementation happens only after a direction is chosen.

### Step 1 — Capture the "before"

- If a screen already exists, render its current state as the **before** image (screenshot the running app, or render the existing component as a static preview).
- If the request is for a brand-new screen, the "before" is either the closest existing screen or a blank state — make this explicit in the caption.

### Step 2 — Produce a single "after" anchor

- One mockup that represents your best-guess interpretation of the request, fully obeying every rule below (components, sentence case, agent-detail inputs/dropdowns, chat-composer card radii, add-schedule button, IconButton hovers, gray-50 surfaces).
- Pair it with the **before** side-by-side. Label them clearly: `Before` / `After`.

### Step 3 — Generate 9 variant explorations

After the before/after pair, produce **9 distinct variant mockups** for the same screen. Each variant should explore a meaningfully different design axis — not 9 color tweaks. Cover a spread such as:

1. Layout — single column vs. split / sidebar / grid
2. Density — compact vs. spacious
3. Hierarchy — which element leads visually
4. Surface treatment — flat vs. card-grouped vs. divided sections
5. Entry point — inline action vs. dedicated CTA vs. empty-state hero
6. Copy framing — instructive vs. minimal vs. conversational
7. Disclosure — everything visible vs. progressive reveal / accordions
8. Composition — content-led vs. control-led
9. A deliberately unconventional / "wild card" direction worth seeing once

Each variant must still respect the non-negotiables (sentence case, reuse components, agent-detail input/dropdown style, chat-composer radii, add-schedule button, IconButton hover, gray-50 neutrals). Variants explore *layout and emphasis*, not "what if we ignored the design system."

### Step 4 — Present, then wait

- Show all images to Ming in one message: the `Before / After` pair first, then the 9 variants numbered 1–9 with a one-line caption each describing the axis being explored.
- Ask which direction (or which mix) to pursue.
- Do not begin implementation until Ming picks a direction.

### Rendering the images

- Preferred path: build static HTML/React previews that use real Tailwind tokens from `turbo/apps/platform`, screenshot them, and upload via `okou web upload-file`.
- For quick exploration: the `v0` skill can generate variant mockups from a prompt — but the prompt must explicitly enumerate the rules below (sentence case, agent-detail inputs, chat-composer radius, etc.) so v0 doesn't produce generic SaaS UI.
- If image generation is unavailable for the session, fall back to clearly-labeled ASCII / textual wireframes for all 11 frames (before, after, 9 variants) and call this out — never silently skip the visuals step.

---

# Design Rules

These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them before writing components, and audit existing PRs against them during review.

## Core principles

1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.

## Reference patterns (copy these directly)

| Element             | Reference source                                  | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select     | Agent detail page dropdown                         | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius   | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button   | "Add schedule" button on the schedule page          | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button  | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button      | Existing IconButton with hover background           | Every clickable icon must have a visible hover state |

When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.

## Copy guidelines

- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.

## Components and structure

- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.

## Buttons

- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.

## Inputs

- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.

## Dropdowns / selects

- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.

## Cards and surfaces

- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.

## Focus and interaction

- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.

## Review checklist

Before declaring a UI ready, walk through:

1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element to confirm feedback?

If any answer is "no", fix it before opening the PR.

## When in doubt

- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.

九個選項不需要都是完成的設計稿。它們的作用是給我足夠的範圍，讓我能從不同角度看待問題，並朝正確方向前進。如果某個概念超出了目前的產品範疇，獨立的 React 原型仍然有幫助。對於這個功能，我選擇留在真實的產品系統中。

真實案例：Zero 的導覽

Zero 最初有一個 300 像素的側邊欄，同時容納產品目的地、固定的 agent 和對話串。它同時承擔三項工作。我想在不改變對話區域的前提下，將這三項工作分開。

這次探索的產品簡報如下：

/ui-design

從真實的歷史基礎重現 Zero 三區域導覽的設計階段。在不改變對話區域的前提下，將產品目的地、agent 和對話分隔成更清晰的區域。使用真實的 Zero token、圖示和元件。產生一個忠實於原始碼的 Before、一個強力的 After，以及九個真正不同的變體。不要編輯產品程式碼，也不要將模型圖呈現為瀏覽器證據。

第一次探索過於保守。幾個選項改變了寬度和選取樣式，但看起來仍像同一個側邊欄。我拒絕了那組結果，並要求 agent 在資訊架構層級讓差異更加明顯。

第二次執行回傳了九個真正不同的方向。我將它們整理成 3 × 3 的表格，方便比較，而不必讓文章變成一長串圖片。每個縮圖都可以在部落格的圖片檢視器中開啟。

1. 頂部導覽	2. 可收合抽屜	3. 對話串優先
將目的地移至對話上方	隱藏目的地直到需要時才顯示	以對話作為主要導覽物件
4. Agent 優先	5. 對話優先	6. 指令啟動器
先選擇 agent，再進入其對話串	將固定的 agent 置於活躍對話上方	從可搜尋的選單開啟目的地
7. 可展開軌道	8. 儀表板入口	9. 底部停靠列
僅在需要時展開窄軌道	從最近的工作開始	將目的地移至底部

我並沒有完全照著其中一個框架來做。我用它們來決定哪些應該保留、哪些應該改變。最終方向採用了窄目的地軌道、獨立的對話軌道、五個可見的固定 agent 插槽，以及現有的對話區域。

ui-design 的重要產出不只是圖片本身，而是一份簡短的決策記錄：

• 保留 68 像素的目的地軌道和 300 像素的對話軌道
• 顯示五個固定 agent 插槽
• 保持選取狀態低調但清晰可辨
• 僅在拖曳過程中顯示重新排序的引導提示
• 保持對話區域和現有的行動裝置抽屜不變

這已足夠開始實作。

3. 使用 ui-implement 將選定設計轉化為程式碼

在我選定方向並連接產品程式碼庫後，agent 直接在程式碼中工作。我不會先在 Figma 中重新繪製選定的框架。

簡單來說，ui-implement 跳過探索階段，因為方向已經確定。它找到最接近的真實元件和頁面結構，用它們進行建構，審查結果，並在瀏覽器中驗證功能。

這個指令所保護的事項

• 選定的方向在實作過程中不應被重新設計。
• agent 必須從最接近的現有元件和範本頁面開始。
• 重用優先於新元件，除非產品確實存在缺口。
• 自我審查和瀏覽器檢查能發現不一致的文案、狀態和互動。
• 如果產品決策仍未解決，工作將回到 ui-design。

這就是設計系統在實作過程中保持活躍的方式。它不是 agent 讀一次就放在一旁的文件，而是影響它選擇哪些元件以及如何檢查最終體驗的依據。

以下是完整的原始指令，逐字複製自實際工作流程：

完整原始 ui-implement 指令

# vm0 / Zero UI Implementation Rules

## Workflow — implement directly

When this skill is invoked, **skip the mockup and variant exploration phase**. Start implementing in `turbo/apps/platform` immediately, applying every design rule below.

### Step 1 — Locate the reference components

Before writing a line, open the reference components you'll mirror:

- Input / textarea → `src/views/agent-detail/` input
- Dropdown / select → `src/views/agent-detail/` dropdown
- Card / panel radius → chat composer card
- Page primary button → "Add schedule" button on the schedule page
- Icon-only button → existing `IconButton` with hover background

Read their props and class names. Mirror them — do not approximate from memory.

### Step 2 — Find the closest existing page template

Open the nearest existing page of the same shape (settings, list, detail) and inherit its scaffolding: section spacing, divider treatment, form-row width. Don't re-derive page structure.

### Step 3 — Build, then self-audit

Implement the screen with existing primitives from `turbo/apps/platform/src/components/`. When you think it's done, walk the **Review checklist** at the bottom of this skill before reporting back. Fix every "no" answer before declaring the work complete.

### Step 4 — Verify in the browser

For any UI work, start the dev server and exercise the feature in a browser before reporting the task as done. Hover every interactive element, test the golden path and edge cases, and watch for regressions in neighboring screens. Type-check and tests verify code, not feature correctness — if you can't open the browser, say so explicitly.

### When to fall back to ui-design

If the request is open-ended ("design a settings page for X") with no chosen direction, stop and run the `ui-design` skill instead — the before/after + 9 variants exist for exactly that case. `ui-implement` is for when the direction is already decided.

---

# Design Rules

These are the non-negotiable design conventions for any new UI shipped inside the vm0 platform (`turbo/apps/platform`). Apply them while building, and audit your own diff against them before opening the PR.

## Core principles

1. **Reuse, don't reinvent.** Always check existing primitives in `turbo/apps/platform/src/components/` and view-level patterns under `src/views/` before introducing a new component. If a similar interaction already ships in agent detail, schedule, or chat composer, copy that pattern rather than designing a parallel one.
2. **Match the Zero design language.** Soft surfaces, neutral grays, generous radii, subtle borders, no harsh shadows. The visual baseline is "calm, opinionated, slightly editorial" — never SaaS-default.
3. **Speak from the user's seat.** Copy should describe what *they* are about to do or see, not what the system is doing. Keep it short — usually a single sentence, max two.

## Reference patterns (copy these directly)

| Element             | Reference source                                  | Why |
|---------------------|---------------------------------------------------|-----|
| Text / textarea input | Agent detail page input (`src/views/agent-detail/`) | Established padding, border, focus state, placeholder treatment |
| Dropdown / select     | Agent detail page dropdown                         | Established trigger style, menu radius, item hover, check mark placement |
| Card / panel radius   | Chat composer card (look for `composer` components) | Sets the canonical card radius and surface style across the app |
| Primary page button   | "Add schedule" button on the schedule page          | The neutral-dark primary used everywhere *outside* of modals |
| Modal primary button  | The brand primary color (only inside dialogs/popovers) | Modals retain the brand-color primary; pages do not |
| Icon-only button      | Existing IconButton with hover background           | Every clickable icon must have a visible hover state |

When in doubt, open the reference component in the codebase, read its props and class names, and mirror them. Do not approximate from memory.

## Copy guidelines

- **User-perspective phrasing.** "Connect your inbox" beats "Inbox connection required". "No agents yet" beats "Agent list is empty".
- **Brevity over completeness.** A short line outperforms a complete sentence. Trim filler ("simply", "please", "in order to").
- **Sentence case for everything.** Labels, headings, buttons, menu items, table columns — all sentence case ("Model providers", "API keys", "Add schedule"). Never Title Case. Never `uppercase` via CSS on section headers. If you find a Title-Case or all-caps label, fix it.
- **No caption-case "decorative" labels** above fields or sections — they read as form-y and dated. Use a normal label or skip the label if the field is self-evident.
- **No trailing punctuation** on standalone labels or buttons. Periods are for body copy and helper text.
- When renaming a string, grep the codebase for the old string and tests for it — labels are referenced in tests and translations.

## Components and structure

- Always build pages out of existing components (`Button`, `Input`, `Select`, `Card`, `IconButton`, dialog primitives, etc.). New components are a last resort and require a reason.
- Look for an existing layout/template (settings page, list page, detail page) and inherit its scaffolding. Don't re-derive page structure.
- When adding to a settings-style page, match the section spacing, divider treatment, and form-row width used by neighboring sections.

## Buttons

- **Page primary** (the main CTA on a page) → match the "Add schedule" button on the schedule page. This is the neutral dark/solid primary used app-wide outside dialogs.
- **Modal primary** (the confirm button inside dialogs/popovers) → uses the brand primary color. Pages do not.
- **Secondary / ghost buttons** → reuse the existing variants; do not invent new ones.
- **Icon buttons** → must have a hover background (typically `hover:bg-gray-50` or the established IconButton hover token). Never ship a bare hoverless icon as a click target.
- All buttons should respect the existing height tokens — don't introduce one-off sizes.

## Inputs

- Mirror the agent detail input: same padding, same border, same focus ring (or lack thereof — check the reference before adding a focus ring), same placeholder color.
- Multi-line: use the agent detail textarea pattern (auto-grow or fixed rows as in reference).
- Don't put a colon at the end of field labels.
- Helper text below the input, in muted gray, single line.

## Dropdowns / selects

- Mirror the agent detail dropdown: same trigger appearance, same menu radius, same item padding, same hover/selected states.
- The menu should not be wider than its trigger unless the content demands it.
- Avoid nested submenus unless an existing dropdown already uses them.

## Cards and surfaces

- Card radius and surface style match the chat composer card. Do not introduce a smaller or larger radius without a reason.
- Borders are subtle (single hairline in the existing border token). No drop shadows unless the chat composer uses one.
- Neutral surfaces on mobile / light gray fills (active pill backgrounds, icon container fills, etc.) → `bg-gray-50`. `gray-100` and `gray-200` have repeatedly been called too dark — start at `gray-50`.

## Focus and interaction

- Don't add custom `:focus-visible` box-shadows or outlines to nav/marketing elements — reuse the hover color shift instead. (Same restraint generally applies inside the platform unless a reference component has an explicit focus ring.)
- Every interactive element (button, icon button, row, link) needs a visible hover state. Test by hovering each one before considering the design done.
- Disabled states use the existing disabled tokens; don't hand-roll a faded color.

## Review checklist

Before declaring a UI ready, walk through:

1. Did I reuse existing components instead of building new ones?
2. Did I match an existing page template / layout?
3. Are inputs visually identical to agent detail inputs?
4. Are dropdowns visually identical to agent detail dropdowns?
5. Do cards match the chat composer radius and surface?
6. Is every label sentence case? Any leftover Title Case or all-caps?
7. Is the copy short and written from the user's seat?
8. Is the page primary the "Add schedule"-style button? Is the brand primary used only inside modals?
9. Does every icon button have a hover background?
10. Did I hover every interactive element in a browser to confirm feedback?

If any answer is "no", fix it before opening the PR.

## When in doubt

- Open the reference component, read its source, and copy the structure.
- If two reference components disagree, prefer the more recently shipped one (check git log).
- If the design genuinely needs a new primitive, raise it with Ming before building it — bundled redesign work belongs in one PR with him as the reviewer.

以下是針對此功能的具體實作提示：

/ui-implement

從修訂版本 04d642bb 開始。新增一個預設關閉的桌面分割版面，包含 68px 的目的地軌道、300px 的對話軌道，以及不變的對話區域。當開關關閉時及在行動裝置上，保留舊的 300px 側邊欄。渲染五個固定插槽，保留使用者定義的順序，並僅在主動拖曳時顯示重新排序的操作提示。在獨立的修補程式、測試和瀏覽器證據確定之前，不要檢視歷史功能或後續的改進。

對於這個導覽功能，我要求 agent 在功能關閉時保留舊側邊欄，開啟時顯示新的三部分版面，保留現有的行動裝置抽屜，並允許使用者重新排序固定的 agent。

在實作過程中，agent 發現了一個重要問題。舊產品記得哪些 agent 被固定，但不記得它們的順序。拖曳互動看起來可能正確，但在重新整理後會重置。

因此 agent 做的不只是繪製拖曳狀態。它讓新的順序持久化，重新整理頁面，並確認順序保持不變。它也確認重新排序的控制點僅在拖曳過程中出現，之後消失。

實作交付成果展示了我需要審查的兩個桌面狀態。我以全寬顯示它們，讓介面保持清晰可讀。行動裝置行為稍後會在逐步說明中以高密度手機截圖呈現。

桌面靜止狀態

主動重新排序

此時我有了一個可運作的功能，而不是另一個設計檔案。但實作仍然不是終點。我需要看到在部署預覽中實際運行的內容。

4. 使用 ui-walkthrough 審查真實產品

產品逐步審查過去很繁瑣。我需要開啟部署預覽、準備正確的帳號、開關功能、點擊每個控制項、調整瀏覽器大小、截圖，並試著記住每張圖片代表哪個狀態。

agent 有內建的 Agent Browser，所以我可以將這項工作交給它。

工作流程有兩個主要步驟：

1. 先列出情境。 agent 將設計和實作聲明轉化為檢查清單。
2. 執行清單並附上證據。 它在部署預覽中執行每個情境，並為每個有意義的狀態回傳 PASS、FAIL 或 BLOCKED 以及截圖。

這個指令如何改變審查方式

• agent 在開始點擊之前先列出情境。
• 它透過內建的 Agent Browser 使用真實部署的元件。
• 它為每個有意義的狀態擷取一張截圖。
• 它將每個檢查點標記為 PASS、FAIL 或 BLOCKED。
• 它絕不用模擬證據掩蓋無法取得的狀態。

這將手動點擊轉化為有組織的審查套件。我可以同時看到預期行為、實際結果和證據。

完整指令如下。我將內部相依性名稱翻譯為「內建 Agent Browser」以便讀者理解；工作流程邏輯其他部分保持不變。

完整原始 ui-walkthrough 指令

# UI Walkthrough

End-to-end visual QA of a vm0/Zero front-end feature in its real per-PR preview. This workflow defines what to verify and how to report the result; it does not define UI-operation tooling.

## Required dependency: built-in Agent Browser

Use the built-in Agent Browser as the single source of truth for every UI interaction, including:

- Discovering and opening the per-PR preview.
- Preview-protection handling and session setup.
- Sign-up, OTP, onboarding, Stripe test checkout, and reaching the live app.
- Enabling feature switches.
- Navigating, interacting with controls, supplying test or mock data, capturing screenshots, uploading artifacts, troubleshooting, and cleanup.

Read and follow the current built-in Agent Browser instructions before taking any UI action. Do not duplicate runtime-specific commands, engine setup, selector mechanics, page-context scripts, session management, or process-cleanup methods in this workflow. If the built-in Agent Browser changes, its current instructions take precedence.

## When to use

- Walk through the UI of a vm0 pull request in its deployed preview.
- Verify an in-app feature that requires authentication, onboarding, billing, feature switches, or a real chat thread.
- Capture faithful screenshots or a short walkthrough video of the feature working in the live application.

## Walkthrough workflow

### 1. Establish the target and scope

- Identify the PR, head commit, changed user-visible behavior, and expected preview.
- Confirm that the deployed preview corresponds to the PR head before testing.
- Read the PR diff and description to derive the critical path and the states that demonstrate the change.
- Do not fix code, resolve conflicts, or change product behavior during a walkthrough unless the user separately requests implementation.

### 2. Reach the feature

Use the built-in Agent Browser to enter the preview and reach the live feature state. Follow its current rules for authentication, onboarding, billing, feature switches, and preview-only bypasses.

If a bypass is used, disclose it in the final report. Never use an onboarding bypass when onboarding itself is under test.

### 3. Define the visual state matrix

Before interacting, list the smallest set of states that proves the feature works. Include the applicable items:

- Initial/default state.
- Open, hover, focus, selected, expanded, or active state.
- Empty and populated states.
- Enabled and disabled states.
- Success, validation, loading, and error states.
- Placement, collision, flip, clipping, and responsive behavior.
- Submission or downstream action when the feature is interactive.

Prefer exercising the actual changed behavior over a generic smoke test.

### 4. Drive the live component

Use the built-in Agent Browser for all interaction and test-data techniques.

Mock or injected content may be used only to place a real application component into a deterministic visual state. The component, styling, and interaction being assessed must remain the live implementation from the PR preview.

For every mocked state:

- Record which content or prerequisite was mocked.
- Distinguish mocked content from real application behavior.
- Never imply that mocked text or data came from a model or production source.
- Exercise the real controls and downstream wiring wherever the environment permits.

### 5. Capture evidence

Use the built-in Agent Browser to capture and upload evidence for the key checkpoints. Each image should prove one meaningful state rather than repeat the same view.

If the user asks for a video, assemble a short captioned walkthrough from the verified checkpoints. Captions should identify the user action and expected result without obscuring the UI.

### 6. Deliver and report

Report:

- PR link, exact preview URL, and tested commit when available.
- Exact user flow exercised.
- Test account when one was created.
- `PASS`, `FAIL`, or `BLOCKED` for each checkpoint.
- Screenshot links and an optional video link with short descriptions.
- Feature switches, bypasses, mock data, and other test-only setup used.
- Failed checks, environment blockers, or verification gaps.

Do not claim the feature is verified unless the live preview flow was exercised and evidence was captured. If the preview is unavailable, report `BLOCKED` with the deployment evidence rather than substituting a local or static replica.

以下是針對此功能的具體逐步審查提示：

/ui-walkthrough

透過內建的 Agent Browser 使用部署預覽作為唯一的瀏覽器真相來源。驗證功能關閉時的側邊欄、68px 和 300px 的分割版面、目的地順序、懸停狀態、五個固定插槽、僅拖曳時顯示的控制點、持久化的重新排序、對話串選取、捲動，以及完整的 iPhone 抽屜。為每個檢查點回傳 PASS、FAIL 或 BLOCKED。不要用複製品替代無法取得的狀態。

對於這個功能，agent 圍繞以下問題組織了逐步審查：

• 功能關閉時，舊側邊欄是否仍然正常運作？
• 功能開啟時，新的桌面結構是否出現？
• 懸停和選取狀態是否清晰可見但不突兀？
• 五個固定的 agent 是否清晰可讀？
• 重新排序控制項是否在拖曳開始前保持隱藏？
• 新的順序在重新整理後是否保留？
• 我是否能選取並捲動瀏覽真實的對話串？
• 現有的行動裝置抽屜是否仍然正常運作？
• 所有導覽目的地是否都存在且順序正確？

agent 接著以新使用者身份開啟部署預覽，完成引導流程，啟用功能，並逐一完成清單。它測試了靜止狀態、懸停狀態、拖曳狀態、重新整理行為、對話串選取、捲動和手機版面。

結果是 11 個 PASS，1 個 FAIL。

這個失敗很有價值。版面和互動都正常運作，但部署預覽只顯示了六個產品目的地。Activity 和 Insights 遺失了，且順序與選定的設計不符。

情境	結果
功能關閉時的舊側邊欄	PASS
新的三部分桌面版面	PASS
懸停和選取狀態	PASS
五個固定的 agent	PASS
僅拖曳時顯示的重新排序引導	PASS
重新整理後儲存的順序	PASS
對話串選取和捲動	PASS
現有的行動裝置抽屜	PASS
目的地內容和順序	FAIL

最終交付成果是一組有組織的截圖，而不是一個未標記圖片的資料夾。桌面截圖為 1440 × 900 像素，手機截圖為 1170 × 2532 像素。它們逐一顯示在下方，讓介面保持清晰可讀；點擊任何圖片即可在不離開文章的情況下放大。

功能關閉

功能啟用

桌面版面

目的地懸停

固定 agent 懸停

主動拖曳

儲存的順序

行動裝置抽屜

這讓我能以有結構的方式審查功能。我可以同時看到預期情境、實際部署結果和證據。如果有任何失敗，我確切知道工作應該回到哪個環節。

如何讓團隊採用這個 AI 產品設計工作流程

完整流程很簡短。團隊成員可以將每個階段儲存為共享的 Zero 工作流程，而不必每次都從記憶中重建流程。

階段	輸入	輸出
ui-design	目前畫面、問題、目標和限制條件	一個推薦方向、九個替代方案，以及選定的設計記錄
ui-implement	選定的設計記錄	可審查的程式碼變更和主要狀態的截圖
ui-walkthrough	已部署的功能及其預期行為	帶有 PASS、FAIL 或 BLOCKED 截圖的有組織情境清單

團隊成員不需要複製我的設計品味。他們需要提供良好的背景脈絡、使用共享的產品系統、在探索後做出明確的選擇，並審查瀏覽器證據。同樣的三個人工檢查點——問題、方向和驗收——也影響著我們如何像管理團隊一樣管理 AI agent。

這個工作流程並不會移除設計實踐或設計思維。它將它們移到最重要的地方：定義問題、設定限制條件、比較方向、選擇取捨，以及判斷運行中的產品。

當元件系統成熟後，我不再需要在 Figma 中將每個功能重建為可拖曳的積木。我可以直接在產品中與 agent 合作，同時設計系統保持輸出的一致性，逐步審查則確保結果的真實性。

常見問題

如何建立 AI 產品設計工作流程？

從現有的產品系統開始，而不是空白的提示語。將工作分為探索、實作和審查三個階段。讓 agent 產生選項並執行可重複的檢查，但讓產品設計師負責問題定義、選定方向和最終驗收。

產品設計師可以不用 Figma 工作嗎？

可以，當產品已有穩定的元件、頁面範本和互動模式時。Figma 在建立新視覺語言或不熟悉的互動時仍然有用。重點不是禁止使用 Figma，而是避免在第二個畫布上重建已知的產品決策。

AI 正在取代產品設計師嗎？

在這個工作流程中並非如此。agent 組裝選項、編輯程式碼並檢查情境。設計師仍然負責定義問題、設定限制條件、比較取捨、選擇方向，以及決定運行中的產品是否足夠好到可以上線。