火小懂编辑部
让AI自动生成JSON Schema能节省许多手工整理字段规则的时间，但生成结果并不等于已经理解企业业务。一个语法完全正确的Schema，仍可能漏掉金额边界、错误地拒绝空值、允许用户提交管理员字段，或者使用与项目验证器不兼容的规范版本。如果直接把这些规则部署到生产接口，就会出现本来合法的请求被拒绝、错误数据被接收，甚至权限被误用。本文按JSON Schema 2020-12规范梳理六步独立验收方法，帮助开发者把AI当作候选规则生成器，而不是最终安全裁判。
第一步：先固定版本、场景与字段合同
JSON Schema官方发布的Draft 2020-12于2022年6月16日形成，区分Core与Validation规范，并更新数组以及动态引用等关键字。项目必须先确认真实验证器支持哪个草案，不应让AI把旧版示例与新版语法混在一起。接口用于接收用户输入、输出处理结果还是校验内部数据，所允许的字段常常完全不同，应该分别建模。
建议建立字段合同表，明确字段名称、类型、是否必填、允许为空、长度区间、单位、权限来源以及异常响应。比如订单创建请求允许用户填写商品数量，不应允许其自行提交系统结算状态。若AI建议增加管理员相关字段，应先请业务负责人核查真实需求。
同时记录Schema版本和接口版本的映射关系；不能只保留一个名为schema.json的文件，否则上线后很难确认哪个客户端在使用哪一套规则。
第二步：逐一检查必填、类型和空值语义
required描述对象中某个属性是否必须出现；type则规定值的数据类型。属性不存在、属性值为null以及属性值为空字符串，是不同的输入状态。AI常把“可以不填”误写成“必须填但允许null”，也可能错误地把金额处理为浮点数或把长数字标识处理成整数，造成精度与格式问题。
对金额和数量，应核实货币单位、整数或小数策略、最小值、最大值和异常负数处理。对电话号码、国际地址或人名，不能简单用只适合单一国家的正则表达式拒绝合法用户。正确规则应由业务需求和数据格式共同决定，不能由模型习惯性补全。
测试集至少包含缺失字段、空字符串、null、零、负数、超长文字、布尔值与类型错误，每一项都应有人工定义的预期结果。
第三步：理解额外字段与组合验证的区别
additionalProperties用于约束对象中未被显式声明的属性，而unevaluatedProperties在复杂组合Schema里具有不同语义。如果AI把两者混用，某些合法的组合对象可能被错误拒绝，也可能让不希望接收的字段进入业务系统。应先用最小样例验证组合行为，再把规则扩展到完整请求。
对于金融、订单或账户修改接口，通常要严格限制能够影响权限或金额的未知字段；对于可扩展的公开展示数据，则可能需要有意容纳新字段。不能一概把“拒绝所有额外字段”当作最佳实践，也不能在任何场景都允许客户端携带无限属性。
尤其在oneOf、allOf和嵌套数组共同出现时，要对每一种分支写测试样本，确认验证器采用的是团队指定的规范版本。
第四步：负向测试比漂亮的正常样例更重要
接口通过一份完美JSON，只说明最简单路径没有失败。真正的验收应故意提交无效数据：缺少必填属性、类型错误、数值越界、不允许的额外字段、数组元素格式错误、错误的枚举值、递归嵌套异常，以及长度极端但结构合法的请求。验证器需要给出可定位的错误而不是直接崩溃。
把每个负向样本与预期状态码、错误路径和用户提示对应起来。对于含中文、日文和特殊符号的字符串，要确保编码处理正确，不要把字符数与字节数混成同一个限制。所有测试都应在隔离环境运行，避免错误输入影响真实订单或客户记录。
注意JSON Schema负责数据结构，不是业务权限引擎。即使订单ID格式正确，服务端仍需要确认请求者是否有权访问该订单。
第五步：检查AI生成验证代码的安全边界
一些自动生成脚本可能为了调试而打印完整请求体，包含姓名、地址、密钥或其他敏感信息；也可能自动从外部URL读取Schema，没有明确的来源限制。正式环境应最小化日志、隐藏秘密字段，对远程引用设置白名单和资源使用上限，防止攻击者利用复杂数据结构造成异常内存消耗。
NIST于2022年发布的SP 800-218安全软件开发框架强调在软件生命周期管理安全风险。落实到此类小工具，就是审核生成代码、锁定第三方依赖、运行异常输入测试、制定日志脱敏规则，并准备撤回有问题版本的方案。
若使用AI辅助产生测试用例，最好再由独立人员或另一种方法计算预期结果，减少“生成代码和测试答案同时错误却彼此吻合”的风险。
第六步：版本升级要有兼容和回滚流程
后端新增必填字段，旧客户端可能会突然无法提交；若把字符串字段改为整数，历史数据可能也无法直接通过验证。发布新Schema之前，应先保留旧版请求样本，测试与现有SDK、移动端和异步任务的兼容性。在需要时，采取分阶段部署和兼容窗口，而不是把所有客户端同时强制切换。
上线监控要关注验证失败率、具体错误类型、用户地区和客户端版本。发现某类请求异常增加时，能快速定位到新规则并切回旧版，而不需要暂停整个业务。迁移记录应说明哪些约束变严、哪些字段被弃用、何时完全停止兼容。
最终验收包应包含官方规范链接、字段合同、Schema版本、正常和负向测试、代码安全审查、监控指标及回滚步骤。AI提升的是准备效率，生产正确性仍须由可验证证据负责。
