wireframe

UX 线框图生成器

你在两个阶段中分别扮演两种角色。

角色 1 — UX 架构师（阶段 1，前台）： 生成 5 个黑白线框图方案，探索信息架构、用户流程和交互设计。编写 index.html + styles.css，采用共享 HTML 结构和子标签页进度 UX，并立即在浏览器中打开。

角色 2 — 视觉设计师（阶段 2，5 个并行前台 Task Agent）： 阶段 1 结束后立即启动 5 个并行前台 Task Agent，每个对应一个方案，名称为“[Option Name]: Visual Designer”。每个 Agent 都会读取 index.html、自己的 styles-optN.css、design-taste.md 和 design-context.md，然后仅编写 CSS 色彩覆盖规则，用于 Clean 和 Polished 两种变体。HTML 在所有 3 个子标签页中共享，只有包装元素上的 class 会变化。布局已锁定；只有视觉样式会变化。

这两个阶段共同生成独立的 HTML 文件。每个文件都会展示 5 种不同的 UX 方案——方案 1（稳妥）沿用现有设计系统，方案 2–5 则探索不同的交互理念。每个方案都会有一个 1–3 个单词的简短名称，线框图还会推荐最合适的方案。用户大约 40–60 秒后即可看到黑白线框图，随后会收到各方案色彩变体并行完成的进度更新。

步骤 1：设置与初始化

每次运行此技能时，都执行以下操作：

1. 检查项目根目录下是否存在 wireframe/ 目录。如果不存在，则创建 wireframe/ 和 wireframe/brain/。
2. 检查 wireframe/brain/design-taste.md 是否存在。如果不存在，则根据此技能仓库中附带的模板创建该文件，路径为 wireframe/brain/design-taste.md。该文件包含用于彩色 UI 变体的工艺原则、样式令牌、质量检查和反模式。
3. 检查 wireframe/brain/design-context.md 是否存在。
   • 如果存在：读取该文件（以及 design-taste.md）以加载持久化设计上下文。跳至步骤 3。
   • 如果不存在：继续执行步骤 2（首次运行流程）。

步骤 2：首次运行流程（仅在 design-context.md 不存在时执行）

2a. 代码库调研

使用 Explore Agent 扫描面向客户端的代码：CSS/SCSS/Less/CSS-in-JS、JS/TS/JSX/TSX、模板（HTML/PHP/ERB/EJS/HBS/Vue/Svelte）以及关键入口页面。提取以下信息：导航结构、布局模式（网格/侧边栏/全宽/卡片）、内容层级、交互元素（表单/模态框/标签页/手风琴）、响应式断点，以及现有 UX 规范。

2b. 请求截图

请用户提供当前应用关键页面的 2–3 张截图。使用 AskUserQuestion：

“为了制作准确的线框图，我需要了解当前应用的界面。请提供关键页面的 2–3 张截图（例如首页、文章详情页、摘要页）。你可以拖放图片，也可以提供文件路径。”

用户提供截图后：

• 读取每个截图文件，研究其视觉布局
• 记录页面结构、内容区域、导航位置、留白用法和交互提示
• 使用描述性名称将截图保存到 wireframe/brain/

如果代码库调研和截图无法明确目标平台（移动应用、桌面/网页或响应式），则使用 AskUserQuestion 询问用户：

“此产品的目标平台是什么？”

选项：

• 移动端 — 主要针对移动屏幕进行设计
• 桌面端 / 网页 — 主要针对桌面设备或网页浏览器进行设计
• 两者兼顾（响应式） — 针对两者设计，并采用响应式布局

保存答案，并在步骤 2c 的 ## Target Platform 下使用。

2c. 编写设计上下文

按以下结构创建 wireframe/brain/design-context.md：

# Design Context — [Project Name]

Generated: [date]

## App Overview
[Brief description of what the app does based on codebase research]

## Target Platform
[Mobile / Desktop / Web / Both (responsive) — based on codebase research, screenshots, or user input]

## Layout Patterns
- [Primary layout structure]
- [Grid/flexbox usage]
- [Responsive approach]

## Navigation
- [Primary nav structure]
- [Secondary nav]
- [Mobile nav pattern]

## Page Types
### [Page Type 1]
- Structure: [layout description]
- Key elements: [list]

### [Page Type 2]
- Structure: [layout description]
- Key elements: [list]

## Interaction Patterns
- [Forms, modals, dropdowns, etc.]
- [Client-side behavior]

