亚马逊Nova产品的演进与客户赋能实践

Filipe Blanes是Amazon AGI Lab的技术团队成员，负责构建下一代产品。他的核心职责之一是客户赋能（Customer Enablement），即深入一线理解客户需求并协助解决实际问题。回顾过去一年，团队于去年3月发布了Nova研究预览版，这是一款旨在自动化浏览器任务的工具。初期目标是通过产品化获取大量客户反馈。7月，团队根据前几个月的观察发现开发者体验存在缺口，从而开发了一套全新的开发者体验方案。到了12月，Nova正式作为AWS上的顶级服务上线，支持构建生产级智能体。在这一过程中，Filipe通过与客户的日常互动，深刻洞察了从研发到生产落地之间的巨大鸿沟。

基准测试的幻觉与静态评测的陷阱

当前AI开发普遍存在一种“基准测试幻觉（Benchmark Illusion）”。工程师们往往致力于在公共基准或自建的合成数据上优化产品，追求极高的跑分。然而，当产品上线后，用户往往会尝试各种预期之外的操作，导致系统崩溃。根本原因在于评测体系的静态性：传统的开发流程是接收需求、构建产品、运行静态评估（如公开基准或合成数据），然后发货。这种模式下，一旦产品交付，开发者只能“祈祷”评测能完全反映用户行为。静态评估无法捕捉真实世界中用户的复杂交互和意外用例，这种从实验室到生产环境的断裂是行业普遍面临的挑战。

构建闭环：以用户定义成功的评估飞轮

解决这一问题的关键不在于追求更完美的基准测试，而在于关闭客户反馈闭环。Filipe提出了一个“评估飞轮（Eval Flywheel）”模型，强调迭代与循环。第一步是定义成功，但这并非由工程师主观决定，而是必须基于“客户认为什么是成功”。第二步是捕捉信号，除了传统的遥测数据和指标外，工程师必须亲自与客户交谈、安排会议甚至实地访问，因为数据本身可能具有误导性。第三步是诊断差距，将收集到的信号分类为三类：模型输入缺陷（需反馈给算法团队）、工程代码漏洞（传统Bug修复）以及产品定位或理解偏差。最后，将这些发现反馈给科学、工程和产品设计团队进行优先级排序和处理。这个飞轮需要不断重复，以适应客户在使用产品过程中的动态演变。

用户旅程的四个阶段与用例发现

在客户使用产品的过程中，他们的需求和技术成熟度会经历不同的演变阶段。Filipe指出，每个客户都有其独特的旅程，而用例发现（Use Case Discovery）是接触新客户时的首要任务。在这一阶段，核心目标是深入理解客户面临的真实问题。通过持续的飞轮迭代，团队能够从静态的基准优化转向动态的用户价值交付，确保产品不仅能在测试中得分高，更能在实际生产环境中稳定运行并解决用户痛点。这种以反馈为核心的方法论，旨在消除基准测试与实际表现之间的落差，建立真正的客户信任。

早期采用者的信号与规模化后的模式识别

在AI产品的生命周期中，早期采用者阶段的核心目标是探索“可能性”。在这个阶段，客户会尝试各种疯狂的使用场景，虽然其中包含大量无法提供帮助的情况，但更重要的是发现客户实际利用产品解决的非预期问题。这种惊喜往往源于用户创造性的用法，这是产品经理未曾想象到的价值点。随着产品进入规模化阶段，客户基数扩大，团队开始从杂乱的使用数据中识别出清晰的模式。这些模式中最重要的就是“英雄用例”（Hero Use Case），即大多数用户都在使用该产品来解决的特定核心问题。与此同时，在产品与早期及规模化客户互动的过程中，团队还会发现产品缺口（Product Gaps）。这些缺口并非失败，而是未来的方向标。产品经理需要利用这些信息来优先排序后续的开发任务，明确下一步应该构建什么功能。这一过程是一个从探索可能性到聚焦核心痛点，再到规划未来路线图的动态演进。

“信任悬崖”：80%与90%可靠性的本质差异

在评估AI产品可靠性时，存在一个被称为“信任悬崖”（Trust Cliff）的关键现象。假设团队构建了一个产品并测得其可靠性为80%，这看似是一个不错的数字。然而，当向客户展示这一数据时，客户的反应并非“可以使用”，而是“我无法信任这个产品”。原因在于，80%的可靠性意味着客户仍需对AI代理进行监控，并在失败时执行手动干预。对于用户而言，这实际上增加了工作量：他们不仅要构建代理，还要监控它并在出错后补救，总投入反而比直接使用传统工具更多。但当可靠性提升至约90%时，客户的心态发生根本转变：他们开始信任产品能够独立处理任务。此时，用户愿意将工作流完全移交给AI。可靠性在此处呈现为“0到1”的二元状态：要么完全信任并放手，要么完全不信任。中间地带并不存在，因为低于90%的可靠性无法消除用户的监控负担。

评估透明度：承认局限性比高分更能建立信任

