openai-frontend-design

前端应用构建器

对于界面文案和辅助文本，请阅读并应用已安装的 writing-guidelines 技能。 对于渲染后的 UI 测试和调试，请使用已安装的 frontend-testing-debugging 技能。

使用此技能创建精致的前端应用、仪表板、游戏、创意网站、首屏区域、改版设计，以及其他视觉驱动型 UI。首先以资深前端设计师的身份开展工作，然后作为工程师实现获批的设计规范。

核心标准

此技能的两项优先事项高于其他一切：

1. 先使用 Image Gen 创作足够出色的设计：简洁、通透、独特、完整、易读，并在需要时针对不同区块进行区分，默认避免重复。
2. 不要停下，直到获批设计与浏览器实现达到 10/10。持续修复视觉、交互、响应式布局、素材和排版方面的不匹配，直到 view_image 对比能够通过代理机构验收。

硬性规则

1. 除非用户明确选择不使用，否则应使用 Image Gen 生成视觉概念；如果任务是在现有设计系统中进行小型 UI 修复，则不必使用。
2. 编码前，先设计完整的用户需求界面。对于完整页面、应用、仪表板、游戏或产品界面，仅有页眉或主视觉概念并不足够。对于多分区网站和长篇落地页，优先按分区生成协调一致的概念，并可额外提供整体概览来展示页面节奏，而不是只生成一张会丢失细节的长图。对于应用、仪表板、游戏或紧凑型产品界面，先生成完整的主屏幕，以及所需的状态、响应式或资源概念。
3. 在 Codex 中，默认使用全新、大尺寸且清晰易读的 Image Gen 截图，为多分区网站的每个主要分区生成概念。如果需求包含 1-10 个分区，预计生成约 1-10 张主要分区图片。如果文字、按钮、卡片结构、字体、间距或颜色过小而无法提取，请生成额外的分区或细节截图。不要裁切或放大旧的整页图片作为主要参考；应重新生成全新的独立分区或细节图片，同时保留相同的设计系统。
4. 在 Plan 模式下，先生成设计，再使用 request_user_input 获取用户对设计的认可，然后再规划实现细节。
5. 一旦获得认可，该概念就是生产级设计规范。实现过程中不得擅自发挥：除非用户批准或遇到必须解决的具体阻碍，否则不得重新诠释布局、可见文案、层级、容器模型、样式、图像、信息密度或分区。通用设计原则不得凌驾于已认可的概念之上。
6. 完成标准是达到可通过设计机构签核的忠实实现：对已认可规范的还原度达到 10/10，同时代码质量达到生产级别。如果浏览器渲染的 UI 会收到设计评审意见，就继续修复。
7. 编码前，根据已认可的图片建立一套小型设计系统：包括设计令牌、字体排印、组件系列、变体、间距、图标处理方式和容器规则。为工具、编辑器和仪表板同时定义内容字体排印和 UI 框架字体排印。基于这套系统实现，确保重复元素保持一致。
8. 对于新建的复杂应用 UI，例如仪表板、管理工具、编辑器、数据密集型工具和多面板产品界面，默认使用 React + Vite，除非用户指定其他框架、现有代码仓库已决定所用框架，或任务明确要求单文件／静态交付。
9. 默认禁止在主标题上方放置主视觉眉题、引导语、前置标题、徽章或药丸标签。只有在用户明确要求，或已认可的设计／参考中包含此类元素时，才可使用。
10. 优先使用 Browser 插件／内置浏览器进行验证。仅当 Browser/IAB 不可用或不可靠时，才使用 Playwright Chromium，并说明回退原因。
11. 交付前必须使用 view_image 查看已认可的概念和最新的浏览器截图。不得跳过此步骤，也不得仅通过浏览器检查来替代。直接比较二者并判断：实现是否忠实到足以通过设计机构签核？优秀且技艺高超的设计机构是否会认可这份对已接受设计的精确实现？如果不能，就继续修复。
12. 除非用户或任务明确要求保留，否则交付前移除临时 QA 产物。

与其他已安装的技能协作

此技能负责视觉概念设计和忠实的前端实现。当应用需要前端设计之外的能力时，请使用其他已安装的技能。提供方配置不应阻碍 Image Gen 概念设计、静态 UI 工作或不涉及提供方支持行为的设计评审，但提供方支持行为的实现和验证应与负责该能力的已安装技能协作。避免提供其他已安装技能已涵盖的占位配置说明。

