说实话,我不确定这篇文章对大家有没有用。因为它不是一篇「AI工具大盘点」,也不是「用ChatGPT写PRD的5个Prompt」,更不是什么方法论课。它就是我这几个月在B端产品经理的位置上,真实摸索出来的一套工作流,踩了很多坑,也有几次让我觉得「卧槽原来可以这样」的瞬间。
如果你也在做B端产品,或者对怎么把AI真正用进工作里感兴趣,可以往下看。不是表面用,是深进去用。

先说一个背景。我做的是B端产品,具体一点,是企事业单位内部系统的产品经理。这类产品有一个很独特的难点,它不像C端,用户会主动给你反馈,会用脚投票,会在评论区骂你。B端的用户通常是被迫使用的,他们的真实痛点藏在流程里、藏在角色关系里、藏在那些说不清道不明的「反正现在就这样」里。
所以B端产品经理的核心能力,不是写PRD,是看穿业务。而我发现,AI在这件事上能帮上很大的忙。
其实 最开始,我也是试着把录音、业务材料等丢给大模型,让它帮我「总结一下需求」,结果当然不是很理想。AI给我输出了一份漂漂亮亮的需求清单,逻辑清晰,分类合理,看起来很专业。但我拿着这份清单去跟业务方对齐的时候,发现大概有一半的「需求」根本不是真实需求,是业务方在访谈时随口说的愿望清单,他们自己都没当真。
还有两三个关键痛点,AI完全没提炼出来。因为那些信息藏在会议纪要里那几句语气词里,「反正就是每次审批走到这一步就卡住了」,AI不知道「卡住」在这个业务场景里到底意味着什么。
我意识到一件事,AI的输入质量,决定了AI的输出质量。废话,但我最开始的时候,还真没认真想过这个问题。
所以我开始调整。
第一个阶段,我把它叫业务洞察。

我现在的做法是这样的。访谈或者会议结束之后,我不会直接把录音或者会议纪要扔给AI。我会先做一件事,把业务的基本结构自己整理出来,角色有哪些,流程节点是什么,核心规则是什么,这个系统里什么状态是正常的,什么状态是异常的。
这个整理的过程,是我自己来做的。
为什么不让AI来?因为这个过程本身就是我理解业务过程。我如果偷懒让AI来整,后面的判断就没有根基。这话听着有点反直觉,但我真的试过,让AI先整理再分析,和我先整理再让AI分析,最后的准确度差很多。
把这些背景信息整理好之后,我再把访谈内容、会议纪要,和这些背景信息一起喂给Claude,让它帮我做四件事,摘要归纳、问题聚类、流程还原,还有初步结论。这时候AI给的东西,质量就完全不一样了。
但我还有一个动作。AI给完初步分析之后,我会重新过一遍,把我觉得「不对」的地方标出来,把我觉得「漏掉了」的业务信息补进去,然后再让AI重新跑一轮。
这个「AI分析→人工校准→再分析」的循环,可能要跑两三轮,最后出来的需求清单,准确度会高很多。
坦率的讲,这个过程一开始挺费时间的,比我以前自己整理甚至还慢一点点。但最后产出的质量不一样,下游的方案设计会顺很多,少走很多弯路。时间花在哪里,很重要。
如果你想试这一步,可以从下一次业务访谈开始。访谈结束之后,先自己先花点时间把业务角色、核心流程、关键规则整理成一份结构化的背景文档,然后再喂给AI分析。看看跟你以前直接扔录音相比,结果有什么不同。
顺着上面的再聊聊,业务洞察结束,我们走到了方案设计。

这块是我觉得AI目前帮助最大的地方,也是最容易被低估的地方。
以前我设计一个功能模块,能参考的东西很有限。网上找点竞品截图,翻翻以前写的PRD,脑子里拼凑一个方案,然后靠自己的经验判断这个方案靠不靠谱。
现在我多了一个输入源,个人方案资料库。
这是我这些年干产品攒下来的东西,历史PRD、设计过的页面结构、业务模型、字段规则、踩过的坑、成功过的模式。这些东西我都整理进了一个本地文件库,每次做方案设计,都会把相关的材料拉进来,让AI一起处理。
你想想看,这相当于什么。相当于你在设计一个审批系统的时候,AI能同时看到你过去设计过的三个审批模块,看到行业里成熟的审批流最佳实践,看到这次的真实需求,然后给你生成一个初步方案。
这种体感。。。怎么说呢,就像是你雇了一个记忆力超强、但业务判断力偏弱的助手。
这个初步方案当然不是最终版,它会有很多没考虑到业务约束的地方,比如这个功能在我们的技术栈里实现成本很高,比如这个流程设计需要跟财务系统对接但我们短期内做不到。这些AI不知道。
AI给方案,我来校准。校准完再让AI改,再校准,出最终版。
我自己的感受是,用这个方式,一个PRD草稿的生成速度,比以前快了大概60%到70%。更重要的是,方案里的「知识密度」更高了,因为AI帮我把行业最佳实践和历史经验都整合进来了,我一个人脑子里装不下这么多。
这块需要注意一下,个人方案资料库的整理是有学习成本的。我大概花了一个多月,才把过去几年的材料整理成AI能读的格式。一开始你可能觉得「整理这些干嘛,太麻烦了」,但这个投入是一次性的,之后每个项目都能复用。
说到原型交付,这里是让我觉得「卧槽原来可以这样」的地方。

