千人工程團隊如何真正用起 AI：Coinbase 的親身示範
「It's about Adapt or Die」
一開頭 Coinbase 工程主管 Chintan Turakhia 就說了這句。
他花了將近一年，讓超過一千名工程師真正改變工作方式。不是靠命令，不是靠 KPI，而是靠一個核心信念：
你不能只告訴工程師「去用 AI」，你必須讓他們親眼看到它怎麼改變你自己的工作。
我看了許多案例，許多公司的管理階層一開始就想要設定導入 AI 的 KPI，而不是跳下去示範，直接親身展現魔法。
我一直秉持的是先施放魔法才是最有用的方式，這個火會慢慢開始向外燒起來。
不過我最近也體會到由上到下的發布強制使用 AI 的效果，所以在適當的時機雙管齊下，會是更有效果的。
Coinbase 整個採用的過程值得參考，因為我也是頗有同感。
失敗的第一次，才是真正的開始
2024 年底，Cursor 剛推出的時候，Chintan 的團隊試用了，覺得還好。模型不夠強，寫個單元測試都磕磕碰碰的，工程師用幾次就放棄了。
這不是第一次了。在那之前，公司推過 GitHub Copilot。採用率有一波漲幅，打開、裝好、Hello World，然後沉寂。
我最在意的就是，怎麼讓這件事真的紮根下來。因為這裡面有什麼東西，我就是感覺到了。
很多工程組織在這個階段就放棄了。但 Chintan 的邏輯不一樣：LLM 會持續進步，現在建立習慣的成本幾乎是零，唯一的浪費只是一點點時間。就像去健身房，你得先把訓練的習慣建起來，等設備升級了你才真的跟得上。
從 2025 年一月到三月，他每天每小時都泡在 Cursor 裡，不是為了研究，而是為了找到可以展示給工程師看的具體用法。
「我下令你們用 AI」是最爛的辦法
一個工程師試了覺得不好用，這件事的殺傷半徑不只是那一個人。周圍的人看到他的反應，整個團隊的採用意願就跌下去了。
所以 Chintan 的策略是：不從上往下頒布，而是從自己開始示範。
他回去寫程式。不是象徵性地，是真的重新進入 codebase，用 AI 處理面試記錄、修 bug、自動建立 PR。最讓他有感的那一刻，是他意識到自己完全不需要再記 git 指令了，對著 cursor 說一句「幫我建一個 draft PR」，事情就完成了。
當他把這些具體用法帶回去給工程師看，說的不是「AI 很厲害你們要用」，而是「我今天早上用它解決了這個問題，你要不要試試看」，反應完全不同。
我想要補充的是，今年幾乎不用擔心這件事了，只要你選對 model。
70 個 PR、30 分鐘、還把 GitHub 搞掛了
等到有足夠多的工程師開始「感覺到了」，Chintan 發動了一場 Speedrun。
全團隊 All Hands 上線，每個人的任務只有一個：挑一件最簡單的事，不管是改文案、修小 bug 還是任何東西，在 30 分鐘內用 AI 輔助把 PR 推上去。
15 分鐘內，100 人加入。最終他們在 30 分鐘內推了將近 70 個 PR。然後他們把 GitHub 搞掛了。
這是在壓力測試。我們應該要設計成能打破規則的樣子。
後來在全公司層級重跑一次，800 名工程師上線，30 分鐘內推了 300 到 400 個 PR，GitHub 又掛了一次。
這個儀式的意義不只是「讓大家用 AI」。它打破了一個更深的心理框架：大家意識到，原來可以直接動手，不需要等 PM 排優先順序、不需要等設計師確認按鈕顏色。
「AI 正在打破規則，如果我們不去適應，就會被淘汰。」
你真正要測量的，不是「AI 使用率」
很多組織導入 AI 之後，開始追蹤「AI 生成的程式碼行數」。Chintan 認為這個指標很容易誤導人。
他真正在追蹤的是：從用戶反饋到功能落地的整個時間。
這個週期包括：看到反饋→建票→PR 撰寫→PR 審查→合併→OTA 更新→用戶看到新版本。每一個環節他都在想辦法壓縮。
PR 審查時間從平均 150 小時壓到 15 小時，大約縮短了 10 倍。
更直接的例子是他在一次用戶通話中，對方反映了一個問題，他當場在 30 分鐘的通話裡把 PR 推上去，通話結束前跟對方說：「你現在重新整理看看，修好了。」
這點我上週才跟同事討論出這個做法，能不能夠知道從開票到上線這個流程，裡面的各個環節到底快了多少?
光是這樣就能夠證明 AI 加速了多少。但這樣就夠了嗎?
不夠，現在工程師使用 AI 的情況是這樣的，大家都無法自拔，開始往更深、更細的地方走，開始補上測試，做更多更完整功能。
不是像以前那樣，單純開發好提出來的需求而已。 我們還要衡量更多事情。 但還要再衡量什麼，再過一陣子我會有明確答案。
但從測試，更完整的錯誤處理，絕對是短期感受不到，但長期感受到複利的一件事。 不要只看表面。
把 Slack 變成 AI 的入口，而不是又一個工具
Coinbase 工程團隊自己做了一個內部的 bot 叫做 Claude Bot，整合進 Slack。
為什麼不直接用市面上的 AI 工具？因為他有個底層認知：Slack 是公司內部讓事情病毒式傳播的地方。如果你把 AI 的魔法藏在另一個工具裡，只有一小群人看得到，它就不會擴散。
當 Claude Bot 在公開頻道裡工作，其他人看到有人說一句話、一個 PR 自動生成、三分鐘後出現 QR Code 可以直接掃描測試新版本，那種「幹，原來可以這樣」的感受會自己傳染出去。
他的目標是讓 AI 承擔那個「回應成本」，讓人回到真正需要人判斷的事情上。
管理者的角色，正在被重新定義
訪談最後，主持人問他和兩年前相比，時間花法有什麼不同。他說：
我的行事曆幾乎是空的。因為那些協調 overhead 消失了，不需要再問『這件事優先嗎？』你就直接做了。
他寫的程式碼比以前更多了。
他設了一個非正式標準：如果他的程式碼貢獻比團隊成員還多，代表大家在 AI 使用上需要更多支持。
他還做了一件很有意思的事：從 Cursor 後台下載使用數據，用 AI 分析整個工程師群體的使用模式，找出「超級用戶」和「還沒上手的人」，然後為每個群體產生針對性的建議。
- Agent 重度用戶：善用 agent mode 但可以更大膽擴展任務邊界
- Tab 完成用戶：習慣小修改，需要練習把控制權交出去
輕度用戶：通常卡在「第一次」，最需要的是一個具體的入門任務
他用 AI 做這個分析、用 AI 寫 Slack 貼文推給全團隊，整個流程從原始 CSV 到「準備好發布的訊息」大概花了不到一小時。
以前這種分析要拉工程師花幾天，或者根本不做。
有一件事，比任何工具都重要
Chintan 在訪談裡說了一件事，我覺得是整集最值得帶走的東西：
在做這種組織變革的時候，你需要一個在領導層有著超強信念的人，而且這個人必須親手在做這件事。因為只有這樣，當工程師說『這個在某個地方不管用』的時候，你才能說：『我知道在那裡不管用，但我試過 A、B、C，它在這三件事上管用。』
不能只有哲學。不能只說「未來某天我們會想清楚」。你必須真的回去動手，然後帶著具體的東西回來。
這不只是 AI 導入的方法，這是任何組織變革都有效的核心邏輯：領頭的人得先跳進去，不是站在岸邊說水很好喝。
我覺得他說的很對，我時常在面對的就是對 AI 的質疑，但我整天泡在 AI 裡面就是要在當有人質疑的時候，我要如何有信心的回應說「你得怎麼樣做才對的」
這篇學到什麼?
- Slack 我也要來接一下
- 導入 AI 後管理者的協調時間也會大幅降低，因為一下子就幹完，根本不必協調先後順序、人力分配，考慮的時間可能都是浪費。