用 AI 做接口联调排错：从报错定位到可复现验证的四步工作流

接口联调出问题时，最耗时的往往不是改代码，而是定位：前端说后端没有返回，后端说请求发得不对，网关日志又各说各话。本文介绍一个用 AI 辅助联调排错的四步工作流：先收齐证据，再做差异比对，然后构造最小复现，最后按清单验证修复。目标不是让 AI 替你改代码，而是让每一次报错都有可核对的证据链。

一、第一步：先收齐证据，再问 AI
联调排错的第一条纪律，是不要只贴一句报错就问 AI。先把四类证据准备好：1）完整请求，包括方法、URL、请求头和请求体；2）完整响应，包括状态码、响应头和响应体；3）服务端关键日志，最好是同一请求 ID 的前后几行；4）接口契约，也就是接口文档或 OpenAPI 定义里对这个接口的约定。把这四类材料按顺序贴给 AI，并说明期望的输出是“可能原因列表，按可能性排序，每条给出核对方法”，而不是直接给修复代码。这样 AI 的回答才有办法逐条验证。

二、第二步：让 AI 做契约与实际报文的差异比对
很多联调问题来自契约与实现不一致。把接口文档里的字段表和实际请求、响应报文一起交给 AI，要求它逐字段比对：字段名、类型、是否必填、枚举值、时间格式。常见的差异有：前端传了字符串，后端期望数字；文档写的是毫秒时间戳，实际传的是秒；分页参数名是 pageSize，服务端却只认 size。让 AI 输出一张差异表，每一行写清“契约怎么说、实际怎么传、影响是什么、改哪一侧”。这一步的价值在于，定位结论不再是猜测，而是可以逐行打勾的清单。

三、第三步：让 AI 生成最小复现用例，把问题从“环境”里剥离出来
定位到可疑点之后，下一步是复现。让 AI 根据已有的请求信息生成一个最小复现用例：一条 curl 命令、一段调用脚本，或者一个 Postman 可导入的请求。复现用例要满足三点：去掉业务无关的字段，只保留触发问题的最小字段；固定输入，每次执行结果可对比；能分别在本地、测试环境和联调环境跑一遍。这样就能判断问题出在哪一层：如果 curl 直接调后端也报错，问题在后端；如果直接调通、经过网关才报错，问题可能在网关配置或鉴权；如果只有前端调不通，问题可能在跨域、请求头或序列化上。

一个真实感很强的例子：下单接口返回 400，后端日志只写“参数校验失败”。把请求体、校验规则和日志一起交给 AI，它比对后发现请求体里 amount 是字符串 "99.00"，而校验规则要求数字；同时时间字段 createTime 传的是 "2026-11-08 10:00:00"，服务端期望 ISO 格式。按 AI 给出的差异表改掉这两处后，再用最小复现用例重新跑一遍，接口返回 200，问题一次定位、一次验证，没有来回扯皮。

四、第四步：修复后按清单验证，不要只看“这一次通了”
修复之后，先别急着说完成。让 AI 根据这次的问题生成一份回归验证清单，逐项执行并记录结果：1）原报错场景重新跑一遍，确认返回符合预期；2）边界值再测一遍，例如空值、超长字符串、金额为 0 的情况；3）错误场景确认，例如参数缺失时返回的错误码和提示是否友好、是否和文档一致；4）超时与重试场景，例如服务端慢响应时前端是否会重复提交。每一项只记“通过 / 未通过 + 实际返回”，不要写“大概没问题”。清单全部通过，才把结论和复现用例沉淀下来，写进团队的联调问题记录里，下次遇到类似报错可以直接复用。

五、一个可以直接复用的提问模板
下次联调报错，可以直接按这个结构问 AI：“接口是 POST /orders，请求体如下，响应是 400，响应体如下，服务端日志如下，接口文档要求如下。请按可能性排序列出可能原因，每条写清核对方法；再给出最小复现的 curl 命令；最后列出修复后需要验证的清单。”模板里的关键不是话术，而是把请求、响应、日志、契约四类证据一次性给齐。证据越完整，AI 的结论越能验证；证据越少，回答越像猜测。

六、使用 AI 排错时的三条注意事项
第一，脱敏后再贴。请求头里的 Token、签名、密钥不要原样贴出，先替换成占位符；真实用户数据也要脱敏，只保留能触发问题的字段结构。第二，不要直接采纳 AI 给出的修复代码。先看它改了什么、为什么这样改，再在测试环境用最小复现用例验证，确认没有引入新问题。第三，AI 只能处理你给它的证据。如果日志截断了关键行，或者契约版本本身就是旧的，AI 的结论也会跟着错。先核对证据本身是否完整、版本是否最新，再讨论结论。

结语
接口联调排错的核心能力，不是记住多少报错码，而是建立一套可复用的工作流：收齐证据、比对契约、最小复现、清单验证。AI 在这套流程里的作用，是把散落在各处的证据对齐、把可能原因排好序、把复现和验证清单写出来。把这套流程跑顺，联调时的沟通成本会明显下降：讨论的不再是“谁的锅”，而是“差异表第几行、复现用例第几步、验证清单第几项”。