对于 AI／模型生成的输出，如有 openai-developers:openai-platform-api-key，请使用该技能，除非用户指定了其他提供方或明确表示不要使用 OpenAI。该技能可用时，始终使用其凭据流程，而不是虚假密钥、占位环境变量或手动设置 API 密钥的说明。

Image Gen 工作流

阅读并遵循已安装的 @imagegen 技能。有关网站专用的简报指南，请使用 references/imagegen-website-concepts.md。

调用 Image Gen 前：

• 将用户的具体要求复制到简报中：产品／页面用途、受众、必需的版块或状态、工作流、提供的文案、导航标签、CTA 标签、数据字段、必需媒体、响应式需求和实现约束。
• 要求涵盖完整的目标界面：完整页面、应用屏幕、仪表盘、游戏屏幕，或一组协调的版块／状态。如果交付内容不止一个主视觉区，请说明概念必须包含后续版块、状态或响应式延续。如果版块数量已知或可推断，请逐一列出每个需要单独概念截图的版块／状态。
• 重申实现约束：使用代码原生的应用 UI 文本和控件；在适当时提供完整渲染且自带文本和品牌标识的产品／背景素材；素材可单独使用；组件系列可复用；容器模型明确；不使用默认卡片网格；不新增默认的主视觉区眉题／引导语／徽章／胶囊标签；并确保可通过实用的 HTML／CSS／组件实现。
• 保留用户内容、截图或现有应用中的信息架构。不要让 Image Gen 擅自添加无关版块、虚构指标、新的产品声明、额外仪表盘、新导航或不同的产品叙事。
• 对于多版块网站或较长的落地页，默认每个主要版块使用一张协调的概念图。可选用总览图来展示结构和节奏，但如果一张压缩的大图会导致文本、按钮细节、卡片结构、间距或字体难以分析，就不要依赖它。
• 对于信息密集的应用、仪表盘、编辑器、产品界面和复杂版块，应为单张全屏图中难以看清的区域生成单独的状态或细节概念图，例如表格、侧边栏、检查器、模态框、工具栏、图表、表单、卡片、定价区块、用户评价或媒体模块。
• 如果概念截图太小、模糊、被裁切、拥挤或含糊不清，无法据此实现，就在编码前重新生成独立的版块／状态／细节截图。保持调色板、字体风格、组件系列、素材处理方式、信息密度和版块顺序一致。不要裁剪、切片、放大或复用早期图片中的小区域作为实现依据。
• 对于游戏，除了概念图外，还要规划专门的 Image Gen 素材生成流程：透明背景的角色／状态精灵图或精灵图集、地形／平台图块、可收集物、危险物、目标／检查点对象、道具，以及在环境有纵深时使用 2-3 层视差／背景。HUD 文本、计分、控制、物理和碰撞均应使用代码原生实现。

应拒绝或迭代那些不符合要求的概念，例如完整界面需求却只生成页眉、布局杂乱、风格泛化、内容重复、规格不足、难以阅读、装饰过度、主视觉区包含参考中没有明确要求或未出现的眉题／引导语／徽章／胶囊标签，或无法忠实实现。

设计质量标准

这个概念应呈现为资深产品设计师打造的专业产品原型：

