Sprint Retrospective 与 AI：为什么改进不能委托给模型

这是关于 AI 如何改变跨职能开发团队经典会议系列文章的第五篇。在前几部分中，我分析了 Backlog Refinement, Sprint Planning, Daily Scrum 和 Sprint Review。总体结论正逐渐变得更加明确：AI 擅长为对话收集输入，但不应取代对话本身。在 Sprint Retrospective 中，这条边界尤其重要，因为在这里团队讨论的不只是任务和产品，还有自身的习惯、互动、质量以及改变的能力。

Sprint Retrospective 看起来非常适合交给 AI。冲刺结束时，已经有 Jira、Git、pull requests、CI/CD、事故、聊天记录、日历、Daily Scrum 笔记、Sprint Review 的决策，有时还有团队的简短问卷。模型可以快速汇总：什么最常拖慢工作，review 瓶颈卡在哪里，哪些任务一天天往后挪，Definition of Done 在哪里变得不清晰，哪些决策反复出现，哪些话题在过去的回顾会上出现过却仍未消失。

乍看之下，这几乎是完美的自动化。不需要重新回忆整个冲刺。不需要争论等待 review 到底是真实问题还是某人的感觉。不需要手动翻看几十个工单和讨论分支。AI 可以准备事实、归类模式、提出 root cause analysis，甚至为下一个冲刺生成 action items。

但主要风险恰恰从这里开始。

Sprint Retrospective 的存在并不是为了得到一份整齐的改进清单。它的意义在于让团队诚实地看到自己如何工作，就应当改变什么达成一致，并为这一改变承担责任。如果 AI 把回顾会变成一份建议清单，团队可能得到一份漂亮的文档，却失去最重要的东西：心理安全感、对问题的共同理解以及真正的 follow-through。

“AI 可以揭示模式，但只有当团队承认问题并改变自身行为时，改进才会开始。”

为什么需要 Sprint Retrospective

在 Scrum Guide 2020 中，Sprint Retrospective 的描述非常务实：团队规划提高质量和效能的方法。为此，Scrum Team 从人员、互动、流程、工具和 Definition of Done 的角度检视冲刺进行得如何。团队讨论什么进展顺利、出现了哪些问题，以及这些问题是否得到解决。然后确定最有用的改变，而最重要的改进应尽快得到处理，并可以进入下一个冲刺的 Sprint Backlog。

也就是说，回顾会不是冲刺结束时的情绪宣泄。它也不是一场正式仪式，只需填满三栏：什么好、什么坏、要改进什么。这个事件关乎工作方式的适应。从这个意义上说，它直接关联 Scrum 的整体逻辑：透明性服务于检视，检视服务于适应，而没有适应的检视会变得空洞。Scrum Guide 明确指出：Scrum 事件的设计目的是引发改变，而不仅仅是产出记录。

作为额外的参考， Scrum Guide Expanded v2026.1很有用，但应将其视为基于 Scrum Guide 2020 的 companion 来源，而不是 Scrum Guide 的新权威版本。对本文而言，它重要在两点。第一，它指出反思在心理安全的环境中更有效。第二，在关于 AI 的章节中，它把模型描述为 supervised decision-making partner：AI 可以增强透明性、检视和适应，但不能取代人类责任，也不能取消对过程的经验性控制。

因此，我会通过五个功能来描述 Sprint Retrospective 的目的：

• 看到团队工作的真实模式，而不只是最响亮的声音；
• 在没有惩罚恐惧的情况下讨论互动、流程、工具和 Definition of Done；
• 把事实与解释和猜测区分开；
• 选择少量团队真正愿意尝试的改进；
• 把这些改进带入下一个冲刺，使它们有 owner、验证标准和在工作中的位置。

这是讨论 AI 的框架。如果工具帮助团队更好地履行这些功能，它就是有用的。如果它只是生成一份更漂亮的 action items 清单，它可能很方便，但不一定能让团队更有效。

通常哪里会出问题

