最近在一个金融业务的 API 上出现过这么一件事：规范说的是一回事，Postman Collection 被匆忙改成了发另一回事，而服务器返回的完全是第三种形态。一切都能跑通，没有一样是对的。

大多数漂移检测工具一次只比对两样东西：把 OpenAPI 规范和服务器比，或者把服务器和请求客户端比。两两比对能抓到明显的契约破坏，但它漏掉了一种更有意思的失效模式：规范、你的团队实际发出的请求以及运行中的服务实际返回的响应，这三者可能同时悄悄地互相不一致。

接下来讲的是如何用 Postman AI Engineer 和 Context Graph 找出这类三方漂移，包括实际使用的提示词，以及输出长什么样。

Context Graph 到底知道什么

Context Graph 是让三方检查变得可落地的那块东西。它是一张持续更新的图，记录了你所在的 Postman 组织里所有 API、Postman Collection、规范、环境、工作区、Monitor 和治理规则，以及它们之间的关系。

关键词是关系。这张图知道：这份 OpenAPI 规范是那个服务的正式契约，这些 Postman Collection 是该规范记录在案的消费者，这个 Postman Monitor 是一个打在 staging URL 上的实时验证面，而那个工作区拥有上面所有这些。你提问时，AI Engineer 遍历的是这张图，而不是靠猜。

漂移检查关心的节点和边

任何一张图的价值，都取决于它选择建模什么。Context Graph 建模的正是回答漂移问题所需要的那些产物：

• 规范是节点。每一份 OpenAPI（或者 AsyncAPI、Smithy、protobuf、GraphQL）规范的每个版本都会保留，所以这张图既知道契约今天怎么说，也知道上个月怎么说。这正是 AI Engineer 能回答漂移从什么时候开始，而不只是现在有没有漂移的原因。
• Postman Collection 是节点，collection 里每一条保存的请求都是它的子节点。这张图不会把一个 collection 当成不透明的 JSON 大块。它把端点、方法、请求头、请求体和测试脚本里的断言都看成可以单独寻址的事实。
• 实时面是节点。Postman Monitor 是一种，对着运行中的 URL 手动跑一次 collection 也算。两者都会捕获真实的请求响应对，这些配对带上时间戳落入图中。
• 环境是节点，图靠它知道某次请求发出时用的是哪个 base URL、哪套认证材料。没有这一层，collection 发送 X 这句话在 dev、staging、prod 之间就会有歧义。
• 工作区、团队和治理规则也是节点。正因为如此，规范错了才能被翻译成一句有主语的话：Payments 团队拥有的那份规范错了，而且那条标记缺失 required 字段的规则没有触发，是因为它的作用域不在这个工作区。

边承载的信息不比节点少。从 Postman Collection 指向规范的一条 consumes 边，让 AI Engineer 能回答这样一个问题：这个端点改了会搞挂谁。从 Postman Monitor 指向规范的一条 validates 边，让它能区分两种情况：服务器以前和规范一致、现在不一致，以及服务器从来就没和规范一致过。两个规范版本之间的 derives_from 边，让历史上的漂移问题变得容易回答。

为什么三方漂移场景下图比手写 diff 强

原则上，你可以手工做三方漂移检测：导出 OpenAPI 文件，导出 Postman Collection 的 JSON，抓一天服务器日志，写个脚本把三方对账，再努力回想上个季度以来改了什么。这样搭出来的脚本只在你搭好它的那一天、针对你搭它的那一个 API 有效。

Context Graph 是持续做这个对账的，覆盖组织里的每一个 API，还不需要脚本。有两个特性让它特别适合三方漂移：

1. 三方都是一等公民。规范不会被当成用来衡量另外两边的基准真值。每一边都是一组节点，图可以对它们做两两比较，也可以三方一起比，还能告诉你当有第三方持不同意见时，是哪两边仍然一致。这恰恰是两两 diff 回答不了的问题：到底哪一边错了。
2. 图从头到尾都带时间戳。每个节点有版本，每条边有 created_at，所以 AI Engineer 可以推理这样的结论：这次部署改变了响应结构，或者这条 collection 断言一直都比规范宽松。带时间点的 diff，才把漂移从一团迷雾变成可以追责的 git blame。

