视觉 Coding
截图生成代码应该如何验收
截图生成代码可能产出外观相近的页面 却没有完成底层工作流 设计验收方案前应先明确目标是静态界面 交互原型还是可运行应用 不同目标需要不同证据
补足截图无法表达的任务约定
截图只能呈现某个时刻的布局与内容 通常无法完整说明导航规则 校验逻辑 加载状态或数据持久化 应另行提供这些要求 或明确将其排除在任务之外 不能把未说明的产品规则当成截图已经提供的信息
开源 screenshot-to-code 项目提供输入截图与生成结果的评估流程 可作为视觉审核参考 下方应用层检查则关注静态图片无法证明的行为
按三个层次分别验收
| 验收层次 | 检查内容 | 对应证据 |
|---|---|---|
| 视觉 | 布局 字体 间距与响应式状态 | 相同尺寸下的参考图与渲染结果 |
| 交互 | 导航 输入校验与有效控件 | 操作序列与后续界面状态 |
| 持久化 | 预期写入能否在刷新及导航后保留 | 应用或数据库状态检查 |
追踪一次完整写入
以自拟收藏流程为例 点击后按钮应变化 但还应检查保存记录 重新访问内容及取消收藏 如果只是前端变量变化且刷新后丢失 就只满足了即时视觉反馈
检查时使用受控初始数据 明确首次操作前是否已有收藏 否则一次切换可能删除原有记录而不是创建新记录 应同时保存起始条件与最终结论
让视觉判断可以解释
在相同视口与加载状态下比较界面 指明差异所在区域 而不是只给总分 动态内容 字体加载和动画都可能改变截图 但并不一定代表实现缺陷
将视觉问题与功能问题分别记录 外观准确的页面可能无法写入 可运行应用也可能存在间距问题 两类发现对应不同修复动作 应在报告中分别保留
同时索取输入与可执行证据
咨询 Demo 时可索取允许使用的视觉输入 交互说明 应用产物与验收报告 并确认是否包含运行环境 公开视觉 Coding 案例只能说明特定实验 不能推导所有后续任务的表现