PM 该不该懂技术实现：AI 功能立项时，产品经理需要懂到「哪一层」？

背景

我做了 5 年技术产品经理，最近半年团队密集做 AI 功能（LLM 应用、智能摘要、对话式搜索）。立项会上我越来越常听到两种声音：

• 工程师说："你连 prompt 长什么样、token 怎么算、什么场景该走 RAG 什么场景该走微调都不知道，需求没法排期。"
• 业务方说："你天天跟我对 token、上下文窗口、幻觉率，说人话，用户到底能少点几下？"

我自己复盘了最近 3 个 AI 项目：有一个因为我在 PRD 里只写了"支持智能问答"，没约定"回答必须给出来源引用、找不到就说找不到"，上线后客服工单里 37% 是"AI 答错了怎么办"；另一个反过来，我把 RAG 的召回阈值、chunk 切分策略都写进了 PRD，研发觉得被越界，评审拖了 2 周。

常见分歧（我观察到的三种做法）

1. PM 只管结果指标：只写"准确率 ≥ 90%、响应 < 2s"，实现完全交给研发。优点是边界清晰，缺点是 AI 的"准确率"定义本身就依赖实现方式，验收时必然扯皮。
2. PM 懂到 prompt 层：参与写 prompt、看 badcase、定 few-shot 示例。优点是需求-实现对齐快，缺点是 PM 容易被 prompt 细节带偏，忘了用户目标。
3. PM 懂到架构层：连 RAG vs 微调、模型选型都要有判断。优点是排期风险看得准，缺点是学习成本极高，且很多判断其实应该由架构师负责。

我的倾向与理由

我倾向第 2 种，但加一条硬约束：PM 必须懂到「验收标准可以机器判定」的那一层，再往下就停。 具体做法是 3 步：

1. 立项前，让研发用 30 分钟讲一遍技术方案的「失败模式清单」（哪些场景必然答错、哪些输入会超时），我把这些失败模式逐条翻译成验收标准（比如"涉及实时库存的问题，必须降级到规则回答并标注"）；
2. PRD 里不写实现，但必须附一份 ≥20 条的 badcase 测试集，每条标注期望行为；
3. 上线后 2 周，我亲自看 100 条真实对话日志，而不是只看看板上的"满意度 4.6/5"。

理由：AI 功能和传统功能的本质差别是输出不可穷举，传统功能可以靠测试用例覆盖，AI 功能只能靠"失败模式 + 边界约定"来收口。PM 不懂实现细节没关系，但必须懂"哪里会失败"，否则验收标准写不出来。

想听大家聊聊

• 你们团队里，AI 功能的验收标准是 PM 写还是研发写？扯皮最多次的是哪条？
• 有没有人试过把 badcase 测试集写进 PRD 当准入门槛？研发接受度高吗？
• 你们怎么定义"PM 懂技术"的及格线？是能画时序图，还是能看懂 prompt，还是能判断 RAG 和微调的取舍？