Coinbase 如何讓 1,000 多名工程師真正用上 AI

AI 工具的採用率高，不代表它已經融入工作。Coinbase 工程資深總監 Chintan Turakhia 分享，如何讓超過 1,000 名工程師從試用工具，走到把 AI 用在日常開發和使用者回饋上。

Coinbase 當時正把錢包產品轉向使用加密技術的社交消費產品，並希望在六到九個月內完成大幅改造。團隊面對的挑戰不只是工程量，而是如何在緊迫的時程裡減少開發摩擦，並盡快把產品交到使用者手上。

公司先前試過 GitHub Copilot 等工具，工程師會安裝、試用，甚至做完簡單的入門操作，之後卻不一定繼續用。Turakhia 的問題不是如何提高安裝數，而是如何讓工具變成持續使用的工作方式。

主管先親自試出有用的地方

早期的模型能力有限，工程師試過一次覺得不好用，就可能把整類工具都擱在一旁。Turakhia 沒有先要求團隊改變，而是自己每天使用 Cursor，從修 bug、補單元測試和處理 linting 等瑣事開始，找出工具在哪些情境能真正省下時間。

他也把有效做法整理成 Cursor Rules，讓團隊能直接沿用，再依各自的工作習慣調整。當工程師遇到新工具不熟悉時，主管親自試過後，就能拿出具體例子說明哪種任務適合、怎麼下指令、結果要如何檢查。

這種示範比單方面要求大家採用更有說服力。團隊不需要因為主管宣布新政策就改變工作，而是先看見工具能替自己拿掉哪些重複工作。

用小任務建立團隊信心

在團隊頻道裡，工程師會分享用 Cursor 完成的工作，例如一次補上二十個單元測試。接著，團隊舉辦名為 Cursor speedrun 的短時間練習，讓每個人挑一個小改動，直接嘗試並提交 PR。

Turakhia 在訪談中回憶，一次約有 100 人加入的練習，在 15 分鐘內提交了約 70 個 PR。之後的全公司活動約有 800 名工程師參與，30 分鐘內提交了三、四百個 PR。大量提交也讓 GitHub 暫時承受不住，反而幫團隊提早發現基礎設施需要改善。

PR 數量本身不能證明程式碼品質或產品價值。這些 speedrun 的作用，是讓工程師親手試出工作方法，並快速看見哪些原本要排進流程的小修正可以立即完成。

衡量需求到使用者的交付時間

Turakhia 不把 AI 產生的程式碼行數當成主要成效指標。他更在意一項需求從建立 ticket，到改動真正交到使用者手上需要多久。這段週期包含需求判斷、實作、PR 審查和發布，比單看 AI 寫了多少程式碼更接近產品交付的結果。

他表示，團隊的 PR 審查週期曾約為 150 小時，後來降到約 15 小時；集中衝刺期間，同一段時間內的 PR 數量曾達平常的三到四倍以上。這些數字是受訪者在訪談中的說法，並非獨立查證的公司指標，也不能直接推論其他團隊能得到相同結果。

訪談中還提到一次與使用者通話的經驗：使用者提出修改建議後，Turakhia 在通話期間就建立並送出 PR，使用者在通話結束前重新載入產品，已經能看到修正。這個例子說明，當實作與交付的摩擦減少，團隊可以更快回應真實使用情境。

用使用資料找出不同的採用路徑

工程主管常需要回答：團隊裡哪些人已經熟練使用 AI？哪些人還沒找到用法？熟練者做了什麼，其他人可以怎麼開始？訪談中，Turakhia 示範把 Cursor 管理後台匯出的 CSV 交給 AI 分析，再產生使用者分群、簡單儀表板和不同群組的練習建議。

示範把使用方式分成偏好 Agent、偏好 Tab 補全、兩者都用，以及仍在觀望等類型。這能讓主管從「要求大家多用 AI」轉向提供更具體的下一步，例如先嘗試 Agent 模式，或把 Tab 補全用在一項熟悉的任務上。

這段示範的部分資料是樣本資料，使用者名稱也是假名。畫面上的比例和人數不能當成 Coinbase 工程師的實際採用統計。示範呈現的是分析流程：將現有使用資料整理成團隊可以討論和採取行動的資訊。

把使用者回饋接到工程工作流

傳統的測試活動通常要先記下現場回饋，再整理文件、建立 ticket、討論優先順序，最後排進 sprint。這段等待時間可能讓使用者失去耐心。

Coinbase 團隊舉辦 feedback cafe，邀請內外部使用者實際操作產品，並用工具錄下語音回饋。AI 會先把口頭描述整理成問題摘要，再建立 Linear ticket；接著，內部工具 Cloudbot 可以根據 ticket 啟動 PR 建立流程。訪談示範了從語音回饋到 ticket，再到 PR 開始處理的過程。

Cloudbot 是公司內部打造的工具。Turakhia 說，當時因安全需求，團隊無法直接使用某些背景代理服務，因此選擇在既有的 Slack 和 Linear 工作流程上接入 AI。Linear 保存任務脈絡，agent 再依需要使用 Datadog、Sentry、Amplitude、內部 Snowflake 等工具和多個程式庫中的資訊。PR 建立後，工具也能回傳 Cursor 分支連結；一次性測試建置完成後，還能提供 QR code 讓工程師直接試用修正。

他提出「superb builder」這個角色，主要任務是打造能幫助更多人成為 superb builder 的工具。這個角色不是單純宣傳 AI，而是找出團隊裡重複出現的工作，把公司脈絡和常用工具接起來。把入口放在 Slack 和 Linear，也降低了切換到新工具的成本，並讓團隊能看見彼此怎麼用。

AI 也能處理工程以外的日常任務

訪談後段，Turakhia 示範了兩個個人用途：把學校寄來的活動通知拍照交給 AI，整理成行事曆邀請；再把品酒筆記交給 AI，歸納個人偏好，並根據餐廳酒單照片推薦可能喜歡的酒款和價格選擇。這些是個人使用示範，不是 Coinbase 工程團隊的採用數據。

管理者把時間放回產品和程式碼

訪談最後，Turakhia 說自己的行事曆幾乎空了，投入程式碼的時間反而變多：修 bug、嘗試技術方案、直接回應產品問題。他也強調，AI 並沒有取代工程師，而是讓他能減少協調成本，親自推進更多工作。

從訪談中的做法可以歸納出一個管理思路：先由領導者親自理解工具，再從團隊真正在意的工作開始；讓成功做法可以被看見和重用；觀察不同人的使用方式；最後把 AI 接進現有的回饋、追蹤和交付流程。這是對訪談案例的整理，不代表單靠工具就能保證更高品質或更快交付。

來源與說明

本文根據 How I AI 對 Coinbase 工程資深總監 Chintan Turakhia 的訪談翻譯、整理與改寫，刪除了贊助口播和重複對談，並非逐句直譯。文中數字依受訪者說法轉述；Cursor 使用分析的示範資料包含樣本與假名。