我花5年从开发转岗产品，结果AI开始拆掉这道墙

5年前，我做了一个决定：从后端开发，转去做产品经理。

那时候的我，其实挺拧巴的。

一边觉得自己懂技术，做产品应该有优势；

一边又特别怕别人心里给我贴个标签：

“哦，他不就是个会写点代码的产品吗？”

这种不安全感很真实。

所以那几年，我补了很多课。

我不是那种“觉得自己以前做过开发，所以做产品天然降维打击”的人。恰恰相反，我那会儿很想把自己重新打磨成一个“标准产品经理”。

我会逼着自己去看各种资料，研究流程、需求管理、PRD、版本节奏、跨团队协作。

我想搞清楚一件事：

一个专业的产品经理，到底专业在哪？

产品和开发的职责边界，到底该怎么划？

需求写到什么程度，才叫合格？

什么是产品该管的，什么又不该越线？

就这么一路补，一路做，一路纠偏。

直到近一年，我终于进了新公司，成了一名很“纯”的专职产品经理。

按理说，故事到这里，应该是我终于打怪升级成功，站稳了。

但很怪。

就在我觉得自己终于把这套岗位游戏规则摸明白的时候，我反而开始感到一种很强的唏嘘。

因为我突然发现，那堵我花了好几年才学会站稳的墙，AI 正在把它一点点拆掉。

我最近打开招聘软件，经常会看到一些很微妙的变化。

前端岗位，不少已经变成了“前端全栈工程师”，JD 里会直接写：

“具备产品思维。”

另一边，“AI 产品经理”这种岗位，越来越常见的一条要求是：

“有计算机背景优先。”

再往外看，社交平台上开始出现大量“不会写代码的人”，用 Vibe Coding 做出一个个能跑的应用，然后高高兴兴发出来。

你很难说这只是一个工具升级。

我的感受更像是：

以前产品和研发之间，有一堵特别结实的墙。大家都默认，墙这边的人负责想，墙那边的人负责做。

现在 AI 像一阵很猛的风吹过来，那堵墙没完全消失，但已经开始塌了。

这件事对我触动很大。

因为我当年转岗，本质上就是在学习怎么适应这堵墙存在的世界。

而现在，世界规则在变。

以前边界清晰的时候，产品经理到底都在忙什么？

如果粗暴一点总结，我现在的答案是：

本质上，产品经理在很多团队里，干的是“对抗信息损耗”的活。

这句话我以前说不出来，是这两年越做越清楚的。

我们为什么要写 PRD？

为什么一个按钮文案都要掰开揉碎？

为什么状态、边界、异常、权限、流程、埋点都要交代得清清楚楚？

因为怕失真。

怕业务说的是一回事，产品理解成另一回事；

怕产品脑子里想的是一回事，写到文档里又变成另一回事；

怕开发看完文档，结合自己的经验，再“合理发挥”成第三回事。

到最后，真正跑出来的东西，可能已经不是任何一个人一开始想要的那个东西了。

所以我后来越来越觉得，很多产品经理的日常，其实不是在“创造”，而是在给这个系统不停补缝。

我自己给它起过一个很土但很好记的名字，叫：

“信息损耗定律”。

你脑子里本来有一个 100 分的方案。

你把它写成文字，可能只剩 80 分。

研发读完文档，再结合自己的理解、项目限制、时间压力和上下文缺失，最后落进代码里的，可能只剩 60 分。

这 40 分是怎么没的？

不是谁故意搞砸。

是它天然就会损耗。

人和人之间靠语言传递意图，本来就有折损。

岗位越多，链路越长，折损越大。

于是产品经理慢慢就成了团队里那个最像“人肉路由器”的人。

今天跟业务对齐，明天跟研发补上下文，后天再跟测试解释一遍为什么这里不是 Bug 是需求。

很多精力，不是在做判断，而是在搬运、解释、校准、返工。

说白了，很多团队里所谓“专业的产品工作”，本质上是在修复一条高损耗的信息传输链路。

我做久了之后，有时候开完一轮很长的对齐会，脑子里都会冒出一个问题：

我们这么多人，花这么多时间，只是在努力把一件本来应该说得清的事，说得没那么歪。

这种工作，到底有多少是真正不可替代的？

也是在这个阶段，我才真正感受到 AI 的冲击力。

很多人说，AI 最大的变化是“开始写代码了”。

我的感受不是这个。

AI 真正击穿的，不是写代码本身。

它第一次大规模压缩了“意图 → 文档 → 代码 → 产品”中间那条高损耗的翻译链。

这才是可怕的地方。

以前你有一个想法，要先把它翻译成需求文档；

开发再把文档翻译成代码；

代码跑出来以后，大家再一起看结果是不是接近最初的想法。

现在不一样了。

你可以直接把你的目标、约束、场景、预期结果，一口气喂给 AI。

它未必一次就对，但它已经可以在很大程度上，跳过过去那种层层转述、层层失真的过程。

这意味着什么？

意味着以前很多靠“中间翻译”存在的工作内容，会被压缩。

不是说产品经理没了。

也不是说开发没了。

被压缩的，是那些纯靠岗位边界存活的中间动作。

把一个很直接的业务目标，翻译成一堆格式正确但信息依然不完整的文档

把一个很小的想法，排进一个漫长的需求流转里

为了改一个不复杂的交互，来回开三轮会

