ui-from-image

使命

将提供的参考图像视为视觉事实来源。

准确性优先于速度。不要满足于“差不多”。页面仅仅能够运行并不代表任务完成；只有渲染结果与参考图高度吻合，且不存在明显差异时，任务才算完成。

多做几轮验证，不要减少验证次数。如果文字可能有误、控件显得拥挤、间距不稳定，或某个视口掩盖了布局问题，就继续迭代。

除非此技能要求的所有强制验证和报告步骤均已完成，且不存在已知的可见差异（明确说明的轻微不确定性除外），否则不要将结果描述为“已经足够好”“可以发布”或类似说法。

默认输出

除非代码库已有其他规定的结构，否则使用：

• index.html
• styles.css
• script.js

如果要适配现有前端或框架，请遵循代码库的文件结构，同时尽可能清晰地分离标记、样式和行为。

工作模式

• 对于独立项目，默认使用纯 HTML/CSS/JS，除非环境已包含用户希望保留的样式系统。
• 如果仓库中已有 Tailwind/DaisyUI 配置，请复用。
• 如果仓库已有其他成熟的样式系统，除非用户明确要求，否则不要引入 Tailwind/DaisyUI 作为第二套竞争系统。
• 如果已有 Tailwind/DaisyUI，或用户明确要求使用，则将它们视为实现工具，而非设计准则。只要默认样式与截图不符，就应覆盖。
• 首先在主截图的确切尺寸下实现高度还原。
• 对于桌面网页，不要将窄版模型图或 POC 截图视为最终的真实桌面页面宽度。完成参考尺寸版本后，优先适配到约 1900px 宽的真实桌面视口；考虑滚动条和浏览器常规界面，可采用约 1900px 而非 1920px。
• 只有参考尺寸版本在视觉上已高度接近后，才开始适配平板和移动端。

当用户提供更新或修订后的截图时，以最新截图为准。

高保真规则

• 尽可能贴合布局、间距、字体、行高、字距、颜色、边框、边框透明度、阴影、渐变、圆角、图像裁切/宽高比和视觉层级。
• 如果默认值不够贴合，就为宽度、高度、最大宽度、内边距、外边距、间隔、圆角、字号、行高、字距和阴影指定明确数值。
• 将文本还原度视为布局问题，而不仅仅是内容问题。如果文本被裁切、过于拥挤、被截断、换行不当，或导致附近控件错位，页面就尚未完成。
• 将数据可视化和比例图形视为布局关键型界面，而非装饰性近似。图表绘图区、坐标轴、图例、分段宽度、地图区域、漏斗、仪表盘、时间线和图形形状都必须在比例和对齐上足够贴合，让用户觉得它们是同一个界面。
• 所有可见细节都必须还原，包括微小细节：
  • 小型徽标和按钮图标
  • 搜索图标
  • 下拉箭头
  • 分页箭头
  • 当前导航项的下划线/辉光
  • 状态圆点
  • 项目符号的颜色
  • 卡片图标
  • 星标/收藏图标
  • 分隔线
  • 细微的圆角差异
  • 文本透明度变化
• 控件中缺少小图标或徽标属于还原失败，不是轻微遗漏。
• 不要重新设计、简化、添加装饰或“改进”界面，除非响应式布局确有需要，或参考内容确实存在歧义。
• 如果 DaisyUI 的排版、按钮、输入框或间距默认样式与参考不符，不要默默依赖这些样式。

现有前端适配模式

在现有前端或设计系统中工作时：

• 创建新结构前，先检查当前代码库。
• 尽可能复用现有布局外壳、共享组件、实用模式、排版标记、间距比例、断点、图标规范和主题变量，以忠实呈现参考设计。
• 优先调整附近已有的页面或版块，而不是从头创建平行实现。
• 除非用户明确要求，否则不要引入重复组件、冲突的设计标记或第二套样式系统。
• 如果截图与既有设计系统冲突，应保留截图的页面级构图，同时尽可能与当前标记和组件保持一致；除非用户明确要求截图覆盖当前设计语言。

参考图接收与断点处理

• 编码前记录每张参考图的确切尺寸。
• 在主要还原阶段，尽可能以参考图的确切视口尺寸（CSS 像素）渲染页面。
• 如果参考桌面图明显窄于现代桌面视口，应将该宽度视为构图／样式参考，而非实际页面最终的桌面宽度。保留截图的结构、层级、间距意图和视觉语言，然后将实际桌面实现扩展至约 1900px 的视口宽度并进行验证。
• 如果提供了桌面／平板／移动端的多张参考图，应将每张图视为对应断点的权威参考。
• 如果只有桌面参考图，应在保留层级、顺序和视觉平衡的基础上推断平板／移动端布局，不要凭空添加新版块或交互。
• 如果文字清晰可辨，应逐字还原，包括标点和小型辅助标签。
• 如果文字不清晰，应采用最接近的合理近似，并说明不确定之处。
• 如果截图展示的是页面裁剪区域而非完整页面，应优先匹配可见区域。

视口真实性与缩放安全

• 将浏览器缩放、操作系统 DPI 缩放和设备像素比视为实现必须适应的环境因素，而非扭曲布局的借口。
• 如果可使用 Playwright 或类似的浏览器自动化工具，应将自动化工具在明确视口尺寸下截取的屏幕截图作为主要的保真度对比依据。
• 如果操作系统 DPI 缩放、浏览器缩放、窗口边框或桌面合成器行为可能影响用户在屏幕上看到的内容，就不要将带界面的浏览器窗口视为像素保真度的唯一依据。
• 尤其是在 Windows 上，即使页面布局在 CSS 像素下正确，非默认的桌面缩放或浏览器缩放也可能使带界面的浏览器产生视觉误导，应对此有所预期。
• 如果 Playwright 报告已打开 chrome 或 msedge 浏览器/通道，这仍然属于由 Playwright 驱动的验证。除非确实放弃了浏览器自动化，否则不要将此描述为“切换离开 Playwright”。
• 不要使用 CSS zoom、根级 transform: scale(...)、合成包装器缩放或类似的视口技巧，让实现的屏幕截图看起来更接近参考图。
• 不要通过缩小整个页面或扩大画布来“修复”宽度、拥挤程度或首屏位置不匹配的问题。
• 应通过实际调整布局来解决屏幕截图中的差异：
  • 正确设置容器宽度
  • 正确设置网格和弹性布局尺寸
  • 正确设置间距和内边距
  • 正确设置字体大小和行高
  • 正确设置控件高度和固有宽度
  • 正确设置响应式断点
