当前位置：首页 > news >正文

初识AI产品经理：我的学习心得与“夸父追日“感悟（收藏版）

news 2026/5/6 7:21:56

本文以作者成为AI产品经理第一个月的真实学习体验切入，用"夸父追日"比喻AI领域知识更新速度远超学习速度的现实。文章核心聚焦AI产品经理与传统PM的思维差异（管确定性 vs 不确定性）、必备基础能力（需求分析、沟通、PRD写法）、五大核心认知（Token上下文窗口、RAG、提示词工程、智能体、模型能力边界）。特别强调"Model Sense"的积累重要性，建议产品经理以"边学边做"方式掌握Token消耗计算、RAG系统设计、提示词工程等实战技能，而非急于深入代码。文章最后提出AI学习非终点论，主张先稳扎地基再追新知，鼓励同行者共享"未完成"经验。

我开始学AI产品经理的第一个月，手机首页每天都是新模型发布、新概念冒出来。刷完一个视频，评论区已经在讨论下一个更新的东西了。那段时间我有一种很奇怪的感觉——不是"我什么都不懂"，而是"我刚刚懂了一点，它已经变了"

这种感觉，我后来给它找到了一个名字：夸父追日

夸父追的是太阳，太阳不会停。你的学习速度，永远赶不上新知识产生的速度。这是AI领域的基本现实，不是你的问题，是这个时代的节奏。但夸父有没有意义？我觉得有。他跑的那段路，是他自己的

所以这篇文章不是一篇"AI产品经理完全学习指南"，我没有资格写那个。这是一个正在学习中的人，把手里攥着的那些东西摊开来给你看一看。我在门里，但还没走远。我看到的风景，可能比那些已经走了很远的人，对你更有参考价值——因为我还记得刚进门时的感觉，记得哪些词会让人一头雾水，哪些比喻会让人突然明白。

AI产品经理，和传统产品经理到底哪里不一样

我最开始以为AI产品经理就是普通产品经理加上会用那些AI对话工具。后来才意识到，这两件事的差距，大概相当于"会开车"和"会设计发动机"之间的距离——不是量的差别，是思维方式的差别。

传统产品经理管的是确定性

你把需求文档写清楚，开发按图施工，测试跑一遍用例，上线了就是那个样子。用户点了按钮，一定弹窗；提交了表单，一定入库。整个世界是可以用流程图画清楚的。

AI产品经理管的是不确定性下的判断力

模型的输出是概率性的——同一个问题问两次，可能得到两个不同的回答，这不是bug，是特性。用户的行为是涌现的——你没办法预判他会怎么用你的产品。模型的能力是流动的——三个月前做不到的事，现在可能已经做到了；三个月前能做到的事，新版本可能表现又不一样了。

有一个比喻我觉得很准：传统PM像建筑师，图纸画好就照着盖；AI PM更像种地的——种子每年都在变，天气你控制不了，你能做的是搞清楚什么节气该干什么活，以及怎么判断哪一垄长得不好需要补救。

这个思维方式的转变，是进入这个领域最重要的第一步。在这之前学再多的技术名词，都只是在用旧地图走新路。

产品经理的基础能力：进AI领域之前，这些先想清楚

我有一段时间急着去学RAG、学Agent，结果发现连用户故事怎么写、需求文档的结构是什么都还没搞清楚。就像想学做菜，却跑去研究分子料理——地基没打，楼盖不稳。

这个弯路让我意识到一件事：AI只是在产品经理的地基上加盖了新楼层，地基本身没有捷径。

无论做哪个方向的产品经理，有几件事是必须先想清楚的。

需求分析是核心中的核心

用户真正想要的是什么？他说的需求和他真实的痛点是不是一回事？在AI产品里，这个问题更难回答——因为用户自己也不知道AI能帮他做什么，你需要替他想清楚

我遇到过一个很典型的情况。做智能客服的产品，用户反馈说"回答太机械"。你如果只听字面意思，就会去改措辞、加语气词。但如果你追问几个"为什么"，会发现用户真正的问题是——它不理解我的上下文，每次都要从头解释。这两个问题，解决方案差了十万八千里

在AI产品里，这种需求分析能力被放大了，因为用户对AI的预期往往不清晰，他们说的和他们想要的，经常是两件事

沟通能力在AI产品里变得更重要，不是更不重要

你需要跟工程师讲清楚你要什么效果，需要跟业务方解释为什么AI的输出"有时候不稳定"是正常的，需要跟用户管理预期

