如果要说哪家公司在 AI 编程上足够激进，Coinbase 绝对首屈一指。
2025 年 8 月，Coinbase 发生了一件“强制上车”事件：公司给所有工程师配齐了 GitHub Copilot 和 Cursor 的企业授权，本是一次工具升级，却被其 CEO Brian Armstrong 直接变成了“忠诚度测试”。他要求工程师全员接入 AI 工具，但有人提醒他，全员采用不可能这么快，可能要几个月才能让一半工程师真正用起来。
Armstrong 听完直接“暴走”，表示一周之内必须全员完成 AI 工具 onboarding。到了周六，他真的拉了一个会议，点名那些没完成的人，当面问原因。有人是度假刚回来、理由充分；也有人说不出为什么，结果就是当场被开除，手段相当强硬。
一个月后，Armstrong 的激进又达到了新的程度：他在 X 上公开表示，Coinbase 目前约 40% 的日常代码已经由 AI 生成，而他的目标是在 30 天内把这个比例推到 50% 以上。
在工程侧，这个压力自然落到了工程总监 Chintan Turakhia 身上。他在最近一期播客里分享说，大规模部署 AI 对团队来说是“要么适应，要么灭亡”。但难点也摆在那儿——Coinbase 不是几十人的创业公司，而是一支超过一千名工程师的队伍，光让所有人都用起来就相当不容易了。
更别说还要把它落到一个正在重写的真实产品里，这事儿确实有点疯狂。
那么 Coinbase 到底是怎么让“全员上车”不止停留在口号，而是变成一套能跑、能量化、甚至能把 GitHub 冲崩的工程节奏？（当然，更值得追问的是：这种“冲到极限”的打法，究竟是可复制的组织能力，还是只适合少数公司、少数阶段的高压策略？它带来的速度红利，是否会在代码质量、协作负担、乃至工程文化上悄悄埋下新的成本——这也许才是 Coinbase 这场“疯狂实验”最值得我们未来持续跟进的部分。）我们整理了这期播客（Slack 相关的内部案例略有删节）。
主持人：Chintan，非常感谢你加入我们。今天我特别期待这期内容。我们花了很多时间讨论个人的 “vibe coder” 或非技术背景的人如何成为软件工程师，但仍然有很多人怀疑，大型、成熟、高度技术化、能力强大的工程组织是否能大规模部署 AI 并真正获得效果。质疑依然很多，但我认为你已经证明这是可能的，也希望你能给我们指条路。Chintan Turakhia： 我认为这不仅是可能的，而是“要么适应，要么灭亡”。这已经成为团队的一种巨大超级能力，我们从中获得了大量效率提升，而且是有方法可循的。我昨天刚看到一条推文，说某个团队在微软内部引入 Copilot，管理层希望“让曲线向右上角走”，但实际采用效果并不好。过去一年我一直在疯狂钻研这件事。它是可以做到的，真的可以。
主持人： 那具体怎么做到？你们的工程师规模是多少？
Chintan Turakhia： 一千多人。
所以这不是小团队试验，这是一个真正的大型团队，在做真实产品，工程能力非常强。
主持人：那么我们从哪里开始？文化层面？产品层面？工具层面？Chintan Turakhia： 很多事情其实是从去年这个时候开始的。我们当时对我负责的产品做了一些调整，其中一个重要决定是——从头重写整个产品。我们要把它从一个自托管钱包，转变为一个“刚好使用加密技术”的社交消费类应用。
我们用的是 React Native。但之前很多决策是围绕自托管钱包做的。要转型成消费级 App，就必须重新思考一切。
第二个挑战是，我们必须在 6 到 9 个月内完成。我们要正面竞争那些拥有上万名员工、领先我们十年的大型社交平台。我们真的想做一件大胆、全新、疯狂的事情——完全疯狂。
问题变成了：如何在这样疯狂的时间线下，把应用重写成市场上最优秀、真正消费级的产品？
团队非常强，真的很强。但在这次组织调整后，我们的团队规模反而变小了。于是我开始思考：如何加速？了解我的人都知道，我对效率极度执着。我认为这是提升团队速度的关键——但必须是在合理使用工具的前提下。
差不多那个时候，Cursor 发布了最初版本，大概是 2024 年 11 月左右。我们都试了。说实话，当时挺糟糕的。
不是我不喜欢 Cursor——我现在很喜欢 Cursor——但当时模型能力不行。模型真的不行。连写个单元测试都做不好。
作为工程师，一旦你尝试一个工具，发现“不怎么样”，就很容易彻底否定它。我们经历了一段“失望低谷”：AI 工具还没准备好，模型不够成熟，那怎么办？
其实在此之前的一年，公司也尝试引入 GitHub Copilot 等其它 AI 工具。我们看到一波采用高峰：大家打开工具、勾选启用，做个简单示例，但没坚持下来。我的核心问题始终是：如何让它真正“粘住”？因为我确信这里面有东西。我的心智模型是：基础大模型一定会持续进步。这就像去健身房，你必须不断训练、不断尝试。尝试的成本几乎为零，只是浪费一点时间。算力成本当时也不是什么问题，因为还处于早期阶段。
所以从 2025 年 1 月到 3 月或 4 月，我彻底改变了自己的心态。
我每天、每个小时都泡在 Cursor 里。我在想：如何让它真正发挥作用？这也让我重新开始写代码。这很好。它解锁了很多用例，比如在面试候选人时，我不想花大量时间写面试笔记，但我已经在脑子里完成了评估，于是用 AI 帮我做日常文书工作。与此同时，在编码层面，我主动去接 bug，尝试不同方式，看看会发生什么，学习各种技巧。关键是“示范给工程师看，而不是只告诉他们”。
一个领导者最糟糕的做法，就是宣布：“我命令你们必须用 AI。”拜托，没人会听你的。
主持人 Claire Bell：我太能共情了。我以前也管理过一个几百人的工程组织。早期版本的这些工具刚出来时，我心里就很笃定：它们一定会改变我们工作的方式——也许这是经验带来的直觉。但现实是，一年前的情况往往是这样的：某个工程师试了一下，效果不理想。问题不只是他自己不用了，而是其他人会跟着下结论：“我信他。如果他说不好用，那对我也没用。”
所以做这种组织级转型，真的需要一个在领导层信念足够强、而且亲自下场的人。你得能讲清楚：“对，那种场景确实不行，但这三个场景是有效的”；或者“我们试了 A、B、C，最后终于把它跑通了”。否则大家不会买账。
你不能停留在哲学层面，更不能只说“未来会变好”。你必须回到工具里，用行动把路径走出来。
而且对很多工程负责人来说，这还有个额外的好处：我们其实已经被推离编码太久了。我也知道自己得重新回去写代码，重新找回那种久违的快乐。
Chintan Turakhia： 没错。你必须“示范”，而不是“说教”。我就是这么做的。我很快意识到，这里面真的有东西。然后我们开始一个一个攻克具体用例。
想打动工程师，最好的方式是给他们工具，让他们不再做那些枯燥工作，让他们去构建真正喜欢的东西。我们从单元测试开始，从 linting 开始，把那些像纸割一样消耗精力的小事一点点剥离。那些事情会抽干构建者的灵魂，而团队真正想要的是更快地前进、构建更好的产品。
我开始更深入地用起 Cursor 的一些能力，比如 Cursor rules 这类规则配置。哪怕是最简单的场景，我记得我的一个“顿悟时刻”是：我在处理一个 bug 报告，按流程推进，然后突然我没有多想，就直接输入：“创建一个 draft PR。这是 ticket，这是我想要的 PR 描述。”就这么做了。那一刻我意识到——我再也不需要记住什么 get status、get rebase 之类的命令了。为什么还有人在手动做这些？我们到底在干嘛？
有趣的是，我还得花点时间说服团队：“兄弟们，直接打 create draft PR 就行，它会帮你搞定。”他们会说，“嗯，我有自己的工作流。”我就说，好，我理解你的工作流，你可以调整，你可以用 cursor rules，不冲突的。所以我们一点点磨下来，写了一堆规则（Cursor rules），这帮助特别大。然后我能感觉到：团队里已经有足够多的人开始觉得“这东西真的把一些事情打开了”。他们会在团队频道里发消息：“你们看我刚做了什么。”
我们甚至专门建了一个频道，名字就叫 cursor wins。大家在里面疯狂晒战绩： “我刚用它做完 20 个单元测试，然后去喝了杯咖啡。”“太爽了，我爱死了。”
当大家开始看到它在真实工作中生效，我们就到了一个拐点。我想：好，现在团队里已经有了一些信念，怎么把整个团队“加速推进”？我记得那次我飞去东海岸，刚落地，上了 Uber，就上线参加了一个全员会议。我们把它叫做“speedrun”——Cursor speedrun。我在 Uber 里用 Cursor 提交 PR。
Speedrun 的规则很简单：每个人随便挑一个最 trivial 的任务，哪怕是改个 copy、修个小 bug，马上提 PR。结果 15 分钟内，大概有 100 个人加入，我们提交了 70 个 PR。
我们甚至把 GitHub 弄崩了。但这反而很好，因为我们意识到基础设施需要升级。
主持人 Claire Bell：我想暂停一下，因为我们一直关注的是战术技巧。你用了几个我也用过的方法：一个拥有高度信念、亲自上阵的领导者；让大家获得工具访问权；聚焦在 toil（重复、枯燥的工作）上——你提到 linting、测试。我还想补充一个，比如设计债（design debt），那些前端工程师或设计师长期忍受却讨厌的部分。另外，你提到共享 Slack 频道。我们当时建的是 “wins and losses” 频道。大家不仅分享成功，也分享失败。当失败时，别人会说：“你可以试试 XYZ”或者“我有个 cursor rule 给你。”
但我想特别强调的是你说的 PR speedrun——设定一个倒计时，让大家一起打开工具，快速冲一波修复。那种从“季度规划、四个月以后再说”到“30 分钟内我们提交了 70 个 PR”的转变，对团队来说一定是极具颠覆性的。
Chintan Turakhia： 那些 PR 的合并成功率其实也不错。那一刻大家都会觉得：这真的可行。
每个人的眼睛都亮了。它很像一个宣言：“状态更新去死，构建万岁。”
主持人：还有一点我想强调：我觉得你们有一种特别的文化。但很多产品、工程、设计组织，经常会被“协作规则”绕死：“如果 PM 不说重要，我就不该做。”“设计没确认，我就不能决定按钮颜色。”而像这种 speedrun 的时刻，你基本上是在把规则全掀了：“猜猜怎么着？你其实就可以直接发版、直接 ship 代码。”你甚至可以两个方案都 ship（A/B 都上）——先不谈 AI。AI 可能只是让这件事成本更低、更容易，但单纯去做这件事本身，对速度的提升就非常强。我也觉得它还会提升质量：因为大家会用更激进的方式去承担责任，变得更“主人翁”。Chintan Turakhia： 你说得太对了。我很喜欢你刚刚那句话：这是一个应该“破坏规则”的时刻。因为 AI 正在替我们打破规则，如果我们不适应、不学会利用它，我们就完蛋了。而且这里的 “我们” 是集体意义上的：任何不适应的人，都会被甩在后面。 这些实践最终解锁的，是 协作成本（coordination overhead）的下降。
我最近特别着迷的一件事是：好，speedrun 很酷，我们做了很多事情，团队也开始不断出现胜利案例、更多人开始采用。然后你（Claire）也把采用情况分享给了 Brian（另一个同事 / 负责人）。接着我们又搞了一次 全公司 speedrun。那一次大概有 800 名工程师在线，30 分钟里我们提交了大约 300～400 个 PR。
我们又把 GitHub 搞崩了——这没关系，这很好。这就是压力测试。我们应该把系统设计成可以“撞破规则”，对吧？
但我最纠结、最着迷的问题是：怎么衡量这些东西的产出？这里存在一种张力：“AI 用得越多，是不是就等于在替代人？”
我完全不认同。AI 不是替代人，AI 是加速器（accelerant），因为永远都会有更多工作要做。所以我对团队、以及我推动全组织统一采用的指标，是：从 ticket 到变更真正交付到用户手里，这段时间有多长。因为它能覆盖整个交付链路里的所有关键环节。
今天，即便你看 ticket backlog，团队也经常会陷在这类问题里：“我该不该优先做这个？”“这重要吗？”“我问问 PM？”“我问问项目经理 / 产品运营 /whatever？”但现在我们从过去走到今天，场景变成了：有人给我们反馈，我们几乎几秒钟内就会行动。我们甚至做了一个内部 bot（我等会很想给你展示）。几秒钟内 PR 就开始被写出来——一个 agent 接手，然后几秒钟内这条反馈就开始被执行。
所以我们会拆解并压缩几个关键时间：
Time to action（反馈到开始行动的时间）
Ticket → PR ready for review（从需求 / 问题到 PR 准备好可评审的时间）
Review time（评审耗时）：我所有的 “dubs”（同事 / 下属团队）都在抱怨评审太慢。我们找到了一些解法。以前 PR review 的平均 cycle time 大概 150 小时，因为积压太多。现在我们把它 缩短了 10 倍，降到大约 15 小时。
Merge → 发布 / 上线（比如 OTA 更新）：最后是从合并到真正触达用户，这一段也要压缩。把整个链路再挤一遍，团队就会被速度彻底“解锁”。
主持人： 然后你就能把东西更快交到客户面前，你就能获得“市场想法的速度”。
Chintan Turakhia： 没错。我们也在痴迷于一个问题：如何尽可能快地把真实世界的反馈转化为修复？
我还有一个“顿悟时刻”。我当时和一个用户通话，他说：“如果你们把 X、Y、Z 改一下就更好了。”我当场开着通话，直接提了 PR，推送。30 分钟后，在通话结束前，我说：“你刷新一下，已经修好了。”
主持人：现在先来看看你实际构建的东西。因为“工程组织能做到这件事”这个宏观结论固然重要：有步骤、有衡量方法，大家都能学到。但你们也确实做了很多具体构建。所以我们来聊聊：你到底怎么用 Cursor 把这套东西推入组织，并且理解 AI 的采用情况？Chintan Turakhia： 我觉得很多事情都来自一种 诚实的好奇心：弄清楚瓶颈在哪里——为什么大家不采用？大家到底怎么用？等等。
我接下来要讲的可能有点疯：我当时冒出一个异想天开的点子。
Cursor 的数据分析能力其实很强——你进 admin 面板看 analytics，而且它还允许你把数据下载成 CSV。我就想：能不能干脆用 Cursor 来分析团队到底怎么用 Cursor？但不是那种虚荣指标式的统计，比如“AI 提交了多少行代码”。我觉得那其实挺误导的。更重要的是深挖：他们到底怎么用、怎么把“高手用法”复制出来。
我们有一些数据，它是 Cursor 从后台下载的一个标准 CSV。里面有很多字段，比如：accepted lines、chat lines、chat lines deleted，以及各种数据项。
我一开始很简单：我想理解 Cursor 的使用情况。我已经知道团队里从轻度用户到重度用户都有。我特别想搞清楚的是：使用行为有没有天然的“聚类”？能不能在团队里找出这些群体？怎么做分组（cohort）最合理？我就把这个标准 analytics 文件丢进来，用 Curosr 进行分析。
主持人： 我想对工程经理或工程领导者强调的是：这种定量分析，是我们以前一直想在各种工程指标上做、但做起来特别难的。董事会或老板经常问：速度怎么样？cycle time 怎么样？哪些工程师效率在曲线最右侧？初级工程师进 repo 的上手情况怎么样？这类分析以前非常费劲，因为数据结构复杂、分析链条长。而我喜欢 LLM 的地方——尤其是像 Cursor 这样的工具——在于你作为管理者，可以做出非常细腻的、基于人类行为的人群分组分析和人效分析，这在以前真的很难。
Chintan Turakhia： 我完全同意。更妙的是，现在有了 MCP、数据更容易接入了，我甚至把 Cursor 当作自己的“日常操作系统”——不管是不是技术问题，我都直接进 Cursor 问它，这个视角很强。
我把 Cursor 管理后台导出的 CSV 丢进去，让它帮我做两件事：一是按使用方式把团队自然分群，二是把结果做成我能复用的输出（比如 CSV 汇总、简单的 dashboard，顺便生成一份 Python 脚本）。它会按大致的使用强度把人分成 light、moderate、active、power、super user，也会看一些更细的维度：产出量、使用复杂度、是否常用 agent mode、模型偏好、采纳率，以及到底用了哪些功能。
跑完后，它给了我一些高层指标（比如 AI 生成占比、每周 AI 行数、agent/composer 生成行数、tab 补全行数），更重要的是它做出了更“行为导向”的分群：一类是 agent-heavy，很多任务直接交给 agent；一类是 tab-heavy，主要靠 tab 补全，更偏“自己掌控”；还有 balanced，两边都用；以及 cursor curious——装了但用得少、还在观望、还没真正进入“LLM 工作流”的人。
脚本生成好以后，我下一步就是拿一个样本用户集跑更深入的分析，把这些分群变成可执行的建议：每一类人该怎么用，才能往“更高阶”的用法迁移。
主持人 Claire Bell：而且我觉得这个案例有趣的点在于：每个做过工程管理的人都知道，这种东西就是你会被拉去董事会汇报的内容。老板会问你：我们有多少工程师在用 Cursor？有没有 power users？我们到底有没有拿到价值？我们现在谈的是 AI 的用例，但其实在管理实践里，有很多关于团队表现和效率的指标是可以量化的。Chintan Turakhia： 没错。而且以前这几乎是不可能拿到的。再者，如果不能用代码去做，就不好玩了——但现在你可以用代码来做。说到底，你现在就是在用“代码”解决问题。你说得太对了。我之前其实低估了你刚才强调的那个点，我想再重复一遍：正常情况下你被问到这些问题，你得去拉一个 IC 来做，现在你可以自己直接做出来。
主持人 Claire Bell：我有两个闪电问题，第一个问题：如果你回看两年前到现在，在工作上你最大的变化是什么？你现在怎么花时间？Chintan Turakhia： 我的日历几乎是空的。几乎空。原因是——协作开销大幅降低。以前是“我们优先级排一下”“改改 roadmap”。现在是——直接做。
第二，我写代码的时间多了很多。团队都知道，如果我提交的代码比他们还多，那我们可能需要帮他们多用点 AI（笑）。当然，团队在做极其复杂的工作，我不是替代他们。
但我现在可以花更多时间进代码库，修 bug，试验方案，推进技术路径。
如果 AI 带来了什么礼物，那就是——取消会议。
主持人：最后一个问题：当 AI 不听你话、给你一个很蠢的 playbook 时，你的 prompting 技巧是什么？Chintan Turakhia： 看我试了几次。如果试了很多次还不行，我一般会说：
第一，你明显没听我说话，这是我真正说的。
第二，我知道我是对的，但别傻了，帮我一下。
第三，终极选项——威胁它。比如用 Claude Opus 4.5 high 时，我会说：“Claude，如果你再不行，我就切换去 Gemini。”然后它就会振作起来。
参考链接：
https://techcrunch.com/2025/08/22/coinbase-ceo-explains-why-he-fired-engineers-who-didnt-try-ai-immediately/
https://www.youtube.com/watch?v=tidINuXB7PA
https://x.com/brian_armstrong/status/1963315806248604035
