从手工调研到自动化工作流，AI产品经理的岗位内核正在经历一场静默革命。本文作者通过四次关键转变，揭示了AI如何重写产品经理的工作方式：从替代脏活累活的初级应用，到自主构建工具链；从苦练prompt技巧到建立AI驱动的交付体系。当原型设计先于PRD、判断力取代执行力的新时代来临，传统产品方法论正在被彻底重构。
如果你看过我上一篇《从传统制造到 AI 产品经理：29 岁，我用半年完成从零转型》，那你应该会知道，我之前写的更多是“我是怎么走到这个岗位上的”。
那篇文章里，我写了自己为什么离开传统制造，为什么会被 AI 这股浪潮推着往前走，也写了这半年里我是怎么靠一个个项目、一点点实践，把自己从原来的工作惯性里拽出来，最后真正拿到一份 AI 产品经理的工作。那篇文章更像一段转型复盘，讲的是选择、冒险、试错和跃迁。
但真正入职以后，我很快意识到，拿到一个新的职位并不意味着真正理解这份工作。因为当我真的坐到这个岗位上，开始用 AI 去处理日常业务、推进需求、做调研、想方案、出概念、拉原型的时候，我才发现这份工作的变化比我想象得更彻底。它不是简单地在原来的产品工作流里塞进一个 AI 工具，而是在反过来重写整套工作方式。很多过去默认应该由人亲自完成的动作，现在都开始显得笨重、迟缓，甚至有些多余。
如果现在要我给 AI 产品经理下一个尽量朴素的定义，我会把它理解成两层。第一层是用 AI 工具开展业务，让它真正进入调研、分析、方案、原型和交付这些日常工作里；第二层是做 AI 相关的产品，去理解模型能力、用户场景、成本边界，以及这些能力到底该怎么落进具体产品。前者决定你怎么工作，后者决定你做什么。也正因为这两层同时存在，所以 AI 产品经理并不是给传统产品经理换一个新名字，而是一个连工作对象和工作方式都在一起变化的角色。
所以这篇文章，算是上一篇转型故事的后续。上一篇更多在讲我是怎么走到这个岗位上的，这一篇想写的，则是当我真的开始以 AI 产品经理的身份工作时，这份工作的内核到底变了什么。对我来说，AI 产品经理最值钱的能力，不是更会写 prompt，而是更会定义工作流、组织 AI 产出，并对结果负责。
一开始我并不是这样想的。刚开始把 AI 用进日常业务时，我的兴奋点其实很朴素：终于有一个工具，可以帮我搜资料、写文案、出方案了。那时候我的工作方式，和现在很多人还在重复的动作差不多。开着 ChatGPT 这类网页对话框，把我要调研的问题一句句发过去，看它吐出一段结论，再顺手点开它给的引用资料，自己继续往下追。它回答得不够准，我就继续补问题；它回答得太散，我就继续缩范围；它没打到我真正想知道的点，我就换一种说法再问一次。
表面上看，这已经比纯手工查资料快很多了。但做久了以后，我会有一种非常明显的疲惫感：我看起来是在用 AI，实际上只是把原来自己做的信息搜集工作，拆成了无数轮更零碎的人机对话。我还是那个最累的人。方向要我自己想，框架要我自己搭，问题要我自己追，最后再由我把那些碎片拼成一个结论。AI 只是被我塞进了某个关键节点，替我搬了一点砖，但整个工作流依旧是人扛着走的。
我真正开始意识到这件事，是在做市场调研的时候。那次我要研究一个品类，最开始还是老方法，把问题丢进聊天框里，读它的答案和引用，再根据它给出的内容继续追问。这个过程一开始会让人产生一种“效率很高”的错觉，因为你确实比从前少打开了很多网页，也少做了很多人工整理。但只要任务稍微复杂一点，比如你不是想知道一个零散事实，而是需要一份成体系、能拿去支撑决策的调研，问题就会暴露得很明显。单点问答式的数据获取，效率其实很低。你永远在对话框里追着信息跑，而不是让信息主动按你的目标组织起来。
后来我开始改用 Deep Research。这个变化看起来只是“换了一个功能”，但对我来说，它第一次让我感受到什么叫真正的提效。因为我不再需要扮演那个不停追问、不断补洞的人了。我只需要把需求讲清楚，让它围绕这个目标去做细、做全、做深。那种感觉非常不一样。以前是我带着 AI 一步一步走，现在变成了 AI 带着一整套搜索、筛选、验证、汇总流程走完一圈，再把结果端回来给我看。我从“信息采集员”变成了“结果判断者”。
这件事后来给了我一个非常清楚的判断：我真正发挥价值的，不应该是不断想下一个问题是什么，而应该是判断最后这个结论能不能支撑业务决策。我的大脑不该被浪费在没完没了的初筛和拼接上。凡是那种需要我苦思冥想找方向、搭框架、补问题的工作，本质上都不该继续由我来主导。AI 应该先给我一组可判断的结果，我只负责做选择题和判断题，而不是永远亲自下场写论述题。
如果说调研这件事，是我第一次意识到“使用 AI 的方式比是否使用 AI 更重要”，那么后面做产品 ID（产品外观设计）图的经历，则让我第一次真正开始为自己的工作流造工具。
那时候我需要让 AI 帮我设计产品的 ID 方案。最开始我还是老老实实守在 Gemini 的网页前，一遍遍写需求，一遍遍等它出图，一次只生成一张。结果不符合预期，就继续改，再继续等。那个过程最折磨人的地方，倒还不只是效果好不好，而是整个动作本身太慢了。你会被一个网页界面绑住，被一次一张的生成节奏绑住，也被没完没了的等待绑住。很多时间并没有花在思考上，而是花在重复点击、反复试错和干等结果上。
我后来实在受够了这种低效。既然网页端一次一张、反复守着等的方式太慢，我就直接换了一个思路：不用网页了，让 AI 编程工具帮我写一个接入 Gemini API 的批量生图桌面软件。这个变化对我的冲击很大，因为它第一次让我从“使用一个现成工具”变成了“为自己的工作流造工具”。以前我必须守在网页前，一张一张试；后来我只要把需求输进去，点一下，后台就可以批量生成很多候选图。我不需要再被一个界面绑住，不需要反复点击，也不需要把大量时间耗在等待上。我去做别的事情，回来之后，一整批结果已经在文件夹里等我筛选。
这个工具解决的，主要还是执行效率的问题。它让我从繁琐、重复、低速的操作里解放了出来，也让我第一次意识到：产品经理不一定只能适应工具，也可以反过来让工具适应自己的工作流。
但更大的变化还在后面。造工具解决的是执行效率，真正让我岗位认知继续往前走的一步，是我开始把“理解需求、组织上下文、生成指令”这件事也交给 AI。
批量生图已经比手动点网页快很多了，可我很快又碰到下一个瓶颈：哪怕生成效率提高了，只要提示词还是由我自己硬写，我还是会卡。因为写提示词这件事，本身仍然是在让我做低价值的翻译劳动。我还是得把脑子里那堆关于产品定位、用户场景、结构特征、风格倾向的想法，压缩成一段尽可能准确的描述，再寄希望于模型能从这段描述里还原出我想要的东西。
后来我终于把这个动作也砍掉了。我不再自己一点点写生图 prompt，而是直接把PRD（产品需求文档）和我想要的 ID 效果参考一起交给 Codex 这样的AIAgent。我告诉它：你去读文档，你去理解我要做的产品，你去分析参考图里的风格，然后你自己构思提示词，自己调用 Gemini API，生图并检查结果，把符合要求的结果整理成文档回复我。到这一步，我第一次觉得自己不再是在“使用 AI 功能”，而是在“组织一个 AI 工作流替我完成任务”。
这里面的差别非常大。前一种方式里，我还是那个把每个环节亲手串起来的人；后一种方式里，我只负责定义目标、提供约束、判断结果。以前我总在问“这句 prompt 还要怎么改”，后来我开始问“这个工作流是不是还让人做了太多不该做的事”。这两个问题看起来只是措辞不同，但背后其实是两种完全不同的岗位认知。
也是从那个时候开始，我越来越确定一件事：AI 产品经理真正拉开差距的，不是会不会写 prompt。至少对我来说，写 prompt 顶多只是一个很早期、很过渡的能力。真正重要的，是你能不能把业务目标拆成一个合理的工作流，知道哪些环节该由 AI 做，哪些环节必须由人保留判断，哪些中间劳动应该被彻底消灭掉。你不是在教 AI 按你的每一句话做事，而是在定义一套系统，让 AI 自动把该做的事做完，再把值得你看的东西交到你面前。
再往后，我连做产品的顺序都改了。传统产品经理的流程，通常是先写 PRD，把需求、逻辑、流程和边界尽量定义清楚，再交给设计和研发往下推进。但我现在很多时候的做法，已经变成了另一种顺序：先和 AI 反复沟通产品需求，让它直接把原型做出来，边做边看，边看边改，直到那个东西越来越接近我真正想要的效果。
等原型在一轮轮迭代里逐渐稳定下来之后，我才会让它回过头去输出完整的 PRD。这个变化看起来只是把前后顺序调换了一下，但本质上完全不一样。以前 PRD 更像起点，是为了推动别人开始做事；现在原型更像起点，我先通过一个可运行、可感知的东西把想法逼清楚，再把已经验证过的内容沉淀成文档。
我后来越来越觉得，这才是 AI 时代更适合我的工作方式。因为很多需求在纸面上看起来成立，真正做成原型以后才会暴露问题。与其一开始就花很大力气把文档写得滴水不漏，不如先让 AI 帮我把东西做出来、改起来、跑起来。等方向真的被验证了，再去补齐那份完整、清晰、可复用的 PRD。在这个流程里，PRD 不再是产品诞生的起点，更像是产品逐渐成形之后的说明书。
后来我慢慢形成了一个很实用的习惯：不要让 AI 的产出只停留在对话框里，而要把它沉淀成文档。因为很多时候，真正有价值的，不是单次回答，而是我和 AI 在不断讨论后沉淀下来的共识。如果是有助于 AI 理解我完整意图的内容，我会尽量让它输出成 Markdown。像需求拆解、调研结论这类材料，都会整理成结构清晰、可以反复调用的文本。这样我后面再切换到别的模型、别的 Agent，甚至别的工具时，就不用再从头解释一遍，直接把文档作为上下文丢进去就可以了。
但如果这份东西主要是给人看，比如拿来学习、复盘，或者给同事、老板做展示，我又会把它进一步转成可视化阅读体验更好的 HTML。因为给 AI 用的文档，重点是结构化、可复用、便于机器理解；给人看的文档，重点则是信息层级、阅读节奏和展示效果。后来我越来越觉得，这一步转换本身也是工作流的一部分。你不是把 AI 的输出复制出来就结束了，而是要继续判断：这份内容接下来是服务 AI，还是服务人，然后用最合适的形式把它交到下一环。说到底，我是在把一次性的 AI 输出，变成可以沉淀、复用、流转的上下文资产。
我后来回头看自己这一路的变化，发现它其实非常清晰。最早的时候，AI 只是工作流里的一个节点，我负责大部分流程，AI 帮我拿一点数据、产一点内容。再往后一步，我开始让 AI 帮我写自动化软件，把那些重复、机械、可批量化的动作接过去，我自己只保留关键确认和结果分析。再后来，我开始把一整个任务交给 Agent，让它像一个真正的执行者一样把中间过程跑完，我只看结果、改方向、做判断。再往后，我又把传统流程倒了过来，先让 AI 把原型做出来，再让文档跟着已经验证过的结果沉淀下来。
这一路的变化，并不只是效率提升了而已。它真正改变的，是我对产品经理这个岗位的理解。过去我们总觉得产品经理最核心的产出是文档、方案和沟通，是把事情协调起来。但现在我越来越觉得，AI 产品经理的边界已经跟过去不一样了。真正的变化，不是我会不会做一个工具，而是我已经开始直接用 AI 推进产品表达、方案验证和交付链路，去补齐过去通常要依赖设计、研发继续往下走的那一段工作。文档当然仍然重要，但它越来越不像起点，更像一个在方向被验证之后再回头沉淀的结果。
所以我现在对自己的要求，已经不再是把文档写得更漂亮，也不是把 prompt 调得更准，而是尽可能成为那个定义工作流、先把结果跑出来、再把结果沉淀下来，并对最终结果负责的人。调研也好，原型也好，很多过去需要多人接力才能推进的事，现在都在被重新打包。
我越来越相信，AI 产品经理真正的基本功，不是表达，而是判断；不是手动完成每个环节，而是知道哪些环节根本不该再由人完成；不是把自己训练成更熟练的使用者，而是把自己逼成一个能独立组织交付的人。
AI 产品经理真正的分水岭，不是会不会用 AI，而是能不能把 AI 组织成自己的工作方式。
作者：岩风 公众号：岩风AI自由
本文由 @岩风 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。