• 如果出现浏览器特有的差异，应首先检查实现中的布局假设是否无效、是否存在溢出或缩放技巧，再考虑用户的环境是否有问题。
• 如果带界面的浏览器窗口与在校准视口下使用 Playwright 截取的屏幕截图不一致，在进行保真度工作时应优先相信屏幕截图，并通过额外的截图检查实现，再将差异归因于用户的设备。
• 报告保真度状态时，应区分以下情况：
  • 用户或浏览器缩放偏好导致的预期重排差异；以及
  • 水平溢出、宽度计算错误、换行异常或断点行为脆弱等实际布局缺陷。

滚动适应性检查

对于包含粘性/固定侧边栏、工具面板、检查器、菜单或任何视口高度区域的布局：

• 验证所有内容高度超过视口的区域都可以独立滚动。
• 固定/粘性面板不要只依赖 height: 100vh；对于内容可能超出可用高度的区域，应添加适当的 overflow-y: auto。
• 如果设计包含全高侧边栏或工具面板，应至少在一种更矮的桌面视口高度或类似缩放的条件下进行测试。
• 确认底部控件、页脚操作、账户卡片、折叠按钮和次级导航仍可触达。
• 应将无法触达面板内容视为功能性布局缺陷，而不只是视觉差异。

持久导航与面板宽度

对于持久导航、侧边栏、轨道、检查器和工具面板：

• 验证展开后的标签在桌面和宽屏/类似缩放的桌面宽度下均能完整显示，且无需内部水平滚动。
• 检查面板内部是否发生水平溢出，而不仅仅是检查 document.documentElement。
• 如果面板中包含标签、图标、徽标、计数器、账户控件、折叠按钮或页脚操作，应截取面板的局部放大图。
• 优先确保面板有足够的固有宽度，为标签使用 nowrap/省略号，允许面板独立滚动，并明确设置折叠断点，而不是让面板内容被挤压或产生水平滚动条。
• 验证折叠或仅图标状态不会过早、过晚触发，也不会仅仅因为文字无法容纳而触发。
• 应将标签被裁切、面板级水平滚动条、页脚控件被隐藏，以及标签与图标/徽标重叠视为布局缺陷。

数据表和面板页脚

对于卡片、面板、数据表、网格和列表模块：

• 检查内部滚动容器，而不只是页面级溢出。即使文档宽度正常，表格或网格也可能有自己的水平滚动条。
• 确认页脚链接、CTA、分页、摘要行和次要操作在视觉上仍位于卡片或面板边界内。
• 对于列数较多、文本禁止换行、包含头像、徽章、行菜单、分页或页脚 CTA 的表格／列表面板，截取重点区域。
• 优先采用明确的列宽设置、表格布局规则、响应式行卡片替代方案，或带有明显提示的有意水平滚动，避免意外溢出。
• 将意外的内部水平滚动条、被裁切的行操作图标、操作单元格溢出后多余的文本省略号，以及越过面板边框的页脚链接视为缺陷。

预检清单

开始实施前，明确检查并梳理以下内容：

1. 页面各个区块及其顺序
2. 网格／列结构和大致宽度比例
3. 主要容器和卡片边界
4. 所有文本块和标签
5. 所有可见控件及其交互状态
6. 所有图标、徽标、徽章、标签、状态点、分隔线和装饰性标记
7. 所有图像资源和背景图形
8. 字体排版分组（主视觉标题、正文、胶囊标签、按钮、表头、表格行、侧边卡片、通知等）
9. 主要、次要、弱化、成功、警告、危险和强调色
10. 可能的响应式设计意图
11. 文案长度、标签数量或控件密度可能导致拥挤的区域
12. 参考断点处必须保持单行显示的行或面板
13. 每个数据可视化元素，包括其卡片边界、绘图区边界、坐标轴、标签、网格线、图例、控件、标记位置、系列形状和空白边距
14. 每个比例图形或示意图，包括相对区段大小、渐缩方向、对齐方式、标签、填充、描边和周围留白
15. 逐项对照参考图检查每个导航或工具栏图标，包括激活状态、徽章位置、描边粗细，以及图形本身是否表达相同概念

在脑海中全面梳理所有具有视觉意义的元素后，再开始编写代码。

排版审查

排版是还原度的核心目标。

• 首先检查仓库中现有的字体资源：
  • 全局 CSS
  • Tailwind 配置
  • DaisyUI 主题配置
  • 设计令牌
  • 现有页面组件
  • 本地字体文件
• 如果现有项目字体与参考图相符，请使用该字体。
• 如果参考图似乎使用了自定义字体或非默认字体，而无法获取确切字体，请选择最接近的可用选项，并明确报告这一限制。
• 不要未经检查就默认使用通用的 DaisyUI／正文排版。
• 确认实际渲染的回退字体，而不仅仅是声明的 font-family。首选字体可能并未安装，而已安装的字体在视觉上可能比参考图更宽、更窄、更粗或更柔和。
• 为每种视觉分组明确设置排版：
  • Logo 文字
  • 导航链接
  • 胶囊标签／徽章
  • Hero 标题
  • 引导段落
  • 统计标签
  • 统计值
  • 辅助文字
  • 筛选标签
  • 表单标签
  • 表格标题
  • 表格行
  • 侧边栏标题
  • 通知／时间戳
  • 主要和次要按钮
• 不仅要检查字体，还要检查：
  • 字号
  • 字重
  • 行高
  • 字间距
  • 字形的视觉宽度／字符适配
  • 大小写
  • 颜色／不透明度
• 除非参考图中明显使用了宽字间距，否则避免人为增加字间距。给大号数字、标题、表格文字或导航标签额外增加字间距，会让界面看起来像被放大了，还可能导致本可避免的截断。
• 对于信息密集型仪表盘、表单、表格、导航栏和运营界面，请比较常见标签和值所占的水平空间是否与参考图相近。如果文字看起来太宽，可尝试更接近的系统字体栈、移除不必要的字间距、减轻字重，或调整特定分组的字号，然后再修改布局。
• 在参考图对应的宽度下验证文字换行和断行。如果标题或段落的换行方式与截图不同，请修正。
• 验证控件和信息密集型界面的文字完整性：
  • 不应出现意外截断
  • 上伸部和下伸部不得被裁切
  • 行高或控件高度不当导致的垂直挤压
  • 标签与辅助文字不得互相覆盖
  • 占位文字不得溢出输入框

图标与完整性审查

在宣布页面完成之前，请确认参考图中每个具有视觉意义的图标或标记都已在 DOM 中呈现。

这包括：

• Logo 标记
• 侧边栏、标签栏、工具栏和命令面板图标
• 按钮内的品牌图标
• 搜索图标
• 下拉箭头
• 统计卡片图标
• 状态指示器
• 行、表格、列表和卡片操作图标
• 地图 / 通知项目符号
• 表格收藏图标
• 分页箭头
• 关闭 / 重置 / 筛选图标
• 任何细微的行内符号

规则：