还有第三个不太显眼的好处。因为治理规则和工作区归属也在图里，AI Engineer 能给每一行漂移附上名字：refunded 这个枚举值在生产环境出现了，但不在规范里；这份规范归 @payments-platform 所有，他们的治理规则要求枚举变更必须提升规范版本号。这就是一份只能丢进工单的漂移报告，和一份可以直接路由到人的报告之间的差别。

也正因为如此，AI Engineer 能在你不做任何拼接的情况下比较三方。规范是节点，collection 里保存的请求是节点，Monitor 最近的运行以及它捕获的响应也是节点。漂移是横跨所有这些的 diff，而不是其中一对，而图已经把连接都做好了。

提示词

下面是实际发给 AI Engineer 的提示词。这里要明确说清要比对哪三方，因为默认倾向是退回规范对代码。原文一个字没改：

Compare the spec to what the collection actually sends and what the running server returns. Show me all three way drift, not just spec vs code.

就这一句。不需要附 JSON schema，也不需要贴脚本。Context Graph 会自己解析出该 API 的规范、消费它的 Postman Collection，以及运行中的服务器。

你可以从 Postman 界面发这条提示词，也可以从 Slack 发，或者通过 API 发。想让报告落在 PR 讨论旁边时，就在 Slack 里跑。

报告长什么样

输出是按端点拆分的。每一行列出规范怎么说、collection 实际发什么、服务器实际返回什么，你一眼就能看出哪一边错了。

下面是从一次真实运行中摘出来的简化片段：

POST /payments
  spec:        body.amount is integer, required
  collection:  body.amount is integer, sent
  server:      response.amount is string ("120.00")
  verdict:     server-side drift (integer → string response)

GET /payments/{id}
  spec:        response.status is string enum ["pending","captured","failed"]
  collection:  asserts response.status in ["pending","captured","failed","refunded"]
  server:      returns "refunded" in ~4% of recent responses
  verdict:     three-way drift (spec, collection, and server all disagree)

DELETE /payments/{id}
  spec:        204 No Content
  collection:  asserts 200
  server:      returns 200 with empty body
  verdict:     spec-vs-implementation drift; collection is aligned with server, not spec

四列的含义分别是：spec 是规范里的定义，collection 是 Postman Collection 实际发送或断言的内容，server 是服务器真实返回的内容，verdict 是 AI Engineer 给出的漂移判定。

GET /payments/{id} 那一行是最有意思的。任何规范对代码的检查都不会标记它。规范和服务器在枚举上不一致；而 collection 有它自己的一套枚举，比规范宽，又比现实窄。三方朝三个不同方向错了。

这正是 Context Graph 擅长暴露的那一类 bug，因为它把 collection 里的断言当成一等产物来看，而不是忽略它们。

在同一轮对话里接着追问

AI Engineer 是 agentic 的，所以拿到初始报告后你可以继续问。第一轮之后最常问的是这几句：

对于每一行三方漂移，告诉我应该相信哪一边，以及为什么。

哪些 Postman Collection 在消费 /payments，如果我把规范改成和服务器对 `amount` 的响应一致，哪些会出问题？

起草一份 OpenAPI 补丁，把 GET /payments/{id} 的枚举对齐到服务器，并列出哪些 collection 需要更新断言。

最后那句就是 context 这个词值回票价的地方。AI Engineer 会遍历图，找出所有请求触达该端点的 Postman Collection，并报告其中哪些的测试脚本还在按旧结构断言。你拿到的是一串 Postman Collection 的名字，而不是一句没把握的让你自己回仓库里搜一下。用这个办法能避免对内清理之后，对外的合作方 collection 悄悄退化。

在你的工作区里怎么跑起来

在 AI Engineer 真正能做三方检查之前，你需要先准备好三样东西：