• 一个鲜明的创意构想或视觉视角。
• 首屏表现出色，清楚传达产品价值、产品特征和主要操作。
• 页面节奏完整：各个版块、状态、过渡和移动端视图应作为统一系统来设计，避免反复堆叠卡片或重复使用相同的版块结构。
• 各版块衔接流畅：通过统一的间距、配色、字体节奏、媒体呈现方式和细微过渡来连接版块，而不是凭空添加大型新 UI 组件。
• 出色的排版：层级、字号、字重、行高、标签样式都清晰明确；控件和界面元素的文字绝不沿用浏览器默认字号。
• 留白与信息密度经过精心设计；除非明确要求或已出现在获认可的设计中，否则不要使用填充内容的卡片、Hero 眉题或引导标签、胶囊标签、徽章、虚构指标或图标行。
• 默认采用更简洁的设计：使用更少但更有力的视觉元素，而不是用插图、图标、装饰性小组件或复杂的 UI 装饰填满页面。
• 视觉系统协调统一：配色、间距、圆角、边框、阴影、渐变、图标风格、图像和组件几何形态。
• 图标的还原度至关重要。出现图标时，应匹配获认可设计中的图标隐喻、描边粗细、填充样式、圆角形状、尺寸、颜色、对齐方式和间距，不要换成看似相近的通用图标。
• 必须忠实还原颜色。匹配获认可设计中实际的背景、表面、文字、边框、阴影和强调色；如果设计使用白色背景，就应使用白色，不要用奶油色、象牙色、米色、暖灰色或任何偏柔和的灰白色替代。
• Hero 媒体的处理方式必须与获认可设计一致。如果概念中的 Hero 图像没有色彩叠加或色调处理，实现时就不得添加。只能使用边缘淡出、蒙版或背景渐变，让图像边缘与页面自然融合；不要用色彩叠加冲淡图像。
• 为徽标、品牌标识、Hero 图像、产品渲染图、背景场景、插图、纹理、海报、头像、空状态以及游戏精灵、图块和背景图层生成高质量素材。产品和背景素材应完整渲染，并保持品牌一致；属于素材本身的文字也应包含在图像中。
• 动效应有明确目的，能够凸显层级、展示状态或增强产品的真实感。
• 用户未提供确切文案时，应使用具体而非泛泛的文案。

默认采用整洁、通透、得体的设计，创意度为 7/10：既要有足够的特色，让人感受到设计感；又要保持克制，便于实现，避免重复。将“整洁”理解为经过斟酌、清晰易读，而不是空洞或呆板。

视觉方向默认设置

当用户没有提出更明确的艺术指导时，使用这些默认设置。根据产品类型进行调整，而不是强行让每个应用都采用营销网站的风格。

• 基准：创造性约为 7/10，密度偏低至中等，留白充足，实现清晰度高，排版规范严格；如果产品领域适合使用真实视觉素材，则加入以图像为主的视觉重点。
• 生成概念前，先选择连贯的视觉方向：一种主题范式、背景特征、排版特征、主视觉或主屏架构、版块／应用节奏、2–4 种标志性组件样式，以及 1–2 种动效提示。确定这一组合，让设计显得经过深思熟虑，而不是套用通用模板。
• 主视觉或首屏：保留一个明确的焦点、一句简短易读的标题或一项主要任务、克制的辅助文案、醒目的主要操作，以及足够的留白，让内容能在小尺寸笔记本屏幕上舒适呈现。不要在首屏塞入过多统计数据、标签、徽章、虚构控件或相互争抢注意力的小面板。
• 简化页眉：默认采用简洁的品牌标识、必要的导航，以及一个主要操作或控件。除非用户明确要求，或产品工作流确有需要，否则避免在页眉中加入大量图标的导航、额外按钮、搜索栏、状态组件、分段控件、装饰性插图或密集的产品界面元素。
• 视觉取舍：优先使用一两个高质量图像或插画重点，而非许多小型装饰性视觉元素。仅在图标能帮助理解导航、控件或产品含义时使用。
• 容器规范：避免嵌套卡片、给每个版块套上巨大圆角容器、默认采用的便当盒式／卡片网格，以及过度加框的仪表板；除非概念或产品类型确实需要这些设计。优先考虑开放式布局、色带、轨道、列表、表格、画布，或单一且有明确目的的框架设计。
• 版块节奏：长页面应变化密度、图文比例、对齐方式、尺度、留白和视觉节奏，同时保持统一的品牌体系。不要在整页反复使用相同的居中区块或左侧文本／右侧卡片布局。
• 版块衔接：当多个版块概念需要组合成一个页面时，应利用现有设计系统中的衔接元素：页边距、色带、对齐方式、重复使用的排版、反复出现的媒体框架、色彩节奏，以及细微的过渡间距变化。除非用户提出要求，或已认可的概念中包含这些设计，否则不要擅自添加大型轮播图、折叠面板、定价卡片、仪表板、表单、导航系统、功能网格或其他组件类别。
• 媒体框架：生成的图像通常应放在清晰且便于实现的框架中，并保持稳定的纵横比、一致的裁切逻辑、圆角、阴影和间距。除非用户明确要求这种方向，否则避免尺寸随意的图片或杂乱无章的拼贴。
• UI 克制：仅当小标签、功能胶囊、仿系统标记、虚构指标和装饰性仪表板术语能帮助理解产品时，才可使用。如果它们只是视觉填充内容，就应在验收前移除。

