frontend-design

前端设计

构建并完善界面，让其视觉方向与产品、受众和内容相契合。让字体排印、构图、图像和交互协同发挥作用；保留用户的品牌特色以及现有应用的惯例。

目标版本（2026 年 10 月——固定版本号，以便直观了解其过时程度）：

• Astro 7.3.5（重大版本：Rust 编译器、Vite 8、高级路由；迁移前请核实与具体安全公告相关的修复版本范围）
• SvelteKit 3.0.0 + Svelte 5.57.1 runes（SvelteKit 3 是于 2026-10-01 发布的重大版本：TypeScript 6+、Node 22.17+；请查阅迁移说明）
• Tailwind CSS v4.3.3
• Vite 8.3.2
• React 19.3.0 + Next.js 16.3.8（更重的选项，仅适用于团队已锁定 React 的情况）
• @use-gesture/react 10.3.1（较现代；Hammer.js 被视为旧技术）

2026 年 8 月 Next.js 安全更新 修复了严重的 AVIF 图像优化 RCE 和 Windows 混合路由器 RCE（CVE-2026-75604）。 修复后的 LTS 版本为 15.5.24 和 16.3.3。9 月 22 日的带外版本 修复了 Node.js ImageResponse（next/og）中的严重 RCE（GHSA-vcvr-r3jv-pc5j），影响 >=16.2.0 <16.3.6；最低修复版本为 16.3.6（15.5.26 仅增加了强化措施；15.x 不受影响）。 9 月 30 日的安全版本 修复了 高危图像优化 SSRF（CVE-2026-94483），以及中危缓存投毒和缓存泄露安全公告；最低修复版本为 16.3.8 和 15.5.27。 评估现有应用时，请检查每项安全公告中的部署条件（截至 2026-10-02 已核实）。

版本列表供新项目选型参考，不是升级指令。 检查已安装的软件包，并遵循项目现有技术栈。选择依赖或使用不熟悉的 API 时，请核实当前文档；不要仅为视觉改动迁移框架。

适用场景

• 构建或调整组件、页面、落地页或应用界面
• 审查 UI 层级、视觉识别、字体排印、布局或交互状态
• 打磨仪表板、设置、表单、引导流程和空状态
• 设计响应式行为、触控交互或主题架构
• 用户明确需要做出前端技术栈决策时，选择合适的技术栈

不适用场景

• 通用代码正确性或逻辑——使用 code-review
• 代码重复、虚构 API 或过度抽象——使用 code-simplification
• 界面之外的文案审查——使用 anti-ai-prose
• 后端 API 设计——使用 backend-api
• 本地化目录和翻译覆盖率——使用 i18n-localization
• 测试策略和自动化测试编写——使用 testing。本技能负责渲染后的视觉检查，以及需要验证的 UI 行为
• 产品策略或架构决策——使用 plan-review

AI 自检

• 设计符合实际需求说明、内容和受众；保留明确指定的品牌选择
• 字体排印、配色、间距和图像形成协调的视觉方向，并有清晰的层级
• 在适当情况下复用现有组件、技术栈和设计令牌
• 首屏支持用户的主要任务；控件能执行其标示的操作
• 移动端布局、长文本、键盘访问、焦点和相关交互状态均正常
• 文本和必要的控件图形符合适用的 WCAG AA 对比度要求
• 已设计并检查支持的主题；动画遵循减少动态效果偏好
• 已检查渲染后的截图并复核发现的缺陷，或明确说明存在的限制
• 分别报告构建／检查结果和视觉观察结果；不得编造任一项
• 已检查 references/agent-hygiene.md 中的跨领域规范

语气与判断

表达直接、善于观察，并带有适度的主见。推荐更好的选择，并解释它为什么适合这个界面。如果设计显得普通或畏缩，就指出具体问题并给出明确的改进建议。避免客套含糊、刻意严厉，以及在已有明确推荐时罗列权重相同的选项。

简短的第一印象能让评审更有个性：“标题很有力，但下面三个同等大小的面板把所有内容都弱化了。我会给主要操作更多空间。”用一两句话说明，并结合可见细节。区分审美判断与可用性缺陷；尊重明确的品牌选择，不要反复争辩。

工作流

对于 Build 和 Refine，请复制此清单并跟踪进度（Critique 只使用第 1、4、5 步）：

• 第 1 步：明确需求与模式
• 第 2 步：选定视觉方向（新建或大幅改版）
• 第 3 步：使用真实内容、状态和无障碍控件构建界面
• 第 4 步：渲染并检查；如果仍有明显缺陷，修复后返回第 4 步
• 第 5 步：交付结果，并说明实际检查项和限制

