表单看起来正确，但数据合约却错误。

问题不在于 AI 构建的表单是否看起来已准备好投入生产，而在于接收其数据的系统是否会接受。

日期选择器可能显示得很完美，但在 API 期望 ISO 日期时却提交了依赖于地区的字符串。复选框可能显示为是或否，而数据库却期待布尔值。演示通过了，截图看起来整洁，但错误却在下游等待。

表单到底承诺了什么？

表单设计通常被视为界面问题进行审查。人们能理解标签吗？标签顺序是否合理？页面在手机上是否正常运行？这些问题固然重要，但它们并未涵盖全部工作。

表单还承诺提供结构化数据，使其他系统能够解析。此承诺涵盖字段名称、数据类型、必填值、可选项、默认值、标识符以及目标映射。若在不更改接收系统的情况下更改其中任意一项，即使是精致的界面也可能变成不可靠的集成。

当 生成式 AI 文档自动化 超越文本草稿并开始生成结构化文档和交互式组件时，这一界限变得更难以辨识。生成速度快，因为模型可以从简短描述中推断出合理的布局。然而，合理并不等同于兼容。

IETF JSON Schema 工作组的 活跃的互联网草案（最近更新于 2026 年 8 月 26 日）将模式描述为一套约束可接受 JSON 值的规则。它还讨论了诸如 UI 渲染器等生成式用途。这种组合直指问题核心：相同的模式或许有助于创建界面，但验证仍必须决定生成的输入是否属于可接受集合。

为什么合约会漂移？

AI 并不需要生成明显错误的代码就能导致糟糕的合约。它只需做出一个合理的假设，而该假设并未被系统的其他部分共享。

想象一个入职表单，其中有一个标记为 “Customer ID” 的字段。模型将该字段命名为 customer_id，似乎合乎情理。现有 API 仍然期望的是 account_number。每位测试用户都可以填写此框，但如果集成未拒绝或转换这个意外的属性，标识符可能永远无法到达正确的记录。

类型会产生同样的错配。空字段可能以空字符串、null 或根本没有属性的形式出现。数字可能以文本形式出现。下拉菜单可能显示友好的标签，而接收系统却期待稳定的代码。OpenAPI 3.2.0 使用 用于定义输入和输出数据类型的模式对象，为团队提供机器可读的描述，以便与表单进行比较，而不是仅依赖屏幕上看起来收集的内容。

依赖关系更容易被忽视，因为它们隐藏在用户选择背后。选择一个国家可能会使州、省或地区字段变为必填。选择“公司”而非“个人”可能需要提供注册号。JSON Schema 的 条件验证 可以通过依赖需求和条件子模式来表达这些关系，但生成的表单仍必须实现相同的规则。

向开发者公开字段名称、类型、值和属性的工具，使 PDF 表单字段验证 成为构建过程的一部分，而不是在最后进行的视觉检查。这并不能取代模式验证器或 API 合约测试。它让开发者能够控制表单端对象，供这些测试检查使用。

还有另一种漂移来源：表单和合约可能最初保持一致，但随后在不同的时间表上发生变化。提示被修改，字段标签被重命名，API 删除了某个选项或引入了新的必填属性。没有人看到布局破损，因此这些更改看起来无害。

并非如此。

如何测试除顺畅路径之外的情况？

一次成功提交只能证明某一组合的值曾经可行。生产环境的表单需要更严格的检验。

从负载而非截图开始。提交一个已知良好的示例，并将实际序列化输出与合约进行比较。检查属性名称、类型、嵌套结构和允许的值。随后将该负载通过真实的集成发送，确认相同的值能够在往返于 CRM、ERP 或数据库以及任何审查界面时保持不变。

接下来的测试应设计为失败。尝试缺少必填值、在应为 null 的位置提供空字符串、超出范围的数字、意外的下拉选项以及合约未识别的属性。有效的验证层不仅仅是阻止请求，还要清晰地指出导致失败的字段和规则，以便开发者、运维人员或用户能够修复。

条件分支值得单独测试。如果表单包含五种选择会显示不同的后续字段，则需对全部五种情况进行测试。同时也要测试切换回去的情况：当用户更改早前的答案后，隐藏字段不应继续提交陈旧的值。这正是 文档结构和上下文 相关的文章与普通软件测试相交的地方。只有当文档中的关系在序列化后仍然保持，理解这些关系才有意义。

字段标识比字段文字更重要。标签会因清晰度、翻译和品牌语调而更改。稳定的内部标识不应随之改变。因此，发布检查应分别比较可见标签、内部名称、预期类型和目标映射等属性。

最后，注意当接收系统不可用或拒绝提交时会发生什么。表单会保留用户的工作吗？它会安全地重试，还是会产生重复？操作员能在不阅读原始日志的情况下追踪故障吗？在 document-processing workflows and enterprise systems 之间传输的数据需要可观察的失败路径，而不是在交接完成前就显示的成功信息。

发布后合同的所有者是谁？

合同测试不能仅在发布前进行一次性清理。表单、模式以及下游接口将持续变化。

即使工作流的多个环节由不同团队负责，也需要有一个团队对合同拥有明确的所有权。该所有者不必批准每一次文案修改，但必须了解哪些更改会影响提交的数据、需要运行哪些测试，以及在验证失败时由谁负责响应。

将模式与表单定义一起进行版本管理。每当模板、提示、表单代码或 API 发生更改时，在持续集成中运行代表性的合同测试。生产环境中，要按字段和合同版本监控被拒绝的提交和映射失败。发布后出现的单一错误上升，比起模糊的“表单停止工作”报告更容易诊断。

模式验证能够证明的范围是有限的。它可以显示某个值符合声明的约束，但无法证明用户选择了正确的值、业务规则是否合理，或工作流是否满足所有安全、隐私、可访问性或合规性要求。团队仍需在后果严重的情况下进行政策检查和人工判断。

这一警示并未削弱合同的必要性。它界定了合同的职责。

结论

AI 可以缩短从描述到可用表单的过程。它也可能在任何人测试其背后承诺之前，使界面看起来已经完成。

发布决策应基于明确的字段语义、包含失败案例的合同测试以及能够在后续更改中仍然有效的所有权。干净的界面固然受欢迎，但更关键的问题是：每个被接受的输入都能被接收系统正确解释吗？