速度眩晕:整个团队快了 10 倍之后会发生什么——Matt Dailey(Ref.)

• Matt 是 Ref. 的 CEO 兼创始人，公司要解决的问题一句话说得清：有了 AI，工程师个人跑得飞快，但团队整体并没有变快——他们做的就是把这中间的落差补上。这场演讲讲的是"当你整个团队都快了 10 倍之后会发生什么——那些不顺的事"。→ 详细
• 讲法是先摆问题、定义词，再看我们是怎么走到今天的、现在站在哪儿，然后"从高处起步，一层层往下落，越来越具体"，最后留下几条马上能用的做法。他特意强调：下面这些毛病本来是个人层面的，但一旦整个团队都染上，就会被成倍放大。→ 详细

▲ 图注：他列的四条症状原页：① PR 多到合不完；② 同时朝太多方向跑；③ 宣布 agent 破产（推倒重来）；④ 关键决策被 agent 做掉。整场后面每一段都在回扣这四条。

• 症状一：PR 多到根本合不完。（PR＝pull request，一次待合并的代码改动提案）这是工程师用上 AI 之后最经典的第一个坑——"太好了，我在疯狂出活"，然后把一堆 PR 全推上去，接着发现根本合不完。整个团队都这么干时，merge conflict（两个人改了同一处代码、系统不知道听谁的）一堆，merge queue（排队自动合并的流水线）直接崩掉。→ 详细
• 症状二：同时往一大堆方向跑。 个人层面是"你手上一堆 agent 各干各的，你努力记住谁在干什么，脑子直接烧掉"；组织层面是这个工程师捡起一件事往这边冲、另一个往那边冲，"说不定还撞到一起"，团队没有聚焦地拧成一股劲，而是朝四面八方各自狂奔。→ 详细
• 症状三：宣布 agent 破产（agent bankruptcy）——指的是把手上所有 agent 会话一把清空、从头再来。画面是这样的：你干得起劲，同时开着十来个终端（他说的是"12 个终端"），一天结束心想"嗯，今天干了不少活"，合上电脑去陪朋友家人；第二天早上回来，"那感觉就像走进一屋子陌生人：这些人是谁？他们在这儿干嘛？"反正是 agent，索性全清掉重来。代价是——你感觉自己干了很多活，可干的是同样的活，token 花了两遍；放到组织层面看，就是团队在时间和 token 资源上都很不划算。→ 详细
• 症状四（他说这条最要命）：关键决策是 agent 做的。 当 agent 替你干了大量的活，"如果你让一个 agent 去做一个关键决策，你就是在交出代码的控制权。这段代码的主人不再是你，而是那个 agent。"放大到整个公司想一想：如果团队里的工程师都在放弃对代码的所有权，那这个产品就不再是你的了。→ 详细

• 定义：速度病指的是"AI 让产出突然暴增所带来的那种压力"。它既会发生在个人身上，也会发生在团队身上，结果是「有产出，没影响力」（output without impact）。→ 详细
• 体感很特别：跑得飞快，"这本该爽的，本该很棒，可不知道为什么就是不爽。你以为会随之发生的那些事，并没有发生，哪怕你自我感觉高产得不行。"→ 详细

*▲ 图注：全场最锋利的一页：先立起 UNREAD PAGES（没人读的页数），再当场划掉，换成 WORDS THAT MATTER（真正重要的字）——产出不是目的，落到人身上的影响才是。*

