工程师怎么和 AI 产品经理合作——我见过的那些冲突和解法

适读人群：在AI产品团队里工作的工程师和产品经理 | 阅读时长：约14分钟 | 核心价值：真实观察到的技术-产品协作模式，有具体解法

去年年底，我参加了一个朋友公司的产品评审会。

那个PM展示了一个用户功能需求：系统要能"理解用户真正想要什么，即使他们描述得不清楚，并且每次都给出准确的个性化推荐"。

我旁边坐的工程师low声说了一句："他描述的是AGI。"

我没笑出来，因为我见过太多次这样的场景。

这篇不是要批判谁，技术和产品之间的分歧有一半是理解问题，不是立场问题。但分歧真实存在，值得认真聊。

---

我观察到的几个典型分歧点

分歧1：对AI能力边界的认知差距

这是最根本的分歧，后面很多问题都从这里派生出来。

PM通常对AI能力有两种倾向，有时候同一个PM两种倾向都有：

过高估计：看了ChatGPT的演示，觉得AI"什么都能做"，于是需求里会出现"让AI自动判断/理解/学习/个性化"这类描述，完全没有对准确率、稳定性、edge case的预期。

过低估计：看到某个AI功能效果一般，就觉得AI不靠谱，对所有AI方案都持怀疑态度，宁愿用规则实现。

这两种倾向都会造成麻烦。第一种让工程师疲于解释为什么做不到；第二种让有价值的AI方案被过早否定。

我见过的一个比较好的解法：

在产品规划早期，工程师和PM一起做一个"AI能力校准"的环节——拿具体的业务案例，跑一遍真实测试，让PM亲眼看到当前AI在这个场景下能做到什么、不能做到什么，以及不确定性在哪里。

这比"给PM讲AI原理"有效得多。PM不需要理解Transformer，但他需要看到：给这100个输入，AI的输出里有哪几个是对的，哪几个是错的，错在哪里。

真实数据的说服力远高于原理解释。

分歧2：对"足够好"的标准不同

工程师通常有一种本能：追求精确，追求100%。AI输出有不确定性，这让工程师不舒服，会自然地倾向于加更多规则、更多校验、更多fallback，直到系统变得复杂且难以维护。

PM通常更看重用户体验整体感受，可以接受一定比例的不完美，但不能接受"功能太慢"或者"功能太复杂难用"。

分歧点在：工程师追求的那个"更高的准确率"，到底值不值那个复杂度代价？

我见过这样一个案例：一个客服分类功能，AI分类准确率95%，工程师花了一个月把准确率提到了97%，代码复杂度翻倍，但那2%的提升对用户体验的改变用户根本感知不到——因为系统本来就有人工审核兜底，95%和97%对最终用户来说没有区别。

这不是工程师的错，是缺少对"足够好"标准的提前对齐。

解法： 在需求阶段就定义"成功指标"——不是"越准越好"，而是"在X场景下，Y%的准确率是可接受的最低标准，超过这个就是bonus"。有了这个标准，工程师知道什么时候可以停止优化，PM也知道什么时候需要提出质量问题。

分歧3：对需求变更的容忍度

AI应用的需求变更问题比普通软件更严重。

原因是：AI应用的产品设计通常依赖于对模型行为的某种预设，当产品方向变了，这个预设可能整个失效。

举例：原来设计是"根据用户历史记录推荐相关内容"，后来改成"推荐用户可能还不知道但会喜欢的内容"——这不只是UI或逻辑的变更，而是检索策略的根本性变化，底层的Embedding逻辑、召回策略、Prompt设计都可能需要重做。

PM往往意识不到这个成本，因为从产品描述上看，改动好像只有一句话。

解法： 我见过效果比较好的做法是"技术影响范围标注"——每个需求变更，工程师在需求文档里附上一段"技术影响范围评估"，说明这个变更会触及哪些系统层（Prompt、检索策略、模型调用、数据处理、前端），大概工作量级别是什么。

这不是为了阻碍变更，而是让PM在决定变更之前有清晰的成本认知。大多数PM在知道"这个改动需要两周"之后，会认真想想这个改动是否值得，或者是否有更低成本的变体。

分歧4：评估标准的主客观矛盾

AI系统的效果评估经常是主观的，或者没有被定义清楚。

