astra-frontend-design

Astra 前端设计

构建连贯且独具特色的界面，服务于产品、契合代码库，并能经受真实浏览器中的检视。除非用户只要求计划或评审，否则应完成所需前端工作的实现和视觉验证。

用户的需求说明和代码库中既有的产品约束优先于本指南。请将此处的指导视为判断标准，而非固定的设计风格。只要符合主题和工作流，采用熟悉的模式也可以。

确定任务对应的参考资料

只阅读当前任务需要的参考资料。

任务	参考资料
落地页、作品集、编辑类、品牌类或表现力突出的站点	art-direction.md
仪表板、SaaS 产品、管理界面、表单或运营工具	product-ui.md
现有界面的重新设计或现代化改造	redesign.md
以截图、Figma 画板、图片或指定网站为参考	reference-to-code.md
突出动画、滚动行为或交互编排	motion-and-interaction.md
评审、润色、无障碍审核或最终验证	quality-gates.md
需要可复用的提示词，而非实现	prompt-recipes.md
比较不同模型或版本的技能质量	evaluation.md

确立设计依据

在更改可见界面之前，检查目标路由、相邻组件、全局样式、资源和依赖清单。除非任务明确要求采用新方向，否则应复用项目的框架、组件基元、设计令牌、图标系列和交互惯例。

根据现有上下文，提炼简明的设计思路：

• 主题、受众和界面的主要用途；
• 视觉特征和一个令人印象深刻的创意；
• 信息密度和动效程度；
• 必须保留的内容、行为、品牌和无障碍约束。

基于合理假设继续推进。只有当不同答案会显著改变产品、品牌或交互模式时，才提出一个重点明确的问题。若用户授权实现，不要只停留在描述可以构建什么。

对于多屏产品或持续进行的重新设计，应将长期适用的产品事实与视觉方向分别记录。如果代码库中没有相应文档，可将 PRODUCT.template.md 和 DESIGN.template.md 作为起点。对于小型的一次性改动，除非文档能避免实际偏差，否则不要创建流程文档。

先规划，再设计样式

在选择装饰细节之前，先确定层级、内容顺序、响应式行为和交互状态。每个界面都应有一个明确的视觉主张。将表现力集中用于支持这一主张，其余部分则保持克制。

只有未经审慎考虑而默认采用时，常见的“生成感”设计惯例才是警示信号。例如：重复的等宽卡片、装饰性渐变、无处不在的胶囊形状、每个标题上方都加眉题、随意使用等宽字体标签、千篇一律的文案，以及每个元素都添加动效。若需求确实需要，可以保留这些做法；否则，应选择更贴合主题的方案。

使用真实可信的内容。不要编造客户名称、推荐语、性能声明、精确指标或产品功能。若需要逼真的数据来展示界面状态，请明确标注为示例数据。

实现真实体验

• 优先构建实用界面。用户要求开发应用、工具、游戏或仪表盘时，不要用营销外壳替代。
• 确保预期的控件和流程都能正常使用。包含相关的加载、空状态、错误、成功、禁用和溢出状态。
• 优先使用真实的项目资源或相关图片，而不是装饰性占位符。只有在能实质性改善结果且现有工具允许时，才创建或获取资源。
• 导入软件包前先检查依赖清单。只有当当前技术栈不具备所需功能时，才添加依赖。
• 在实现中考虑语义化 HTML、键盘访问、可见焦点、易读的对比度、文本重排、减少动态效果的偏好和响应式布局，而不是把它们单独列成检查清单。

通过视觉迭代完善

运行最精简且相关的构建、代码检查和行为测试。必要时启动应用，在具有代表性的桌面和移动端宽度下截取实际界面，并检查像素效果，而不是只相信源代码。检查层级、取景、内容适配、对齐、对比度、交互反馈和控制台错误。修复可见缺陷或功能缺陷，并重复相关检查，直到没有实质性问题。

如果项目已有浏览器或端到端测试工具，请使用现有工具。不要仅为截图而添加庞大的测试套件。根据改动调整验证范围：微调设计令牌无需太多测试，响应式页面或动画交互则需要更全面的测试。

交付时，先说明现在可用的内容。简要说明所选视觉方向和验证依据；除非用户提出要求，否则不要逐一叙述所有设计考量。

与 Agent 编排配合时

将本技能中的设计和实现判断交由能力出众的前端实现者负责。对于范围明确且可通过浏览器测试的构建任务，较小的协调者可以将原始产品需求和参考资料交给一名 Astra 工作人员，然后测试运行结果，并将截图和具体缺陷反馈给同一工作线程。协调者不应以规定性的布局方案取代工作人员的视觉判断。当质量至关重要、任务复杂或难以测试验收时，应直接使用 Astra 或采用由 Astra 主导的计划。只有在用户和环境允许时才委派；明确分配必要的检查工作。

研究依据

本技能是面向 Astra 的原创综合成果。有关出处和调整决策，请参阅 research-basis.md。