过去很多年，我们讨论研发协作，常见的框架无非两种：瀑布流，或者敏捷。
落到执行层面，分工方式也很稳定：产品提需求，设计出稿，前后端开发实现，测试提缺陷，研发修复，最后上线交付。这个模式在传统手工编码时代非常合理，因为代码是靠工程师一行一行写出来的，研发天然就是整个交付链路里唯一的实现中心。
但进入 Vibe Coding 之后，这个前提已经开始松动了。
今天很多项目里，真正稀缺的能力，已经不再是"谁来写出第一版代码"，而是"谁能把 AI 生成的系统持续拉到可交付状态"。第一版往往出来得很快，真正拖慢项目的，反而是后面的反复修正、边界补洞、体验打磨、缺陷回归和上线验收。
问题也就出在这里。
如果团队分工还停留在旧时代，那么 AI 提升的只是局部生成速度，却没有缩短整条协作链路。最后常见的结果不是效率翻倍，而是沟通轮次变多、返工次数变多、责任边界变模糊，甚至把 AI 带来的收益重新吃掉。
所以，Vibe Coding 下更适合的研发组织方式，不应该再沿用"产品---开发---测试"的串行接力，而应该拆成三个更贴近实际产出的阶段：
设计（Design） → 实现（Build） → 校准（Calibration）
这不是换个名字那么简单，而是把研发体系从"按岗位分工"，调整为"按价值流分工"。
一、为什么传统分工开始失效
先看一个事实变化：
在传统开发里，代码编写本身是主要成本，所以开发环节最重，其他岗位围绕开发协同。
但在 Vibe Coding 里，第一版代码的产生成本被大幅压缩，系统很快就能"看起来能跑起来"。于是项目的主要矛盾发生了转移：
- 不是没有代码
- 不是写不出页面
- 不是接口搭不起来
而是：
- 需求有没有被准确压缩成 AI 能稳定执行的输入
- 生成出来的结构是否可持续维护
- 缺陷是否能快速被发现、描述、修正和验证
- 项目是否能从"能运行"真正走到"能交付"
这意味着，过去那种以"编码"为中心的组织方式，开始出现几个明显问题。
1. 第一版很快，后续却很慢
AI 可以迅速给出首版系统，但首版并不等于成品。真正耗时的，通常是后续大量细碎而高频的调整：文案不准、状态不对、交互不顺、边界漏判、异常没兜住、接口口径不一致、组件行为跑偏。
这些问题如果还沿用"测试提单---研发修复---测试回归"的传统流程，沟通链路会被迅速拉长。
2. 问题不是写出来，而是收敛下来
AI 生成最大的优势是速度，最大的风险是随机性。
同样一句提示，不同轮次可能生成不同实现；同样一个局部修改，也可能误伤其他模块。于是团队真正需要的，不只是生产代码，而是建立一套能持续收敛偏差的机制。
3. 岗位职责还在旧世界，协作成本却进了新世界
如果每一个细小问题都要在产品、研发、测试之间往返流转，AI 提升的只是单点产能，不是系统效率。最终你会发现：代码生成速度上去了，但组织吞吐量没有上去。
所以，Vibe Coding 不是简单地"让开发更快"，而是逼着团队重新定义谁负责什么。
二、比起"谁写代码"，更重要的是"谁让系统交付"
如果把整个研发过程重新拆开，会发现更合理的分层其实是这三段：
- 设计：把模糊需求压缩成稳定输入
- 实现：把输入变成整体可运行的系统
- 校准：把能跑的系统拉到可交付状态
这三段并不是三道互相甩锅的工序，而是一条连续的收敛链路。
从这个视角看，团队里每个岗位的价值也会重新排序。
三、第一阶段：设计不是画图，而是降低生成随机性
在 Vibe Coding 里，设计阶段最重要的工作不是把页面"画漂亮"，而是把需求整理成AI 和人都能稳定执行的输入。
谁离业务目标最近，谁就最适合主导这一阶段。这个角色通常还是产品经理。
因为产品经理最清楚：
- 系统到底要解决什么问题
- 哪些功能优先级最高
- 哪些业务规则不能出错
- 哪些边界场景一旦遗漏就会出事故
- 什么才算真正验收通过
在这个阶段，设计质量直接决定后面生成质量。前面写得越清楚，后面偏差就越少；前面约束越扎实，后面返工就越低。
设计阶段真正要产出的，不是"文档"，而是"稳定输入"
一个可用于 Vibe Coding 的设计阶段，至少要沉淀出四类内容：
1. 功能规格说明
包括：
- 模块目标
- 核心业务规则
- 输入与输出
- 异常处理
- 数据口径
- 验收标准
这部分不是为了"写文档交差"，而是为了让后续实现和校准都有共同参照。
2. 可预览的 UI 原型
这里我非常赞成一个关键做法：尽量把页面原型直接做成 HTML 格式，而不是只停留在图片稿。
原因很现实。
静态图只能表达样子，HTML 原型更容易表达：
- 页面结构
- 组件层级
- 状态切换
- 动效意图
- 交互路径
- 提示文案
它既方便产品自己确认，也方便研发在实现阶段把它作为页面生成参考。相比只给一张视觉稿，HTML 原型能明显降低 AI 在页面实现上的跑偏概率。
3. 页面与交互说明
除了原型本身，还需要补上文字说明，尤其是：
- 页面入口和出口
- 关键按钮行为
- 状态变化条件
- 异常提示
- 空状态、加载态、失败态
- 权限差异和角色差异
很多项目不是做不出页面，而是页面"长得像"，行为却不对。问题往往就出在这一层没写实。
4. 验收口径
没有验收口径，就没有真正意义上的"完成"。
要明确：
- 哪些结果算通过
- 哪些问题必须修
- 哪些偏差可以接受
- 哪些指标必须达标
- 哪些场景必须覆盖
对于 Vibe Coding 来说，验收标准不是结尾才需要的东西，而是前置约束。
设计阶段的目标，只有一个
把模糊需求变成稳定输入，把后续生成的不确定性尽量消灭在源头。
这一步做得越扎实，后面的实现就越不是"碰运气"。
四、第二阶段：实现不只是生成代码，而是搭建受约束的生成流水线
很多人理解 Vibe Coding，会把实现阶段简单看成"让 AI 开始写代码"。
这其实低估了实现阶段的难度，也误解了研发在这个时代的价值。
因为 AI 能生成大量代码，不代表项目就会自然成型。真正决定系统质量的，仍然是这些工程层判断：
- 技术栈怎么选
- 模块边界怎么划
- 状态和数据流怎么组织
- 接口和领域模型怎么定义
- 错误兜底怎么做
- 公共能力怎么沉淀
- 后续修改边界怎么约束
所以，实现阶段依然更适合由研发主导。只是研发的角色已经不再只是"写代码的人"，而是系统生成方式的设计者。
实现阶段的核心，不是直接开写，而是先把生成过程流程化
比较成熟的做法，是走一套 spec-driven development 的工作流：先把规格、约束、计划和任务边界立住，再进入生成。
你提到的 spec-kit 思路就很适合放在这里。
它的价值在于：把原本一次性、易漂移的提示词，变成一组可以复用、可以继承、可以被后续引用的工程文档。
可以把这条链路理解成六步。
1. Constitution：先定宪章
先明确哪些原则不能碰，例如：
- 架构边界
- 命名规范
- 代码组织方式
- 质量门槛
- 安全要求
- 兼容性要求
- 可观测性要求
这一步相当于给 AI 先划红线。
2. Specify：把需求结构化
把业务需求转成结构化规格，明确：
- 用户故事
- 功能边界
- 输入输出
- 关键流程
- 验收标准
3. Clarify：把歧义提前问清楚
尽量在写代码之前，把模糊点、冲突点和缺失点解决掉。越早澄清，后面代价越低。
4. Plan：形成实现计划
这里不只是"准备怎么做"，而是把核心工程决策写实，包括：
- 模块结构
- 技术方案
- 数据模型
- 接口约束
- 权限策略
- 异常路径
- 日志与监控方案
5. Tasks：拆成明确任务单元
目的是为后续实现和校准建立修改边界，让每一块都知道"谁负责、改到哪、什么算完成"。
6. Implement：最后才进入代码生成
到了这一步，AI 才开始真正落代码，而不是一上来就靠一句大提示"帮我写个系统"。
为什么实现阶段仍然要由研发主导
因为真正的工程风险，不在"能不能生成代码"，而在"生成出来之后会不会把团队拖死"。
研发在这个阶段的价值，已经从"手写所有细节"转向了几件更重要的事：
- 定技术边界
- 控结构复杂度
- 保后续可维护性
- 给校准阶段留下可操作的修改空间
- 在 AI 失控时，知道应该往哪里拉回来
换句话说，研发不再是唯一生产者，但仍然是最关键的技术中枢。
五、第三阶段：校准，才是 Vibe Coding 下最容易被低估的主战场
如果说设计决定方向，实现决定骨架，那么校准决定项目能不能交付。
因为 AI 时代最常见的情况，不是"什么都没有"，而是"已经有了一个差不多能用的系统"。真正花时间的，是把这个"差不多"不断往"可以上线"推进。
这包括：
- 功能测试
- 缺陷复现
- 局部修改
- 提示修正
- 体验补齐
- 文案打磨
- 边界清理
- 回归验证
这也是为什么我非常认同：校准应该被单独拆出来，而且可以由测试主导。
为什么校准适合测试来主导
传统模式下，测试发现问题，提交给研发，研发修完，测试再验证。这套流程在手工编码时代是合理的，因为修复只能由研发完成。
但在 Vibe Coding 场景下，很多局部问题并不一定非得由研发亲自改。
测试本来就擅长几件事：
- 发现偏差
- 描述偏差
- 复现偏差
- 判断偏差是否被修正
- 做回归验证
而校准阶段的本质，恰恰就是持续发现偏差、描述偏差、修正偏差、再验证偏差。
从语言形态上看，测试提 bug 和校准提示词其实非常接近。它们都在回答同一类问题：
- 哪里不对
- 怎么复现
- 期待结果是什么
- 实际结果是什么
- 应该修到什么程度
这使得测试天然适合进入"直接与 AI 协作修正问题"的位置。
为什么把校准交给测试，反而可能更高效
因为这样可以直接砍掉大量无效沟通。
传统链路是：
测试发现问题 → 提单 → 研发理解 → 研发修改 → 测试回归
而在校准模式里，可以变成：
测试发现问题 → 直接结合上下文和 AI 修正 → 回归验证 → 必要时再升级给研发
只要实现阶段已经把上下文铺好，测试拿到的不应该只是一个仓库，而应该是一套完整的修改约束：
- UI 原型
- 功能规格
- 接口约定
- 计划文档
- 任务边界
- 架构约束
- 代码风格约束
有了这些，测试做的就不是"乱改代码"，而是在明确边界内做问题收敛。
什么时候测试能自己收，什么时候必须回到研发
这里很关键。校准能由测试主导，不代表所有问题都适合测试独立处理。
可以简单分成两类：
适合在校准阶段直接收掉的问题
- 文案错误
- 样式偏差
- 页面状态缺失
- 表单校验问题
- 明确的交互缺陷
- 局部接口适配问题
- 已知规则下的边界补齐
- 单页面或单模块内的细小逻辑修正
应该升级给研发的问题
- 跨模块结构冲突
- 数据模型设计错误
- 技术方案需要调整
- 状态管理架构不合理
- 接口协议本身不成立
- 权限体系设计问题
- 公共组件或基础能力缺陷
- AI 修改开始出现大面积失控
一句话概括：
局部偏差，校准收敛；结构问题，研发兜底。
六、研发、产品、测试三种角色，会怎样重新站位
在这种分工下，三个岗位的定位会发生明显变化。
产品经理：从"提需求的人"变成"输入设计者"
产品经理不再只是负责写 PRD，而是负责把业务目标压缩成 AI 和团队都能执行的稳定输入。
产品阶段做得越扎实，后面整个系统的随机性就越低。
研发：从"生产主力"变成"技术中枢"
研发依然关键，但关键点变了。
他的核心职责不再是自己把所有代码写完，而是：
- 选择技术栈
- 搭结构
- 立约束
- 设计生成路径
- 把公共能力先沉下来
- 在系统偏离结构时负责拉正
测试：从"问题转发者"变成"校准推进者"
测试不再只是缺陷的发现者，而成为系统交付阶段真正的推进者。
他们既做验证，也做收敛；既发现问题，也在边界内推动问题被直接消化掉。
七、真正值得调整的，不只是流程，而是团队配置
如果这套方式跑通，团队配置也不必再沿用过去那种"一条需求线配一套产品、研发、测试"的平铺模式。
传统模式里，常见是：
- 1 个产品
- 1 个前后端开发
- 1 个测试
每条线都复制一套人力，线性扩张。
但在 Vibe Coding 下，更可能出现的，是一种中枢式配置：
- 少量产品经理，负责需求压缩和规格定义
- 少量核心研发，负责技术底座和生成约束
- 更多测试，负责并行校准和交付推进
也就是说，团队的并行能力，未来未必主要来自研发人数，而可能主要来自测试侧的校准吞吐量。
一个更接近未来的组织方式
例如：
- 2 个产品经理
- 1 个核心全栈 / 技术负责人
- 8 个测试 / 校准执行者
这里的核心开发不是被削弱了，而是角色升级了。他不再作为每条需求线上的"人工编码器"，而是作为整个技术系统的设计者和纠偏者存在。
而测试则成为并行推进的主力：
- 按模块推进
- 按页面推进
- 按业务流程推进
- 一边验证，一边修正，一边回归
这样一来，组织吞吐量就不再被研发人数死死卡住。
八、这套模式真正改变的，是"生产关系"
很多人谈 Vibe Coding，容易把注意力放在工具层：模型更强了，生成更快了，IDE 更智能了，脚手架更高级了。
这些当然重要，但还不够。
因为软件研发从来不是单点工具问题，而是一个生产体系问题。
过去软件研发的生产力，主要取决于：
- 研发个人编码速度
- 团队人力投入
- 协作效率
而现在，AI 已经把"代码生成能力"整体抬高了一个数量级。很多原来要靠多人、多轮才能完成的实现动作，已经可以通过工作流和约束文档快速产出。
但这不意味着结果一定更好。
真正决定这波能力能不能释放出来的，不是模型演示效果，而是团队的生产关系有没有同步变化：
- 谁定义输入
- 谁控制结构
- 谁负责收敛
- 谁在什么边界内修改
- 问题如何回流
- 什么情况升级
- 谁对最终交付负责
如果这些关系不变，那么 AI 带来的速度提升，大概率会被以下成本吞掉：
- 沟通成本
- 返工成本
- 责任割裂
- 上下文丢失
- 多轮往返
- 局部优化带来的系统失真
所以，Vibe Coding 时代最本质的问题，从来不是"会不会生成代码"，而是：
当生产力已经跃迁之后，组织有没有能力重新组织生产关系。
九、和传统模式的差异，可以归纳成这张表
| 维度 | 传统研发模式 | Vibe Coding 模式 |
|---|---|---|
| 主要瓶颈 | 编码产能不足 | 交付收敛速度不足 |
| 开发角色 | 主要实现者 | 技术中枢与结构控制者 |
| 测试角色 | 提 bug、做回归 | 直接参与校准与问题收敛 |
| 产品角色 | 提需求、写文档 | 设计稳定输入与验收约束 |
| 协作方式 | 串行接力 | 连续收敛 |
| 文档作用 | 辅助沟通 | 直接约束 AI 生成与修改 |
| 第一版代码 | 相对较慢 | 通常很快 |
| 真正耗时阶段 | 实现 | 校准 |
| 组织并行能力来源 | 研发人数 | 测试侧校准吞吐量 |
结语
Vibe Coding 的意义，不只是让代码写得更快。
更大的变化在于，软件研发这件事的主战场已经变了。过去比的是谁写得快、谁堆的人多；现在越来越比的是谁能把需求压缩得更准、把系统结构搭得更稳、把交付过程收敛得更快。
所以，研发体系也必须跟着变化。
真正有竞争力的团队，不会停留在"让 AI 帮开发写代码"这一步，而会继续往前走：把设计、实现、校准三段重新组织起来，把产品、研发、测试之间的职责重新分配，把原本依赖个人经验的动作沉淀成可复用的工作流和约束体系。
到那时，Vibe Coding 才不只是一个演示能力，也不只是几个聪明人的效率工具。
它会变成一套真正稳定、可复制、可放大的生产体系。