在与客户合作时，产品透明度的三个维度至关重要。首先是展示“什么能做好”，即明确产品的可靠性水平，让用户知道在哪些场景下可以信任代理。其次是说明“正在改进什么”，坦诚告知已知但尚未解决的差距以及团队当前的投入方向。最困难但也最关键的是“什么不在范围内”（What is out of scope）。许多团队不愿承认产品的局限性，但透明地告知用户产品无法做什么，能显著增加信任感。如果让用户尝试超出能力范围的功能并失败，他们会立即转向竞争对手。核心洞察在于：对产品局限性的透明度比更高的基准测试分数更能赢得客户信任。只有当用户清楚知道产品的边界时，他们才能建立合理的预期并真正信赖产品。

深入客户场景：从卫星轨道到RPA的定制化启示

与客户紧密合作能挖掘出意想不到的用例，从而驱动产品迭代。例如，在与亚马逊旗下的卫星互联网部门Leo合作时，团队发现客户通过缓存轨迹而非每次都进行推理来优化成本。当模型失败时再回退到原始计算，这种轨迹缓存机制极大地降低了费用。在与汽车租赁公司Hertz合作QA自动化时，团队观察到其内部技术人员具备Python等编程能力，但部分非技术背景的QA人员则不具备。这一洞察促使团队开发了一套面向非技术人员的使用体验，扩大了产品的用户基础。此外，RPA公司Sol的案例显示，由于他们处理大量不同的自动化用例，团队需要为产品提供更高的灵活性，特别是允许客户自定义执行栈（Actuation Stack）。这些案例表明，深入理解客户的实际工作流是发现新功能需求的关键。

构建评估飞轮：四大原则与持续进化

基于上述经验，团队总结出了运行“评估飞轮”（Eval Flywheel）的四大原则。第一，从生产环境而非想象中推导评估场景。虽然合成数据在初期有用，但一旦获得客户信号，必须将其反馈到评估体系中。第二，将问题分类为可操作的领域。明确区分产品缺陷、工程问题和研究问题，以便团队合理优先处理。第三，诚实地共享能力边界。再次强调透明度是建立信任的基础，特别是向客户展示产品的不足之处。第四，尽可能快地运行飞轮。评估迭代的速度直接决定产品改进的速度。每周都应看到评估体系变得更智能，如果停滞不前，则意味着评估数据正在过时（Stale）。这一闭环机制确保了产品能够持续适应真实世界的需求。

评估标准必须对齐客户真实痛点

在构建AI产品评估体系时，首要原则是确保测试内容能够准确反映客户的实际关注点。许多团队容易陷入一个误区，即依据内部主观判断来设定评估标准，而非基于用户视角。正确的做法是深入获取客户输入，确保你的评估指标（evals）直接对应他们正在解决的具体问题。如果评估标准偏离了客户的核心诉求，即使分数再高也无法代表产品的真实价值。

"eval must reflect what customer cares about not what you think they care about."

这意味着评估工作不能闭门造车，必须将客户反馈机制嵌入到研发流程中。只有当评估体系真正映射出用户在使用产品时面临的挑战和需求变化，才能为后续的产品优化提供有意义的指导。这种以客户为中心的评估理念是建立可靠AI系统的基础。

构建随用户旅程演进的动态飞轮

评估体系并非一劳永逸的静态产物，而是一个随着客户演变而不断进化的飞轮。我们需要认识到客户的旅程是一个动态过程：当用户从初步接触产品到深度使用时，他们利用产品完成的任务复杂度会显著增加。因此，评估体系必须保持实时更新状态，以精确捕捉客户当前试图完成的具体任务。

"evals are not built once. It's a flywheel that evolves as your customer evolves."

如果评估标准停滞不前，就无法应对日益复杂的用户场景。团队需要建立一种机制，能够敏锐捕捉客户行为的变化。随着产品成熟度的提升和用户技能的增强，他们的期望和交互方式也会发生转变。评估系统必须具备足够的灵活性，能够动态调整权重和内容，以匹配这种复杂度的提升。只有保持评估体系的时效性，才能确保产品始终满足用户当下的最高标准。

通过持续迭代赢得客户信任

最终，建立可靠评估体系的目的是赢得客户的信任。实现这一目标的路径非常清晰：构建闭环、持续交付（ship）、并让评估体系随之进化。当客户看到他们的反馈被认真对待，且产品能够随着他们需求的变化而不断改善时，信任感便由此产生。

"build the loop ship evolves that matter and then you earn your customer trust."

这是一个正向循环的过程。通过不断迭代评估标准，团队能够更精准地解决用户痛点；而解决的成效又反过来强化了用户对产品的信心。这种信任不仅体现在单次交互的成功率上，更体现在长期合作关系的稳固性中。因此，将评估视为一个持续进化的过程而非一次性任务，是确保AI产品长期成功的关键策略。

结论

亚马逊AGI Lab的实践表明，传统静态基准测试存在严重局限，无法反映真实生产环境中的用户行为与意外用例。构建以“评估飞轮”为核心的闭环机制，通过深入客户现场捕捉信号并动态迭代标准，是弥合研发与落地鸿沟的关键。可靠性需突破约90%的“信任悬崖”，才能消除用户监控负担，实现从辅助到自主的转变。同时，坦诚展示能力边界比追求高分更能建立信任。

该模式在早期探索非预期用例及规模化识别核心痛点方面优势显著，但高度依赖持续的客户互动与快速迭代能力。其有效性建立在将评估标准严格对齐客户真实痛点的基础上，而非内部主观判断或合成数据优化。