特别是"管理预期"这件事，我觉得是AI产品经理最容易忽视的一个技能。

很多用户对AI的理解，来自科幻电影和媒体报道。他们要么觉得AI无所不能，要么觉得AI一无是处。这两种极端预期，都会导致产品体验的崩塌——前者会失望，后者根本不会用。

怎么在产品界面上、在引导文案里，把用户的预期调到一个"合理且积极"的区间，这是纯产品设计的问题，跟技术没关系，但会直接影响留存。

PRD的写法在AI产品里也发生了变化

传统PRD写"用户点击后走这个流程"，AI产品的PRD要写"这个场景下期望的效果是什么，接受率的底线是多少，什么情况算失败"。

从确定性的流程描述，变成概率性的效果定义。这个转变，听起来简单，但真的要写的时候，很多人会发现自己根本不知道"效果好"和"效果坏"的边界在哪里。

举个具体的：你在做一个智能摘要功能，你怎么在需求文档里定义"摘要质量合格"？这个问题没有标准答案，但你必须给出一个可以测量的标准，否则上线之后什么叫成功、什么叫失败，没有人说得清楚。

用户思维始终是第一位的

这说起来是废话，但在AI产品里这句话会被反复考验。

因为AI太好玩了，太有趣了。你很容易就陷进去，花大量时间去研究模型的技术细节，测各种参数，搞各种实验，然后忘记了——这个东西要给真实用户用，他们才不管你用的是哪个模型、参数调成什么样，他们只在意"这个东西有没有帮我节省时间"。

我在学习初期就踩过这个坑。对着提示词调了一个星期，得意洋洋地跑去问朋友感受，对方说：输出太长了，我没时间读完。整个研究成果被一句话否定。但这句话是对的。

AI产品的核心认知：你必须先懂这几件事

这是我目前学得最用力的部分，也是我最想分享的部分。我不打算用教科书的方式写，我只想告诉你我是怎么理解这些东西的。

Token与上下文窗口：模型的"工作记忆"

第一次看到Token这个词，我以为是什么加密货币相关的东西。后来才知道，它是大模型处理信息的最小单位——不完全等于一个字或一个词，但可以大致这样理解，一个汉字差不多对应一到两个Token。

更重要的概念是上下文窗口。你可以把它理解成模型的"工作记忆"——它在回答你的问题时，能同时"看到"多少内容。

比如一个32K上下文窗口的模型，大概能处理两万字左右的中文内容。超出这个范围，它就"忘了"前面说了什么。

这个"遗忘"不是模型坏了，是它的工作机制就是这样。你跟它聊了很久，前面的内容超出窗口之后，它就像一个记忆力有限的人，开始只记得最近说的话，忘了对话一开始你交代的背景。

对产品设计的影响是直接的：你想做长文档解读、合同审核、多轮对话，首先要搞清楚上下文窗口的上限。窗口上限就是你产品功能的天花板。

另一个影响是成本。

几乎所有大模型的商用接口都按Token计费。你设计的每一个功能，每一次对话，都在花钱。这不是工程师该考虑的问题，是产品经理必须算清楚的账。

我见过一个反面案例：一个做智能阅读的产品，用户每次上传文档都会把整篇文档塞进上下文，然后开始对话。听起来很合理，但他们没算过每次对话的Token成本，上线之后发现用户越活跃，亏的越多。最后不得不加限制，用户体验一落千丈。

所以作为产品经理，你不需要会写代码，但你必须知道Token是怎么消耗的，你的功能设计会带来多少消耗，这些消耗的成本是否可持续。

RAG：给模型配一本"可以查的书"

这个概念让我想了很久。

大模型有一个天然的问题：它的知识是训练时"学进去"的，训练结束后就固定了。你问它最新的政策、你公司内部的文档、昨天发生的事情，它要么不知道，要么"幻觉"——也就是一本正经地编一个听起来合理但完全错误的答案。

幻觉这个词，我第一次听到的时候觉得很有意思。模型不知道自己不知道，所以它不会说"我不清楚"，而是会生成一个听起来流畅的答案，但这个答案是它"想象"出来的。

RAG（检索增强生成）解决的就是这个问题。它的逻辑很简单：不让模型背知识，而是给它一本可以查的书。

用户提问的时候，系统先去知识库里找最相关的内容，然后把"用户的问题 + 找到的内容"一起交给模型，让模型基于这些内容来回答。这样模型就不需要"记住"所有东西，只需要"理解和表达"。

