协作与持续学习：AI 产品经理的成长引擎

AI 产品经理的产出，是团队的“接口质量”

你不直接训练模型，也不写代码，你的价值很大程度体现为团队接口的质量：需求是否清晰、技术评审是否问到点上、trade-off 是否拍得有依据。另一半成长来自持续学习——这个领域半年一换代，学习系统本身就是竞争力。

与算法/工程/设计协作

如何提需求：给问题与标准，不给方案

• 描述问题与场景，而非指定技术方案（“长答案被截断时用户流失”优于“把 max_tokens 调大”）。
• 附上可评估的成功标准：一组 bad case、一个评估集、一个可量化目标（如某类问题准确率提升）。
• 提供优先级与背景：影响多少用户、挂钩哪个业务目标，帮助对方判断投入。

如何评审技术方案：问对五个问题

1. 为什么选这个方案，放弃了什么？（看见 trade-off）
2. 用什么评估集验证，结果如何？（防止“感觉更好”）
3. 极端与边界 case 表现如何？（长输入、多语言、对抗性提问）
4. 延迟与成本变化多少？（质量提升常以延迟/成本为代价）
5. 失败时如何回滚？

如何达成 trade-off

质量、延迟、成本构成 AI 产品的“不可能三角”。达成共识的方法不是争论，而是：

• 把选项的数据摆上桌（离线评估 + 小流量结果）。
• 用场景定优先级（客服场景重延迟，医疗场景重准确）。
• 结论写成决策记录（背景/选项/依据/复查时间），避免三个月后重吵一遍。

产品决策提示：trade-off 谈不拢，多半因为缺数据或缺场景定义。回去补齐再开会，不要在会议室里凭偏好投票。

信息源建设

类型	示例	用法
模型/产品更新日志	各家模型的版本发布说明、竞品 changelog	每周固定扫一遍，新能力常直接转化为产品功能
论文与技术报告	模型技术报告、评测基准论文	不求全懂，抓住结论与适用条件
社区讨论	技术社区、即刻/知乎/X 上的从业者	看真实用法与翻车案例，比官方文档更快
公众号/Newsletter	少量精选、定期清理	作为聚合层，避免陷入算法推荐的信息茧房

原则：少而精、可淘汰。信息源每季度清理一次，三个月没带来有效输入的源直接删。

RIO 学习法：Read-Iterate-Output

• Read（读）：带着当前产品的问题读，读完能回答“这对我的产品意味着什么”才算读过。
• Iterate（试）：新能力上手最快的路径是亲手试——用新模型重做产品里的一个小环节，跑自己的 bad case 集，体感远超看评测。
• Output（输出）：写笔记、做内部分享、更新自己的 PRD。输出会暴露理解的模糊处，也是把个人经验沉淀为团队资产的唯一方式。

三步循环：读到 → 在真实场景试过 → 输出结论 → 带着新问题进入下一轮。

构建个人知识库

• 三层结构：原则层（可复用的判断标准）、案例层（决策记录、bad case、竞品拆解）、工具层（Prompt 模板、评估集、常用命令）。
• 绑定工作流：开周会前翻案例层，写 PRD 前翻原则层——用不起来的知识库会迅速荒废。
• 定期重构：每月把散乱笔记归档进三层结构，删掉过时内容。知识库的价值不在收藏量，而在检索速度。

本节要点

• 提需求给问题与可评估标准，不给技术方案；评审方案问评估结果、边界、成本与回滚五个问题。
• 质量/延迟/成本的不可能三角，用数据 + 场景优先级裁决，结论写成决策记录存档。
• 信息源少而精、每季度淘汰；RIO 学习法让输入经过“试用与输出”内化为能力。
• 个人知识库分原则/案例/工具三层，与日常工作流绑定，重在检索速度而非收藏量。