第 1 步：明确需求与模式

新建 UI 时使用 Build；获准修改 UI 时使用 Refine；评估时使用 Critique；仅在用户要求或确有必要选择框架时使用 Stack-pick。仅进行评估并不代表获准修改。

阅读相关文件以及现有的产品或设计指南。明确受众、主要任务、实际内容和限制条件。区分注重表达的营销页面与服务日常工作的操作界面；后者需要足够的信息密度和熟悉的控件。若有参考资料和现有截图，请一并查看。

只询问那些会实质影响结果且无法推断的信息。否则，简要说明假设并继续。用户已经提供足够方向时，不要要求新写设计文档或再走一轮审批。小幅修复应保留既有设计，规划投入也应与修改幅度相称。如果用户只要求调整间距，就使用提供的选择器并修改间距；尺寸或无障碍方面的不相关问题另行说明。

第 2 步：选择视觉方向

在新建或大幅改版前，简要说明设计方向：

• **内容与构图：**哪些内容最先吸引注意力，视线如何到达主要操作，以及布局如何适配实际标题、数据或图像
• **字体排印：**字体系列及用途、字号层级、字重、行长和间距。选好一种字体系列也可能足够；请确认字体是否可用，以及是否支持所需语言
• **颜色：**为界面背景、文字、强调色和状态色指定名称及具体数值。根据需求确定配色，而不是只根据产品类别决定
• **图像：**如果提供的素材或相关且获准使用的图像能传递信息或建立辨识度，就使用它们。确定裁剪方式、位置和备用方案；绝不要捏造客户背书
• **个性：**明确最具辨识度的元素，以及应保持克制的辅助元素。对于现有产品而言，保持一致性可能比打造新标志性风格更重要

如果构图尚未确定，就比较两个简短的布局草图，并选择最能支持内容的方案。简洁的 ASCII 线框图就足够。不要把每次小型组件修改都变成多个概念方案的展示。

编码前先审视设计方向：如果把产品名称替换掉，这套设计是否仍然像是为无关业务量身打造的？如果是，就用具体内容、结构或素材调整那些泛化的选择。简要说明这项关键选择。设计必须有辨识度，但不能牺牲易理解性，也不能违背用户要求的风格。

第 3 步：构建可用的界面

• 遵循现有框架、包管理器、文件组织方式、组件和设计令牌。 对于没有限制的新项目，选择最简单且合适的实现方式；纯 HTML 也可以。仅在选择技术栈时加载 references/frameworks.md
• 使用有代表性的内容构建实际界面。避免使用掩盖布局问题的占位文案。标注示例数据，并根据数据计算显示的总数。省略无法执行其所标注操作的可选控件；不要交付可点击的占位内容
• 运用字体、对齐、间距和分组来明确层级。只要符合需求，卡片、渐变、居中布局和常用字体都可以使用
• 检查通用的界面构成时，阅读 references/ai-tells.md。其中的替代方案是诊断示例，而非可直接套用的风格指南
• 确保控件可用，并使用语义化元素、无障碍名称、可见焦点和键盘操作流程。优先使用原生控件；只有在完整实现焦点管理和键盘操作模型时，才使用组合式 ARIA 控件。在适用的情况下，确保加载、空内容、错误／重试、成功和禁用状态以及选择状态都可触达；没有后端时，使用带标签的示例控件展示这些状态。如果某项操作会移除或禁用当前获得焦点的控件，请保留有用的键盘焦点
• 在此处负责无障碍交互设计、语义、焦点顺序和错误恢复；使用 testing 执行可重复的无障碍回归检查。针对关键流程进行手动键盘和屏幕阅读器检查；仅靠自动化扫描无法证明符合规范。
• 精心设计窄屏布局。移动设备上的触控目标应尽量达到 44 x 44 CSS px；请依据适用标准及其例外情况，单独评估无障碍合规性
• 在适用的产品界面中支持深色和浅色主题，并保留现有主题行为。单主题宣传页面或局部组件变更无需添加切换开关。实现主题时阅读 references/themes.md；检查每个受支持的主题
• 仅在有助于说明状态变化或符合获批设计方向时添加动效。不强制使用故障风格、入场动画或装饰效果。遵循减少动态效果的偏好设置
• 运行类界面使用 references/app-ui-patterns.md，手势或触控相关工作使用 references/mobile-touch.md。仅在确有理由时加载 references/glitch-effects.md
• 使用符合用户习惯的词汇编写标签。操作描述应始终与其结果一致；错误和空状态应说明下一步有用操作，不要添加多余内容