• Matt 说他工作的一部分就是去找那些走在最前沿的人聊、向他们学习。这位主角不是工程师，是写 newsletter 的，但流程跟做工程高度相似：先有想法 → 做调研和探索 → 把这些想法揉到一起、做编辑加工，确保成品是他自己的腔调。对方一步步讲他怎么管理这整条 pipeline、怎么把自己的产能放大。→ 详细
• 关键是：这不是那种粗制滥造的 AI 垃圾。 Matt 的原话是"这完全不是那种粗制滥造的 AI 垃圾（slop），而是一个人用 agent 去放大自己的声音，做得非常漂亮"，他当时"听得津津有味"。然后对方来了一句：「所以我基本上每周写一本书。」→ 详细
• Matt 问："那你的读者每周读一本书吗？"对方说："大概不会吧。"——一个写了非常多东西的人，写出来的那些页，没人读。→ 详细
• 他把这一刀当成速度病的本体：我们造出来的东西，对我们想影响的那群人来说其实无关紧要、根本没触达。 比起一堆没人读的页，真正想要的是"写出有分量的字，写出能跟人产生连接的字"；对应到做软件、做产品的人，就是做出能改变人们生活方式和工作方式、让他们日子变好的产品。有了 AI 我们比以往任何时候都更有能力做到，可偏偏"感觉本该做到了，却总差那么一口气没落地"。→ 详细

• AI 之前的流程：先做前期规划 → 坐下来一个人闷头写、把东西实现出来（迭代和探索都在这一段里）→ 最后打磨一下、发布出去。"这套挺好的，我们都会这么干，也围绕它建了一大堆体系。"→ 详细
• 问题是工具是为那套流程造的——"我们整部编码工具的历史，都是为那种工作方式造的"。IDE（写代码的主力软件）作为主力工具，是为「实现」和「打磨」造的，是为一个人埋头写代码造的。→ 详细
• AI 之后的形状：前期规划（把脑子里的想法一点点铺开）→ agent 接过这个想法把它实现出来 → 人再把成果接回手里打磨、掂量一下"这是我想要的吗"。他说中间那一步"严格说都不该出现在这张幻灯片上，因为它已经不是人的活了"。→ 详细

• 人手上只剩「规划」和「打磨」，而这两块正是"我们作为工程师最有创造性、最需要协作的部分，是我们施展工程手艺的地方"——其中变化最大的是规划。→ 详细
• 规划这段活长什么样：脑子里有个模糊想法，面前是个复杂系统，你得摸清系统的轮廓、把想法套上去、从里面挑出真正相关的东西，然后亮出作为工程师的品味——我想让这个系统往哪儿走。这类工作"天生是创造性的，也天生需要一群人一起做"。→ 详细
• 他给了一条不会变的判断："在 AI 之下，工程团队和产品团队的形态正在改变，但有一件事永远不会变：总会有一群人负责管理一个复杂系统，并决定这个系统的未来。"那就是规划这块活。→ 详细

• 决策层（decision layer）：在这一层你思考哪些是关键决策、施展工程的手艺、亮出品味——"它跟「实现」完全是两回事，是工程师身上的另一个挡位"。→ 详细
• 他把这变成一个随时可自查的能力："今天真正的能力是：我现在挂在哪个挡上？我用的工具，跟我此刻想完成的这个挡位匹配吗？"→ 详细
• 一句话概括他要的工具：它会是围绕文档、而不是围绕聊天造的工具（a tool built for docs and not chat）。他自己说"这句话很短，但里面有很多东西要拆"，于是在这张片上多讲了很久。→ 详细

*▲ 图注：DOCS, NOT CHAT（要文档，不要聊天）：左绿是文档——可复写、可共享、耐久，关键决策一目了然；右红是聊天——只能往后追加、转瞬即逝、决策埋在对话里。*

• 聊天是"为实现而造"那个时代的遗留物：它默认是孤立的、用完即弃的，而且是不用动脑的——"它是拿来把事情做出来、做完的"，而决策层干的是创造性、探索性的活，根本不是一回事。→ 详细
• 决策在聊天里被做掉，然后消失：你带着一个模糊想法开始探索、开始提问，那些决策就在那个会话里被定了——没跟团队共享，回头就消失，最后只落下一堆代码，而那些重要的决策从来没被讲清楚、也没被同步给团队。→ 详细
• 「推荐选项」陷阱：agent 说"我打算这么干，行吗？走起"，或者问你一个问题、顺手加一句"这是推荐选项"，"然后你就想，好极了，那我干脆不动脑了，直接点那个，继续往下走"。——这就是症状四（决策权外流）在日常里的具体长相。→ 详细

