09
AI 团队协作：PM 与工程师的高效配合
AI 团队协作：PM 与工程师的高效配合
AI 产品的成功不仅取决于 PM 的产品思维或工程师的技术能力，更取决于两者之间的高效协作。本章将帮你建立跨角色协作的最佳实践。
本章学习目标
- 理解 AI PM 与 AI Engineer 的能力边界
- 掌握技术评审和需求对齐的沟通技巧
- 建立高效的迭代沟通机制
- 学会处理 AI 项目中的常见冲突
一、角色边界与能力互补
1.1 AI PM vs AI Engineer 能力图谱
AI PM AI Engineer
│ │
┌─────────────────┼──────────────────┬───────────────┼─────────────────┐
│ │ │ │ │
│ 用户研究 │ │ │ 模型选型 │
│ ████████████ │ │ │ ████████████ │
│ │ │ │ │
│ 需求定义 │ │ │ Prompt 工程 │
│ ████████████ │ │ │ ████████████ │
│ │ │ │ │
│ 商业分析 │ 协作区域 │ │ RAG 架构 │
│ ████████████ │ ┌────────────┐ │ │ ████████████ │
│ │ │ │ │ │ │
│ 产品设计 │ │ AI 能力边界│ │ │ Agent 开发 │
│ ████████████ │ │ 评估与规划 │ │ │ ████████████ │
│ │ │ │ │ │ │
│ 项目管理 │ │ 质量标准 │ │ │ 性能优化 │
│ ████████████ │ │ 定义 │ │ │ ████████████ │
│ │ │ │ │ │ │
│ 数据分析 │ │ 迭代优先级 │ │ │ 系统架构 │
│ ██████████ │ │ 决策 │ │ │ ████████████ │
│ │ │ │ │ │ │
│ 技术理解 │ └────────────┘ │ │ 产品感知 │
│ ██████ │ │ │ ██████ │
│ │ │ │ │
└─────────────────┴──────────────────┴───────────────┴─────────────────┘
1.2 职责边界清单
| 领域 | AI PM 主导 | 协作决策 | AI Engineer 主导 |
|---|---|---|---|
| 需求 | 用户价值、优先级 | 技术可行性评估 | 技术方案设计 |
| Prompt | 业务逻辑、输出格式 | Prompt 结构设计 | Prompt 工程优化 |
| 质量 | 验收标准、用户反馈 | 评估方案设计 | 自动化测试实现 |
| 成本 | 预算、ROI 分析 | 成本优化方案 | 技术实现细节 |
| 安全 | 合规要求、风险评估 | 安全策略制定 | 安全机制实现 |
二、需求对齐沟通
2.1 AI 需求文档模板
# AI 功能需求文档
## 1. 需求背景
- 用户痛点：[描述用户当前面临的问题]
- 业务价值：[量化的业务目标]
- 成功指标：[如何判断需求成功]
## 2. 功能描述
### 2.1 用户场景
[描述用户使用该功能的典型场景]
### 2.2 输入输出规范
- 输入：[用户提供什么]
- 输出：[AI 返回什么]
- 格式要求：[输出的结构、长度等]
### 2.3 边界条件
- 必须处理：[核心场景]
- 尽量处理：[扩展场景]
- 明确不处理：[边界外场景]
## 3. 质量要求
- 准确率目标：[如 90%]
- 响应时间：[如 P95 < 3s]
- 安全要求：[如不输出敏感信息]
## 4. 示例数据
| 输入示例 | 期望输出 | 备注 |
| -------- | -------- | ---- |
| ... | ... | ... |
## 5. 技术评估（Engineer 填写）
- 技术方案概述
- 预估工时
- 风险点
- 依赖项
## 6. 验收标准
- [ ] 通过评估集测试（准确率 > 90%）
- [ ] 通过人工抽检（满意度 > 4/5）
- [ ] 满足性能要求
- [ ] 通过安全审查
2.2 需求评审检查点
PM 自查清单：
- 需求背景和价值是否清晰？
- 输入输出示例是否充分？（至少 10 个）
- 边界条件是否明确定义？
- 质量标准是否可量化？
- 是否预留了技术评估空间？
Engineer 反馈清单：
- 技术上是否可行？
- 现有模型能力是否支持？
- 预估工时是多少？
- 有哪些技术风险？
- 需要 PM 补充什么信息？
三、技术评审机制
3.1 评审会议模板
# AI 技术评审会议
## 会议信息
- 日期：2024-01-15
- 参与者：PM (Alice), Engineer (Bob), QA (Carol)
- 时长：60 分钟
## 议程
1. 需求背景介绍 (PM, 10min)
2. 技术方案讲解 (Engineer, 20min)
3. 质量保障方案 (QA, 10min)
4. 讨论与决策 (All, 20min)
## 技术方案概述
[Engineer 填写]
### 方案一：[名称]
- 实现方式：...
- 优点：...
- 缺点：...
- 预估工时：...
### 方案二：[名称]
- 实现方式：...
- 优点：...
- 缺点：...
- 预估工时：...
## 讨论记录
[会议中讨论的要点和决策]
## 行动项
- [ ] [Owner] [Action] [Deadline]
- [ ] ...
## 决策结论
- 选定方案：[方案 X]
- 预计上线时间：[日期]
- 后续风险点：[列出需要关注的风险]
3.2 技术术语对照表
| 技术术语 | PM 友好解释 | 产品影响 |
|---|---|---|
| Token | AI 处理的最小文本单位 | 影响成本和响应速度 |
| Temperature | AI 输出的随机性/创造性 | 越高越有创意但越不稳定 |
| Context Window | AI 能「记住」的最大内容量 | 决定能处理多长的对话 |
| Hallucination | AI 编造不存在的信息 | 影响准确性和可信度 |
| Fine-tuning | 用特定数据训练模型 | 提升特定任务性能，成本较高 |
| RAG | 检索增强生成 | 让 AI 能查询外部知识 |
| Embedding | 文本的向量表示 | 用于语义搜索和相似度 |
| Latency | 响应延迟 | 用户等待时间 |
3.3 技术风险沟通
风险矩阵模板：
│ 低影响 中影响 高影响
────────────┼─────────────────────────────────────
高概率 │ ⚠️ 关注 🔴 重点 🔴 紧急
中概率 │ ✅ 接受 ⚠️ 关注 🔴 重点
低概率 │ ✅ 接受 ✅ 接受 ⚠️ 关注
风险沟通示例：
## 技术风险评估
### 风险 1：幻觉问题
- 风险描述：AI 可能在专业领域编造不存在的信息
- 发生概率：中
- 影响程度：高（可能导致用户决策失误）
- 缓解措施：增加 RAG 引用源，添加人工审核机制
- 责任人：Engineer Bob
- 状态：🟡 进行中
### 风险 2：响应延迟
- 风险描述：复杂问题处理时间可能超过 5 秒
- 发生概率：低
- 影响程度：中（影响用户体验）
- 缓解措施：实现流式输出，优化 Prompt 长度
- 责任人：Engineer Bob
- 状态：✅ 已解决
四、迭代沟通机制
4.1 日常沟通节奏
| 频率 | 形式 | 参与者 | 内容 |
|---|---|---|---|
| 每日 | 异步更新 | PM + Engineer | 进度同步、阻塞问题 |
| 每周 | 站会 | 全团队 | Sprint 回顾、下周计划 |
| 每迭代 | 评审会 | PM + Engineer + QA | 功能评审、技术评审 |
| 即时 | 群消息/会议 | 相关人员 | 紧急问题、决策讨论 |
4.2 沟通渠道规范
紧急程度 ──────────────────────────────────────────────────▶
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 电话 │ │ 即时消息 │ │ 文档 │
│ (紧急问题) │ │ (日常沟通) │ │ (长期参考) │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
│ │ │
▼ ▼ ▼
线上故障 进度更新 需求文档
紧急决策 快速讨论 技术方案
人员协调 问题确认 评审记录
4.3 问题升级机制
问题发现
│
▼
是否 15 分钟内可解决？
│
├── 是 → 直接解决
│
└── 否 → 升级到负责人
│
▼
是否 1 小时内可解决？
│
├── 是 → 负责人协调解决
│
└── 否 → 升级到 PM/TL
│
▼
是否影响上线？
│
├── 是 → 紧急会议决策
│
└── 否 → 排入下个迭代
五、常见冲突与解决
5.1 典型冲突场景
| 冲突类型 | PM 视角 | Engineer 视角 | 解决思路 |
|---|---|---|---|
| 工时分歧 | 「这个功能很简单」 | 「需要考虑很多边界」 | 拆分任务，明确范围 |
| 质量标准 | 「用户说不够好」 | 「已经达到技术极限」 | 数据说话，定量评估 |
| 优先级 | 「先上线再优化」 | 「架构不好后面难改」 | 风险评估，分阶段实现 |
| 技术债 | 「什么时候能还？」 | 「一直没时间」 | 预留固定比例还债时间 |
5.2 冲突解决框架
┌─────────────────────────────────────────────────────────┐
│ 1. 理解对方 │
│ - PM 理解技术约束和风险 │
│ - Engineer 理解业务价值和用户需求 │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 2. 共同目标 │
│ - 聚焦用户价值和业务目标 │
│ - 避免「谁对谁错」的二元对立 │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 3. 数据驱动 │
│ - 用数据而非感觉支撑论点 │
│ - A/B 测试验证方案效果 │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 4. 分阶段实现 │
│ - 先 MVP 验证，再优化迭代 │
│ - 预留技术优化空间 │
└─────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 5. 升级决策 │
│ - 无法达成一致时，升级到上级决策 │
│ - 明确决策责任人 │
└─────────────────────────────────────────────────────────┘
5.3 建设性反馈话术
PM → Engineer：
| 场景 | 不好的说法 | 好的说法 |
|---|---|---|
| 进度落后 | 「为什么又延期了？」 | 「遇到了什么阻塞？我能帮什么？」 |
| 质量问题 | 「用户反馈很差」 | 「这几个 case 能帮我看看吗？」 |
| 需求变更 | 「老板说要改」 | 「业务目标有变化，一起评估下影响？」 |
Engineer → PM：
| 场景 | 不好的说法 | 好的说法 |
|---|---|---|
| 需求不清 | 「需求写得不清楚」 | 「这个场景能给我几个具体例子吗？」 |
| 技术风险 | 「这个做不了」 | 「技术上有 X 风险，我们可以考虑 Y 方案」 |
| 工时紧张 | 「时间不够」 | 「按这个时间，我们可以先做核心功能，其他下个迭代」 |
六、协作工具推荐
6.1 工具组合
| 用途 | 推荐工具 | 使用场景 |
|---|---|---|
| 需求管理 | Linear, Jira, Notion | 需求文档、任务跟踪 |
| 技术文档 | Notion, Confluence | 技术方案、API 文档 |
| 即时沟通 | Slack, 飞书, 企业微信 | 日常沟通、问题讨论 |
| 代码协作 | GitHub, GitLab | Code Review, PR 讨论 |
| AI 实验 | Weights & Biases, MLflow | Prompt 版本、实验追踪 |
6.2 信息同步看板
┌─────────────────────────────────────────────────────────┐
│ Sprint 2024-W03 │
├─────────────────────────────────────────────────────────┤
│ │
│ 📋 待开始 (3) 🔄 进行中 (2) ✅ 已完成 (5) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ FEAT-12 │ │ FEAT-10 │ │ FEAT-08 │ │
│ │ 优化 XX │ │ 新增 YY │ │ 修复 ZZ │ │
│ │ PM: Alice│ │ Eng: Bob│ │ ✓ Merged│ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
├─────────────────────────────────────────────────────────┤
│ 🚨 阻塞问题: FEAT-10 等待第三方 API 权限 │
│ 📌 本周目标: 完成智能推荐功能 MVP │
└─────────────────────────────────────────────────────────┘
七、本章小结
| 维度 | 关键点 |
|---|---|
| 角色边界 | 明确 PM 和 Engineer 的能力范围与协作区域 |
| 需求对齐 | 标准化需求文档，包含示例和边界条件 |
| 技术评审 | 建立评审流程，使用风险矩阵沟通 |
| 迭代沟通 | 固定节奏 + 灵活即时沟通 |
| 冲突解决 | 共同目标 + 数据驱动 + 分阶段实现 |
实战练习
练习 1：需求文档撰写
为「AI 智能客服自动回复」功能撰写一份完整的需求文档，包含所有必要字段。
练习 2：技术评审模拟
模拟一次技术评审会议，分别从 PM 和 Engineer 角度准备材料，识别可能的分歧点。
练习 3：冲突解决演练
场景：Engineer 认为某功能需要 3 周开发，PM 希望 1 周上线。请设计一个双方都能接受的解决方案。