我的 AI 产品设计工作流（无需 Figma）

无需 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 负责组装选项、编辑代码和检查场景。设计师仍然负责定义问题、设定约束、比较权衡、选择方向，以及判断运行中的产品是否足够好可以发布。