一、背景介紹

現階段前后端自測+聯調耗時較長，經過摸底，耗時主要在以下幾個方面：接口錄入、接口轉為前端代碼、mock數據生成。但是在我們預期中，聯調耗時占比應該很少，理想情況下就像兩個匹配的齒輪，各自完成開發后，組裝在一起便可順利運行。為了達到這種狀態，需要重新梳理我們現有的工具和流程，融入AI的能力，讓聯調自測環節更加高效。

目前存在的問題包括：接口文檔維護不及時，導致前后端理解不一致；手動編寫接口調用代碼效率低下；mock數據缺乏真實性，無法充分驗證業務邏輯；聯調過程中頻繁的溝通協調消耗大量時間。這些問題不僅影響了開發效率，也降低了代碼質量和項目的整體交付速度。

二、項目目標

通過AI智能化，改進接口從定義到聯調的全流程，提升前后端聯調效率。將自測聯調占開發時間的比值顯著降低。

預期效果

通過引入AI能力，實現接口文檔的智能生成和維護，自動化的代碼生成，以及更真實的mock數據模擬。讓前后端開發能夠無縫對接，大大減少聯調階段的溝通成本和問題排查時間，最終實現開發效率的質的提升。

三、項目方案

針對這些問題，我們計劃通過AI改進現有系統的方式，讓開發同學可以圍繞接口平臺（ZAPI） 和IDE（Cursor）來實現從接口定義到自測聯調的全部流程，從而提升自測聯調效率。

傳統的流程中，接口的定義往往是先寫一個簡陋的文檔，然后前后端根據文檔，編寫具體的代碼，過程中再不斷完善文檔。但如果放到現在，這個流程相對就比較繁瑣了，并且不可避免的有重復的工作（比如接口說明、描述等）

結合當前AI能力，我們重構了一下我們接口的定義與聯調流程，更多的將整個流程整合到我們的核心工具鏈條中（Cursor + ZAPI）

這里面特別是Cursor，對于程序員來說，我們最終的產物都會落在代碼上，而最懂你代碼的就是你的IDE（Cursor），所以我們整體思路上，就是能在Cursor上完成的，就在Cursor上完成。

img

3.1 接口錄入

在軟件開發過程中，接口文檔的維護一直是開發團隊面臨的挑戰。無論是手工編寫文檔的低效與錯誤，還是代碼變更后文檔同步的滯后，再到不同數據源文檔格式的不統一，這些問題都直接影響著開發效率和團隊協作。接下來，讓我們具體看看這些常見的問題：

img

3.1.1 方案概要

方案概要主要是將目前三種可生成接口數據源統一落到ZAPI平臺里，然后通過工程化處理后調用模型生成OpenAPI，中間再有一些規范校驗、差異檢測操作后落入到ZAPI平臺上進行接口管理。

img

3.1.2 技術架構

大神文檔和純文檔方案是相似的，都是把富文本轉化成Markdown，所以下面的內容主要著重Git代碼生成接口部分。

img

在調用模型接口之前，還需要做一些工程化能力：精準識別變更方法、按方法數進行文件拆分、解析Java代碼上下文。

3.1.3 精準識別變更方法

只獲取目標方法（變更、新增），而不是代碼里所有方法。

3.1.4 拆分文件

拆分文件的目的：如果某個分支代碼影響的方法過多，比如新起了一個項目新增了很多接口，過長的代碼作為輸入token就會導致模型接口超時或模型輸出token不完整等問題，而且拆分后還可以并發調用模型接口提高生成速度。

img

目前按2個方法拆分文件

ICemUserTestService.java_part1 包含前兩個方法

ICemUserTestService.java_part2 包含最后一個方法

img

3.1.5 解析Java代碼上下文

識別到方法后，如果沒有解析出相關聯的引入類那么模型生成的數據在出入參等字段上就會有缺失，因此還需要解析出方法關聯的入參、返回值類，這樣我們獲取到完整java代碼后，再把這些代碼和對應的路徑作為prompt的一部分。

3.1.6 模型Prompt編寫

