AI 团队协作：PM 与工程师的高效配合
AI 团队协作：PM 与工程师的高效配合
AI 项目最常见的失败方式，不是模型不够强，而是 PM 和 Engineer 从第一周开始就在用两套语言说话。PM 讲 user value、deadline、体验；Engineer 讲 latency、hallucination、token、fallback。两边都没错，但如果没有共同的决策接口，项目会一直卡在“大家都觉得自己说清楚了”。
所以这页的重点不是讲谁该做什么，而是怎么把 AI 项目的协作从抽象讨论，变成可执行的分工和 review 机制。
先说结论：AI 协作最怕的不是意见不一致，而是边界不清
一个健康的 AI team，不需要 PM 懂所有技术细节，也不需要 Engineer 替 PM 定业务优先级。
真正重要的是三件事：
- 谁定义 success
- 谁判断 feasibility
- 谁对 bad outcome 负责
这三件事说不清，后面每次评审都会重复争论。
PM 和 Engineer 该怎么分工才合理
更实用的理解不是“谁更懂 AI”，而是谁负责哪类决策。
| 决策类型 | PM 更主导 | 共同决策 | Engineer 更主导 |
|---|---|---|---|
| 用户问题定义 | 用户任务、业务目标 | 边界条件 | 不主导 |
| 能力判断 | 不主导 | 能做多好、做到什么程度 | 模型与架构可行性 |
| 交付标准 | success metric、上线标准 | eval / guardrail | 实现方式与测试 |
| 成本取舍 | ROI、优先级 | model routing、质量阈值 | 技术优化细节 |
| 风险控制 | 合规和业务风险 | fallback、review flow | 安全机制与隔离 |
PM 不该替 Engineer 承诺能力边界，Engineer 也不该替 PM 决定这件事值不值得做。
AI 项目里最常见的 4 类协作误区
| 误区 | 实际后果 |
|---|---|
| PM 只写“做一个 AI 助手” | Engineer 无法判断范围和质量标准 |
| Engineer 只说“技术上能做” | 团队误以为已经具备商用价值 |
| 双方都不写 edge case | 上线后全靠用户帮你发现问题 |
| 讨论只围绕模型，不围绕 task | roadmap 会越来越偏技术炫耀 |
如果你的周会总在讨论“要不要换模型”，但很少讨论“用户任务是否真的被完成”，协作方向已经有点歪了。
一份 AI 需求，至少要写到什么程度
AI feature 的需求文档，比普通功能更需要 examples 和 boundaries。
推荐至少写清这 6 块：
| 模块 | 你应该写什么 |
|---|---|
| user task | 用户要完成什么，而不是功能名 |
| input / output | 输入是什么，输出长什么样 |
| success definition | 怎么算真的帮到了用户 |
| unacceptable failure | 哪些错法绝不能接受 |
| latency / cost expectation | 用户能等多久，业务能花多少钱 |
| review path | 出问题时如何回滚和兜底 |
没有这几块，Engineer 很容易只能凭经验补全你的需求。
例子：把模糊需求改成可协作需求
差的写法
做一个 AI 总结会议纪要功能
更好的写法
User task:
在 30 分钟会议后，用户希望 1 分钟内拿到可转发的 summary。
Input:
- transcript
- meeting title
- participants
Output:
- summary
- action items
- owner
- deadline if mentioned
Success:
- 用户无需大改即可发给 team
- action item 提取准确率达标
Unacceptable failure:
- 编造 owner
- 把讨论项写成已决定事项
- 漏掉关键 next step
这类需求写法，才真正能让 Engineer 进入正确的问题空间。
技术评审，不是让 Engineer 做单向汇报
AI technical review 更像一个 joint decision meeting。
建议每次评审至少回答这 5 个问题：
- 这个 use case 模型能稳定做到几分
- 失败的主要模式是什么
- 我们打算怎么评估它
- 这版上线的 guardrail 是什么
- 出问题时回滚哪个层
如果技术评审最后只留下“看起来能做”，那其实不算评审。
共同语言要尽量 productized
PM 不需要追着学所有术语，但一些关键词必须共用定义。
| 词 | 协作里更实用的解释 |
|---|---|
| hallucination | 模型说得像真的，但其实不可靠 |
| eval set | 用来验证版本前后差异的一组题 |
| latency | 用户从提交到看到结果要等多久 |
| fallback | 模型不稳时系统怎么兜底 |
| grounding | 回答有没有基于真实 source |
协作效率很大程度上取决于这些词双方是不是指同一件事。
冲突通常发生在哪
AI 项目里最常见的冲突，不是人际问题，而是 tradeoff 冲突。
| 冲突点 | PM 在意什么 | Engineer 在意什么 |
|---|---|---|
| 上线时间 | 能不能尽快验证价值 | 会不会带着明显风险上线 |
| 模型选择 | 用户体验够不够强 | 成本和稳定性是否可控 |
| 质量标准 | 用户能不能接受 | 这个标准技术上是否现实 |
| scope | 能不能多做一点场景 | 边界一大就很难稳 |
处理这类冲突最有效的方法，不是争论谁更懂，而是把问题改写成：
如果我们只先做最小可控场景，能不能先上线验证？
一套够用的协作节奏
更稳的 AI project cadence 通常是：
problem framing
-> example collection
-> technical review
-> small eval
-> limited rollout
-> weekly quality review
这条线里，PM 最重要的贡献不是催进度，而是把例子、坏例子、业务判断带进来。
Weekly Review 该看什么
每周至少一起看这几类东西：
- 3 个明显变好的 case
- 3 个明显翻车的 case
- 用户抱怨最多的 failure mode
- 本周最贵的一条调用链
- 下周是否要扩 scope 或收 scope
这比只看 ticket 完成率有用得多。
Practice
拿你现在正在推进的一个 AI feature，和 Engineer 对齐 4 件事：
- 成功样例长什么样
- 最不能接受的错误是什么
- 这版上线先覆盖哪些场景
- 出问题后先回滚哪一层
这 4 个问题对齐后，协作阻力会明显下降。