AI 写代码太快之后，团队协作反而更难了

最近用 AI 写代码越多，越明显感觉到一个变化：

以前团队协作怕"写得慢"，现在更怕"大家都写得太快"。

一个人让 AI 生成一个模块，另一个人也在做相似的东西；

一个 PR 几百上千行，功能能跑，但 review 的人根本不知道该从哪里看；

很多关键决策散落在聊天记录里，过几天连自己都忘了为什么这么写。

所以我越来越觉得，AI 时代的团队开发，不是简单地"提高编码效率"，而是要重新设计协作方式。

下面是我目前比较认可的几套方法论。

1. Spec-driven Coding：先写规格，再写代码

AI 很擅长执行，但它也很擅长"自作主张"。

你让它实现一个功能，它可能顺手帮你改类型、改接口、改状态管理，甚至重构一堆无关代码。单看每一步都好像有道理，但合在团队协作里，就很容易失控。

所以在让 AI 写代码之前，最好先写一个很短的 spec。

比如：

# Feature: 用户收藏文章

## Goal
用户可以收藏文章，并在个人中心查看收藏列表。

## In Scope
- 文章详情页可以收藏 / 取消收藏
- 个人中心展示收藏列表
- 刷新后收藏状态保持正确

## Out of Scope
- 收藏夹分组
- 批量管理
- 推荐算法

## Data Contract
收藏记录：
- userId
- articleId
- createdAt

## Acceptance Criteria
- 点击收藏后，按钮状态立即变化
- 取消收藏后，收藏列表不再展示该文章
- 接口异常时给出错误提示

这个 spec 不需要写成正式 PRD，也不需要很长。它主要解决三件事：

• 这次到底要做什么
• 哪些东西明确不做
• 什么情况算完成

我觉得这就是 Spec-driven Coding 的核心：

不是让 AI 先跑起来，而是先给 AI 画好跑道。

对团队来说，spec 还有一个额外价值：它让别人知道你这次的边界在哪里。

否则等到 PR 出来，大家只能从代码里反推你的意图，这个成本太高了。

2. Automatic PR：一个 PR 只回答一个问题

以前我们经常说"小 PR"，但 AI 时代，"小"这个词有点不够用了。

因为 AI 生成代码之后，行数经常不是最重要的问题。

有时候 800 行测试代码很好 review；有时候 80 行核心模型变更，反而非常重。

所以我更喜欢用这个标准：

Automatic PR：一个 PR 只承载一个核心决策。

比如下面这些 PR 是比较清晰的：

• 只定义收藏功能的数据模型
• 只实现文章详情页的收藏按钮
• 只接入收藏接口
• 只补收藏功能的测试

但下面这种 PR 就比较危险：

• 加收藏功能
• 改请求封装
• 调整用户模型
• 重构文章详情页
• 顺手修了几个样式问题
• 又补了一些无关工具函数

这种 PR 最大的问题不是代码多，而是决策混在一起。

reviewer 需要同时判断：

• 功能设计对不对
• 接口改得合不合理
• 重构有没有副作用
• 样式改动是不是必要
• 历史 bug 修复是否可靠

这就很难 review。

AI 写代码很快，但 PR 仍然应该方便人类理解。

Automatic PR 的目的，就是让每次 review 都聚焦在一个问题上。

一句话总结：

PR 的最小单位不是代码行数，而是决策数量。

3. Harness Engineer：工程师从"写代码"变成"驾驭上下文"

AI 时代，工程师的角色会有一点变化。

不是说工程师不写代码了，而是很多时候，我们更像是在做 Harness Engineer。

这里的 Harness，可以理解成"约束装置"或者"驾驭系统"。

AI 像一个很快的引擎。

工程师要做的，不只是亲手写每一行代码，而是让这个引擎在正确的轨道上输出。

具体来说，Harness Engineer 要做这些事：

