在現代的前後端協作開發中，API 的定義通常領先於實際功能的實現。當前端工程師需要開發新功能，但後端對應的 Resolver（解析器，負責將 GraphQL 欄位映射到實際數據源的函數）尚未完成時，開發者通常必須手動編寫大量的 JSON 模擬數據（Mock Data）來維持開發進度。然而，這種手動維護方式存在巨大的維護成本：一旦 Schema（結構定義文件）發生變更，原本的模擬數據就會失效，導致開發者必須反覆修改冗長的 JSON 檔案。
針對這個痛點，近期 Airbnb 與 Expedia Group 等公司開始嘗試將大語言模型（LLM）引入 GraphQL 的模擬數據生成流程中。根據 InfoQ 的報導，這類工具的核心邏輯在於將 GraphQL 的 Selection Set（選擇集，即客戶端請求的具體欄位清單）視為一種精確的規格說明書。由於 LLM 在「憑空創造結構」方面表現較差，但在「填充既有結構」方面表現優異，因此利用 GraphQL 強型別的特性為 LLM 提供一個明確的邊界，能讓生成數據的準確度大幅提升。
Expedia Group 的實作方案
Expedia 開源了一款名為 mockql-rs 的 Rust 命令行工具，其運作方式是在客戶端與伺服器之間建立一個獨立的處理程序。開發者可以在 GraphQL 查詢中使用 @mock 指令來標記尚未完成的欄位，並可選擇性地提供 Hint（提示詞）來引導 LLM 生成特定內容。
該工具的運作流程分為三個階段。首先，它使用 apollo-compiler 對請求進行解析與驗證，確保操作符合 Schema 定義。接著，它將請求拆分為「真實欄位」與「模擬欄位」，將真實請求轉發至後端伺服器，同時將模擬欄位及其對應的 Schema 片段發送給 LLM。最後，工具將後端回傳的真實數據與 LLM 生成的模擬數據合併成單一回應回傳給前端。
這種設計的最大優勢在於能實現「混合數據回應」。例如，在查詢旅程詳情時，飯店的名稱與地址可以由後端真實回傳，而推薦餐廳的清單則由 LLM 根據當前飯店的地理位置即時生成。由於 LLM 掌握了真實數據的上下文，生成的模擬數據具有高度的連貫性，且開發者無需依賴特定的 SDK 或客戶端函式庫即可在 CI（持續整合）環境中使用。
Airbnb 的靜態生成路徑與標準化爭議
與 Expedia 的即時生成不同，Airbnb 的做法是在建構階段（Build Time）處理。其 @generateMock 指令會透過 Niobe 代碼生成工具，直接產出 JSON 模擬文件以及對應的型別存取函數。這種方式更適合用於 Demo 應用程式、快照測試（Snapshot Tests）或單元測試，因為它能確保數據的穩定性，且允許工程師對生成的數據進行手動微調並在後續執行中予以保留。
除了企業實踐，GraphQL 基金會也提出了一份 RFC（Request for Comments，徵求意見稿）試圖將模擬數據標準化。然而，目前業界存在明顯的設計分歧。RFC 建議將 @mock 指令放在整個 Operation（操作）層級而非單一欄位，並要求客戶端在檢測到模擬數據與 Schema 發生偏移（Drift）時必須強制修正。此外，RFC 還前瞻性地提出應提供 Agent Skill（代理人技能），讓 AI 編碼代理人能透過對話方式直接修改模擬數據的變體。
實務意義與潛在限制
將 LLM 引入 GraphQL 模擬流程的深層意義在於，它將 API 定義從單純的「溝通協議」轉變成了「數據生成指令」。在 REST API 中，由於缺乏統一且強型別的結構描述，LLM 容易生成看似合理但實際無法使用的噪聲數據；而 GraphQL 的 Schema 提供了必要的約束，使得自動化生成變得可行且高效。
然而，這種技術路徑仍面臨挑戰。首先是標準化缺失，目前 Expedia 與 Airbnb 的實作在指令位置、參數名稱與網路行為上完全不同，且 GraphQL 基金會的 RFC 仍處於 Stage 0（初步構想階段），缺乏強大的推動力量。這意味著開發團隊若現在採取某種方案，實際上是在對接特定廠商的私有定義而非工業標準。
其次是確定性的問題。Expedia 的即時生成雖然具備上下文連貫性，但缺乏可重複性，這對於依賴固定輸出結果的快照測試來說是一個重大缺陷。如何在「數據的靈活性」與「測試的確定性」之間取得平衡，仍是目前 LLM 驅動開發流程中尚未完全解決的議題。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。