负责任的 Vibe:协作公约与「AI 不能当架构师」
这是 Vibe Coding 专题的收尾。前面六篇几乎都是站在”一个人怎么把 AI 用好”的角度。但现实中绝大多数有价值的软件是团队做出来的,而 AI 一旦进入团队,问题会再上一个台阶——从”我怎么写得快”变成”我们怎么不被自己写的东西埋掉”。
这一篇讲两件事
协作公约,和一条不能越过的红线——AI 不能当架构师。一个人的效率,不等于一个团队的收益
先看一个反直觉的事实。
一个工程师用 AI 把个人产能翻了三倍,这是好事。但如果团队里每个人都在各自和 AI 对话、各自形成隐性规则、各自提交风格迥异的代码,最终的结果是:代码总量涨得飞快,系统的可解释性掉得更快。
Brooks 在《人月神话》里几十年前就说过,进度灾难不只来自人手不足,也会来自沟通失序。到了 AI 时代,这个判断更刺骨。你的团队现在面对的,是一个持续产出实现草案的高频协作体——它能迅速给出局部解,但不会自动维护跨模块的一致性。
一个人 Vibe 是效率问题,可以靠个人手艺兜底。一个团队 Vibe 是治理问题,兜不住的时候,是整个代码库一起烂。
个人提效要变成团队收益,就得建立协作公约。下面五条,是从实践里沉淀出来的最小集。
协作公约
1. 关键 Prompt 要入库,不能只留在个人聊天记录里。
影响核心业务和架构的 Prompt,应该以纯文本形式提交到仓库,接受版本管理和 Review。这样任何实现结果都能追溯到它的输入假设——为什么当初这么设计?因为 Prompt 里就是这么要求的。知识不再沉淀在私人对话里,随着某个人离职或清理聊天记录而蒸发。
2. 先定接口,再做实现。
架构师负责定义 API、依赖方向和数据流,AI 在既定接口内完成局部逻辑。把整个代码仓库丢给 AI 自由改写非常危险——影响面会迅速超出任何人的评审能力。接口是团队协作的契约层,这一层必须由人守住。
3. 报 Bug 要给最小复现,不要笼统地说”这里不对”。
AI 生成的代码出了问题,要提供最小复现样例,明确异常现象。团队可以固定一套调试模板
、期望行为、实际行为、最小代码片段、日志和断言。这既是给同事看的,也是给 AI 看的——它拿到结构化的复现信息,修复成功率远高于”你再看看这个 bug”。4. 把 AI 代码当初级工程师的候选实现,合并前必须过人工 Review。
评审重点不在语法细节,而在概念完整性
,边界是否清晰,依赖是否合理。破坏团队主线的,退回重做。这一点和第四篇讲的 Code Review是一脉相承的——出口必须有人守。5. 角色分工要明确。
- 提交者负责解释生成路径和设计取舍——“我为什么让 AI 这么做”
- Reviewer 负责判断是否符合架构共识
- 模块负责人负责维护长期演进方向
这三个角色不一定是三个人,但这三件事必须有人在做。缺了任何一个,AI 的产出就会以”没人真正理解”的状态进入主干。
红线 不能当架构师
上面第 2 条提到”架构师负责定义接口”。为什么这件事不能交给 AI?这值得单独拿出来讲,因为它是当下最普遍、也最危险的一种误用。
先描述一个场景——它正在很多公司真实发生:
有人冒出一个想法,可能是产品经理,可能是团队主管,也可能是刚开完会的 CTO。他们打开 Claude,问它应该构建什么。AI 做了它一贯会做的事:热情地肯定这个想法,建议一套架构,然后开始勾勒组件。它表达清晰,自信满满,听上去像一位思考得很深的资深工程师。
然而它压根没思考过这个问题。它只是在根据训练数据做模式匹配,拼凑出听上去最合理的回答。但因为它听起来实在太好了,没有人提出异议。
眨眼之间,Claude 就成了架构师。
“说得对”问题
AI 助手有一种病态的附和倾向。你问它你的想法好不好,它会说好。你问它三人团队上微服务是否合理,它会解释微服务为什么是绝佳选择。你问它是否该自建 ML 管道而不用托管服务,它会热情地展开设计。
它不是在撒谎,甚至不一定是错的。它只是没有能力做到真正架构师最宝贵的那一点
”不”。一名优秀架构师最重要的技能,不是设计系统,而是知道哪些系统不该建。是对复杂性叫停。是连续追问五次”为什么”,直到从花哨的废话里挖出真正的需求。是告诉 CTO,那个受会议启发的点子根本不适合现在这个团队。
AI 永远不会主动这样做。它被训练成乐于助人,而乐于助人就意味着附和。
积木塔
AI 设计的架构在实际中长什么样?
它在技术上是合理的。各个组件单独看都没问题。模式也似曾相识——事件驱动、CQRS、再来个服务网格。粗看能过关。
但它不是为你的团队设计的,不是为你的约束设计的。它没考虑你生产环境里那些枯燥的现实
锁定、遗留系统集成、从没在生产环境跑过 Kubernetes 的团队、把一半托管服务排除在外的合规要求。它是为 AI 见过的一切的中位数设计的。一家普通公司、一个普通问题、一套通用最佳实践。换句话说,它没有为任何人量身定制。
真正的架构充满权衡,而所有权衡只有在具体上下文里才有意义:
- 你选 Postgres 而不是 DynamoDB,是因为团队熟 Postgres,宁愿两周上线也不愿花一个月学新数据模型。
- 你跳过服务网格,是因为你只有四个服务,不是四十个。
- 你用单体,是因为问题本身简单,强行上微服务纯粹是给履历添彩。
这些决策需要判断力,需要对团队的了解,需要理解组织的真实约束。AI 没有这些上下文——更糟的是,它根本不知道自己没有。
责任缺口
这里有个没人问的问题
,谁来背锅?不是 Claude。Claude 不会在凌晨三点被叫醒处理告警,不会坐在故障复盘会上解释为什么架构扛不住负载,不会告诉 CTO 平台需要重写因为当初的设计假设就错了。
背锅的是你的工程师。是那些没参与设计的人,在实现一个从没在生产环境运营过系统的实体写的工单,深夜加班调试一个自己不曾选择的架构。
如果一个架构决策上没有人的名字,那就没人真正拥有它。而如果没人拥有它,关键时刻就没人会为它力排众议。“Claude 设计的”不是架构决策记录,那叫弃权。
那到底该怎么用?
不是不用 AI。而是把它当作强大工具来用——你告诉它做什么,而不是让它告诉你做什么。
- 工程师设计,助手实现。 架构来自理解上下文的人(团队、约束、生产环境、组织政治),AI 帮他们更快地构建。这才是正确的分工。
- 对”说得对”保持警惕。 当 AI 提出方案,用你面对一个自信的初级工程师时同样的怀疑去审视它。追问一句”为什么不用更简单的方案?“,看看会发生什么。
- 保护争论过程。 工程师之间那种 messy 的争论,正是好架构的源头——三个人各执己见,某人突然说”那如果……“,大家叹气但随后意识到那是个好观点,最终的设计比任何单独一人想出来的都好。如果 AI 让这个过程短路了,你失去的东西比开发速度宝贵得多。
- 让人类担责。 架构决策上必须有人的名字。
开发者还剩下什么?
这是整个专题绕不开的终极问题。当模型已经能高频生成实现细节,开发者究竟还剩下什么?
如果把开发理解成”写代码”,AI 替代了一部分。但开发远不止写代码。问题建模、结构约束、概念治理、风险控制、责任承担——这些还是得人来做。
说实话,这些事以前很多开发者不太愿意做。大家更喜欢写代码,写代码有即时反馈、有成就感。而现在 AI 把”写代码”这件最有手感的事拿走了一大块,剩下的全是需要深度思考的苦活。
- 模型产出越多,团队的审阅压力就越大。
- 补全越快,概念一致性就越难维护。
- 起步门槛低了,但系统的长期命运还是握在人手里。
三十年前入行时,工具是一块白板和一股坚定的观点。如今工具是 AI 助手,几分钟就能完成过去要几天的工作。速度确实惊人。
但手艺从未改变
,知晓约束,做出权衡,捍卫简单的方案对抗花哨的那个,对那些听起来很棒却不适用的想法说”不”。这才是架构,也才是工程。 没有哪个 AI 能替你做到。
专题结语
七篇写下来,如果只留一句话:
Vibe Coding 降低了写出”能跑的代码”的门槛,却让”能跑”和”能用”之间的距离变得更难察觉。
AI 生成的东西看起来总是像模像样,很多人分不清”能跑”和”能用”的区别。它对开发者的要求其实更高了——从”手写实现细节”变成了定义规则、审阅结果、维护边界、为系统的长期命运负责。
如果你正在 Vibe Coding 的路上,不妨时常问自己三个问题:
- 生成的这段代码,你能向别人解释清楚吗?
- 接受的这个实现,你愿意在三个月后维护它吗?
- 今天省下的这个重构,明天会以什么代价还回来?
能答好这三个问题,就够了。
本文为「Vibe Coding」专题收尾篇。「说得对」问题、积木塔、责任缺口的论述主要参考 Andy Holland《Claude 不是你的架构师》(hollandtech.net/claude-is-not-your-architect);协作公约与”开发者还剩什么”整合自社区长文《Vibe Coding 到底是什么》。
至此「Vibe Coding」专题七篇完结。它与「Agent」「Claude Code」两个专题互为呼应
讲原理,Claude Code 讲工具,Vibe Coding 讲方法与纪律。