在 Uber 构建初版 AI PRD 审阅器的经验教训
如果每位产品经理在 PRD 进入评审室之前,都能拥有一个快速、上下文丰富的初审员,会怎样?我们在 Uber 构建了一个 AI PRD 评估器,以便尽早发现盲点、挖掘既有资料,并为产品评审提供更高价值的信息。
简介
大多数产品组织都有某种形式的评审流程。通常,一旦产品经理(PM)准备好 PRD(产品需求文档)的早期草案,就会在设计、工程、法务、运营、科学和产品领导层之间传阅。该流程旨在提高质量并降低风险。但在实践中,它往往揭示出一个更艰难的现实:PM 可能正在一个系统中做决策,而该系统中相关的背景远远超出任何一个人能独自轻松收集的范围。
一份 PRD 可能带着缺乏依据的余量假设、对功能如何影响相邻系统的盲点、未经审视的二阶效应,或缺少评审者所期望的防护措施的政策敏感性变更进入评审阶段。在其他情况下,团队可能在不知不觉中重新审视一个已经在较小实验或相邻工作中探索过的假设,但相关的背景却分散在文档、幻灯片、仪表盘和机构记忆中。
此时,评审流程往往会转向更底层的发现工作:揭示相邻影响、重建先前背景,并找出那些本应更早解决的问题。这会拖慢团队进度,消耗评审者在本可更早揭示的问题上的注意力,并导致反馈不一致。
真正的问题不在于 PM 缺乏严谨性,而在于产品工作往往需要一个 360 度的视角,而这在当下很难手动收集:相邻影响、合作伙伴的顾虑、先前的实验、隐藏的依赖关系,以及资深评审者可能提出的问题。
这就是我们着手解决的问题。
为什么这在 Uber 很重要
在 Uber,产品开发通过一个结构化的检查点流程进行,该流程让领导层和跨职能团队能够了解情况、加速审批并推动一致的执行。但检查点流程的有效性取决于进入其中的材料的质量。
我们看到了进一步加强该工作流的机会,方法是帮助 PM 更早地揭示重要问题。目标不是改变检查点流程本身,而是提高进入该流程的内容的质量。
这让我们想到了一个简单的问题,并最终催生了 PRD Evaluator:如果每个 PM 在 PRD 进入更广泛的审批流程之前,都能有一个快速、有背景信息的第一轮评审者,会怎样?
AI 驱动的 PRD Evaluator 的作用
PRD Evaluator 是一个 AI 驱动的评审工具,它从一份 PRD 开始,并围绕它构建更广泛的知识库:链接的文档、相关的幻灯片和会议记录、先前的实验、跨职能工件,以及预加载的 Uber 特定背景,如核心原则、指标定义和关键待办任务。它利用这些背景来返回一份关于发布就绪情况的结构化评估。
它的作用是刻意聚焦的:在 PRD 进入高成本评审论坛之前对其进行强化。它不是要取代资深判断,而是帮助团队带着更强的背景和更少的可避免的差距进入这些对话。它位于审批系统的上游,并提高进入该系统的内容的质量。
对我们而言,这意味着构建一个系统,帮助 PM 更早、更好地完成几件事:
- 识别草稿中最重要的差距
- 揭示相邻影响和跨职能依赖关系
- 挖掘当前团队可能未曾察觉的过往经验
- 带着更有力的成果进入检查点与评审论坛
工作原理:从草稿到可执行记分卡的 4 个步骤
我们不想要一个仅仅奖励华丽文笔的通用写作工具。一份 PRD 即使写得再好,也可能缺少决定其能否通过评审的上下文、框架或决策逻辑。
图 1:PRD Evaluator 工作原理概览。
1. 围绕 PRD 构建更广泛的知识库
评估器以 PRD 作为切入点,然后利用 AI 搜索相关的公司文档和关联材料,以汇集良好评估决策所需的上下文:相关文档、过往实验、跨职能输入,以及预加载的 Uber 专属上下文。
2. 对 PRD 进行分类以校准评审深度
并非每份 PRD 都需要同等的审查。评估器会对每个提案进行分类,并据此校准:
- 对于 UX 一致性或可发现性变更,进行轻度评审
- 对于增量式工作流变更或内部工具迁移,进行中度评审
- 对于全新功能,进行全面评审
- 对于政策、定价或市场变更,进行全面评审并施加专项审查
3. 从多个维度评估发布就绪度
评审围绕以下几个维度展开,包括:
- 机会与假设: 问题是否真实存在?成功标准是否定义得足够清晰以供评估?
- 产品范围: 提案是否易于理解、范围界定是否合理、是否已准备好供决策?
- 用户体验与影响: 该体验在不同用户群体、地域和潜在边缘场景下是否都表现良好?
- 指标与数据严谨性: PRD 是否定义了成功标准、护栏以及可信的验证方法?
4. 生成面向行动的记分卡
评估器不会给出一堆评论,而是生成结构化的记分卡:
- 发布就绪度评级
- 逐维度的评估
- 一个明确的“从这里开始”指引,指向最重要的修复项
- 针对每个差距,说明缺失内容,提供可直接使用的替换文本建议,以及来自关联文档或过往实验的证据
- 按优先级排列的行动项,分为关键要求和优化项
该输出的设计目的不止于指出弱点。它旨在让下一轮修订更轻松、更有针对性,让下一次评审对话传递更多有效信息。
图 2:PRD Reviewer 输出格式概要。
图 3:记分卡示例。
对 PM 的价值体现在哪里
最大的价值在于它改变了产品思考的质量和时机。
它拓宽了 PM 的视野
许多最棘手的产品错误源于视野不完整。PM 可能不知道另一个团队此前测试过类似的假设。他们可能没有意识到某个指标存在歧义,或缺少一个明显的护栏。他们可能没有看到下游的运营依赖关系,因为它位于其直接产品界面之外。
一个真正有用的评估器会扩展这一视野。它可以将草稿与先前的产物、相邻的工作、既有的假设以及缺失的问题联系起来——这些内容作者本可访问,否则就只能依赖别人在会议上想起来。它还能呈现那些从未在 PRD 中明确关联、但对理解该决策仍然相关的背景信息。
它使自我评审更加结构化
大多数产品经理都能感觉到一份文档是否薄弱。更难的问题是它为什么薄弱,以及应该先修复什么。
评估器让这种诊断更加明确。产品经理获得的不再是模糊的不安感,而是一个关于缺失基本要素的结构化视图:缺乏支撑的上限假设、未定义的护栏、变更可能影响相邻系统的盲区,或需要承认的风险。
它提升了评审会议的质量
当 PRD 以更好的状态交到评审者手中时,讨论会更快地转向权衡、优先级和判断,而花费在恢复背景信息上的时间则更少。这正是评估器与 Uber 产品开发体系联系最直接的地方。
它将批评转化为可用的修订
该体系中最重要的设计选择不是评分,而是确保可操作性。
“更具体一些”或“考虑下行风险”之类的评论对产品经理帮助不大。评估器最有用的时候,是它将批评转化为修订指导:定义基线、明确目标、补充护栏、缩小首次发布的范围、承认风险,或明确依赖关系。
这将工作流程从被动的批评转变为主动的改进。
早期采用
早期使用验证了核心价值:该评估器帮助 IC PM 早期发现盲点,对缺乏支撑的上限假设进行压力测试,揭示所提变更可能如何影响与其职责不直接相关的相邻系统,并识别其已定义范围内的体验改进机会。
在早期内部使用中,该评估器已被 Uber 各团队的数十位 PM 使用。
当 PM 能够将其纳入日常的起草和评审工作流、提升进入评审内容的保真度,并帮助评审者聚焦于更高信号价值的问题时,该工具的价值便得以体现。
我们的经验教训
在构建和测试该评估器的过程中,有几条经验尤为突出:
- 框架优于泛泛的批评。 宽泛的评论很少能帮助团队提速。真正的杠杆作用来自与实际决策标准和失败模式挂钩的框架。
- 上下文与语言质量同样重要。 许多重要信号存在于 PRD 本身之外,更丰富的上下文往往能揭示出仅看文档无法发现的一组不同盲点。
- 硬性边界让输出更诚实。 定义少量关键缺口,有助于评估器避免在基本面缺失时仍将 PRD 标记为可评审状态。
- 优先级排序是产品的一部分。 将所有内容都标记为重要的评审工具并无帮助。该评估器的价值在于告诉 PM 应优先修复什么。
- 最优秀的 AI 产出能改善人类对话。 评估器正在发挥作用的最有力迹象是,后续的评审讨论变得更加犀利、更加高效。
人类判断仍然重要的地方
评估器的目标不是做出最终的人工批准决定,也不是取代领域专家。该工具最有用的场景是在专家评审之前强化交付物。
结论
产品开发中最困难的部分,是让合适的人在合适的时间做出正确的决定,而所依据的交付物必须足够有力,能够支撑这些决定。
大多数产品组织都有某种形式的检查点、评审论坛或门控审批。名称各不相同,但挑战是一样的:如何确保进入流程的交付物足够有力,使流程能够真正发挥作用?
AI 在这里具有真正的杠杆作用,它作为一个结构化的思考伙伴,在决策进入高成本论坛之前扩展上下文、揭示盲点并磨砺判断。这就是我们构建 PRD Evaluator 的原因。根据我们目前的观察,我们认为这种模式(强化人类决策输入的 AI)的重要性将远远超出某一家公司或某一个工具。
致谢
封面图片来源:由 Gemini 创建
评分卡图片来源:由 Claude 创建