Sprint Review 与 AI：为什么演示不能替代关于价值的对话

这是关于 AI 如何改变跨职能开发团队经典会议系列文章的第四篇。在第一篇文章中，我分析了 Backlog Refinement ，并指出 AI 能加速材料准备，但不能替代团队对意义的检验。第二篇讨论的是 Sprint Planning：AI 起草计划草案，但不承担团队承诺。第三篇关于 Daily Scrum：AI 准备冲刺进展信号，但不替团队进行同步。现在顺理成章地转向 Sprint Review，剖析最诱人的错误：把关于价值的生动对话变成一场漂亮的 AI 演示。

Sprint Review 看起来是 AI 的理想舞台。冲刺结束时，一切素材都已就绪，很容易拼出一场效果出众的演示：Jira 中已关闭的任务、已合并的 pull request、代码变更、新界面、更新后的指标、支持工单、用户反馈。AI 可以在几分钟内生成发布说明、草拟演示脚本、制作幻灯片、统计完成的工作量，甚至生成一份关于用户反馈的整洁摘要。

乍看之下这是纯粹的收益。更少的手工准备。更少的“我们在会前五分钟再决定展示什么”。更少的枯燥罗列。演示看起来专业，发布说明写得连贯，指标可视化得漂亮。

但这里有个陷阱，而且比 Daily Scrum 中的更严重。

Sprint Review 的存在不是为了演示。它的任务是与利益相关者一起检视冲刺成果、讨论向 Product Goal 的进展，并调整 Product Backlog。如果 AI 把 Sprint Review 变成一场精心打磨的演示，团队得到的是更漂亮的展示，却失去了最重要的东西：诚实的反馈、关于“下一步做什么”的共同决策，以及对产品的责任感。

“AI 可以消除准备中的繁琐工作，但 Sprint Review 的价值不在于演示，而在于决定产品要改变什么。”

为什么需要 Sprint Review

在 Scrum Guide 2020 中，Sprint Review 的描述相当严格。它是冲刺的倒数第二个事件，对于为期一个月的冲刺，时间盒最多为四小时。其目标是检视冲刺成果并确定后续调整。Scrum Team 向关键利益相关者展示工作成果，并讨论向 Product Goal 的进展。Scrum Guide 还几乎以论辩的口吻特别说明：“The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation”——这是一次工作会话，团队不应将其缩减为一场演示。

这是贯穿全文的关键句。Sprint Review 不是产品负责人对工作的验收，不是向管理层的汇报，不是面向客户的营销演示，也不是“我们很棒”的仪式。它是团队与利益相关者一起审视已完成的工作以及周围发生的变化，并决定下一步做什么的时刻。该事件的成果不是掌声，而是调整后的 Product Backlog。

作为额外的参考， Scrum Guide Expanded v2026.1也有用，但仅作为 companion 来源，而非 Scrum Guide 的新权威版本。对本文而言，它的价值在于一个实践框架：Sprint Review 关乎价值向利益相关者的真实流动以及产品计划的共同调整，而非状态汇报。在关于 AI 的章节中，它将该模型描述为 supervised decision-making partner：AI 可以增强透明度、检视和调整，但不能替代人类责任，也不能取消对过程的经验性控制。

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

• 检视冲刺的真实成果，而非关于成果的讲述；
• 收集来自利益相关者和用户的诚实反馈；
• 检查向 Product Goal 的进展；
• 共同决定下一步做什么；
• 调整 Product Backlog，而不仅仅是展示已完成的工作。

这是讨论 AI 的框架。如果工具帮助团队更好地履行这些功能，它就有用。如果它只是让演示更漂亮，它可能很方便，但不一定改善产品。

通常哪里出了问题

Sprint Review 的问题很少在于团队不会展示已完成的工作。问题在于该事件随时间退化为单向演示：团队准备演示、展示界面、罗列已关闭的任务，利益相关者礼貌点头，有人说“很好，谢谢”，然后各自散去。而 Backlog 并未改变。Scrum.org 在 Myth 12: The Sprint Review is a Demo一文中直接剖析了这一反模式：演示可以是事件的一部分，但 Sprint Review 的目标是最大化反馈并降低风险，而不是做一场演示。

那么会议就开始背离其目标。团队讨论的是如何更漂亮地展示，而不是什么值得讨论。利益相关者来不及给出反馈，因为团队“天真地沉迷于自己的演示”——Scrum.org 在材料 How to Engage Stakeholders in your Sprint Reviews. 中特别指出了这一点。令人不适的问题没有被提出。所构建的东西与市场所需之间的差距，很晚才浮现。Product Backlog 保持与会议前完全一样，尽管这个活动的全部意义就是基于新数据改变它。