經過上面步奏獲取到完整上下文的java代碼后調用模型接口生成openapi json，我們主要關心接口名稱（ZAPI接口名稱）、接口路徑、請求方法、請求格式、請求參數、字段屬性、Tag（ZAPI分類）這些生成的準確度，下面著重講解下請求格式、請求參數、字段屬性：

3.1.7 總結

和傳統靜態解析相比，利用AI只需要關注接口生成的規則給予相應的prompt，則無需修改代碼，智能理解業務邏輯，自動生成高質量接口文檔。

3.2 zapi接口智能轉為前端代碼

以往我們在編寫前端調用接口代碼，都是對著ZAPI文檔手工編寫，在前端也需要寫一份和后端類似的各種類型定義，這種過程是繁瑣且耗時的，有下列痛點：

img

3.2.1 MCP-ZAPI實現代碼生成

現在我們在cursor中利用MCP-ZAPI來實現前端調用接口代碼的自動編碼，有更快的速度和更一致的代碼風格。

支持單個、多個URL，并且支持提供文件或不提供文件兩種方式。

提供對應文件時，會先理解該文件中的代碼風格，并將接口定義生成到對應文件中。

不提供對應文件時，會先理解該工程中接口定義的代碼風格，新建語義化文件并將接口定義生成到新建的文件中。

img

img

• 首先會對引用的url進行分析，并獲取到接口schema。
• 判斷是否有引用的目標文件以及分析當前工程的接口定義風格。
• 保證相同的代碼風格并生成接口定義代碼。

3.3 AI_MOCK工具集成

前端mock數據一般是使用mockjs生成，但是還存在以下問題：

• 需要手動編寫mock數據
• 同一接口mock數據只有一份，使用者不能方便自定義使用修改mock數據
• 全是隨機數據，無法滿足業務自測場景

3.3.1 接入集成

在項目中接入內部npm包，這個實現原理主要是攔截ajax和fetch請求，接入后會在頁面展示氣泡入口。

3.3.2 使用

點擊氣泡彈出有抽屜，展示攔截的接口列表。

img

img

點擊查看按鈕，可查看或修改響應數據。可以使用mockjs生成mock數據，或者也可以點擊AI生成按鈕來生成，通過匹配ZAPI接口schema后調用模型接口來生成更加符合業務語義化的mock數據。

3.3.3 總結

通過集成AI_MOCK工具后，每個使用者可自定義接口mock數據，在開發階段可使用更加真實符合業務的數據，尤其是demo演示時更加真實。

四、總結與展望

4.1 總結

通過系統化引入AI技術改進前后端聯調流程，我們在接口錄入、代碼生成、Mock數據等關鍵環節取得了顯著成效，驗證了AI在軟件開發流程中提質增效的巨大潛力。在多個典型實踐場景中，AI展現出在接口文檔自動生成、前端代碼智能轉換、業務語義化Mock數據生成等方面的突出能力，大幅降低了重復性、規范化工作的開發成本，同時有效保障了接口定義的一致性和代碼風格的可維護性。

4.2 展望

隨著生成式AI技術的持續演進，我們正站在一場前后端聯調流程變革的起點。傳統的"接口文檔→手工編碼→聯調測試→問題修復"的線性流程將被徹底重構。

從"文檔驅動"到"代碼驅動" 未來AI將直接從代碼變更中智能提取接口定義，實現"代碼即文檔"的實時同步，前后端開發者無需再維護冗余文檔。

從"接口到頁面"的智能生成鏈路 當接口調用代碼生成完成后，AI將結合原型圖自動生成完整的頁面代碼

從"手工Mock"到"智能仿真" AI將基于業務上下文生成真實、多樣化的測試數據，模擬復雜業務場景，讓聯調測試更貼近生產環境。

從"問題發現"到"問題預防" AI將在開發過程中實時分析接口兼容性，預測潛在問題，在代碼提交前就給出修改建議。

從"經驗依賴"到"智能沉淀" AI將學習團隊的最佳實踐，形成標準化的開發模式和代碼模板，讓新成員也能快速產出高質量代碼。

通過持續優化AI輔助工具鏈，我們有望實現從"人適應流程"到"流程適應人"的轉變，讓整個開發過程從傳統的手工模式轉變為AI驅動的智能化開發模式。