• 小型 UI 图标也算作资源，不得省略。
• 必须逐项审查导航图标。只有在参考图中的字形确实无法辨认时，才可以使用通用占位图标；否则，应匹配相同的视觉隐喻、描边粗细、尺寸和对齐方式。
• 必须将重复的行操作图标作为整体并逐一审查。确认保留了其预期语义，例如评论与编辑、打开 / 外部链接、复制、删除和更多选项之间的区别；不要用外观相似但含义不同的控件替代。
• 对于网页和 Web 应用，优先使用仓库中已有的图标；只有在字形足够简单、可以准确复现，且经过针对性的视觉检查确认与参考图一致时，才使用简单的内联 SVG。
• 将复杂图标、精细的象形图、自定义插画按钮、品牌控件、徽章、奖章、标签页、切换控件、游戏风格控件、定制 UI 装饰、纹理表面以及其他视觉上鲜明独特的 UI 元素视为资源；使用 SVG / 代码复现可能不够可靠，或会明显失真。
• 当图标具有可辨认的轮廓、镂空、星形尖角、弯曲弧线、品牌特征几何形状或特定的视觉隐喻时，不要依赖 CSS 伪元素、边框或 clip-path 技巧来绘制图标。请使用内联 SVG 或现有图标组件，确保图标清晰可见，且与参考图相符。
• 除非仓库已经使用某个图标库，或用户明确要求，否则不要添加新的图标库。
• 对于 UI 控件中常见的品牌标记（例如 Discord），除非仓库中已有合适的资源，否则请使用清晰的内联 SVG 或现有图标组件。

数据可视化与图表还原度

图表、示意图和密集的分析图形都需要单独进行明确的检查。不要将它们简化为泛泛的“看起来像图表”的实现。

对于每个类似图表的区域，记录并匹配：

• 分别记录卡片尺寸和图表区域尺寸
• 绘图区的宽度、高度，以及相对于卡片边缘的内边距
• 图例的位置、图例色块样式，以及与标题或绘图区之间的间距
• 轴标签数量、坐标轴所在侧、刻度标签位置和网格线数量
• 数据系列的颜色、描边宽度、虚线样式、曲线形状、标记大小和大致点位轨迹
• 图表周围控件的位置，例如分段按钮、下拉菜单、缩放控件、范围选项胶囊或工具栏
• 绘图区下方的摘要行／页脚行，包括列宽和分隔线

对于每种比例图形，记录并匹配：

• 整体边界框及其在卡片内的对齐方式
• 分段数量、各段的相对高度和宽度，以及它们是否收窄、扩展、重叠或呈阶梯状
• 各段内部或外部的标签位置
• 各段之间的颜色顺序、不透明度、边框、阴影和间隙
• 配套标签、标注框、图例或侧边指标，以及它们与图形之间的距离
• 文本是否完整位于预期分段内，或刻意置于其外，且没有标签溢出、裁切或拥挤

对于圆形图表，例如圆环图、饼图、仪表盘和径向进度指示器：

• 单独检查中心标签与图表形状。
• 根据参考图匹配中心标签的字号、字重、行高和垂直对齐方式。
• 确保在参考视口和响应式断点下，标签都能舒适地容纳在内圆中。
• 中心标签优先使用明确的 flex/grid 居中方式和行高。
• 如果中心标签显得拥挤、过大、偏离中心或被裁切，应先调整排版和内半径，再判定图表是否匹配。

实现建议：

• 对于漏斗、金字塔、仪表盘、径向图表、地图、节点图、复杂时间线和图标式示意图等非矩形比例图形，除非使用普通布局框即可精确匹配参考图，否则请使用内联 SVG。
• 当分段宽度、收窄角度、分隔间隙或标签位置需要精确还原时，避免使用堆叠 div、伪元素、边框三角形或 CSS clip-path 来近似复杂形状。只有在截图检查证明几何形状和文本容纳情况均匹配后，才可使用这些技术。
• 使用 SVG viewBox 时，应明确设置宽度、高度、多边形／路径坐标、文本锚点和标签位置，不要仅依赖自动缩放或居中布局。

如果图表或示意图显得太窄、太高、过于居中、过于简化，或与周围卡片在视觉上脱节，应将其视为几何不匹配。先调整容器轨道、绘图区内边距、SVG viewBox／宽高比、控件宽度和相邻列比例，再进行响应式处理。

布局适配与拥挤处理规则

对于参考断点：

• 先还原截图中的构图，再进行响应式适配。
• 不要过早通过重新设计、删除、缩小或重新排列主要分组来解决拥挤问题。
• 不要通过 CSS 缩放整个页面，或依赖对浏览器缩放比例的假设来解决拥挤问题。
• 先穷尽所有能保留还原度的方案：
  • 匹配参考视口尺寸
  • 调整容器宽度和侧栏宽度
  • 将间距收紧或放宽至测量值
  • 使用正确的字号和行高
  • 使用正确的控件宽度和最小宽度
  • 为各个网格列设置正确的轨道尺寸，而不是将所有空间平均分配
  • 为密集控件提供实际所需的宽度，再考虑缩小相邻元素
  • 仅在截图表明需要换行时才使用换行
  • 检查参考布局是否确实使用了多行
• 只有在以下情况下，才在参考断点将控件移至其他行：
  • 截图明确显示了多行，或
  • 用户提供了显示更新后结构的新截图。
• 如果经过一轮调整后控件仍显得拥挤，应假定比例仍不正确，并继续迭代。不要把拥挤视为“足够好”。
• 对于更窄的断点，应在保留层级和视觉平衡的同时进行整洁的重新排布。

颜色、表面与效果审查

• 尽可能准确地匹配主表面、次级表面、柔和表面、边框、光晕、阴影、渐变和文本不透明度。
• 尽可能从参考图中取色或估算颜色，而不是凭空设计新颜色。
• 注意以下方面：
  • 背景渐变
  • 细微的边框透明度
  • 面板透明度
  • 参考图中可见的悬停／激活强调效果
  • 主内容与侧栏卡片之间的对比差异
  • 徽章、实时指示器、按钮和高亮元素之间的强调色一致性

资源处理工作流

直接使用 image_gen 的规则

当缺少栅格素材，且这些素材能显著改善实现效果时，默认直接使用原生 image_gen 工具。无需要求安装单独的 imagegen 或 imagen 技能。

运行 image_gen 后，除非用户明确要求仅输出图像，否则请在同一轮中继续处理。简要说明生成了什么，在可用时提供保存的文件路径或素材引用，评估其是否符合请求，并继续进行保存、集成和验证。

如果 image_gen 不可用或运行失败，则使用占位素材，并为每个缺失素材提供一条独立的生成提示词。

直接使用 image_gen 的操作规则：

