构建AI产品感知力（下）：一份每周15分钟的修炼指南

Lenny's Newsletter · 2026-02-10🎬 在 YouTube 观看原视频 →

帮助你理解并设计能在混乱现实世界中运行的可信赖AI产品

摘要

本文是"构建AI产品感知力"系列的下篇，由曾在 Google 和 Meta 担任 AI 产品经理多年的 Marily Nika 博士撰写。文章以 Meta 最新推出的"AI产品感知力"（Product Sense with AI）面试为切入点，指出AI产品感知力——理解模型能做什么、会在哪里失败，并在这些约束下设计出用户喜爱的产品——正在成为产品管理的核心新技能。Nika 提出了一套仅需每周15分钟的三步修炼法：① 绘制失败模式图谱（通过三种仪式刻意触发模型幻觉、语义脆弱性和推理极限）、② 定义最低可行质量（MVQ）（设定可接受、惊喜和不可发布三道门槛，并估算成本边界）、③ 在行为断裂处设计护栏（用系统提示、澄清式提问和降级策略保护用户免受模型缺陷的影响）。文章强调，2026年真正稀缺的PM，是那些能在混乱输入、模糊意图和零耐心面前，依然交付令人信赖的AI产品的人。

第一章：AI产品感知力——产品管理的新核心能力

Meta 最近增加了一项全新的产品经理（PM）面试环节，这是其PM面试流程五年多来的首次重大变化。这个环节叫"AI产品感知力（Product Sense with AI）"，候选人被要求借助AI实时解决一个产品问题。

在这个面试中，评判标准不是巧妙的提示词（prompt）、模型知识，甚至不是炫目的演示。候选人被评估的是他们如何处理不确定性：他们如何察觉模型在猜测、如何提出正确的追问，以及如何在信息不完美的情况下做出清晰的产品决策。

这一转变反映了一个更宏大的趋势。AI产品感知力——理解模型能做什么、会在哪里失败，并在这些约束下构建用户喜爱的产品——正在成为产品管理的新核心技能。

过去一年里，Marily Nika 在自己的工作和培训中反复观察到同一个模式：AI在受控流程中表现完美……然后因为少数可预测的失败模式（failure mode）而在生产环境中崩溃。一个令人不安的事实是，AI产品开发中最困难的部分，往往发生在真实用户带着混乱输入、模糊意图和零耐心到来的时候。例如，一个客户支持智能体（agent）在演示中可能令人惊艳，但上线后却会因为自信地回答含糊不清或信息不足的问题（比如"这个东西好吗？"）——而不是停下来要求澄清——而悄然失去用户的信任。

Nika 在语音识别和身份特征（speaker identification）领域为对话式平台和个性化体验（设备端助手及多样化硬件产品组合）交付产品已有十年。她从中提炼出一套简单、可重复的工作流程，用来提前发现那些本会在数周后才暴露的问题。这套流程不是理论或框架，而是一种重要的实践——它给你关于模型行为、失败模式和权衡取舍的早期反馈，迫使你在用户以惨痛方式教会你之前，先看清这个AI产品是否经得起现实的考验。

当你运行这套流程时，两件事会迅速发生：你不再对模型行为感到意外，因为你已经亲身体验过那些奇怪的情况；你会清楚地分辨出什么是产品问题，什么是模型局限。

从另一个角度看，这份工作从"这是个好产品创意吗？"扩展到了"这个产品在真实世界中会如何表现？"

第二章：第一步——绘制失败模式（与预期行为）图谱

每一个AI功能都有一个失败特征（failure signature）：当世界变得混乱时，它会可靠地陷入的那组崩溃模式。而构建AI产品感知力最快的方法，就是在你的用户之前，刻意将模型推入这些失败模式。

Nika 每周进行一次以下仪式，通常在周三上午、第一次会议之前，针对她当前正在构建的任何AI工作流。全部加起来不到15分钟，但每一秒都值得。结果始终能为她提前揭示那些本会在生产环境中很久之后才会出现的问题。

仪式一：让模型做一件明显错误的事（2分钟）

目标： 理解模型将结构强加于混沌之上的倾向。

拿出每个PM每天处理的典型混乱数据——Slack对话串、会议记录、Jira评论——然后让模型从中提取"战略决策"。这正是生成式模型暴露出其最危险模式的地方：

面对混乱时，它们会自信地发明结构。

举个例子。以下是一段混乱的 Slack 对话：

