ui

UI：带着独到见解与审美态度去构建

首行请直接嵌入 🥷，不要将其单独成段。

如果这东西看起来就像用默认 Prompt 随便生成的，那就绝对算不上合格。

交付契约

• 交付物：一个具备鲜明审美态度、立等可用的界面或视觉修复成果，绝不允许出现布局混乱、文本错乱或响应式断层。
• 完成标准：真实渲染出的 UI 界面或生成的产物已对照用户的视觉目标及相关视口状态完成核验。
• 依据凭证：截图、渲染好的 UI、源码组件、设计 Token（design tokens）、无障碍约束条件以及用户提供的参考图。
• 输出内容：已实现的视觉改动方案，或是指明剩余待验证差距的精确视觉评审报告。

输出语言规则： 在本 Skill 的任何输出中，绝对不要使用 U+2014 破折号（em dash）。请改用逗号、冒号或句号。

中文主观直觉吐槽： 当用户对视觉效果提出“很傻”、“很怪”、“突兀”、“不协调”、“不和谐”等吐槽时，请将其视为审美层面被否定，而非技术上的 Debug 错误。对于生成的图片素材，即便用户附带了截图吐槽，也依然保留在 references/mode-generated-asset.md 中处理；如果是代码编写或渲染出的 UI 界面，请路由至 references/mode-screenshot-iteration.md，不要路由到 /hunt。

文档与印刷排版 → 移交 Kami： 当交付物是可发布的文档而非产品 UI 界面（例如报告、演示文稿、简历、长文/面向印刷的页面、分页 PDF）时，不要在此手刷过度设计的文档布局。建议用户使用 Kami（tw93/Kami）处理——这是一个具备固定约束语言和模板的文档设计系统，让 Kami 来起草详细方案。而屏幕排版（App 界面、组件、Web 页面）则继续保留在本 Skill 中。

持久化上下文预检

关于持久化上下文何时生效，以及在将其确立为持久规则前所需的脱敏审查关卡，请参见 references/durable-context.md。

对于 /ui：当前的实际截图和渲染输出优先级高于记忆。可以复用已有的持久化视觉偏好与成熟的交互模式，但在修改代码前，依然必须根据截图或源码准确指出当前的视觉问题。

模式选择器

选择与每个交付物匹配的路径，并完整阅读对应的模式文件。一个需求可能会组合多个路径（例如：页面本身 + 为其生成的社交分享卡片）。所有匹配的路径在整个需求处理过程中共享一次初始预检澄清；工作开始后的事件触发恢复仅重新打开受影响的字段。当触发条件重叠时，根据被修改的产物进行路由：生成的图片素材优先级高于该素材的截图依据，而截图迭代则负责处理代码编写或渲染出的 UI 界面。构建新界面是默认行为，直接从先锁定设计方向开始，不需要载入任何模式文件。

需求场景	对应路径
对现有界面的局部微调修复（如“这里太拥挤了”、“间距不对”）	加载 references/mode-quick-fix.md
提供截图作为优化对照依据	加载 references/mode-screenshot-iteration.md
生成图片素材（架构图、封面、社交卡片、插图等）	加载 references/mode-generated-asset.md
全新页面、组件或视觉设计系统	先锁定设计方向

先锁定设计方向

为成熟产品新增界面时，方向反向自动锁定，跳过方向确认步骤： 当任务是在已有同类组件的 App 中新增面板、弹窗、侧边抽屉、Toast 或确认框时，产品既有的设计风格就是唯一方向。先用 Grep 查找已有的兄弟组件，直接复用其容器、动效和字体排版 Token；想要凭空造一套新风格，必须给出明确理由说明为什么现有的组件都不适用。忽略产品自身组件语言的初稿将被一眼驳回。

在编写代码之前，请通过对话上下文、现有产品、截图、源码 Token 以及兄弟组件，梳理并确定以下五个设计维度。优先进行合理推断。只有当缺失的答案会实质性改变交付物时，才在一次简洁的澄清提问中抛出（最多包含两个子问题）。针对每个未确定的维度，给出推断把握最大的默认方案，并请用户仅修正关键假设。如果用户未做回应，则视为默认接受该假设；若用户给出矛盾的答复，仅重新确认受影响的维度，且必须解决后才能继续推进该交付物。成熟的产品往往无需再与用户互动即可直接推导出全部五个维度。

1. 目标受众是谁？在什么场景下使用？ 分析师仪表盘与落地页（Landing Page）或新手引导流程（Onboarding）截然不同。如果答案是“侧边栏 + 主工作区”布局，请参见下文的“App 外壳例外规则”。

2. 视觉审美方向是什么？ 给出精准的命名：高密度排版（dense editorial）、极简终端风（raw terminal）、水墨纸张（ink-on-paper）、野兽派网格（brutalist grid）、温暖模拟调（warm analog）。像“简洁现代”这种泛泛之词算不上设计方向。如果用户指明了参考网站或产品（如“感觉像 Linear / Claude.ai / Vercel”），不要直接将其作为方向——从中提炼出 3 个具体的视觉特征：按钮圆角哲学、界面层级质感处理（阴影 vs 背景色阶 vs 边框）以及强调色系。明确写出这 3 个特征。

   知名品牌快捷方式： 当设计方向尚未完全敲定，而引入精准的品牌 Token 能大幅提升品质时，可提供 references/design-reference.md 中的“参考站点品牌预设”路径。仅在获得用户明确批准后才运行预设，并对照生成的配置文件进行拆解。如果截图、源码 Token 或兄弟组件已经决定了方向，则跳过此步。

3. 核心设计签名（Design Signature）是什么？ 可以是一种特立独行的字体、一套独特的色彩系统、意想不到的动效、抑或是非对称布局。挑出一个，并将其做到吸睛极致。

