# 通过模拟发现你的产品
LLMS 索引： [llms.txt](/llms.txt)
---
> 你必须从客户体验出发，再反推技术。你不能从技术出发，再去想你要把它卖到哪里。
>
> — 史蒂夫·乔布斯
在[第 6 章](/ch6/#ch06_target_aud)中，我们找到了自己的客户。我们想弄清楚客户是谁、他们的问题是什么。通过这个过程，我们打磨出了一份产品论题（product thesis）：即我们对“什么才是这群人眼中的优秀产品”的高层主张。
但我们暂时按住了对解决方案的深入思考。
在这一章，我们将打开闸门，把注意力转向*产品发现*（product discovery）。
也就是说，在构成用户场景的角色与模拟中，目前我们只有角色。现在该写模拟了。
但你想构建的这个产品或功能，还不存在。没人讲过关于它的故事。如果我们想第一次就尽量做对，就必须先讲一些微型科幻故事，预测用户将如何驾驭我们赋予他们的新能力。
于是，一场从产品之地走向系统之地的伟大旅程开始了。
### 从愿景到需求 {#id118}
软件开发里一个老大难问题是后期才冒出的产品需求：我们前面没看到它们。有时它们来自用户反馈，有时是我们在设计和实现时才意识到更多细节。这会拖慢路线图、扩大范围。而这类不受欢迎意外的一大原因，就是前期发现工作不够。
为了减少惊喜，这里有一条我在中大型项目中验证过有效的路线。每个团队工作方式都不同，所以我不打算规定某个流程或文档模板，而是突出我认为你应该关注的关键点。
- 用用户场景补完产品愿景，这些场景叫*北极星场景*（north star scenarios）。
- 把这些北极星场景切分重组，整理成需求，形式是*用例汇编*（use case compendium）。
- 制作路线图，聚焦第一个里程碑，覆盖最关键的需求。
- 提出你要在第一个里程碑交付什么。把细节故事写出来，称为*用户流程*（user flows）；如果展示用户界面，也可称为*分镜图*（storyboards）。
- 为你选中的每个用例补充详细系统需求，并在必要时回流到原始需求。
- 基于用户流程与系统需求，整理一份*待完成工作*（jobs to be done）清单。
到这一步，你已经从发现过渡到定义。定义通常包含更详细的设计，我们会在后续章节里讲。
没有任何流程能让你无所不知，在周期后段才学到意外信息是自然的。但这些意外的规模应该小很多，并且最好不至于威胁产品生死。
[图 7-1](/ch7/#product_discovery_workflow) 展示了一个围绕产品发现组织流程的示例，它分成三份文档：
- **产品简报（Product brief）**：一份愿景文档，用于让所有人对目标达成一致。有时也叫“问题简报（problem brief）”或“一页纸（one-pager）”。最少应包含：产品论题/反命题与目标受众（[第 6 章](/ch6/#ch06_target_aud)）、要追踪的目标或产品指标（[第 5 章](/ch5/#ch05_user_feedback)），以及稍后会定义的*北极星场景*。在双钻模型（Double Diamond）术语里，它的目标是为发现阶段清障。
- **产品需求文档（Product requirements document）**：展开产品应该具备的属性，不仅面向长期，也提出首个可交付物或里程碑，同时尽量减少对实现方式的过度规定。目标是为定义阶段清障。
- **产品规格（Product specification）**：展示产品应如何设计。目标是为开发阶段清障。
**图 7-1.** 一个产品发现流程示例
我并不是来推销某个特定流程的，而且我接触的大多数团队并不会把这三步都正式化。不过在本章里，我会用这个流程演示如何系统地从愿景走向可执行设计。即使你只把它用于个人工作流，我也希望它有价值。
无论你的团队如何运作，这里有三个关键属性值得追求。
第一，正式或非正式地把工作拆成多个阶段：为什么（why）、做什么（what）、怎么做（how），都从用户视角出发。粗略地说，阶段 1 聚焦用户*为什么*希望我们采取行动，阶段 2 聚焦用户在要求*什么*，阶段 3 聚焦用户将*如何*达成目标。每个阶段都要警惕过早陷入你现在还不必思考的细节泥潭。
第二，在每个阶段都用场景模拟来确保团队对齐并解决完整问题，这种做法叫*场景驱动发现*（scenario-driven discovery）。后面我会展开讲。
最后，要允许向前一阶段回流反馈。负责产品规格的工程师和设计师，需要和负责产品简报的工程师与 PM 紧密协作，让团队持续学习。没有这种反馈，你得到的就是“瀑布式”做法。鉴于软件开发的混沌本质，瀑布法已经逐渐失宠。它往往会导致：因为后面难改，所以前面过度思考；同时又无法适应信息变化。
这一章里，我会逐步走完整个产品发现流程。
过程中，我会重点讲一些与发现和优先级相关的重要概念：
- 如何把用例组织清楚
- 如何从产品思维过渡到系统思维
- 如何批判性地思考产品给用户带来的价值，包括四条“残酷真相”
- 如何整体评估构建与维护软件的投入规模
- 如何用用户流程梳理你的待完成工作（jobs to be done）
作为开场，我先给出一个关于构建 AI 代理的案例研究。
### 案例研究导入 {#id119}
当我写下这些内容时，时间是 2025 年，也就是所谓的“代理之年（year of the agent）”，所以要是不放一个 AI 助手或代理案例就有点说不过去。这个案例是虚构的，但它融合了真实公司正在尝试的产品特征——目前谁也不确定最终会怎样。未来的读者：欢迎告诉我结果如何。
假设我们在 Kabletown（一家互联网和有线电视服务商）的支持工程团队。我们的团队使命是让支持服务运转顺畅。现有一套遗留自动化系统会先和客户聊天、尽量先帮忙再转人工，但它使用的是大语言模型（LLM）之前的技术，对于客户多样化需求过于僵硬。客户说他们讨厌 Kabletown 的支持体验，觉得自己被困住了。与此同时，人工客服被压垮，用户的邮件和聊天回复要等好几天。
我们注意到，前七类账户操作占了支持请求量的 65%，但当前方案实际自动化有效覆盖只有大约 15%。
先给出几个你需要知道的 AI 相关定义。
- **Assistant（助手）**：一种 AI，能在与用户的一次交互中回答问题、做分析并执行任务。
- **Agent（代理）**：也能做到上述能力，但还能围绕目标自主规划并行动。
- **Tool（工具）**：带有描述信息的函数，用于告诉助手或代理应如何调用它。
由于 Kabletown 还不确定自己需要 agent 还是 assistant，所以在不需要精确区分的地方，我会交替使用这两个词。
现在我们来填写产品简报的几个部分。
#### AI 助手产品简报 {#id216}
我们的自动化支持代理 Helpy McHelpface，将彻底改变 Kabletown 的技术支持与账户支持体验。
##### 产品论题 {#id120}
我们提出两个基本主张：
- **降低用户挫败感**：用户对当前助手很不满意，它在大多数请求上表现糟糕，甚至连何时该转人工都判断不准，这项判断 80% 的时候都错。Helpy McHelpface 会比旧技术更好地处理与客户的直接沟通，因为它更能理解用户意图，从而降低用户挫败感。
- **降低支持事务性负担**：当前助手一旦要做变更就必须拉人类介入。如果给 Helpy 配置可操作账户变更、创建预约、下发寄送订单等工具，我们就有机会把剩余未自动化支持量中的一半以上也自动化。通过加速这些例行但耗人的工作，我们可以显著缩短等待时间、提升用户满意度，同时减轻支持代表积压。
##### 反命题/风险 {#id295}
哪些因素可能导致结果不如预期？
- Helpy 可能会执行它不该执行的动作，导致用户产生糟糕的意外体验。
- 我们可能无法仅靠 assistant 达成目标，而需要一个自主规划 agent，从而抬高构建和运行成本。
- 我们的知识库可能不足以提供 Helpy 所需上下文。
##### 目标受众 {#id296}
我们有两个目标人物画像，不过可能会先做其中一个：
- **账户支持用户**：Tinker Tia 是 Kabletown 的长期互联网和有线电视客户，她想修改自己的账户，比如升级/降级服务，或新增/升级硬件。
- **技术支持用户**：Sad Lisa 是新加入的 Kabletown 宽带客户，遇到问题无法正常使用，希望尽快修好。
##### 产品目标 {#id121}
我们的首要目标是提升用户满意度，并在不大量扩招的情况下改善支持积压。我们认为这两个目标可以同时达成。短期内我们不以提升利润为目标。
- **采用指标（Adoption metric）**：把完全自动化支持交互比例从 15% 提升到 65%。
- **价值指标（Value metric）**：把助手与人工支持后的客户满意度评分从 2.1 提升到 3.5（满分 5 分）。
- **KPI**：利润中性。虽然我们希望长期降低人工支持成本，但也可能因为更容易降级套餐等因素压低收入。我们会跟踪降级行为以理解收入影响。
##### 北极星场景 {#id297}
这一节我们稍后会回到。
### 用北极星场景补完你的产品愿景 {#id217}
在我写北极星场景前，先解释一下场景驱动发现，然后再讲如何为产品简报做场景头脑风暴、筛选与打磨。
#### 场景驱动发现 {#id122}
*场景驱动发现*（SDD）是指在整个发现流程中持续使用场景。我在发明这个术语，但不是在发明这件事本身——业界最接近的概念是“场景化设计（scenario-based design）”，只是它并不算广为人知。我希望有一个更直接表达“我们如何用场景去挖需求和待完成工作”的词。
你可以依靠场景来确保最终交付给用户的是完整而有用的产品，原因如下：
- 通过突出角色需求，它能把*为什么*讲清楚，确保需求与原始意图一致。
- 它能照亮完整故事，因此我们更可能发现重要功能或边缘情况。
- 相比抽象需求清单，故事更不容易被误读。一套共享故事更容易让团队对齐。
- 在场景里找情节漏洞，比在需求列表里“调 bug”更容易。
产品简报里的场景通常被称为*北极星场景*。
> [!NOTE]
> 北极星场景是你会贯穿整个产品生命周期持续沿用的一组重点故事。别人问你在做什么时，你会拿它来解释。它们会为产品需求提供论据并输入其中，后续你还会用它们检查是否漏建了关键东西。你会基于它们做演示。视产品而定，它们也很可能演化成营销材料、快速上手指南或示例。
在产品需求文档中，场景会被切成细粒度“需求”，或者在敏捷术语里叫“故事”。
在产品规格中，场景通常称为用户流程或分镜图。
本节里，我会以补完 Helpy McHelpface 产品简报为目标，演示北极星场景的准备过程。
#### 以团队方式头脑风暴场景 {#id123}
并不是每位工程师都喜欢写完整用户故事。有人觉得陌生所以畏难；也有人天生更擅长挑故事毛病，而不是从零创作。弥补这些差距的一个好办法是结对或组队。协作写故事非常有趣。某个场景可以先由一个同事写出内核，再由其他人补步骤。最后每个人都会有共同所有权和共同打磨作品的成就感。
和任何头脑风暴一样，协作构思用户故事需要接纳每个人的想法，并在他人的想法上继续搭建。但在压力和紧迫截止日期下，如何保持冷静与包容？
这些年我学到的关键一点是：做发现工作时，不同人（通常是下意识地）心里装着不同时间尺度。有人看长期，有人看未来几周。有人角色更偏前瞻，有人更偏战术。
在头脑风暴时，要允许大家面向未来做梦。先和团队约定：某个故事里出现了“构建成本很高的功能”，不代表它马上就要做。这能消除那种紧张感——有些人会担心你打算把所有功能都塞进首个版本。
并且在你制定第一个里程碑前，都要保持这种心态。你的目标是先有足够多想法，避免错过最优方案；同时形成一份面向未来的路线图，让每个里程碑都在服务长期愿景。
头脑风暴应该是有趣的！敏捷方法里著名的“便利贴”练习，就是大家把小故事写在彩色便利贴上，再按主题分类、筛选优先。你们团队怎么顺手就怎么来，但最好最终沉淀成一份共享文档，包含几条北极星场景。
#### 选择并打磨北极星场景 {#id124}
选出那些最重要、最能说明问题、也最可能进入路线图的场景。后面你还会继续做优先级，但第一步先把最关键想法挑出来，并把最能照亮这些想法的故事补完整。
如[第 1 章](/ch1/#ch01_foundations_prod)所述，团队应该通过寻找情节漏洞来给选中的故事“调试”。有些故事是不是跳过了用户旅程中的关键步骤？是不是对用户做了英雄式假设？是不是忽略了关键细节？团队中有些工程师也许不擅长从零写故事，但他们在这一步可能非常强，这同样很有价值。
就我个人经验，通过书面评论而不是口头争辩来做这种调试，既高效又和气。这有助于让头脑风暴保持“增量、积极”的氛围。
记住这些是高层故事；这个阶段追求的是“准确”，而不是“精确到细节”。等到有人写用户流程时，细节会下钻得非常深。
有了完整且有说服力的故事，我们后面就更容易看见所有需求。
以下是 Kabletown 的第一条北极星场景：
- **有线电视盒安装**：Tinker Tia 想给卧室的第二台电视配一个新的有线电视盒。她在笔记本上访问 kabletown.com，找到了 Helpy。Helpy 同意帮忙，并询问她是否需要安装人员协助，她回答需要。Helpy 引导她完成套餐变更并获得确认，然后触发寄送订单。订单发货时，它会在聊天里提醒她，Tia 收到通知后可安排安装预约。Helpy 会与她确认时间约束，并把预约安排在货到之后。技术人员报告安装完成后，Helpy 还会回访并发起满意度调查。
我是怎么写出这个场景的？我的目标是把故事当作创意聚焦工具，避免漏掉重要需求。
- 我先从一个常见用户问题出发：“想安装一个新有线电视盒”。
- 我不断追问自己：“Tia 下一步需要发生什么？”“Kabletown 的流程必须怎样配合？”直到用户完整问题被解决。
- 我思考了如何跟踪价值指标，于是在结尾加了客户调查。
- 我主动找情节漏洞。当故事某部分过于模糊，或让我担心某种结果时，我会问自己：“这里有哪些关键细节会帮助我们指导需求？”
- 我回头检查自己是否对具体方案规定太多。我的重点应该是“做什么”和“为什么”，而不是“怎么做”。
头脑风暴后，团队注意到这个场景里 Helpy 需要走一条复杂工作流，于是开始讨论：Helpy 是否需要较高自主性，还是可以用硬编码工作流包裹一个 assistant。团队勾勒了这个场景的若干变体，展示 Helpy 将面对的广泛情形，并据此决定 Helpy 需要是一个 agent，而不仅是 assistant。随后他们回去更新了产品论题/反命题。
由于北极星场景要广泛传播，他们把这些变体从主列表里拿掉，以保证易读。他们另外做了一个“附录”，收纳与他们相关但不必向整个组织重点传播的额外场景。
团队又草拟了几条北极星场景，以覆盖更广需求范围，比如移动端与 PC、销售支持与技术支持（或两者兼有），以及在销售类中区分升级与降级。他们特别想突出降级，因为在产品简报里提到过它可能涉及收入上的争议。目标是在改动成本变高前，尽早暴露最大风险与认知不一致，并确保包括财务团队在内的相关方都感觉被代表。
- **降级**：Tinker Tia 有两个有线电视盒，但从不使用卧室电视那个，她想降低月费。Helpy 搜索了一个与她现有方案接近但不含额外机顶盒的套餐，并告诉她可以节省多少费用。她同意该方案，Helpy 告知只要归还机顶盒就会处理降级。她确认后，Helpy 给她寄出回寄包装。她寄回设备后，Helpy 在签收后给她发满意度调查。
- **带账户变更诉求的愤怒用户**：Tinker Tia 基本不用某个房间的机顶盒，想降月费。她查看账户时发现了 Helpy 链接并发起咨询。Helpy 注意到她处于促销价周期，于是告知没有能让她省钱的可切换方案。她很生气，要求找主管。人工客服从 Helpy 接管该聊天。双方最终协商为：只要她归还机顶盒，就给一次性小额折扣。她同意并收到满意度调查。
- **故障中断**：Sad Lisa 的有线宽带断网了。她在手机上打开 Kabletown App（手机套餐仍可用），看到 Helpy 按钮并询问发生了什么。Helpy 将她地址与故障地图比对，发现确有中断并发送预计恢复时间。故障恢复后，Helpy 再次通知并附带满意度调查。
- **客户硬件问题**：Sad Lisa 觉得网速慢，认为是 Kabletown 的问题。她在 kabletown.com 看见 Helpy 的“获取支持”按钮并点击。Helpy 询问她的设备与环境，发现她在无线网络下使用 PC 笔记本。它判断没有区域故障后，便引导她执行一系列诊断与建议，从历史最成功方案开始，包括重置无线路由器、运行 Windows 网络诊断等。重置 Kabletown 提供的无线路由器后问题解决。Helpy 告知她若问题反复出现可再次联系（例如路由器故障），随后发起调查，她给出了很高评分。
在写这些场景时：
- 我有意加入摩擦和失败情境，例如用户不喜欢机器人，以确保 Helpy 具备韧性。
- 当我想到不同需求时，我会写包含这些需求的故事。比如我通过“Lisa 家宽断网，只能转向蜂窝设备”来论证移动端支持必要性。故事本身就是这些功能的“销售提案”，后面做优先级时我们会逐一评估。
如果我做得还行，这些场景应该能让人清晰、直观地理解我们想达成什么。因为故事是人类从小就习得的通用沟通媒介。你对系统的心智模型也许和我不同，但我们大概率能在这些故事含义上达成一致。
把这些故事都实现出来可能并不容易。这反而是好事。请回忆序言里讲过的双钻模型：产品生命周期中的发现阶段本来就是发散、探索的。愿景应该把标准拉高，推动我们去做那些虽然困难但影响巨大的事情。即便后来发现，比如给 Tia 在订单发货时推送通知很难，我们也可以迭代，之后再写替代故事。或者通过分批发布逐步补全这些故事，只要每次增量发布本身都能提供真实价值。
同时要注意，这些场景现在还没有按“便于分工构建”的方式组织。下一步写 PRD 时就会处理这件事。
### 把北极星场景转换为需求 {#id125}
如果把用户故事放进一张数据库表，它会是按时间排序的一系列时刻，并关联到某个人物画像。这是理解用户如何完成产品旅程的一种很好的方式。
但这并不是系统设计最有用的表示。系统设计更像图数据库——页面里有表单，表单里有按钮，点击按钮会连到服务外层的 API 网关，再通往存储系统。
如果我们的大脑里也有类似这些“数据库”，那么从发现阶段走向设计阶段的过程，就是一次从“时间/故事表示”到“图/系统表示”的*大重排*（great reindexing）。[图 7-2](/ch7/#great_reindexing_story_view) 与 [图 7-3](/ch7/#great_reindexing_system_view) 展示了同一产品的两种表示：
**图 7-2.** 故事视图
**图 7-3.** 系统视图
最全能的工程师，往往能在脑中同时构建这两种索引。如果你只会第一种，你就像产品经理；如果你只会第二种，你就会彻底依赖产品经理，并在与其沟通时步履维艰。
这两种表示之间的翻译尤其关键，而误译到处都是，尤其当 PM 与工程师无法内化彼此的表示方式时。
大重排通常从高层需求与设计原则开始。
#### 高层需求 {#id126}
高层需求与设计原则是一份摘要，用来明确我们设计“要达成什么”。优先哪个人物画像？追求营收？还是易用性？它能与那些没法通读全部细节用例的人建立沟通与信任。
对 Kabletown 来说，可能会是这样：
- 根据产品简报，我们要在利润中性的前提下提升用户满意度并降低支持负担。
- 首个里程碑先聚焦技术支持类交互。
- 先瞄准最高频任务，例如慢网诊断。比如 Helpy 识别到超出其能力边界时，应转人工，而不是硬着头皮继续。
- 早期优先安全性，让 Helpy 处于清晰护栏内；即使这意味着它有时不够“尽可能有帮助”。
注意我在显式指出我们如何在冲突原则之间打破平局。把这些权衡明确写出来往往既有争议也有价值，能激发高质量讨论。
如果把这段写在产品需求文档开头，读者会更容易理解后面的内容。
#### 产品需求文档 {#id127}
PRD在不同公司里含义会略有不同。对某些团队，它甚至可能已经包含本章后文会讲到的产品规格。PRD 到底要放多少设计细节本就模糊，尤其是大项目，值得和团队明确。
在我们这里，PRD 的目标是让工程师与 UI 设计师可以开展详细设计。后文的产品规格目标则是让实现工作可以展开。因此这里我们会重“做什么”，轻“怎么做”。我们会包含：
- 高层产品需求与设计原则。
- 细粒度产品需求——一份*用例汇编*（或故事汇编），记录用户想要的具体交互。
- 里程碑定义，用于选择首发要做哪些功能。
- 召集合适团队与相关方共同推进。（本书不展开。）
#### 用例汇编 {#id298}
接下来我们进入产品需求本体。我称之为“用例汇编”，因为每条需求都从用户视角书写。常见模板有：
- “【用户】可以【动作】，从而【动机】。”
- “【产品】提供【功能】，从而让【用户】能够【获得价值】。”
每条需求都是我们某个场景的一段切片。以“客户硬件问题”场景为例——Sad Lisa 网速慢，需要重置无线路由器。
第一条需求是：当 Sad Lisa 寻求技术支持时，她无需先登录就能在首页轻松找到 Helpy。
需求写作的艺术在于：说清楚必须发生什么，但不要过度规定怎么做。以第一条需求为例，写它时我试图做到：
- 足够具体，表达清晰无歧义。比如明确“Helpy 在无需登录的首页可被找到”，而不是笼统写“Helpy 可发现”。
- 表达意图。我们不只是说“Helpy 在首页”，还要明确这件事是为了“可发现性”。如果放在首页做不到，工程师也能回到意图层面寻找备选方案。
- 仍给工程师留出设计空间。我们不规定 Helpy 必须在首页哪个位置或菜单，只规定它必须可发现且登录前可见。
有时很难既清晰又不规定过多，这时我会给一个示例，例如“在首页（例如右下角悬浮聊天按钮）”。
同一条北极星场景剩余需求如下：
- Helpy 能高效引导 Lisa 诊断慢网问题，原因覆盖软件、硬件与故障中断。
- Helpy 会向 Lisa 建议它从支持数据库学习到的最成功干预措施。
- Helpy 会询问 Lisa 哪些措施有效，以便在技术变化中持续学习。
- 当修复尝试结论不明确时，Helpy 能在结束聊天前建议后续跟进行动，避免 Lisa 放弃。
- 应向 Lisa 展示满意度调查，以便我们跟踪结果。
- Helpy 可以基于满意度调查进行训练，从而随时间提升效果。
其余北极星场景也可按同样方式拆分，逐步补全需求。随着思考与学习，我们也可以加入场景之外的新需求；如果漏了大项，还能补新的北极星；如果要降级优先级，也能删掉某些北极星。
我还从其他北极星中挑了几条，后面会讨论，它们与“责任委派”有关：
- Helpy 能以 95% 准确率判断请求属于支持还是销售。
- Helpy 检测用户沮丧情绪的能力至少达到人工坐席的 90%，并可转人工。
- 人工客服在接管对话时可咨询 Helpy，从而使人工支持效果至少不低于 Helpy 自己提供的水平。
这些百分比多少有些武断，我们现在也未必知道真实可达上限，但先给出粗量级。后续我们会通过一种叫*evals*的代理质量评测来约束自己。如果离这些数值差太多，我们会重新评估方案。
再补一条后面还会再提到的需求：
- Sad Lisa 可以在不使用家庭宽带的移动设备上使用 Helpy，以便在故障中断期间获得支持。
#### 组织你的用例汇编 {#id128}
用例汇编通常会贯穿工程团队的优先级、设计与执行阶段。理想情况下我们会一次性前置挖完需求，但现实里随着迭代，常常还会新增。
这让用例汇编成为承重文档。对中大型项目来说，把它组织好、打好标签很值得。
如果你愿意，可以把每条需求转成规划系统里的工单——例如 Atlassian Jira 里的 Story 工单类型，每条就对应一条这种以用户为中心的需求。
也可以用电子表格，或像 Notion 这类带嵌入式数据库表格的应用，让汇编可排序、可筛选、可管理。它们也可以按原始产品愿景元素打标签。下面是一些建议标签或分栏：
- **人物画像（Persona）**：本例中，按 Sad Lisa 的支持需求与 Tinker Tia 的销售需求分栏会更聚焦。你会看到，我们后面也会基于人物画像做优先级决策。
- **北极星场景（North star scenario）**：便于查询“兑现某条场景承诺”所需的全部需求。
- **边缘情况（Edge case）**：边缘需求很重要，但不需要所有人都读透。应允许筛掉。
- **里程碑（Milestone）**：做优先级与路线图规划时会很有用。
- **状态（Status）**：这张表甚至可直接用于项目追踪。
- **备注（Commentary）**：按需补充信息。
[表 7-1](/ch7/#helpy_use_case_compendium) 展示了用例汇编。
**表 7-1.** Helpy 的用例汇编
| 需求 | 里程碑 | 人物画像 | 北极星场景 |
| --- | --- | --- | --- |
| 当 Sad Lisa 寻求技术支持时，她无需先登录就能在首页轻松找到 Helpy。 | | 任意用户 | 客户硬件问题、恶意软件 |
| Lisa 可以在不使用家庭宽带的移动设备上使用 Helpy，从而在故障中断期间获得支持。 | | 任意用户 | 全部 |
| Helpy 能高效引导 Lisa 诊断慢网问题，原因覆盖软件、硬件与故障中断。 | | Sad Lisa | 故障中断、客户硬件问题、恶意软件 |
| Lisa 会收到 Helpy 基于支持数据库学习结果推荐的最成功干预措施。 | | Sad Lisa | 故障中断、客户硬件问题、恶意软件 |
| 向 Lisa 展示满意度调查，以便我们跟踪结果。 | | 全部 | 全部 |
| 当修复结论不明确时，Helpy 能在结束聊天前建议后续跟进，让用户在需要时重新接触支持。 | | Sad Lisa | 客户硬件问题、恶意软件 |
| Helpy 可以基于满意度调查进行训练，从而随时间提升效果。 | | 全部 | 全部 |
| Helpy 能以 95% 准确率判断请求属于支持还是销售。 | | 全部 | 全部 |
| Helpy 能检测用户是否沮丧并转人工。 | | 全部 | 带账户变更诉求的愤怒用户、导致性能问题的恶意软件 |
| 人工客服在接管对话时可咨询 Helpy。 | | 全部 | 带账户变更诉求的愤怒用户 |
| … | | | |
我们已经在重排之路上大步前进，不仅需求在重排，我们的大脑也在重排。你已经能开始看到如何把系统组件挂接到这些需求上，同时又不丢失最初“为什么要做”的理由。
但在开始详细设计前，我们还得先填上那列空白的优先级。
### 为首个里程碑做需求优先级 {#id129}
当我们与团队对长期需求达成一致后，下一步目标是制定路线图。也就是说，我们需要做优先级。
优先级是我们工作中最难且影响最大的部分之一，最后常常会有点混乱。每个人都有自己的“重要性”判断，也很容易分心。看看[表 7-1](/ch7/#helpy_use_case_compendium)：这张表的规模还不到我把全部内容写全时的一半。再叠加多里程碑规划、组织约束和代码库约束，确实会令人不知所措。
更糟的是，我们通常要先完成很多事，才能拿出一个能给用户看的版本。原因是后面要讲的四条“残酷真相”告诉我们：做出真正让用户满意的东西有多难。
我们需要一套策略。
首先，我会指出在众多互相竞争的关注点里，我们真正该优化什么。
接着，我会给出场景驱动发现中常见的一种优先级策略：首个里程碑聚焦单条北极星场景。
我还会主张一次只规划一个里程碑。
最后，我会把这套策略应用到 Kabletown 案例。
#### 优先级里真正重要的是什么？ {#id130}
优先级背后最根本的两个因素是：用户影响（impact）和投入（effort）。
> [!TIP]
> 优化你的性价比（bang-for-the-buck）：按用户影响（bang）与公司总体投入（buck）的组合来给场景与功能排优先级。
这听起来简单到几乎不值一提，但说起来容易做起来难。实践中，保持聚焦像走迷宫。其他优先级会不断渗入：处理人际冲突与组织问题、维护面子、兑现对特定客户的承诺、不同岗位激励不一致，等等。所谓真正的“狠”，就是持续盯住“单位投入换来的用户价值”。
而“bang”和“buck”本身也不易衡量。
我认识的大多数工程师往往对 buck 或 bang 其中一项过度敏感。夸张地说，有的人偏向更快交付、少写代码、保持代码库简单可维护，即使这会让用户更难用或拉低采用；另一些人追求完美产品，愿意为此在底层付出任何代价。真正的智慧在于平衡二者。
下面我会先分别看用户影响与投入，再把它们合并。
##### 优化 buck（投入） {#id131}
尽管我很想做个纯粹主义者，说“唯一重要的是用户影响”，但投入水平同样重要。如果你的团队花了一千小时只给人类节省五百小时，你大概率并没有让世界变得更好。
工程师作为人类，通常对投入很敏感，所以我不用说太多。但有两点我想强调。
第一，如果它能建立相对竞品的优势，或能让用户眼前一亮，有时值得投入比“严格必要”更多的成本。比如你已有相当规模用户群，花一点时间为他们整体节省大量时间，通常是划算的。
第二，考虑总体成本，而不只是工程成本。而且这个原则是双向的。
工程师（尤其初级工程师）估算实现成本时，常只看 happy path（理想路径）上生产代码的规模。但防御性处理边缘情况呢？场景测试呢？以及文档、内部试用（dogfooding）、部署、A/B 测试、营销这些非编码工作呢？即使你无法精确估算，也应把它们纳入权衡。
一方面，考虑总体成本有助于避免范围蔓延。如果你心里冒出“这个加起来很简单”，不妨听听你身边那位友好 PM 的看法。他可能会告诉你，公司为了把它推出去并让用户看到，背后还有多少工作。
另一方面，也要想想如果你*不做*，总体成本会怎样。比如你决定不给 Helpy 增加程序化护栏来避免它说出不该说的话，就可能把压力转嫁给用户支持、公关和法务团队，让他们准备 Helpy 失控时的应对策略。
##### 优化 bang（影响） {#id132}
如果你想数学化一点，用户影响等于覆盖规模（reach）与单用户价值（value per user）的乘积，再乘上你选定时间窗。
> [!NOTE]
> User Impact = User Value × Scale × Time
用户影响可以用*效用函数*（utility function）估算：它描述“产品包含哪些功能”与“用户获得多少价值”之间的关系。随着产品变好，效用函数应上升。
但典型效用函数的数学形态非常残酷，这意味着你必须先做很多事，才会产生显著影响。
关于为用户构建有价值产品的难度，有四条严酷教训，也就是“四条残酷真相”：
1. 规模很难。
2. 用户价值是后置兑现的。
3. 竞争差异化的后置性更强。
4. 价值的长期维持很难。
###### 规模很难 {#id299}
做出高 Impact、高 Scale 的产品很难。做出一个对少数人深度有用的东西并不难；但要打动大量用户，就得同时做到可发现、有用、易用、营销到位、可规模化稳定运行等等。反过来，你可以轻松改首页字体，这种改动覆盖广，但价值不高。
###### 用户价值是后置兑现的 {#id300}
产品不断加功能时，效用函数并非线性增长。很多产品在功能到达临界质量前几乎没用。自行车得同时有两个轮子、刹车、可转向车把和上坡换挡，才真正有用。
[图 7-4](/ch7/#bicycle_utility_function) 展示了自行车的效用函数：
**图 7-4.** 随功能增加而变化的自行车效用函数
这种“前期平坦、后期陡升”的模式是效用函数的典型特征。最初一些功能可能只是“打勾项（checkbox features）”，不必做得惊艳，但必须存在，否则多数用户根本用不了。除非你想冒生命危险，否则你需要刹车。除非你专门练独轮平衡，否则你需要第二个轮子。除非你在骑场地赛，否则你会希望能换挡。
###### 竞争差异化的后置性更强 {#id133}
第三条真相是：竞争会施加额外压力。除非你在发明全新品类，否则进入一个市场时，通常要先攒到某个功能临界值，别人才会认真看你。然后你还得再提供额外优势，比如新功能或更低成本。有时你甚至是在重写自己的产品，与过去版本竞争。
我把它叫做*替代产品之上价值*（Value over Replacement Product, VORP）[^id878]。计算 VORP 时，需要把市场上已有产品，或你正在构建产品的旧版本价值，从你的效用函数里扣掉。自行车案例的曲线大致如[图 7-5](/ch7/#bicycle_vorp)。
如你所见，VORP 转正晚于简单用户价值。这要求我们做的不只是“有用”产品，而是“特别”的产品。对于 Helpy 而言，我们不仅在和现有自动化系统竞争，也在和真人客服竞争——这确实挑战很高。再往后，随着 AI 技术成熟，市场对助手表现的预期也会持续提高。
**图 7-5.** 随功能增加而变化的自行车“相对替代产品价值”函数
###### 长期维持价值很难 {#id134}
第四条也是最后一条残酷真相与时间维度有关。持续提供长期用户价值，比获得短期胜利更难。做一辆便宜但容易坏的自行车，或一辆不够舒适、难以让用户持续使用的车，都比做一辆用户愿意骑很多年的车容易。同理，Helpy 若想持续有帮助，就必须持续摄入更新的支持数据，并被持续监控性能退化。
由于这四条残酷真相，大多数产品和功能之所以无法产生巨大影响，是因为“烤得不够熟”——要么缺了关键功能，要么没按可规模、可长期维护的标准工程化。
残酷真相提醒我们不要“工程投入不足”，那“过度工程化”呢？同样要避免：过度打磨、一次追太多目标或选错目标、入场太慢、资金耗尽、或让自己长期缺乏用户反馈。
正如我在[第 6 章](/ch6/#ch06_target_aud)提到的，我们可以找到被现有方案服务不足的目标受众，他们会为了“真正为自己而做”的东西容忍功能缺失。
另一条常见的更优做法是迭代产品，正如[第 5 章](/ch5/#ch05_user_feedback)所讲。迭代时，我们会暂时忽略一两条残酷真相，但沿途仍在学习。
沿着这个思路，我们来讨论首个里程碑优先级。
##### 合并 bang 与 buck {#id135}
许多团队会从*最小可行产品*（MVP）开始。我将 MVP 定义为：效用函数明显转正的那个点，即便它可能只服务一个较小目标受众——先暂时忽略残酷真相 #1（规模）。
你也许听过*最小可爱产品*（MLP）这个词。它越来越流行，是对 MVP 常常“太糙”的一种反思。
在竞争环境里，把 MLP 理解为 VORP 明显转正的点会更有帮助。MLP 与 VORP 绑定，因为人们通常只会爱上并依赖高 VORP 产品。只有打勾项功能的自行车，除非那是你的第一辆，否则你不会爱上它。
用残酷真相来讲，MVP 聚焦 #2（用户价值），MLP 则对应 #3（差异化价值）。
下面我会展示如何用场景驱动发现来定位 MVP 或 MLP。
#### 为首个里程碑定义目标北极星场景 {#id136}
在使用 SDD 时，你可以通过优先排序“某一条北极星场景”或“最小必需场景集合”的需求，来定义你的最小可行/最小可爱产品。
聚焦北极星场景有不少好处：
- 因为北极星是完整故事，我们会交付正向效用。
- 因为它包含最佳产品愿景，我们会为某些人交付正向 VORP。
- 因为它只聚焦一个人物画像和一条故事，我们可以先去掉额外功能，把泛化推迟到后续。
我们还可以进一步收窄早期目标受众。最常见做法是限制为可参与内部试用（dogfooding）的员工（[第 4 章](/ch4/#ch04_dogfooding)），或愿意容忍早期版本以换取产品影响力/白手套支持的设计伙伴。另一个选择是限定单平台用户，比如 Android 而非 iOS，或者限定不太需要引导的高级用户。
在这些限制下，我们一开始甚至可以省略北极星场景的部分片段。比如目标是公司员工时，若故事里有“用户如何发现该功能”的步骤，我们可以先用发邮件请同事试用来替代。
最后，我们准备好给单条需求做优先级了。
#### 对用例汇编做优先级 {#id137}
我们进入一场大型会议讨论优先级。也许技术负责人或 PM 已先给出一些初始草案。
好在我们已经按场景与人物画像给表格打了标签，判断哪些该进、哪些该出会相对直接。
按我的经验，只聚焦首个里程碑会高效得多。为了争论“某个不在 MLP 里的条目是 P2 还是 P3”而陷入细节，往往是一小时的纯浪费。
这里有个简单格式：
- **P0**：MVP 必须项。没有它就无法发布或获得用户反馈。
- **P1**：MLP 必须项。它们是极具吸引力的冲刺目标，通常在临近发版时执行。如果进度滑坡且又必须按时结束，你会不开心，但仍能发布一个可行版本。
- **空白**：其他全部。规划下一里程碑时再排。
如果你们按里程碑推进，这里有个便于复用优先级汇编的方案：
- **0**：纳入里程碑 0。
- **0.5**：里程碑 0 的冲刺目标。
其余保持空白。等规划下一里程碑时，再分别加 1 和 1.5，对应里程碑 1。
这里我采用里程碑格式，因为它鼓励我们把产品路线图持续维护在一份易于查找的文档里。
我们的大多数员工家里都用 Kabletown，所以首个里程碑先限制在 Kabletown 员工，他们更宽容，也会给出更有质量的反馈（[第 4 章](/ch4/#ch04_dogfooding)）。这样我们可以先发布 Helpy 并从中学习，再去做完整打磨。面向员工的首发因此是 MVP，而非 MLP。
该选哪条场景？这里有几个考虑：
- 我们应把 MVP 限制在“支持场景”或“销售场景”之一，这样能省掉给 AI 供训练数据以及为另一个方向做测试的大量工作。
- 若选常见或高影响场景，效用函数的跃升会更高。假设现有交互里多数来自技术支持，尤其是用户认为网络不通或变慢。
- 假设数据还显示，大多数技术支持流量来自桌面和笔记本，而非移动设备。（我并不知道现实中是否如此，但先这么设定。）
“客户硬件问题”场景符合以上条件。这是一个覆盖面较完整的支持问题，足以充分检验我们助手的 AI 能力，也能验证方向对不对。
因此我们更窄的目标人物画像是：“Sad Lisa，Kabletown 员工，拥有 PC。”这样的人不算多，但我们希望她会喜欢 Helpy 并提供高质量反馈。
不巧的是，Kabletown 正在做网站框架重构，这意味着若先做 PC，我们可能要多投入约一周工程时间。那要不要改做移动端？
从总体成本看，对 Kabletown 这种流程繁复的大公司来说，多一周工程可能不是大事。这仍只是发布总成本中的一小部分。
如果 PC 和移动端使用量大致相当，当然可以优先移动端。但若 80% 支持交互都来自 PC，恐怕还是应该接受多这一周工程工作。
我们每一步都聚焦价值。我们不希望假设自己一定能跑完整张路线图——Kabletown 的管理层很容易被其他事分散注意力，如果在交付高价值成果前团队就被抽走，那会非常糟。
[表 7-2](/ch7/#helpy_prioritized_use_case_compendium) 展示了按优先级排序后的用例汇编，以及我为何做出某些看起来反直觉优先级的脚注说明：
| 需求 | 里程碑 | 人物画像 | 北极星场景 |
| --- | --- | --- | --- |
| Helpy 能高效引导 Lisa 诊断慢网问题，原因覆盖软件、硬件与故障中断。 | 0 | Sad Lisa | 故障中断、客户硬件问题、恶意软件 |
| Lisa 会收到 Helpy 基于支持数据库学习结果推荐的最成功干预措施。 | 0 | Sad Lisa | 故障中断、客户硬件问题、恶意软件 |
| Helpy 可以发送满意度调查，这样我们就能跟踪结果。 | 0[^id888] | 全部 | 全部 |
| 当 Sad Lisa 寻求技术支持时，她无需先登录就能在首页轻松找到 Helpy。 | 0[^id889] | 任意用户 | 客户硬件问题、恶意软件 |
| 当修复结论不明确时，Helpy 能在结束聊天前建议后续跟进，让用户在需要时重新接触支持。 | 0.5 | Sad Lisa | 客户硬件问题、恶意软件 |
| Sad Lisa 可以在不使用家庭宽带的移动设备上使用 Helpy，以便在故障中断期间获得支持。 | | 任意用户 | 全部 |
| Helpy 可以基于满意度调查进行训练，从而随时间提升效果。 | | 全部 | 全部 |
| Helpy 能以 95% 准确率判断请求属于支持还是销售。 | [^id890] | 全部 | 全部 |
| Helpy 能检测用户是否沮丧并转人工。 | [^id891] | 全部 | 带账户变更诉求的愤怒用户、导致性能问题的恶意软件 |
| 人工客服在接管对话时可咨询 Helpy。 | [^id892] | 全部 | 带账户变更诉求的愤怒用户 |
| … | | | |
{#helpy_prioritized_use_case_compendium num="7-2" caption="Helpy 的优先级用例汇编"}
现在看看我们的北极星场景是否经受住了优先级筛选。下面我会划掉任何被降级或改成冲刺目标的部分：
- **客户硬件问题**：Sad Lisa 的网络很慢，她认为是 Kabletown 的责任。她在 kabletown.com 看到了 Helpy 的“获取支持”按钮并点击。Helpy 询问她的设备环境，识别到她在无线网络下使用 PC 笔记本。它判断没有区域故障后，引导她执行一系列诊断与建议，从历史最成功方案开始，包括重置无线路由器、运行 Windows 网络诊断等。重置 Kabletown 提供的无线路由器后问题解决。Helpy 告知她若问题持续可再次联系（例如路由器硬件故障），随后发起满意度调查，她给出了高评分。
还不错！改动都很小，调整后的故事依旧有说服力。
当我们结束发现、进入设计阶段前还有最后一步：写出详细用户流程。
### 为首个里程碑构建详细用户流程 {#id138}
我们前面讲的故事都比较高层，省略了大量细节，以至于可能漏掉关键问题。
我们也刻意确保故事更多在描述“做什么”而非“怎么做”。现在我们仍需要对不同方案做推演，看用户如何完成这些故事。比如 Helpy 可以替用户运行 Windows 诊断，也可以只告诉用户怎么做；它可以在对话里内联提问做调查，也可以给独立调查表链接，等等。
现在我们来细化*用户流程*。
> [!NOTE]
> 用户流程会详细展示：用户为完成某条需求所经历的步骤序列，以及让该场景成立所需的前置条件。
本节我会演示如何创建用户流程，然后如何和用户做验证。
在做这件事时，我们会从发现逐步进入定义：一方面仍在这些练习中学习新需求，另一方面也开始定义产品本身。
在做 UI 设计时你可能听过用户流程，通常也叫“分镜图（storyboards）”。它可以是一组 UI 原型图，模拟用户点击过程。
如果我们的界面不是图形 UI 而是代码，那流程就会是代码清单与命令行的组合，中间穿插说明文字。
下面是一些关于编写流程的高层建议：
- 用户流程应足够细，以便我们围绕关键交互问题展开讨论（[第 8 章](/ch8/#ch08_interaction_design)），并从中提炼清晰系统规格（[第 9 章](/ch9/#ch09_product_architecture)）。
- 与选择北极星时一样，要比较不同方案。可以头脑风暴，也可以给出多个用户流程备选，让团队帮助你做选择。这是引入多元观点、并让大家知道你并未绑定单一路径的好方法。
- 把主要精力放在首个里程碑，以及那些虽未优先但你认为必须尽早搞懂、才能形成整体设计的事项。
- 和任何场景一样，用户流程应讲完整故事：从用户动机与其如何发现功能讲起。
我们来为 Kabletown 的一条需求写流程，即：“Helpy 可以从支持数据库学习最常见干预措施，并推荐给 Lisa。”
我们最初训练 Helpy 的效果并不理想。遗憾的是，遗留系统里我们从未给支持数据库做过标注，因此根本不知道技术支持问题中最常见有效修复是什么。最可能的办法是：回看成千上万条历史支持请求，并按“有效干预措施”或“结论不明确”进行分类。我们还希望标注支持人员当时的推理过程，让他们的经验能教会 Helpy。
下面是一个新人物画像 Support Rep Sam（支持代表 Sam）的用户流程。我们要努力让他愿意做大量标注：
1. Support Rep Sam 收到老板邮件，要求他在下个月内给自己过往 50 条客户聊天做标注。
2. 他很忙，但老板提了，于是打开内部工具。工具先带他进入一条旧支持线程，让他回看并回忆当时是如何修好的。
3. 他看到一个标签下拉菜单，如“重置路由器”“扫描恶意软件”“重启机器”等。若没有匹配标签，他也可新增，之后其他支持同事也能看到该标签并使用。
4. Sam 还需要补充说明为何选择这组建议顺序。他输入：“我先重启路由器，因为用户有两台设备都离线，看起来不像是单设备问题。”
5. 他提交后，系统将他带到下一条聊天线程。
6. Sam 在回家前处理了十几条。几天后，他又收到催办邮件提醒继续标注，点开链接后又完成了几条。
我们也可以写一版 AI 辅助流程：
1. AI 扫描一千条聊天，提取它认为每条里的修复措施与推理过程。
2. Sam 收到老板邮件，要求他核对 AI 对其过往 50 条聊天的解读。
3. Sam 打开某条聊天后，系统直接问“AI 的判断是否正确”。他可以点击 *Yes*，或直接在行内修改 AI 的结论与理由。
4. 他提交后，系统带他进入下一条聊天。
5. 与此同时，新选择会反馈给 AI。第二天夜里，AI 会基于这些反馈重训。
6. Sam 发现 AI 有四分之三时间是对的，因此他在半小时里轻松处理了 30 条。
我们会与团队讨论并确定方案。对方案有信心后，我们可以交付配套分镜图。也可以把这些流程拿给几位支持人员看，做个临时可用性研究：“你会愿意这样用吗？你还希望有什么功能？”
用户流程画出并验证后，发现阶段就告一段落，至少在我们学到新遗漏之前如此。
#### 验证用户流程 {#id218}
对于关键界面，你会希望和真实用户做验证，确认其可发现、直观，并覆盖了最重要用户需求。
我会讲两种实践：征求意见稿（RFC）与可用性研究。
##### 征求意见稿（RFC） {#id139}
如果你的主要目标是确认功能在真实世界里做对了事，可以创建一份 RFC 文档，给潜在用户看分镜图，问这个场景是否有用，并请他们对设计提出反馈。
考虑到我们在设计的是一个服务少量员工的短期内部工具，这大概就是我们会采取的方式。我们会把 RFC 发给几位支持坐席，让他们指出功能缺口、标出困惑点、补充我们可能漏掉的日常流程细节。早期咨询这些支持员工，也有助于我们提前评估：他们会不会对新增工作产生抵触。
但 RFC 的局限是：我们其实已经把“答案”给他们看了。如果不先给答案，我们往往能得到更多洞察。
##### 可用性研究 {#id140}
*可用性研究*会让受访者基于可运行原型完成任务，从而暴露大量问题，如可发现性、易用性和功能缺口。
你可以安排几场访谈，通常通过视频进行，并准备一系列希望受访者完成的任务。
你的可运行原型应当看起来能完成这些任务目标，同时允许其他功能仍未实现。很多设计工具都能制作这种原型，甚至有些工具可基于现有应用或其截图，快速生成带新功能原型的改版。
访谈开始时：
- 先让受访者放松，并说明流程。
- 请他们在使用功能原型时“边操作边说出想法”。
- 告诉他们可以提问，但你可能不会立刻回答。
然后你给出任务，也就是关键用户流程中的“动机”部分。这里你可能会说：“你被要求给一条历史支持线程标注问题类型和有效修复措施。请共享屏幕，并用这个可点击原型尝试完成任务。”
除了呈现用例外，尽量不要给额外引导。如果确实需要回答问题，把问题记下来，后续用于调试流程。
我非常建议你抓住机会参与一次可用性研究。我第一次做这件事，是给我在微软写的一个 C# API 做研究，那次经历非常令人谦卑。看着程序员在我以为“很好用”的地方频频受阻，让我真正意识到 API 设计这门学问有多深、多难。
### 把用户流程翻译成待完成工作 {#id141}
我们大重排的最后一步，是写出需要构建的组件与功能。这些有时称为*待完成工作*（jobs to be done）。
用户流程可以被翻译成待完成工作，方式与北极星场景拆解成需求类似。
例如，如果我们决定让 Sam 手工标注他所有历史支持聊天，可能要构建以下组件：
- 用于标注聊天的内部工具
- 一张可编辑的标签数据库表
- 一张用于存储“标签 + 自由文本”标注结果的数据库表
- 让 Helpy 联合摄入“聊天历史 + 标注结果”的数据流水线
- 按员工追踪其是否完成 50 条标注目标的进度系统
到这里，大重排完成！我们已成功把“以用户/时间线为中心”的产品视图，转换为“以系统/图结构为中心”的视图，至少在高层层面如此。
在[第四部分](/part-iv/#part4)中，我们会把注意力转向这些组件与系统的设计。
### 反哺需求文档 {#id219}
任何人都不该期待一条从发现到设计、单向流动的优雅瀑布。现实更像潮池，潮涨潮落，不同水体彼此混合。即便在为某些方案做设计，我们仍可能偶尔要补新的场景。
也就是说，北极星场景列表和用例汇编都应该是“活文档”，需要持续更新。
比如我们准备在技术支持能力之上，再给 Helpy 增加销售场景。这会拉伸它的能力边界，因为我们要给它更多知识并开放新工具。
我们的某条需求是：
- Helpy 能以 95% 准确率判断请求属于支持还是销售。
但我们真的想透了吗？
2025 年代理设计中的一个现实是：对于复杂代理，采用“多个专长代理混合”通常比“一个全能大代理”错误更少。在本例里，我们可以做一个技术支持 assistant 和一个销售 assistant，再由 Helpy 作为礼宾代理（concierge agent）负责对外沟通、规划，并把任务分派给各 assistant，如[图 7-6](/ch7/#mixture_of_agents)所示。
**图 7-6.** 两个专长助手与一个代理的混合模式
现在我们要批判性审视这个设计，并构造可能击穿它的故事。比如用户提出一个技术支持问题，而真正解决方案是升级设备。此时 Helpy 在一次会话里可能不该只委派给一个 assistant，而是需要同时咨询两边。
如果我们前期没意识到这一点，现在就是补写新用户故事并让它重新走一遍大重排的时候。
### 本章小结 {#id142}
我们已经把“以场景表达的产品愿景”推进到了“接近传统实现需求”的形态。在场景驱动发现的指导下，我们对成功更有把握：
- 因为所有人都能读故事，沟通质量更高。
- 因为我们聚焦北极星场景要素，不会浪费时间。
- 借助人物画像和北极星场景，我们既保留长期愿景，又只执行一个增量里程碑。这让我们在更整体策略下保持聚焦优先级，知道自己正朝着一致目标构建。
- 我们依据成本与用户价值来选最高优先级，并清楚四条残酷真相——Helpy 需要在多个维度都足够强，才能给终端用户真正交付价值。
- 上线后，我们预计用户反馈不必触发大改版，因为团队在北极星场景与用户流程中主动找了情节漏洞，并通过 RFC 与可用性研究验证了用户流程。
- 当进入设计与实现，我们会在编写场景测试时回看用例汇编与用户流程，并把北极星场景做成演示。
如果你还没尝试过，我希望你试试 SDD。上手后，写故事会很有趣，尤其是团队一起写。而且它可能带来十倍回报：你会用更少尝试交付出正确的产品。
### 练习 {#id220}
1. 在 2010 年代到 2020 年代初，Visual Studio Code 通过优秀的扩展发现机制赢得了数百万开发者的心，例如 lint、语法高亮和测试框架扩展。请为这个主题写一条北极星场景，真正把“扩展发现”卖出去。如果你不熟悉 VS Code，可想象一个 IDE，提供“扩展市场（extensions marketplace）”以帮助你找到合适工具。
2. 把你的场景——或者如果你想对比答案，也可以用我在上一题给的场景——拆成高层产品需求。尽量不要对具体设计元素规定过多，以便后续写用户流程时有更大灵活性。
3. 指出几个边缘情况，补充到上述需求中，它们可能没有被北极星场景直接覆盖。同样，尽量保持高层表述。
4. 写一个用户流程，满足“发现高口碑扩展”的产品需求。
### 参考答案 {#id143}
1. 开发者 Deanna 打开某个 Python 仓库的 Visual Studio Code。她刚接触这个仓库，Python 经验也不多。好消息是，仓库维护者提交过一个代码格式化器推荐，所以她会收到一个弹窗建议安装。与此同时，由于源码主要是 Python 文件，系统向她推荐 Python 语言服务器和调试器扩展——这些扩展下载量高、星级高，她安装后立刻进入正确轨道。最后，她去扩展市场“逛店”，并配置了一个口碑不错的 AI 编码助手。
2. 用户可以编写并提交一份推荐语言扩展列表，帮助队友在 clone 仓库后快速进入状态。
应有一个扩展库或商店，按流行度与评分排序，帮助新接触某语言或仓库的用户找到最有效选项。
应主动向用户展示推荐扩展，让新用户即使此前不了解扩展也能快速上手。
用户可以按描述、关键词和名称搜索扩展市场，从而既能找自己偏好，也能发现尚未高排名的新扩展，例如新型编码助手。
3. 当队友更新推荐时，用户应主动看到新推荐提醒。
用户可以拒绝安装某些扩展，VS Code 应记住其偏好，避免重复提示已拒绝扩展。
用户可以配置“按仓库”扩展或“全局”扩展，以适配不同仓库可能存在的代码格式规范差异。
4. 开发者 Deanna 打开一个新仓库。VS Code 识别到这是她第一次接触该仓库，于是弹窗提示她查看扩展。她可以点 X 关闭，或点“前往扩展市场”。她点击按钮后，看到一组推荐扩展：按仓库语言适配过滤，并按流行度与评分综合排序。每个扩展都展示名称、简述、下载量、星级，以及两个按钮：*install* 与 *learn more*。她点击 *Install* 后，会弹出一个页面，展示作者提供的使用说明，并显示该扩展下载进度。
[^id878]: 该术语改编自棒球统计学（sabermetrics），其中 P 代表“Player”而非“Product”，指的是一名大联盟球员相较于最强替补小联盟球员所带来的价值。
[^id888]: 短期看它对用户不算关键，但在路线图早期，用户反馈是我们的生命线。
[^id889]: 在现有产品里这项能力藏在登录后，我们希望把它前置以促进早期内部试用，因为人们并不是每天都需要支持。并且在网速很慢时登录本身可能很痛苦。
[^id890]: 对 M1 而言，Helpy 可以先直接询问用户请求类型；若是销售，就转到旧机器人 + 人工体系。
[^id891]: 员工内部试用者会更宽容。
[^id892]: 这对规模化下的生产力与质量很重要，但对受限测试不是刚需。