火小懂编辑部
现在让AI生成一个报名表或客户留资表，几十秒就能得到HTML代码。但表单能显示、按钮能点击，不代表它可上线。空手机号被误收、错误提示只靠红色文字、重复提交产生两条记录，或者用户用键盘根本找不到表单字段，都会直接影响业务。MDN的HTML约束验证指南解释了浏览器原生校验机制，W3C WCAG 2.2提供了可访问性相关标准。本文从业务字段、错误反馈、后端校验和设备测试六个环节说明怎样验收AI生成的表单。
为每个字段写明业务规则
表单设计不能从HTML标签开始，而要从用户要完成的任务开始。比如收集合作申请，可能只需姓名、联系方式、合作方向，不能因为AI默认模板包含生日、地址和身份证号就全部采集。把每个字段的用途、是否必填、允许长度、格式和保存期限写入字段说明。对于电话号码，要考虑国际区号和用户输入空格等情况，不能只用固定十一位数字判断全世界的手机号。联系人姓名也不应限制只能使用英文字母。字段越多，出错和隐私风险越高。先简化需求，再让AI根据明确规则生成界面，能减少后来反复添加补丁的成本。
使用浏览器验证但不依赖浏览器
MDN的Constraint Validation API文档说明，HTML可以通过required、minlength、pattern、类型等约束向用户提示无效输入。这对即时反馈有价值，但客户端代码可能被绕过，因此服务端仍需独立验证全部输入。不要把浏览器的绿色通过标记当成数据库可以直接信任的证明。应当测试空值、超长文本、异常字符、重复提交和不合规字段组合。涉及金额、数量和日期的表单还要核对业务上下限与时区。若AI生成的正则表达式过于复杂或无法解释，应先用正常和恶意样例做测试。验证规则应可维护，避免一个冷门输入让所有合法用户无法完成提交。
让错误提示明确指出如何修改
不少AI生成的表单只在页面顶部显示“提交失败”，用户不知道哪个字段错了。应当在相关字段附近提供可理解的错误说明，并在提交失败后让键盘焦点或辅助技术能够定位错误。不能只靠红色边框区分成功与失败，因为颜色感知能力和屏幕环境会影响判断。对于多字段错误，提供简短的错误摘要，同时保留用户已填写的有效内容，避免重复输入。错误提示可以写“请输入包含区号的联系电话”，而不是只显示技术性的“Invalid format”。对于网络请求超时，明确说明是否已经收到提交，防止用户重复点击造成两个申请。
检查键盘、屏幕阅读器与文字缩放
W3C WCAG 2.2是帮助不同能力用户访问网页内容的重要标准。AI生成界面常出现没有关联label的输入框、只用占位符替代字段名称、无法看见焦点的位置或自定义下拉框不能用键盘展开。应当让所有控件有可识别名称，使用Tab键顺序检查焦点，并确认回车键与按钮的行为合理。对长表单，分组标题与必填说明可以减少理解负担。把系统字体放大后再次测试是否发生文字遮挡、按钮溢出或错误信息消失。移动端横竖屏均要操作一遍，不能只凭电脑端截图判定无障碍性已经完成。
把隐私和反滥用放进提交链路
用户填入的姓名、邮箱或手机号码，应通过加密连接传输，并按照业务目的设置合理保存和访问控制。不要在前端控制台日志或分析工具中完整记录表单内容。对容易遭遇机器提交的接口，可以增加限流、验证码或其他合适的人机风险检查，但不应让防护机制完全挡住使用辅助技术的人。服务端要限制字段长度、防止常见注入攻击并设置合理的身份鉴别或防重放机制。对外部营销留资，还需要清楚告知用途、联系方式和适用的同意或退出机制。安全设计不是事后加一个同意复选框就完成的，数据流转的每一步都要有明确责任人。
用真实用户任务完成最终验收
准备一份覆盖十到二十个测试输入的表格，至少包含正常提交、缺少必填、格式不对、网络中断、重复提交、键盘操作和移动设备放大字体等情况。测试人员记录实际结果、预期结果和截图，而不是只在最后写一个“OK”。如果页面声称提交成功，应确认服务端确实生成唯一记录，后台能够查看，且没有重复发送邮件或短信。对出现异常的数据，必须保留错误状态并可安全重试。发布后关注表单完成率、错误分布和垃圾提交数量，但不要通过额外采集敏感信息来提高分析粒度。真正的成功是合法用户可以清楚、稳定、安全地完成提交。
AI可快速生成一个看起来完整的表单，可靠性却取决于业务规则、服务端校验、错误提示、键盘交互和数据保护。把这些验证转成可重复执行的清单，比单纯修改外观更能节省后期返工。
