Spotify 後台程式設計智能體落地實作（已成功合併超過1,500 個AI 產生的PR） 核心問題與解決方案 @Spotify 的Fleet Management 系統雖然在自動化簡單任務方面表現出色，但複雜程式碼變更一直是個挑戰。傳統方法需要操作抽象語法樹或正規表示式，需要高度專業知識。例如，他們的Maven 依賴更新腳本就超過20,000 行程式碼。 團隊的核心思路是：以自然語言定義的智慧體取代確定性遷移腳本，同時保留Fleet Management 的所有基礎設施－目標倉庫選擇、PR 開啟、審查和合併流程完全不變。 技術演進路徑第一階段：開源工具探索團隊嘗試了Goose 和Aider 等開源工具，但在大規模遷移場景下難以可靠地產生可合併的PR。 第二階段：自研循環他們建構了基於LLM API 的"智能體循環"，包含用戶提供提示、智能體編輯文件並整合構建反饋、測試通過或達到限制後完成三個步驟。這適合小改動，但複雜多檔案變更時經常耗盡回合數或遺失上下文。 第三階段：Claude Code Claude Code 成為表現最佳的智能體，已應用於約50 次遷移和大部分生產PR。它支援更自然的任務導向提示，可管理待辦清單和高效派生子智能體。 提示工程的關鍵原則 1. 針對智能體特性調整- 自研智能體適合嚴格的逐步指令，Claude Code 則更適合描述最終狀態並留出自主空間 2. 明確前置條件- 智能體往往過於急切地執行，需明確說明何時不採取行動 3. 使用具體範例- 少量具體程式碼範例能極大影響結果 4. 定義可驗證的目標- 最好以測試形式呈現，避免模糊指令 5. 一次一個變更- 組合多個變更容易耗盡上下文或產生部分結果 6. 向智能體徵求回饋- 會話結束後，智能體能指出提示中的不足 工具與情境管理 Spotify 採用保守的工具策略來維持可預測性。他們的智能體只能存取: · 驗證工具：執行格式化、靜態檢查和測試· 受限的Git 工具：標準化Git 操作，禁止推送或更改遠端倉庫· 白名單Bash 指令：如ripgrep 他們沒有暴露程式碼搜尋或文件工具，而是要求使用者預先將相關上下文濃縮到提示中。這種設計理念是：更多工具意味著更多不可預測維度。 實際應用成果系統已處理複雜遷移任務，包括: · 語言現代化(如Java 值型別遷移到records) · 具有破壞性變更的升級· UI 元件遷移· 設定檔更新這些遷移節省了60-90% 的時間。更重要的是，2024 年中以來，Spotify 約一半的PR 都由此系統自動化產生。 超越遷移的應用團隊透過MCP 協定將智慧體整合到Slack 和GitHub Enterprise。工作流程是：互動式智能體先收集任務訊息，生成提示後交給編碼智能體執行並建立PR。這讓工程師能從Slack 執行緒擷取架構決策記錄，或讓產品經理無需在本地建置即可提出簡單變更。 待解決的挑戰 Spotify 團隊坦誠指出目前限制: · 性能與可預測性問題· 缺乏結構化的提示/模型評估方法· 難以驗證PR 是否真正解決原始問題· 仍主要依靠直覺和試錯來演進提示 Part1：https://t.co/M5pJCeL5Ds Part2：