对产品经理来说，懂RAG意味着什么？

意味着当用户反馈"回答不准、瞎编"的时候，你知道问题大概率出在哪里——是文档切片方式不对，还是检索匹配度不够，还是召回的内容太杂。你能给工程师提出有价值的优化方向，而不是只会说"把准确率提上去"。

我之前看到一个产品的用户投诉：问合同里的违约金条款，模型给了一个完全错误的数字。后来排查发现，不是模型幻觉，而是文档切片的时候把一个表格切断了，关键数字被切到下一片，没有被召回。这个问题，不懂RAG的产品经理根本不知道从哪里入手。

还有一件事关于RAG很值得专门说一下：知识库的质量决定了产品的上限。

很多团队把精力全放在模型调优上，但知识库里的文档是几年前的、格式乱的、有错误的。这就像给一个很厉害的厨师，提供了一堆变质的食材——厨师再好也做不出好菜。

这个道理说起来简单，但在真实的产品开发里，知识库的建设和维护经常是最不受重视的环节。产品经理如果理解RAG，就应该把知识库的质量管理纳入产品的核心指标，而不只是去看模型的各种评测分数。

提示词工程：给模型写"需求文档"

很多人对提示词的理解，还停留在"网上抄几句万能咒语"。但我学到的是：提示词就是你给模型写的需求文档。

你在提示词里定义模型的角色（它是谁）、任务（它要做什么）、约束（它不能做什么）、输出格式（它应该怎么呈现结果）。写得越清晰，模型的输出越稳定。

这个类比我觉得特别准。一个写得很烂的需求文档，开发出来的功能会跑偏；一个写得很烂的提示词，模型的输出会发散，甚至走向你完全不想要的方向。

有一次我想让模型帮我总结一篇会议记录，随手写了"帮我总结一下这个会议"。结果模型给了我一段很长的叙述，把会议里的废话也总结进去了，格式也乱。

后来我改成：角色定义是专业的会议助理，任务是提取决策事项和待办清单，格式是分两个部分，每部分不超过五条，只保留有明确结论的内容。

同样的模型，同样的会议记录，输出的质量天壤之别。

这对产品经理来说是一个直接的控制手段——你不需要改代码，不需要重新训练模型，只需要优化提示词，就能显著改变产品的表现。这是AI产品独有的"无代码调优"能力。

我目前在学一个叫CRISPE的提示词框架，把角色、背景、指令、风格、约束、示例都写清楚。用这个框架写出来的提示词，比随手写的效果要稳定得多。有兴趣的话可以自己去搜，内容很多，实操性很强。

顺便说一个容易踩的坑：提示词写长不等于写好。

我一开始以为提示词越详细越好，后来发现写得太长太复杂，模型反而会顾此失彼，某些重要的约束会被"淹没"。提示词是有侧重的，你最不想要模型做的事情，要用最明确的方式写出来，放在显眼的位置。

这个感觉很像在做产品设计——不是功能越多越好，是主次越清晰越好。

智能体：从"回答问题"到"完成任务"

这是我目前理解得最模糊的一个概念，但我觉得模糊本身就是一种诚实的状态——这个领域的边界本来就还没画清楚。

如果说大模型是一个很聪明的大脑，那智能体就是给这个大脑配上了手脚、记忆和行动能力。它不只是回答你的问题，而是能够主动规划、调用工具、执行步骤、完成任务。

举个例子，你说"帮我策划一次日本旅行"。

一个普通的大模型会给你一段文字建议，内容可能不错，但需要你自己去执行每一步。

一个智能体会主动问你预算和偏好，然后去查航班价格、查酒店、查景点开放时间，生成一份附带具体价格和预订链接的行程表，最后把一份可以直接用的旅行计划交给你。

差别在于：模型是在"给你信息"，而智能体是在"替你完成事情"。

目前智能体的能力已经很强，但边界也很清晰——它在处理复杂的、多步骤的任务时仍然会出错，需要人来介入和校验。作为产品经理，你需要知道什么场景适合用智能体，以及当它出错的时候，产品应该怎么设计兜底方案。

这个兜底设计，我觉得是目前大多数智能体产品做得最差的地方。

很多产品把智能体包装得很厉害，但当它出错的时候，用户不知道哪里错了、错在哪一步、怎么纠正。结果用户的处置方式就是关掉页面不再用了。这是产品设计的问题，不是技术问题。

模型能力的边界：你需要有"手感"