• 文档的本职就是把关键决策摆到台面上，而"我们现在的活"是：搞清楚哪些决策真正重要，把这些决策做掉，然后让开路，剩下的交给 agent 去填。→ 详细
• 他用一个 AI 之前的类比证明这不是新发明：回想你当团队 manager 或 lead 的时候，团队对不齐，你不会说"来，咱们全都去 Slack 私信里干活吧"；你会说"把关键决策摆出来、对齐它们、把时间花在这些上面，想办法真正把决策做对"。用文档创造对齐，本来就是经典做法。→ 详细

*▲ 图注：他把工作分成三挡：PLAN（规划）→ IMPLEMENT（实现）→ POLISH（打磨）。AI 吃掉的是中间那挡，而两头恰恰最需要创造力与协作——他主张把新工具造在 PLAN 这一层。*

• 不是 plan mode（AI 编码工具里"先出方案、你确认了再动手"的那个模式）。他说那是个好工具，"但它本质上还是一条更丰富的聊天消息——agent 在说'嘿，我把想表达给你的东西做了个更好的可视化'"，依然跑在隔离、用完即弃的环境里。→ 详细
• 也不是全自动、工厂流水线式的 spec 驱动开发（先把行为规格定死、让 AI 照着全自动造）。也是好工具，但"只定义行为、只在产品层面上操作，离工程现实太远了"——工程现实是：我得理解我的系统，我需要一个工具帮我理解它，并且用技术的语言把那些关键决策摆出来。→ 详细
• 他要的是中间那个：更持久、更共享、生命周期更长——值得你和团队真正投入时间去经营的东西。→ 详细

*▲ 图注：「计划即传送门」的示意：左边是人待的地方（IDE / CLI），中间是 Decision（决策），右边是 Implementation（实现）——计划不是待办清单，是你进入整个软件系统的入口。*

• 他喜欢的比喻是 Tony Stark：你对着系统说"把重要的东西调出来给我看"、"我在做这一块，把相关的部分抽出来"。而"AI 最擅长的恰恰就是找出事物之间的关联"，帮你锁定哪些相关、把它们摊在你面前的桌上；接着你按自己的想法把这些零件组织起来，表达你希望这个系统怎么生长。→ 详细

• 翻转本身：在一个长时间的会话里跟 agent 干活，会有一层隐性的上下文慢慢积累起来，"这本身是好事"；但你同时也在执行各种动作，而这些动作是不共享的。他要的是——把 agent 当作「动作」、把文档当作「状态」，两者分开。→ 详细
• 这么做换来什么：你可以派生出新的 agent，它们带着同样的上下文、从同一个起点出发，能在同一份状态上协作。"你在这份文档里做的其实就是 context engineering"（上下文工程，即刻意安排喂给 AI 的背景材料，而不是指望它自己攒），让每个 agent 基本上都是无状态的（不依赖自己记住什么，因此随时可杀、随时可重开）。→ 详细
• 对人的好处：你和你的团队可以打开这份文档，看清里面到底有什么、正在做哪些决策，对关键决策有一个清晰的把握。→ 详细
• 一句话收口：你工作的基本单元是一份文档，而不是一段对话。→ 详细

• 第一个观察到的现象是：人们开始做计划，然后并不去实现这个计划。 Matt 说这"其实是个非常好的信号"。→ 详细
• 因为这意味着他们在把想法想透——"我脑子里只有个模糊的念头，别急着给我代码，别自己跑去把它建出来，先帮我把我说的这个想法搞明白。"→ 详细
• 然后他们攒了一堆这样的想法，其中一些被建出来了，另一些没有——"这说明他们在做优先级取舍：探索完之后，挑出真正值得建、值得往下一步推进的那些。"→ 详细

▲ 图注：一句话的翻转：CODE VELOCITY ⇒ IDEA VELOCITY——该被提速的不是写代码，是把想法推进到位。

