夜雨聆风我的几个核心观点
- 人与AI的协作效率，远高于人与人之间的协作效率。
- 只把AI当成提效工具的人，未来一年很可能会失去职场竞争力。
- 那套产品写需求、研发接需求、测试验结果的软件研发流程，将不再适合AI时代。
- 产品经理不能再只做产品经理的工作，研发也不能再只做研发的工作。
- 未来真正具备职场竞争力的，将是具备产品思维的研发，或者具备全栈研发能力的产品经理。
一、我感触最深的一点：人和AI协作，效率太高
过去一个产品想法要往前走，通常要经过很多人。
产品经理先写PRD，画原型，找研发评审。研发看完以后提问题，产品再解释背景。评审过了，研发排期。开发完，测试再验。上线以后，大家才知道这个判断到底对不对。
这个过程最大的问题，不一定是谁做错了，而是太慢。
慢在哪里？慢在人和人之间的信息传递，理解对齐，沟通成本。
你要解释一次，对方要理解一次。对方理解错了，你还要重新解释。你以为自己说清楚了，别人可能理解的是另一个意思。一个想法还没真正被用户看到，已经在会议、文档、排期里来回走了好几圈。
AI把这件事改了。
现在你有一个想法，可以先让AI帮你拆场景、画页面、写接口、接数据库，做出一个真正能跑的服务。哪里不对，马上改。逻辑缺一块，马上补。体验不顺，马上重来。
这不需要写文档，不需要安排会议，不需要等排期，也不需要先把一个很早期的想法包装得很正式。
所以我越来越觉得，在很多早期探索环节里，人与AI的协作效率要远远超过人与人之间协作的效率。
二、只拿 AI 在原有的工作流程里提效，会慢慢失去职场竞争力
现在很多人用AI，其实还是在做原来的事。
产品经理让AI写PRD、改文案、总结竞品、整理会议纪要。研发让AI补代码、写注释、生成单测、解释报错。
这些当然有用，但这只是把原来的工作做快一点。
问题是，做快一点这件事，很快会变成基本操作。
一年后，很多产品经理都会用AI写文档，很多研发都会用AI写代码。到了那个时候，会不会用AI提效，已经不是优势，只是入场券。
真正的差距，不是你把原来的事情快了20%还是50%。
真正的差距是：你有没有用AI来做原来做不了的事情。
原来不懂技术的产品经理，能不能借助AI落地一个完整服务？原来不懂数据的人，能不能借助AI写SQL、看指标？原来只会写代码的研发，能不能让AI帮自己拆用户场景、判断产品价值？
如果AI只是帮你省时间，你还是原来的你。
如果AI帮你长出新的能力，你就已经不是原来的你了。
所以，如果你还在用AI在原有的工作流程里提效，那么未来一年很可能会失去职场竞争力。
三、产品经理要能把一个完整服务跑起来
我对产品经理的判断会更直接一点。
过去，一个产品经理不懂技术，是可以被接受的。因为公司默认你只要发现问题、写清需求、推动研发就行。
但AI出现以后，这个理由会越来越弱。
你不需要成为一名专业工程师，但你要能借助AI，把自己的想法变成一个真的能跑的服务。
这里说的不是做一个看起来像产品的页面。
而是前端能点，后端有接口，数据库能存数据，简单部署以后别人也能访问。哪怕很粗糙，哪怕代码还不漂亮，但它是活的，能真正解决用户问题的，不是一张图，也不是一份文档。
比如，一个用户提交表单后，数据能不能真的写进数据库？一个订单状态变化后，页面能不能真的更新？一个后台操作后，前台能不能马上看到结果？这些过去都要等研发，现在产品经理可以借助AI跑通。
以前产品经理拿着PRD去评审，大家讨论的是“这个需求到底什么意思”。
以后的产品经理，可能是拿着一个跑通的完整服务去讨论：这个方向值不值得继续做。
这两种人，或许职位都叫产品经理，但能力已经不一样了。或许未来会有新的职位来区分这两种人。
一个还在等别人理解他的想法。另一个已经用AI把前端、后端、数据和流程都试了一遍。
四、研发也不能再只会接需求
研发的变化也一样。
过去很多研发会把自己的边界划得很清楚：产品给需求，我负责实现。需求不清楚，是产品的问题。用户不买账，也是产品判断的问题。
这套说法过去说得通，以后会越来越说不通。
因为AI会让写代码这件事变得没那么稀缺。真正稀缺的研发，不只是能把需求写成代码，而是能理解问题、判断方案、顺手把东西做出来，还能借助AI快速验证。
我认为未来更有竞争力的研发，一定要有产品思维。
他不会只问“需求文档在哪里”。他会问：这个功能解决谁的问题？为什么现在要做？最小版本是什么？有没有更简单的做法？有没有更快的验证方式？
过去研发的强项是实现。未来研发的强项，会越来越像“把一个模糊问题变成可运行方案，并借助AI快速验证”。
五、过去二十年的产品研发流程，会被重新洗牌
过去的流程很清楚：产品写需求，研发做功能，测试验结果。
这套流程能跑，是因为大家默认每个人只能做自己那一块。
产品不会写代码，所以只能写需求。研发不负责需求洞察和需求定义，所以只能接需求。测试后面进入，所以只能等功能做完再验。
AI改变的是这个前提。
当产品经理可以借助AI跑通完整的服务，可以借助AI生成完整的测试用例，写完整的测试脚本，那过去的产品研发流程就失效了。
以后很多需求不会再从一份完整PRD开始。
它可能先从一个人和AI跑通的小服务开始。页面能点，接口能调，数据能存，别人也能访问。大家看完以后，再决定要不要投入更多研发资源。
这不是说团队协作不重要。恰恰相反，团队还是重要的。
只是团队不应该再把大量时间花在“听懂对方在说什么”上，而应该把时间花在“把已经验证有价值的东西做好”上。
六、未来更值钱的，是全栈型产品经理和产品型研发工程师
所以我对未来一年的判断很简单：只守着原岗位边界的人，会越来越被动。
产品经理不能只会写需求。他要能借助AI打通前端、后端、数据库和部署，把想法先推到可以验证的状态。
研发也不能只会接需求。他要能理解用户、理解业务、判断方向，把模糊想法变成更靠谱的方案，还能借助AI快速验证。
未来更值钱的人，会是两类。
一类是具备全栈研发能力的产品经理。他不一定是顶级工程师，但他能借助AI像研发一样把服务跑起来，还能借助AI快速验证。
另一类是具备产品思维的全栈研发。他不只是写代码，还能判断这个东西为什么做、怎么做更简单、怎么更快验证。
我不觉得这是很远的未来。
一年后，这可能就会变成很多团队对候选人的基本期待。
最后：被淘汰的将不会是岗位，而是岗位边界
AI不会简单淘汰产品经理，也不会简单淘汰研发。
真正会被淘汰的，是只像产品经理的产品经理，和只像研发的研发。
只会写PRD、开评审、推排期的人，会越来越像一个信息中转站。只会接需求、写代码、等验收的人，也会越来越像一个执行节点。
而AI时代更强的人，会同时具备两种能力：能判断问题，也能推进结果；能理解用户，也能理解实现；能提出想法，也能先把一个完整服务跑起来试一遍。
过去二十年，产品研发靠分工提高效率。
接下来，过度分工本身会变成效率问题。
这就是我认为产品研发体系会被推倒重来的原因。不是因为AI让我们写文档更快、写代码更快，而是因为它让一个人可以从想法一路走到一个能运行的服务，并借助AI快速验证。