在 AI-assisted 语境下，这个问题可能会加剧。如果模型每个冲刺都生成演示、release notes 和成果清单，团队很快就会习惯于“回顾已经准备好了”的想法。于是 Sprint Review 变得更加顺滑：打开 AI 幻灯片，读了 release notes，展示了指标，收到了礼貌的“谢谢”，然后结束了会议。

看起来专业。但问题不在于演示组织得有多连贯。问题在于，如果现实发生了变化，团队是否改变了自己的 Product Backlog。

AI 真正有帮助的地方

AI 在 Sprint Review 中有一个相当实用的用武之地。它可以消除准备工作的例行事务，并把团队在冲刺末期容易丢失的东西浮现到表面。当来源很多时，这尤其有价值：issue tracker、pull requests、CI/CD、产品分析、支持工单、应用商店评价、调查结果、用户访谈记录。

但这里重要的是不要过度承诺。即便是最新的 DORA State of AI-assisted Software Development 2025 也更多地把 AI 描述为现有组织实践的放大器，而不是更好交付的独立保证。对 Sprint Review 来说，这意味着很简单：如果团队已经能够就价值进行诚实的对话并调整 backlog，AI 会让进入这场对话的入口更丰富。如果 Sprint Review 早已变成演示仪式，AI 只会让这个仪式更快、更漂亮。

一个好的 AI 助手在 Sprint Review 之前收集的不是“如何更有效地展示”，而是用于产品决策的有用上下文：

• 冲刺期间产品中真正发生了什么变化，以及这与 Product Goal 有何关联；
• 增量中的哪些元素已准备好接受检视，哪些最好诚实地作为未完成项展示；
• 此前发布之后产品指标说明了什么；
• 来自用户和支持的反馈是什么，包括矛盾的和令人不适的；
• 过去冲刺的哪些假设得到了证实，哪些没有；
• 哪些开放的产品问题值得提交给利益相关者讨论；
• Product Backlog 中哪些条目可能已经失去相关性，或者相反，优先级上升了。

在这种模式下，AI 不替代 Sprint Review。它降低了为 Sprint Review 做准备的代价。团队带来的不是原始数据，也不是匆忙拼凑的幻灯片，而是一幅已经结构化的图景：这是结果，这是数据，这是反馈，这是开放问题。这样可以花更少时间收集事实，花更多时间进行“我们现在要在产品中改变什么？”的对话。

这延续了本系列此前文章的逻辑。在 refinement 中，AI 帮助收集讨论材料。在 planning 中——提供计划选项。在 Daily Scrum 中——提供冲刺进展信号。在 Sprint Review 中，它可以收集结果和反馈。但在所有四种情况下，人的部分都不会消失：团队和利益相关者必须检查什么重要、什么发生了变化，以及要做出什么决定。

为什么 AI 不应把 Sprint Review 变成演示剧场

AI-assisted Sprint Review 最危险的版本看起来非常有说服力：模型生成带有漂亮幻灯片的演示、连贯的 release notes、“冲刺关键成果”清单、指标图表以及平滑的用户反馈摘要。有时还会加上对 Product Goal 的自动预测以及建议的 backlog 变更。

从形式透明度的角度看，这很方便。从 Scrum 的角度看，这可能是退化。

第一，这种形式强化了单向性。AI 演示越漂亮，把会议“办成”演示的诱惑就越强。注意力从反馈转移到展示上：团队为幻灯片辩护，而不是邀请利益相关者就价值展开争论。

第二，AI 对反馈的摘要可能恰好抹掉 Sprint Review 之所以举行的东西。反馈的真正价值在于矛盾、弱信号、令人不适的分歧，以及罕见但重要的评论。平滑的平均化摘要很容易丢弃离群值，而在产品中，往往正是离群值才是信号。这是 information integrity 和 misinformation 的经典风险， NIST 生成式 AI 简介中对此有描述。

第三，模型可能自信地编造出数据中并不存在的洞察。虚构在 Sprint Review 中尤其危险，因为生成的关于用户的“结论”很容易变成产品决策。如果 AI 写“用户要求 X”，而实际上这只是两个工单和一次访谈，团队就有基于幻觉修改 Product Backlog 的风险。

第四，团队可能开始把产品判断委托给工具。如果 AI 建议对 backlog 做更改，看起来似乎可以直接接受。如果 AI 说 Product Goal 已达成，看起来似乎没什么可讨论的。这不是 Sprint Review 的自动化，而是把责任转移到不可能承担责任的地方：对产品负责的是产品负责人和团队，而不是模型。

“AI 演示可以是有用的输入。它不应成为关于价值对话的替代品。”

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

