354 lines
26 KiB
Markdown
354 lines
26 KiB
Markdown
---
|
||
title: 不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南
|
||
source: https://mp.weixin.qq.com/s/6s9iQrTKuN18706ULWqr_Q
|
||
author: shenwei
|
||
published:
|
||
created: 2025-12-18
|
||
description:
|
||
tags: []
|
||
---
|
||
|
||
|
||
原创 Kira2red *2025年11月19日 22:48*
|
||
|
||
Gemini 3 pro发布的当口，AI圈沸腾了，可圈外谈论者寥寥。Vibe Coding已经被广泛应用在编码工作中了，但是对产品经理而言，特别是非AI行业的产品经理，工作中到底怎么高效、高价值利用AI并没有广泛共识。
|
||
|
||
我想说两件事：
|
||
|
||
第一，都不需要Gemini 3 pro，哪怕是上一代的Gemini 2.5，也几乎可以将我的某些工作时间缩短90%以上。
|
||
|
||
第二，很多不会用大模型的初阶产品经理注定是要被淘汰的，或者说的好听点，能力结构是要重塑的。
|
||
|
||
这不算是耸人听闻的话，对于产品经理（特别是负责功能实现的中初阶产品）的日常工作，我已经跑通了除输出高保真C端交互图以外的绝大部分流程，本文就是手把手的保姆级教程。
|
||
|
||
|
||
|
||
这篇文章适合两类人：
|
||
|
||
第一，能掌握大模型的产品经理，特别是中初阶产品经理。希望你可以优化我的方法，让你一些文本工作的工作时间释放出90%以上，进而有时间探索、思考应该朝着哪些方向构筑自己不可替代的竞争力。
|
||
|
||
第二，不能掌握大模型的产品经理，这里的掌握可不仅仅是浅尝辄止问问豆包，而是能把大模型“嵌入”到你的工作流中，产生实际的价值。看完这篇文章之后如果你还是无法做到的话，可以尽早考虑转行之类的，比如做做自媒体博主。
|
||
|
||
让大模型写SQL查个数据、做个简单的demo用作演示，很多自媒体都分享过，我们就直接进入产品经理最核心的工作交付物——需求文档。
|
||
|
||
|
||
|
||
1.用FeatureList构思需求
|
||
|
||
后台需求特别适合大模型来写，交互层面的规范化程度特别高，甚至可以直接用arco design这种开源框架来搭积木，你几乎只要能清晰描述好后台需求的工作流、数据结构，就能设计出来大差不差的需求。
|
||
|
||
我们强调一点，让大模型来“ 写 ”需求文档，真的只是让它来“ 写 ”，而不是“ 想 ”。如果你希望给大模型一句话，它就能把热气腾腾、完美无缺、逻辑严密的需求文档捧给你，我试了，Gemini 3 pro差的有十万八千里。“ 想 ”永远需要你来完成，大模型只是负责把你脑海里的东西“写”下来。它跟你自己写的差别是，你可以只用只言片语描述需求，它来负责补全各种边界场景定义、各种通用规则描述、语言严谨的行文格式。
|
||
|
||
“想”的过程，有个很好用的工具就是FeatureList。
|
||
|
||
我是进入造车行业之后才开始用FeatureList的，其实就是按层级的需求表，之前做互联网产品的时候用的是脑图，本质上是一回事。FeatureList可以分层级展开你想做的功能点，我们主要关注三方面：
|
||
|
||
（1）各个功能模块的分层、分类是否合理
|
||
|
||
（2）某个细分模块的功能点是否全面、划分是否合理
|
||
|
||
（3）每个功能点的优先级评估是否合理
|
||
|
||
下面是我发给Gemini的一个表头，实际的表头格式你也可以根据自己的实际场景来定义。
|
||
|
||
|
||
|
||
|
||
|
||
为了更直观的体验，我虚构了一个场景： 制作一个英雄联盟出装查看工具 。
|
||
|
||
我想强调一点，正好今天纯银在犬校分享自己体验Gemini 3 pro的感受提到一句话： 只有提交真实需求，才能获得真实的触动 。这么说吧，我在围绕这个虚构场景工作时的震撼程度跟解决我真实遇到的问题相比，十不存一，你一定要拿自己生活、工作中最困扰的问题让它来解决！
|
||
|
||
书归正传，我是这么跟Gemini沟通的：
|
||
|
||
|
||
|
||
> 我要做一个英雄联盟数据库工具的后台产品，需要输出prd、Featurelist和关键页面的html代码。现在我要先跟你描述需求框架，我们一起设计Featurelist，先不要写prd和html。
|
||
>
|
||
> 这个英雄联盟数据库能够查询英雄数据：包括QWER+被动技能的名称和描述，推荐出装（可能有几套出装，对应不同的对局要求和打法），推荐加点（可能有几套，也是对应不同打法，一般来说打法和出装有一定的对应关系，但不是严格的1:1）。
|
||
|
||
> 后台至少有这几个模块：
|
||
>
|
||
> 英雄管理：维护英雄名称、图标、配置每个技能的图标、名称、技能描述
|
||
>
|
||
> 装备管理：维护装备名称、图标、装备描述
|
||
>
|
||
> 天赋加点管理：这块比较复杂，天赋对应三种天赋树，每个天赋树下有一系列天赋点，此处管理天赋点的名称、描述、图标和天赋树的关系。
|
||
>
|
||
> 出装配置：给一个英雄管理多套出装配置，每个配置关联一系列装备，能定义装备的先后顺序。每套出装可以关联不止一套加点配置，也可以关联多个克制英雄
|
||
|
||
> 加点配置：给一个英雄管理多套加点配置，每个配置关联一套加点方式。我们要先选择一个天赋作为主天赋，再选择一个天赋为副天赋，然后在这两个天赋树中选择天赋加点。也可以关联多个克制英雄
|
||
>
|
||
> 按照我的描述，根据我附件给你的Featurelist模板，输出Featurelist，以表格形式
|
||
|
||
你看，基本是自然语言，提纲挈领地描述了下想要它做什么事，但是细节是没有讲的，比如怎么关联、怎么创建。这对应了需求创意阶段，跟“同事”讲清楚你想做什么。
|
||
|
||
它当然给了我第一版FL，可以点击文末 【查看原文】 ，我汇总到飞书文档中了。但这一版FL我几乎没好好看，因为在回答最后，它问了我两个关键业务问题：
|
||
|
||
|
||
|
||
|
||
|
||
我补充了业务逻辑之后，它给了我第二版FL，但是不知道为啥，虽然附件的模板中展开到四级功能点，这次给我的FL只到二级功能，并且漏掉了优先级字段，达不到我的要求，所以我对它说：
|
||
|
||
|
||
|
||
然后我就有了终版FL，看上去是不是还挺像样子的？同样同步在飞书文档中了。
|
||
|
||
|
||
|
||
这里有个小技巧，在实际应用中Gemini应对表格可能会犯下面两个错误，都很容易解决：
|
||
|
||
（1）生成了表格格式，但是复制到其他表格文档中（excel）容易丢格式或者错行。这个问题可以点击表格下方的导出到Google表格，然后把Google表格复制出来就不会有格式问题了。
|
||
|
||
|
||
|
||
（2）有的时候Gemini会脑瘫用制表符写成文本发给你，这个时候你直接把那段制表符文本复制贴给它，告诉它改成表格就行了。
|
||
|
||
你怎么管理你下属，你就怎么管理Gemini，严厉一点，没问题的，它不需要你提供情绪价值。
|
||
|
||
|
||
|
||
2.脑补画逻辑图
|
||
|
||
FeatureList完成后，这个产品的大体框架基本已经在你脑海里面了，通过FeatureList也能知道你这个后台会有哪些页面，每个页面会有哪些功能。
|
||
|
||
但是这么长的表格可读性是不好的，也不容易让人直观理解业务流。这个时候，我们就需要Gemini画一些逻辑图，况且这些逻辑图在真正写PRD时偶尔也用得上。
|
||
|
||
Gemini不能准确直接输出图片格式的逻辑图，但是可以用mermaid代码给你。
|
||
|
||
|
||
|
||
2.1 ER图
|
||
|
||
ER图是描述实体、属性、联系的一种逻辑图，用来表达数据结构再好不过了。你的后台有几张表，每张表有哪些字段，字段之间是怎么关联的，都可以用ER图直观的表达。
|
||
|
||
我对Gemini说：
|
||
|
||
|
||
|
||
它输出的是这种代码：
|
||
|
||
|
||
|
||
你看得懂吗？看不懂没关系，我也看不懂。这是mermaid代码，你可以访问mermaid官网，用代码生成逻辑图。但还有一种更方便的用法，打开飞书，新建一个文档，然后输入“/mermaid”，飞书会提示你插入“文本画图”的文档小组件，插入之后，把上面那一坨代码复制进去，右边就会显示图像了。
|
||
|
||
|
||
|
||
下面就是生成的ER图，我没有详细检查里面的逻辑关系是否正确，按经验来说这种逻辑图往往是一次成功。如果真的需要修改的话，你直接用自然语言跟Gemini对话，它能听得懂的！
|
||
|
||
|
||
|
||
-
|
||
|
||
2.2 时序图
|
||
|
||
ER图表示数据结构，而表示工作流的逻辑图我们一般会用时序图，我是这么说的：
|
||
|
||
|
||
|
||
你发现了没，这里有个“华点”，我一直以为那种一条一条的图叫“泳道图”，但Gemini并不这么认为，所以一开始它画给我的都是错的。
|
||
|
||
第一个错误是，可能它没画过这种图，所以飞书报错了。
|
||
|
||
|
||
|
||
我们怎么解决？当然是做好“传声筒”工作，把报错信息直接丢给Gemini。
|
||
|
||
|
||
|
||
第二个问题是，它不理解我说的“泳道图”是什么，所以生成了个歪歪扭扭的图。
|
||
|
||
|
||
|
||
我解决这个问题稍微废了点事，Google了一下“mermaid 泳道图画法”，然后在一个教程中，把能正确生成我想要效果的一段代码发给它了：
|
||
|
||
|
||
|
||
学得真快啊，马上就画出来我想要的时序图了，细心的小伙伴可以检查下图里画的对不对。
|
||
|
||
|
||
|
||
|
||
|
||
2.3 不知道什么图
|
||
|
||
其实在上面讨论的时候，我们就发现了“名词”的重要性，如果我们跟Gemini对一个名词的理解不同，很容易出现驴唇不对马嘴的情况（生活中跟真人沟通又何尝不是如此呢）。
|
||
|
||
就拿作图来说，mermaid的能力如此强大，如果我们不想自己翻阅官网上英文的文档，其实凡事都可以问Gemini的。
|
||
|
||
比如，我看到过一种图，但不知道它叫啥，问过之后你就知道让Gemini画甘特图了：
|
||
|
||
|
||
|
||
比如，你想用逻辑图表达一个流程，但不知道用什么图来表达，问下它，你也就知道了：
|
||
|
||
|
||
|
||
总之，结合Gemini和mermaid，几乎可以应对你工作中所有的逻辑图需求，且一键直出的正确率非常非常高！
|
||
|
||
|
||
|
||
3.脑补 写PRD
|
||
|
||
有了FeatureList，有了逻辑图，其实这个需求基本已经在你脑海中了，现在终于可以让Gemini写需求文档了。
|
||
|
||
此处有三条注意事项：
|
||
|
||
|
||
|
||
3.1 分页面逐一描述
|
||
|
||
一定要保证任务难度维持在Gemini胜任的范围内，我的实践是“一个页面一个页面地口述需求，如果一个页面太复杂，拆成几个状态分批跟它沟通”。
|
||
|
||
你一定要记住，Gemini是一个知识渊博但“不带脑子”的苦工，你表述的越准、它执行得越准。如果你希望让它完成“一句话需求”，目前来看还是雇个真人更适合你。
|
||
|
||
|
||
|
||
对于后台来说，常见的就是列表页+详情页，可能会有弹窗。我的习惯就是每个页面单独描述，确保任务收敛在它能胜任的范围内。
|
||
|
||
看下我的提示词，实际上我描述的已经很详细了，每个小功能应该怎么做，大体表述清楚了。但是我的原文不包含各种边界情况等功能细节的定义，例如空数据怎么处理、例如筛选器是求交集还是并集，这些体力活就是Gemini去干的。
|
||
|
||
|
||
|
||
3.2 模板 + 调教
|
||
|
||
如果你注意到，我这条提示词是带一个文件的。正好之前自己写过一份prd写作指南，就把这篇指南和我找了一份简单的prd示例合到一个doc里发给它了。如果你想要这份文档发给你的大模型，同样可以点击文末 【查看全文】 获取。
|
||
|
||
|
||
|
||
尽管这样，它第一次给我的文档是很粗糙的，后台文档堪堪可看，后面我测试了下一些交互比较复杂的C端需求，把有简单标注的原型图发给它，它写的文档简直是灾难。怎么办呢？你作为“带教老师”，需要手把手给它指出问题。它比真人好的地方是一教就会，同样的问题几乎不会犯两次。
|
||
|
||
这是我把很久之前做了份智能笔的部分页面扔给它，原型图见：
|
||
|
||
|
||
|
||
它的第一版需求是遗漏了大量交互细节的，比如：
|
||
|
||
|
||
|
||
我们要做的，就是用白话、直接把它的问题告诉它：
|
||
|
||
|
||
|
||
第二个版本，Gemini开始走火入魔了，把技术文档中的内容跟PRD混在一起了。当然有些toB或者中后台的业务确实是可以这样的，但显然不符合主流C端需求的情况。
|
||
|
||
|
||
|
||
于是继续调教，我甚至动了动尊手，给它写了一句例子：
|
||
|
||
|
||
|
||
然后就基本满足我的标准了，并且从此之后写的其他需求文档基本也符合这个水位。
|
||
|
||
“调教”出来了。
|
||
|
||
这不比带个新人容易多了？ 三句话，带出来一个文档写得好的产品经理 。
|
||
|
||
|
||
|
||
所有的PRD可以到飞书文档中查看。
|
||
|
||
|
||
|
||
3.3 生成html文件代替原型图
|
||
|
||
这里特指后台需求，因为交互简单。
|
||
|
||
所以你看我前面每一段写prd的提示词中，都要求它同时生成html代码。并且由于我每一步只画一个页面，所以也几乎没有复杂的页面跳转，Gemini处理起来更容易一点。
|
||
|
||
|
||
|
||
有了html代码，怎么变成可视化的文件呢？可以参考我之前写过的另外一篇文章，在macbook里面简单配置一下，每次选中代码右键就可以了。
|
||
|
||
[0基础5分钟包会的AI编程指南：要实用也要成就感](https://mp.weixin.qq.com/s?__biz=MjM5OTc0MTI2NA==&mid=2648244087&idx=1&sn=81c7d54680f197187db893636750d402&scene=21#wechat_redirect)
|
||
|
||
|
||
|
||
|
||
|
||
我甚至觉得自己可能低估了Gemini的能力，因为有些单页面里面的功能其实挺复杂，比如分步配置、各种弹窗内逻辑、嵌套表格，它基本都能一次成功。下面这个算是比较简单的交互了，实际工作中我用gemini一次成功生成过更复杂的。
|
||
|
||
|
||
|
||
逐个页面生成html还有个好处，就是维护起来特别方便。比如以后需求迭代的时候，你就可以把之前的html文件丢给它，只描述修改的内容，就有了新的html文件和差量部分的prd了，相当于你维护了一份永远最新的交互原型库。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4.耸人听闻的话
|
||
|
||
到这里，你会发现传统产品经理工作的大部分文档内容都可以被Gemini胜任了。我还想谈谈自己的感想，不一定对。
|
||
|
||
“ 不会用Gemini的产品经理真的要被淘汰了 ”，这句话不一定对，因为有可能 会用Gemini的产品经理还是会被淘汰 。
|
||
|
||
你看我这个流程，仍然是把产品设计 - UI设计 - 功能实现 - 测试准出分成了不同的环节，局限在产品设计环节中的提效。可能过去我要写一两天的文档，Gemini用了10min就写好了（甚至里面大部分时间是我复制到其它文档工具中改格式花的时间），但是， 谁说未来的需求实现过程一定要需求文档呢？谁说未来的产品经理一定要写文档呢 ？
|
||
|
||
智驾都端到端了，需求实现不能端到端吗？用图文传递信息一定是有损的。
|
||
|
||
|
||
|
||
OpenDriveLab | 关于自动驾驶感知决策一体化架构设计思考 - 知乎
|
||
|
||
有没有可能未来不久的工作流是，作为产品经理的我跟一个agent疯狂对话，获得一串id，然后我把id丢给下游的研发，研发盯着屏幕疯狂冒代码，获取另外一个id，然后把这个id发布到线上？
|
||
|
||
有没有可能真正来到一人公司？我跟agent们对话，不同的agent帮我完成需求呢？
|
||
|
||
我不知道这些情况多久会到来，但是凭经验来说，它们一定会到来。
|
||
|
||
|
||
|
||
正好前不久在犬校聊大模型的时候，我是这么说的：
|
||
|
||
我对AI的态度从“理性悲观”变成了“理性乐观”，甚至现在还要更乐观一点。
|
||
|
||
发生变化的原因是，几次关键节点上，AI进化的速度每次都超过我的预期。
|
||
纯银文中提到的 **“时间线拉长到五年，十年是无法预测的，但两三年内，在大语言模型这个技术路线下，基于上面提到的关键约束，我对于 AI 的商业价值大量喷发是悲观的”。** 我有另外一种看法，确实目前为止，2-3年的尺度内没有像移动互联网井喷时代那么疯狂的商业增长，但是从个人视角，一些细分任务，我之前以为2-3年内不会有太大进展的时候，可能不到几个月突然冒出来个模型或者产品完美胜任。
|
||
|
||
就拿大模型来说，突然之间发现它几乎能胜任我手上大部分文本类工作了，甚至不需要修改。进化速度是超出我预期的。当然我算是大模型外行人，使用者视角，不知道从业人员视角是不是这样。
|
||
|
||
在我看来，大模型领域正在进行量变到质变的过程，无数个细分场景的能力都在参差不齐、速度不一地提升，有的被我们看到了，有的没被我们看到。它们的共性是，进化速度超出我的预期，但还没到改变某个大行业商业逻辑、产生巨大商业价值的那个临界点。
|
||
|
||
原来我觉得那个临界点就算到来，也不会太近；现在我觉得我不应该做这个判断，我也没能力做这个判断。如果自己并非模型类产品的从业人员，那就贴身去用、悬置判断，等到质变发生的时候，我们能快速嵌入到漩涡中。
|
||
|
||
再聊All in AI。
|
||
大多数场景下，All in是一种愚蠢的、懒惰的做法，但据我观察，除了莽撞的All in来说，有些时候也有“聪明”的All in。
|
||
就像我上面说的“个人要贴身去用”一样，企业“贴身去用”的做法看起来就像是All in——要求员工在工作中多用AI，要求新需求与AI有关，可能是一种保持在线、积累认知、以战养兵的做法。只是这种做法的“寸劲”很难拿捏，就像Moba游戏开团之前疯狂拉扯，哪里近一点、哪里远一点、何时开团，这些寸劲就是菜鸟和高手之间的差距。特别是何时开团，这是基本只有老板能指挥，很考验老板的能力。
|
||
可能有些老板是能“保持在线、积累know how"，有些老板在贴身参与的过程中激进一挥下场开团，有些老板有样学样、知其然不知其所以然鲁莽All in，情况很复杂。
|
||
|
||
最后关于“超级个体”。
|
||
我想补充个观点，超级个体之所以是超级个体，不是因为AI，而是因为他们本来就是超级个体（或者说有成为超级个体的潜质）。
|
||
我老婆在另外一个AI大厂当HRBP，他们All in AI，我们每天上班路上几乎都会聊下形形色色的人在All in过程中的奇妙案例。在当前的AI能力下能用好AI的人大概率本身在某个领域就能做到八九十分，只是因为需要横向扩展，所以AI帮助他们在其他领域拉到了六七十分。如果没有AI，他们大概率也有其他方法，比如请教专家等等，只是目前AI最好用。
|
||
原本能做到八九十分是关键，因为他们本身就掌握“ **把一件事做对** ”的方法和能力，比如提问能力、比如对模糊信息的判断能力、比如模块化、流程化的能力，所以他们相比其他人更容易用好AI。
|
||
我对AI的悲观判断在于，我认为本身只能做到六十分及以下的人，大概率永远“用不好AI”，而是会被工具化，嵌入到AI的某个流程中。
|
||
|
||
这事就跟老板All in AI殊途同归了——有的公司可能就是用不好AI。 **人用不好AI，公司用不好AI，不是AI的问题** 。
|
||
|
||
|
||
这样我对AI的发展更乐观了，
|
||
一方面，AI对现在的商业格局、做事方式重构是必然要发生的事，有的人、有的公司就是会被淘汰。
|
||
另一方面，现在AI在细分场景下的进化速度确实超过我的预期，我在静待质变时刻的发生。
|
||
|
||
好像归根结底还是纯银文中这句话“ **市场洞察永远是创业者和产品经理最稀缺，也最重要的能力。技术服务于市场洞察，而不是技术领导市场洞察** ”。我相信这句话是持久有效的，无论是不是所谓的AI时代。或者说AI时代，这个能力更重要了。
|
||
至于乐观还是悲观，何时会有质变，whatever，管他呢。
|
||
|
||
|
||
|
||
并不是说你我不会Gemini，就会被淘汰，
|
||
|
||
而是说 ，
|
||
|
||
你我不能把时代里随时涌现的新东西嵌入到自己中，
|
||
|
||
新时代也就没有了嵌入你我的位置。
|
||
|
||
[阅读原文](https://mp.weixin.qq.com/s/)
|
||
|
||
继续滑动看下一个
|
||
|
||
二红笔记
|
||
|
||
向上滑动看下一个 |