1. 一份发布到 Postman 工作区的 OpenAPI 规范。Spec Hub 文档里讲了怎么创建和版本化。没有规范，AI Engineer 就只有两边可比。
2. 一个真的会去调这个 API 的 Postman Collection，最好是你们团队在 CI 或演示里用的那个。这就是客户端发送什么这一边。从零开始的话可以看 collections 文档。
3. 一个近期的实时面。打在 staging 或生产上的 Postman Monitor 就很合适，因为它给 Context Graph 新鲜的响应可供推理。实在没有，AI Engineer 也可以在自己的沙箱里，对着一个运行中的 URL 自己跑 collection。

需要说明一句：这三个前提都落在 Postman 生态内。这三样到位后，上面那条提示词按原样就能用。如果你想在 CI 里跑，Postman CLI 通过 API 暴露了 AI Engineer，你可以像跑测试一样把漂移检查接进 PR 流水线。

base URL 和认证 token 建议留成环境变量，不硬编码在 collection 里：

{
  "id": "payments-staging",
  "name": "Payments Staging",
  "values": [
    { "key": "base_url", "value": "https://staging.api.example.com", "type": "default" },
    { "key": "auth_token", "value": "{{secret_staging_token}}", "type": "secret" }
  ]
}

把它作为一个新环境导入，把 token 标成 secret，AI Engineer 在拿 collection 打实时面时就会用上它。

几个要留意的坑

有几个坑值得提前说一句。

流量要够新。Context Graph 推理的是它实际观测到的响应。如果你的 Monitor 一周没跑，而服务器昨天改了，先让 AI Engineer 跑一遍 collection，再重跑漂移分析。否则你就是在拿规范和 collection 去比对一份过期的生产快照。

collection 的断言属于消费者这一边。如果你的测试脚本悄悄把响应结构钉死了，这个钉子本身就是你们团队做出的承诺。当漂移报告说 collection 和规范不一致时，往往说明有人几个月前绕过了一个规范 bug 打了补丁，然后忘了修规范。

不是每一行漂移都是 bug。有时候服务器是有意返回规范里还没有的字段，因为功能还在开关后面。有用的做法是让 AI Engineer 把每一行分类成规范错了、服务器错了或 collection 错了，并从图上追溯每一边最后一次变更。这通常能直接指向那个有罪的 commit 或 Postman Collection 修订，不用考古。

认证往往是最吵的那一个。在上一次运行里，最吵的漂移根本不在业务字段上。规范描述的是放在 Authorization 头里的 bearer token，collection 里有一半请求把它当成查询参数发，那是更早的认证模型留下的东西，而服务器两种都接受。什么都没坏，一切都错了。这正是三方比对能抓到、两两检查会漏掉的那种安静的漂移。如果你想顺手给自己的认证流程做个体检，Postman API Security 规则值得在追问时指给 AI Engineer。

把它加进评审流程

最好用的工作流不是一次性的漂移排查，而是在每一个不那么 trivial 的 API PR 上跑那条三方提示词。AI Engineer 把报告发成一个 Slack 帖子，评审者先看报告再看 diff，任何一行不是无漂移的，都在合并前处理掉。

这个安排有两点值得说：规范、collection 和服务器被当成一个系统来评审，而不是三件独立产物；而且报告用的是整个团队本来就熟悉的词汇，比如端点、字段、状态码，不是内部治理方言。

拿你自己的 API 试一下。把 AI Engineer 指向一份规范、一个 Postman Collection 和一台运行中的服务器，原样发上面那条提示词。然后在下次合并之后再跑一次，看看三方里哪一边动了。有意思的漂移，几乎总是出现在两次运行之间的差集里。

收录于 FunTester 原创专题：AI ，测试有点东西

相关阅读：Agentic AI 如何增强 API 测试 · Pact：微服务契约测试的利器 · 看懂 AI 测试工具的四种类型 · 拒绝拍脑袋，AI 测试的工程化实践 · Postman 进阶