行业知识 · v2.3.0 · 资料核对 2026-10-03
AI 产品经理
一句话定义
AI 产品经理把真实用户问题转化为可持续的 AI 产品结果，并对价值、体验、指标、风险和路线图负责。
“AI”不是职位装饰。与普通软件产品相比，AI PM 要额外管理五种不确定性：
- 能力不确定：同一输入可能得到不同输出，长尾错误难以穷举。
- 数据不确定：分布、质量、标注、授权和反馈会改变效果。
- 评测不确定：很多任务不存在唯一正确答案，自动评分也会偏。
- 成本不确定：输入长度、推理强度、工具调用和重试改变成本。
- 治理不确定：模型、供应商、法规和攻击面持续变化。
AI PM 不是什么
- 不是只会写提示词的人。
- 不是模型供应商的功能搬运工。
- 不是把算法结论翻译给业务的传声筒。
- 不是必须亲自训练模型的算法工程师。
- 不是只对“功能按时上线”负责的人。
AI PM 的核心产出是一组有证据的产品决策：为谁解决什么问题，为什么用 AI，什么效果才算有用，失败如何处理，成本能否成立，风险是否可接受。
工作全景
| 阶段 | 关键问题 | 主要产物 |
|---|---|---|
| 战略 | 哪些业务能力会因 AI 改变？ | 市场/能力地图、路线图、投资主题 |
| 发现 | 用户最昂贵、频繁、可验证的任务是什么？ | 访谈、JTBD、旅程、机会池 |
| 论证 | AI 是否优于规则、搜索、人工或不做？ | 基线、价值假设、商业论证 |
| 定义 | 输入、输出、边界、失败、权限是什么？ | AI PRD、原型、数据与评测需求 |
| 方案 | Prompt/RAG/微调/Agent 如何取舍？ | 架构草图、模型评分卡、ADR |
| 构建 | 怎样缩短学习周期而非只追功能进度？ | 实验 backlog、黄金集、错误分类 |
| 上线 | 什么证据足以放量？ | 门禁报告、灰度方案、回滚与运营手册 |
| 运营 | 价值、质量、成本和风险是否持续健康？ | 指标树、漂移监控、反馈闭环、路线图 |
日常工作节奏
每天
- 看产品、模型、成本和安全告警，不只看 DAU。
- 抽样真实输入输出，阅读失败样本。
- 清除阻塞，确认实验结论是否可复现。
- 与用户、客服、销售或运营保持一手反馈通道。
每周
- 评审机会/实验 backlog；淘汰证据弱的想法。
- 做错误分类：知识缺失、检索失败、指令误解、推理错误、工具失败、体验失败或政策拦截。
- 与算法/工程看质量—延迟—成本 Pareto 前沿。
- 更新风险、决策日志和路线图，不让口头决定消失。
每月/季度
- 复核北极星指标、留存、单位经济和用户分群。
- 重新跑回归评测；检查供应商和模型升级影响。
- 复盘事故、投诉和未被采用的输出。
- 重新评估 Build/Buy/Partner、法规和竞争格局。
AI PM 的十项硬能力
- 问题定义：把“做个机器人”还原为用户任务、触发、约束与结果。
- 基线思维：先测现有人工/规则流程，再证明 AI 增量。
- 数据判断：识别数据是否可得、可用、可授权、可持续。
- 模型素养：理解能力边界、上下文、采样、微调、RAG 与 Agent。
- 评测设计：用真实分布、分层切片和明确 Rubric 衡量端到端任务。
- AI UX：把置信、引用、纠错、确认、撤销和人工接管做进体验。
- 系统权衡：在质量、延迟、成本、隐私和锁定之间做决策。
- 实验能力：区分离线进步、线上因果和业务结果。
- 治理能力：威胁建模、风险分级、文档追溯和事故响应。
- 跨职能领导：让业务、设计、数据、算法、工程、法务在同一目标下工作。
最关键的判断框架：是否应该用 AI
依次回答：
- 任务是否需要对非结构化信息进行理解、生成、预测或决策？
- 规则方案是否已经足够稳定、便宜、透明？若是，优先规则。
- 容错空间多大？错误能否被发现、纠正和撤销？
- 是否有代表性数据和可操作的评测方法？
- AI 改善是否足以覆盖集成、推理、治理和变更成本？
- 用户是否愿意改变行为并信任这种协作方式？
- 最坏损害是否可被权限、确认、人工复核或拒答控制？
适合的早期场景通常具备：高频、高耗时、信息密集、有反馈、错误可逆、有人工基线。高自主、高损害、不可逆、责任模糊的场景应晚做或不做。
产品指标不能只有准确率
建立五层指标：
| 层 | 示例 |
|---|---|
| 业务结果 | 收入、成本节省、处理时长、转化、风险损失 |
| 用户任务 | 任务完成率、采用率、节省时间、编辑距离、复用率 |
| AI 质量 | 正确性、忠实性、相关性、完整性、拒答正确率 |
| 系统质量 | P50/P95 延迟、可用性、错误率、恢复时间 |
| 经济与风险 | 单任务成本、毛利、人工复核率、严重事件率、泄漏率 |
北极星指标应反映用户获得的结果。例如“被坐席采纳且无需重大修改的有效答复数”，通常优于“生成次数”。
资历层级
| 层级 | 典型范围 | 证明方式 |
|---|---|---|
| 初级 | 一个明确功能或实验 | 按指导完成发现、PRD、评测和复盘 |
| 中级 | 一个端到端场景 | 独立权衡模型、体验、指标和上线 |
| 高级 | 多场景产品线 | 做路线图、平台复用、跨团队资源取舍 |
| 负责人 | 产品组合与组织能力 | 对 P&L/战略、治理体系和人才负责 |
常见失败与纠偏
- 从模型找场景 → 从用户最昂贵的任务和现有替代方案出发。
- Demo 即成功 → 在真实分布、真实权限和真实流量上验收。
- 平均分掩盖高风险长尾 → 按用户、语言、任务和风险切片。
- 用“用户会检查”转移责任 → 设计可检查性、确认点和人工兜底。
- 每次迭代只换模型 → 先定位是数据、检索、提示、工具、体验还是流程问题。
- 上线后没有评测集演进 → 把投诉、失败和新分布回灌为回归用例。