Navan 最近一次遷移涵蓋 8 個應用程式與 15 個函式庫，約一週即完成，過程中開發工作完全不必暫停。兩年前，一次規模相當的遷移耗時超過一個月，還曾因一次錯誤的合併，導致 master 分支被鎖住整整一天。關鍵差異就在於 Cursor 的雲端代理：Navan 只需規劃一次遷移，就能在自行託管的機器上，對 8 個應用程式並行執行，不必再由單一工程師獨自一步步完成。

#涵蓋 8 個應用程式的遷移，從一個月縮短為一週

兩年前，將 Navan 的程式碼庫遷移至新版 Spring，花了資深軟體技術專家 Rahul Popuri 超過一個月的時間。在那段期間，不完整的推送與回退曾讓 master 分支被鎖定長達一天。而鎖定解除後，影響並未就此結束：好幾天後，其他工程師仍在努力追趕進度、合入各自的變更。但更大的成本其實不在於鎖定本身，而在於一名工程師整整一個月的時間都耗在遷移上，無法用來發布功能或修正錯誤。

Navan 最近一次遷移至 Spring Boot 4，只花了大約一週就完成，對進行中的開發工作影響也更小。透過 Cursor，Rahul 事先規劃好升級作業，再將每個元件委派給在 Navan 自行託管機器上執行的雲端代理，讓 8 個應用程式與 15 個函式庫同時遷移，而不必逐一處理。這些代理使用 Navan 的內部工具體系，並在同一批機器上啟動瀏覽器，逐一點擊各項流程，以驗證自己所做的變更。

Rahul 不只是盯著單一任務執行，而是同時監控多個代理升級不同的應用程式。他表示，這種規模的並行作業，就算在短短幾個月前都還無法實現。

#雲端代理扛起實際工作負載

Rahul 幾乎把所有工作都移到了 Cursor 的雲端代理上。GitHub 相關工作在 Cursor 管理的基礎架構上執行；用於 Snowflake 和 Slack 的內部 MCPs 則在 Navan 自己的自行託管機器上執行，代理還能在這些機器上啟動瀏覽器，驗證自己所做的變更。自動化、技能與記憶都建構在這套設定之上，因此評估迴圈與遷移工作能以非同步方式持續進行，不需要有人在旁監控。

此後，這套模式早已不限於單一工程師：Navan 現在約有 200 人積極使用 Cursor 的雲端代理，人數自 2026 年 4 月以來成長了 10 倍。

在採用 Cursor 之前，Navan 的工程師已經圍繞先前的程式開發代理建置了一套實際可用的基礎架構，但它需要有人全程守在一台桌面電腦前，讓工作階段保持開啟。如此一來，Navan 需要的並行、非同步工作就無從實現。

#產品團隊也能獲得同樣的效益

在產品端，負責費用與計費業務的資深軟體技術專家 Elton Yang，只需一段簡單的說明，就能為費用與計費工作流程建立新的代理。Cursor 會遵循團隊現有的設計模式，並自行撰寫代理的提示詞，因此當天就能開始測試，不必先花上好幾個小時手動撰寫初始提示詞。

這項轉變也讓小型團隊能承擔更多工作。在許多工程師離開 Navan 專責的 AI 代理團隊後，一位工程師便接手了過去需要 2 到 3 位工程師、橫跨多個衝刺週期才能完成的功能開發。最具代表性的例子之一是手動銀行帳戶連結：這位工程師將一個 Angular 表單改以 React 重建，並開發了與之串接的後端，在任務需要時從純後端工作跨足全端開發。這條由個人負責的工作線得以持續專注於新功能，而不至於淪為單純的維護工作。

Cursor 也改變了代理同事職務的方式。當同事休假、Elton 必須接手兩個他不太熟悉的程式碼庫時，Cursor 替他包辦了調查工作：在 Elton 開啟任何一個檔案之前，就已擷取日誌與資料庫紀錄，並把議題的來龍去脈整理清楚。

光是這兩個程式碼庫，就省下了大約兩天的上手時間，也免去了從零開始摸索的壓力。

審查仍由人來把關。Elton 將代理視為結對程式設計的夥伴，而不是無所不知的程式碼神諭：他會在代理執行時觀察其推理過程，一發現錯誤假設就立即修正。程式碼產生後，會與其他程式碼一樣經過人工與 AI 審查、測試及暫存流程，複雜的變更則會先在暫存環境中驗證，再部署到正式環境。代理負責規劃與執行工作，但關鍵判斷由工程師做出，最終的合併也由工程師負責。

---

如果你正在進行過去需要整個團隊投入、還得鎖定程式碼庫才能完成的遷移或並行工作線，歡迎與我們聯絡，開始試用 Cursor。