回顾会的问题很少在于团队不会指出问题。通常问题在别处。团队又一次讨论同样的内容。行动项从一个冲刺拖到下一个冲刺。人们说话小心翼翼，因为不想显得有错。最痛苦的话题被绕开。Scrum Master 把形式拉出来，却拉不出改变。最后大家都同意类似“我们多沟通吧”的说法，而它在下一周就已经消散了。

Lehtinen、Itkonen 和 Lassenius 在 Empirical Software Engineering 上的研究很好地凸显了回顾会的这一面。作者们研究了近三年间的 37 次团队级回顾会，并展示了几件重要的事：讨论往往涉及团队熟悉且可管理的主题，但可能受到参与者偏差的影响；没有硬证据时，它们并不总能反映现实；有些主题长期重复，要么是因为它们自然回归，要么是因为团队因复杂性或缺乏可控性而无法在自己的层面上解决它们。

这对 AI 来说是一个非常有用的框架。模型确实可以帮助把硬证据带到以前只有感觉的地方。例如，团队说：“review 拖慢了冲刺。”AI 可以提出事实：有多少 PR 等待超过一天，具体哪些卡住了，哪些评论重复出现，哪里在 merge 之后还有返工。这比凭记忆争论更有用。

但这个框架也有反面。如果团队不想谈论令人不适的原因，AI 不会让它更诚实。如果问题在团队的影响范围之外，模型可以漂亮地表述一个行动项，但依然没人会执行。如果人们不信任上下文，他们争论的就不再是流程，而是 AI 是否正确描述了他们的工作。

AI 真正有帮助的地方

在 Sprint Retrospective 中，AI 有一个强大的用武之地，前提是不试图把改进本身交给它。我会在回顾会之前和之后使用它，而不是代替回顾会。

但这里重要的是不要过度承诺。 DORA State of AI-assisted Software Development 2025 将 AI 描述为组织系统现有优势和劣势的放大器。对于回顾会来说，这几乎是完美的表述：如果团队已经能够诚实地讨论流程并把改进落实到行动，AI 会让输入更丰富。如果回顾会早已变成没有后续跟进的安全仪式，AI 只会让这个仪式更快、更整洁。

在会议之前，AI 可以为检视准备输入：

• 从 Daily Scrum、工单、pull requests 和 incident notes 中收集重复出现的 impediments；
• 找出 work items 长时间等待 review、测试数据、产品负责人决策或外部依赖的地方；
• 将 Sprint Planning 中的计划、冲刺期间的实际决策以及 Sprint Review 上讨论的结果进行对比；
• 突出 Definition of Done 与团队实际关闭任务方式之间的差异；
• 收集旧的行动项，并显示哪些已完成、被遗忘或重复出现；
• 为对话拟定候选问题：什么是事实，什么是解读，什么需要验证。

会议之后，AI 可以帮助后续跟进：仔细记录选定的行动项，添加 owner、验证标准、与 Sprint Backlog 的关联，以及下次回顾会的提醒。这尤其有价值，因为许多回顾会的薄弱之处不在于讨论，而在于改进没能活到下一个冲刺。

但在所有这些场景中，AI 始终是准备性和支持性的层面。它不应该决定哪个问题最重要。它不应该指派责任人。它不应该把 root cause 当作事实来确定。它当然不应该在没有活人验证的情况下自动写出“团队改进计划”。

为什么 AI 不应该代替团队进行回顾会

AI-assisted Retrospective 最危险的版本看起来是成熟的。模型收集所有数据，分析团队情绪，找到“三个主要问题原因”，提出行动项，并把摘要发送到 Slack 或 Confluence。所有人都读了，点头，加上反应，回顾会变得更短。有时团队甚至开始想：如果 AI 已经全部分析过了，为什么还要花一小时讨论？

