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