• 如果生成的输出用于实现，则将其视为项目专用素材。内置工具可能会将其保存到 $CODEX_HOME/generated_images/；在代码中引用前，请将选定的最终素材移动或复制到工作区。
• 不要依赖为内置工具指定目标路径的参数。先生成，再移动或复制选定的输出。
• 除非用户明确要求替换，否则不要覆盖现有素材。请改用同级文件名，例如 hero-v2.png 或 card-thumbnail-generated.png。
• 对于多个缺失的栅格素材，如果它们彼此相关且能整齐地放在同一画布上，优先生成一张或多张素材图集，而非每个素材单独生成一张图。
• 如果素材数量过多、视觉风格不相关、需要不同风格或差异很大的纵横比、包含大量文字，或从同一张素材图集中提取会导致素材过小而无法准确提取，则使用多张素材图集。
• 编辑本地文件时，先用 view_image 检查文件，使其显示在对话上下文中。为每张输入图标注用途，例如编辑目标、风格参考、构图参考或辅助插图。
• 提示词应简洁地说明素材类型、在 UI 中的用途、主体／内容、构图／取景、风格／媒介、光线／氛围、配色、确切文本（如有）、约束及需要避免的内容。对于编辑任务，请重复说明不变项，例如“仅更改 X；保持 Y 不变”。
• 不要将备用 CLI/API 控件（例如质量、输入保真度、蒙版、输出格式或输出路径）当作内置 image_gen 工具的参数。

要求透明背景时，在完成前请验证保存的 PNG 确实具有 alpha 通道。使用 Pillow 或 .NET System.Drawing 等工具检查元数据或像素；有效的透明 PNG 应支持 alpha 通道，例如 RGBA 或 Format32bppArgb，且代表性背景像素（例如四角）应具有 alpha 值 0。如果生成的文件带有渲染出的棋盘格或纯色背景，请勿直接修改该文件；应创建一个名称清晰的修复版本，例如 *-transparent.png，并重新验证修复后的输出。

素材表生成与提取

需要生成多个缺失的栅格素材时，默认采用素材表工作流：

1. 将风格兼容的素材合并到同一个素材表提示词中。按共同的风格、光照、透视、媒介和目标用途分组。需要不兼容风格、精细文字、精确品牌标识、差异很大的比例或大量细节的素材，应分别放在不同的素材表中。
2. 要求生成整洁的联系表或精灵图：每个单元格放置一个素材，留出充足间距，比例保持一致，主体正面朝向或构图清晰，不重叠，不让阴影跨越单元格边界，除非 UI 素材本身需要文字，否则不要添加标签；背景使用平坦且可移除的颜色，且该颜色不应出现在素材中。
3. 需要透明效果时，优先使用高对比度的纯色背景，例如纯洋红色、青色或其他色键颜色。不要指望图像模型生成真正的透明背景，也不要要求生成棋盘格透明背景。
4. 生成后，将选定的素材表复制到工作区，然后使用本地脚本提取单个素材，优先使用 Python Pillow。保留原始生成素材表，不作修改。
5. 提取时，裁剪每个单元格或检测到的对象，移除色键背景或与边缘相连的中性色背景，裁掉透明边距，添加所需的安全边距，并使用清晰的文件名将每个素材保存到项目素材文件夹。
6. 确认每个提取出的透明 PNG 都采用支持 Alpha 通道的模式（例如 RGBA），并且具有代表性的背景像素／角落像素的 Alpha 值为 0。将提取出的素材集成前，先进行目视检查。
7. 集成提取出的单个文件，而不是完整素材表，除非实现方案有意使用精灵图。
8. 如果提取过程损坏边缘或移除了内部细节，应保留原始素材表、修复提取蒙版，或使用更清晰的间距／背景重新生成，再使用该素材。

如果生成的素材很可能保持较大且易于分离，请使用一个素材表。如果单个素材表会导致素材过小、含义模糊、难以裁剪或风格不一致，请使用多个素材表。

首先，盘点页面所需的所有可见素材：

• 徽标
• 主视觉图片
• 缩略图／卡片
• 地图
• 头像
• 图标
• 自定义按钮和按钮图案
• 自定义控件、开关、标签页、徽章、奖牌、贴纸、光标、手柄、旋钮或 UI 装饰元素
• 桌面／游戏／应用专属界面装饰、HUD 元素、菜单板、物品栏槽位、工具图标或装饰性界面组件
• 插画
• 背景图形
• 任何其他非文本视觉元素

为每个素材恰好选择一种处理方式。

1) 用户已提供素材

• 使用前先进行目视检查。
• 在适当的位置使用。
• 根据参考构图的要求进行裁剪、调整尺寸、留边、修边或蒙版处理。
• 保持宽高比；切勿拉伸变形。
• 根据实际情况使用 object-fit: cover 或 contain。
• 如果素材分辨率较低或存在其他瑕疵，应尽可能贴近参考效果，并说明限制。

2) 缺少资源，应当生成

• 如果 image_gen 工具可用，请直接使用它来生成或编辑资源。
• 如果可以一次生成多个缺失资源，默认使用资源表工作流，然后在本地提取单个文件。
• 如果只缺少一个资源，或某个资源需要独特的构图／细节，请单独生成。
• 对于网页和 Web 应用，仅当可以在视觉上匹配时，才将简单的 UI 图形实现为内联 SVG 或使用仓库中现有的图标；否则请将其生成为图像资源并提取出来。
• 对于非 Web UI（例如桌面应用、游戏 HUD、菜单、库存界面、启动器或高度定制外观的工具），除非代码实现能够忠实还原并经过验证，否则应将许多自定义 UI 元素视为图像资源。
• 将生成的资源保存在仓库现有的资源目录中；如果没有约定目录，则使用 assets/generated/ 等合理目录。
• 更新使用该资源的代码或标记，使其引用生成的资源。
• 验证每个提取或生成的资源在布局中的视觉效果和尺寸是否合适。
• 如有需要，请重新裁剪、重新生成或迭代，直至资源在上下文中正常呈现。
• 如果 image_gen 不可用、生成失败，或在当前轮次中无法修复提取结果，请使用明确标注的占位图，并为每个仍缺失的资源输出一条独立的生成提示词。

3) 缺少资源，但不应生成

对于专有品牌标识、需要准确真实来源素材的资源，或用户明确要求不要生成图像的情况，请使用此路径。

• 使用明确标注的占位图，并设置合适的大致尺寸、宽高比、圆角、位置和视觉权重。
• 如果你自行创建或合成临时替代资源，而非使用通用占位图，仍须在缺失资源报告中将其视为缺失。
• 切勿悄悄使用替代图、代理插图或合成替代品，然后在最终缺失资源报告中不予说明。
• 除非用户明确要求不要提供提示词，否则请为每个缺失资源准备一条独立且可直接使用的生成提示词。
• 不要在最终回复中将多个仍缺失资源的备用提示词合并成一条。资源表提示词用于当前轮次中的生成和提取，不应用于最终的缺失资源备用提示词区块。
• 每条提示词都必须完整独立；但在最终回复中，所有仍缺失资源的提示词都必须放在同一个带围栏的 text 代码块中，方便复制／粘贴到其他 AI／LLM 中。
• 使用清晰的分隔符（例如 ---）分隔代码块中的各条提示词。
• 每条提示词都必须包含：
  • 资源名称／建议文件名
  • 在 UI 中的用途
  • 目标主体／内容
  • 构图／取景方式
  • 风格／氛围
  • 色彩／光照
  • 目标宽高比或尺寸
  • 透明度／背景要求（如适用）
  • 关键的“避免”事项

