引子
最近我开始大量使用 AI 工具介入自己的产品工作，也明显感觉到，产品经理的工作流程相比以往发生了很大变化。借此文章，我来聊聊我对现在 AI 时代，产品经理的角色转变的看法。本文纯属个人观点，欢迎各位从事产品工作的人一起交流。
传统产品经理的常态
如果你是产品经理，那相信你一定会有和我一样的工作流：每天源源不断的需求会进来，要不停地去排期，既定的产品规划不断被打断；每天有写不完的 PRD，然后天天和 UI / UX 吵，这个做得慢，那个做得不好要重做，然后改了 NNNNNN 版后才去评审，评审万一没过，那就再来一遍。
在 AI 到来前，有无数的产品经理有着和我一样的处境，每天都有回马枪杀过来，导致产品推进得慢，又手足无措，最后只能说 “好吧先这样吧”，然后草草上线，勉强赶上项目进度。一段时间下来，产品推进效果先不谈，自己先被耗得满身疲惫。，甚至晚上休息的时候还会想着工作怎么推进。
AI 出现后，我的工作流变化
我是一名技术型的产品经理，我感觉其实 AI 的出现，并不会影响到产品工作的本质。产品要做的还是那些事：用研、竞品分析、需求收集整合、PRD、原型 ……
AI 对我产品工作的影响，其实是改变了我的核心工作流：它能将很多分阶段推进的事情并行推进，并且由于 AI 高效的产出速度和相对较高的产出质量，减少了大量沟通成本。
拿原型这个事情举例：以前都是先画低保真原型，过评审，然后交给 UI / UX 去生成高保真，再评审，然后再推进下一步。有了 AI 的加持，现在已经演进出一套全新的高效打法：喂上下文 → 出高保真原型 → 推进评审。
首先进入业务现场，进行真实业务场景调研，然后借助 AI 工具进行整理和竞品分析，尽可能收集到更多的用户需求、使用现状以及竞品信息，以此作为投喂给 AI 的业务上下文。然后直接利用 Open Design 等设计工具设计出高保真原型，或者利用类似 Eazo 这类面向非技术人员的 AI 平台，直接生成一个带小型后端的 demo。这种打法让 PM 和业务方能够在很短的时间内看到想法落地的样子，进而快速验证和调整。
这种工作流的优势极其明显，既降低了业务方理解产品方案的成本，也能够让业务方更早介入产品设计，而不是等到设计完成后才进行评审。在投喂了详尽的业务上下文和产品结构设想后，AI 会在极短的时间内生成一个接近成品形态的高保真 Demo，很多时候最终生成出来的效果甚至比原先设想的更好，给产品和业务方都带来惊喜。
本质转变 —— PM 从「自己干」变成了「指挥别人干」
从上面的 Workflow 可以看到，从完成上下文投喂开始，后面的很多工作其实就可以交给 AI 去完成。我之前简单用 “用 AI 设计原型或生成 Demo” 来概括了它的作用。
但实际上，作为产品经理，在 AI 生成的过程中，或者生成完一版之后，你需要经常介入并给出提示、做调整、加约束，告诉它 “这个不要、那个简化” 等等。这有点像在带一个新手员工：你把任务和背景给他交代清楚后，得时不时过去盯一下进度，发现跑偏了要马上拉回来、纠正方向。
这种 “指挥” ，其实比自己干更考验功力。你对 AI 下达的指令稍微模糊一点，它就可能给你整出一堆偏离目标但又看着像是对的东西。这时就必须依靠人，来对业务进行判断，把控方向，确保最终 AI 产出的结果是可控且可接受的。
这就是现在 PM 角色本质上的转变：从原来的自己亲手干所有的事情，变成了现在指挥 AI 干活的领导者。PM 不再是那个天天埋头执行的匠人，而更像是一个小团队的 leader。只不过，这个团队里被他带领的，正是一个个 AI Agent。
AI 时代 PM 必须修炼的四种能力
每个行业，都有自己需要修炼的功法。
传统的 PM，需要学习怎么写 PRD，怎么画流程图，怎么使用 Axure、Figma 这类原型工具，怎么开需求评审会，怎么跟研发、设计、测试沟通 …… 这些更像是 PM 的 “外功”。外功固然重要。不会写文档、不会梳理流程、不会表达需求，确实很难做好产品工作。
但问题是，AI 出现之后，很多过去看起来很重要的外功，正在快速被自动化、标准化、专业化。现在的 Agent，已经能够写出相当高标准的 PRD；也能根据几句话画出足以供评审的高保真原型；还能编写形象生动的用户故事、分析异常流程、列举字段说明、编写验收标准，甚至能顺手生成测试用例。
这意味着什么？意味着 PM 的价值，不应该继续停留在 “我会多少外功” 上。因为大部分的外功，AI 已经修炼到出神入化了。
AI 时代，PM 修炼的重心，更应该从 “外功” 转向 “心法”。结合我实际工作的经验，我认为，AI 时代的 PM，至少必须修炼四种心法：业务理解力、指令表达力、结果判断力，以及做减法的决断力。
业务理解力
很多 PM 会觉得，AI 产出的方案和 PRD 虽然全面，但很难贴合真实业务。比如说要做一个订单系统，AI 确实能给出用户管理、订单管理、权限管理、数据看板、通知中心、配置后台这一套东西，甚至还会给你画一个看起来很完整的信息架构，但这些东西都是通用系统八股文，套在业务场景上根本没法用。
没错，因为 AI 根本不理解业务场景是什么，所以只能根据已有的通用系统进行生成。
业务理解力的本质，是要拆解出真实世界里到底发生了什么。用户不是在 “使用一个功能”，用户是在某个具体场景下，试图完成一件具体的事，同时还会受到时间、成本、情绪、组织流程、权限边界、历史习惯的影响。
一个不懂业务的 PM，会把产品做成 “功能堆叠”。一个懂业务的 PM，才会把产品做成 “流程闭环”。
AI 能帮你把流程写得很好看，但它不知道你们公司的历史包袱，不知道一线同事的真实操作习惯，不知道用户在哪一步最容易骂人，也不知道某个看似不起眼的字段，背后其实绑定着财务、客服、运营、风控一整套链路。
所以，AI 时代 PM 的第一项修炼，不是学会怎么问 AI，而是学会怎么理解业务。
你要下沉到真实场景里去。看用户怎么操作，看业务人员怎么处理异常，看客服怎么解释规则，看财务怎么对账，看研发为什么不敢改某个逻辑。
这一心法，正是对应着前面提到的 “上下文”。
指令表达力
AI 不怕任务复杂，它怕任务含糊。对业务有了足够的理解后，我们需要将自己的理解，转化为 AI 能理解、能执行、能产出有效结果的任务。这背后考验的，还是 PM 的基本功。
真正有效的指令应该包含背景、目标、用户、场景、约束、当前问题、输出格式和判断标准。
“帮我设计一个活动报名页面。”
和
“我正在设计一个面向线下 AI 沙龙的报名页面。用户主要是想快速判断活动是否值得参加，组织者最关心报名人数是否达到预期。当前页面的问题是信息很多，但用户很难快速判断活动价值。请你从用户决策路径出发，帮我重新梳理页面信息优先级，并输出移动端页面结构。要求：优先突出活动主题、嘉宾、适合人群、时间地点、报名状态；不要新增复杂功能；适合小程序首版。”
这两种指令，得到的结果会完全不一样。前者是在问 AI 要答案。后者是在给 AI 划定一个可工作的范围。
AI 时代的 PM，必须学会把脑子里的隐性判断，转化成清晰的显性指令。你不能指望 AI 自动理解你的业务边界。你不说，它就会自由发挥。AI 最大的 “问题” 恰恰是：它很擅长自由发挥。
你没有说清楚要的是 MVP，它就可能给你设计一个平台级产品；你没有说人力有限，它就可能给你拆出十几个模块。这就像你只想搭一个小摊试试水，它直接给你规划了一个购物中心。看起来很豪华，实际上你连第一天的客流都还没验证。
指令表达力不是 “把话说漂亮”，而是 “把任务定义准确”。
一个优秀的 PM，应该能把 AI 当成一个能力很强但不了解现场的新同事。你要告诉它背景，告诉它边界，告诉它不能做什么，告诉它什么结果算好，什么结果算跑偏。AI 不是神，它更像一个执行力爆表但没有业务责任感的实习生。你喂给它清晰任务，它能把产出拉满。你喂给它一团浆糊，它就会给你一份包装精美的浆糊。
到这一步，才叫真正掌握了 “喂上下文” 的能力。
结果判断力
喂饱了上下文，AI 就会在很短的时间内，给我们一份结果。但当你把方案提交上去，在一次草率的评审中被放过，结果上线后出了事故，你就会明白，“结果判断力” 是四个心法中最最重要的心法。
如果没有结果判断力，那就不要用 AI 辅助工作了。原因很简单，AI 不会为结果担责，但你会。
AI 确实能产出很多的结果，而且这些结果看起来都完整好看，但我们不能忘记，AI 是一个生成工具，黑盒工具。它的产出总是带有一些不可预料的结果。PM 必须有能力判断：AI 产出的结果里，哪些是真正有价值的，哪些是 AI 为了生成而生成的填充物。
结果判断力，至少包含三层。
第一层是事实判断：AI 有没有理解业务？有没有编造前提？有没有漏掉关键约束？有没有把不适用于你场景的通用方法搬过来？
第二层是逻辑判断：方案之间有没有冲突？用户路径是否闭环？状态流转是否完整？前后规则是否一致？一个功能上线后，会不会引发新的操作成本？
第三层是价值判断：这个功能到底解决谁的问题？解决的是高频问题还是低频问题？是核心痛点还是边缘需求？它对业务增长、效率提升、风险降低有没有实质的贡献？
很多 PM 在 AI 时代会变弱，不是因为 AI 太强，而是因为他们把自己的判断力让渡给了 AI。
过去，一个判断力弱的 PM，可能一周写出一份有问题的方案。现在，一个判断力弱的 PM，一天能让 AI 生成十份有问题的方案。效率是提高了，但方向错了，跑得越快越危险。
AI 是用来放大你的判断力的，不是用来替代你的判断力的。你判断力强，AI 会让你更强。你判断力弱，AI 只会让你更快地犯错。
做减法的决断力
最后一门心法，我想从最近的一个项目开始举例。
我最近做的一个翻译项目，我想区分注册用户和非注册用户的权限，在输入了足量的上下文后，我让 AI 帮我生成一份需求清单。然后 AI 就为我规划了全套的用户注册、登录、付费、积分等等一整套的需求。因为 AI 生成的速度确实够快，我就让 AI 帮我进行生成。结果，注册接口、用户数据库、积分系统、还有各个功能的权限开放…… 一条 “确认，开始执行” 的命令，在不到 10 分钟时间，给我挖了一连串的坑，我调试了两天，问题一环套一环，最后只能回滚，重新删减掉看似能支撑系统完整性的一些功能，再重新 coding。
经过这段经历，我才明白，在 PM 的工作里，“做减法”，是一定要培养的能力。
AI 时代，做加法变得太容易了：你想要一个功能，AI 可以帮你补成一个模块；你想要一个模块，AI 可以帮你扩成一个系统；你想要一个系统，AI 可以帮你规划成一个平台。而且，这所有的操作，可以在短短不到半天的时间里全部完成。
这就有个很大的问题：产品会在很短的时间内变得虚胖。
以前做产品，虚胖还会被研发和评审拦一下，因为每加一个功能，都要评估人力、排期、开发、测试、上线。但现在 AI 降低了很多环节的成本，让人产生一种错觉：既然实现变容易了，那就多做一点。这是 AI 时代最危险的产品陷阱之一，因为功能实现成本下降，并不代表产品复杂度下降。
代码可以更快写出来，但用户理解成本不会自动下降。页面可以更快生成，但用户决策成本不会自动下降。后台可以更快搭起来，但业务维护成本不会自动下降。你每多做一个功能，就多一个入口、多一种状态、多一套规则、多一种异常、多一份解释成本。
AI 能帮你生成代码，但它不能替你解决复杂度的问题。复杂度最后一定会回到产品、研发、运营、客服和用户身上。
马斯克也多次强调了做减法的重要性：
“若无法在 100% 确定其必要性前，默认将其删除。若删完后需加回超过 10%，说明删得不够狠”
关于这一点，“奥卡姆剃刀” 法则，和衍生出来的马斯克的 “埃隆剃刀”，在网上的表述和解释已经很充分了。
工具会不断迭代，但对业务的深刻理解和判断力永远不会过时
借用现代管理学之父彼得・德鲁克的一句话：
“效率是把事情做对, 效能是做对的事情。”
现在 AI 的迭代是飞速的，但它最终还是要围绕着人的想法去执行工作的。我们可以把过程交给 AI，但目的的定义和结果的验收，还是要把握在自己的手中。我们不能一味地迷信 AI，而应该把它作为提效工具。真正的决定权，必须要放在自己的手上。
如果对您有所帮助，欢迎添加本站到收藏夹，也欢迎微信搜索公众号 半山数字札记 ，我会持续更新新的内容。
如果你也在做个人项目、优化工作流，或者只是想找一群折腾工具和内容的人交流，可以添加我的微信，备注「半山」，我会邀请你进群，欢迎一起探讨，一起交流。
