跨国深谈← 返回←速度病：当团队 10 倍速写代码却推不出产品，怎么治

速度病：当团队 10 倍速写代码却推不出产品，怎么治

关联

人物 Matt Dailey

公司 REF

概念 速度病 · 智能体 · 决策层 · 上下文工程 · 状态 · 原型重力 · 智能体破产

AI 让个别工程师写得飞快，但很多团队的整体产出却陷入了「写了一堆没人看的东西」的窘境。Matt 是 Ref 的 CEO，他观察到工程师用 AI 变快后，团队反而集体染上了「速度病（指因 AI 导致产出突然暴增而引发的压力，结果是有产出却没影响）」。

他讲了一个很扎心的例子：他认识一个用智能体（能够自主执行任务的 AI 程序）写文章的人，用 AI 把构思、探索和编辑全流程自动化，产能高到「基本上每周都在写一本书」。但问题来了——读者根本看不过来，这些海量写出的页面最终都无人问津。这正是现在软件团队面临的困境：代码狂飙突进，最后做出来的东西却没有真正触达和打动用户。

速度病的四个典型症状

当整个团队开始用 AI 时，个人的小麻烦会被放大成组织灾难，Matt 总结了四个核心问题 ：

1. 待合并的 PR 太多：每个工程师都在疯狂用 AI 产出并提交代码，导致合并冲突频发，合并队列直接崩溃。
2. 团队四处乱撞：每个人手下都有一堆智能体在做不同的事，工程师自己的脑子先崩溃了；在组织层面上，大家各自带着 AI 朝不同方向冲刺，互相撞车，缺乏一致的焦点。
3. 频繁宣告「智能体破产」：工程师同时开着十几个终端狂跑任务，下班走人。第二天早上回来一看，面对一堆陌生的任务上下文，只能全部推倒重来。这不仅做着重样的工作，还白白浪费了算力 token。
4. 关键决策被智能体夺权：这是最致命的一点。如果工程师放手让智能体做关键决策，就等于交出了代码的控制权。如果在公司范围内发生，你就不再拥有自己的产品了 。

为什么会这样？我们还在用「埋头写代码」时代的旧工具

要根治速度病，得先理解工作流程的演变。在 AI 出现前，软件开发主要是「预先计划 → 埋头实现 → 打磨发布」。我们最核心的工具 IDE（集成开发环境），就是为「一个人埋头苦干写代码」而设计的。

但有了 AI，工作的形状变了：前期的规划变成了探索复杂系统、发挥工程师品味的创造性过程；中段的代码实现完全交给了智能体；人类只在最后接手进行打磨 。

既然「实现」已经不是人的主要工作了，IDE 这种为「实现」而生的工具就不匹配了。Matt 提出，我们需要一个为**决策层（思考关键技术取舍、发挥工程品味的地方）**打造的新工具 。

解法：用「文档」取代「聊天」来做核心工作

具体该用什么工具？Matt 给出的核心判断是：决策层的工具，应该是为「文档」打造的，而不是为「聊天」打造的。

为什么不能用聊天界面（比如现有的 AI 编程助手的对话框）？因为聊天是「实现」时代的遗留物，它默认是孤立的、转瞬即逝的。

你在聊天里跟智能体探索想法、做决定，但这些重要决定既没有跟团队共享，随着对话滚动也会彻底消失。更糟的是，智能体在聊天框里总喜欢问你「这样行吗？我推荐选 A」，你很容易无脑点头，放弃了思考 。

如果把工作中心转移到文档上，它就能成为通往软件系统的入口（就像钢铁侠的全息操作台）：你可以让 AI 帮你把复杂系统中相关的片段提取出来，摆在桌面上，帮你梳理关键决策。

这里最核心的概念翻转是**状态与动作分离**。如果你一直在与智能体的长对话中工作，所有的上下文都是隐式的、不共享的。

正确的做法是把「文档作为状态」，把「智能体作为动作」。你可以随时基于这个文档生成新的智能体，它们读取同一份共享上下文，从同一个起点开始工作。这本质上是在文档里做**上下文工程（精细管理 AI 工作背景的方法）**，让智能体相对无状态 。

这套新打法怎么解决开头的四大速度病？

• PR 堆积和方向乱撞：把代码审查的节点提前了。

大家在写代码前，先在文档上对齐关键决策，对齐后代码审查就变简单了；团队也能在有人深入钻研某条歧路前，早早地比对一下大方向 。

• 智能体破产：智能体本身没状态，工作结果都留在文档里。

哪怕你度个假回来忘了进度，只要读一遍文档就能无缝接手 。

• 夺权问题：最重要的关键决策被前置、显式地写出来，人类重新夺回了软件的所有权 。

同时还会带来一个意外的好处：持久的决策日志。与其事后费劲让 AI 去总结聊天记录里到底拍板了啥，不如直接把决策前置写进文档里保存下来 。Matt 断言，既然我们要做更多创造性的工作，未来的工程必然是「多人协作」的 。

本集带走

• 警惕「原型重力」：别一做出点东西就兴奋得只想赶紧发布。把你的速度从「代码速度」转移到「想法速度」，通过文档多探索几条路径，找到真正有价值的金子 。
• 切换工作档位：认识到你的工作不再是单一的「埋头实现」，而是「规划」和「打磨」两个档位。留意自己是否在单个会话中不知不觉从规划漂移到了打磨，确保你用的工具服务于当下的任务 。
• 把计划当成操作台：不要把写计划当成走过场，要把它当成一个可塑的、通往软件系统的入口，让 AI 把你当前最关心的东西提取出来辅助决策 。
• 写下计划并务必分享给队友：别只把计划丢给智能体去实现，一定要把它交给团队里的聪明人。他们脑海里的上下文能给你极其宝贵的反馈 。

个别工程师用 AI 进展得非常快，但团队作为一个整体却没有
Individual engineers are going really fast with AI, but the team as a whole is not
—— Matt Dailey · [00:24]

如果你作为工程师让智能体做出关键决策，你就是在放弃你的代码的控制权。
If you as an engineer are letting an agent make a critical decision, you are ceding control of your code.
—— Matt Dailey · [03:27]

聊天的问题是它们是为实现而构建的遗留物。
The problem with chats is that they are the relic of building for implementation.
—— Matt Dailey · [10:11]

你想要的是将智能体作为操作，将文档作为状态分离开来。
What you want is to separate the agent as the action and the doc as the state.
—— Matt Dailey · [13:44]

你正在从代码速度转向想法速度。
You’re shifting from code velocity to idea velocity.
—— Matt Dailey · [15:13]

人类需要拥有决策。
Humans need to own the decisions.
—— Matt Dailey · [17:15]

我认为工程学的未来是多人游戏。
I think the future of engineering is multiplayer.
—— Matt Dailey · [18:17]