资产专属指南

• 简单的 UI 图标不应成为留白的理由。对于网页，如果可以通过视觉匹配并验证，请使用内联 SVG 或仓库中现有的图标来实现简单的字形图标。
• 不要强行将每个图标、按钮或自定义 UI 元素都转换为内联 SVG。如果参考图依赖自定义插画、纹理、复杂几何形状、绘画细节、阴影、浮雕样式、游戏或桌面界面装饰，或其他难以通过代码可靠还原的视觉效果，请使用栅格资源。
• 对于非 Web 界面，除非现有平台或代码库已提供匹配的组件，否则应更多地使用生成或提取的图像资源来实现自定义 UI 部件，而非内联 SVG。
• 对于重复出现的图标或快捷方式／导航标记，请在截图上下文中检查每个渲染后的图标；如果图标虽然存在，却过于模糊、被裁切、挤扁或难以辨认，仍应视为缺失。
• 对于未提供的品牌 Logo 或具有专有风格的标记，请使用占位图，除非用户明确要求临时生成一个替代品。
• 对于主视觉图片、缩略图、地图和其他醒目的视觉元素，请尽可能匹配裁切方式、焦点、宽高比和视觉权重。
• 如果参考图中有重复的缩略图卡片，请注意所有卡片的裁切方式和圆角保持一致。

实现工作流

1. 检查参考图，并建立预检清单。
2. 如果存在现有代码库，请先检查最相关的页面／组件／设计令牌／图标，再决定要复用哪些内容。
3. 先完成一版在视觉上已接近参考图的实现。
4. 运行页面或预览页面。
5. 在与参考图完全相同的视口尺寸下截取实现效果。
6. 将实现截图与参考图进行对比。
7. 编辑前先列出书面差异清单。优先处理最大的视觉差异，再处理细节。
8. 重复截图、列出差异并修复，直至不再有明显差异。
9. 对于任何图表、地图、仪表盘、时间线、漏斗、金字塔、树状图、关系图或其他分析类视觉元素，在确认主布局接近之前，专门进行一次视觉元素检查，对比其边界框、内部比例、标签和控件。
10. 对于密集、受限、重要或脆弱的组件，请截取重点组件的截图／局部图，并放大检查，不要仅依赖整页视图来判断。凡是文本、图标、徽章、控件、图表、图例、表格、头像或操作行必须适应有限空间的组件，都必须执行此步骤。
11. 完成前，至少进行一次明确的“脆弱性检查”，重点关注以下内容：

• 拥挤的行
• 被裁切或挤压的文本
• 重叠的元素
• 贴近卡片／控件边缘且留白不足的文本、标签或数值
• 组件边界处可能伸入相邻组件的卡片、列表、行、弹出层或工具栏
• 内容显示不下的控件
• 可能在宽度略有变化时出现问题的过紧间距
• 内容在更高缩放比例、DPI 缩放、更大字体或更短视口高度下可能溢出、重叠或无法访问的固定高度卡片、行、面板或粘性区域
• 圆环图、饼图、仪表盘、徽章、计数器和紧凑型图表标签的中心文本

12. 对于卡片网格、表格行、统计卡片、导航项或重复按钮等重复 UI 结构，请专门进行一次对齐检查，验证同组元素的基线、页脚行、按钮位置、标签行和媒体裁切是否一致。

浏览器验证可用时，不要只做代码编辑和 lint／构建检查就停止。构建／测试结果不能取代本技能要求的截图对比循环。

强制视觉验证工作流

当浏览器和截图工具可用时，以下检查阶段为必做项。

如果浏览器工具可用，而你还没有亲自捕获并检查截图，就说明工作尚未完成。不要声称工作已完成、已就绪或已验证。应继续操作，直到完成截图检查，或者明确报告无法执行的阻碍原因。

如果任务只更改了一个密集或视觉上重要的区域，而非整个页面，仍至少要捕获以下截图：

• 一张展示更改区域及其上下文的截图
• 一张更改区域本身的特写截图（如果工具支持元素截图或裁剪截图）

在最终报告中，绝不要暗示自己检查过截图，除非你在当前轮次中确实捕获并检查了这些截图。

在最终报告中，按类别列出实际进行视觉验证的产物：

• 已检查的整页或视口截图
• 已检查的组件特写裁剪图
• 已检查的缩放／适应性截图
• 未能执行的任何必需视觉检查，以及具体原因

除非在当前轮次中确实捕获并检查了对应产物，否则不要声称已完成组件裁剪、缩放检查、浏览器检查或响应式检查。

如果页面过长，无法通过单张截图可靠检查，请捕获多张分段截图，共同覆盖整个页面。优先覆盖顶部／中部／底部，必要时增加分段。不要假设未看到的下方区域没有问题。

对于长页面，推荐的验证方式如下：

• 如果工具支持，先捕获一张整页截图或可捕获的最长页面截图，以了解整个文档的整体纵向节奏、区块间距和宏观构图
• 同时捕获分段视口截图，通过有意设定滚动位置，覆盖从页面顶部到底部的所有内容
• 亲自检查这些分段截图；对于长页面的下方区域，不要只依赖整页截图，因为长截图可能掩盖拥挤、文字裁切、固定定位元素重叠或细微的对齐错误
• 确保分段截图完整覆盖整个页面，检查范围之间没有遗漏
• 如果某个区块特别密集或容易出错，请为该区域额外捕获局部截图，而不要假设最近的分段已足够

将整页截图作为宏观构图参考，将分段截图作为长页面保真度检查的权威依据。

阶段 0 - 视口校准

• 首轮对比时使用精确的主要参考尺寸。
• 确保截图对应正确的路由／状态和可比的滚动位置。
• 不要依据不同宽度下的效果判断保真度，然后声称结果一致。
• 如实进行视口校准：不要使用 CSS zoom、包装元素缩放或仅对截图应用变换来强行调整构图。
• 优先使用在明确 CSS 视口尺寸下捕获的自动化截图，而不是凭视觉判断有头浏览器窗口。
• 如为方便而使用有头模式，仅将其用于交互／调试；如果可以直接获取 Playwright 截图，就不要把实时窗口视为权威保真度检查结果。

阶段 1 - 宏观构图

检查：