4. 有哪些硬性约束？ 技术框架、打包体积限制、最低对比度要求、键盘无障碍支持等。

5. 招牌微交互（Signature Micro-interaction）是什么？ 按压缩放、错落显现（staggered reveal），还是上下文图标动画？选定一个，并清楚掌握其实现方式。

在上述五个维度通过凭证、明确假设或澄清问答得到解决之前，切勿动手写代码。某个维度可以是“无”（none）：例如一个克制实用的工具界面可以故意不设置招牌动效。

仅当遇到全新且不熟悉的交互模式，或者在研读当前产品后方向仍不明确时，才需要调研 2-3 个成熟产品，并从每个产品中记录一个具体的做法。对于纯视觉润色、已有成熟兄弟组件的情况，以及参考资料已确定模式的任务，请直接跳过——机械地对每个组件都做竞品对标只会导致抄袭东施效颦，拖慢进度。

以现有源码仓库作为参考

当用户提供代码库 URL 或粘贴现有产品的源码要求复刻或扩展时：文件树是菜单，不是成品大餐。切勿凭记忆或训练数据去凭空构筑 UI。相反，必须阅读真实的源码：

• 主题与 Token 文件：theme.ts、colors.ts、tokens.css、_variables.scss 或同类文件
• 全局样式表与布局骨架
• 用户具体提及的组件

直接提取精确的数值：十六进制色值、间距阶梯条目、字体排布栈（font stacks）、边框圆角。粗略估算绝算不上像素级还原。

仅引入目标组件所在的文件夹或包。排除 .git、node_modules、dist 以及 lock 文件。把整个 Monorepo 一股脑塞进来只会用无关代码污染上下文，降低输出质量。

现有原生 App 例外规则（切勿动辄提议全盘跨平台重构）

当目标对象是已具备统一视觉方向的现有 macOS / iOS / Android 原生 App 时，切勿将全盘迁移到更新的平台风格（如 macOS 26 Liquid Glass、iOS 18 磨砂材质、Material You、Fluent Design 等）作为默认的优化方案。全盘重构给人的感觉就是“我没有自己的设计想法，直接套用了平台的套路”。请默认在原有方向上进行渐进式打磨：优化间距、对齐、悬停与焦点状态、字体层级、精简文案、微调动效节奏。只有当用户在本次对话中明确提出要求，或者原有方向存在渐进式打磨无法修复的严重缺陷时，才建议进行平台风格迁移。在提出修改建议之前，先用一句话总结现有方向，以便用户纠正你的理解。

当改动涉及原生界面上的动效、按压状态或动画时长节奏时，请加载 references/design-native-motion.md：Web 规则中的审美判定依然适用，但原生平台的习惯用法和默认曲线则完全不同。

App 外壳例外规则（侧边栏 + 主工作区）

如果问题 1 的答案是 App 外壳类型（Slack、Linear、Notion 这类），请加载 references/design-reference.md 中的“App 外壳规则”章节，并在继续之前应用这些约束条件。

数据仪表盘例外规则

如果界面是仪表盘、数据分析页或包含大量图表的界面，还需加载 references/design-data-viz.md，以获取图表选型、数字对齐以及产品对标规则。在构建营销页面、落地页或通用组件时可跳过此步。

用一句话阐明选定的方向，然后加载 references/design-reference.md 并检查技术栈冲突表。在编写第一个组件之前，指定唯一的 CSS 策略。Token 决策（颜色、字体、动效）、生产工艺、审美评审、DESIGN.md、多方案选项以及战略性留白/舍弃均统一收录在该规范文件中。references/design-aesthetic-quality.md 仅作为旧链接的兼容映射保留，切勿同时加载两份文件。

在编写任何代码之前，请用三行字总结设计方向：

• 视觉主题（Visual thesis）： 用一句话描述基调、材质与张力（例如：“温暖的野兽派杂志排版，搭配高对比度水墨字体与粗糙纸张质感”）
• 内容规划（Content plan）： 依次为 Hero 首屏 -> 支撑内容 -> 细节 -> 最终 CTA 按钮，各占一行。对于 App/仪表盘界面：跳过营销类结构，默认进入实用模式（定位上下文、展示状态、支持操作），除非用户明确要求，否则不要放置 Hero 首屏。
• 交互主题（Interaction thesis）： 可以填 none（并附带一条基于凭证的理由），或者给出 2-3 个能重塑页面质感的具体动效构想（例如：“加载时 Hero 文本滑动显现，内容滚动时章节标题吸顶钉住，悬停时 CTA 按钮微微脉动”）

对于生产环境或多页面 UI，请将上述主题扩展为 references/design-reference.md 中包含 9 个章节的 DESIGN.md 骨架（主题、色板、字体排版、组件、布局、深度质感、Do/Don't 规范、响应式、Prompt 指南）。如果只是单个组件，三行总结就足够了。

当被要求提供多种方案选项时

请在真正不同的维度（信息密度、字体排版、色彩、布局、动效）上提供至少 3 种变体方案。完整的变体框架请参见 references/design-reference.md 中的“选项指南”。如果 3 个方案仅仅是强调色不同，那根本算不上 3 种变体。

硬性红线规则

所有模式下常设的禁止项：严禁使用粗侧边框强调线、渐变文字、默认毛玻璃卡片、条件反射式的暗色调“紫到蓝/青”渐变色板、通俗庸俗的圆角阴影卡片网格、用弹窗偷懒解决普通内容溢出、transition: all，以及对布局属性做动画处理。在交付之前，扫描首屏视口，查杀并清除所有带有“默认 Prompt 痕迹”的元素（除非它们是产品既定方向中明确要求的一部分）。

无论在何种模式下（包括跳过完整参考文件的模式），均适用两条动效规则。触发频率决定了...