速度病的表征：提速 10 倍后的团队混乱

当个人开发者利用 AI 大幅提升编写代码的速度时，往往会给整个团队带来意想不到的系统性摩擦。这种由于 AI 引入导致产出骤增而引发的压力与混乱，被称为速度病（Velocity Sickness: AI 带来的代码产出暴增与实际业务影响脱节的失衡状态）。团队在经历速度病时，通常会表现出以下四个典型问题：

• 待合并的 PR 泛滥：当全队工程师都在使用 AI 疯狂产出代码时，PR（Pull Request: 合并请求）的数量会呈指数级上升。这会导致合并队列崩溃，冲突频发，团队根本无法高效地进行代码审查和合并。
• 开发方向四分五裂：多名工程师在多个智能体的辅助下，同时朝着不同的方向疾驰，彼此缺乏有效的同步。这不仅容易导致工作内容冲突，更会让团队失去专注力和协作凝聚力。
• 智能体破产（Agent Bankruptcy: 开发者由于同时管理过多独立 AI 会话导致上下文过载，最终放弃并清理所有会话的历史状态）：工程师在一天内开着十几个终端与多个智能体协作，看似完成了海量工作；但在隔天重新面对这些智能体时，却像走入一间装满陌生人的房间，无法重建协作上下文，只能选择将其全部关闭并重新开始，从而造成了严重的 Token 和时间资源浪费。
• 出让代码所有权：这是最致命的问题。当工程师允许智能体代替自己做出架构设计或关键逻辑决策时，就等同于放弃了对代码的控制权。长此以往，公司将不再真正拥有自己的产品，而是被智能体编写的未知代码所主导。

这一系列问题的根源，在于我们虽然极大提升了代码的生成速度，却并没有将其转化为有实际影响力的业务价值，即陷入了“无效果的高产出”陷阱。

未读页面与未用软件：低频连接的效率陷阱

为了更直观地理解速度病，可以从非软件工程领域中寻找共性。一位 newsletter 创作者展示了由 AI 驱动的高效创作流程：他将想法生成、研究探索、内容整合和编辑修正等环节全部交给智能体协同打理。这套高度成熟的体系让他能够达到“每周产出一本书”的惊人效率。

然而，在这个看似完美的创作管道中，存在一个核心断层：他的受众根本不可能每周去读完一本书。尽管智能体极大提高了内容产出的速度，但由于缺乏读者在接收端的消化和反馈，绝大多数生成的页面最终都处于无人阅读的状态。这种高产出与零阅读的断层，完美折射了软件工程师在使用 AI 时的现状。

我们开发产品的最终目的是与人建立连接，去改善用户的日常生活和工作方式。然而，在速度病的影响下，工程师们极易沉溺于“我能用 AI 快速写出大量代码”的技术快感中，而忽略了这些代码是否真正解决了用户的痛点。效率的骤增掩盖了方向的偏离，导致生产力资源的空转。

工作流重塑：从“个人脑力编码”到“人机协作设计”

在传统的软件工程时代，开发者的工作流是一个相对连贯的单人闭环：首先在前期进行构思和规划，接着进入长时间的隔离式编写与自我迭代（即单人纯手工实现环节），最后做一些细节润色并发布。以往所有的集成开发环境（IDE）和代码管理工具，都是基于这种“单人、沉浸、以实现为核心”的模式设计的。

引入 AI 之后，工作流的底层结构发生了剧变：

1. 前期设计与规划：人类开发者首先要明确意图，构建系统轮廓并梳理系统关系。
2. 生成与实现：传统的编码实现环节，已逐步外包给智能体自动执行。
3. 审视与润色：人类重新接入，接管智能体生成的结果，进行可行性审查、深度测试和逻辑打磨。

在这套全新的流程中，真正的“人类手工编码”时间已被大幅压缩，而最具创造性和协作性的规划和润色环节则上升为主导。开发者已经从一个体力编码者转变为决策层（Decision Layer: 开发者在 AI 编码时代的核心职责，专注于系统架构、决策权归属、设计品味和战略路线的定义）。决定工程成败的，不再是键盘敲击的速度，而是开发者能否通过清晰的决策将复杂的软件系统引导至正确的方向。这要求我们必须切换工程“挡位”，使用匹配这一决策层协作特征的全新工具体系。