Alice: "Stripe 对欧盟用户又出问题了？"
Ben: "不知道，可能是 webhook 的问题？"
Sara: "哈哈，我们能别再重命名那个 onboarding 弹窗了吗？"
Kyle: "暗黑模式还没想好怎么搞"
Alice: "我们周四前必须把 onboarding 交付出去"
Ben: "等等，移动端的 banner 是不是还坏着？？？"
Sara: "我之后可以改文案"

Nika 让模型从这段对话中提取"战略产品决策"，模型自信地幻觉（hallucinate）出了一份路线图，分配了错误的责任人，把随口一提的评论变成了正式承诺。输出看起来权威、干净、结构化——但完全错误。这就是每个AI PM必须围绕其进行设计的失败特征。

具体操作步骤：

1. 用同一段对话再跑一次模型

使用导致幻觉的同一段混乱上下文。比如（你粘贴 Slack 对话）：

基于这段 Slack 讨论，起草我们的 Q4 路线图。

假设模型编造了你从未讨论过的功能。很好，你已经找到了一个失败模式。

2. 告诉模型"好"是什么样子，再跑一次

添加一句简短说明来解释预期行为：

再试一次，但只包含对话中明确提到的事项。如果信息不足，就说"信息不够"。

用同样的对话串运行这个提示词。正确、可信赖的行为应该是：承认缺乏明确决策，提出澄清性问题，在不编造事实的情况下呈现有用的结构（"关键主题"）。避免在未明确声明的情况下分配责任人，并突出不确定性而非隐藏它们。

3. 并排对比两个输出——以及导致它们的输入

自信幻觉 vs. 谦逊清晰——这种对比教会你模型当前的行为方式，以及你需要朝什么方向设计。正是这种对比，让AI产品感知力最快地磨砺出来。

你需要问：
- 什么变了？
- 哪个护栏（guardrail）修复了幻觉？
- 模型需要什么才能可靠地行动？（明确的约束？更好的上下文？更紧的范围？）
- "好"的版本是否感觉可以交付，还是仍然脆弱？
- 用户在每个版本中会有什么体验？

4. 捕捉差距——这将成为产品需求

当你看到一个失败模式反复出现时，它通常指向特定类型的产品缺口（以及特定类型的修复方案）。现在你知道了产品在哪里失败，以及它的预期行为应该是什么。

仪式二：让模型做一件模糊的事（3分钟）

目标： 理解模型的语义脆弱性（semantic fragility）。

模糊性是概率系统的克星，因为如果模型不能完全理解用户的意图，它就会用最佳猜测填补空白（即幻觉、糟糕的想法）。这时用户信任就开始崩塌。试试，例如，将一份产品需求文档（PRD）输入 NotebookLM，然后让它"为产品VP总结这份PRD"。

2分钟快速测试方法（NotebookLM）：

  1. 打开 NotebookLM → 创建新笔记本
  2. 上传一份 PRD（Google Doc/PDF 均可）
  3. 提问："为高管总结这份文档，并列出前5大风险和未决问题。"

检查模型是否：
- 过度概括？
- 抓着一个无关细节不放？
- 忽略了限制条件？
- 假设了错误的受众？

模型的失败揭示了其语义脆弱性的所在——模型在技术层面理解你的词语，但完全错过了你的意图。其他例子包括：你要求为领导层做总结，它却给你一列表情符号和对话中的笑话；或者你要求找出UX问题，它却自信地提出一套新的定价模型。

你在这里学到的是模型在哪里会困惑，而这正是你的产品应该介入并消除歧义的地方。这可能意味着让用户选择一个目标（"为谁总结？"），给模型更多上下文，或者限制操作使模型无法偏离轨道。你不是在"欺骗"模型；你是在理解沟通在哪里断裂，以便通过设计来防止误解。

可测试的模糊提示词示例：

测试不同的解读方式，看模型会在哪里走偏——这是又一批需要你通过AI产品设计来引导它走向可预测、可信赖结果的设计工作。

仪式三：让模型做一件意外困难的事（3分钟）

目标： 理解模型的第一个失败点。

选择一个对人类PM来说感觉简单但对模型的推理、上下文或判断构成压力的任务。你不是在穷举测试模型，而是在看清它最先在哪里断裂，这样你就能知道产品需要在哪里提供组织性结构。它开始出问题的地方，正是你需要设计护栏、缩小输入范围或将任务拆分为更小步骤的地方。

注意： 这还不是最终解决方案，这只是预期行为。在后面的护栏部分会展示如何将其转化为产品中的显式规则（提示词 + UX + 降级行为）。

示例1： "将这40个 bug 按主题分组并提出一份路线图。"

让模型处理大量杂乱的 bug 报告——看它是否能保持上下文一致性，还是会混淆主题、遗漏关键项或发明不存在的关联。

