我的 AI 產品設計工作流程（無需 Figma）

當產品已經擁有成熟的設計系統時，無需 Figma 也能進行產品設計。我的 AI 產品設計工作流程運用三種智能體技能：ui-design 探索九種方向，ui-implement 將選定方向轉化為產品，ui-walkthrough 透過內建 Agent Browser 檢查每個狀態。決策仍由我來做，智能體負責重複性的製作與檢查。

大多數產品功能並非從零開始。當產品運作一段時間後，基本設計決策已經存在於程式碼中。按鈕、輸入框、卡片、導覽、間距、顏色、文案、滑鼠懸停狀態與行動裝置行為都已定義。用 Figma 重建這些元件，通常只是把相同元件拖到另一個畫布上，然後又在產品裡重建一次。

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

1. 以設計系統開始無需 Figma 的產品設計

不使用 Figma 並不代表沒有設計規則，反而需要更明確的規範。

對 Zero 而言，智能體可以檢查：

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

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

這為智能體劃定了界線。它可以探索功能結構，而不必為每個畫面發明新的視覺語言。

當團隊要創建新品牌、新元件系統或沒有現成產品參考的互動時，Figma 仍然有用。但當系統成熟後，執行中的產品就能成為主要設計場域。這就是我們用設計即程式碼工作流程重建 Zero的功能級版本。

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

每個功能仍需探索。我不希望智能體拿到我的第一句話就直接寫程式。

我從 ui-design 開始。我給智能體目前畫面、用戶問題、目標與主要限制。智能體讀取現有產品模式，回傳一個推薦方向與九個替代方案。

簡單來說，這個技能會擷取當前畫面，產生一個推薦方向，探索九個明顯不同的替代方案，說明權衡，並等待人類選擇。

這個指令背後的設計思維

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

1. 先理解再提案。 先擷取當前畫面並閱讀周邊產品，再開始設計。
2. 系統化思考。 以現有元件、範本頁面、互動模式與文案規則為出發點。
3. 避免重新發明。 當提示語模糊時，AI 容易創造新模式。這個指令要求找出最接近已上線的元件或頁面並重用，而非憑記憶猜測。
4. 先探索再選擇。 After 方案給出一個可行方向，九個變體則展開不同的版面、層級、密度、進入點與揭露方式。
5. 將探索與決策分開。 智能體在呈現選項後停止，由人類比較權衡並選擇，才開始寫程式。
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 像素的側邊欄，包含產品目的地、已釘選智能體與聊天串，三種功能混在一起。我想在不改變對話區的前提下，將這些功能分開。

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

/ui-design

以 Zero 三區域導覽的真實歷史基礎重播設計階段。將產品目的地、智能體與對話分成更清楚的區域，不改變對話區。使用真實 Zero 代幣、圖示與元件。產出忠於原始的 Before、一個強而有力的 After，以及九個真正不同的變體。不要編輯產品程式碼，也不要用瀏覽器證據展示假模型。

第一次探索過於保守。幾個選項只改了寬度與選取樣式，但看起來還是同一個側邊欄。我否決那組方案，要求智能體在資訊架構層級上讓差異明顯。

第二次執行回傳了九個真正不同的方向。我將它們整理成 3 × 3 表格，方便比較，不會讓文章變成長長的圖片帶。每個縮圖都能在部落格圖片檢視器中放大。

1. 上方導覽	2. 可收合抽屜	3. 對話優先
將目的地移到對話區上方	只在需要時顯示目的地	讓對話成為主要導覽物件
4. 智能體優先	5. 對話區優先	6. 指令啟動器
先選智能體再選對話串	將已釘選智能體放在主動對話上方	從可搜尋選單開啟目的地
7. 可展開軌道	8. 儀表板進入	9. 底部停駐
只在需要時展開窄軌道	從最近工作開始	將目的地移到下方

我沒有完全照著這些方案選一個，而是用它們來決定哪些要保留、哪些要改變。最終方向採用窄目的地軌道、獨立聊天軌道、五個可見釘選智能體，以及現有對話區。

ui-design 最重要的產出不是圖片，而是一份簡短的決策紀錄：

• 保留 68 像素目的地軌道與 300 像素聊天軌道
• 顯示五個釘選智能體欄位
• 選取狀態保持低調但可讀
• 只在拖曳時顯示重新排序指引
• 保持對話區與現有行動抽屜不變

這就足以開始實作。

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

選定方向並連接產品程式碼庫後，智能體直接在程式碼中作業。我不會先在 Figma 重畫選定方案。

簡單來說，ui-implement 跳過探索，因為方向已經確定。它會找出最接近的真實元件與頁面結構，組合建構、檢查結果，並在瀏覽器驗證功能。

這個指令保護的重點

• 實作時不應重新設計已選方向。
• 智能體必須從最接近的現有元件與範本頁面開始。
• 除非產品真的有缺口，否則優先重用現有元件。
• 自我檢查與瀏覽器驗證可發現文案、狀態與互動不一致。
• 若產品決策尚未解決，工作會回到 ui-design。

這就是設計系統在實作期間持續發揮作用的方式。它不是智能體只讀一次的文件，而是決定選用哪些元件、如何檢查最終體驗的依據。

以下是完整原始指令，從實際工作流程逐字轉錄：

