做 AI 产品经理要不要先学编程？不需要。但你要能判断：一次漂亮的演示效果，是否足以支撑产品对用户作出的承诺。这篇文章用一条完整的 AI 产品运行链路，告诉你技术到底要"懂"到什么程度。

上一篇讲了产品经理的入门路线。很多人接着会问：想做 AI 产品经理，是不是要先学编程？RAG、Agent、微调这些概念，是不是都要掌握？

我的回答是：不需要先把自己学成工程师，但必须理解技术会怎样影响产品。

一、争论不休的话题

《人人都是产品经理》作者苏杰老师在2015 年发表的《产品经理要不要懂技术？》文章中，给出的答案很明确：不要求你会 Coding，但至少可以和技术人员无障碍对话。

他的例子很实际：一个改动属于客户端还是服务端，经常变化的文案能不能做成配置，业务变化会不会影响系统设计。

知乎上积累多年的讨论也认为，产品经理“不需要懂技术”。但这里的“不需要”，主要指不要求会写代码。

所以，双方真正争论的不是“要不要学技术”，而是“懂技术到底指什么”。

产品经理不一定要写代码，也不应该替研发决定具体实现。但如果连接口、数据、权限、状态和异常都不了解，很多需求从一开始就没有办法落地。

到了 AI 产品，这个问题更加明显。

一个简历助手能够生成修改建议，不代表这些建议准确。它把“参与项目”写成“主导项目”，接口没有报错，产品却已经出了问题。

因此，AI 产品经理需要懂到的程度是：能判断一个演示效果，是否足以支撑产品对用户作出的承诺。

二、一个 AI 产品怎样运行

举个例子：用户上传简历和岗位描述，系统分析两者差距，再给出修改建议。

用户看到的只是上传文件、点击按钮、得到结果，而产品的路径是：

文件解析 → 准备上下文 → 调用模型 → 检查结果 → 用户确认

每个环节的代码不需要产品经理来写，但要知道每一环可能在哪里出错。

1. 文件解析

用户上传个 PDF 文件，需要做文字识别，还可能出现各种问题：双栏排版可能被打乱，表格内容也可能出现错位。

如果第一步就解析错误，后面的AI再强，输出也没有意义。

所以，产品经理至少要知道输入从哪里来、经过哪些处理、保存在哪里，以及失败后如何提示用户。

接口也是类似的概念。你不一定要写接口，但应该能看懂一次请求传入什么、返回什么，以及失败属于参数错误、权限问题还是服务超时。

2. 准备上下文

包括简历、岗位描述、历史记录和检索结果，提示词则是对任务的具体说明。

产品经理要关注的不是某句提示词写得多漂亮，而是模型这次到底拿到了什么资料。

• 用户删除的内容是否还留在历史记录里？
• 岗位要求有没有更新？
• 无关信息会不会干扰判断？

上下文也要有边界。不是说放进去的内容越多越好，过期资料、重复内容和无关信息，都会增加成本并影响结果。

产品经理需要明确哪些信息应该保留、哪些需要更新，以及资料不足时是否应该让用户补充。

3. 调用模型

模型擅长提取、归纳、改写和生成，但不会天然保证事实准确。

用户写“参与用户调研”，模型可能改成“独立负责用户访谈”。所以，产品经理要先定义边界：哪些内容可以优化，哪些事实不能改写；资料不足时，是要求用户补充，还是允许模型给出推测。

调用模型时，不能只问“用哪个模型”，还要确认模型拿到了哪些资料、任务是否明确、输出格式是否稳定，以及响应时间和调用成本是否可以接受。模型需要参考岗位描述、企业资料或历史记录时，还要确认这些内容确实传入了上下文，且没有使用过期资料。

简单的格式整理，不一定需要最复杂的模型；复杂任务也不能只看价格。产品经理不必亲自调参数，但要能和研发讨论模型适合处理什么、哪些结果需要程序检查，以及失败后如何重试或降级。

4. 检查结果

事情还没完。

系统还需要确认事实有没有被改错，建议是否对应岗位要求，是否出现模型自行补充的经历，以及用户能不能分辨哪些内容只是推测。

“回答准确”“建议有帮助”都太宽泛，不满足验收标准。应该是这样：不能凭空增加经历，建议要有对应依据，缺少信息时要明确提示，用户可以逐条接受或修改。

检查不能只依赖模型自己判断。格式是否完整，可以由程序检查；内容是否合理，需要通过测试样本和人工抽查判断；涉及个人经历的修改，必须交给用户确认。

测试时不要只用整理得很好的简历，也要加入扫描件、资料缺失、经历矛盾和要求编造经历的输入。出现错误后，再判断问题来自文件解析、上下文、任务要求、模型理解，还是页面展示。

速度和成本也属于检查结果。一次任务到底耗时多久、调用多少次模型、需要多少人工返工，决定了这个功能是否真的适合上线。

三、技术学习，要学到什么程度

看完这条链路，你会发现，产品经理不需要亲自实现每一环，但不能只停留在概念层面。

至少应该能看懂一份简单的接口文档，知道请求参数、返回字段和错误码分别意味着什么；能理解一段 JSON 数据，知道数据缺失、格式不对会造成什么后果；也应该知道权限、状态、异步处理这些概念为什么会影响产品设计。

做 AI 产品时，再往前一步，需要理解模型的能力边界。

什么任务适合交给模型处理，什么任务必须由程序或人工确认；什么情况是资料不完整，什么情况是模型理解错误；为什么同一个任务换了模型、提示词或上下文，结果可能完全不同。

不需要一开始就研究模型训练、算法架构，也不必为了显得专业，把 RAG、Agent、微调挂在每个方案里。

真正有用的学习标准很简单：研发讲技术方案时，你能听懂它会影响什么；需求评审时，你能提前发现可能出错的地方；功能上线前，你知道该怎么验证结果。

如果只能背出一串技术名词，却说不清它和用户体验、成本、风险有什么关系，这些知识还没有变成产品能力。

四、怎么补？

跟着真实产品问题补。

比如，你在做 AI 求职助手，就先去弄清楚 PDF 是怎么解析的，模型调用时能传哪些内容，生成结果怎样规定格式，用户修改后数据怎么保存。

做企业知识库，就需要理解资料如何更新、不同员工为什么看到不同内容、回答找不到依据时应该怎么办。

做一个能执行任务的 AI 助手，则需要继续理解权限、确认、工具调用和失败回退。它能帮用户查订单，和它有权替用户退款，完全不是一个难度。

每学一个概念，都可以问自己三个问题：

1. 这个技术解决了产品里的什么问题？
2. 它会带来什么新的限制或风险？
3. 如果它出了错，用户会看到什么？

这样学习，你很快会发现，技术知识不是一张必须背完的地图，而是一套帮助产品经理做判断的工具。