• 给 AI 提供准确上下文
• 写清楚 spec
• 限定本次任务的修改范围
• 明确哪些文件不能碰
• 明确哪些公共契约不能改
• 设计验收标准
• 让 AI 写完后跑测试
• 对 AI 生成代码做第一轮 review

我现在给 AI 写需求时，经常会加类似这种约束：

只修改当前任务相关文件。
不要重构无关模块。
不要改变公共类型和接口。
如果必须修改公共契约，请先说明原因。
保持改动尽量小，方便 code review。

这些话看起来普通，但非常有用。

因为 AI 默认会倾向于"把问题完整解决掉"。

而团队开发里，我们更需要的是：

在当前边界内，把当前问题解决掉。

这两个目标并不完全一样。

所以，AI 时代的工程师，不能只做 prompt 的消费者，更要做上下文和边界的设计者。

4. Repo as Team Memory：不要把项目记忆留在聊天窗口里

AI 协作里还有一个很容易被忽略的问题：很多关键决策都留在聊天记录里。

今天你和 AI 讨论了一个方案，觉得很合理。

明天队友不知道。

后天你自己也忘了。

一周后大家看代码，只知道"这里是这样写的"，但不知道"为什么这么写"。

所以我觉得团队应该尽量把重要共识沉淀到仓库里。

可以很轻量，比如：

docs/
  product.md
  architecture.md
  decisions.md
  working-log.md

尤其是 decisions.md，非常值得维护。

示例：

# Decisions

## D001: 重要功能采用 Spec-driven Coding

原因：
团队会并行使用 AI 生成代码。如果没有明确边界，很容易出现重复实现和范围漂移。

影响：
核心功能开始前，先写简短 spec，再进入实现。

这不是为了写文档而写文档。

它真正解决的是"项目记忆"的问题。

代码告诉我们：现在是什么样。

commit 告诉我们：什么时候变成这样。

decision 文档告诉我们：为什么要这样。

AI 会让代码增长很快，如果项目记忆跟不上，维护成本也会涨得很快。

5. Ownership over Files：按问题域负责，而不是按文件负责

传统协作里，我们很习惯按文件或技术层分工：

• 你写前端
• 我写后端
• 你写页面
• 我写接口

这种分法当然还能用，但在 AI 时代不太够。

因为 AI 很容易跨文件改动。

你让它做一个页面，它可能顺手改类型、接口、mock、工具函数。

如果团队只按文件分工，很容易出现边界不清。

我更倾向于按问题域分工：

• A 负责账号体系
• B 负责支付流程
• C 负责内容编辑器
• D 负责数据看板

重点不是"这个人只能改哪些文件"，而是：

这个问题域的设计和质量，谁负责到底。

这样会更适合 AI 时代的开发节奏。

代码可以由 AI 快速生成，但问题域必须有人 owner。

否则大家都在生成代码，却没人真正对方向负责。

一套轻量协作协议

如果把上面这些方法合起来，我觉得可以形成一套很轻的团队协议：

1. 重要功能先写 spec，再进入编码
2. 一个 PR 只承载一个核心决策
3. AI 生成代码前，先明确修改边界
4. 公共契约变更必须说明原因
5. 关键决策写进仓库，不只留在聊天里
6. 分工尽量按问题域 owner，而不是只按文件

这套东西听起来像流程，但它的目的不是增加流程感。

恰恰相反，它是为了减少后续沟通成本。

AI 让编码速度变快了，但团队协作最终还是要靠共识。

没有共识，速度越快，偏差也越快。

最后

我觉得 AI 时代的团队开发，有一个很重要的变化：

代码不再是最稀缺的东西，共识才是。

AI 可以帮我们快速生成代码，但它不会自动保证团队方向一致。

它可以提升个人效率，也可能放大协作混乱。

所以我们需要的不是更重的管理，而是一套更轻、更清晰的协作协议。

Spec-driven Coding、Automatic PR、Harness Engineer、Repo as Team Memory，这些方法本质上都是在做同一件事：

让快节奏开发仍然可理解、可 review、可持续。

速度很重要，但速度必须有方向。🚀