我的游戏在一个Phaser场景的周围有一个Vue界面。我与编码助手合作的大部分工作，是让屏幕在移动端和桌面端保持一致的行为，而不仅仅是获得一张好看的截图。

我搭建这套系统中最有用的部分是一个仅用于开发的展示模式。它运行真实的路由和组件，API响应由固定数据提供。我可以在同一屏幕的有数据、空数据、加载中和错误状态之间切换，而不必等待这些情况在实际游戏中出现。

我把组件示例单独存放。它们回答的是“这个按钮或卡片本身是否能正常工作？”而展示模式回答的是“当我通过应用到达这个实际屏幕时，它是否正常工作？”一个整洁的组件库并不能证明导航、滚动或提交行为。

这里有几点刻意设定的约束：

  • 共享的标记和组件定义了字体、间距、颜色和通用控件。自动化检查能捕捉部分偏差，包括未定义的标记。
  • 屏幕声明了它们的导航和主要的滚动容器。这让审查有了比“让布局更干净”更具体的方向。
  • 固定数据使用生成的协议类型。后端契约的变更可以在类型检查时暴露过时的固定数据。
  • 缺失固定数据路由会被报告，而不是像成功的API请求一样悄无声息地运行。
  • 页面变更会在移动端和桌面端布局中同时检查。截图是检查的一部分，而非证明整个应用正常工作的依据。

这些限制和它的能力同样有用。这个模式不会验证管理区域、真实的增量SSE推送或Phaser动画。这些需要各自的检查。它也不会证明后端会接受提交。

对于一个小项目，我会从一张麻烦的真实屏幕和两个固定数据开始：一个正常响应和一个失败响应。不需要先构建一个巨大的预览框架再去验证它是否有帮助。维护成本在于让固定数据契约与真实API行为保持一致。

在您的AI编码工作流中，哪种方法能捕捉更多UI回归：是独立的组件预览，还是使用受控数据测试真实屏幕？

声明：基于本人项目中的惯例和实现，借助AI辅助写作。