以前做B端产品,交付物通常是PRD加上原型图,Axure画的那种。业务方看完,表示看懂了,但等真的研发出来之后,他们会说「不是这个意思」。
这个现象,我以前以为是业务方的问题,后来我发现,这是抽象方案本身的局限,它很难让人真正代入使用场景。你盯着一个线框图,脑子里想的是它真的「运转起来」是什么样的,但线框图告诉不了你这些。
现在我在做完PRD之后,会多一个步骤,让Claude Code 或者 codex 帮我把PRD翻译成一个可以跑起来的前端Demo。带Mock数据,带交互,看起来像一个真实的系统页面。
这个Demo不是最终交付给研发的,是用来跟业务方沟通的。
效果非常明显。业务方拿到一个能点的页面之后,马上就能发现那些他自己都没意识到的问题。「这个字段的名字不对」「这个状态应该不会出现这里」「等等我们还有一种例外情况你没有处理」。
这些问题,如果等到研发出来之后再发现,成本很高。现在在Demo阶段就能发现,改起来几乎是0成本。
但要说一个我自己踩过的坑。
我们第一次做Demo的时候,忽略了公司的设计规范,AI生成了一套完全不一样的UI风格,拿去给业务方看,他们第一反应是「这不是我们公司的系统」,直接影响了他们的信任感。
所以这个Demo的质量,取决于你喂进去的信息质量。建设方案要清楚,需求规格要明确,如果你们公司有组件规范或者前端框架约束,也要一起喂进去。这个细节,不亲自踩过真的不知道要注意。
好,最后一个阶段,持续迭代。

这是四个阶段里,我觉得现在做得最不成熟的一块,所以我说话会比较保守。
传统的B端迭代,很多时候是这样的。用户说不好用,业务方说流程慢,领导说体验差,然后产品经理靠经验 and 感觉判断优先级,排一个版本计划,开始做。
这个过程里,很多判断是模糊的,感性的,也是很难被追溯的。
我现在尝试的做法是,把反馈源做到四个维度,用户访谈的主观反馈、业务指标和异常数据、Demo验证之后的多方问题、历史问题库里的重复问题。把这四个维度的信息统一整理进来,让AI做问题聚类和初步归因,给我一个「优化建议」的清单。然后我再结合业务目标、团队资源、版本节奏,做最终的优先级判断。
这样做最大的好处是,优先级决策更有依据,更可以被追溯。以前有人问我「为什么这个需求排在下一版而不是这一版」,我可能只能说「我觉得这个更重要」,现在我可以说「AI聚类显示这个问题在三个维度都有反映,但这一版资源有限,我们先解决影响最多人的那个」。
话虽如此,AI在这里给的建议不是最终答案,我每次都还要经过人工判断。业务里有很多AI看不到的政治因素、资源约束、组织边界,这些必须靠人来判断。我自己也还在摸索这块怎么做得更好。
聊到这里,我想说一个更大的感受。
这四个阶段,有一个共同的结构,AI处理,人工校准,然后输出结构化的东西进入下一个阶段。这个结构听起来很简单,但我觉得它背后藏着一个对产品经理角色的重新定义。
以前我们总觉得,产品经理,尤其是高级产品经理,核心工作应该是战略规划与核心的沟通协调。但现实很骨感。在实际工作中,无论你级别多高,大部分的时间和精力依然会被无情地拖死在整理会议纪要、写PRD、画流程图、拉着各方人肉对齐这些把信息从一种形式转换成另一种形式的体力活上。本该属于高级产品的战略洞察、业务破局和真正的深度协同,全被这些琐碎且重复的文档搬运给挤占得所剩无几。这其实是整个行业的痛点。
现在,这部分搬运和翻译的信息体力活,AI可以帮我们接管大半了。
那产品经理的核心价值,到底被提炼到了哪里?
我觉得,是判断力,以及基于判断力之上的沟通协调。
是对业务真假需求的判断,以及推动各方达成共识的沟通协调。是对方案落地可行性的判断,以及跨部门调配资源的沟通协调。是对迭代优先级的判断,以及做利益相关者管理的沟通协调。是对系统演进方向的判断,以及牵引业务战略落地的沟通协调。
这些判断与深度的沟通协调,是没有标准答案的,没有任何一个AI能够替代。它需要你对业务有真实的理解,对组织架构有敏感的体感,对用户有真正落到细节的同理心。
AI让我们能把更多精力,放在这些真正有价值的判断与深度协同上。而不是继续在那些可以被自动化的信息搬运里,无端消耗自己。
我也不确定我这套方法论是不是最优解,可能有些想法还很不成熟,我自己也还在跑通它。
但这是我这几个月真实摸出来的东西,尽量不画饼,把每一步的具体做法和踩过的坑都写进来了。如果你想试,可以从最简单的那步开始。下次做完业务访谈之后,先自己把业务结构整理一遍,再喂给AI分析,看看结果有什么不同。
就这一步,可能就够你想清楚很多事情了。
既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐
谢谢你看我的文章,我们,下次见。
作者:AI打工实验室合作请联系邮箱:chatfastar@gmail.com
夜雨聆风