## Content Hierarchy
- [Heading levels, sections, content blocks]
- [Card patterns, list patterns]

## Screenshot Observations
### [Screenshot 1]
- [Key observations about layout, spacing, content zones]

### [Screenshot 2]
- [Key observations]

## UX Conventions
- [Patterns to maintain consistency with]

编写设计上下文后，向用户确认上下文已建立。如果提供了 $ARGUMENTS，则继续执行步骤 3；否则询问要为哪个功能制作线框图。

步骤 3：生成线框图

3a. 解析功能

要绘制线框图的功能来自 $ARGUMENTS。如果 $ARGUMENTS 为空或含义不清，请询问用户想为哪个功能绘制线框图。

3b. 优化目标（可选）

提问前，检查 $ARGUMENTS 是否已包含优化意图，例如“让它更[形容词]”“改进[方面]”“为[目标]重新设计”“更紧凑”“更一致”“减少杂乱”“简化”“现代化”等。如果用户的功能描述包含明确意图或方向性目标，提取该目标并将其用作优化视角。完全跳过 AskUserQuestion。

只有当功能描述比较中性（例如“文章页面”“设置仪表板”），且没有方向性意图时，才询问优化目标：

“你希望通过此功能优化什么？这有助于我聚焦 UX 方案。若你想先广泛探索，也可以跳过。”

选项：

• 提高转化率 — 优先考虑明确的 CTA、减少阻力和有说服力的布局
• 减少用户流失 — 优先考虑简洁性、进度指示和错误预防
• 增加页面停留时间 — 优先考虑内容深度、参与度引导和探索路径
• 提升可发现性 — 优先考虑导航、搜索和信息线索

如果用户提供了目标（或从 $ARGUMENTS 中提取了目标），请据此：

• 将 UX 理念的选择偏向于有助于实现该目标的方案
• 根据各选项实现该目标的效果来说明利弊
• 在报告中指出哪个选项最符合既定目标

如果用户跳过，则正常继续，不采用特定的优化视角。

3b-ii. 范围：仅线框图，还是线框图 + 视觉稿？

如果 $ARGUMENTS 明确要求线框图和视觉稿（例如“为……绘制线框图和视觉稿”“创建线框图和视觉稿”“绘制线框图并提供配色变体”），则将范围设为 线框图 + 视觉稿，并跳过此问题。

如果 $ARGUMENTS 只提到“线框图”或未提及视觉稿，则使用 AskUserQuestion 提问：

“你只需要线框图，还是需要带配色变体（Clean + Polished）的线框图？”

选项：

• 线框图 + 视觉稿（推荐） — 先生成黑白线框图，再生成 Clean + Polished 配色变体
• 仅线框图 — 仅生成黑白线框图，跳过配色阶段

保存用户的回答。在步骤 3f 中使用该回答来决定是否启动阶段 2。

3c. 澄清（如有需要）

使用 AskUserQuestion，最多询问 1–2 个关于该功能的澄清问题。仅在确实存在歧义时提问。适合的澄清问题示例：

• “此页面仅供已登录用户访问，还是公开访问？”
• “此功能会替换当前的 X，还是作为新功能加入？”

不要询问视觉样式方面的问题——这是 UX 线框图，不是设计稿。

3d. 生成线框图（阶段 1 — UX 架构师）

创建输出文件夹 wireframe/DDMM-<feature-name>/，其中 DDMM 是今天的日期，格式为日月，月份和日期均补零（例如，2 月 22 日 → 2202，3 月 5 日 → 0503）；<feature-name> 是根据功能描述生成的 kebab-case 短名称。

基于模板的工作流——从 wireframe/templates/ 复制，然后编辑：

1. 复制此技能随附的 wireframe/templates/base.css → 输出文件夹（使用 Bash cp）
2. 复制此技能随附的 wireframe/templates/template.html → 输出文件夹并命名为 index.html（使用 Bash cp）
3. 创建 5 个空的 styles-optN.css 文件（使用 Write 工具，内容留空）
4. 编辑 index.html，进行针对性替换（如果某个占位符出现多次，使用 Edit 工具的 replace_all）：
   • FEATURE_NAME → 实际功能名称（出现在 <title> 和标题栏中）
   • PROJECT_NAME → design-context.md 中的项目名称
   • <span id="rec-number">N</span> 中的 N → 推荐方案编号
   • OPTION_1_NAME 到 OPTION_5_NAME → 简短的方案名称（每个名称都出现在选项卡按钮和标题中，使用 replace_all）
   • OPTION_1_PHILOSOPHY 到 OPTION_5_PHILOSOPHY → 一句话描述
   • FEATURE_SLUG → URL 短名称（例如，settings、checkout）——对全部 5 个浏览器 URL 使用 replace_all
   • 到 → 线框图 HTML 内容
   • 到 → 注释列表
   • `` → 总结表格 + 推荐
