Vibe Coding 时代，PM 和研发真的可以少吵一点了

本文来自微信公众号： 简写2019 ，作者：余子申

Vibe Coding时代，PM和研发的对接方式，正在悄悄变快

我越来越觉得，PM和研发之间的摩擦从来没消失过。

只不过以前大家吵的是“你没写清楚”，现在开始吵“你别瞎加功能”。

听起来像是抱怨升级了，但其实是好事。因为这意味着一件事：很多问题开始能更早暴露出来，而不是等到代码写一半才发现“根本不是这么回事”。

以前的对接，很多时候像“无实物表演”

传统流程大家都熟：

PM写PRD+画个静态原型（Axure/Figma）→需求评审→开发。

问题是，PRD再写得漂亮，静态图再画得精致，研发很多时候还是没法前置评估真正的坑在哪里。因为最关键的东西通常不在图上，也不在文字里，而在那些你没写、但系统一定会逼你回答的问题里，比如：

• 这个字段从哪来？

  
  

• 这个状态会不会出现？

  
  

• 异常怎么兜？

  
  

• 没权限的时候怎么表现？

  
  

• 数据没加载完用户点了怎么办？

  
  

于是评审会就变成一种“阅读理解”：

PM讲一遍，研发脑补一遍，问一堆“你这句话是什么意思”，然后回去改文档，下次再讲一遍。

开会开到最后，大家不是在讨论怎么做更好，而是在确认：我们是不是在讲同一个功能。

去年我在一家公司试过一套更“硬”的做法

去年在上一家公司，我开始试着在团队推行一种更快的对接方式：先把东西做出来，再写PRD。

先说清楚一个前提：我们当时是中小公司做内部系统（500个人的公司不算小），不对C端，也基本不涉及UI好不好看这种事。所以原型不是为了“画得漂亮”，而是为了把路径先走通、字段先想明白。

在这个前提下，我们做了几件很朴素的事。

1）不用Axure慢慢“画”，直接用Cursor搭HTML

PM不追求高保真，不纠结样式，直接用Cursor写个HTML页面，把页面骨架搭出来。

这一步最重要的不是“看起来像产品”，而是“能不能跑一遍”。

你只要真点一遍、填一遍、走一遍流程，很多模糊的地方就会自己跳出来：

• 哪些字段是必填？

  
  

• 空状态怎么显示？

  
  

• loading的时候能不能操作？

  
  

• 报错是贴字段还是全局提示？

  
  

• 有些按钮到底要不要禁用？

  
  

以前这些细节，可能靠一句“这里支持XX”就糊过去了。

现在糊不过去，因为页面摆在那，你得把流程走完。

2）开画之前，先把系统现状交代清楚

这里还有个很关键的小动作：PM开始搭之前，会先把系统现状说清楚。

不需要搞得很工程化，通常就是：

• 截几张现有关键页面

  
  

• 丢几段以前的PRD/说明文档

  
  

• 再补两句：“现在已经支持哪些功能，哪些还不支持”

  
  

• 如果更高阶一些的，可以把接口字段也发给Cursor；

  
  

这样做的目的很简单：让AI和研发先站在同一张“现有能力地图”上，再往上加需求。否则你很容易又回到老路：写了一堆愿望，最后发现系统根本接不住。

3）让AI基于代码，反向总结一份Markdown PRD

等HTML原型把主要路径跑通之后，我们会让AI做一件很具体的事：根据这套代码反推PRD。

重点不是让它写得好看，而是把几件事列明白：

• 页面涉及哪些字段（字段清单）

  
  

• 关键交互路径怎么走（步骤和分支）

  
  

• 会出现哪些状态（空、loading、失败、成功之类）

  
  

• 有哪些边界已经在原型里暴露出来

  
  

最后产出的是一份Markdown PRD。

它更像“归档”：把大家已经看过、已经点过的东西写下来，方便后面追踪，而不是靠文笔把一个还不存在的功能讲圆。

评审会最明显的变化：从“阅读理解”变成“现场拆解”

这套方式真正让我觉得值的地方，是评审会。

以前评审会像上语文课：

PM讲需求，研发问“你这句话什么意思”，然后大家围绕文字争论半天。

改成HTML原型之后，评审会变成：

大家直接对着页面走一遍流程。

你能感觉到对话重心变了：

不再是“我理解的对不对”，而是“这个东西怎么做更合理”。

一句话讲就是：以前是在对齐语言，现在是在评估结构。

当然也别神化：边界问题还是会冒出来，但性质不一样

有人肯定会说：你这也不可能一次把需求说完，研发写着写着还是会来问。

对，这很正常。

但差别在于：问题从“需求不清楚”变成了“细节怎么收敛”。这两种对接成本完全不一样。

边界情况是一定会出现的，尤其是内部系统，很多流程是人造出来的，越做越复杂。但只要大家是在同一个“可运行的东西”上讨论，PM和研发就不太容易变成对立面。

有人会问：那UX不也是提前画出来吗？

我觉得不一样。

UX提前的是体验稿，解决的是“好不好用”“清不清晰”“长什么样”。

但我们当时这个场景压根不怎么涉及UI，更多是在处理流程、字段、状态、权限这些事。

所以这里所谓的“提前”，不是把界面画得更漂亮，而是把需求变成一个能点、能跑、能暴露问题的东西，让研发能更早判断：这里会不会炸、成本大不大、要不要换个实现方式。

我对Vibe Coding的理解：它影响的不只是写代码

很多人聊Vibe Coding，焦点都在“AI写代码更快”。

但对我来说，真正改变的是协作方式：

需求不再从一堆文字开始，而是从一个可跑的东西开始。

PRD不再是起点，而是对共识的整理。

当PM能先把路径跑一遍、把字段想明白，

研发就不用在评审会上做阅读理解，

团队也更容易把时间花在“怎么做更好”，而不是“你到底想要什么”。

对中小团队来说，这可能就是最实在、也最值钱的效率。