问题在于，回顾会的价值不仅在于结论。它的价值在于共同理解的过程。团队重要的不只是得到一个论断“review 花费太多时间”。他们需要就为什么会发生、团队准备改变什么、接受什么妥协以及谁承担行动达成一致。有时在这个对话中会浮现出数据中看不到的东西：害怕与强势开发者争论、因不清晰的产品上下文而烦躁、因不断出现的紧急任务而疲惫、对当前 Definition of Done 的默默反对。

Amy Edmondson 关于 psychological safety 与学习行为 在这里重要的不是作为时髦的引用，而是作为实践指南。如果人们不觉得自己可以在没有 межличностный 风险的情况下谈论问题，回顾会就会变成安全的措辞。在这种情况下，AI 可以让会议记录更顺畅，但无法让团队更诚实。

此外，如果团队将 AI 视为监控，它可能会损害诚实性。如果模型读取 Slack、Jira、PR 评论和日历，然后写道“阿列克谢对 review 的反应速度低”或“QA 经常延迟数据的就绪”，这已经不是对回顾会的支持。这是以流程改进为幌子的绩效管理。在这种环境中，人们开始优化可见的活动，与模型争论并捍卫声誉，而不是讨论真实的流程。

正因如此，诸如 NIST Generative AI Profile、 OWASP Top 10 for LLM Applications 2025、 EDPB Opinion 28/2024 以及 ICO 关于 monitoring at work 的材料在这里是相关的。不是作为文章的法律章节，而是作为提醒：回顾性数据很容易变得敏感。它们涉及人、行为、冲突、错误、延迟、通信，有时还涉及管理的薄弱环节。

实践边界很简单：回顾中的 AI 应该分析 work and system，not people。也就是说，卡住的工作、重复的期望、不清晰的规则、Definition of Done 中的空白、糟糕的 handoffs、过载的流程点。不是“谁工作得不好”，而是“系统中是什么让我们再次得到相同的结果”。

“好的 AI-input 用于回顾会关注卡住的工作和重复的模式。糟糕的 AI-input 把人变成报告中的行。”

继续案例：B2B LMS 和电子邮件提醒

让我们沿用之前文章中的同一个案例：B2B LMS 平台、必修课程、向未在截止日期前完成必修课程的员工发送电子邮件提醒。在 Sprint Planning 上，团队选择了一个狭窄的 Sprint Goal：系统向有未完成必修课程的活跃员工发送一条正确的提醒，并保存可验证的发送历史。在 Daily Scrum 上，团队跟踪了去重、时区和测试数据的风险。在 Sprint Review 上，团队讨论了这对产品和 Product Backlog 意味着什么。

现在到了 Sprint Retrospective。没有 AI，对话可能很快陷入习惯性的感受。后端说：“我们被 eligibility 的澄清拖慢了。”QA 说：“测试数据来得太晚。”前端说：“API 在冲刺中期变了。”产品负责人说：“我们没预料到关于 expired的这么多问题。”Scrum Master 记录：“改善沟通”、“更早准备数据”、“更少更改需求”。回顾会似乎开过了。

AI 可以让输入更具体。它调出冲刺历史并显示：

• 四个 PR 等待 review 超过一天，且都与 retry logic 和 idempotency 相关；
• 对已停用用户的 eligibility 解释改变了三次；
• QA 数据比团队在 planning 时预期的晚了三天出现；
• Definition of Done 不要求对负面场景提供可验证的发送历史；
• 旧的 action item“减小 PR 大小”未完成，并作为问题再次出现；
• Slack 中的部分讨论不是关于实现，而是关于缺乏对 expired的统一决策。

这是好的输入。但这还不是回顾会。

回顾会始于团队讨论其中哪些真正需要改变。例如，它可以决定：不是“更早沟通”，而是“在 planning 时明确记录有争议的 eligibility 状态及其 product owner decision”。不是“QA 更快准备数据”，而是“在 Sprint Backlog 中，在开始实现关键场景之前，为测试数据添加单独的 work item”。不是“少做 PR”，而是“对于 notification architecture 的更改，PR 应能容纳在一个 review 场景中，并在工作开始前有 review owner”。不是“改进 DoD”，而是“Definition of Done 现在包括对提醒的负面场景提供可验证的发送历史”。

