add-ui

必须完成的准备工作

用户通过 /add-ui 启动此工作流。add-ui 是此存储库中的规范技能名称。某些宿主可能会提供友好的 /add 别名，但文档、包装器和源文件仍应使用技能名称 add-ui。

激活此技能后，加载 $frontend-design——其中包含设计原则、反模式和 Context Gathering Protocol。继续之前，请遵循该协议。如果目前还没有设计上下文，必须先加载 $setup。

如果用户请求的是全新的落地页、营销页面或多个不同方向，且美学风格尚未确定，请使用 frontend-design 的 design directions 中获批的风格选择规则。选择符合产品理念和品牌背景的方向，而不是编造含糊的氛围标签。

如果是在已有成熟视觉系统的项目中工作，应优先保留该系统，并让各个选项在风格上有所区别，避免在不经意间重新塑造产品品牌。

此外，还需收集生成可用代码所需的最少实现信息：

• 框架／运行时（React、Next.js、Vue、纯 HTML 等）
• 样式系统（Tailwind、CSS modules、styled-components、原生 CSS 等）
• 目标插入位置（新路由、现有页面、共享组件文件夹、设计系统区域）
• 这是全新产物还是对现有产物进行重新设计
• 用户需要的是某个区块、页面、流程、外壳还是独立组件
• 质量要求（快速草稿、可用于生产环境、旗舰级）

如果请求是重新设计现有产物，还需确定：

• 哪些部分必须保持可辨识（内容区块、区块顺序、交互模式、熟悉的操作提示、品牌线索）
• 哪些部分可以灵活调整（风格、颜色、文案、字体、媒体呈现方式、信息密度、细节风格）
• 用户希望主要进行稳妥的迭代、广泛探索并比较多个方案，还是尝试一两个突破性方向

确定实现默认选项时，按以下优先级顺序执行：

1. 首先检测并匹配现有项目的样式和组件库
2. 如果这是一个全新项目，且用户明确指定了样式库或组件库，则使用该库
3. 如果这是一个全新项目，且用户未指定，则使用 frontend-design 中定义的框架默认选项

如果适用基于 React 的回退默认选项，还需查阅 component library integration，以判断所请求的产物应以基础组件、可复用模式还是区块加速器为主。

只询问缺失的信息。如果能从代码库推断出技术栈，就直接推断。

根据需要查阅以下参考资料：

• artifact taxonomy
• component library integration
• variation quality bar
• preview and apply patterns
• request mapping heuristics
• examples and command naming

当这些确定性的辅助资源有助于提升不同宿主和 Agent 之间的一致性时，请使用它们：

• comparison table template
• component library integration checklist
• variant naming scheme
• preview page checklist
• apply / cleanup checklist

---

为用户请求的产物生成多个有实质区别的 UI 方向，帮助用户进行比较，然后引导用户选择并完成集成。

这既适用于添加新 UI，也适用于重新设计现有 UI。 当请求是重新设计现有页面、区块、流程、外壳或组件时，默认保留该设计中可辨识的核心结构，除非用户明确要求从结构上彻底改造。通常，这意味着：

• 如果核心信息架构、内容区块和顺序已能满足用户要完成的任务，就保持不变
• 除非交互方式明显有问题，或用户要求进行更大幅度的 UX 改动，否则保留熟悉的交互和操作提示
• 通过字体、颜色、文案呈现方式、媒体处理、细节风格、间距节奏和重点策略来演进视觉系统
• 明确展示各个方案中哪些内容保持不变、哪些有所改变

如果某个变体有意在结构上做出更大突破，应明确将其标注为大胆尝试方案，而不是悄然推倒重做现有页面。

本技能适用于以下类型的请求：

• 营销与变现界面：主视觉、功能、定价、用户评价、常见问题、行动号召、Logo 墙、图库、博客、关于、联系、套餐选择器、升级弹窗、付费墙
• 导航与外壳：导航栏、页脚、仪表板外壳、引导流程信息流、设置、卡片式导航
• 身份验证与账户：登录、注册、忘记密码、重置密码、验证邮箱、双重身份验证
• 电商：产品概览、产品类别、产品列表、筛选器、购物车、结账、评价、订单摘要、礼品卡
• 数据 UI：图表、组件、数据表、表单、对比视图、便当盒网格、时间线、仪表板

此列表仅供参考，并非穷尽。

核心操作规则

1. 生成真正不同的方案，而非只换颜色

   • 各个变体必须在布局、层级、信息密度、风格、交互模式和内容呈现方式上有所不同。
   • 仅更改配色、圆角或图标集，不算新的设计方向。

2. 从用户要完成的任务出发

   • 定价区块不只是几张卡片。
   • 登录页面不只是几个输入框。
   • 仪表板外壳不只是界面框架。
   • 每个变体都要围绕用户的主要任务和产品风格展开。
   • 对于宽泛的新项目营销请求，选择适合公司 / 产品构想的获批设计方向，并说明其契合之处。

3. 优先使用基于源代码的预览，而非临时 DOM 技巧

   • 如果宿主支持预览，就生成用户可查看并选择的真实组件 / 页面 / 路由。
   • 不要将类似浏览器扩展的 DOM 注入作为主要工作流。这种方式很脆弱，也无法生成易于维护的源代码。

4. 保持鲜明立场

   • better-web-ui 致力于打造独特且品味出众的成果。
   • 不要退回到最保险、千篇一律的 SaaS 布局。
   • 积极运用前端设计中的反模式指导。

5. 关注集成

   • 遵循项目现有的代码规范和文件夹结构。
   • 如果已有共享 UI 系统，就接入该系统，而不是随意创建一次性基础组件。
   • 如果多个变体中出现重复结构，就提取合理的共享部分。