• 整体页面宽度和边距
• 主内容区与侧边栏的宽度比例
• 首屏区域的分栏比例
• 卡片的宽度和高度
• 卡片内图表、示意图、地图、媒体和表格区域的宽度比例
• 区块间距
• 顶部导航、首屏区域、筛选区域、表格和侧边栏的对齐情况
• 是否存在水平溢出，或整页出现可疑的缩小／拉伸
• 是否有行看起来比参考内容更密集、更紧凑或压缩得更厉害

第 2 轮——排版与文案

检查：

• 字体系列选择
• 字号
• 字重
• 行高
• 字符间距
• 文本颜色／不透明度
• 文案是否准确
• 换行是否完全一致
• 文本没有被截断、裁切或明显挤压
• 小标签、辅助文本、时间戳、徽章文本、占位符或表格元数据没有文案不一致的情况

第 3 轮——图标与控件完整性

检查：

• 每个图标、徽标、箭头、项目符号、圆点和星号
• 每个导航、侧边栏、工具栏和选项卡图标都与对应的参考项匹配
• 每个重复出现的表格／列表／卡片操作图标，包括每个字形是否与参考项表达相同的语义
• 按钮前置／后置图标
• 搜索图标是否存在且位置是否正确
• 行内辅助图标
• 统计卡片图标
• 缺失的细节

第 4 轮——颜色与表面效果

检查：

• 渐变
• 表面色调
• 边框
• 边框不透明度
• 阴影
• 光晕
• 胶囊形填充
• 徽章颜色
• 表格行分隔线
• 弱化文本的色调

第 5 轮——间距与精细几何

检查：

• 内边距
• 外边距
• 间隙
• 边框圆角
• 标签尺寸
• 输入框高度
• 按钮高度
• 行高
• 图片裁切框
• 图表绘图区边界、坐标轴／网格线位置、系列形状、标记位置、图例间距和图表页脚几何结构
• 比例图的边界、分段尺寸、收窄／阶梯几何形状、标签位置和相邻指标间距
• 比例图文本是否位于对应分段内：标签不得溢出其所属分段，除非参考图也是如此
• 控件内的图标尺寸
• 卡片和面板高度，尤其是同一行中相邻卡片高度有意设计成不同时
• 组件内部的垂直平衡：图表、环形图、图例、页脚链接和行动号召按钮应处于与参考图相同的相对高度
• 图层没有重叠，圆角没有被裁切，控件内部没有被压缩
• 字段／按钮／选择框没有比参考图窄，除非截图明确显示如此
• 重复组件的对齐方式一致
• 参考图暗示同级卡片的页脚／按钮基线对齐时，确保它们对齐
• 除非参考图显示同级卡片等高，否则不要强行设为等高；参考图中的高度差属于设计的一部分
• 同级卡片或磁贴中的行动号召按钮、统计行、徽章行或标题块，不得在没有明确设计理由的情况下明显高于或低于其他同级项

第 5a 轮——组件裁剪检查

对于密集、受限、高价值或脆弱的 UI 区域，除整页或分段截图外，还要截取并检查单个组件的特写截图。

以下情况使用组件级截图：

• 图表、环形图、仪表盘、地图、漏斗、表格、数据网格、时间线和分析面板
• 粘性侧边栏、工具栏、检查器、页眉和筛选栏
• 持久导航面板、侧边栏、导航轨道和工具面板，包括展开标签和折叠／仅图标状态
• 带页脚 CTA、分页、行操作、不换行列、头像、标签或徽章的表格／列表面板
• 卡片、表单、模态框、导航栏、侧边栏、标签栏、分段控件、结账区块、定价卡片、设置面板、信息流／列表项、桌面应用窗格、游戏 HUD 面板及其他受限界面
• 包含紧凑排版、徽章、标签、计数器、头像、图标、图例、数值、时间戳、日期或操作行的组件
• 卡片堆叠处的连接点、卡片之间的边界、粘性区域与内容之间的边界，以及组件自然高度可能延伸至相邻组件的任何位置
• 在整页缩放比例下容易忽略文字对齐、裁切、溢出或精确比例几何尺寸的任何区域
• 在整页检查过程中发现任何可疑的组件

使用 Playwright 或同等浏览器自动化工具时：

• 优先使用元素截图／裁剪来检查目标组件。
• 当周围间距很重要时，截取包含上下文的组件截图。
• 在组件级别检查中心标签、图例、标签行、按钮文字、图标对齐、行高、内部边距、边缘留白以及相邻组件之间的间隔。
• 不要仅凭整页截图来判断小字号文字或图表标签。
• 如果组件级裁剪发现问题，应先修复并重新截取该组件，然后再宣布视觉检查完成。
• 如果组件密集或受限，却没有截取裁剪图，则不要在最终报告中声称已完成组件级视觉验证。

第 5b 轮——移动端导航状态检查

对于推断或适配的移动端导航，应截取并检查相关状态，而不只是默认页面：

• 移动端导航关闭／默认状态
• 存在时的打开状态，包括抽屉、底部弹层、菜单、溢出菜单或展开的标签
• 导航包含标签、图标、徽章或多个目的地时，在一个较窄的移动端宽度下进行压力测试

检查所有主要目的地是否仍可访问、活动状态是否清晰、标签是否能完整显示或按预期截断、触控目标是否易于操作、菜单触发器是否明显、覆盖层是否会不协调地遮挡控件，以及抽屉／底部弹层在内容超出视口时是否可滚动。

第 6 轮——响应式行为

参考尺寸版本接近完成后：

• 对于桌面网页，除非用户明确要求其他桌面目标，否则应在约 1900px 视口宽度下进行首选宽屏桌面验证
• 不要假定参考截图的较窄宽度就是生产环境中正确的桌面宽度；如果截图是 POC，应在保持其构图和设计语言的同时，将其转化为适用于首选宽屏桌面视口的稳定真实页面布局
• 测试平板电脑和移动端宽度
• 如果可行，还应在一种备用桌面条件下进行合理性检查，例如稍窄的桌面宽度或浏览器缩小显示，以发现脆弱的布局假设
• 如果已知用户环境采用非默认缩放比例或 DPI 缩放设置，则在实际可行时加入一项近似该条件的合理性检查
• 保持层级关系和平衡
• 避免溢出、控件裁切、尴尬换行和媒体变形
• 不要让响应式版本偏离过多，以致不再呈现相同的设计语言
• 汇报结果时，应区分环境导致的渲染差异与真正的布局缺陷；不要把 DPI 缩放或浏览器缩放当作可见几何错误的万能借口

Pass 6a - 浏览器与缩放适应性

对于任何内容密集或空间受限的 UI，在最终定稿前执行一次缩放适应性检查：