示例2： "总结这份 PRD 并为领导层标记风险。"

考验模型在长篇技术文档中提取最重要信息并正确判断风险优先级的能力。

完成三个仪式后，你现在拥有了一份完整的清单，列出了需要完成的产品设计工作，以便获得你和用户可以信赖并使用的结果。随着时间推移，这类工作还会开始揭示二阶效应——那些微小的AI功能悄悄重塑工作流、默认设置和期望值的时刻。系统层面的洞察会在基础稳固后到来。第一目标是理解行为。

第三章：第二步——定义最低可行质量（MVQ）

即使你理解了模型的失败模式并围绕它们进行了设计，也几乎不可能完全预测AI功能在接触真实世界后会如何表现——但性能几乎总是在脱离受控开发环境后下降。由于你不知道它会如何下降或下降多少，从一开始就保持高标准的最好方法之一，就是定义一个最低可行质量（Minimum Viable Quality, MVQ），并在整个开发过程中用它来检验你的产品。

一个强有力的 MVQ 明确定义三个阈值：

  1. 可接受线（Acceptable bar）： 对真实用户来说足够好的水平
  2. 惊喜线（Delight bar）： 让功能感觉神奇的水平
  3. 不可发布线（Do-not-ship bar）： 会摧毁用户信任的不可接受失败率

MVQ 中同样重要的是产品的成本边界（cost envelope）：这个功能在规模化运行时将花费的粗略成本范围。

Nika 分享了一个来自她亲身经历的具体 MVQ 案例。她花了多年时间从事语音识别和说话人识别（speaker identification）工作，在这个领域，实验室准确度和真实世界准确度之间的差距是痛苦可见的。

她仍然记得那些演示：模型在受控测试中达到90%以上的准确率，然后在第一次在真实家庭中试用时完全崩溃。一只狂吠的狗、一台运行中的洗碗机、有人在房间另一头说话——突然间，"很棒"的模型感觉坏掉了。而从用户的角度看，它确实坏掉了。

以智能音箱的AI功能中识别谁在说话的能力为例，MVQ 如下：

可接受线（Acceptable bar）

惊喜线（Delight bar）

你不需要一个完美的百分比来知道是否达到了正确的惊喜线，你会寻找行为信号：
- 用户不再重复自己或重新表述指令
- "不，我是说……"这类纠正急剧减少

经验法则：如果在真实条件下10次尝试中有8或9次无需重试就能成功，就会感觉神奇。如果每5次就有1次需要重试，信任就会迅速消蚀。MVQ 还取决于你所处的阶段。在封闭测试（closed beta）中，用户通常能容忍粗糙边缘，因为他们期待迭代。在广泛发布中，同样的失败模式会感觉像产品坏掉了。

评估惊喜的语音识别示例：

不可发布线（Do-not-ship bar）

你可能注意到了，Nika 并没有给每条线赋值。这是因为 MVQ 的具体阈值（你的"可接受"、"惊喜"和"不可发布"线）不是固定的。它们严重依赖你的战略上下文（strategic context）。

第四章：影响MVQ的五大战略因素与成本边界估算

五大战略上下文因素

以下五个因素最常决定 MVQ 标准应该设在哪里，以及它们如何改变你的产品决策：

  1. 失败成本（Cost of failure）： 错误购买 vs. 错误推荐歌曲的代价天差地别。涉及金钱、隐私或安全的功能，MVQ 标准必须更高。
  2. 用户容忍度（User tolerance）： 内部工具 vs. 消费者产品——用户对缺陷的耐心截然不同。
  3. 发布阶段（Launch stage）： Beta 版 vs. 全面发布（GA）——同一功能的同一失败率在 beta 中可接受，在 GA 中可能不可接受。
  4. 竞争格局（Competitive landscape）： 如果你的竞争对手已经解决了这个问题而你不行，你的可接受线会飙升。
  5. 可逆性（Reversibility）： 用户能撤销AI的行为吗？如果能，你可以容忍更高的失败率。

估算成本边界

新AI PM最常犯的错误之一是爱上一个令人惊艳的AI演示而没有检查它在财务上是否可行。这就是为什么需要尽早估算 AI 产品或功能的成本边界。

成本边界 = 这个功能在规模化运行时为用户服务的粗略成本范围。

你不需要精确数字，但需要一个大致的范围。从以下问题开始：

示例：AI 会议记录

现在你可以进行真正的讨论了：
- 一个实际成本为$0.30/用户/月且能驱动留存的功能，是无需犹豫的选择。
- 一个最终$5/用户/月但影响不明确的功能，则是一个商业问题。