明明知道问题在哪，却因为“这不是我的职责范围”只能继续传球

这些事，以前大家都觉得合理。

因为工具不够强，组织必须靠分工运转。

但 AI 一进来，很多默认合理的流程，突然变得很笨重。

你开始意识到：

原来有些事情不是天然需要这么多人接力，

只是过去没有更好的方式。

这两天我反复在看 Gergely Orosz 写的一篇文章。

他提到一句话，我特别有共鸣：

产品管理和软件工程的重叠，会比以往任何时候都更多。

我认同。

因为在老工作流里，产品负责把业务意图转成文档，开发再把文档转成机器能执行的代码。

大家都在“翻译”。

可一旦 AI 能直接参与甚至承担相当大比例的编码工作，整个链条就会变短。

你会发现，IDE 开始越来越像“代码浏览器”，而不只是“代码编辑器”。

你会发现，产品经理不只是能画原型，有时候已经可以自己把主流程跑起来，拿给客户演示。

你也会发现，开发不再只是“接单写实现”，而是越来越需要提前介入问题定义、架构取舍和用户体验。

这时候，很多过去靠岗位分工维持的边界，就开始松动了。

所以我现在更愿意说：

AI 不是在把产品经理变成工程师，也不是在把工程师变成产品经理。

它是在逼所有人重新面对一件事：你到底是在解决问题，还是只是在扮演工种。

这两者差别很大。

很多人看到这里，会本能地问一句：

那工程师会不会被削弱？

我的答案很直接：不会。

但工程师值钱的地方，确实变了。

以前写得快、写得多，本身就是能力。

现在代码供给开始被 AI 放大，真正稀缺的东西反而往后移了。

谁来兜架构？

谁来判断哪些非功能需求不能被一句“先做出来再说”带过去？

谁来做测试策略、回滚机制、可观测性、性能边界、权限控制？

谁来压住技术债，不让系统在表面飞快生长的同时，底座烂穿？

这些事，AI 现在远远接不了盘。

所以我的逻辑一直很简单：

代码会越来越便宜，系统判断会越来越贵。

这也是为什么，我一点都不觉得“软件工程死了”。

它不是死了。

它只是从“产出代码”这件事，往“约束代码、验证代码、维护系统完整性”这件事上迁移。

以前很多人把工程师理解成“写代码的人”。

以后，这种理解会越来越窄。

真正的工程师，价值从来不只是手速。

而是你能不能在一个复杂系统里，知道哪里能快，哪里绝对不能快。

那产品经理呢？

说实话，我对这个岗位的感受，也在变。

以前我很想证明自己“是个专业产品经理”。

现在我越来越觉得，如果一个产品经理的核心竞争力，只剩下会写 PRD、会排需求、会拉对齐会，那会很危险。

因为这些动作里，有很大一部分，本来就是旧工作流为了降低信息损耗而发明出来的中间层。

一旦翻译成本下降，这些动作的价值就会被重新定价。

产品经理以后还重不重要？

当然重要。

但重要的地方，不再是“我比谁更会写一份格式规范的文档”。

而是：

• 你能不能定义清楚问题
• 你能不能看懂用户到底卡在哪
• 你能不能把模糊需求拆成 AI 和人都能执行的任务结构
• 你能不能判断什么是伪需求，什么是高价值路径
• 你能不能对结果负责，而不是只对流程负责

我甚至会觉得，AI 时代最危险的，不是你不懂提示词，不懂 Agent，不会调 API。

最危险的是，你还把自己理解成流水线上的某一个固定工种。

因为一旦你只会工种动作，不会问题闭环，你就会越来越被动。

作为一个从开发转去做产品的人，看着这两个岗位慢慢重新靠拢，我现在的感受已经不是焦虑了，反而更像一种释然。

以前我总觉得，自己得先证明：

我不是“半个开发”，

我得成为一个足够标准、足够像样、足够专业的产品经理。

现在回头看，我花很多力气追的，可能只是上一代分工体系里的“标准姿势”。

而 AI 来了之后，我突然意识到一件事：

我们真正值钱的，从来不是站在哪个岗位上。

而是能不能把一个模糊的念头，推成一个真的可用的东西。

这个过程里，懂用户的人有价值。

懂系统的人有价值。

懂边界、懂取舍、懂验证的人更有价值。

反而那些只负责在链路里转述、传球、补话的人，会越来越难受。

这也是我最近最强烈的一个感受：

AI 并没有先淘汰产品经理，也没有先淘汰工程师。

它先压缩掉的，是产品和研发之间那层高损耗的翻译层。

墙还没完全没了。

很多公司里，它甚至还会存在很久。

但裂缝已经出来了。

而且一旦你看见那道裂缝，很多过去默认合理的流程、边界、岗位执念，就再也回不去了。

我现在偶尔还是会想起5年前那个拼命想成为“专业产品经理”的自己。

如果让我重新对那时候的自己说一句话，我大概不会说“你该更早学 AI”，也不会说“你应该早点去做全栈”。

我可能只会说：

别太迷信岗位边界。

你真正该死磕的，从来不是像不像某个角色，而是你有没有把想法推到现实世界里。

至于产品和研发，未来到底会不会真的变成一个岗位？

我不知道。

但有一件事，我现在越来越确定：

谁还把自己当成流程上的一个节点，谁会先难受。

谁能同时看见用户、系统和结果，谁就会先尝到下一轮红利。