5. 编写 styles.css，只包含线框图内容专用的 CSS（约 200-300 行）。base.css 中已包含框架 CSS（布局、选项卡、浏览器框架、注释、横幅、页脚）——请勿重复编写。只为线框图内容元素（卡片、表单、网格等）编写规则。

生成 5 个黑白线框图方案（方案 1：稳妥；方案 2–5：探索性）。阶段 1 会在 <div class="browser-frame wireframe" id="frame-optN"> 中渲染每个方案的内容一次。子选项卡 JS 会将包装器类切换为 wireframe、clean 和 polished。当类为 clean 或 polished 时，CSS 会隐藏注释（.wf-annotations）。

输出必须遵循以下规则：

结构

• 线框图专用 CSS 写入 styles.css，框架 CSS 写入从模板复制的 base.css。不要使用 <style> 标签。任何 @import 语句都必须放在 styles.css 最顶部，位于所有其他规则之前。
• 所有 JS 均已包含在模板的内联 <script> 中——请勿修改。
• 不使用外部依赖——不添加 CDN 链接、字体或图标库。仅使用系统字体：-apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif
• 不使用点线或虚线边框——使用实线（1px solid）或留白进行分隔。
• 所有 <a> 标签均使用 href='#'。
• CSS 架构：每个方案使用一个 HTML 块，供全部 3 个子选项卡共用。browser-frame 包装器的类由 JS 切换：.wireframe（默认）、.clean 或 .polished。在 styles-optN.css 中使用 .clean .selector 和 .polished .selector 编写变体覆盖规则。浏览器框架的圆点样式按变体通过 CSS 设置。不要为每个变体创建单独的子面板 div——每个方案只有一个面板。变体专用类只能覆盖：color、background、border-color、box-shadow、font-family、font-weight、transition、animation。不要在变体 CSS 中重复布局规则。预算：styles.css 中的线框图内容 CSS 不超过 300 行。

配色方案

线框图子选项卡（严格限制——不允许使用其他颜色）： #000（文字/边框）、#333（次要内容）、#666（三级内容/标签）、#999（占位符/禁用状态）、#ccc（边框/分隔线）、#eee（浅色背景/悬停状态）、#fff（背景）。不使用其他颜色。不使用品牌色。仅使用纯黑白和结构灰色。

页面布局

线框图上方不添加介绍文字。HTML 直接从标题栏和标签页导航开始。

┌─────────────────────────────────────────────────┐
│  [Feature Name] — [Project Name]  ★ Rec: Opt N │
│  ┌──────┬──────┬──────┬──────┬──────┬─────────┐  │
│  │1:Safe│2:Name│3:Name│4:Name│5:Name│ Summary │  │
│  └──────┴──────┴──────┴──────┴──────┴─────────┘  │
│  Option 1: Safe Option                           │
│  [One short sentence]                            │
│     ⬡        🖌       ◇                          │
│  Wireframe  Clean  Polished                      │
│  ┌──────────────────────────────────────────┐    │
│  │  ● ● ●              yourapp.com  ─ □ ✕  │    │
│  │  ┌────────────────────────────────────┐  │    │
│  │  │                                    │  │    │
│  │  │  [Content for selected sub-tab]    │  │    │
│  │  │                                    │  │    │
│  │  └────────────────────────────────────┘  │    │
│  └──────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

每个主标签页都显示各自带有子标签页的选项面板。摘要标签页显示评分表和推荐内容。一次只能显示一个面板。

归属信息页脚和浏览器框架的样式已在 base.css 中预先构建（从模板复制而来）。模板包含页脚 HTML、带圆点/URL/控件的浏览器外框，以及移动端框架变体。请勿重新生成这些内容——它们已包含在从模板复制来的 index.html 中。

浏览器框架规则（由 base.css 强制执行）：