6. 遵循保留设计精髓的要求

   • 如果用户要求保留设计精髓，就保留可辨识的结构、关键部分和叙事流程，除非用户明确表示可以进行更彻底的改造。
   • 即使保留核心结构，不同方向仍可通过字体、颜色、文案、信息密度、证明材料呈现、表面样式、媒体方向和行动重点体现真正的差异。
   • 不要把“给我几个方案”误解为可以舍弃现有架构。

工作流

1. 对请求进行分类

使用产物分类判断用户要的是区块、页面、流程、外壳，还是数据／内容组件。

同时判断这是：

• 全新产物
• 在基本保留结构的前提下重新设计现有产物
• 允许适度调整结构的重新设计
• 允许彻底重新构思的重新设计

然后确定：

• 用户的主要目标
• 核心内容区块
• 关键状态（加载、空状态、错误、成功、验证、响应式布局）
• 所处位置（新页面、现有页面内、仪表板内、营销网站内）
• 哪些结构元素是固定的，哪些是灵活的
• 当前哪些特质应保留以维持辨识度，哪些应改变

2. 定义 5 个不同方向

生成 5 个候选方向。少于 3 个会限制探索；多于 5 个则会产生干扰。

使用变体质量标准，确保这五个方向存在实质差异，而不是只换了配色。

如果请求要求保留现有结构或精髓，就将当前产物作为基准框架。未经许可，不应通过删除或重新排序页面内容来区分方向；应主要通过视觉体系和文案策略来呈现差异。

对于这类重新设计，选项之间可以通过以下因素的组合体现差异：

• 字体排印与字体搭配
• 配色与对比策略
• 文案语气与标题角度
• 证明材料的布局与强调方式
• 信息密度与间距节奏
• 图像或插画的处理方式
• 表面样式、边框、纵深感与细节语言
• 操作层级与 CTA 呈现方式

每个方向都必须包含：

• 名称：简短、好记、以概念为核心
• 获批方向：主要结构方向，以及相关的辅助处理方式
• 设计主张：用一句话解释设计思路
• 适用原因：说明它如何支持用户目标
• 关键特征：层级、布局、密度、个性、媒体处理、操作策略
• 最适合的情况：说明何时应优先选择该方向
• 风格成本：需要留意的主要实现、性能或状态管理成本

对于现有产物的重新设计，还需说明：

• 保留的骨架：哪些内容会有意保留，以维持当前产物的辨识度
• 主要变化：该方向着重强化的部分

3. 构建真实的候选产物

为每个方向生成完整的真实产物包。

优先采用：

• 真实的组件文件
• 真实的路由／页面文件
• 可在不同变体间切换的真实预览外壳
• 必要时使用真实数据模拟或占位内容，让界面清晰易读

重新设计现有产物时，只要可行，就从当前真实实现分叉，而不是从头重建。首先保留用户要求的结构，再叠加设计变化。

使用预览与应用模式，确定预览的组织方式、备选比较形式以及最终集成方式。

4. 确保各变体可以真正比较

每个变体都要涵盖相同的实用检查项：

• 响应式行为
• 无障碍预期
• 关键交互状态
• 内容占位符或示例文案
• 实现说明
• 所需的支持组件

重新设计时，还需包括：

• 简要说明结构上保持一致的部分
• 简要说明视觉或编辑层面的变化

不要让某个选项只是草图，而另一个已经达到生产级别。请确保比较的各项处于同等完成度。

5. 提出建议，再让用户选择

生成选项后：

1. 用简洁的表格总结各方案的权衡
2. 如果用户的目标明显倾向于某个方案，就推荐该方案
3. 如果有多个可行方向，就让用户明确选择

推荐时应说明所选方向为何最符合以下要求：

• 受众
• 产品语气
• 信息密度
• 转化或易用性目标
• 在当前代码库中的可维护性

6. 清晰地应用所选方向

选定方向后：

• 将其整合到指定目标位置
• 保留项目约定和导入语句
• 只有在确实可复用时，才提取重复的基础元素
• 删除明显无用的临时脚手架，除非用户希望保留其他方案
• 仅在预览产物仍有助于后续迭代时保留它们

出现可复用模式时，应践行 extract 的理念，但不要为单次需求搭建臃肿的设计系统。

使用请求映射启发式，了解英雄区域、定价、付费墙、身份验证、仪表盘、电商流程和内容界面等不同产物的优先事项。

输出约定

尽可能按以下顺序呈现结果：

1. 生成内容——请求的产物和方向数量
2. 方案对比表——1/2/3/4/5，列出设计思路和最适用场景；适用时使用对比表模板
3. 推荐方案——如适用
4. 预览／应用说明——如何检查或切换方案
5. 实现产物——创建或更新的文件

使用方案命名规范，确保标签、文件名和选择映射具有确定性。 构建预览界面时，使用预览页面检查清单。 用户选定方向后，使用应用／清理检查清单。

切勿这样做

• 生成 5 个只有表面差异、近乎相同的方案
• 将临时浏览器 DOM 注入作为主要实现策略
• 忽略现有代码库结构和样式系统
• 用户要求保留现有产物的精髓或可辨识部分时，彻底推翻其结构
• 仅因提示宽泛，就默认采用通用的创业公司美学
• 在此库中默认采用复古、赛博、合成波、终端或通用未来霓虹风格
• 让每个选项都喧闹、卡片繁多、渐变过多或动画过多
• 当加载、错误、空状态或响应式布局会显著影响产物时，跳过这些状态
• 应用所选方案时，不说明具体改动

请记住：这项技能不是用于生成可互换 UI 的老虎机，而是一套结构化的探索工作流，帮助用户在真正不同且适合投入生产的方向中做出选择，并最终获得易于维护的源代码。