本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《什么是 AI 产品经理，工作内容是什么？》
之前我写了一篇关于AI项目团队应该如何搭建的文章，其中提到一个观点在项目初期，产品经理这个岗位其实是没有意义的，有些同学可能会觉得不可思议，因为之前产品是很多干不动岗位想要去到的角色，比如：测试→产品、技术→产品......
现在你告诉我，产品不需要了，这不玩吗？要回答这个问题，可能还需要从最初说起：
unsetunset产品经理的“权柄”unsetunset
如果让我描述产品最大的权柄的话，我会说产品经理是产品（项目）的验收者，也就是产品往往具有产品（从测试到上线前）的首次评价权。
如果再高级一点的话，产品经理是产品（项目）的定义者，但这东西多半是有点虚的，因为一个中小型公司产品最终设计者大概率是老板，老板才是最大的产品经理，如果你拥有产品定义的权限（拍板的权限），那么你可能也不是纯粹的产品经理，大概率是高管。
综上，对产品的评价能力，就是产品经理耐以生存的基石，也是他可以对程序员指指点点的原因，毕竟他是上游嘛，只不过现阶段，他们这个基石有点不稳了，或者说被分出去很大一部分。这里我们先看全景图：
这里几乎有一个生产级复杂AI项目的所有任务，能够读懂这张图，也就能知道为什么产品经理的价值会很低：
行业专家是整个AI项目的评价者，这个AI回答的好不好、专不专业、有什么缺漏，是他们需要去评说，转达给技术Leader的；
而技术Leader更是整个项目组的核心驱动，他们承上启下，需要评价技术路径的好坏；另外，行业专家团队只能发现问题，他们并不能独立解决问题，只要涉及问题解决，那就一定要回归技术团队；
而产品团队在AI这个时代是比较尴尬的，原因有两点：
第一，过往互联网所有的产品好坏（审美）几乎已经固化，也就是说，只要你想做一个产品，大概率是可以在市面上抄一抄、借鉴借鉴的；
第二，也是核心关键，AI产品的交互就是一个对话框，极其简单，几乎没有产品审美的用武之地，其次产品经理没办法评价AI的专业回答好坏，也就是产品经理丢失了产品评价的能力，作为曾经产品好坏评价的重要参与者（至少是验收者），产品的角色被极大的削弱了；
相应着，之前对程序员的评价是代码优劣，逐渐会加入提示词写得是否优雅，整个AI项目的改变是整个评价体系的重塑。
在了解底层后，我们再延展下，在中小型公司产品经理的其他重要角色：
unsetunset高兼容性的PMOunsetunset
以之前产品好坏的首次评价者和修改建议（多数是决策者）来说，产品经理在实际工作过程会有意无意承担一个角色：团队PMO！
大家会发现，产品经理天然就适合这个角色，一方面要梳理很多信息，让团队运作得更顺畅、另一方面也需要确定产品在执行的过程中没有走偏；
只不过，我觉得产品经理最为重要的作用可能是：向上管理，因为汇报很烦的......
程序员这批人其实是比较鸡贼的，他们在平时工作中总会选择对自己职业生涯最有帮助的工作，或者说把时间精力放在ROI更高的技能上。
所以，在互联网寒冬来临之前，其实程序员们是更喜欢默默的写代码，并且这几乎是一个难以两全的选择，这里可能只有真正写过代码的同学知道这其中水有多深，以多年前（10年）前端技术栈为例：
最初可以选择的是JavaScript或者CSS，这样已经可以安身立命，之前很多jser是不会写CSS的，你敢信？
再往后一点，前端卷起来了，JS和CSS开始变成都要会了，这里就涉及了两个技术栈，搞熟悉各自要个半年很合理；
然后继续卷，只是打通前端还不够，还得搞定Native，于是乎Hybrid、RN这些东西出来了，这个时候其实已经是应用级了，前端侧业务代码已经很复杂了；
但他保不齐人多啊，为了拉出差距，NodeJS来了，终于开始往后端卷了，这里技术栈跨度还不小，半年熟练绝对不夸张；
只不过无论NodeJS还是Php，都是语言层面的问题，数据库这东西总得懂吧，各种坑点、卡点总得突袭吧，这可不是一年半年能搞定的了，之前我下面一个后端出身的小伙伴，去B站就一个锁没搞明白，直接就吃了一个T0级事故；
...；
以上就是所谓全栈工程师，大家可以看出来，真正要达到那个标准，还是需要花费巨大的精力，绝不是一朝一夕能可实现的，这也说明一个问题：
靠谱的程序员，根本没时间也没心思去做产品相关工作，因为他们会认为那是杂事，不具备通用能力的低阶技能。其实毫不夸张的说：
项目管理的核心也就是Todolist+闹钟，就是不停的沟通、确认、汇报，全程各种push就好了...
而这个角色其实有沟通能力的技术是一定比产品更适合的，他们才知道谁在摸鱼，只不过他们之前不愿意做罢了，但现在情况发生了天翻地覆的变化：
市场寒冬极大的加剧了内卷；
AI的出现极大的提升了效率，并且降低了全栈工程师达成的门槛；
于是乎，你他妈不做，多的是人想做的场景发生了，在技术Leader（经理）愿意做PMO的时候，一般的产品经理说实话就有点小弱势了...
所以，产品经理当前的生存空间其实算是被同步压缩了，现阶段聪明一点的产品已经尽可能的在自己切入Vibe Coding、至少要会一点Coze/Dify，他们也想要去革程序员的命，其实大家也看出来了：现在是行业在重新定义岗位任务边界的时候了...
unsetunset产品经理：翻译工具unsetunset
综上，在项目初期，产品经理的意义不大，但是当发展到一定阶段后，比如规模化、商业化阶段后，会需要协调市场、运营、销售等多方资源，这个时候技术又会很吃力；
比如就简单跟商务沟通这个事情，技术会很不适应，销售一定会过分承诺追求成单，但技术一定会保守承诺追求把握性，销售会认为技术脑子不好使，影响自己成单、技术会认为销售满嘴跑火车，给自己找麻烦，一来二去就容易扯皮。
除非能解决这种结构性上下游矛盾性问题，否则更为专业的产品万金油总是需要的，我认为一个比较贴切的形容是：产品的公司的翻译者，他首先需要帮助老板翻译、传达战略、其次需要帮各个部分翻译各种业务语言。
这个不是技术和业务专家能不能做的问题，是一个对比优势的问题，谁更擅长谁做呗，只不过都到规模期、产品上线了，也不是初创团队的情况了...
unsetunset结语unsetunset
最后总结一下：AI的出现，对当前项目研发的各个角色都造成了不小的冲击，其核心原因就是评价权被重塑了
一方面，AI产出的专业性需要行业专家来评价，这剥离了产品经理过去对内容价值的评价权；
另一方面，我们每个人的工作过程与产出，也前所未有地暴露在AI的审视与辅助之下，这让岗位的价值必须用更本质的贡献来衡量。
一旦评价权重塑，团队的组织形态就会被迫重排，尤其是在0-1的AI项目里，会出现一种更“AI-Native”的组合方式：让技术承担更多的角色。
但要注意，这不是说不要产品，而是传统产品那套靠PRD、靠传话、靠对齐的中间层被系统性压缩了。更高效的结构如下：
一、老板是唯一真正产品经理
初期AI项目的关键跟需求几无关系，而是清晰定义我们AI产品的能力边界，对于做什么、不做什么这个事情必须取舍清楚！
就我最近两年在各个公司的经历，现在CEO越来越喜欢自己下场干活了，他们：第一时间体验输出质量、亲自判断能力边界、亲自决定下一步迭代优先级。
这样可能也是时代必须，否则信息在转述—再转述中损耗，速度立刻塌掉。
更进一步，增长也会被拉进产品里：你怎么把产品价值翻译给用户、怎么在社区里验证需求、怎么形成反馈回路，本质上都是产品的一部分，而不是上线之后再补的“运营工作”。
总之，AI项目，一定是一把手工程。
产品Coze小能手
当交互已经被收窄到一个对话框时，产品设计的关键就肯定不是原型图了...
如何把企业抽象的氛围、品味、体验、约束等，添加到这个小小的聊天框、又不显得拥挤，可能会成为新的挑战。
而且，我这边看到的产品负责人就特别卷，他们往往自己就学会Coze这些东西了，这里带来的变化是他们在“原型机”阶段抛弃研发了；
过去产品写在PRD里的东西，会越来越多地变成“活的原型”、“可运行的demo”、“可对齐的工作台状态”。
这种Coze搭建的东西验证通过后，几乎需求文档就完成了...
全栈技术、管理高手
技术在体系里面，可能依旧是“最忙”的人，项目早期的工程师不只是接任务的人，还需要把模型能力、上下文、工具链、评测链一起跑通。
AI项目demo产出时间可能很短，但真要打磨到可用、好用是非常考验耐心和能力的，所以这其实也是个巨大的项目管理事务，需要这个人是个管理高手。
这个角色需要将所有的工作串联起来：怎么建测试集、怎么定红线、怎么回归验证、怎么线上监控漂移与风险。工程师越能用AI工具放大产出，团队越能用更小的人数完成闭环，也越不需要靠“中间层岗位”去维持运转。
最终，谁掌握了这些，谁就掌握了事实上的评价权，你懂了吗？