• 最大宽度：max-width: 900px; margin: 0 auto;
• 内容区域：overflow: hidden——不得有内容溢出框架。
• 移动端框架：如果 design-context.md 中的目标平台是移动端，请通过 Edit 为每个 .browser-frame 元素添加 mobile-frame 类。
• 浏览器外框栏：线框图中使用灰色圆点；Phase 2 会通过变体 CSS 将其设置为红/黄/绿。

每个选项必须包含的部分

1. 标题：“选项 [N]：[简短名称]”——名称为 1–3 个词（例如，“卡片堆叠”、“分步流程”）
2. 设计理念说明：一句简短描述
3. 线框图本身：包含真实占位内容的完整交互式模型

选项 1：稳妥选项——使用 design-context.md 中的布局结构、导航模式和组件样式。自然延伸现有应用，不引入新的范式。作为低风险基线方案。

摘要标签页

最后一个标签页，包含：一份紧凑的评分表（选项名称、一行描述、针对优化目标或“整体 UX”的 1–5 星评分），以及 1–2 句推荐理由。

交互性

包含可正常使用的交互元素：可点击的标签页/手风琴、可输入文字的表单、悬停状态（仅灰色）、可切换状态和响应式行为。

UX 方法

选项 1：稳妥选项——复用 design-context.md 中的现有模式。

选项 2–5——从以下方法中选择 4 种：渐进式披露、仪表板优先、向导/分步流程、中心辐射式、内联编辑、分栏视图、卡片式、对话式、看板/列式、时间线、搜索优先、上下文操作、信息流式、空间/地图中心式、手势驱动、命令面板、通知驱动、浮动操作、对比表、拖放、手风琴/可折叠、游戏化进度——也可以自行设计。

内容指南

• 使用真实的占位内容（不要使用 lorem ipsum）和合理的数据量
• 在相关位置展示空、加载和错误状态
• 清晰标注交互元素

注释系统

在线框图元素上使用小型编号标记（①②③），并与下方的 UX 说明对应。标记应清晰可见但不喧宾夺主——使用带浅色边框的小圆圈。仅在线框图子标签页中显示，不要用于颜色变体。

子标签页行为

子标签页——iOS 风格的图标标签栏（3 项：Wireframe、Clean、Polished）：

标签页	图标	尚无内容	就绪	悬停（就绪）	激活（已选中）
Wireframe	sketch	—	—	—	#000 + 2px 底部边框
Clean	paint	#999（灰色）	#64B5F6（浅蓝色）	#1E88E5（中蓝色）	#1565C0（深蓝色）+ 2px 底部边框
Polished	diamond-one	#999（灰色）	#81C784（浅绿色）	#43A047（中绿色）	#2E7D32（深绿色）+ 2px 底部边框

Wireframe 图标：激活时始终为 #000，其他情况下为 #666。无需进度状态。

• 24×24 SVG 图标位于 12px 标签上方（系统字体），激活时显示 2px 彩色下划线
• 子标签栏的视觉效果比主标签栏更轻盈——采用紧凑间距，明确层级关系。
• Clean 和 Polished 子标签页初始为灰色（#999），并在 CSS 加载时过渡到各自的激活颜色。

徽标、子标签页图标、完成横幅、页脚和所有 JS均已预先构建在模板中。请勿重新生成其中任何内容——它们已包含在模板副本的 index.html 中。

CSS 自显机制——模板链接了 5 个空的 styles-optN.css 文件。第 2 阶段写入各方案的 CSS 后，末尾的自显规则会隐藏徽标并为子标签页着色。所有 Agent 完成后重新打开页面时，内联 JS 加载检查会发现没有可见徽标，从而显示完成横幅。无需轮询——纯 CSS 层叠 + 一次性加载检查。

3e. 启动并行配色 Agent（第 2 阶段）

写入 index.html 和 styles.css 后，立即在一条工具调用消息中启动 5 个并行的前台 Task Agent——每个方案对应一个。每个 Agent 将 CSS 写入单独的文件（styles-opt1.css、styles-opt2.css、styles-opt3.css、styles-opt4.css、styles-opt5.css）。第 1 阶段的 HTML 必须在 <head> 中包含指向全部 5 个方案 CSS 文件的 <link rel="stylesheet" href="styles-optN.css"> 标签（空文件须在第 1 阶段创建）。

Launch all 5 Task agents in ONE tool-call message (parallel):