概念评审模式

仅当用户要求先生成概念、评审方案或等待批准时使用。

• 生成并展示概念。
• 持续迭代，直到用户批准。
• 用户仍在评审时，不要开始实现。
• 概念获批后，将其视为当前生效的规范，并遵循以下保真度工作流。

编码前

编码前，将已接受的概念转化为设计系统和实现清单：

• 精确的可见文案、导航项、CTA 标签、版块标题、证明信息、数据标签和重要 UI 文本。
• 按版块/状态整理的图片清单：源概念截图、原生宽高比、视觉优先级、可读文本、字体关系、间距、按钮/控件样式、组件/容器规则、主色，以及需要重新提取截图才能解决的未决细节。
• 首屏可用文案列表：来自已采纳概念或用户提供文案、允许显示的所有 Hero、导航、眉题/引导语/前置标题、徽章/胶囊、CTA、标签和证明文案。
• 首屏构图、版块顺序、后续状态、响应式延续方式，以及下一版块预览。
• 版块衔接方案：说明相邻版块如何沿用已采纳的设计系统，以及允许使用哪些主要组件系列。除非用户提出要求，或必要工作流无法正常运行，否则未展示的主要组件一律视为禁止使用。
• 品牌标记、图像用途、产品模型、仪表盘、表格、图表、地图、媒体轨道、表单、HUD 或其他视觉元素。
• Hero/媒体处理清单：明确记录每张图像是无叠加层、纯色叠加层、渐变叠加层、边缘渐隐、蒙版、透明背景，还是匹配背景色。编码前须明确记录。
• 独立素材需求：如果概念中包含徽标、品牌标记、产品标签、包装、海报、标牌、产品渲染图或品牌背景物件，请在实现前使用 Image Gen 编辑并创建匹配的独立素材，以保持品牌风格一致。
• 游戏素材需求：如果概念是游戏，请在实现前使用 Image Gen 创建匹配的生产级美术素材。按需包含透明精灵/状态素材、地块/平台、收集物、危险物、目标物件、道具和视差/背景图层；碰撞箱和游戏状态使用代码实现，不能用代码替代可见美术素材。
• 从图像中采样或近似得出的设计令牌：背景、表面、文本、弱化文本、边框、阴影、强调色、语义色、圆角、层级、间距比例和动效时长。
• 颜色锁定：明确指出概念背景是纯白、米白、奶油色、灰色、深色还是带色调，并准确实现该选择。不要对调色板进行暖化、冷却、弱化或其他所谓“美化”处理。
• 字体系统：字体系列/回退字体、字号比例、字重、行高、字距、标签样式、标题/正文/说明文字样式、控件文本样式和响应式字体行为。
• 图标清单：记录每个可见图标、字符、尖括号、类徽标标记、工具栏符号、状态符号和空状态符号；注明其含义、来源系列、线框或实心样式、描边宽度、尺寸、颜色、容器、对齐方式、间距，以及选中/悬停/禁用样式。
• 组件系列和变体：按钮、导航、行、面板、媒体框、产品模型、仅在概念中出现的卡片、表格、表单、标签、图标、空状态、响应式变体、悬停/焦点/选中状态。
• 复杂应用 UI 的组件架构方案：应用外壳、导航、主要功能区域、可复用 UI 基础组件、数据/状态辅助模块、图表/表格/表单模块、素材模块和响应式布局边界。优秀的前端实现应有清晰的组件职责，而不是把所有内容塞进一个庞大的 App 组件，或重复粘贴零散标记。
• 容器模型：卡片、面板、轨道、色带、列表、表格、画布、抽屉、侧边栏、模态框或通栏版块。
• 核心工作流：必须可交互的控件、选中状态、筛选器、标签页、编辑、创建流程、成功状态、播放、游戏控制或生成结果演示。