"回答质量怎么样？" "那个总结准不准？" "推荐效果好不好？"

这些问题在评审会上经常出现，但大家说的"好"和"准"可能根本不是同一个标准。工程师可能在说"BLEU score提高了5%"，PM可能在说"我自己测了10条感觉还行"，两者之间几乎没有对话基础。

解法： 在功能上线前定义好评估指标，并且是工程师和PM都认可的指标。

对不同类型的AI功能，我见过几种可行的评估方式：

总结/提取类功能：
  - 建立一个"golden set"——50-100个人工标注了正确答案的样本
  - 每次模型或Prompt变更，跑一次golden set，对比分数
  - 分数不是唯一标准，但给了变更的基线

生成类功能（文案、报告）：
  - 定义几个核心维度（准确性、相关性、简洁性），各打分
  - 人工评测小组（3-5人）每周抽样评分
  - 关注分数趋势，而不是单次绝对值

推荐类功能：
  - 用户行为数据说话（点击率、停留时长、转化率）
  - A/B test是正路，但需要有足够的样本量才有统计意义

---

我见过的有效协作模式

模式1："AI能力边界文档"的共同维护

这个方法我见过两个团队在用，效果都不错。

做法是：工程师维护一份内部文档，记录"当前系统里的AI组件，在哪些情况下可以信赖，在哪些情况下会失效"。

不是技术文档，是用产品语言写的，PM看得懂的。

比如：

知识库问答功能 - 能力边界说明（供产品和运营参考）

可靠性高的场景：
- 问题明确指向文档中有明确描述的内容（准确率约90%）
- 用户使用和文档相近的措辞提问

需要人工兜底的场景：
- 需要多份文档综合判断的复杂问题
- 文档更新后24小时内（索引延迟）
- 问题涉及实时数据（价格、库存）

会可靠拒答的情况：
- 文档中完全没有相关内容
- 问题明显超出系统设计范围

这份文档让PM在设计产品流程时有了可信赖的参考，也减少了"这个功能为什么会失败"的反复解释。

模式2：工程师参与产品需求的"可行性预审"

在需求正式进入排期之前，有一个工程师参与的"可行性快速评估"环节，15-30分钟。

工程师的角色不是否决需求，而是回答三个问题：

Q1：技术上做不做得到？（直接判断，不解释太多原理）

Q2：如果能做，在什么约束条件下？（准确率限制？响应时间限制？成本限制？）

Q3：有没有技术方案可以用80%的成本达到90%的效果？

最后这个问题很关键。PM很多时候对"完美实现"和"够用实现"之间的差距没有意识，工程师的角色是提供这个视角。

模式3：Prompt和产品需求的"双向绑定"

这个是我在一个团队里观察到的比较新颖的实践。

他们维护一个专门的"Prompt需求对照表"，每一条核心Prompt规则都对应一个产品需求说明，写明"这条规则是为了解决什么问题，如果移除会有什么影响"。

当产品需求变更时，工程师可以快速找到受影响的Prompt部分；当Prompt效果有问题时，PM可以理解这条规则的业务意义，而不是当成黑盒。

这个实践的好处不只是沟通，它还减少了一种常见的低效：工程师花两周调出来的Prompt效果，因为PM不理解其背后的设计，在"优化"过程中被无意识地破坏掉。

---

我认为最根本的一件事

技术和产品之间的协作问题，大部分不是立场问题，是信息问题。

工程师掌握的信息：技术边界、实现成本、技术风险、系统复杂度。 PM掌握的信息：用户需求、商业目标、优先级、用户体验预期。

两边都在用自己的信息做判断，然后发现另一边"不理解"，其实是另一边没有自己掌握的那部分信息。

所以大部分协作问题的解法不是"谁听谁的"，而是"怎么让两边更快地共享信息"。

工程师可以主动做的事情：把技术约束用业务语言描述，不是"这个实现复杂度太高"，而是"这个实现需要X周，在当前优先级下，有Y和Z两个替代方案可以在X/3的时间内解决核心用户需求"。

PM可以主动做的事情：在描述需求的时候加上"为什么要这样"——不只是"我要A功能"，而是"我要A功能，因为我们的用户在做X的时候有Y的问题，A功能是我想到的解法，但我不一定是对的"。

当PM说出"我不一定是对的"的时候，工程师才有空间提出更好的技术方案。