如何与设计师、工程师、AI 工程师协作
AI 时代的 PM 更像 orchestrator。你不是每件事都亲自做，而是让正确的人在正确的时间处理正确的问题。
真正高效的协作，不是把需求丢出去，而是让信息流动顺畅、判断标准一致、节奏可控。
三类核心协作对象
| 对象 | 你需要和他对齐什么 |
|---|---|
| 设计师 | 用户任务、关键路径、信任与预期设计 |
| 工程师 | 依赖、边界、异常流程、验收标准 |
| AI 工程师 | 模型能力边界、RAG 质量、评估样本、风险控制 |
PM 的协作任务不是转发信息
graph TD
A["业务目标"] --> B["PM 统一问题定义"]
B --> C["设计方案"]
B --> D["工程实现"]
B --> E["AI 能力方案"]
C --> F["上线版本"]
D --> F
E --> F
PM 的作用，是让 B 做得足够清楚，否则 C、D、E 会各自理解、各自优化，最后拼不到一起。
和设计师合作时要补的点
- 不只是页面长什么样，而是用户什么时候信任 AI、什么时候需要解释、什么时候需要看到“转人工”
- 高风险动作要有明显提示
- 错误与不确定状态要被设计出来
和工程师合作时要补的点
- 输入输出定义
- 系统边界
- 异常处理
- 日志与监控
- 验收样例
和 AI 工程师合作时要补的点
- 什么结果算“好”
- 哪些错误绝对不能出现
- 知识源是否可信
- 样本怎么评估
- 什么时候必须人工兜底
一个协作节奏模板
weekly_loop = [
"周一：目标与范围确认",
"周二：设计/工程/AI 方案对齐",
"周三：原型与样本验证",
"周四：风险与验收确认",
"周五：进度复盘与下周调整",
]
for item in weekly_loop:
print(item)
常见误区
| 误区 | 表现 | 后果 |
|---|---|---|
| 只发文档，不对齐判断 | 每个人各自理解 | 返工多、争议大 |
| 只盯排期，不盯质量 | 赶上线但问题没定义好 | 表面推进，实际失控 |
| 把 AI 工程师当“魔法实现者” | 只提愿望，不谈边界 | 方案不落地 |
课堂案例：一次典型的三方对齐会
案例背景
项目主题是“做一个 SaaS Copilot”。设计师关心体验，工程师关心接口与权限，AI 工程师关心知识源与评估样本。
教学拆解
PM 在会上至少要准备这四类材料：
- 问题定义与目标
- 场景优先级与 MVP 范围
- 关键异常流程与人工介入点
- 验收标准与风险边界
对齐结构图
graph TD
A["PM：问题与目标"] --> B["设计：体验与信任"]
A --> C["工程：边界与实现"]
A --> D["AI：能力与评估"]
B --> E["统一版本方案"]
C --> E
D --> E
练习题
- 为什么“同步信息”不等于“完成协作”
- 与 AI 工程师对齐时，PM 最该补什么信息
- 为什么异常流程必须提前对齐
标准答案提示
- 真正的协作是统一判断，不是共享文档链接
- 可从目标、错误边界、样本、知识源、评估标准回答
- 异常流程往往是上线后最容易出问题的地方
本章 checklist
- 我是否让设计、工程、AI 团队围绕同一个问题定义工作
- 我是否把异常、风险、验收提前说清楚
- 我是否建立了固定节奏，而不是临时追着问进度
- 我是否让每个角色都知道自己在这个版本里的成功标准
本章小结
- 协作编排是 AI PM 的关键能力之一
- 好协作的本质是统一判断标准，而不只是同步信息
- 越复杂的 AI 项目，越需要 PM 主动补上下文和边界
下一节：02-与AI工程师协作的关键接口 — PM 与 AI 工程师的边界划分：哪些判断 PM 必须给出，哪些交给工程师决定。