写给想做 AI 应用的产品经理——技术不是最大的障碍
写给想做 AI 应用的产品经理——技术不是最大的障碍
适读人群：想在AI方向发力的产品经理 | 阅读时长：约12分钟 | 核心价值：老张和大量AI项目PM合作之后的真实观察，PM在AI项目里最容易犯的错误和最需要建立的能力
我和很多PM合作过，其中想做AI应用的那些，给我留下了一个很深的印象：他们对AI最焦虑的部分，往往不是最危险的部分。
他们焦虑自己不懂技术、焦虑自己看不懂代码、焦虑向工程师提需求的时候显得外行。这些焦虑可以理解，但它们遮住了真正的问题——很多AI项目做出来效果差或者根本落不了地，不是因为PM不懂技术，是因为PM对另外几件事的判断出了问题。
这篇文章写给那些想做AI应用的PM，说说我真正观察到的问题在哪里，以及实际上需要建立什么能力。
最常见的错误：把"AI功能"当成产品核心
这是我见过最多的问题。
产品文档里写的是："用AI总结用户评论"、"AI智能推荐"、"AI辅助撰写"——这些都以AI为主语。会议里讨论的是"我们要接什么模型API"、"要不要支持语音输入"。
但有一个更根本的问题没人讨论：用户为什么需要这个？他现在是怎么解决这个问题的？AI能比他现有的方式好到什么程度？
有个PM朋友做了一个"AI帮律师写合同"的产品，花了四个月，做出来了，然后发现律师用了两次就不用了。原因是：律师事务所里的合同都是从历年自己的模板改的，AI生成的合同他们不放心直接用，要检查修改的时间比直接从模板改要长。
这不是技术问题，是需求验证问题。在技术开发之前，如果花两周去和五个律师深度聊，可能就不会有这四个月的投入。
AI的存在让很多PM陷入一种迷惑：觉得只要加了AI，就解决了用户问题。但AI是一个能力，不是一个答案，这个能力能不能解决真实的问题，需要回到用户研究里去找答案，跟用不用AI没有关系。
第二个常见错误：对AI能力的预期不准确
我和PM合作，最让我头疼的对话之一是这样的：
PM："我们要做一个AI，能理解用户上传的合同，找出所有潜在的法律风险点，用颜色高亮出来，精准率要达到95%。"
我："……这个95%是怎么定的？"
PM："因为竞品标了90%，我们要超过他们。"
这里有两个问题：一是95%的精准率在法律风险识别这个任务上目前很难做到（不同类型的风险、不同类型的合同，模型能力差异很大）；二是精准率这个指标的定义本身就很模糊——谁来认定一个高亮是"对"还是"错"？
PM经常从"竞品说了什么"或者"用户说想要什么"直接跳到指标要求，中间缺少一个环节：和工程师、和实际的AI能力做校准。
AI能力是有边界的，不同任务的边界差别很大。对话总结比精准的事实提取容易得多；结构化信息提取比开放域问答稳定得多；有明确答案的问题比需要主观判断的问题可靠得多。
PM需要对自己产品里用到的AI能力有一个大致准确的预期，不是要求会写代码，但要知道"大模型在这类任务上的能力上限大概在哪里"。这个认知不需要技术背景，需要的是花时间去试——真的拿你的用例去测几个模型，看实际输出是什么样的。
第三个常见错误：用传统软件的思维设计AI产品
传统软件是确定性的：输入A，输出B，每次都一样。
AI不是。同样的输入，不同的时间可能有略微不同的输出；同样的功能，不同用户的使用方式不同，模型的表现也会有差异；一个月后模型更新了，输出的风格也可能变化。
这个不确定性对产品设计有深刻的影响，但很多PM还在用传统软件的思维来设计AI功能。
最典型的表现： 产品文档里设计了一个AI输出，但没有设计当AI输出不好的时候用户怎么办。
比如"AI生成的周报摘要"——文档里画的是那个漂亮的摘要展示页面。但当AI把这周的核心事项漏掉了、或者表述和事实有偏差，用户有没有地方可以编辑？有没有反馈机制？有没有"不用AI，我自己写"的选项？
这些问题在传统软件里基本不存在，因为结果是确定的。在AI产品里，把不确定性当成设计要素，而不是当成bug处理，是一个根本性的思维转变。
第四个常见错误：忽视数据飞轮的设计
AI产品和传统软件产品有一个本质的不同：AI产品有机会通过用户使用数据来持续改善，传统软件基本没有这个能力。
但大多数PM设计AI产品时，完全没有考虑这件事。
有个具体问题我喜欢问PM："你们这个AI功能，上线三个月后会比上线第一天更好吗？为什么？"
很多人的回答是"模型更新了就会更好"——这是被动的，依赖于模型提供商的更新，不是你主动做了什么。
真正的AI产品应该设计数据反馈循环：用户的行为数据、显式反馈（点赞/踩）、隐式反馈（是否接受了AI的建议），这些数据应该被收集、分析，用来持续优化AI的表现。
这不是工程师的事情，设计反馈机制、决定收集什么数据、用什么方式让用户提供反馈——这是PM的工作。如果你在产品里没有设计这些，AI功能上线就是终点，而不是起点。
PM在AI项目里真正需要建立的能力
说完了错误，说说应该建立什么。
1. 会跑、会测——不是会写代码，是会操作模型
你不需要会编程，但你应该会直接使用大模型的API或者Playground。当你有一个想法，你应该能自己去测试：这个任务，GPT-4的效果是什么样的？Claude呢？DeepSeek呢？在什么类型的输入上效果好，在什么类型的输入上会出问题？
这个能力没有任何技术门槛。打开Claude的API，写一个Python脚本（AI帮你写都行），跑100条真实用户数据，看输出，分析规律。这件事一个周末能学会。
但它带来的认知提升是巨大的：你不再依赖工程师告诉你"能做"或"不能做"，你有自己的一手判断。
2. 建立AI能力的直觉
不同类型的任务，大模型的能力天花板不同。多做几个实际测试，你会积累出一些直觉：
- 文本分类和信息提取：相对可靠，容易做高质量
- 生成式内容（文案、摘要）：质量参差不齐，需要人工审核机制
- 精确的事实查询：需要配合RAG，裸模型容易幻觉
- 复杂推理（如法律判断、医疗建议）：精准率很难保证，需要非常谨慎的产品设计
这个直觉来自动手，不来自看教程。
3. 把"不确定性"纳入产品设计的习惯
每一个AI功能，问自己：当AI表现差时，用户有什么出路？如何让用户知道这是AI的输出，他有权利不信任它？如何收集用户对AI输出好坏的反馈？
4. 和工程师的协作方式要变
不要再问"能不能做"，要问"在什么条件下能做到什么水平"。这是一个更精确的问题，也能让工程师给你更有用的答案。
一个真实案例
有一个做企业内部知识库的PM找我合作，她在行业里做了8年，完全不会写代码，但她是我合作过的AI项目PM里做得最好的一个。
原因是她在需求文档里有一个章节叫"AI能力边界说明"，里面写了：
- 这个功能预期的准确率范围（不是固定数字，是一个区间，来自她自己测试的结果）
- 哪类问题模型会出问题（她测出来的case类型）
- 当模型给出不确定或错误答案时，产品的应对设计
她还有一个"用户反馈收集方案"文档，设计了五种反馈信号的收集方式和后续处理流程。
这是把技术现实和产品设计真正整合在一起的PM。她不会写代码，但她知道AI能力的边界，知道用户在什么时候会遇到问题，知道怎么把这些纳入产品设计。
技术从来不是最大的障碍。最大的障碍是思维方式——从"我要做一个有AI的产品"到"我要用AI解决一个真实的用户问题，并且我要清楚AI在这个过程中的能力和局限"。