这些才是 action items。它们具体、可验证，并与下一个冲刺相关。AI 帮助看到了模式。团队选择了改变。

反模式

以下是我在将 AI 引入 Sprint Retrospective 时会特别跟踪的几个反模式。

1. AI 摘要取代了实时对话

如果团队只是阅读生成的摘要并同意它，回顾会就失去了最重要的东西。好的问题不是“AI 是否准确描述了冲刺？”，而是“我们准备改变其中的什么？”

2. 情感分析变成了关于团队的真相

情感分析可能是有用的弱信号，但它不了解上下文。讽刺、疲劳、局部冲突、玩笑、沉默和谨慎的措辞很难转化为指标。团队的情绪不能简化为图表。

3. AI 寻找责任人而不是系统模式

一旦模型开始按速度、活跃度或“制造的阻塞者”数量给人排名，回顾会就变成了监控。这会破坏心理安全感，并降低人们愿意提供的信息质量。

4. 根本原因未经核实就被接受

模型可能会自信地写道：“延误的主要原因是需求不明确。”但这可能只是可见的部分。真正的原因可能是架构债务、优先级冲突、缺少测试数据，或害怕升级问题。AI 给出的根本原因是假设，而不是事实。

5. 行动项变得过于笼统

“改善沟通”、“加快评审”、“更好地准备”几乎从不改变行为。好的行动项应该回答这些问题：谁来做、具体改变什么、在下一个冲刺中在哪里能看到、团队如何验证效果。

6. 改进没有进入 Sprint Backlog

Scrum Guide 允许最重要的改进进入下一个冲刺的 Sprint Backlog。如果团队选择了某项改进，却没有为它分配注意力、负责人和工作位置，那就不是改进。那只是愿望。

角色如何变化

AI 不会取消 Scrum Team 内部的职责范围，但会改变对话的准备方式。手动重建冲刺历史的价値降低了。诚实解读、选择小实验并把改进推进到结果的价值更高了。

角色	糟糕 AI 场景下的风险	成熟的 AI 使用方式
开发者	争论 AI 对自己活跃度的评估，维护声誉而不是讨论流程。	把事实和模式作为输入，但自己选择在工程实践、评审、DoD 和交接中改变什么。
产品负责人	把 AI 回顾当作团队绩效报告来读，并施加速度压力。	帮助消除产品层面的模糊性，明确那些拖慢团队的决策，并支持改进进入下一个 Sprint Backlog。
Scrum Master	把引导工作交给模型，得到一份整洁的会议记录，而不是诚实的对话。	利用 AI 输入做准备，但保护心理安全感、聚焦系统，并跟进所选行动项的落实。
质量工程师 / QA 工程师	如果模型肤浅地把问题与测试联系起来，就会被当成“延误来源”的角色。	帮助把质量信号转化为 Definition of Done、测试数据归属和可观测性的改变。
UX/UI 设计师	被排除在回顾之外，因为 AI 主要分析代码、PR 和开发任务。	突出那些影响团队和产品质量的交互、决策和用户上下文。
Engineering Lead / Tech Lead	把 AI 回顾当作控制工程师的仪表盘。	帮助区分系统性工程瓶颈和个人活跃度，并选择真正能放进下一个冲刺的技术改进。

AI 辅助 Sprint Retrospective 的实用过滤器

我不会从“让 AI 来主持回顾”这个想法开始。我会从一个更窄的问题开始：什么样的输入能帮助团队更诚实地检视工作方式，并选择一两个它真正会执行的改进？

如果 AI 输入能帮助回答以下问题，那么它对 Sprint Retrospective 就是有用的：

• 哪些问题反复出现，哪些是一次性的；
• 哪些事实支持这个主题，哪些是观点或情绪评价；
• 什么在团队的影响范围内，什么需要 Supporters、管理层或其他团队的帮助；
• 哪些旧行动项没有完成，为什么；
• 下一个冲刺中值得改变哪一个流程、工具、工作协议或 Definition of Done；
• 团队如何验证改变奏效了。

