需求爆兵：互联网传统业务不可能实现的目标

一、 我一直认为，AI 时代对于互联网传统业务来说，最大的红利是代码变得更廉价，可以进行更多更敏捷业务尝试，“技术资源不够用” 不再成为阻碍。 大概从 2020 年开始，互联网公司排着队一家接一家走入了深水区。深水区意味着明确的增长方向开采殆尽，潜在的机遇沉在深水里，可能往某个方向游很久，也不确定那边有多大收益。宝贵的研发资源不知如何投资，便投资在了令老板兴奋的大跃进项目上，结果众所周知。 那么，一旦代码变得廉价，是不是就可以同时投资多个 “不确定收益” 但 “有可能有收益” 的方向呢？用多点下注来分散投资失败的风险，又不会增加更多的研发人力。 我对这件事相当兴奋，自认为在 “满足用户价值” 和 “预判演化潜力” 两方面都很厉害，擅长沿着满足用户价值的路径，选择几个演化潜力最好的方向下手，就是缺研发资源，这辈子都缺研发资源，大量的产品方案烂在手里都没机会上线。既然 AI 时代程序员纷纷表示 3X 5X 10X 效率，是不是我的所有产品方案都可以爆兵上线呢？ 白日做梦。 我在犬校做过一轮调查，传统互联网项目的需求上线并没有明显加速。 程序员：3X 走起！5X 甚至 10X 走起！ 产品发版：没有明显变化…… 二、 5 月我和产品拍档聊到未来的互联网职业演化方向，如果现在这种协作方式做不到需求爆兵上线，还有什么思路呢？ 有的。三大职业都需要作出脱胎换骨的改变。 设计师： 现在用 Figma 做视觉稿已经有点过时了，更流行的是视觉稿直接生成 HTML，方便 AI 修改。从这个角度出发，UI 设计师以后可能会演化为组件设计师，生成各种 HTML 组件供团队调用，设计师自己也可以参与前端代码的完整实现，或是调试少量复杂的 HTML 页面视觉。 程序员： 演化为全栈工程师，不再受技术栈的束缚，这点行业已有共识。未来的程序员需要增加一个新的职能：为需求工程师搞好基建环境，提供技术支持，帮助需求工程师高质量高效率地完成任务。 产品经理： 那么需求工程师是谁呢？显然是我们产品经理，在全栈工程师提供的基建支持下，需求工程师调用组件设计师的组件直接写代码。简单的功能由需求工程师直接写，复杂的功能交给全栈工程师。新版本先做出来再说，老板 上手用了以后再下判断（是否允许发版）。 全栈工程师在发版前给代码质量兜底。 最终产品/研发/UED，恐怕都是三选一，每个职能合并为一个岗位，每个岗位三个人里边留一个就可以了。这个残酷的未来并不会太快实现，因为老团队革不了自己的命。比如说 程序员为提效做得越多，程序员的 HC 越少，纯属自杀行为。拒绝自杀可以有很多理由来搪塞，老板一时半会儿也强迫不了。与此同时，市场缺乏新需求，孵化不出来多少新团队。 行业接受被 AI 改造的协作新范式，还需要漫长的过程。 三、 二季度，我到处了解别的公司需求爆兵的有效实践，他们是怎么做到的？ 已知的关键约束有两个：

• 新项目，新代码，用 AI 从头构建适合这个项目的技术架构，不受老代码的历史拖累。
• 1、产品经理和 UI，和一部分轻量级开发任务合体，2、前后端程序员合体，3、1+2 职能精简。

如果是老项目，AI Coding 融合到老项目代码有很高成本，历史债太多，往往不能显著加快开发效率，产品经理 Vibe Coding 也很难介入。 还有程序员表态：我可以提效但我为什么要提效？为了资本家发现其实不需要那么多程序员吗？ 技术主管对此也没有很强的动力，哪怕老板急于提速——线上代码出了问题谁来承担责任？你还是我？ 因此，AI 加速 Coding 是一回事，需求上线速度不变是另一回事。 对于老项目来说，如果强求需求爆兵，方法有点残酷，你可能需要相当粗暴地对待程序员，强行打碎原有的工作习惯，用新的一套 KPI 来牵引他们改变。高自尊的技术人才会选择离开，你也接受这部分损失。尤其重要的是，一定得有一个强势的，懂业务也懂 Coding 的人操盘改革。

• 懂业务才能做到需求（而不是政治）驱动改变
• 懂 Coding 才能反弹程序员花样百出的的推诿
• 有权力才能逼迫别人服从

