我们团队 3 个人，最近全面切到 AI 辅助开发——两个人用 Claude Code，一个用 Cursor。
写代码的速度确实飞起来了，一个下午能出一个完整功能。但很快我们发现，写代码快了，合代码慢了。
这篇文章记录一下我们踩的坑和最终找到的解法。
灾难现场
某次 sprint，三个人分别开发三个功能模块，周五合代码。
坑 1：字段命名各写各的
A 的 agent 生成的用户接口：
{ "userId": 1, "name": "张三" }
B 的 agent 生成的：
{ "user_id": 1, "username": "张三" }
C 的前端代码里 expect 的：
{ "id": 1, "displayName": "张三" }
三个人，三套命名，同一个接口。
坑 2：返回格式不统一
A 的列表接口返回：
{ "data": [...], "total": 100 }
B 的列表接口返回：
[...]
C 的前端统一封装了 res.data.data 的解析逻辑，直接炸了。
坑 3：状态码和错误处理各搞一套
A 的 agent 用 HTTP 状态码 + message：
// 404
{ "message": "not found" }
B 的 agent 用 code 字段：
// 200
{ "code": 404, "msg": "未找到" }
修冲突花了一整天，比写代码还久。
为什么会这样？
想了想，根本原因很简单：
AI agent 是无状态的。每次对话它都是一张白纸，不知道你队友的 agent 做了什么决定。
你告诉它"写一个用户列表接口"，它会写出一个合理的实现。但"合理"不等于"和队友一致"。
每个 agent 各自合理，合在一起就是灾难。
我们试过的方法
方法 1：共享文档
在 Notion 写了一份 API 规范文档，让大家把链接贴给 agent 读。
问题：
- 每次新开会话都要重新贴
- agent 读了文档但不一定严格遵守
- 文档更新了不会通知其他人
结果： 坚持了两天就没人贴了。
方法 2：类型共享包
把接口类型定义抽到一个 shared package，想着 agent 会读 import 来对齐。
问题：
- agent 生成新接口时经常不参考已有类型
- 需要人手动维护这个包
- 跨仓库的场景更麻烦
结果： 有一定效果，但维护成本高，而且 agent 经常自己"创新"。
方法 3：Code Review 卡点
PR 里严格 review 接口一致性。
问题：
- 发现问题时代码已经写完了，改动成本高
- review 的人也不一定记得所有接口约定
- 本质上是事后补救，不是事前预防
最终方案：让 agent 写代码前先对齐
我们最后的思路转变是：
不要在合并时修冲突，要在写代码前就消除冲突的可能。
具体做法：维护一份团队共享的接口规范（living spec），让每个 agent 在写代码前自动读取最新版本。
核心流程：
1. 一个 agent 扫描当前代码库 → 生成接口规范（Markdown 格式）
2. 规范同步到云端
3. 队友的 agent 开始工作时 → 自动拉取最新规范
4. 所有 agent 按同一份规范写代码
5. 规范随代码演进自动更新
关键点：
- 规范是活的，不是写了就丢那种文档
- agent 自动读取，不需要人每次手动贴
- 一行 prompt 接入，不改现有工作流
我们基于这个思路做了 Coware，现在团队内部用了一个多月，接口冲突的问题基本消失了。
接入方式
在你的 AI agent（Claude Code / Cursor / Copilot 等）里粘贴一句话：
Use Coware Living Specs for team coordination. Read https://coware.team/llms.txt to get started.
agent 会自动：
- 读取指令
- 扫描代码库生成规范
- 同步规范到服务器
- 队友加入后自动共享
一些思考
Vibe coding 带来的效率提升是真实的，但它也引入了一个新问题：AI 的速度放大了不一致性。
以前人写代码，写得慢，但好歹会翻翻队友的代码看看风格。现在 agent 写得快，一个下午能出 2000 行，但它不会主动去看队友的 agent 写了什么。
我觉得未来多人 AI 协作的基础设施会是一个重要方向。不只是接口规范，还有：
- 数据库 schema 的协同
- 状态管理的统一
- 错误处理策略的一致
如果你的团队也在多人用 AI 写代码，建议尽早建立某种"规范同步"机制，不管用什么工具。否则越写越快 = 冲突越来越多。
欢迎评论区聊聊你们团队的 AI 协作踩坑经历 👇
