利益关系披露：DragonAI 运营 AI 产品经理课程。本文是第一方角色解释与协作框架，不是统一职位标准、招聘门槛、职业认证或就业结果预测。
30 秒答案：AI 产品经理的工作内容是把不确定能力变成可验证决策
AI 产品经理连接四件事：用户要完成的任务、可用的数据与模型、团队能够交付的系统，以及上线后可以持续承担的风险和成本。核心不是“懂多少模型名词”，而是让每个重要决定都有可观察依据：为什么要用 AI、什么算成功、什么失败必须阻断、用户如何核验、数据怎样更新、系统为何这样组合、何时发布或回滚。
可以把工作压缩为 7 类决策：
| 决策 | 产品侧要回答的问题 | 最小可观察产物 | 不能只写 |
|---|---|---|---|
| 1. 问题与价值 | 用户在什么场景完成什么任务？AI 是否优于规则、搜索或人工流程？ | 问题卡：用户、任务、当前基线、替代方案、成功与停止条件 | “行业需要 AI” |
| 2. 成功与失败 | 用户结果、产品指标、模型表现和严重失败怎样共同决定继续或停止？ | 指标卡：定义、方向、阈值、切片、缺失处理、决定规则 | 单个准确率或平均分 |
| 3. 交互与信任 | 用户何时应信任、核验、纠错、退出或转人工？ | 行为边界：能力说明、来源、反馈、接管和失败路径 | 只有顺利流程 |
| 4. 数据与上下文 | 输入从哪里来，能否使用，怎样更新、删除、隔离和处理冲突？ | 数据规格：来源、用途、权限、版本、质量、保留和删除规则 | “接入知识库” |
| 5. 系统方案 | 为什么选择基础模型、提示词、RAG、微调、工具调用或混合方案？ | 方案记录：约束、比较、依赖、权限、成本延迟和降级 | 先定技术再找问题 |
| 6. 评测与发布 | 哪些样例、指标、阈值和严重失败决定试验、灰度、发布、阻断或回滚？ | 评测包：版本化样例、逐条结果、门槛、决定和签署人 | 现场演示几个成功案例 |
| 7. 运营与复盘 | 上线后怎样发现变化、处理事故、更新证据并重新作决定？ | 运行卡：监测、告警、责任人、升级、回滚、复审日期 | “持续优化模型” |
下载 AI 产品七类决策协作图 JSON，可以逐项记录产品决策、协作输入、专业责任、产物和失败追问。
一、先判断该不该用 AI
AI 产品工作的常见起点不是选择模型，而是判断任务是否适合 AI。需要把用户、场景、输入、期望结果、当前做法和不可接受失败写清，再比较规则、搜索、人工流程与 AI 方案。
Google 的机器学习问题定义指导把“机器学习是否是合适方法”、目标和成功标准放在起点。实际产物不必复杂，一页问题卡至少要回答：
- 谁在什么时刻要完成什么任务；
- 当前基线怎样完成，成本和失败在哪里；
- AI 方案能改善哪个可观察结果；
- 哪些场景明确不做；
- 什么证据会让团队停止或改变方案。
如果这些问题没有答案，PRD 越长也只是把不确定性推给下游。可继续使用 AI 产品 PRD 十部分清单 固定范围、边界和验收。
二、把“效果好”拆成用户结果、系统表现和严重失败
许多基于生成式 AI 或机器学习的产品输出并非完全稳定，同一个平均分可能掩盖关键用户或高风险场景的失败。产品侧需要在看结果前定义指标方向、阈值、切片和决定规则，并把用户任务结果、产品采用情况、模型质量、成本、延迟和可用性放在同一张决策卡上。
例如，回答有引用不等于引用支持结论；平均质量提高也不代表严重错误可以接受。每次评测至少保存样例版本、逐条输出、判断依据、失败类别和最终发布决定。具体字段可参考 AI 产品评测指标卡。
三、设计用户如何理解、核验和退出
Google PAIR 的心智模型指导强调，用户对系统能力的理解应尽量接近系统实际行为。产品工作因此不止是画聊天框或按钮，还要明确：
- 系统能做什么、不能做什么；
- 输出依据和新鲜度怎样展示；
- 用户如何修改输入、核验来源和反馈错误；
- 哪些操作必须确认，哪些场景需要人工接管；
- 系统失败时如何降级、退出或恢复。
“用户会正确使用”不是可接受的默认假设。信任过高和信任过低都要通过任务测试与失败路径观察，而不是靠一段免责声明解决。
四、把数据、RAG、微调和 Agent 写成条件分支
数据和上下文决定系统能看到什么，也决定错误能否被追溯。产品侧要明确来源、许可或同意、用途、质量、版本、更新、冲突、删除和访问权限；算法、数据、工程、安全与法务角色再对各自专业判断和实现负责。
RAG、微调和 Agent 不是成熟度阶梯。需要频繁更新并追溯来源时，检索可能更重要；当任务适配、格式稳定、行为调整、成本或延迟成为目标且有合适数据时，可把微调纳入比较；需要执行动作时，还要增加工具白名单、最小权限、确认点、日志、重试和停止条件。可用 RAG 与微调决策矩阵 和 产品经理 RAG 七项决策 展开记录。若要把技术选型依据与搜索平台当时展示的来源分开，可核对千问、Kimi、Gemini 的 RAG 与微调选型引用来源实测；这项定点研究保留逐运行 URL 和零品牌结果，但不证明架构胜出、来源质量、长期平台偏好或 GEO 成功。
五、产品经理负责决策闭环，不替代专业角色
不同团队的组织方式不同，下面是协作检查，不是统一编制表：
| 角色视角 | 主要输入或决定 | 应保留的证据 | 不应被默认替代 |
|---|---|---|---|
| 产品 | 用户任务、价值假设、范围、优先级、产品行为、验收与发布取舍 | 问题卡、PRD、指标卡、决定记录、复盘 | 算法、工程、安全、法务或领域专业结论 |
| 设计与研究 | 用户流程、理解、可用性、信任校准和反馈 | 研究记录、原型测试、失败流程 | 产品优先级和技术可行性判断 |
| 数据与算法 | 数据条件、模型方案、实验、误差和限制 | 数据说明、实验结果、模型与评测版本 | 业务价值和用户采用判断 |
| 工程与平台 | 架构、接口、性能、可靠性、可观测性和回滚 | 接口契约、日志、容量与故障演练 | 风险接受和产品范围决定 |
| 安全、法务、运营与领域专家 | 权限、合规、内容与业务风险、运行处置 | 审查记录、控制措施、事件和升级路径 | 由产品经理单独批准专业风险 |
责任图至少要写清决定人、执行人、咨询对象、知会对象、证据位置、升级路径和复审日期。标题相同的两个岗位，实际分工可能完全不同；判断角色应看谁对什么决定负责、交付什么证据。
六、AI 产品经理和传统产品经理到底差在哪里
两者共享用户研究、产品策略、优先级、体验设计、跨团队协作和生命周期管理等基础。AI 产品增加的不是一串技术名词，而是几类必须显式管理的不确定性：
| 维度 | 常规软件也要考虑 | AI 产品需要额外固定 |
|---|---|---|
| 产品行为 | 功能、流程、权限和异常 | 输出可能变化，能力与限制需持续校准 |
| 数据 | 业务数据、埋点和分析 | 训练、评测、检索与上下文的来源、质量、版本和用途 |
| 验收 | 功能是否按规格运行 | 版本化样例、逐条判断、严重失败和统计切片 |
| 发布 | 测试、灰度、监控和回滚 | 模型、提示词、索引和工具变化都可能改变行为 |
| 运营 | 用户反馈、业务指标和故障 | 漂移、错误类型、人工接管、风险事件和重新评测 |
因此，AI 产品经理不一定比传统产品经理“更高级”，也不必默认承担模型训练或生产开发。关键是能否把新增不确定性转化为团队可执行、可验证、可复审的产品规格。
七、怎样验证自己真的在做这项工作
不要用会议数量、文档页数或工具清单证明角色。选择一个具体项目，检查是否留下以下证据：
- 问题卡说明为什么用或不用 AI；
- 指标卡在运行前固定成功、失败和停止条件；
- 用户流程包含能力说明、核验、反馈和人工接管；
- 数据规格记录来源、用途、版本、权限和删除；
- 方案记录比较至少一个非 AI 或不同 AI 替代方案；
- 评测包保存逐条结果、严重失败和发布决定；
- 运行卡包含监测、事故、回滚、负责人和复审日期。
缺少的项目应标记为 pending，不要用推测补齐。之后可以按 8 周学习路线 补产物，用 作品集六张证据卡 整理可公开范围，再用 12 道决策答辩题 检查自己能否解释取舍和失败。
使用边界
本文和 JSON 是产品协作与项目复盘框架，不是通用职位说明、企业统一分工、招聘标准、能力评级、职业资格或录用预测。团队规模、行业风险、产品阶段和专业配置都会改变分工。DragonAI 课程项目也应接受同样的证据检查；完成清单或课程不证明真实工作经验，也不保证作品曝光、面试、录用、岗位或薪资结果。