AI重塑敏捷团队三大角色：PO、SM、Dev的新定位

AI 对敏捷团队的改变，不是给角色加一个工具，是让角色的行为模式发生根本性迁移。

PO、SM、Dev 这三个角色，名字没变，但每天做的事、做的判断、负的责任，都已经不一样了。

---

一、敏捷团队三大角色，正在被 AI 重写

过去十年，我们习惯用固定的画像去理解敏捷团队：PO 负责需求，SM 负责流程，Dev 负责交付。

但当 AI 真正进入日常研发流程之后，这个画像开始失真——不是角色被取消，而是每个角色的重心发生了位移。

下面分别拆解这三个角色正在发生的变化，以及变化之后真正的能力要求。

---

二、PO：只是“写需求的人”吗？

传统 PO 的核心工作是写用户故事、排优先级、跟团队对齐需求。

AI 来了之后，写故事这件事本身变得很容易——你把上下文丢给 AI，它几秒钟就能生成一批看起来挺规范的用户故事。

但 PO 真正的价值，不是写故事的速度，是判断“这个需求到底对不对”的能力。

AI 可以帮你把需求拆细、把验收标准写清楚，但它：

• 不知道业务方真正的痛点是什么
• 不知道这个功能值不值得做
• 不知道优先级该怎么排

这些判断，AI 做不了。

PO 的角色正在从“需求传递者”变成“意图定义者”。

你要做的是：把模糊的业务愿景，翻译成 AI 能理解、团队能执行的精确规格。

同时，当 AI 生成了一堆看起来合理但逻辑空洞的内容时，你能一眼看出来——“这个不对，它不是我们真正要解决的问题。”

---

三、SM：只是“开会和清障碍的人”吗？

传统 SM 的工作是主持站会、回顾会，帮团队扫清障碍。

AI 来了之后，站会可以用 AI 自动汇总进度，回顾会可以用 AI 分析代码数据。SM 的很多“日常动作”正在被自动化。

但 SM 真正的价值，不是开了多少会，是让团队的人机协同效率变得更高。

这带来一个全新的挑战：

• 团队用 AI 用得好不好？
• 有没有人过度依赖 AI 导致自己的判断力退化？
• AI 生成的内容有没有人认真审查？
• 工具链是不是越来越乱？

SM 正在从“流程管家”变成“人机协同的效能教练”。

你需要评估和治理团队的 AI 工具栈，需要监控团队的认知负载，需要用数据而不是感觉来引导回顾会。

SM 的新 KPI 不是“开了多少会”，是“AI 引入之后，团队的质量指标有没有变稳”。

---

四、Dev：只是“写代码的人”吗？

传统 Dev 的核心能力是编码。AI 来了之后，编码本身变得容易了——你描述一个功能，AI 就能生成代码。

但这不意味着 Dev 的工作变简单了。

Dev 真正的价值，正在从“写代码”转向“审代码、定架构、管上下文”。

• AI 写的代码，逻辑对不对？
• 有没有隐藏的安全漏洞？
• 性能有没有隐患？
• 边界条件处理好了吗？

这些问题，需要你比手写代码时更严格地审查。

AI 可以帮你写，但出了问题，负责的是你。

与此同时，Dev 还要学会给 AI 提供精准的上下文——不是随便丢一句 Prompt，而是把相关的文件、接口、设计规范一起给到 AI，让它生成的内容能真正融入项目。

这是一个全新的能力：Context Engineering——为 AI 构建精准的工作环境。

---

五、这三个角色到底怎么配合？

AI 实际上变成了团队的“第四角色”。它不是工具，是一个需要被管理的非人类成员，是你的一名“新同事”。

• PO 负责“教”AI 理解业务，AI 帮 PO 消除歧义
• Dev 负责“指挥”AI 干活并验收，AI 负责加速执行和查漏补缺
• SM 负责“监控”AI 对团队的影响，AI 负责提供客观效能数据

三个角色围绕 AI 建立新的协作契约，而不是各自为战。