最近对接一家物流服务商的开放平台，我差点被AI式工整的回复气笑。

文档打开一看：只有请求 JSON、响应 JSON，字段一个字说明都没有。 哪个必填、单位是克还是千克、全靠猜。

这还不算完。真正让我确信对面大概是业务人员丢给AI写的，是后面几件事。

签名错了？不，是小数惹的祸

其它接口过了签名，下单接口怎么都过不了签名。我按文档把字段顺序排好、编码好、加签好，对面一直回签名错误。

我从问到对方回复，等了两天。最后终于丢过来一段语气非常标准、条目清晰的说明，大意是：

我们这边用的是 Node.js，JSON.stringify 不支持小数，所以金额等字段不能传小数……

我盯着屏幕看了三秒。

Node.js 当然能处理小数。 JSON.stringify({ a: 1.5 }) 就是 "{\"a\":1.5}"，这是语言基本能力，跟会不会写业务没关系。他们真正的意思大概是：

  • 自己的签名串拼接/序列化实现里，把小数搞丢了或格式化乱了；或者
  • 服务端校验只认整数，要取整，文档却没写；

我侧是.NET，小数用decimal，序列化成 JSON 数字完全正常。最后对接只能按对方实际能吃的格式改——金额改成取整

两天，就为了等一句AI式回复。

更搞笑：取消接口是路由参数，还得传空JSON

取消运单的接口，路径上已经带了单号（典型路由参数）。按常理，DELETE /shipments/{id} 或者 POST /cancel/{id}，body 空着或根本不需要 body。

对方要求：必须传一个空 JSON。

就是 {}。

不传就是参数校验失败。

我猜实现大概是：框架/网关层写死了「POST 必须有 JSON body」，AI 生成的 handler 又统一 JSON.parse(req.body)，没body就不行。

每次回复都像同一份模板

后面几次答疑，味道都一样：

  • 分段清晰、加粗恰当、列表工整
  • 术语齐活，因果却对不上现场
  • 很少承认「我们实现有 bug / 文档漏了」
  • 很喜欢甩锅给语言、框架、标准库

明明简单的问题能回复很长一段话，还要解释的非常仔细，一看就不是人类。

我在跨境物流里踩过不少服务商文档的坑，以前常见的是：字段过时、示例是假的、测试环境和生产行为不一致。最近2026年，多了一种：文档和答疑本身就是AI 一键生成，实现代码也是AI一键生成，两边还对不齐。

为啥有人敢写完就上线？

不是因为他们更勇，是因为成本结构变了：

  1. 写接口的成本接近0。 丢一段提示词就能出 Express/Nest 骨架、出「看起来很全」的 README。
  2. 丢人对接方成本很低。 签名失败、字段含义不明、空JSON玄学，耗的是你的联调时间，不是他们的发版压力。
  3. 真出事还有词： 我们用了业界主流技术栈，文档已提供完整JSON示例，还有c#,java,php,nodejs,rust语言示例（你敢信，连rust都有）。

所以你看到的不是勇气，是把验证义务外包给对接方，我们对接方变成了他们免费测试的小白鼠。