• 他的概括：你从 code velocity（代码的速度）转向了 idea velocity（想法的速度）。回到最开始的问题——速度病就是"我们发了一大堆最后哪儿也没去成的代码"，解法是把这份速度转移到想法上。→ 详细
• 原型引力（prototype gravity）：建了个东西，"兴奋得只想赶紧把它发出去，一头扎进想法迷宫（idea maze，一个想法能走的所有可能岔路）的某一条岔路"里出不来。把速度放到想法上，你才能"更高效地把整座迷宫探完，找到拐角后面的那块金子"，并真正影响到你想帮的那群人。→ 详细

▲ 图注：开场那四条症状被逐条打上对勾：评审计划、尽早对齐、读文档、决策权归人；底部一行是他的总结——并行 agent、持久的决策日志、协作变多。

• PR 太多 → 把 review 这个节点往流程更早的地方挪。 先在关键决策上对齐，代码 review 就变简单了——因为"任何一次代码 review 里最难的部分，就是搞清楚这里到底什么才是重要的"，第一步永远是"我该关心什么"；把这一步提前、先对齐好，后面就轻松多了。→ 详细
• 方向发散 → 提前对齐，团队共享计划。 个人层面你能"在很多个 agent 之间搞清楚自己到底在做什么"；团队层面共享这些计划、达成一致，而且这很容易做到——"在有人花上一整天让 AI 深挖某个想法、做出一个原型之前，我们就能早早聊一聊，确认我们对系统要走向哪里是有共识的。"→ 详细
• 宣布 agent 破产 → 压根不会发生。 因为你已经把 agent 变成无状态的了，它工作的成果都在文档里；"如果你需要重建你自己（人类）那份上下文，读一遍文档就行"——你马上就明白项目现在是什么状态，从那里接着往下走。→ 详细
• 最重要的一条 → 决策权归人类。 "这才是我们真正要解决的事。人必须掌握决策权，这样我们才能保住对自己软件和产品的所有权，让它真正成为我们想在这个世界上创造的东西的表达。"→ 详细

• 并行 agent 更容易跑：状态抽离出来、大家从共享的上下文出发之后，同时跑多个 agent 变容易了。→ 详细
• 一份持久的决策日志：很多人在琢磨怎么把会话里产生的决策全记下来；他的解法是反过来——"干脆把所有决策在一开始就抽出来、达成一致、放进一个持久的地方，这样就不用等着某个 LLM 事后帮你总结、还可能挑错重点"，前置了才能存下来、以后随时回看。→ 详细
• 协作变多（他说这是他最喜欢的一条）：这个流程里的活更偏创造性，工程师就该更多地协作。"我认为工程的未来是多人模式的，而且它默认变成多人模式的那一天，会比我们以为的来得更早。"→ 详细

▲ 图注：他给的三条走出会场就能做的事（页面上是编号列表）：想清楚「规划」和「打磨」分别挂哪一挡、把计划当成通往系统的传送门、把计划分享给队友。

• 第一，把你的工作分成「规划」和「打磨」两档来看。 意识到自己是在两个挡位上工作，不再只有"实现"这一个焦点。留意你是不是在同一个会话里把两件事一起干了、留意你什么时候从规划阶段滑进了打磨阶段，以及"此刻你手上的工具，到底服不服务于你当下想做的那件事"。→ 详细
• 第二，开始把你的计划当成「通往软件系统的传送门」。 真正把它当一个强大、可塑的工具来用：对我眼下做的这件事来说，什么才是重要的？让它把这些呈现出来给你看，好让你做出尽可能好的决策。→ 详细
• 第三，把计划分享出去——给团队里的某个人看，别只是写完丢给 agent 去实现。 他承认"这对很多人来说非常别扭，我们总觉得自己心里有数"，但"你有很聪明的队友，他们脑子里有很好的上下文，你应该把这些用起来，他们会给你很好的反馈"。→ 详细

• Matt，Ref. 的 CEO 兼创始人。 演讲最后一张片上放了他的全部联系方式（视频里只说"这上面有我所有的联系方式"，没有念出具体地址）。→ 详细
• Ref. 是一个为「决策层」打造的工具，"跟你现有的所有实现类工具都能配合"。想看 demo 可以去 AI Engineer 大会现场的展台，或者在场外直接找他。→ 详细