visual-verification 是一个针对 AI 编码代理的视觉验证技能，核心规则一句话：如果外观是需求的一部分，那么渲染出来的结果才是证据。源码、DOM 结构、CSS、场景树、测试套件通过和构建成功只能证明“描述得对”，不能证明“看起来对”，而“描述得对”与“看起来对”之间的差距，正是大量被用户立刻指出“坏了”的“完成”界面的来源。
用途与工作循环。技能要求代理按以下循环工作：实现 → 启动/渲染 → 捕获实际输出 → 查看它 → 发现缺陷 → 修复 → 重新渲染 → 再看 → 才算完成。第二次查看不是可选项：证据必须来自最终状态，最后一次编辑之前截的图不能证明最终交付物是什么样。
能否真正看到像素。技能指出“看截图”是最容易造假的指令，因为诚实汇报和编造汇报是同一句话。它区分两个断言：“截了一张图”（文件存在）和“代理检查了像素”（模型确实读取了图像），只有后者支持完成声明。为此提供一次性会话检查：运行 TOOLS\Test-VisionCanary.ps1 -Word <word> -Shape <shape> -Color <colour>，先打开 TOOLS\vision-canary\vision-canary.png 并报告其中内容；期望答案只以哈希存储，因此读仓库不能替代真正查看。若检查通过，则在每次视觉完成声明前检查渲染输出；若失败，这不是错误而是答案：保留截图作为工件供用户或具备能力的代理使用；回退到 DOM、可访问性树、计算样式、控制台、网络和元素几何等结构性检查，这些能捕获许多缺陷；并明确说明“本提供方/会话中视觉验证不可用”以及哪些内容尚未检查，绝不能对没看到的像素写“看起来不错”。
各客户端对图像的支持随版本变化，技能建议实测而非假设。按其资料记录：Claude Code 可直接读取图像文件；codex 和 codex exec 接受 -i/--image；grok、kimi 和 hermes 的 --help 中未显示图像附加标志。返回图像的 MCP 服务器只有在客户端把图像转发给模型时才有用，金丝雀检查正是用来确认这一点。
获取像素的最省事充分路线。技能强调按需选择：检查 README 不必启用浏览器栈，能渲染成文件解决就不要开完整浏览器。网页/应用优先使用提供方自己的浏览器能力，否则用 Playwright（CLI 或 MCP）截图到文件；需要控制台错误、失败请求、计算布局时使用 Chrome DevTools MCP 网页配置；桌面应用或 EXE 则启动、截取窗口、关闭并确认进程确实退出；Blender、Godot、Unity 通过引擎自身能力渲染或捕获；生成的图像或素材直接打开文件。能力配置按项目启用且默认关闭，只开启本任务所需的一项。
检查清单。技能列出 AI 编写界面的常见可识别失败模式，建议先扫这些再看主观问题：元素重叠或裁切、文本溢出容器；内容被页头页脚或固定栏遮挡、控件跑到屏幕外；图片损坏、缺失、错误、拉伸或低分辨率；空白或灰色预览框、残留加载占位符；对比度不可读、文字过小；模态框、下拉或提示框定位错误、层级错误；页面主体出现横向滚动条、移动宽度下布局坍塌；本应自定义界面处露出浏览器或操作系统默认外观；点击控件无响应；从未设计过的空状态；间距或视觉层级不一致；与参考设计或用户要求明显不符。扫完即止：这是收尾技能而非设计系统，只修复正确性、可用性和明显缺陷，不陷入无边界像素完美。
交互而非仅外观。截图只证明第一帧。若需求包含行为，就要实际点击控件、提交表单、打开菜单、调整到关键断点，然后再看。内容缺失而非难看时，检查控制台错误和网络面板失败请求——灰色框通常是请求失败而非 CSS 缺陷，靠猜 CSS 会反复修而不中。
失败的验证是工作流正常运转。发现缺陷正是目的，不应压制它、不应削弱检查使其通过、也不应把未修复的缺陷描述成小事。观察、修复、渲染、再看。汇报时须说明属于哪种情况：渲染并检查了实际输出（注明尺寸/状态）；捕获了输出但无法检查（说明原因并保留工件）；仅做结构性验证（说明哪些尚未验证）。“我检查了代码，应该能正确渲染”不属于以上任何一种。