然而技术主管不懂业务，产品主管不懂 Coding，老板啥都不懂。如果有一个人业务和 Coding 都熟，那么他很可能没有权力。 这方面（老业务爆兵）的有效实践，犬校仅有一例，的确是罕见的能力和权力的组合。 四、 我在思考需求爆兵这件事的时候，最难过去的一关，是怎样和程序员、设计师达成一致的目标。 产品经理作为需求发起方，天然拥抱需求爆兵（混日子的忽略不计），但对程序员和设计师来说，爆兵一方面为自己亲手挖坟，走向被裁员的未来；另一方面可能也缺乏过去打磨代码与设计的成就感与成长值。 除非是小规模的新团队，尤其是 AI native 新业务，对于业务成长有着一致的目标，否则技术&设计团队内部 “谁爆兵，谁工贼”。 如果爆兵对研发&设计部门完全没有好处，全部都是坏处，自然会按惯性遵古法运行。 长期来看，拥抱 AI 让程序员和设计师的职业未来模糊而暗淡。 在这个前提下，老项目老团队对于爆兵有八百种方式推诿。我找不到任何理由说服他们参与产品经理的爆兵大业——关我屁事？我为什么要把自己的脖子用绳子挂在树干上？ 事实上，爆兵必须有程序员和设计师积极的支持。UI 交互设计师合体转型为组件设计师，前后端程序员合体为全栈程序员，两边合力给需求工程师——也就是未来的产品经理提供支持，三个角色流畅衔接。 如果你无法和程序员、设计师达成一致的目标，即便用暴力的管理手段来压制，也只能得到一些被动的疲惫的消极的响应。 五、 我想来想去，都想不到什么办法可以在老项目老团队里，与程序员、设计师组建新家庭。对他们完全没有好处，全部都是坏处。 AI native 的新业务新团队倒是孵化了类似的组合， 创始人自己必然是那个懂业务，懂 Coding 的操盘手。同时创业团队人数精简，精简到成员不担心自己被开掉，而是担心公司垮了我还得找下一份工作。在这种心态下，程序员和设计师会更积极配合老板发起的工作范式迭代。 但 AI native 的 少数实践没有任何的扩散力，他们甚至还没有证明自己能长期存活下去。 在过去，先进的组织形态和先进的产品业务互相促进，借助成功光环向行业扩散，比如 OKR。但这一次的成功实践极少而阻力极大。 你面对的阻力，是一整个研发&设计部门守旧，甚至保命的激烈情绪。 需求爆兵带来的裁员潮，迟早也会平等地惠及产品部门，三个里边留一个做需求工程师就好。 因此，我对于互联网裁员潮到来的预期比过去乐观多了，一方面，范式改革的阻力特别大，另一方面，收益也没那么诱人。新贵没几个，老公司又没有强烈的动力去改变现状，只要表示出 “我们已经拥抱新技术了” 的姿态给老板看就能过关。事实上需求上线的确快了一丢丢，距离爆兵还很远，但老板对爆兵也没什么愿力。 也许爆兵只不过是我这种永远缺程序员的产品经理的愿力。 这里就找到另一个关键卡点了，爆兵（快速上线/快速迭代/快速试错）对老板来说并没有显著的好处，更大更确定的收益才能撬动老板的热情。如果是老板在意的项目，他用传统管理手段就能压迫产研团队快点上线。如果是深水区里收益不确定的项目，既然收益不确定，老板其实不着急的，着急的是想做这个项目的产品经理。 因此爆兵既不能自上而下，更没法自下而上。 换个角度看，爆兵利好我这种创造力强的 PM，但 “三个留一个” 的未来对行业里的大多数人来说都太残酷了。渴望爆兵的我也是工贼，渴望打破现状但给不了其他人一条出路（活路）。 六、 犬校同学 Mellos 对此有精彩的回复—— 这就是之前读过的「发电机悖论」了，真正需要的是组织结构的完全重塑，在已有结构上做优化都不如推倒重来。 19 世纪末电动机刚问世时，工厂的老板们们非常兴奋，但他们做的事情和我们今天很像： 第一阶段（物理平替/组驱动）：工厂主们舍不得拆掉原有的多层厂房和复杂的传动皮带网络，只是简单地拆掉中央蒸汽机，原位换上一台大电动机，结果发现由于动力传输结构没变，摩擦损耗依然严重，一旦电机故障，全厂照样停工。在长达 30 年的时间里，这种电气化并没有带来任何生产率的提升。这就像在老项目、老团队里硬塞 AI Coding，我们保留了 “PM-UI-前端-后端” 的旧有分工和考评体系，只是让程序员用 AI 多写几行代码。这种 “物理平替” 不仅没有带来 “需求爆兵”，反而带来了巨大的系统摩擦和防御情绪。 第二阶段（分布式/单元驱动）：直到几十年后，人们才意识到应该把动力分布式化，拆掉所有天轴和皮带，给每一台机器安装独立的小型电动机，彻底解放了工厂的物理布局。工厂从多层垂直建筑变成了单层平铺，机器完全按照物料流动的业务逻辑直线排列，这才诞生了亨利·福特的现代流水线，生产率随之迎来了数十倍的爆发。正好对应了你文中设想的终极状态：UI 转型为组件设计师、前后端合体为全栈、与需求工程师（未来的PM）紧密咬合。这种由分布式动力（AI）催生的全新组织形态，才是释放生产力的唯一解。 但正如历史所揭示的，旧工厂很难自己拆掉那些旧皮带。真正的变革往往也不是在旧工厂里发生的，而是在那些直接采用 “分布式单机传动”（新团队、新代码、极简职能）的新工厂里野蛮生长出来的。 我很悲观，以往这种变革都需要一两代人的时间，从 1839 年第一次鸦片战争到 1905 年科举取消用了 60 多年，从垂直式到分布式用了 30 多年。这波 AI 也许比历史上所有技术变革带来的组织重塑都要快，这波要多久？5年？10年？我不知道答案。 《纯银的产品分析》专栏已更新 210 篇， 7.27-8.8 期间七折促销： 「纯银的产品专栏」2026 年打折倒计时开始 扫码可直接订阅专栏。