如果概念未包含必需的后续版块、状态、移动端视图，或复杂区域缺少可读细节，而视觉一致性或素材提取存在不确定性，请生成匹配的版块/状态/细节概念。否则，请严格沿用同一视觉系统进行扩展。

实现

• 首先构建真正可用的界面，而不是围绕未来应用搭建营销包装。
• 遵循仓库的框架、路由、组件、样式、状态、无障碍和资源约定。
• 在没有现有框架约束的情况下创建复杂的新应用 UI 时，默认使用 React + Vite。按照资深前端工程师的方式组织代码：使用精简、专注的组件，清晰的应用外壳，为重复控件创建可复用的基础组件，为仪表板、表格、图表和表单创建特定功能模块，将示例数据和状态辅助逻辑分离，并使用共享设计令牌和样式。让 App 负责组合，而非实现一个庞大的单体页面。
• 根据从图像中提取的设计系统进行实现。相似元素必须使用同一组件或共享样式基础；差异应通过明确的变体体现，而不是复制一份 CSS 临时处理。
• 严格按照已接受的概念进行实现。保留文案、层级、区块顺序、信息密度、颜色、字体、间距、圆角、边框、阴影、素材构图和交互模式。
• 对于多区块页面，按照已接受的区块概念分阶段实现。从首屏开始，将浏览器截图与区块概念进行比较，修正明显偏差，然后逐区块继续。不要等整页编码完成后才统一进行视觉比较；也不要仅仅因为全景概览图更容易参考，就合并或简化各区块特有的设计决策。
• 将各区块衔接成一个协调统一的页面，但不要添加未经批准的大型 UI 组件。使用间距、背景色带、对齐方式、字体节奏、重复图案和媒体构图来衔接各区块。除非已出现在已接受的概念中、用户明确要求，或记录为具体的功能必要项，否则不要为了让页面看起来完整而凭空添加新的轮播、折叠面板、价格区块、仪表板、表单、标签页系统、功能卡片网格或其他大型组件。
• 概念获得认可后，除非相关文案出现在已接受的概念中、由用户提供，或记录为有意偏离，否则不要在首屏可见区域添加新的文案、主视觉眉题/引导语、说明标签、副标题或分类文字。如果语义化 HTML、SEO 或无障碍需求要求修改 H1 或标题级别，应先调整元素语义；不要凭空添加可见文案来补偿。
• 不要添加已接受设计中没有的装饰性主视觉眉题标签、胶囊、徽章、渐变、光晕或叠加层。除非概念确实符合渐变的配色、方向、强度和位置，否则不要改用渐变处理。如果已接受的主视觉图片没有颜色叠加层，就不要添加半透明色调、色彩蒙层或彩色图层。如果图片需要处理才能与不匹配的页面背景自然融合，应使用匹配的素材、透明抠图、边缘渐隐、蒙版，或在图片周围添加背景渐变，而不是在图片上叠加颜色。不要将白色背景替换为米色、灰白色，也不要以其他方式改变已接受设计的色温。
• 为控件明确设置字体样式。按钮、标签页、输入框、工具栏、侧边栏、检查器面板、图层行、状态栏、命令面板或导出/分享控件，不要依赖浏览器默认样式或继承的 16px 字号。
• 保留容器模型。如果规范使用开放留白、色带、轨道、列表、表格、画布或通栏构图，就不要添加卡片、带边框面板、浮动容器、瓷砖或卡片网格。
• 真实交互式应用 UI 中的文字、导航、按钮、表单、表格、控件和标签都必须使用代码实现。产品图片、海报、包装、标牌、背景场景、主视觉照片或其他栅格素材中的文字与品牌元素不在此限。不要把静态截图当作 UI 交付。
• 使用 Image Gen 生成核心的非图标素材。生成产品图片和背景素材时，应完整呈现所需的文字、徽标、标记、标签、包装、标牌和品牌元素。当素材需要叠放在 UI 上时，应要求透明背景或干净抠图。需要准确呈现文字时，应引用确切的素材文字，并要求逐字呈现。
• 如果已接受的设计包含品牌产品图像，应使用 Image Gen 编辑功能，根据概念图或匹配素材生成独立的徽标、产品、包装或标牌素材。如果这些素材需要叠放在 UI 上，还应提供透明背景版本。不要用通用 CSS、不匹配的字体或近似标签来重建带品牌的栅格素材。
• 对于游戏，使用 Image Gen 生成可见的正式美术资源：角色/状态精灵或精灵图集、地形/平台图块、收藏物、危险物、目标/检查点、前景道具，以及视差/背景图层。不要因为画布绘制更简单，或便于处理碰撞、缩放或动画，就退而使用画布绘制的图形。HUD 文本、分数、控件、碰撞箱、物理效果和游戏状态应使用代码实现，并根据渲染后的素材调整碰撞几何形状。任何使用代码绘制或矢量制作的游戏美术，都必须列为有意偏离或具体阻碍。
• 不要用粗糙的 CSS 绘图、通用渐变、占位 SVG 或类似图库素材的裁剪图替换概念素材。图像必须自然融入构图：背景色、光线、边缘、裁切、阴影和透明度都应与周围设计协调。SVG 可用于忠实呈现图标和方向性字形。
• 箭头、尖括号、插入符号、展开/收起指示符、分页箭头和轮播箭头应使用 SVG/图标组件；除非概念本身就采用，否则不要使用纯文本字符。
• 其他视觉元素应如何忠实呈现，图标也应如此。优先使用仓库现有的图标集；只有在与已接受设计的风格一致时才使用 lucide。否则，应创建符合概念的小型自定义 SVG/图标变体。自定义 SVG 图标必须达到生产质量：viewBox 清晰、几何形状简洁、描边宽度一致、连接和端点对齐、负空间均衡、视觉居中、路径可缩放，不得出现锯齿或占位图形的观感。只有当 currentColor 或显式填充符合设计系统时，才使用它们。不要将实心图标替换为线框图标、将圆角图标替换为尖角图标、将粗描边替换为细描边，也不要用通用符号替代特定隐喻。图标颜色、视觉尺寸、基线对齐、内边距和交互状态都应与提取出的图标清单保持一致。
• 让应用界面具备真实体验：根据需要实现本地状态、有意义的选中状态、可用的筛选器/标签页/表单、可编辑或可创建的项目、成功状态、播放控件、游戏控件，或模拟生成结果。
• 只有在确实合适时，才在主视觉中加入交互式 UI，例如 SaaS/软件产品预览、产品演示或有明确用途的交互动画。不要为了交互而在品牌宣传、编辑、产品、场地、美食、消费品或背景主导的主视觉中硬塞虚假的交互界面。忠实还原设计并保持品牌一致，比添加交互更重要。
• 仅在有助于设计时添加动效。遵循无障碍要求，并尊重 prefers-reduced-motion。
• 保持实现面向生产环境：使用语义化标记，采用稳定的响应式尺寸，避免脆弱的硬编码技巧，并在仓库支持时执行类型检查、lint 和测试。

