AI 生成的网页，经得起重复提交吗？用 PPIO 沙箱验收

一个报名页面已经生成，输入资料、点击提交，屏幕显示成功。产品准备通过评审，研发却发现连续点击两次会新增两条记录。界面完成了演示，重复提交的处理还没有落地。如果评审时没有约定后台应留下什么，问题就会延后到集成阶段。生成式原型开始具备真实行为，评审也需要覆盖行为的结果。11 月 4 日，Figma 发布工作流示例，展示团队如何在画布中并排尝试代码原型。这种协作方式让反馈更直接，技术团队还需要把反馈变成可复查的测试条件。

先定义“一次操作”，再处理重复请求

按钮置灰能减少误点，但连接中断、页面刷新和多端操作仍可能产生重复请求。更稳妥的设计，是为一次业务操作分配请求标识，让后续重试继续对应同一次报名。例如，用户提交后没有收到结果，再次点击时沿用原标识。服务若已完成报名，就返回已有结果；若尚未完成，再按约定继续处理。只有用户明确发起另一项报名，才建立新的操作。使用关系型数据库时，可以对操作标识设置唯一约束，并将标识与报名写入放在同一事务中，避免两个并发请求同时通过检查、各自新增一条。这里需要一个业务决定：相同资料是否允许再次提交？活动报名可能限制每人一次，资料收集表却可能允许同一人分批补充。直接按内容去重，可能把合法的新提交也挡住。先写清规则，测试才有正确答案。

用三种情形检查同一个功能

可以为报名服务准备一组独立测试数据，分别执行以下操作。

第二项尤其重要。页面显示失败时，服务端可能已经成功。若只测试“请求报错后再提交”，很容易漏掉这种结果暂时未知的情况。可以在测试服务写入之后中断响应，再查询记录，观察页面怎样带用户继续。同时检查失败后的体验：已填资料是否仍在，提示是否给出下一步，用户能否知道报名已经完成。技术上的重复控制，最终要让用户少填一次表、少担心一次结果。还应加一个反例：同一操作标识携带了不同资料。服务应识别这种冲突，让用户确认是否发起新操作，而不是悄悄返回旧报名。测试由此同时覆盖“重复的请求”和“改变了的意图”，避免把所有相似输入都当成重试。

在 PPIO 沙箱里保留可重现的起点

PPIO 沙箱提供独立文件系统、命令执行和依赖安装环境。将原型代码、测试服务与固定数据放入同一个测试环境，可以让设计、产品和研发访问相同版本，重现同一种行为。先固定代码提交和启动命令，再启动 Web 服务获取预览地址。Web 服务示例展示了这种访问方式。每轮测试重新建立相同的数据起点，修改前后分别执行三种情形，变化就能对应到具体代码。测试服务宜与生产数据分开。演示记录可以重复创建和清理，网络异常也能主动制造，不必等待真实用户遇到问题。若页面还使用模拟响应，就先验证交互与提示，接入测试服务后再验证报名结果。

把测试结果带进开发交接

交接材料可以很精炼：通过的是哪个版本，怎样启动，三种情形各得到什么结果，还有哪一种尚未满足预期。附上复现输入和相关命令输出，接手者就能直接从问题继续工作。截图适合说明用户看到了什么，服务记录适合说明报名发生了什么。两种材料围绕同一操作标识组织，能减少“我这里正常”的往返解释。原型验收的价值也由此变得具体：团队在接入生产之前，就发现了会让用户重复操作的问题，并留下可持续复用的测试。下一次调整表单或更换接口，仍能用这三种情形检查原有体验是否保住了。