Amplitude 使用 Cursor 交付 3 倍正式環境程式碼
Amplitude 使用 Cursor 打造自主開發流程，讓軟體從構想到正式環境只需極少的開發者介入。
Amplitude 的工程團隊希望打造一套完全自主的開發流程，讓軟體從構想到正式環境只需極少的開發者介入。借助 Cursor，Amplitude 現在已建立起一套系統，能從整個軟體生命週期擷取上下文——從客戶意見回饋、可觀測性工具到程式碼審查——再交由代理執行。
現在，當客戶在 Slack 回報錯誤或提出功能請求時，雲端代理就會自動啟動，展開調查、建立工單並撰寫修正程式碼。Cursor Automations 會持續在背景中執行，遷移既有程式碼，並為每個新增或更新的 PR 判定風險等級。Bugbot 則作為第一道審查防線，自動合併低風險變更，並將高風險 PR 送交給合適的審查者。
大多數 AI 程式設計工具只會產生更多程式碼。Cursor 帶來的是更多真正有用、可在正式環境運行的軟體。能夠執行代理，讓它們有效平行化工作、測試自己的變更，並將一項功能從構想帶到正式環境，這就是差別所在。
僅限本機的代理會限制並行與自主性
Amplitude 在導入程式設計代理的初期，就遇到了 Adam Lohner (一位資深軟體工程師) 所說的工程生產力假性平台期。
真正能提升開發速度的，是代理產出真正有用、可投入正式環境的軟體，而不只是大量程式碼。要做到前者，我們需要更強的代理並行能力與自主性，但受限於本地開發者工作站的代理做不到這一點。
本機代理會競爭同一組有限資源，很快就會產生衝突。即使同時執行兩到三個代理，也可能導致效能下降。Amplitude 的程式碼庫規模大到即使是配備大容量 RAM 的高階硬體，本地開發機器也會碰到記憶體限制。
本機代理也無法像工程師一樣存取完整的開發環境。少了這些，代理就無法自行測試或驗證自己的工作成果。開發者仍然必須設定環境、執行端對端測試，並在任何變更能夠上線前手動驗證。
雲端突破了代理的本機限制天花板
為了提升平行執行能力與自主性，Amplitude 採用了 Cursor 的 雲端代理。其中有幾項能力特別突出：
- **可大規模平行執行：**雲端代理可在彼此隔離、可彈性擴充的 VM 中執行，消除了限制本機平行執行的資源瓶頸。
- **完整開發環境：**雲端代理可像工程師一樣測試、驗證並反覆改進成果，且能存取完整的開發環境。
- **長時間執行：**Amplitude 正將更深入、更具挑戰性的任務交給雲端代理端到端處理，而不再只是短暫的同步任務。
- **常駐型代理：**Cursor Automations 讓 Amplitude 能設定雲端代理，根據觸發條件或定期排程執行，而非仰賴手動下提示詞。
我們在 Cursor 中同時執行許多雲端代理，每個代理都能完整存取我們的工具堆疊。能夠快速啟動不受本機資源限制、也不需要持續盯場管理的代理，帶來了躍進式的改變。
Amplitude 的工程師現在會依工作類型，在雲端代理與本機代理之間切換。新點子通常從雲端開始，因為 Cursor 的機制讓代理能長時間獨立運作。許多工程師會直接從正在討論功能構想的 Slack 討論串中啟動 Cursor。
當開發人員準備好專注於更可控的反覆改進，或需要更貼近細節時，就會把代理拉回本機。Cursor 則成為串接雲端與本機的統一工作空間。
Cursor 提供了最好的介面，讓你協調所有不同的平行代理。你可以維持高層次視角，也能在需要時深入查看差異和檔案等細節。
自從採用雲端代理後，Amplitude 每週在正式環境的提交數增加了 3 倍。以提交量來看，Cursor 已成為 Amplitude 程式碼庫前三大貢獻者之一，每週會在無需任何提示詞或開發人員介入的情況下啟動超過 1,000 次代理執行。
雲端是建構軟體的地方，本機則是我們測試與反覆改進的地方。Cursor 對兩者之間無縫交接的支援，是推動 Amplitude 產品開發速度的關鍵。
從 Slack 到工單再到 PR
Amplitude 設有專門的 Slack 頻道，讓前線團隊回報客戶的錯誤回報與功能請求。在使用 Cursor 之前，他們有一位專責團隊成員負責監控這些頻道、分流議題、追蹤工單，並從待辦清單中指派工作。
接著，Pauly 建立了一個 Cursor Automation，將整個工作流程交由代理接手。當 Slack 中出現新訊息時，雲端代理會檢查 Linear，確認這個議題是否已有對應工單。若已有工單，代理就會加入新的客戶上下文；若沒有，代理會探索程式碼庫、建立新工單，並開啟一個已實作解決方案的 PR。
Cursor Automations 正在幫助我們消除客戶與工程師之間的落差。我們能更快回應客戶需求，並提供更好的解決方案。
你可以從這個範本開始打造能將 Slack 回報轉成 PR 的自動化流程。
自動化既有程式碼重構
Amplitude 的前端程式碼庫多年來累積了各種彼此競爭的模式，包括既有的 CSS 元件、過時的 React 版面配置，以及不一致的樣式慣例。
我們有太多彼此競爭的既有模式，讓代理很難判斷接下來該怎麼做才對。這就是典型的垃圾進，垃圾出。
為了解決這個問題，Lohner 建立了一組以 cron 為基礎、每小時執行一次的 Cursor Automations，逐步處理既有系統的遷移。其中一個自動化流程會掃描 CSS 檔案，找出可直接替換成 Tailwind 類別的樣式，完成替換後刪除舊檔、建立 PR，並發送 Slack 通知。另一個則會處理 Amplitude 超過 20,000 個既有 React 版面配置元件實例，將它們替換為原生的 Tailwind 對應寫法。
將這些遷移工作以自動化流程的形式在雲端執行，代表它們會持續在背景中進行，不會排擠其他工作，也不會占用開發人員的時間。
由 Agent 主導的程式碼審查
另一個拖慢 Amplitude 開發速度的瓶頸，是人工進行的程式碼審查。Amplitude 希望採用以代理為優先的審查流程，提升產品可靠性，並減少開發者在工作中被打斷的情況。
Amplitude 導入 Bugbot，作為專用的代理式審查層。隨著開發者發現，面對 Amplitude 程式碼庫的規模與複雜度，Bugbot 能抓出人工審查者遺漏的議題，採用率也自然而然地提升。
Bugbot 經常能找出非常棘手的錯誤，並為這些議題提出紮實的修正方案。
Lohner 也打造了一個 Cursor Automation，用來評估每個 PR 的風險影響等級。低風險變更可以直接進入合併流程，由 Bugbot 在無需開發者介入的情況下進行審查並自動修正議題。涉及較複雜邏輯變更的高風險 PR，則會自動分派給合適的工程師。大約 60–70% 的低風險 PR 都能在不需要開發者額外處理的情況下完成合併。您可以從這個範本開始打造自動化流程，將 Slack 回報轉成 PR。
Bugbot 經常抓到真實、足以威脅正式環境的錯誤；這樣的實績讓它成為我們程式碼審查流程中的關鍵一環。
接下來，Amplitude 正專注於將自動化推進到開發生命週期的後半段：CI/CD 流程、建置驗證與部署。目標是讓代理能在無需開發者介入的情況下，將軟體從已審查的 PR 一路推進到正式環境。
如果您有興趣使用 Cursor 打造自主式開發流程，請聯絡我們的團隊開始試用 Cursor。