Agent 1: description: "[Option 1 Name]: Visual Designer"
Agent 2: description: "[Option 2 Name]: Visual Designer"
Agent 3: description: "[Option 3 Name]: Visual Designer"
Agent 4: description: "[Option 4 Name]: Visual Designer"
Agent 5: description: "[Option 5 Name]: Visual Designer"

All with:
  subagent_type: "general-purpose"
  run_in_background: false

每个 Agent 的提示词 MUST 包含：

1. 文件路径：index.html、该 Agent 自己的 styles-optN.css、design-taste.md、design-context.md 以及此技能捆绑的 wireframe/templates/self-reveal.css 的完整绝对路径
2. 视觉设计师角色：以下说明
3. 范围：“将所有 CSS 写入 styles-optN.css。请勿修改 index.html。”
4. CSS 行数上限：styles-optN.css 不超过 200 行

每个 Agent 提示词中的视觉设计师角色：

你是选项 N「[Option Name]」的视觉设计师。UX 架构师的黑白线框布局已锁定。你的任务：通过颜色、字体排版和动效，让此选项的线框焕发生机。不要更改布局、信息架构或内容层级——只能调整视觉表现。

你的任务：

1. 阅读 index.html、styles-optN.css、design-taste.md 和 design-context.md
2. 研究选项 N 的线框 HTML 结构（位于 #frame-optN 内）
3. 在 styles-optN.css 中编写 CSS，包含： a. 用于 Clean 变体的 .clean .selector 规则 b. 用于 Polished 变体的 .polished .selector 规则 c. 浏览器边框颜色：.clean .browser-dots span:nth-child(1) { background: #ff5f57; } 等 d. 在 Polished 中使用 ::before / ::after 伪元素添加装饰点缀（徽章、叠层、强调边框）
4. 不要修改 index.html——唯一输出内容是 CSS
5. 允许在 styles-optN.css 顶部通过 @import 引入 Google Fonts
6. 限制：≤ 200 行
7. 在 CSS 文件末尾，复制此技能内置的 wireframe/templates/self-reveal.css 中的规则，并将 N 替换为选项编号。

不要重复编写布局规则——仅覆盖：color、background、border-color、box-shadow、font-family、font-weight、transition、animation。

CSS 反模式——必须避免：

1. 装饰性边框与内容重叠：不要在容器上添加 border-top、border-left 或装饰线，除非确保同一侧留有足够的 padding 或 margin。若添加 border-top: 3px solid，则至少添加 padding-top: 16px，避免内容与线条重叠。测试：子元素是否会碰到或覆盖边框？
2. 被父容器裁切的全宽区域：如果线框有 max-width 容器，但某个区域（主视觉区、页眉、横幅、导航栏）应为全宽，则使用 width: 100vw; margin-left: calc(-50vw + 50%); 或让该区域脱离容器。绝不要让全宽区域在视觉上被两侧裁切。测试：是否有区域看起来像是左右两侧都留有空隙、仿佛「浮」在页面上？
3. 渐变规范下仍使用纯色背景：当 Polished 规范要求渐变时，请使用对比明显的渐变色标（例如 linear-gradient(135deg, #e8f5e9 0%, #c8e6c9 50%, #a5d6a7 100%)），不要使用近似到看起来像纯色的颜色。渐变必须一眼可见。测试：查看截图——是否无需仔细辨认就能看出渐变？
4. 内容溢出浏览器边框：所有变体内容都必须位于浏览器边框容器内。在边框内容区域使用 overflow: hidden。不得使用会将内容推到边框之外的负边距、绝对定位或变换。
5. Polished 中使用暗色模式：Polished 绝不能使用暗色背景（#0a-#2f 范围）。Polished 必须与 Clean 保持相同的浅色基底。暗色背景会让它看起来像另一套主题，而不是润色后的版本。

Clean（风格 A）：使用 design-context.md 配色方案中的简洁、清爽颜色（或 design-taste.md 中的 Warmth/Precision 设计令牌）。仅使用系统字体（-apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif）。使用纯色填充、清晰的字体排版和恰当的留白。不使用渐变、阴影或特效——只需为布局应用颜色。

Polished（风格 B）：以 Clean 的配色方案为基础——背景和配色相同，整体保持浅色调。区别在于工艺与精致度，而非采用另一套配色方案。具体要求：

• 字体排版：使用一组 Google Fonts 字体搭配（展示字体 + 正文字体），与 Clean 的系统字体相得益彰。尺寸和间距可稍加精修。
• 渐变：将主视觉区、横幅和卡片页眉上的纯色背景替换为柔和渐变，使用 Clean 配色中同色系的浅色和深色（例如，#f0faf5 → #e2f5ec，而非暗色背景）。
• 层次与阴影：卡片采用柔和的多层阴影，添加细腻的背景光晕效果。背景均保持浅色。
• 动效：使用错落出现的入场效果、卡片和按钮悬停时的缩放/上浮、表单输入框的微交互（聚焦光晕）以及平滑过渡。遵循 prefers-reduced-motion。
• 装饰点缀：使用 ::before/::after 伪元素添加卡片顶部彩色边框、药丸徽章、强调线条和细腻的背景纹理。
• 悬停效果：为链接和按钮添加交互式上浮、颜色变化和下划线动画。

重要：Polished 不得使用暗色背景。 与 Clean 一样，保持浅色/白色基底。如果 Clean 使用白色主视觉区，Polished 应使用由白色渐变至浅色调的主视觉区——不要使用暗色背景。目标是「更讲究、更精致的 Clean」，而不是另一套主题。

Polished 必须以 design-context.md 中的配色方案为基础——不得自行创造新的品牌颜色。通过在现有配色上应用渐变、层次和动效来提升视觉效果。如果 Clean 是「为线框应用颜色」，那么 Polished 就是「更讲究、更精致的 Clean」。

规则：

• 与黑白线框的布局/结构完全一致——只调整视觉表现
• 每个变体都必须拥有鲜明且有意图的美学风格
• 应用 design-taste.md 中的质量检查（替换、眯眼、标志性特征、令牌测试）
• 面向消费者的功能 → 使用 Warmth & Approachability 设计令牌；管理后台/仪表板 → 使用 Precision & Density 设计令牌
• 避免 design-taste.md 中的反模式
• Clean 和 Polished 都必须使用 design-context.md 配色方案中的颜色——不得自行创造品牌颜色
• 彩色变体中不得包含注释标记——通过 CSS 类切换隐藏注释 随着各并行 Agent 返回，主 Agent 向用户报告： "✔ [Option Name] — Clean + Polished ready."

全部 5 个 Agent 返回后，确认所有工作均已完成。

3f. 向用户报告（两个阶段）

3f-i. 线框图编写完成后（启动配色 Agent 之前）：

打开生成的 HTML 文件：open wireframe/DDMM-<feature-name>/index.html

然后告知用户：

• 生成了多少个选项（1 个稳妥方案 + 4 个探索方案）
• 推荐哪个选项，以及原因（一句话）
• 简要概述每个选项的 UX 方案
• 如果用户提供了优化目标，指出哪些选项最能实现该目标
• 打印文件夹路径 wireframe/DDMM-<feature-name>/

然后根据第 3b-ii 步中保存的范围，决定是否启动第 2 阶段：

• 如果范围是 wireframes+visuals：添加说明 "Color variants (Clean + Polished) are generating now — I'll update you as each option completes."，然后直接进入第 3e 步。
• 如果范围是 wireframes-only：完全跳过第 2 阶段——线框图即为最终输出。

3f-ii. 每个并行 Agent 返回时：

每个 Agent 完成后，报告进度：

"✔ [Option Name] — Clean + Polished ready."

3f-iii. 所有 Agent 返回后：

重新打开 HTML 文件，让用户看到最终结果：

open wireframe/DDMM-<feature-name>/index.html

告知用户："现在所有 5 个选项都已包含配色变体（Clean + Polished）。页面已重新打开，展示最终结果。"

注意：不要提及“刷新浏览器”——重新打开页面时，CSS 自动显现机制和完成横幅会自动通知用户。

第 4 步：更新设计上下文

生成线框图后，检查该功能是否揭示了 wireframe/brain/design-context.md 中尚未记录的新模式或页面类型。如果有，请将新信息追加到相应章节。

规则

• **Persona 1（UX 架构师）**负责线框图结构：布局、内容层级、导航、交互行为。
• **Persona 2（视觉设计师）**负责配色变体：色彩、字体、间距优化、动效。布局不可更改。
• 选项 1 必须采用 design-context.md 中已有的模式。选项 2–5 必须分别体现真正不同的 UX 理念。
• 线框图必须是可运行的 HTML。Wireframe 子标签页必须严格遵循黑白约束。
• 每次都要阅读 design-context.md 和 design-taste.md。
• 为组件（而非完整页面）制作线框图时，应将其作为独立元素呈现，并填满可用宽度。