验证

运行应用并验证实际可见的产品，而不只是构建结果。

1. 优先使用 Browser/IAB。加载应用，检查首屏，滚动页面，并点击体验核心工作流。
2. 检查桌面端、当前浏览器视口和移动设备尺寸的视口。
3. 捕获或找到已接受的概念稿和最新的实现截图。在同一轮 QA 中，对两者都使用 view_image；最终交付前不得跳过这一步，也不得用浏览器中随手一瞥来代替。
4. 条件允许时，以已接受概念稿的原生尺寸捕获实现效果。如果无法做到，记录阻碍原因，并同时验证当前浏览器视口。
5. 最终定稿前撰写保真度记录：不一致之处、概念稿证据、渲染证据，以及已修复的内容或未修复的原因。对于包含多个分区或状态的规范，须提供相关分区／状态概念截图的证据，而不只是总览。检查至少五个具体对比点，涵盖文案、布局、字体、配色／渐变、素材处理、间距／容器模型、响应式行为或动效。
6. 并排比较文案、导航、CTA 标签、分区顺序、首屏布局平衡、下一个分区的可见程度、配色、渐变处理、字体风格、字号层级、间距、边框、圆角、容器模型、素材／背景融合效果、动效和模拟交互。
7. 对首屏可见文案与获准文案列表进行差异比对。新增、删除、改名或重新排序的可见文案必须修复，或列为有意偏差；未经批准的新增内容不符合保真度要求。
8. 全面检查各处的排版，而不只是主视觉区或主画布。检查标题、正文、说明文字、标签、工具栏控件、侧边栏行、标签页、输入框、检查器字段、状态栏、命令面板、导出／分享按钮、表格单元格、图表标签和移动端换行情况。如果截图显示有偏差，则检查计算后的 CSS 字号、字重和行高。
9. 检查所有出现图标的位置：导航、按钮、卡片、工具栏控件、侧边栏、表格、状态指示器、空状态、分页控件、轮播控件和移动端控件。对照已接受的概念稿，检查图标所表达的含义、描边／填充样式、尺寸、颜色、对齐方式、视觉权重、间距和状态变化。
10. 对于画布／编辑器应用，须单独检查应用外框与画布／文档文字。默认缩放和画布平移属于规范内容；验证时，已持久化的本地状态不得掩盖种子、比例或排版修复效果。
11. 明确自问：这个实现是否足以通过代理机构的签核？一流的专业设计代理机构会认可已接受设计稿的这一具体实现吗？如果任何问题可能在设计评审中被指出，就写出具体的修复清单并继续编辑。不得在仍有可修复的视觉问题时给出最终答复。
12. 验证生成的素材均已加载、取景恰当，且不会遮挡文字或控件。
13. 验证核心工作流确实会更新真实的本地 UI 状态。不得交付无响应的控件、虚假的媒体进度、隐藏的必需媒体或占位交互。

