本文来自微信公众号： InfoQ ，编译：Tina，作者：Tina，原文标题：《Coinbase 真疯了？“不用AI就滚”，千人工程师被强制 AI 写代码，把 GitHub 都打崩了》
如果要说哪家公司在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相关的内部案例略有删节）。
1000人工程组织如何真正落地AI
主持人：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，最后终于把它跑通了”。否则大家不会买账。
你不能停留在哲学层面，更不能只说“未来会变好”。你必须回到工具里，用行动把路径走出来。
而且对很多工程负责人来说，这还有个额外的好处：我们其实已经被推离编码太久了。我也知道自己得重新回去写代码，重新找回那种久违的快乐。
从PR冲刺到交付提速
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分析团队怎么用Cursor
主持人：现在先来看看你实际构建的东西。因为“工程组织能做到这件事”这个宏观结论固然重要：有步骤、有衡量方法，大家都能学到。但你们也确实做了很多具体构建。所以我们来聊聊：你到底怎么用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