第 4 步：渲染、检查并修改

使用可用的浏览器或截图工具检查运行结果。这些说明与工具无关：选择可用的同类工具，不要假设一定有某个特定工具、插件或已安装的配套技能。

1. 运行相关项目检查，并通过文档说明的命令启动或使用预览。
2. 检查桌面端和窄屏移动端的渲染结果，以及任何出现缺陷的布局断点。检查层级、对齐、密度、文本换行、图像和主要操作的可见性。
3. 测试主要交互、键盘操作流程以及相关的错误或空状态。检查长标签、溢出、支持的主题、焦点和减少动态效果的行为。验证渲染界面中的初始、活动和恢复状态；CSS 可能会覆盖元素的 hidden 属性。检查所有可见的移动端控件，包括状态变化后显示的控件。
4. 找出与需求差距最大的已观察问题。在构建／优化模式下修复这些问题，重新渲染，并再次检查受影响的视图和行为。在评审模式下，报告证据和建议的修复方案，不要修改产物。
5. 已观察到的重大问题解决且符合需求后即可停止。不要只为追求新鲜感而不断修改设计。如果问题仍然存在，请准确描述。

如果无法渲染，请检查源码和提供的截图，说明哪些内容无法验证，并在已知时提供预览／检查命令。仅凭代码检查，绝不可声称视觉检查已通过。如果环境已提供合适的工具，不要仅为满足本技能的措辞要求而安装浏览器或添加依赖。

第 5 步：交付结果

对于构建／优化模式，请总结重要的视觉设计选择，链接到已更改的文件或预览，并报告实际执行的检查及仍存的限制。不要将常规实现细节放入产品界面。小改动无需强制提供文件树或单独的美学说明文档。

对于评审模式，请遵循 references/critique-template.md：提供证据、用户影响和具体修复方案。优先列出影响最大的发现；不要将颜色或字体偏好列为发布阻断项。主要工单列表最多列出 10 项；其他严重发现应放在附录中，不要省略。未知行为应列入验证限制，而不是按严重程度排序的发现；信息提示应放在修复工单表格之外。

性能

• 复用现有资源和依赖；针对支持的设备优化图像和字体
• 预留图像尺寸，延迟加载首屏以下的媒体，并避免延迟主要内容的显示
• 无需服务器状态时，在本地提供交互反馈
• 添加动画库前，先测量耗费较高的效果和运行时成本

参考文件

• references/ai-tells.md - 用于诊断通用构图的提示词
• references/frameworks.md - 确实需要选择时的技术栈选择建议
• references/themes.md - 支持主题的实现指南
• references/mobile-touch.md - 触控和手势模式
• references/app-ui-patterns.md - 应用外壳、仪表板、表单和状态
• references/glitch-effects.md - 适用于特定需求的可选特效
• references/critique-template.md - 基于证据的评审和优先级

输出约定

完整约定请参见 references/output-contract.md。

• 技能名称： FRONTEND-DESIGN
• 交付物类别： deliverables
• 模式： 有条件。调用技能来分析、评审、审计或改进现有 UI/UX（例如“评审我的落地页”）时，遵循 references/output-contract.md 中关于报告篇幅和证据的规则，并将交付物写入 docs/local/deliverables/frontend-design/<YYYY-MM-DD>-<slug>.md。调用技能来构建新产物或生成内容（其主要模式是在聊天中生成 UI 代码）时，可自由作答，不受约定限制；构建模式的行为保持不变。
• 严重性等级： P0 | P1 | P2 | P3 | info（参见共享约定；仅在审计/评审模式下使用）。

相关技能

• code-simplification - 实现质量和不必要的抽象
• anti-ai-prose - 文案评审；界面文案仍属于此技能的范围
• code-review - 视觉设计以外的代码正确性
• i18n-localization - 翻译覆盖范围和区域设置行为
• testing - 自动化验证和回归测试
• plan-review - 产品、业务和架构决策

规则

1. 修改或评价产物前，先阅读产物和需求说明。
2. 遵循用户的明确指示。必要时说明具体的可用性权衡；不要要求用户为合理的审美偏好申请例外。
3. 根据内容和上下文推导设计。切勿强加通用配色、字体或效果。
4. 将改动限制在范围内。视觉任务不授权迁移技术栈或添加新功能。
5. 评审界面，而非设计师；切勿仅因个人品味就将问题定为发布阻碍。
6. 技能说明文案和生成的代码注释使用纯 ASCII 字符。