当 Vibe Coding 进入团队，真正的瓶颈已经不是写代码
Vibe Coding 极大地提高了个人开发效率，但当这种工作方式进入团队之后，一个很快就会暴露的问题是：代码生成得越来越快，团队却不一定跑得越来越快。真正限制团队吞吐量的，开始从编码能力转向需求理解、架构决策、上下文传递和结果验证。AI 时代的软件工程，也许需要重新思考一件事：如何把团队共识变成 AI 可以直接执行的工程资产。
第一次真正用 Claude Code、Codex 或 Cursor 完整做一个功能时，很容易产生一种错觉：软件开发这件事情，好像突然简单了。
以前一个功能要先找代码、理解调用链、写接口、补类型、调页面、处理异常，再来来回回调试。现在很多时候只需要告诉 AI："这里增加一个批量导出功能，沿用现有权限体系，补上接口和前端入口。"然后看着它搜索代码、修改文件、运行测试。
如果项目上下文比较完整，一个熟悉业务的工程师配合 AI，开发效率提高几倍并不夸张。
但做了一段时间以后会发现一个很有意思的问题：个人变快了，团队不一定变快。 甚至有时候，个人开发速度越快，团队的问题暴露得越明显。
因为过去"写代码"占用了大量时间，很多协作问题被编码成本掩盖了。现在 AI 把编码时间压缩之后，那些一直存在、但以前没那么刺眼的问题突然浮了出来。
需求到底是什么意思？这个接口为什么这么设计？为什么这里不能直接查数据库？上次讨论决定使用异步方案，结论记录在哪里？两个人同时让 AI 修改相邻模块，谁保证最后的设计还是一致的？一个新人打开项目，让 Agent 工作时，它凭什么知道团队过去半年形成的约定？
这些事情，AI 不会天然知道。
Claude Code 可以读取整个仓库，但它读不到昨天会议室里的争论。Cursor 可以理解调用链，但它不知道某个看起来奇怪的设计，其实是三个月前线上事故之后留下来的约束。Agent 可以生成一套逻辑完全正确的实现，但如果五个人分别给自己的 Agent 不同的上下文，最后得到的很可能是五套都"有道理"的代码。
这可能才是团队开始使用 Vibe Coding 之后真正要面对的问题。
个人 Vibe Coding 的核心，其实是"共享脑子"
个人使用 AI 为什么顺畅？并不只是因为模型代码能力强。更重要的是，人和 AI 之间有一个非常低成本的反馈回路。
你告诉 AI 做什么，AI 写。你看到结果以后觉得不对："这里不要新增 Service，沿用现有实现。"AI 改。你又发现一个问题："这个接口需要兼容旧数据。"继续改。
整个过程中，真正完整的需求其实没有写在任何地方。它存在于你的脑子里。你知道哪些地方可以妥协，哪些地方不能改；知道产品嘴里说的"用户"到底指平台用户还是业务用户；知道数据库里某个字段虽然叫 status，实际承担了三层业务含义。AI 每偏一次，你纠正一次。
所以个人 Vibe Coding 很像两个人共同操作一个上下文：一个人负责判断，一个 Agent 负责高速执行。
问题在于，一旦从一个人变成五个人，这套机制就开始失效。因为团队没有一颗共享的大脑。
张三知道支付接口为什么必须幂等，李四知道用户模块为什么不能复用某个公共表，王五知道前端某个按钮其实还有历史兼容逻辑。每个人都知道一点，但没有一个 AI 知道全部。
于是一个很有意思的变化出现了：AI 时代团队最重要的基础设施之一，可能不是更强的模型，而是把分散在人脑里的上下文变成机器可以消费的上下文。
这也是我理解的团队 Vibe Coding 和个人 Vibe Coding 最大的不同。前者不是"五个人分别用 AI 写代码"——如果只是这样，本质上只是把五个程序员分别加速。真正的团队 Vibe Coding，应该是：团队先形成共识，再让 AI 基于同一份共识执行。
文档开始从"给人看"变成"给 Agent 执行"
传统软件工程里，我们当然也写文档。PRD、接口文档、技术方案、会议纪要、README、架构图……但很多文档的默认读者一直是人，所以里面允许存在大量人类可以自动补全的模糊信息。
比如："增加操作日志功能。"
对于参与过会议的人来说，这句话可能已经够了。大家脑子里自动补齐了一堆信息：哪些操作需要记录、谁能查看、存多久、失败是否影响主流程、批量操作怎么处理、查询量有多大。
但如果把同一句话交给 Agent，它只能开始猜。猜得好，看起来像魔法。猜得不好，就是"AI 怎么又乱写"。
这也是为什么进入 Agent 编程以后，很多团队会慢慢发现，真正有价值的 spec 和传统需求文档并不是一回事。好的 spec 不一定很长，但它应该减少猜测。
与其写"增加管理员操作记录"，不如明确：
对用户权限修改、数据导出、批量删除三类操作记录审计日志。日志包含操作人、操作类型、目标对象、发生时间和请求 ID。日志写入失败不得阻塞主业务，保留 180 天。后台支持按照操作人、操作类型和时间范围查询。
这段话甚至算不上详细设计，但它已经产生了一个非常重要的变化：结果开始可以被验证了。
有没有记录三类操作？有没有请求 ID？写入失败会不会影响业务？查询条件是否存在？保留策略是否满足要求？当描述可以被验证，AI 编程才真正开始从"生成代码"变成"执行任务"。
这也是未来团队 spec 最重要的变化：它不是为了显得流程完整，而是为了降低执行过程中的歧义。
Code Review 的对象也会变化
AI 编程出现以后，我越来越觉得传统 Code Review 里有一部分工作正在失去价值。
比如检查某个空指针、发现一个明显的重复逻辑、提醒补异常处理、检查格式问题。这些事情不是不重要，而是越来越适合交给静态检查、测试和 Agent。
工程师真正应该把注意力放到另外一个问题：它到底是不是我们决定要做的东西？
这是一个比"代码有没有错"更高一层的问题。
假设团队准备增加一套资源权限能力。AI 最后生成了一套权限系统，代码结构很优雅，测试覆盖率也不错。但 Review 时有人发现：它重新设计了一套角色模型，而团队原来的决定其实是沿用现有 RBAC。从代码质量角度看，它可能完全没有问题。从工程目标来看，它就是错的。
因此团队 Vibe Coding 以后，Review 的一个核心对象会从代码本身逐渐扩展到：实现与决策之间的一致性。
可以把整个过程简单理解成这样：
团队讨论 → 形成可执行共识 → Agent 实现 → 测试与 Review
↓
结果符合预期？
↙ ↘
是 否
↓ ↓
交付 定位差异
↙ ↘
实现错误 需求遗漏 架构冲突
↓ ↓ ↓
Agent 调整共识 重新讨论
这里最有价值的并不是 Agent 执行那一步，恰恰是后面的分叉。
因为结果不符合预期，并不意味着永远都是"AI 写错了"。有时候实现错了，有时候最开始的需求就漏了场景，还有时候真正的问题来自架构。
例如一个看起来非常简单的操作日志功能，实际开发后才发现日志量远大于预期，如果同步写主库会影响核心链路。这时候继续修改代码解决不了问题，因为代码只是忠实执行了一个有问题的决定。团队需要回到上游重新讨论。
我觉得这是 AI 编程里一个很容易被忽略的地方：AI 越擅长执行，人越需要判断到底哪里出了问题。
否则团队很容易陷入一种奇怪的循环：AI 写代码 → 发现不对 → 改提示词 → AI 再写 → 还是不对 → 继续改。表面上一直在 Vibe Coding，实际上只是高速试错。
真正成熟的工作方式应该能够判断：究竟是 Agent 执行错了，还是我们一开始就没想清楚。
AI 最值得沉淀的，不是 Prompt，而是团队经验
很多团队开始使用 Claude Code 以后，第一个动作就是研究提示词。怎么写 Prompt？怎么让模型更听话？CLAUDE.md 应该怎么配置？这些当然有价值。
但如果一个团队真的长期使用 Agent，我觉得最终沉淀下来的东西不会只是"提示词技巧"，而是一整套工程经验。
比如连续几次开发都出现同一个问题：外部 HTTP 调用没有超时设置。第一次 Review 时改掉，第二次又出现，第三次还出现。到了这里，其实已经不应该继续把它当作单次代码问题。它已经说明：团队存在一个没有被显式表达的工程约束。
于是可以把它写入 Agent 规则："所有外部 HTTP 调用必须设置连接超时和读取超时，并明确失败处理策略。"如果能够通过静态检查解决，那就加入检查规则。如果属于架构决定，就写 ADR。如果属于 Review 经验，就加入 checklist。
CLAUDE.md / AGENTS.md
↓
Agent 开发约束
Lint / Static Analysis
↓
自动检查的工程规则
Test
↓
可执行的业务与技术约束
ADR
↓
关键架构决策及原因
Review Checklist
↓
暂时无法自动化的判断规则
这样做的价值其实非常大。
以前所谓"团队经验"，很大一部分存在于老员工脑子里。"新人为什么不能这么写？""因为以前出过问题。""为什么这里必须走 MQ？""历史原因，后面你就知道了。"这些都属于典型的隐性知识。
Agent 时代反而逼着团队做一件过去经常懒得做的事情：把隐性知识显式化。 因为你不写下来，AI 就真的不知道。
从这个角度看，我甚至觉得 AI 编程带来的最大工程价值之一，并不是生成代码。而是它会迫使一个团队重新审视：哪些东西只是大家"默认都知道"？哪些约束其实从来没有形成正式规则？哪些设计决策已经没有人知道原因？哪些经验只存在于某个核心成员脑子里？
当这些东西逐渐变成 Agent 可以读取的上下文以后，它带来的收益并不仅仅属于 AI。新人 onboarding 会变快，Code Review 会变轻，架构的一致性会提高，人员流动带来的知识损失也会减少。AI 只是那个逼团队把事情写清楚的契机。
最危险的情况：五个人拥有五套"正确答案"
所以我现在不太认同一种做法：给团队每个人配一个 AI 编程工具，然后就宣布进入 AI 研发时代。这只是工具升级，甚至可能制造新的问题。
因为过去工程师写代码比较慢，一个架构分歧可能两天后才暴露。现在两个 Agent 一个下午就能分别把两套方案完整实现出来。AI 不但会放大效率，也会放大分歧。
当团队缺少共享上下文时，每个人的 Agent 都可能非常勤奋地沿着不同方向快速前进。最后你会得到：更快产生的技术债、更快扩散的不一致设计、更快复制的错误模式，以及越来越大的 Review 成本。
所以 AI 时代真正重要的不是"让每个人都有 Agent"，而是让这些 Agent 尽可能运行在同一套工程认知之上。
这套认知可以分散在很多地方：项目规则、设计文档、测试、ADR、代码本身、接口契约、数据库规范。形式并不重要，重要的是团队的关键判断不能永远只存在于聊天记录和某个人脑子里。
软件开发的重心正在悄悄上移
过去我们经常把软件开发理解为：需求 → 设计 → 编码 → 测试 → 上线。于是程序员大量时间花在"编码"这一步。AI 正在快速压缩这一部分。
但它并没有让软件工程消失。反而让另外几个环节变得更重要：理解问题、定义边界、做技术决策、表达约束、验证结果、发现遗漏、沉淀经验。
也就是说，过去很多团队把软件工程中最昂贵的环节理解成"把代码写出来"。现在会越来越发现：真正昂贵的是让一群人对"到底应该写成什么样"形成一致判断。
代码只是这个判断的一种最终表达。
这也是为什么一个团队不可能因为接入几个 AI 工具就自动获得五倍生产力。如果需求每天都在重新解释，架构决策没人记录，Review 只是挑代码格式，测试无法表达业务预期，那么 AI 唯一做到的事情，很可能只是让混乱发生得更快。
反过来，一个团队如果已经能够把问题讲清楚、把决策记录下来、把约束变成测试和规则，那么 Agent 会产生非常明显的杠杆效应。因为大量执行工作可以被机器接管，人的精力就可以继续向上移动。
Vibe Coding 的下一阶段，可能不是 Coding
个人 Vibe Coding 最爽的地方，是从想法到代码之间的距离变得非常短。而团队 Vibe Coding 真正值得期待的地方，是另一件事：从团队共识到软件实现之间的距离，也开始变短。
一个需求经过讨论形成明确约束，Agent 根据约束执行，测试和 Review 验证结果，发现遗漏以后修改共识，重复出现的问题沉淀为团队规则，下一次 Agent 自动遵守这些规则。
于是整个系统慢慢形成一个循环：共识 → 执行 → 验证 → 修正 → 沉淀 → 下一次更好的执行。
这可能比"AI 一次写多少代码"重要得多。因为代码生成能力还会继续变强，模型也会越来越便宜。真正难复制的，最终反而是一个团队经过长期实践形成的那些东西：知道什么值得做，知道事情应该做到什么程度，知道哪些边界不能碰，知道过去为什么踩过坑，也知道一次失败之后应该把经验留在哪里。
过去这些东西被称作经验、规范、工程文化。到了 Agent 时代，它们还多了一层新的意义：它们开始成为可以被机器直接消费的生产资料。
所以 Vibe Coding 并没有让软件工程变得不重要。恰恰相反。当"写代码"越来越便宜以后，真正的软件工程，才开始显露出来。