graph TD
    subgraph 传统开发模式 (以编码实现为核心)
        A[前期规划] --> B(手工编码/迭代/单兵作战)
        B --> C[后期润色与发布]
    end
    subgraph AI协同开发模式 (以决策与规划为核心)
        D[人类: 前期规划与意图设计] --> E{智能体: 自动生成与实现}
        E --> F[人类: 审查、调试与打磨]
    end
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#bbf,stroke:#333,stroke-width:2px
    style F fill:#bbf,stroke:#333,stroke-width:2px

文档中心模式：以“状态”为载体的系统级交互

大多数团队在决策层遇到的第一个阻碍，是过度依赖单向聊天的“对话框交互模式”。基于对话（Chat）的协作工具天然是隔离的、转瞬即逝的、容易让人放弃深度思考的。在对话中产生的核心架构决策无法沉淀、极难跨团队共享，甚至会随着对话窗口的关闭而被智能体彻底遗忘。

一个真正适配决策层的开发工具，应当以文档（Docs）而非对话作为交互的核心媒介。在这个模式下，工具链的工作方式发生了本质的转变：

1. 信息聚合与呈现：像钢铁侠的贾维斯一样，它能分析整个复杂系统，把与你当前任务最相关的系统上下文（代码段、接口依赖、历史修改记录）自动拼装并平铺在你的面前。
2. 解耦状态与行为：最核心的观念转变是将文档作为系统状态的载体（即软件的骨架与核心决策流），而将智能体降级为无状态的执行动作。

当智能体变得 stateless，开发者就可以从同一个结构化文档中随时衍生、启动不同的智能体去并行实现不同子模块，而不必担心上下文断流。同时，人类开发者也可以通过实时查阅这篇高度结构化的文档，轻松重建协作上下文，彻底告别“智能体破产”的窘境。

graph LR
    A[人类开发者] -- 规划设计 --> B((共享文档: 状态/上下文))
    B -- 派发 --> C[智能体A: 独立任务]
    B -- 派发 --> D[智能体B: 独立任务]
    C -- 返回结果 --> B
    D -- 返回结果 --> B
    E[新进人类/智能体] -- 快速同步 --> B

想法速度的跨越：将敏捷评估点前移

引入文档中心工作流后，团队开发效率的评估标准将产生一个健康的演变：团队会发现大量的开发设计规划最终并没有转为具体代码的实现。

这并不是无谓的内耗，相反，它是敏捷开发在 AI 时代的进化标志。当团队把决策和审查点大幅度前移到编码工作之前，开发者就能以极低的 Token 和脑力成本，在文档空间内反复横向探索多种系统设计的可行性。这种演进帮助团队跳出原型重力（Prototype Gravity: 团队过早为某一初始原型方案提交实现代码，以至于由于重构和转换成本过高，被动锁死在并不完美的单一设计路线中）的束缚。

通过在设计阶段对海量“想法分支”进行快速筛选，团队实现了从传统的代码速度（Code Velocity: 生成和递交代码包的绝对速率）向想法速度（Idea Velocity: 在文档/规划层面探索、验证及废弃不同架构设计路径的迭代效率）的跨越。其最终结果是，每一次智能体启动的编码任务，都是基于高一致性的共识，极大地缩短了后续的代码合并阻力和重构周期。

实操行动指南：摆脱速度病的三个关键步骤

对于面临“速度病”困扰的技术团队，可以立刻在日常开发中落地以下三项具体的改良实践：

1. 分清“规划”与“润色”这两个不同开发挡位：在开启任何编辑器或智能体终端之前，清醒地认识自己目前所处的工程状态。是在进行前期的系统级架构规划，还是在对已有代码进行局部的微调打磨？不要在同一个长对话窗口里将两者混为一谈，注意工具在不同阶段对你的赋能效率。
2. 将设计文档视作系统级入口：像对待生产代码一样对待设计文档。利用 AI 提取系统依赖，将文档改造成可以清晰检索、自由组合、可读可写的交互界面。这不仅是向团队展现系统大图的窗口，也是你向下游智能体传递高浓度上下文的黄金底座。
3. 在团队中公开分享并评审你的设计计划：打破 AI 时代带来的“单兵闭门造车”怪圈。智能体非常擅长执行细节，但真正决定系统架构高度的是你的技术 taste。在让智能体跑起第一行代码前，把文档丢给队友，主动接受同僚们的输入、纠偏和建议。这是人类在 AI 研发时代巩固代码最终所有权最有效的防线。