我们沿用之前文章中的同一个案例：B2B LMS 平台、必修课程、向未在截止日期前完成必修课程的员工发送邮件提醒。在 planning 中，团队选择了一个狭窄的 Sprint Goal：系统向有未完成必修课程且临近截止日期的活跃员工发送一条正确的提醒，并保存可验证的发送历史。

在没有 AI 的情况下，这样的冲刺中的 Sprint Review 很容易沦为演示。团队展示提醒设置界面，演示测试邮件，说“调度器正常工作，去重已到位，历史日志正在写入”，利益相关者点头，有人称赞邮件设计。形式上一切良好。Backlog 没有变化。

但团队可能错过关键点：提醒发出去了，但打开率低，因为邮件主题不佳；支持部门已经收到几起“为什么我会收到关于我无需完成的课程的提醒”的请求——也就是说 eligibility 边界的工作方式与预期不符；一个大客户要求个性化时间表，这可能改变下一个冲刺的优先级；而对状态 expired的解读，团队认为在工作范围之外，实际上对利益相关者很重要。

AI 在这里可以提供帮助。在 Sprint Review 之前，它收集输入：发送了什么、发给了谁，打开率和点击率如何，支持部门收到了哪些请求及其内容，试点客户留下了哪些反馈，哪些 backlog 条目与这个 Sprint Goal 相关。这是很好的讨论材料。

但价值只在会议上出现，当团队和利益相关者采取下一步时：决定低打开率是产品问题而非表面问题；eligibility 边界需要澄清并作为单独条目放入 backlog；大客户的个性化时间表是战略决策而非快速修复；以及对 expired 是时候从“工作范围之外”移到最近的优先级了。AI 给出了结果和数据。团队与利益相关者调整了 Product Backlog。

反模式

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

1. AI 让演示更漂亮，但会议仍然是单向的

如果精力都花在打磨幻灯片和发布说明上，Sprint Review 作为演示而非工作会话会被强化。更有用的是让 AI 准备给利益相关者的问题和开放的产品议题，而不仅仅是炫目的成果展示。

2. AI 反馈摘要平均化并丢失弱信号

流畅的摘要便于阅读，但危险在于它会丢弃矛盾和罕见但重要的评论。反馈应当保留分歧和异常值，而不仅仅是平均化的“总体情绪”。

3. AI 编造数据中不存在的产品洞察

“用户想要 X”听起来很有说服力，但需要验证：结论基于多少个信号，是否是幻觉，是否用大众需求替代了罕见情况。来自模型的洞察是假设，而不是决策。

4. 指标被展示为成就，而不是决策的契机

“发送了 10,000 封邮件”是活动，而不是价值。Sprint Review 应将指标与 Product Goal 联系起来，并询问它们改变了计划中的什么，而不是把它们当作冲刺进展顺利的证明。

5. AI 建议对 Product Backlog 做更改，而这些更改未经讨论就被接受

模型的建议可以是有用的输入，但调整 backlog 是产品负责人与团队和利益相关者共同做出的产品决策，而不是自动应用 AI 建议。

6. 为管理层做的演示剧场，而不是为调整而做的检视

如果 Sprint Review 变成“向老板展示我们很棒”的表演，AI 只会让表演更有说服力。这会破坏对活动的信任，并剥夺团队诚实的反馈。

角色将如何变化

AI 不会取消 Scrum Team 内的角色，但会改变 Sprint Review 准备和进行中的重点。手动组装演示文稿的价值降低。诚实检视结果、处理反馈和共同做出产品决策的价值更高。

角色	糟糕 AI 场景下的风险	成熟的 AI 使用
产品负责人	将AI反馈摘要和提议的backlog变更当作现成决策接受，不再自行思考价值。	将AI输入作为材料使用，但自己主导关于价值的对话，验证洞察，并对Product Backlog的调整负责。
开发者	将准备时间花在打磨AI演示上，而不是诚实展示哪些已完成、哪些未完成。	使用AI快速汇总结果和风险，并与利益相关者一起诚实检视增量。
Scrum Master	将引导交给幻灯片，只关注演示的时间安排。	保护Sprint Review不沦为演示，帮助吸引利益相关者参与，并将焦点保持在调整上。
利益相关者	看到流畅的AI演示，礼貌点头，却不给出真实反馈。	看到真实结果和数据，提出尖锐问题并影响产品优先级。
质量工程师 / QA工程师	确认AI生成的“已完成”清单，制造增量已就绪的假象。	帮助如实展示哪些符合Definition of Done、哪些不符合，以及质量风险留在哪里。
UX/UI设计师	被排除在视野之外，因为AI演示聚焦于功能和指标。	带来用户观察和体验反馈，帮助将结果与真实价值联系起来。

AI辅助Sprint Review的实用过滤器