这是AI产品感知力的核心组成部分：你所提议的产品对业务来说真的有意义吗？

第五章：第三步——在行为断裂处设计护栏

现在你更好地理解了模型行为在哪里断裂，以及你需要什么标准来批准发布，接下来是时候将一些护栏（guardrails）系统化并设计到产品中。一个好的护栏决定了当模型触及其极限时产品应该做什么，这样用户就不会困惑、被误导或失去信任。

在实践中，护栏保护用户免于体验模型的失败模式。Nika 合作的一家初创公司构建了一个AI功能来提高团队生产力——将长 Slack 对话串总结为"决策和行动事项"。在测试中它运行良好——直到它开始为行动事项分配责任人，而实际上还没有人同意任何事情。有时它甚至选了错误的人。

因为她的团队已经培养了AI产品感知力，他们发现修复方案是产品中的一个新护栏，而不是换一个底层模型。于是他们在系统提示（system prompt）中添加了一条简单规则（在这个案例中，只是一行额外指令）：

只有当某人明确自愿或被直接要求并确认后，才分配责任人。否则，呈现主题并询问用户下一步该做什么。

这一个约束几乎立即消除了最大的信任问题。

仪式四：在系统提示中添加显式的失败响应（3分钟）

在第一步中，你找出了系统在哪里断裂。现在你将决定产品在断裂时应该做什么。

覆盖大多数真实场景的四种护栏模式

1. 当模型似乎不确定 → 询问而不是猜测

在实践中，这通常意味着在系统提示或任务提示中添加显式指令，例如：

"如果你不确定，请提出一个澄清性问题，而不是做出假设。"

小问题能走很远：
- "你是想要总结还是关键决策？"
- "我应该聚焦 onboarding 还是支付？"

这些检查往往能防止下游出现大得多的错误。

2. 当上下文太长 → 给用户一个选择

不让模型静默丢弃信息：

"这段对话很长——我应该聚焦前半部分、后半部分，还是只看行动事项？"

这很快、很诚实，并且避免了幻觉。

3. 当模型发明结构 → 直接说出来

如果输入中没有决策、责任人或明确结论：

"我在这里没有看到任何决策——你想要主题分析吗？"

透明建立信任。

4. 当输出每次都不一样 → 添加轻量结构

如果同样的请求产生截然不同的答案，用简单的格式稳定它：

"列出：讨论了什么、决定了什么、需要跟进什么。"

这减少了方差，同时不会让产品变得僵化。

因此，在一次近期的产品评审中，当 Nika 被要求"修复模型"时，她转而决定了当模型触及其极限时产品应该做什么。没有一个护栏让模型更"智能"。好的护栏只是保护用户免受模型缺陷的影响，防止误解。你提前决定系统应该如何减速、寻求帮助、缩小范围或说"我不知道"。这就是AI产品如何优雅地失败（fail gracefully）而不是灾难性地失败。

第六章：结语——AI产品感知力是可靠用户体验的基石

AI产品感知力是一块通过重复锻炼而成的肌肉——通过看到真实输出、捕捉真实失败模式、在不确定性下做出真实产品决策。

有一件事让 Nika 感到意外：她最近问她的AI PM训练营学生（以及几位PM同行）"AI产品感知力"对他们意味着什么，得到了非常不同的答案。

有人说的是模型知识。
有人说是评估。
有人说是提示工程（prompting）。
有人说是安全性。
有人说是成本和单位经济学。

我们正处于一项新的PM技能走向主流的早期阶段，行业仍在就"优秀"的样子形成共识。但在交付产品、辅导学生、看着AI产品在生产环境中崩溃之后，Nika 发现实际的定义要简单得多：

AI产品感知力是将概率性模型行为转化为人们可以依赖的产品体验的能力。

这正是本指南真正的核心——培养一种直觉：发现模型会在哪里猜测而不是询问，在上线前定义质量线（包括成本），设计护栏使失败可预测且可恢复。

每周运行一次这些仪式， AI产品感知力就不再是抽象的。你将停止对奇怪的输出感到意外，因为你已经开始设计更清晰的提问、更紧的约束和更好的降级策略——因为你知道事情会在哪里断裂。

在2026年，真正稀缺的差异化能力，是那些能在混乱输入、模糊意图和零耐心面前，依然交付令人信赖的AI产品的PM。

原文作者：Marily Nika 博士（前 Google/Meta AI PM，AI产品管理教育者）
原文发表于 Lenny's Newsletter：https://www.lennysnewsletter.com/p/building-ai-product-sense-part-2
本文为中文精译版，保留了原文的全部关键数据、引用和推理链。