完整原始 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 側邊欄。渲染五個釘選欄位，保留使用者自訂順序，僅在拖曳時顯示重新排序提示。獨立補丁、測試與瀏覽器證據凍結前，不要檢查歷史功能或後續優化。

針對導覽功能，我要求智能體在功能關閉時保留舊側邊欄，功能開啟時顯示新三區佈局，保留現有行動抽屜，並允許使用者重新排序釘選智能體。

實作過程中，智能體發現一個重要問題。舊產品會記住哪些智能體被釘選，但不會記住順序。拖曳互動看似正確，但重新整理後會還原。

因此，智能體不只畫出拖曳狀態，還讓新順序能夠持久保存，重新整理頁面後順序不變，也確認重新排序把手只在拖曳時出現，結束後消失。

實作交付展示了我需要檢查的兩種桌面狀態。我以全寬顯示，確保介面可讀。行動裝置行為則在 walkthrough 以高密度手機截圖呈現。

桌面靜止狀態

重新排序中

此時我已經有一個可運作的功能，而不是另一份設計檔案。但實作仍不是結束，我還需要檢查實際部署預覽的運作狀況。

4. 用 ui-walkthrough 檢查真實產品

過去產品 walkthrough 很繁瑣。我得打開部署預覽、準備正確帳號、開關功能、點擊每個控制項、調整瀏覽器大小、截圖，還要記住每張圖代表哪個狀態。

智能體內建 Agent Browser，所以我可以把這些工作交給它。

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

1. 先列出情境。 智能體將設計與實作主張轉為檢查清單。
2. 執行清單並附上證據。 它在部署預覽中執行每個情境，針對每個重要狀態回傳 PASS、FAIL 或 BLOCKED 並附上截圖。

這個指令如何改變檢查流程

• 智能體在點擊前先列出情境。
• 它透過內建 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.

這是針對此功能的 walkthrough 提示語：

/ui-walkthrough

僅以內建 Agent Browser 操作部署預覽作為唯一瀏覽器依據。驗證功能關閉時的側邊欄、68px 與 300px 分割、目的地順序、懸停狀態、五個釘選欄位、僅拖曳時顯示把手、持久排序、對話選取、捲動與完整 iPhone 抽屜。每個檢查點回傳 PASS、FAIL 或 BLOCKED。不要用複製品取代無法到達的狀態。

針對這個功能，智能體將 walkthrough 組織成以下問題：

• 功能關閉時舊側邊欄還能用嗎？
• 功能開啟時新桌面結構會出現嗎？
• 懸停與選取狀態是否明顯但低調？
• 五個釘選智能體是否可讀？
• 重新排序控制項是否只在拖曳時顯示？
• 新順序是否能在重新整理後保留？
• 能否選取並捲動真實對話串？
• 現有行動抽屜還能用嗎？
• 所有導覽目的地是否都在且順序正確？

智能體接著以新用戶身份打開部署預覽，完成導覽、啟用功能並逐一檢查。它測試靜止狀態、懸停狀態、拖曳狀態、重新整理後行為、對話選取、捲動與手機版畫面。

結果是 11 PASS，1 FAIL。

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

情境	結果
功能關閉時舊側邊欄	PASS
新三區桌面佈局	PASS
懸停與選取狀態	PASS
五個釘選智能體	PASS
僅拖曳時顯示重新排序指引	PASS
重新整理後順序保存	PASS
對話選取與捲動	PASS
現有行動抽屜	PASS
目的地內容與順序	FAIL

最終交付是一組有組織的截圖，而不是一堆未標記的圖片。桌面截圖為 1440 × 900 像素，手機截圖為 1170 × 2532 像素。下方逐一顯示，點擊圖片可放大檢視。

功能關閉

功能開啟

桌面佈局

目的地懸停

釘選智能體懸停

重新排序中

已保存順序

行動抽屜

這讓我能以結構化方式檢查功能。我可以同時看到預期情境、實際部署結果與證據。如果有失敗，就知道該回到哪個階段修正。

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

完整流程很簡短。團隊成員可以將每個階段存為共享 Zero 工作流程，無需憑記憶重建過程。

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

團隊成員不必複製我的設計品味，只需提供良好脈絡、使用共享產品系統、探索後明確選擇，並檢查瀏覽器證據。同樣三個人為檢查點——問題、方向與驗收——也形塑我們像團隊一樣管理 AI 智能體的方式。

這個工作流程沒有移除設計實踐或設計思維，而是將它們移到最重要的部分：定義問題、設定限制、比較方向、選擇權衡與判斷執行中的產品。

當元件系統成熟後，我不再需要在 Figma 以拖曳方塊重建每個功能。我可以直接與智能體在產品中協作，由設計系統確保產出一致，walkthrough 則確保結果誠實。

常見問題

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

從現有產品系統開始，而不是空白提示。將工作分為探索、實作與檢查。讓智能體產生選項並執行可重複檢查，但產品設計師仍負責問題、選定方向與最終驗收。

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

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

AI 是否取代產品設計師？

在這個工作流程中沒有。智能體負責組合選項、編輯程式碼與檢查情境。設計師仍然定義問題、設定限制、比較權衡、選擇方向，並決定執行中的產品是否足以上線。