功能 QA 不等于保真度 QA。构建检查通过、点击控件或验证本地状态，都不能取代与概念稿的截图对比、原生尺寸检查和书面的不一致记录。

硬性拦截项：主要内容被裁切、意外换行、布局看起来像原型、粗糙的种子数据、占位框、看起来像通用图库素材的素材、未完成的卡片、用代码绘制的游戏占位图替代概念图、杜撰的可见文案、杜撰的主视觉眉题／引导语／胶囊标签／徽章、颜色或渐变不匹配、把白色背景改成奶油色／灰白色、未经批准的主视觉图片颜色叠加或着色、缺失或通用替代图标、图标风格或描边粗细不匹配、图片与背景无法融合、过时的调试残留、文字难以辨认、字号层级偏差、控件使用浏览器默认字体、移动端溢出、响应式布局折叠得不专业，或任何与已接受规范的可见偏差。

表面要求

• 着陆页／公司网站：保留首屏视口、主视觉区域的作用、品牌／导航／CTA 标签、版块顺序、下一版块预览和标志性图像。
• 产品／SaaS 页面：保留产品模型图、工作流示意图、功能条、证明元素和品牌风格。
• 仪表板／工具：保留信息密度、侧边栏、页眉、表格、标签页、时间线、图表、地图、行数以及选中／详情行为。不要将表格驱动的概念改成卡片网格。
• 画布／编辑器工具：保留默认缩放／平移状态、画布／文档文字比例、界面控件密度、工具栏、侧边栏、检查器控件、图层行、状态栏、命令界面，以及自动保存／初始状态行为。
• 时间线／规划工具：保留网格／时间轴结构、行跨度、事件密度、状态栏和指挥中心适配情况。
• 仿制类界面：先保留可识别的基本布局，再进行润色。不要添加破坏产品类型的营销主视觉或自定义导航。
• 游戏：使用 Image Gen 资源保留美术风格，包括精灵、图块／平台、可收集物、危险物、目标点／检查点、道具和背景／视差层。验证资源能够正确加载、缩放、播放动画或切换状态，与碰撞几何体对齐，并支持移动、动作／跳跃／拖拽行为、计分、危险物和重新开始。
• 媒体界面：验证真实媒体能否加载、时长、播放／暂停、定位／进度以及可见画面变化。
• 表单／预订／购买／餐饮流程：验证主要交易路径和确认状态。

最终回复

包括已接受的概念路径、渲染截图的方法、浏览器／IAB 验证方法或采用 Playwright 替代方案的原因、使用 view_image 检查已接受概念和最新实现截图的情况、已检查的原生尺寸视口或阻碍因素、至少五个检查过的对比点、首屏文案差异检查结果、剩余的有意偏差，以及明确声明实现已按照已接受的设计进行了忠实验证。同时还要说明已修复的实质性差异和已验证的核心交互路径。如果没有剩余实质性差异，请直接说明。