我不会从引入“AI演示生成器”开始。我会从一个更窄的问题开始：什么样的输入能帮助团队和利益相关者更快做出诚实的产品决策？之后，AI可以作为准备层使用，而不是事件的替代品。

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

• 产品中真正改变了什么，这与Product Goal有何关联？
• 哪些已准备好接受诚实检视，哪些需要作为未完成项展示？
• 数据和反馈说明了什么，包括相互矛盾的反馈？
• 哪些假设得到证实，哪些失败了？
• 哪些开放的产品问题值得与利益相关者讨论？
• Product Backlog中哪些条目需要修改、添加或移除？
• 我们根据结果将做出什么决策，而不仅仅是我们将展示什么？

反过来：如果AI输入主要回答的是“如何更炫地展示已完成的工作”，那就不是Sprint Review。那是演示。演示对沟通可能有用，但不应将其与对结果的检视和Product Backlog的调整混为一谈。

治理与数据卫生

Sprint Review对数据尤其敏感，因为AI准备很容易开始从支持工单、CRM、访谈记录、问卷、应用商店评价和客户往来通信中收集反馈。访问范围越广，摘要就越有说服力。但敏感信息泄露、语义失真以及过度依赖模型自信但不完整结论的风险也越高。这些风险类别在 NIST生成式AI概况、 NIST AI风险管理框架1.0 以及 OWASP Top 10 for LLM Applications 2025.

团队应事先约定：哪些反馈来源允许用于AI、用户数据如何匿名化、谁可以看到生成的摘要，以及是否可以向外部利益相关者展示客户的原始引述。在处理用户和客户的个人数据时，诸如 EDPB Opinion 28/2024 和 ICO monitoring at work impact assessment 之类的指引是有用的——不是作为本文的法律说明，而是作为对法律依据、数据最小化、透明性和相称性的提醒。

在实践中，这意味着：不要把多余的个人数据拉进模型，将事实与生成的解释分开，将AI洞察标记为假设，依据原始来源核实用户引述，并且不要在Sprint Review上展示无法用数据证实的“结论”。AI应帮助团队诚实看到结果和反馈，而不是制造一幅有说服力但未经核实的图景。

实践结论

AI确实可以让Sprint Review更有用。它可以消除准备中的例行工作，提前汇总冲刺结果，将其与指标关联，聚合反馈，突出计划与现实之间的差异，并提出与利益相关者讨论的主题。

但这只有在团队理解边界时才有效：AI准备输入，而不是主持Sprint Review。它帮助看到结果和数据，但不决定它们对产品意味着什么。它可以收集反馈，但本身不会创造关于价值的诚实对话。它可以提议backlog变更，但不承担产品责任。

因此，我会这样表述核心论点：AI应降低准备成本，让团队和利益相关者把更多注意力留给关于价值和计划调整的对话。如果情况相反，Sprint Review变成一场打磨过的AI演示，团队就会失去该事件存在的根本意义：对结果的诚实检视、真实反馈、共同决策以及对产品的责任。

成熟的团队不会问：“我们能不能让 AI 来生成冲刺评审？”他们会换一种问法：“AI 能替我们承担准备工作中哪一部分例行事务，从而让我们的 Sprint Review 成为一场更诚实的对话——关于价值，以及产品中需要改变什么？”这种表述没那么抓眼球，但更贴近真实的产品实践。

来源与参考

• Scrum Guide 2020 ——Sprint Review、Product Goal、Product Backlog、增量、工作会话、检视与调整。
• Scrum Guide Expanded v2026.1 ——基于 Scrum Guide 2020 的配套来源：Sprint Review 的实践框架、面向利益相关者的价值流，以及 AI 作为受监督的决策伙伴。
• Scrum.org：什么是 Sprint Review？ ——Sprint Review 是协作式工作会话，而非演示。
• Scrum.org：误区 12——Sprint Review 就是演示 ——为什么 Sprint Review 不应沦为演示。
• Scrum.org：如何让利益相关者参与你的 Sprint Review ——为什么利益相关者的反馈是这一事件的核心价值。
• NIST 生成式 AI 概况 ——虚构/自信地编造、信息完整性、过度依赖与人工监督。
• NIST AI 风险管理框架 1.0 ——治理/规范、问责制以及人机交互配置。
• OWASP Top 10 for LLM Applications 2025 ——LLM 应用中的敏感信息泄露、错误信息与过度代理。
• DORA State of AI-assisted Software Development 2025 ——AI 是组织实践的放大器，而非改进的独立保证。
• EDPB 第 28/2024 号意见 和 ICO 工作场所监控影响评估 ——在处理反馈时关于个人数据、最小化、透明度和相称性的参考。