• 除参考尺寸和常规响应式断点外，再测试一种受限的有效桌面宽度。优先选择比参考宽度窄 5-15% 的宽度，或最接近且高于平板断点的宽度。
• 条件允许时，测试一种较大文本或可用宽度缩小的情况，以模拟浏览器缩放、最小字号调整、Windows/macOS 显示缩放、侧边栏或浏览器特有的字体度量。
• 在此压力条件下，检查空间最受限组件的局部截图，尤其是图例、表格、卡片、导航栏、工具栏、表单、徽章、日期/数值列和堆叠卡片的衔接处。
• 将文本换行、裁切、贴边、重叠、数值截断、徽章拥挤以及组件高度意外增加视为布局问题。
• 对于文本较多的组件，除非已在压力条件下验证溢出处理及其与相邻组件的间距，否则避免使用固定高度、固定网格行或绝对定位。
• 当组件在桌面视口中可能变窄时，优先采用自然文档流、min-height、独立堆叠、容器查询、固有尺寸、换行规则和更早的断点。
• 如果压力条件表明忠实还原参考布局会导致布局过于脆弱，请保留设计风格，同时采用更稳健的布局；并将此说明为有意进行的适应性调整。

Pass 7 - 最终完整性检查

完成前，请确认：

• 所有可见区块均已实现
• 所有可见图标均已实现
• 所有可见文本标签均已实现
• 所有重要的可见控件都具备适当的基本交互状态，或明确设计为不可交互状态
• 所有提供的资源均已正确使用
• 所有生成的资源图集均已拆分为独立文件，或有意作为图集/精灵图集成
• 所有提取的透明资源在需要透明效果时均已验证 Alpha 元数据/像素
• 所有仍缺失的资源均有占位内容，并在需要时列入唯一的资源提示词代码块
• 表格/列表面板没有意外的内部滚动条、被裁切的行操作按钮，或位于容器外的页脚 CTA
• 在已验证的视图中，不存在明显的拥挤、裁切、重叠或布局脆弱问题

如有需要，请在通过这些检查后继续迭代。不要停留在第一个可用的初稿。

可选辅助脚本

如果此技能包含 scripts/compare_screenshots.py 且 Python 可用，请在以参考尺寸截取实现截图后使用该脚本。

推荐用法： python <path-to-codex-home>/skills/ui-from-image/scripts/compare_screenshots.py path/to/reference.png path/to/implementation.png --out-dir .codex-artifacts/ui-diff

说明：

• 辅助脚本位于已安装的技能目录中，而非目标仓库中，除非你已将其复制到仓库。
• 最佳做法是在不调整尺寸的情况下，对相同尺寸的截图进行比较。
• 仅当候选截图尺寸略有偏差且你需要快速诊断时，才将 --fit 作为备选方案。
• 使用生成的差异图像和指标定位差异显著区域，但不要只以数值为优化目标；仍需进行视觉判断。

响应式要求

• 页面必须在桌面、平板和移动设备上均能正常显示。
• 避免溢出、换行异常、内容裁切、媒体变形和间距突变。
• 尽可能保留桌面布局，并在较小屏幕上整齐地重排/堆叠。
• 确保交互元素适合触控操作。
• 除非参考设计明确表明应隐藏，否则不要隐藏重要内容。

推断的移动端适配

未提供移动端参考时，不要机械地将桌面布局纵向堆叠。应设计移动端适配方案，在保留产品层级和视觉语言的同时，让每个组件都能在窄屏触控视口中使用。

对于推断的移动端布局：

• 编写代码前，先确定移动端的信息呈现顺序。
• 将密集的表格／数据网格转换为行卡片、精简摘要或横向滚动视图，但仅限于此类转换不影响任务完成的情况。
• 根据应用类型，为常驻侧边栏设计恰当的移动端导航模式。不要只是隐藏侧边栏，也不要把冗长的桌面导航改成过长的横向导航条。
• 确保图表和示意图清晰易读；必要时简化坐标轴、图例和标签，或采用摘要优先的卡片。
• 如果不违背参考设计，可将内容分为选项卡、折叠面板、摘要或深入查看视图，避免页面过长。
• 检查触控目标、标签换行、卡片间距、粘性页眉／导航栏以及所有主要操作。
• 捕获移动端视口截图，并为内容密集的移动端组件截取重点区域。
• 在最终报告中说明移动端布局是推断得出的，并列出相较桌面版有意进行的结构调整。

移动端导航替换方案

当桌面侧边栏、导航栏、顶部导航、检查器导航或命令菜单无法适配移动端时：

• 保留对所有重要桌面端目标页面的访问。移动端适配可以优先展示几个常用目标页面，但其余目标页面仍须通过完整菜单、抽屉、底部弹层、溢出菜单或同等方式让用户能够找到。
• 有意选择导航模式：3–5 个主要应用区域适用底部导航，同级视图适用顶部选项卡／分段导航，多个目标页面适用抽屉或底部弹层；仅当所有项目都能被找到且易于使用时，才使用紧凑型横向导航。
• 如果同时提供快捷入口和完整菜单，应限制快捷入口数量，并让菜单触发器在视觉上足够醒目。
• 如果使用抽屉／底部弹层，应包含清晰的标题或上下文、关闭控件，并在适当情况下支持遮罩层或点击外部关闭、在实际可行时支持键盘关闭，以及支持长列表滚动。
• 在菜单关闭和打开两种状态下，检查激活状态、图标／文本对齐、标签是否适配、触控目标尺寸以及菜单触发器的位置。
• 将隐藏的目标页面、被截断的标签、无法访问的抽屉项目、关闭时仍可聚焦的画布外链接，以及含义不明确的菜单触发器视为移动端导航缺陷。

行为

• 仅为参考设计中体现的可见行为添加 JS。
• 如果不需要 JS，仍须创建 script.js 并添加简短注释。
• 不要添加无关功能、动画或库。

隐含交互与操作反馈的还原

当参考内容或产品情境表明可见控件具有交互性时，请实现基本的交互状态。保持行为局部且可信；不要凭空添加缺乏依据的工作流、后端逻辑或产品功能。

对于 Web 和应用 UI：

• 如果相关界面需要，链接应有恰当的悬停、焦点、已访问或激活样式。
• 如果参考内容或控件角色表明需要，按钮应有悬停、按下、焦点可见、选中、加载和禁用状态。
• 对于可见或明显暗示存在的下拉菜单、选择框、分段控件、标签页、切换开关、复选框、单选按钮、图标按钮、行菜单、命令栏、表格行和列表项，应实现基本的局部交互行为。
• 存在可见的本地数据时，搜索和筛选控件可以执行轻量级的客户端筛选。
• 如果参考内容暗示存在多种模式，且无需虚构产品数据即可呈现内容，则标签页或分段控件可以切换本地可见状态。
• 如果存在相应触发器，菜单、弹出层、抽屉、折叠面板和工具提示可以打开或关闭；仅在截图或周边产品情境有依据时，才显示合理的选项。
• 除非明确要求，否则不要伪造破坏性操作、付款流程、身份验证、持久化、网络请求、通知、文件系统访问或复杂的产品工作流。