这是我觉得最难学、也最关键的一点。

懂Token、懂RAG、懂提示词，这些都是可以通过读文章学到的知识。但对模型能力边界的感知——也就是"这件事当前的模型能做到吗？做到什么程度？"——这个判断力，只能靠自己动手积累。

我目前的状态是：我知道这件事很重要，但我的手感还很弱。我会把一个需求交给模型，然后发现它做得比我预期好很多，或者差很多，但我说不清楚为什么。这个"说不清楚"，就是我现在的知识缺口。

有一个词我在一篇文章里看到过，叫"Model Sense"——对模型能力的体感。作者说这是AI产品经理最底层的能力，也是最难速成的，只能靠亲手写过几千条提示词、调过几十个任务之后形成的肌肉记忆。

我深以为然，也深感自己目前还在这条路的起点。

这里有一个很现实的问题想聊一下：作为产品经理，要不要学编程？

我的个人答案是：不一定要学会写代码，但一定要能看懂逻辑。

你不需要自己去写一个RAG系统，但你要能理解"文档切片——向量化——检索——召回——生成"这个链路里，每一步的输入输出是什么，可能在哪里出问题。这样你才能和工程师有效沟通，才能在出问题的时候快速定位。

很多技术概念，不写代码一样可以理解，区别只是理解的深度。我目前选择的路径是：先把概念理解到"能用人话解释给别人听"的程度，然后通过实际使用产品和分析产品来积累手感，暂时不去深入代码层面。

这个策略对不对，我还不确定。但这是我现在的判断。

学这些东西，我目前最真实的感受

写这篇文章的过程，本身就是一次暴露。

写到上下文窗口那一段，我意识到我对Token的计算方式其实只有模糊的概念，没有真正算过一个完整产品的Token成本。写到RAG那一段，我发现我能讲清楚它是什么，但如果真的要让我去设计一个RAG系统的文档切片方案，我会卡住。写到Model Sense，我承认我现在就是那个"把模型当黑盒"的人。

这不是谦虚，是事实。

但我发现，写下来和记在脑子里是完全不同的两件事。写的时候才知道自己哪里真的懂了，哪里只是以为自己懂了。

这篇文章让我的知识地图变清晰了一点，同时也让我看见了更多空白的格子。这种感觉有点像——你以为房间很整洁，打开灯才发现角落里全是灰尘。但看见了总比看不见好。

我在一个奇怪的中间地带：知道的刚好够多，但多到可以看见自己不知道的有多少。我不是专家，但我也不是完全的门外汉。

我认为这个位置写出来的东西，可能比专家讲的更容易被刚入门的人接受。专家经常犯一个错误，就是忘记了他们也有过不懂的阶段，他们讲的东西对他们来说很简单，但对刚入门的人来说仍然是一堵墙。我还没走远，我记得墙在哪里。

还有一件事我想说：这个领域的学习，不是一个"学完就结束"的过程。

你不需要等到"学完"再开始做，你可以边学边做，边做边学。我写这篇文章的时候，我还在学。我发出这篇文章的时候，我还在学。这没有什么不好意思的。

给同样在路上的你

AI这个领域，知识更新快，但核心框架是相对稳定的

Token、上下文、RAG、智能体、提示词工程——这些概念不会因为下一个模型发布就过时，它们是这个领域的地基。先把地基搞清楚，再去追那些日新月异的新东西，会更有底气

有时候我也会觉得，这个追日的过程是不是太累了。

信息流每天都在更新，新工具每周都在涌现，你刚搞懂一个框架，另一个更厉害的已经出来了。有一段时间我焦虑得很，觉得自己永远学不完。

后来我换了一个思路：我不需要追上太阳，我只需要比昨天的自己跑快一点。

夸父最后累倒了，但他手里那根木杖，变成了一片桃林。这个结局，我觉得挺好。

写这篇文章让我想到一件事：这个领域里，愿意把自己"还没学完"的状态公开出来分享的人，其实不多。大家更愿意等到"学成了"再出来说话。但对于刚入门的人来说，一个比你早几步的同行者，有时候比一个遥不可及的专家，更有参考价值。

所以我写了这篇。不完整、有缺口、有些地方只能说"我还不确定"。但这是我现在真实的状态。

如果你也在这条路上，欢迎一起走。我打算把后面学到的东西继续写出来，RAG在真实产品里怎么落地、提示词工程的实战案例、以及那些我踩过的坑。一格一格地填，慢慢来。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】