接口联调与测试

正常路径谁都记得写。空值、超长字符串、类型错误、缺必填、越权访问——这些边界和异常，取决于写用例的人当时有没有想到。

接口一改，用例跟不上。跑得通的回归测试给人虚假的安全感，真正的风险在没覆盖到的地方。

用 HTTP 请求节点拉取 OpenAPI 文档，LLM 节点以 JSON 输出格式生成用例集：路径、方法、入参、预期状态码、预期结构，每条落成固定字段。

提示词里显式要求每个接口至少覆盖三类：正常路径、边界值（空值／极值／超长）、异常输入（类型错误／缺必填／越权）。把它写进指令，比指望谁每次都记得可靠。

用例数组进循环节点，循环体内用 HTTP 请求节点发起实际请求。

循环开始节点必须设最大迭代次数——接口从 20 个涨到 200 个时，执行时长是线性涨的。HTTP 节点自带超时与重试配置，网络抖动不会直接被判成用例失败，这在联调环境里很关键。

响应与预期的比对放在代码执行节点里，按字段逐项断言。

这一条没有商量余地。如果让模型判断"这个返回算不算符合预期"，同一份数据两次跑可能给出不同结论——回归测试的全部意义就是"这次和上次一样"，一个不确定的判定器让整件事失去价值。

模型负责生成用例，代码负责判定结果，这个分工是这个场景的核心。

结束节点输出通过率与失败清单，每条失败带上完整请求参数、实际返回、以及断言在哪一项上不符。

开发拿到就能复现，不需要再来回问"你是怎么调的"。这个细节决定了测试报告是被认真看还是被直接忽略。