对于桌面风格的 UI：

• 为工具栏按钮、树形行、菜单项、标签页、网格行、分隔条、窗格、滚动区域和表单控件提供符合原生体验的悬停、焦点、按下、选中、禁用和调整大小反馈。
• 遵循平台在键盘焦点、上下文菜单、密集数据网格、禁用控件、窗口装饰和状态栏方面的惯例。
• 除非参考内容本身是营销风格界面，否则不要让桌面工具看起来像营销网页。

对于游戏 UI 和交互式 3D 界面：

• 当界面有所暗示时，实现菜单选择、悬停／焦点／按下状态、适配手柄／键盘的导航提示、基本面板切换、HUD 反馈，以及暂停／设置导航。
• 除非有明确要求，否则不要虚构玩法系统、物品栏效果、战斗规则、物理效果、成长进度、存档／读档行为或在线功能。
• 优先保证可读性、选中状态、输入反馈、稳定的 HUD 布局，以及叠加层之间不互相遮挡。

对于任何 UI 界面：

• 每个可见的可点击元素都应具有真实的本地行为，或处于明确且恰当的不可交互状态。
• 光标、悬停、按下、选中、禁用、焦点可见、拖动、调整大小和触摸状态应符合平台与视觉风格。
• 仅图标按钮需要在代码中提供无障碍标签或等效语义。
• 本地状态变化不得损害视觉还原度、导致布局跳动、隐藏必要内容或产生与参考内容矛盾的状态。
• 如果自动化或 UI 工具条件允许，请至少验证重要控件的一种悬停、焦点、选中或打开状态。

最终报告

最后简要报告：

1. 实现了哪些内容
2. 复用／调整了哪些内容，以及新创建了哪些内容
3. 使用了哪些提供的素材
4. 生成并集成了哪些素材，包括素材来自单独生成还是从素材表中提取
5. 还剩下哪些占位内容
6. 如果仍缺少素材，请使用且仅使用一个带围栏的 text 代码块，列出所有剩余的素材生成提示词
7. 完成了哪些视觉对比检查
8. 仍存在哪些不确定之处或细微差异
9. 如果针对缺失素材使用了任何临时替代品或合成替代品，请明确说明，并在缺失素材报告中一并列出
10. 对于提取出的透明素材，是否已完成 Alpha 验证
11. 如果推断了移动端导航，请说明选择了哪种移动端导航模式，以及检查了哪些打开／关闭／窄屏状态的截图

单个素材提示词代码块规则

• 对于所有仍缺失的素材提示词，只使用一个带 text 标记的围栏代码块。
• 如果不需要生成素材提示词，则完全省略代码块。
• 不要将素材提示词分散在多个代码块或普通文本中。
• 需要此代码块时，不要用自由形式的文本提示词、项目符号列表或改写后的提示词建议代替。
• 仍有缺失素材时，请原样复制以下结构，不要自行改用其他格式。
• 在代码块内，每条素材提示词都应独立成项，并用 --- 清晰分隔。
• 代码块以以下内容开头：

Generate each asset below as a separate image file. Do not combine multiple assets into one image.

• 然后为每项素材使用以下结构：

---

asset_name: ... suggested_filename: ... purpose_in_ui: ... target_dimensions_or_aspect_ratio: ... background_requirements: ... prompt: ... avoid: ...

发送最终答案前，请快速自查：

• 是否仍有缺失素材；如果有，是否恰好使用了一个带 text 标记的围栏代码块
• 每项缺失素材是否都包含自己的 asset_name、suggested_filename、purpose_in_ui、target_dimensions_or_aspect_ratio、background_requirements、prompt 和 avoid
• 是否避免在该单个代码块之外添加任何额外的素材提示词

完成定义

仅当以下条件全部满足时，任务才算完成：

• 渲染后的页面与参考图在视觉上高度一致。
• 先匹配主要参考尺寸的截图，再进行响应式适配。
• 桌面端、平板端和移动端布局连贯且稳定。
• 在工具条件允许时，至少检查一个主要桌面截图之外的其他视图，以进行合理性验证。
• 已截取并检查密集或受限组件的局部截图，包括内容增长可能导致重叠的相邻组件交界处。
• 在工具条件允许时，已针对密集或受限 UI 完成缩放和浏览器适配检查，可采用更窄的有效宽度、更大字号的近似设置或已知用户环境条件。
• 对于常驻导航、侧边栏、轨道、检查器和工具面板（如有），已检查其内部水平溢出、标签适配、独立滚动及正确的展开／折叠行为。
• 当桌面导航改变形式时，移动端导航替代方案仍可访问所有重要目的地，并已验证关闭、打开和窄屏状态。
• 已检查数据表格、网格和列表面板是否存在意外的内部滚动条、被裁切的行操作，以及溢出卡片边界的页脚链接／CTA。
• 在适用情况下，已沿用现有项目模式。
• 已明确检查字体的字族、渲染回退、字号、字重、行高、字间距和字形视觉宽度；并非仅依赖框架默认设置。
• 经验证的视图中文字正确，且未出现裁切、截断、挤压、贴边、重叠或换行错误。
• 已参照参考图检查卡片和面板高度，包括有意设置为不同高度的同级卡片，而非自动统一高度。
• 已明确检查图标和细节，没有明显遗漏的小型 UI 元素。
• 已明确检查数据可视化和比例示意图的卡片边界、内部几何结构、标签、控件和周边留白。
• 在工具条件允许时，已截取并检查密集、高价值或易出问题区域的组件局部截图。
• 可见交互控件具备适当的平台专属交互状态，并在参考或产品上下文有所暗示时具备基本的本地行为，且未臆造不受支持的工作流。
• 已恰当使用提供的资源。
• 在可能的情况下，已生成应补充的缺失栅格资源，优先为兼容的资源组生成资源图集，再提取为单独文件并集成。
• 需要透明度时，已确认生成／提取的透明资源确实具有 Alpha 通道。
• 剩余缺失资源均以准确的占位图表示，并附有独立的生成提示词，统一放入一个 text 代码块中。
• 经验证的视图中，不存在明显的水平溢出、元素重叠或拥挤导致的回归问题。
• 独立项目使用独立的 HTML／CSS／JS 文件；基于框架的项目则已整洁地集成到仓库现有结构中。
• 如果具备浏览器工具，最终回复会准确说明截取并检查了哪些截图；不得省略此检查，也不得将非视觉检查描述为等同检查。
• 如果需要组件局部截图或缩放检查，最终回复会准确说明截取并检查了哪些内容；不得暗示仅凭整页截图就完成了这些检查。
• 如果仍有缺失资源，最终回复会采用此技能要求的准确单块资源提示词格式，而非自行变通。