AI PM 与工程师协作指南
AI 产品成功的关键在于 PM 和 MLE（机器学习工程师）的紧密协作。本文档定义角色边界、协作节点、决策权归属和冲突处理。
1. 角色边界定义
职责矩阵
| 职责领域 | AI PM | ML Engineer | Data 团队 |
|---|---|---|---|
| 用户需求 | 🏆 负责 | 咨询 | — |
| 产品定义 | 🏆 负责 | 技术输入 | — |
| 评估标准 | 🏆 产品级指标 | 🏆 技术级指标 | 数据支撑 |
| 模型选型 | 给约束 | 🏆 负责 | — |
| 训练/微调 | — | 🏆 负责 | 训练数据 |
| Prompt 编写 | 🏆 初版 | 优化 | — |
| 推理优化 | — | 🏆 负责 | — |
| 评估执行 | 人工评估 | 🏆 自动化 | 标注 |
| 数据采集 | 定义需求 | 技术支持 | 🏆 负责 |
| 数据标注 | 定义标准 | 工具支持 | 🏆 负责 |
| 灰度方案 | 🏆 负责 | 技术实现 | 数据支撑 |
| 上线决策 | 🏆 负责 | 评估数据 | 数据支撑 |
AI PM 核心职责
用户需求发现（30%） — 用户访谈、需求排序、竞品分析 产品定义（20%） — PRD、UX 设计、Prompt 初稿、评估标准 评估与迭代（30%） — 构建评估集、人工评估、Prompt 迭代 项目推进（20%） — 跨团队协调、进度跟踪、上线决策
MLE 核心职责
模型选型（25%） — 技术调研、Benchmark、成本预估 模型训练/优化（25%） — Fine-tuning、RAG、推理优化 评估工程（20%） — 自动化管线、指标计算、监控看板 Prompt 技术优化（15%） — 压缩、结构化验证、安全防护 线上维护（15%） — 性能监控、版本管理、灰度实现
Data 团队核心职责
数据采集（30%） — 数据源接入、清洗、脱敏 数据标注（40%） — 标注指南、团队管理、质量控制 数据质量监控（20%） — 分布变化、异常检测、版本管理 数据分析支持（10%） — 用户行为分析、AB 测试统计
灰色地带
| 灰色地带 | 建议解决方案 |
|---|---|
| Prompt 最终责任人 | PM 负责业务，MLE 负责技术，共同 Review |
| 质量门槛标准 | 用数据说话 + 用户测试验证 |
| 迭代优先级 | 设立技术债预算（如 20% 时间） |
| 数据标注标准 | PM 定标准，Data 执行，MLE 自动质检 |
2. 协作关键节点
协作全景图
Week 1-2 │ 产品定义研讨会（PM + MLE + Data Lead）
│ 用户访谈（MLE 旁听）
Week 3-4 │ 模型选型会议 → Prototype 联调
Week 5-6 │ 评估标准对齐 → 评估集构建
Week 7-8 │ Prompt Workshop → 灰度方案评审
Week 9-10 │ 灰度监控晨会 → 问题排查
Week 11-12│ A/B 测试方案 → 上线决策
上线后 │ 定期 Review模型选型会议
会前准备：
| 参与方 | 准备内容 |
|---|---|
| PM | 产品需求文档、成本预算上限、延迟要求 |
| MLE | 候选模型列表、技术参数对比、初步 Benchmark |
| Data | 训练数据预估、标注成本预估 |
会议议程（60-90 分钟）：
- PM 介绍产品需求 — 场景、约束、必须能力（15min）
- MLE 技术方案 — 候选模型对比、推荐方案、备选方案（25min）
- 讨论与决策 — 单模型 vs 多模型分级？需要微调吗？（20min）
- 行动计划 — 验证任务、Prototype 计划（10min）
决策框架：
| 维度 | 权重 | PM 打分 | MLE 打分 |
|---|---|---|---|
| 模型能力 | 35% | — | — |
| 成本 | 25% | — | — |
| 延迟 | 20% | — | — |
| 部署复杂度 | 10% | — | — |
| 合规与安全 | 10% | — | — |
评估标准对齐会议
对齐维度：
| 维度 | PM 视角 | MLE 视角 | 对齐方式 |
|---|---|---|---|
| 准确性 | 用户是否觉得可信 | 与 golden answer 一致 | 共同定评分标准 |
| 有用性 | 用户能否完成操作 | 是否包含所需信息 | 用户测试验证 |
| 流畅性 | 读起来是否自然 | 语法/格式正确 | 人工评分 |
| 安全性 | 是否让用户不适 | 是否触发安全规则 | 自动化检测 |
对齐方法（正例/反例法）：
- PM 准备 10 条示例（5 好 5 不好，标注原因）
- PM 和 MLE 各自对 20 条模型输出独立评分
- 对比评分结果，讨论分歧
- 更新评分标准，形成版本化的评分指南
产品级 vs 技术级指标对应：
| 产品指标（PM） | 关联技术指标（MLE） |
|---|---|
| 用户满意度 | 准确率 + 流畅度 |
| 任务完成率 | 完整率 + 相关性 |
| 用户留存 | 质量一致性 |
| 用户投诉率 | 安全性 + 幻觉率 |
| 首次回答满意率 | 准确率 + 格式合规 |
| 平均交互轮次 | 回答完整率 |
Prompt 协作工作流
PM 写初版（业务逻辑）→ MLE 技术优化（Token 效率、格式可解析）
→ 共同 Review → 评估集验证 → 灰度发布协作示例 — 客服 AI Prompt：
PM 初版（太模糊）："请用友好的语气回答用户的问题"
MLE 优化要点：
- ❌ 无角色边界 → 模型可能超范围承诺
- ❌ "友好"太模糊 → 需具体风格示例
- ❌ 无错误处理 → 不确定时怎么办？
- ❌ 无安全约束 → 可能被用户诱导
MLE 优化后：角色定义清晰 + 能力边界 + 具体风格 + 错误处理 + 安全规则
灰度期间协作
每日流程：
10:00 灰度晨会（15min）：PM 汇报用户反馈/质量抽样，MLE 汇报技术指标，Data 汇报数据质量
→ 结论：继续放量 / 暂停 / 回滚
14:00 用户反馈 Review（30min）：PM 收集当日反馈，MLE 判断是否技术问题
17:00 灰度日报（15min）：汇总状态，决定明日放量计划灰度期 RACI 矩阵：
| 活动 | PM | MLE | Data |
|---|---|---|---|
| 制定灰度计划 | A | R | C |
| 用户分桶 | I | R | I |
| 监控指标设置 | C | R | C |
| 用户反馈收集 | A | I | R |
| 质量问题判断 | R | R | C |
| 放量决策 | A | R | C |
| 回滚决策 | A | A | I |
| 灰度报告 | R | C | C |
R=执行, A=负责, C=咨询, I=知情
3. 决策权归属
决策权总览
| 决策类型 | 流程 | 最终决策者 |
|---|---|---|
| 产品功能 | PM 提议 → 讨论 → PM 决策 | PM |
| 技术方案 | MLE 推荐 → PM 确认 → 执行 | MLE 推荐，PM 赞同 |
| 质量门槛 | PM 提案 → MLE 反馈 → 共同设定 | 共同设定 |
| 优先级排序 | PM 提议 → 协商 → PM 决策 | PM |
| 资源分配 | PM + MLE 提需求 → 管理层确认 | 管理层 |
| 上线决策 | PM 汇总评估 → 团队评审 → PM 决策 | PM |
质量门槛三级机制
| 级别 | 标准 | 决策方式 |
|---|---|---|
| 硬性门槛（P0） | 安全合规、严重幻觉 | 不可妥协 |
| 建议门槛（P1） | 准确率≥90%、延迟≤3s | 双方协商，可调±5% |
| 优化门槛（P2） | 准确率≥95%、延迟≤1s | PM 提目标，MLE 评估可行性 |
4. 冲突处理
冲突类型
| 冲突 | 典型场景 | 原则 |
|---|---|---|
| 成本冲突 | PM 要强模型但预算不够 | Token 经济学 + 分级策略 |
| 复杂度冲突 | MLE 想复杂方案 PM 觉得没必要 | MVP 优先 + 迭代规划 |
| 质量标准冲突 | 对"好"的判断不一致 | 用户测试说了算 |
| 优先级冲突 | PM 要新功能，MLE 要还技术债 | 20% 时间制度 |
| 时间线冲突 | PM 催上线，MLE 说没准备好 | 风险评估 + 备选方案 |
冲突 1：成本冲突
解决：Token 经济学 + 分级策略
分析 token 消耗分布：
简单查询（60%）→ 小模型（GPT-4o-mini）
中等查询（30%）→ 中模型（GPT-4o）
复杂查询（10%）→ 强模型（Claude Opus）
成本：纯 GPT-4o 方案 vs 分级方案 → 节省 60-70%冲突 2：复杂度冲突
解决：MVP 优先 + 迭代规划
Phase 1（4 周）：Prompt + API → 覆盖 80% 场景
Phase 2（4 周）：增加简单 RAG（如果准确率 < 90%）
Phase 3（按需）：Fine-tuning（如果仍有系统性错误）
原则：最小必要复杂度 — 最简单的方法能否解决 80% 问题？冲突 3：质量标准分歧
解决：用户测试说了算
1. PM 提供用户反馈证据，MLE 提供离线评估报告
2. 设计用户测试：A 组用当前模型，B 组用更强模型
3. 用数据决策：
- B 组显著优于 A → PM 对，需提升质量
- 无显著差异 → 当前质量"够好"
- A 组优于 B → MLE 对，当前方案已最佳
4. 根据结果更新评估标准和目标值其他冲突处理
| 冲突 | 处理方法 |
|---|---|
| PM 要上线，MLE 说模型不稳定 | 分段上线，PM 对灰度风险负责，MLE 对稳定性负责 |
| MLE 想做新技术栈 | 设立 10-20% 技术探索时间 |
| 标注质量不满足 | PM + Data 优化标注指南，MLE 自动质检 |
| PM 频繁变更需求 | 设定需求冻结期，变更走控制流程 |
| MLE 低估开发时间 | Buffer + 里程碑跟踪 + 早期预警 |
5. 沟通机制
定期沟通
| 会议 | 频率 | 时长 | 参与人 |
|---|---|---|---|
| 每日站会 | 每日 | 15min | PM + MLE + Data |
| 产品-MLE 同步 | 每周 2 次 | 30min | PM + MLE |
| 迭代评审 | 两周 | 1h | 全团队 |
| 灰度晨会 | 灰度期间每日 | 15min | PM + MLE + Data |
| 模型 Review | 季度 | 2h | PM + MLE + Data |
| 复盘会 | 每版本 | 1h | 全团队 |
信息同步
| 信息 | 格式 | 频率 | 责任方 |
|---|---|---|---|
| 产品路线图 | 看板 | 每月 | PM |
| 技术方案 | 文档 | 每次确定 | MLE |
| 评估报告 | 模板 | 每次评估 | MLE |
| 用户反馈 | 文档 | 每周 | PM |
| 灰度日报 | 模板 | 灰度期间 | PM |
| 版本变更 | Changelog | 每次 | MLE |
决策记录
重要决策必须有记录：
## 决策记录 #XXX
日期：YYYY-MM-DD
决策者：PM/MLE 姓名
背景：[需要做决策的原因]
决策内容：[具体决策]
理由：[为什么这么决策]
备选方案：[其他方案及不选原因]
影响分析：[产品/技术/时间线影响]
后续行动：[行动项 + Owner + DDL]6. 工作流整合
需求到上线完整工作流
PM：需求收集 → PRD → 评估标准 → Prompt 编写 → 评估验收 → 灰度方案 → 上线决策
│ │ │ │ │ │ │
MLE：← 技术评估 ← 模型选型 ← 评估框架 ← 技术优化 ← 自动化评估 ← 灰度实现 ← 技术报告
│ │ │ │ │ │
Data：← 数据评估 ← 评估数据集 ← 数据监控 ← 数据报告工具链
| 领域 | PM 用 | MLE 用 | 共享 |
|---|---|---|---|
| 项目管理 | Linear/Jira | Linear/Jira | ✅ |
| 文档 | Notion | Notion/技术 Wiki | ✅ |
| 代码/版本 | — | Git | ✅ Prompt 版本 |
| 评估 | 人工评估平台 | 自动化管线 | ✅ 结果共享 |
| 监控 | 产品看板 | 技术看板 | ✅ 核心指标 |
| 沟通 | 企业微信/Slack | 企业微信/Slack | ✅ |
7. 常见协作模式
三种模式
| 模式 | 说明 | 适用 | 优点 | 缺点 |
|---|---|---|---|---|
| 嵌入式 | MLE 嵌入产品团队 | 核心 AI 功能 | 沟通效率高 | 资源占用多 |
| 共享服务 | MLE 共享资源池 | 多产品线 | 利用率高 | 沟通成本高 |
| 项目制 | 按项目周期参与 | 一次性探索 | 边界清晰 | 磨合成本高 |
嵌入式协作（推荐）
配置：1 PM × 1-2 MLE（固定配合 > 1 个迭代） 运作：每日站会 + 按需沟通 + 同一空间 + 相同工具 成功关键：MLE 参与产品讨论，PM 理解基本技术概念
建立高效协作
第 1 周 — PM 和 MLE 1-on-1 深度沟通：工作方式、沟通偏好；PM 带 MLE 参加用户访谈；MLE 给 PM 做 AI 科普
第 2-4 周 — 共同完成第一个 Prototype；建立 Review 节奏；理解彼此的约束和节奏
第 4 周+ — 形成稳定协作模式；互相信任；PM 能判断基本可行性；MLE 能判断基本产品逻辑
PM 需掌握的技术概念
| 概念 | 理解程度 |
|---|---|
| Token | "1 个中文词 ≈ 2-3 tokens" |
| 温度 (Temperature) | "温度高→随机性强" |
| 上下文窗口 | "GPT-4o 有 128K" |
| RAG | "先检索再回答" |
| Fine-tuning | "用你的数据训练模型" |
| P50/P99 | "P99 是最坏情况的延迟" |
| Prompt Injection | "用户可能通过输入攻击" |
| Hallucination | "模型会自信地说错话" |