AI构建的UI需要证据关卡：设计Token、截图、视觉质量检查

我认为前端工作暴露了AI编码代理的一个奇怪弱点。对于后端任务，失败通常很明显：测试失败、类型失败、API返回错误结果。对于UI工作，代理可以让应用编译通过，但结果仍然让人觉得是生成的： - 间距和阴影不一致 - 默认排版 - 随机渐变 - 组件没有共同的设计语言 - 没有浏览器截图证明结果看起来正确 有用的标准（至少对我来说）不是“代理编辑了React文件”。它更接近一个证据关卡：在编码之前定义视觉契约。一个 `DESIGN.md` 或 token 文件应该说明允许哪些颜色、字号、间距、圆角、阴影和动效。在实现之前阻止通用AI默认值。如果结果变成同样的紫色渐变/三卡片/随机阴影SaaS模式，那么应该在“完成”之前就失败。在真实的浏览器中验证，而不仅仅是构建。在移动/平板/桌面宽度下截图，检查空白/加载/错误状态，验证交互，而不是相信静态代码差异。如果有参考目标，将视觉差异用作地图，而不是判决。热点区域应指示审查者检查哪里；高相似度分数不应覆盖截断文本、布局损坏或虚假一致。让最终答案引用证据。“完成”应该指向截图、日志、测试输出或视觉质量检查工件，并且应该说明哪些仍然不确定。 我正在将它构建成一个名为Superloopy的小型MIT Codex插件/CLI。我是开发者，所以这有一部分是项目介绍，但我希望得到反馈的是其核心思想。最近的工作添加了一个 `superloopy-frontend` 技能，通过要求设计Token契约、防混乱检查、92项品牌/样式参考库、设计系统合规性检查、截图证据和视觉质量检查，在代理声称UI完成之前确保前端工作更好。同样的模式也出现在研究和克隆技能中： - 研究：引用合成、扩展波、声明账本、验证工件 - 授权网站重建：截图、DOM/拓扑、计算样式、资源、组件规范、构建输出、视觉质量检查 相关仓库：https://github.com/beefiker/superloopy 问题：如果你使用AI代理进行产品/前端工作，哪些证据能让你真正信任最终答案？截图？设计Token合规性？视觉差异？Lighthouse？人工检查清单？还是其他什么？