我参加过一次会议，产品负责人向团队展示了一个新产品的 500 个刚刚编写好的产品待办事项（Product Backlog Items），会议的目标是看看其中是否遗漏了什么。

没人能说得清楚，面对 500 个相对细小的待办事项，要发现其中遗漏了某项重要需求非常困难——甚至几乎不可能。

而且，500 个待办事项其实还不算特别多。很多组织的 Product Backlog 可能是这个数量的 10 倍，甚至更多。

但试想一下，如果团队最初面对的不是 500 个细小事项，而是 25～50 个高层级的 Epic（史诗级需求），讨论会有多么不同。在这个层级上，团队可以从产品整体角度提出问题：

 ● 我们是否遗漏了某一类重要用户？

 ● 是否缺少一个关键的用户工作流程？

 ● 这些内容是否体现了我们希望如何定位这个产品？

 ● 哪些能力能够真正让我们与竞争对手形成差异化？

 ● 是否有一些功能，仅仅因为类似产品都有，所以我们也把它们加进来了？

当这些高层级的决策完成以后，团队再把最重要的Epic分解成更小的Product Backlog Item。

AI让团队非常容易跳过一个关键步骤：先识别并审视产品的高层级 Epic，然后再将其分解为用户故事。

团队可能直接进入数百个详细的待办事项，却没有先思考：这些待办事项加在一起，真的描述了我们应该打造的那个产品吗？

只要给AI一段产品描述，几分钟之内，它就可以生成数百个用户故事。再问一次，它还可以继续加入验收标准、边界情况、依赖关系和优先级建议。

这些结果通常写得很好，而且看起来非常全面。

而这恰恰是让我担心的地方。

真正的危险并不是 AI 会生成一些明显很糟糕的待办事项。如果是那样，反而很容易发现并删除。

更大的危险在于AI 会生成大量看起来合理、表达专业，而且似乎非常完整的待办事项。

大量细节本身会让人不再质疑这个Backlog。当你面对数百个独立的用户故事时，很难再发现究竟遗漏了什么；同样也很难判断，某项功能到底是真正关键的能力，还是 AI 只是觉得“看起来合理”所以加了进去。

一个很大的Backlog，并不等于一个完整的Backlog。一个看起来很完整的Backlog，也不一定是一个好的Backlog。

团队应该从一个仍然能够看清整个产品全貌的层级开始。

我更倾向于先由人来识别数量相对较少的高层级Epic。然后，可以让AI审视这些Epic，并建议团队是否遗漏了某些重要领域。

当团队在这个层级上充分思考过产品之后，再让AI每次帮助分解一两个最重要的 Epic。

这种方式比直接让 AI 一次性创建一个“完整”的 Product Backlog 要安全得多。

在让 AI 生成 Product Backlog Item 之前，首先应该向它说明：这个产品打算如何取得成功？

它是一个希望覆盖几乎所有用户需求、通过功能全面来竞争的产品？还是一个针对特定细分用户、依靠少数几个具有独特价值的功能来取胜的产品？

市场中存在什么空白？为什么客户会选择这个产品，而不是竞争对手？是否存在某些财务目标或时间目标，会影响产品决策？哪些用户画像（Persona）或角色最重要？

这些背景信息能够帮助 AI 提出真正符合产品定位的建议，而不是生成一个千篇一律的“标准版本产品”。

如果缺乏这些背景，AI 往往会建议那些大家意料之中的功能。这些基础必备功能（table-stakes features）当然重要，但它们通常无法让一个产品变得卓越。AI 还可能遗漏 Kano 模型中所说的 Delighters（兴奋型需求）——用户可能不会主动提出，但这些能力却可能真正让产品区别于竞争对手。这一点不仅适用于商业产品，也适用于内部产品。一个内部工具虽然可能没有直接的商业竞争者，但它仍然在与以下事物竞争：当前的工作流程，现有工具，Excel 表格，各种临时解决方案，以及“什么都不改变”。

因此，在生成任何 Product Backlog 之前，应该先说明：

● 产品希望创造什么结果（Outcome）

● 谁会使用它

● 这些人现在是如何完成工作的

● 当前方式中哪些地方缓慢、昂贵、高风险或令人沮丧

● 什么因素会促使他们愿意采用新的解决方案

● 团队将如何判断产品是否成功

● 哪些约束条件和“非目标（Non-goals）”应该限制解决方案

如果是商业产品，还应该说明：

● 市场机会

● 重要竞争对手

● 客户为什么可能选择这个产品

● 相关的财务目标和时间目标

这些战略背景，几乎就像是整个产品本身的验收标准。它定义了：要让这个产品被认为是成功的，必须满足哪些条件？

先从这里开始，然后再利用 AI 帮助团队探索：我们应该如何实现这种成功？

AI通常并没有亲自参与这个产品用户的访谈或现场观察。除非团队把这些真实证据提供给AI，否则AI所生成的往往只是：“看起来合理的功能”，而不是“已经被验证的用户需求”。

因此，团队不能只问：这个AI生成的用户故事是否清晰、是否可测试？

还应该继续问：

● 它是否支持我们的产品定位？