反过来：如果 AI 输入主要回答“谁是瓶颈”，那就是危险信号。回顾应该帮助团队改进工作系统，而不是产出隐藏的成员排名。

数据与边界

Sprint Retrospective 对数据尤其敏感，因为 AI 很容易开始收集人们视为私人的东西：聊天消息、响应速度、评论语气、对 PR 的反应时间、会议参与度、重复错误、讨论中的冲突。访问范围越广，分析越有说服力。但敏感上下文泄露、过度依赖模型输出以及回顾变成员工监控的风险也越高。

在实践中，我会在把 AI 引入回顾之前确定几条规则：

• 使用回答问题所需的最小数据源集合；
• 未经明确约定和必要，不分析私人消息；
• 不构建个人排名、分数和绩效管理结论；
• 向团队展示使用了哪些数据、排除了哪些数据；
• 把事实与生成的解读分开；
• 重要结论要对照原始来源核实；
• 如果 AI 摘要包含敏感的团队上下文，就删除或限制其存储。

这不是官僚主义。这是诚实对话的前提条件。如果人们不清楚模型究竟读取了什么、其输出之后又如何被使用，他们就会说得更谨慎。而谨慎的回顾几乎总是产生安全但微弱的改进。

那么真正改变的是什么

AI 确实能让 Sprint Retrospective 更有用。它可以降低准备成本、把事实带进对话、展示重复出现的模式、提醒未完成的 action items、标出与 Definition of Done 的偏差，并帮助把模糊的「需要改进」变成具体的 next-sprint experiment。

但这只有在团队理解边界时才成立：AI 为检视准备材料，而不是替团队完成适应。它帮助看见数据，但不创造心理安全感。它可以提出 root cause，但不知道人们害怕谈论什么。它可以写出 action item，但不承担 owner，也不改变下一个冲刺中的行为。

因此我会这样表述核心论点：AI 应当降低还原事实的成本，让团队把更多注意力留给诚实的对话和选择一个小改进。如果反过来，Sprint Retrospective 变成自动生成的建议清单，团队失去的恰恰是这个活动存在的理由：共同学习、对改变负责，以及提升工作质量的能力。

成熟的团队不会问：「我们能不能把回顾交给 AI 来做？」它会换一种问法：「AI 能承担哪部分准备工作，让我们的回顾更诚实、更具体、更好地落到行动上？」这个问题没那么炫目。但它恰恰更接近真正的 continuous improvement。

来源与参考

• Scrum Guide 2020 — Sprint Retrospective、质量与效能、人员 / 互动 / 流程 / 工具 / Definition of Done、最有用的改进以及与 Sprint Backlog 的关联。
• Scrum Guide Expanded v2026.1 — 基于 Scrum Guide 2020 的 companion 来源：psychological safety、meaningful continuous improvement follow-through，以及 AI 作为 supervised decision-making partner。
• Scrum.org: Introduction to the Sprint Retrospective — 对 Sprint Retrospective 作为团队工作实践 inspection and adaptation 事件的实务说明。
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements — 对近三年 37 次回顾的实证研究：participant bias、hard evidence、recurring topics 与 corrective actions。
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — 关于心理安全感作为 team learning 条件的经典来源。
• NIST Generative AI Profile — confabulation、data privacy、human-AI configuration、overreliance、information integrity 以及生成式 AI 的其他风险。
• OWASP Top 10 for LLM Applications 2025 — sensitive information disclosure、excessive agency、misinformation 以及 LLM 应用的运营风险。
• DORA State of AI-assisted Software Development 2025 — AI 作为组织系统既有优势与弱点的放大器。
• EDPB Opinion 28/2024 和 ICO monitoring at work guidance impact assessment — 关于个人数据、透明度、比例原则以及职场监控边界的参考。