Cursor 改 API 總漏前端？CodeGraph 實測解決方案（Vue + Spring Boot）

用 Cursor 或 Claude Code 改 API，後端合併了、前端忘了改——不是你一個人。本文只回答三件事：為什麼漏、真實案例怎麼抓、用 CodeGraph 怎麼解決。技術棧是 Vue 3 + Spring Boot 分離倉；工具是 GitHub 熱門的 CodeGraph（經 MCP 接進 Agent）。

為什麼 Cursor 總漏改前端

漏改很少是「模型不會寫程式」，而是 AI Coding 看不見跨目錄、跨語言的引用。在 Vue + Spring Boot 分離倉裡，常見就三條：

1. Context Window：視窗裡只有當前檔案

Cursor 的 @ 檔案、Claude Code 的 Read 都有上限。Agent 盯著 OrderController.java，不知道三百行外的 frontend/src/api/order.ts 也在用同一個 DTO 欄位。換對話、換分支後，「改到哪了」更容易丟（和 Cursor 跨週失憶 疊加時更糟）。

2. Grep：找得到字串，看不懂呼叫關係

預設探索靠 grep。搜 amount 會撈出日誌、測試、廢棄常數，卻分不清誰呼叫 OrderService.createOrder、哪個 @PostMapping 對應哪個 handler。token 花在「找入口」，不是「改全影響面」。

3. 沒有 Impact Analysis：改一處，漏一片

人類改 API 會先問：改這個欄位，還有誰在用？ 沒有結構化 impact 時，Agent 往往「Java 改完收工」，TypeScript、Pinia、單測留到下一輪——你以為一輪對話搞定，其實是兩輪債務。

要補的不是更大的模型，而是給 Agent 一條能查呼叫圖、依賴邊、路由入口的通道。下面用真實訂單 API 說明。

真實案例：OrderDTO.amount

需求：POST /api/orders 的請求體裡，amount 從 number 改為 string（例如支援大額或格式化字串）。倉庫是典型分離結構：backend/（Controller → Service → OrderDTO），frontend/（api/order.ts → Pinia → 下單頁）。

無 CodeGraph 時，Cursor / Claude Code 常漏什麼

我只給業務描述、不 @ 檔案，讓 Agent 自己探索。常見結果：

• ✅ 改了 OrderDTO.java、OrderService
• ❌ 漏 frontend/src/api/order.ts 裡 createOrder 的 payload 型別
• ❌ 漏 useOrderStore 裡對 amount 的對應
• ❌ 漏下單頁 v-model 仍按數字驗證

本機 mvn compile 可能仍過（Java 側已改），pnpm build 有時也過（TS 沒嚴格到欄位級），合併後聯調或上線才爆——這就是「改 API 漏前端」。

對照：impact 列出的波及面（節選）

codegraph_impact
  symbol: "OrderDTO.amount"

→ OrderService.createOrder
→ OrderController.create
→ frontend/src/api/order.ts :: createOrder
→ stores/order.ts :: useOrderStore

最後一行正是以前 grep 最容易漏的 Pinia。有了清單，再在 Cursor 或 Claude Code 裡按列表改，漏改率明顯下降。

CodeGraph 怎麼發現問題

CodeGraph 在本機用 Tree-sitter 建索引（Java / TS / Vue script），呼叫邊寫入 .codegraph/，經 MCP 暴露 codegraph_* 工具。資料預設不出本機，適合內網倉。

改這條訂單 API 時，我固定順序：

1. codegraph_context — 按任務打包 Controller、DTO、前端 API 入口（不必先 @ 路徑）
2. codegraph_trace — Spring 側：OrderController.create → OrderMapper.insert
3. codegraph_impact — 從 OrderDTO.amount 向外擴，拉齊 Java + Vue + store
4. codegraph_explore — 只展開相關方法，避免把八百行 Service 整檔塞進上下文

HTTP 路徑與前端 axios 字串若沒有 symbol 邊，仍要靠 impact 從 DTO 往外追——正是本案例裡「超出預期」的一步。更完整的工具說明與和 RAG 的對比，見 程式碼知識圖譜選型；安裝細節見下文。

團隊側建議在 AGENTS.md 寫死：改 DTO 必先 codegraph_impact，並列出 frontend/src/api 與 Pinia——比單句「別忘了改前端」穩。

安裝（5 分鐘）

在含 frontend/ + backend/ 的倉庫根目錄（macOS）：

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# 或：npx @colbymchenry/codegraph

codegraph install --target=cursor --yes   # Claude Code 選對應 target
cd /path/to/your-repo
codegraph init -i
codegraph status

首次全量索引視倉大小約十到二十分鐘；排除 node_modules、target、dist。儲存檔案後約 2 秒防抖增量同步；MCP 回傳 ⚠️ Pending sync 時讓 Agent 直接 Read 原始碼。

結果對照

官方 Java 基準（OkHttp ~645 檔案）中位從 10 次降到 3 次（2026-05-29）；Vue + Spring 分離倉我的體感接近「少一半以上探索」。圖譜不替代測試：合併前仍跑 mvn test + pnpm test:unit。

大型倉庫索引的現實問題

首次 codegraph index 時，CPU 占用高、SQLite 寫入頻繁、風扇狂轉——若同時開 IDEA 編譯 Spring、pnpm build Vue，Cursor 裡連 MCP 查詢都會卡。

很多團隊會把「克隆 + 全量索引 + 定時重建」放到專用機器：Mac mini、CI 節點或 Cloud Mac；本地筆電只開 Cursor / Claude Code 做編碼與 MCP 查詢。我這邊索引跑在按天租的 Macstripe M4 上，和本機建置錯峰；worktree 與 CI 策略可參考 企業 Mac CI FAQ。

「Cloud Mac + CodeGraph 部署」值得單獨寫一篇；本文只點到：索引與互動分離，體驗會穩很多。

總結

Cursor 改 API 總漏前端，根因通常是：上下文有限 + grep 不懂呼叫 + 沒有 impact。在 Vue + Spring Boot 倉裡，用 CodeGraph MCP 先 context → trace → impact，能把 DTO 改動的前後端清單一次拉齊，工具呼叫從十幾輪探索降到幾輪結構化查詢。

固定動作：init 索引 → impact（改 DTO 前）→ 按清單改 → 測試。概念科普、Claude Code 讀大倉、Cloud Mac 部署可以拆成系列文——下面延伸閱讀。

延伸閱讀

• 程式碼知識圖譜：大型倉庫裡 AI 該用哪種圖？
• Cursor 為什麼總失憶？長上下文救不了跨週協作
• OpenClaw 遠端 Mac：長任務 Agent 與索引同機