一个人 Vibe Coding 很开心，一群人 Vibe Coding 就炸了

你自己用 Cursor 做个人项目的时候，一切都很顺畅——你让 AI 写代码、你 review、你 commit、你 deploy。整个流程里只有你一个人，不存在"沟通成本"。

但入职之后呢？你在一个 5 人的团队里。小王也用 Cursor，但他的 .cursorrules 跟你的不一样。小李用 Claude Code，他的 CLAUDE.md 规范跟你写的完全矛盾。小张不用 AI，他觉得 AI 写的代码"不可靠"，每次 review 你的 PR 都要挑一堆毛病。

我亲眼见过一个团队因为 AI 编程搞得鸡飞狗跳。故事是这样的：

一个 5 人前端团队，老板说"大家都用 AI 提高效率吧"。然后就没有然后了——没有统一工具、没有统一规范、没有讨论工作流。结果一个月后：

• 代码风格完全混乱——A 的代码用 Cursor 生成的，函数式风格；B 的代码用 ChatGPT 生成的，类组件风格
• Git 历史一塌糊涂——有人一次 commit 5000 行（让 AI 生成了一整个模块然后一把推上去），有人 commit message 写的是 "AI generated code"
• Code Review 变成了战场——reviewer 不知道哪些代码是人写的、哪些是 AI 生成的，不知道该用什么标准来评价
• 出了一个线上 bug，排查发现是 AI 生成的代码里有一个竞态条件（race condition），但写代码的人说"这是 AI 写的我没注意"

这个团队最后花了两周时间才把规范理清楚。如果一开始就有一个好的工作流，这些问题根本不会发生。

AI 进入团队后的三大挑战

挑战 1：代码风格不一致

不同的 AI 工具生成的代码风格不同。就算是同一个工具，不同的 Prompt 也会生成不同风格的代码。你让 AI "写一个用户列表组件"和"实现一个展示用户数据的 React 组件"，出来的代码结构可能完全不同。

在个人项目里这不是问题，但在团队里这是灾难。5 个人用 5 种风格写代码，半年后这个代码库就没人看得懂了。

挑战 2：责任归属模糊

"这段代码谁写的？"——在 AI 时代，这个问题变得很尴尬。如果一段代码是 AI 生成的，出了 bug 谁负责？生成代码的人？review 通过的人？还是"AI"？

答案很清楚：谁提交的代码谁负责。不管代码是你手写的还是 AI 生成的，只要你 commit 了、push 了、PR 被 merge 了——这就是你的代码。你不能出了问题说"这是 AI 写的不是我写的"。

这意味着你提交的每一行代码，你都需要理解它在做什么。这也是为什么"让 AI 写完直接 commit"是一个非常糟糕的习惯。

挑战 3：Code Review 标准变了

传统的 Code Review 主要看：逻辑对不对、代码风格一不一致、有没有性能问题。但 AI 时代的 Code Review 需要额外关注：

• 这段代码是 AI 生成的吗？提交者有没有理解它？
• AI 有没有引入不存在的依赖？（AI 经常"发明"包名）
• 有没有硬编码的 API Key 或密码？（AI 有时候会在代码里留下示例密钥）
• 错误处理是不是只有 happy path？（AI 的通病）

这些都是 AI 之前不太需要检查的东西。