界面由模型逐帧生成之后，测试用例要先重写｜洹拓科技

一、被换掉的是可复现与可寻址

据公开报道，一类被称作“界面世界模型”的做法宣称不写代码、实时逐帧生成交互式界面，用户的点击和拖动连同当前画面一起作为输入，决定下一帧长什么样；报道称其在盲测中的界面效果优于若干由代码生成的对照方案。盲测的设置、参与者与判定口径都没有公开细节，我们不拿它当可用性判据。值得认真对待的是机制本身：它没有替换某个组件库，它动的是前端工程赖以成立的两条隐含约定。

第一条是可复现。同一份代码加同一组输入得到同一块界面，所以回归用例敢写死断言，失败时的第一次截图就是证据。第二条是可寻址。界面上每个元素都有一个在版本演进中尽量稳定的标识，自动化脚本靠它定位，埋点靠它归类，读屏软件靠它播报，客服工单靠它描述故障位置。逐帧生成把“变更”换成了“生成”：结果带采样随机性，标识每帧都可能是新的。测试对象的定义变了，这不是升级测试框架能解决的。

二、代码生成与模型生成的四项根本差异

对照项	代码生成	模型逐帧生成	对测试的直接后果
同一输入是否同一输出	是，异常算缺陷	不保证，结果带采样性	断言只能写约束不能写等值
元素有无稳定标识	有，来自源码与属性	每帧可能重排	依赖选择器的用例成批失效
状态存在哪里	应用状态层，可快照	部分画在帧里，去向不明	跨帧一致性无从核对
变更如何发生	提交、评审、发布	生成、覆盖、再采样	回归范围无法按版本圈定

四条里最麻烦的是第三条。代码路线上状态有明确归属，界面只是状态的投影；生成路线上，上一帧画面本身参与了下一帧的决定，画面变成了状态的一部分。于是“刷新一下还在不在”“退回去对不对”这类基本问题都要重新设计用例，而不是重新执行用例。

对有自研组件库的团队，影响还有另一半在契约上。组件契约里承诺的东西——受控状态、事件回调、无障碍属性、测试标识——在逐帧生成里全部悬空，因为界面不再由这些组件装配而成。契约测试要跟着改写成约束满足检查：不再断言“按钮上有某个标识”，改为断言“页面里存在一个能完成提交动作的控件，键盘可达，提交后状态在下一帧仍然保持”。前一种断言查代码，后一种断言只能查行为，测试的成本结构从维护选择器变成了维护判定器。

三、要把这套系统测起来，先定六项

洹拓接手界面自动化类项目时，我们要求先把下面六项地基约定写进合同附件，缺一项都不启动用例改造。

1. 稳定标识的生成与保留规则：模型必须为跨帧存续的元素沿用同一标识，标识变更要能查询到原因。
2. 输入事件与生成结果的映射记录：每次点击、拖动、滚轮，连同产生的帧结果落一条记录，出争议时对得上账。
3. 可复现所需的随机种子与版本快照：每个页面对应随机种子、模型版本、提示模板三元组，测试环境要支持按三元组重放。
4. 幂等判定：同一操作重复执行多少次算“等价界面”，先定义再谈测试，位置容差、控件集合容差、文案容差三项分开给。
5. 跨帧状态一致性检查项：表单已填内容、选中态、滚动位置在帧切换后必须保持，逐条写成断言。
6. 失败时的最小可重放单元：一次失败至少能重放“上一帧画面加本次操作”，否则缺陷没法交给别人复现。

四、无障碍与合规的问题等不起

代码路线上无障碍可以逐步还债，因为结构还在，改标签、补属性就能推进。生成路线上的第一批问题恰恰是结构性的：焦点顺序由模型当帧决定，键盘用户的路径每次都可能不同；语义标签可能整个缺失，读屏软件拿不到控件角色；对比度随配色生成波动，同一组件在不同帧勉强达标或明显不达标；读屏依赖的稳定标识拿不到，播报只能退化成一句“按钮”。合规侧这些属于验收门槛而不是体验加分项，一旦上线后被投诉或被检查，整改要退回测试对象的定义重来。所以我们的做法是把无障碍要求并进第三节那六项地基里，作为上线条件，不作为上线后的优化项。对应判法也是现成的：同一操作连续采样三次，核对焦点顺序是否稳定；抽取每帧控件的角色枚举是否齐全；同一配色方案在连续帧里抽检对比度差值；读屏播报里是否出现无名称控件。四条用例不复杂，难的是它们必须在“标识不稳定”这个前提下还能给出结论，这又回到了六项地基。

五、性能与埋点的口径都要重算

性能方面，逐帧生成把“渲染耗时”换成了“推理延迟”，至少重算三处。交互手感按动作发出到下一帧可见的延迟分布来验收，不能只看平均值，拖动这类连续输入对帧间隔极敏感，平均达标而尾部超标一样不可用。首帧与后续帧分开给指标：首帧决定进入体验，后续帧决定操作体验，两者的瓶颈常常不在同一层。再有一条必须提前设计——断网或推理服务不可用时的退化界面策略，回落到已固化的静态版本、切只读模式还是明确报错，不允许出现停在上一帧假装可用的状态。

埋点方面，旧体系的事件名挂在组件名和层级路径上，标识每帧可能重排，报表会悄悄失真而不报错。改造方向是按语义事件建模：不记“第三层容器下的按钮”，记“提交了订单”“打开了筛选”这类与位置无关的事件，并配一份语义事件字典作为交付物。同时把“同一功能位在连续帧里的位置漂移”做成独立监控项，设阈值告警，作为数据质量指标单列。

六、三条折中路线与适配判据

完全生成与完全代码之间存在三条可落地的中间路线。

路线	做法	保住了什么	付出了什么
只生成布局	模型决定组件摆放，组件本体仍出自代码库	标识、无障碍、行为逻辑全部保留	样式自由度受组件库约束
生成后编译	生成一次，产出静态代码，评审后按常规发布	上线后仍是可复现的传统前端	失去实时性，迭代回到发布节奏
固化为已验证快照	完全生成，但每个页面锁定一个通过测试与无障碍检查的版本对外服务	保留生成能力，线上行为确定	快照过期与再生成的回归管理

第三条路线要额外回答三个问题才能落地：一个快照的可用期怎么定，由业务变更触发还是由模型版本触发；再生成之后走不走第三节六项的完整检查，不查等于没固化；检查通过前新旧快照怎么并行放量。这三问没有答案时，“已验证快照”只是一句安慰话。

适配与否给一条判据：变更频率高、出错代价低、用户对偶发不一致有容忍度的场景适合往前走，例如原型验证、营销落地页、内部工具、一次性配置向导；反过来，交易与支付、长表单填写、政务与医疗流程这三类，一次错误界面就构成资损或合规事故，而它们的测试要求恰好是可复现与可寻址，与这套机制正面相撞。演示解决的是“能不能生成”，客户问的永远是“错了怎么办”。在测试对象定义被重写之前，生成式界面进不了后面那三类业务，这是我们对客户的直话。

#回归测试 #无障碍 #生成式界面 #可控性 #组件契约