Expedia和Airbnb引入LLM生成的GraphQL模拟数据，不过规范相对滞后

事件核心：发生了什么

Expedia Group 近期开源了 Rust 命令行工具 mockql-rs，该工具能在请求发生时调用大语言模型，为 GraphQL 查询中标注了 @mock 指令的字段生成模拟响应。其设计思路是：开发者只需在尚未实现的后端字段上添加注解和提示词，工具便会利用 Apollo Compiler 解析并验证操作，将真实字段转发至上游服务器，同时将模拟字段交给 LLM 填充，最后合并为一个完整的 GraphQL 响应返回给客户端。

这并非孤例。Airbnb 在今年 4 月发布了 @generateMock 指令，在构建时生成模拟 JSON 文件及类型化访问函数，供演示应用和测试使用。更早的 2 月，GraphQL 基金会则提交了一份 RFC，提出在操作级别定义 @mock 参数，并要求客户端绕过网络直接返回本地模拟数据。三方都认可同一个前提：GraphQL 的选择集本身已经为生成数据提供了清晰的“形状约束”，LLM 擅长填充内容而非创造结构，Schema 恰好补足了这一短板。

为什么重要

这三项进展指向同一个痛点：在前后端并行开发中，手工维护上百行 JSON 固件文件既低效又脆弱，Schema 一旦变更，文件随即失效。引入 LLM 后，开发者只需描述字段意图（如“附近最受欢迎的 5 家餐厅”），模型即可在既定结构内生成可信数据，并将真实后端响应与生成数据合并在同一个 payload 中，响应本身不标记来源差异。

但更值得关注的是标准化进程的滞后。GraphQL 基金会的 RFC 目前仍处于第 0 阶段，即“初步草案”，没有列明倡导者，也不保证继续推进。Expedia 与 Airbnb 在指令名称、参数位置和运行时机上已出现显著分歧，RFC 还要求客户端检测模拟数据与操作之间的漂移并强制纠正，而 Expedia 的每次运行时生成方式提供了上下文一致性，却无法支撑依赖可重复性的快照测试。三方互不兼容的设计，意味着团队若将 @mock 作为标准推行，实际上只是在追认某一供应商对名称的私有解释。

对用户/开发者/创作者的影响

对使用 GraphQL 的团队而言，这类工具能显著降低联调阶段的前后端依赖阻塞：前端可在后端接口未完成时直接获得结构合法、语义合理的模拟数据，CI 流程中也能注入动态 mock 来覆盖边界场景。但采用时需注意风险：目前公开信息显示，Expedia 的非确定性生成数据无法提供快照测试所需的固定基线，这对回归测试意味着什么尚无明确答案；而 Airbnb 的方案虽保留人工编辑能力，却绑定在其 Niobe 代码生成体系内。若项目需要跨团队统一 mock 策略，建议等待 RFC 后续进展，或在内部明确选定一种实现并接受锁定成本。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

值得关注的后续

其一，RFC 是否会在未来半年内从第 0 阶段进入正式草案阶段，以及三方设计能否在参数语义上收敛，是判断该领域是否会形成事实标准的关键信号。其二，Expedia 选择 CLI 而非 SDK，意味着 mockql-rs 可能被集成到各类 CI Runner 或脚本中，需观察其社区采用速度以及与 apollo-client 生态的兼容性。其三，RFC 中提及的 Agent Skill 场景——允许编码智能体通过对话方式增删模拟变体——如果落地，将把 mock 管理纳入更广泛的 AI 辅助开发工作流，这可能是比规范本身更值得追踪的演进方向。

来源：InfoQ CN