● 我们有什么证据证明用户确实需要它？

● 它是必要的、具有竞争差异化的，还是仅仅“听起来合理”？

● 如果不做它，我们还能成功吗？

● 验收标准描述的是真正重要的事情，还是只是 AI 容易描述的事情？

最后一个问题尤其重要。

假设团队正在开发一个扫描小票的费用报销应用程序。这个产品希望通过让报销变得极其简单而取得成功：用户只需要拍一张小票照片，几乎不需要输入任何内容，就可以完成报销。

● 如果没有这个背景，AI 可能会生成这样的验收标准：

● 用户可以上传 JPG、PNG 和 PDF 格式的小票

● 文件大于 10MB 时显示错误信息

● 用户可以输入商户、日期、金额和费用类别

● 提交之前验证必填字段

● 报销保存成功后显示确认信息

这些验收标准非常明确，也完全可以测试。

但它们描述的其实只是一个很普通的文件上传表单。真正能够保护这个产品竞争优势的验收标准，可能应该关注：

● 从小票照片中自动提取商户、日期、金额和费用类别

● 只有当系统无法有把握识别信息时，才要求用户进行修改

● 自动识别重复小票

● 自动建议合理的费用类别

● 在提交之前识别潜在的公司政策违规问题

第一组验收标准描述的是这个功能能够工作。第二组描述的是为什么用户会更愿意使用这个产品。

如果缺乏战略背景和人的审视，AI很容易产生第一种结果：为一个通用型产品设计出合理的功能。

而真正决定“什么能够让这个特定产品产生价值？”，仍然必须由人来完成。

假设Product Owner独自与AI一起工作，生成了非常完善的用户故事和验收标准，然后把它们“交给”团队。

这种方式可能非常快，但它失去了共同创造（Co-creation）解决方案过程中很多重要的价值。

用户了解用户清楚自身目标、痛点、所处环境以及当下的行为模式。客户（客户并不一定等于最终用户）则会考量采购相关问题、组织内部需求，以及他们自身对价值的定义。

开发、测试、设计及其他团队成员，负责提供技术可行性、潜在风险、约束条件、替代方案，以及如何逐步验证一个想法。

Product Owner负责产品方向和权衡取舍的责任，Product Owner最终决定什么进入Product Backlog，但优秀的Product Owner会在做出这些决定时，与用户、客户和团队共同讨论。

这些并不是应该通过一次次“交接”完成的独立职责。它们实际上代表的是不同类型的知识，被带入同一场产品对话之中。

共同创造能够帮助团队避免解决错误的问题、发现任何一个人单独都无法发现的信息、建立主人翁意识和信任、让最终解决方案更具有适应性。因为更多人理解了为什么我们做出了这样的决定。

AI可以参与这个过程。它可以提出各种可能性、揭示隐藏的假设、发现遗漏情况、提出有价值的问题。

但是，AI既不需要对产品结果负责，也没有关于具体用户和具体情境的第一手知识。

真正的共同理解（Shared Understanding）存在于人与人之间。AI 可以帮助创造形成共同理解的条件，但它无法替代那些真正建立共同理解的对话。

当Product Owner，或者Product Owner与团队一起，对AI生成的用户故事进行审核之后，这个故事可以进入Product Backlog。

但从那以后，它应该和其他所有初稿一样被对待。它需要被排序、被进一步讨论、补充更多细节、拆分、修改甚至删除。

AI在生成用户故事时附带初始验收标准也是有价值的。因为生成这些内容的成本很低，而且通常能够帮助读者更好地理解预期行为。

但它们仍然只是第一版草稿。

当某个事项优先级逐渐提高，并越来越接近进入 Sprint 时，团队应该在 Product Backlog Refinement（产品待办事项梳理）过程中认真审视它的验收标准。

AI 可以在这里提供帮助。它可以帮助发现遗漏、重复和不一致缺少的示例。特别是在用户故事涉及具体计算或业务规则时，AI 可以非常有用。

但是，即使 AI 工具告诉你“这个用户故事已经准备好了”，团队仍然必须运用自己的判断。

AI可以辅助Backlog Refinement，但无法消除Refinement的必要性。

事实上，AI让生成大量细节变得如此容易，反而使得协作式Refinement更加重要。

“Trust but verify——信任，但要验证。”这是使用 AI 时一个不错的原则，但这还不够。

团队不能仅仅检查AI 是否把这个 Product Backlog Item 写对了？团队更应该判断这个东西究竟值不值得做？

应该从以下内容开始：用户 → 产品定位 → 期望结果 → 少量高层级 Epic。然后让AI质疑、补充、扩展团队的思考。让它提出可能遗漏的待办事项，分解选定的 Epic，起草验收标准并在 Refinement中审视用户故事。

然后由人来进行判断。

与用户和客户交谈，与整个团队一起共同创造解决方案。随着最重要的事项越来越接近实施，再逐步对它们进行Refinement。

AI可以编写Product Backlog Item。

但只有一起工作、一起学习的人，才能决定这些待办事项所描述的产品是否真的值得去做。

来源：Mountain Goat Software, “AI Can Write Backlog Items. It Can't Create Shared Understanding” (2026)