划定范围与首个成果

这个阶段为了什么，又会怎样失败

上一章“需求挖掘”以一个观察到的问题收尾：真正让客户耗费时间或金钱的那件事，而它很少是客户要求的那件事。划定范围就是把这个问题变成一件你能赢下来的事。这意味着一个小到几周内能构建完的工作流程，一个说明你有没有造出来的数字，以及那些对“更好”的判断说了算的人的签字。

划定范围会朝两个方向失败，而每一个在你做选择时看上去都很合理。

安全的目标。团队选一个失败了也没人在乎的工作流程：内部常见问题解答、一个边缘流程、一个没有预算的部门。它上线了，却没人注意到。OpenAI 前线部署工程负责人 Colin Jarvis 描述了成功客户的相反模式：“他们不会去做那种偏在公司一边的边缘用例。他们选的是真正高利害的东西”（Altimeter 访谈，2025 年 11 月；T2，供应商描述自己的客户）。他的例子是摩根士丹利，其财富管理业务是该行最大的业务之一。在边缘工作流程上取得的成果，只证明模型在边缘工作流程上能用，而且没有人必须相信它。

没有共识的数字。团队选了一个真实的目标，却从未定下成功意味着什么。演示很顺利，大家都说看起来很有希望，然后“够不够好”的争论一拖就是几个月。“需求挖掘”一章讲过的 RAND 从业者访谈，把这一点放在最常见失败的根源上：干系人“误解或误传需要用 AI 解决的是什么问题”，模型最后“针对错误的指标做了优化”（RAND，2024；T1，但依据的是访谈，而不是项目结果）。在划定范围阶段，这个错误看起来人畜无害：一个按没人认可的数字调出来的模型，要到交付之后才会暴露。

这两种失败互相拉扯。高利害的目标往往很大，而大目标塞不进一个试点。划定范围就是两者兼顾的办法：保住利害，缩小面积。选发起人在意的工作流程，然后把它削到其中一片，配一个数字和一个日期。

合成案例：一条业务线，一个数字

这一段里有三点撑起了整章。目标位于核心业务之中，但被削到其中一条线。数字是二维的，并且在任何人动手构建之前就已测量。设定阈值的人，就是其团队要为错误答案买单的人。本章其余部分讲的是怎样做到这些。

高利害，小范围

“从小处着手有效”的最好证据带着一个附加条件。斯坦福数字经济实验室研究了 51 个带来了可衡量价值的企业 AI 部署，发现“73% 的实施刻意从小处起步，63% 明确把试点定位为实验”（Pereira、Graylin 和 Brynjolfsson，2026 年 4 月；T2，网上的版本标注为草稿）。附加条件就在标题里：Lessons from 51 Successful Deployments（51 个成功部署的经验）。样本里只有成功案例，所以它无法告诉你有多少失败的项目同样是从小处起步的。应该读作“成功的团队通常从小处起步”，而不是“从小处起步会让你成功”。

作者的解释比百分比更有用。他们把受控的范围称为一种“失败策略”：“小试点失败的代价低。代价低的失败不会终结职业生涯。”在他们的一个案例里，一家已经有两个技术项目失败在前的专业服务公司，因为一位发起人“接受 80% 的准确率已经足够推进”，才得以往前走。小范围让一个诚实的阈值在政治上变得可行。

MIT 的 NANDA 报告从供应商一侧指向同一方向。它的结论是，成功的初创公司“在狭窄的工作流程中取得小而可见的成果，然后扩展”（MIT NANDA，2025 年 7 月；T2）。方法限制了这一结论能走多远：报告依据的是对 52 家机构的访谈、对 153 位领导者的调查，以及对 300 多个公开项目的回顾，它自称其数字“方向上准确”，依据的是访谈而非公司的正式报告。

这些都不是在主张一个安全的范围。小而可见，不等于小而边缘。Jarvis 用 OpenAI 的欧洲半导体交付再次说明了这一点：“你得挑一个很大的问题去解决”（Altimeter 访谈，T2）。两者兼顾的办法，是顺着业务去切，而不是避开业务去切：

• 几条业务线中的一条（车险，而不是财产险）。
• 长工作流程中的一步（分拣，而不是结案理算）。
• 一个地区、一个团队或一部分流量，其余仍走旧流程。
• 只提建议，不直接执行：智能体建议，人来决定，这样风险缩小了，利害却没有缩小。

有一个办法检验你是不是切得太狠了。问发起人：如果试点达到了阈值，他们会怎么做？如果答案是“推广到整个理赔运营”，那么这个范围就是某件重要事情的一片。如果答案是耸耸肩，你选的就是边缘工作流程。

还有一条证据确定了框架。RAND 建议领导者“让每个产品团队至少用一年时间专注于解决一个具体问题。如果一个 AI 项目不值得这样长期投入，那它很可能根本不值得投入”（RAND，T1）。30 天的试点与此并不矛盾。首个成果是对一个问题长达一年的投入的开端，而不是全部。如果客户方没有人准备在这个问题上坚持一年，一个成功的试点也无处可去。

先有指标，再有构建

在写下第一行智能体代码之前，先写好成功标准。一旦有了原型，每次关于阈值的讨论都会变成关于原型的讨论，数字也会向原型已经做到的水平漂移。

Anthropic 关于定义成功标准的指南给出了一个值得原样照抄的形态（Claude 文档；T4，供应商指南）。它给出的一个良好定义的标准是：“情感分析模型应在一个包含 10,000 条多样化 Twitter 帖子的留出测试集上……达到至少 0.85 的 F1 分数……比当前基线提高 5%。”这一句话包含四个部分，而一份范围文件四个都需要：

1. 一个指标，业务方能认出来，而不只是模型团队：分派准确率、节省的分钟数、结案数。
2. 一个阈值，写成一个数字或一条没有解释余地的规则。
3. 一个留出集，阈值在它上面测量，构建者从不针对它调优。
4. 一个基线，改进从它算起（见 6.5 节）。

同一份指南还说，“大多数用例需要沿着多个成功标准进行多维度评测”。这一点对 FDE 比对产品团队更重要，因为单一的准确率数字会掩盖客户最怕的那些错误。把主指标与一个速度或成本指标配对，再加上至少一条护栏：一类绝不能发生的错误，比如合成案例中涉诉标记的案件被分到快速队列。护栏通常是客户的风险部门首先会问的东西，现在定下来，能省掉以后的一场争论。

谁来设定阈值。不是 FDE，往往也不是发起人。阈值属于那个其团队要承受错误的人：理赔总监、客服中心负责人、临床负责人。发起人签字确认这个指标重要；运营负责人签字确认这个阈值好到可以用。如果两者是同一个人，很好。如果没有人愿意为阈值负责，你就找到了那个没有负责人的工作流程，而这是换目标的理由，不是继续推进的理由。

谁拥有留出集。永远是客户。由他们的专家标注，由他们保管，供应商只在测量阈值时才看到它。这听起来很官僚，但它保护你，也保护他们。当供应商既造智能体又造测试时，通过测试只是供应商的说法。当客户拥有测试时，通过测试就是客户自己的发现，在转化会议上很难被反驳。用第 1 周的基线样本作为它的种子，这样同一批文档既衡量旧流程，也衡量新流程。

把阈值翻译成发起人的话。“F1 达到 0.85”对首席运营官毫无意义。“至少和你的资深理赔员一样准，并且当天完成首次处理”才有意义。两个版本都写进范围文件：精确的那个给评测用，朴素的那个给发起人看。如果两者有分歧，你会被追究的是朴素的那个。

本章设定阈值；评测那一章（第 9 章）会搭建测量它的评测框架，并把留出集扩充成一套评测集。本 wiki 的评测入门讲了相关术语，评测驱动的智能体开发讲了评测怎样成为构建智能体所依据的规格。

第 1 周测出基线

没有基线，就没有成果。没有测得的“之前”，好结果总能被说成旧流程本来也能做到，坏结果总能被归咎于运气不好的一周。Alpine Edge 为前线部署交付设计的四周模板把基线放在第一位：“在任何 AI 碰它之前测量基线：周期时间、返工、单任务成本”（Alpine Edge，2026 年 8 月；T4，一家咨询公司的做法）。它的四周作为一种形态值得了解：

• 第 1 周：“发现并测基线”。
• 第 2 周：“构建一个完整的工作流程”。
• 第 3 周：“加固并试运行”。
• 第 4 周：“评估生产就绪度和结果”。

同一篇文章列出了这个阶段的预警信号：“已经有了原型，但第一周结束时还没有接近生产的数据接入。”把它当作警报，而不是延误。接下来的数据接入章节（第 7 章）会讲怎么应对；对划定范围来说，要点是：在你拿不到的数据上测出的基线，算不上基线。

基线不需要数据平台。它需要一个样本、一块秒表和一位标注员：

1. 样本。从目标工作流程中抽取几百个近期案件，分散在不同的周和团队，这样一个糟糕的周一定不了数字。写下你是怎么抽的。
2. 计时。对于速度指标，使用系统已有的时间戳（收到、分派、首次处理、结案）。如果没有，就跟随做这份工作的人一天，自己计时，并在范围文件里注明你是这么做的。
3. 标注。对于准确率指标，请客户的两位专家各自独立标注同一批案件。他们意见不一的地方告诉你两件事：哪些案件确实模棱两可，以及上限在哪里。没有哪个智能体会被判定得比两位专家之间的一致程度更好。
4. 保留样本。这些标注过的案件就是留出集的第一个版本。

基线也是你对需求挖掘的第一次核查。如果测出的数字比需求挖掘中大家说的好得多或差得多，先弄清原因，再设定阈值。要么流程不是别人告诉你的那样，要么指标测的不是你以为的东西。两者在第 1 周发现都比在第 4 周发现便宜。SDLC 一书关于90 天试点的章节为工程团队提出了同样的论点：比较方式要在运行之前定好，而不是之后。

“暂不做”清单

每开一次会，范围就扩大一点。一位没参加需求挖掘的干系人问，能不能顺便处理财产险理赔。发起人的同级想给核保也弄一个。有人指出最初的方案里有聊天机器人。每个请求都合情合理，而每接受一个，首个成果就离得更远一点。

拒绝不管用，因为拒绝看起来像供应商在保护自己的利润。写下来才管用。Alpine Edge 应对范围蔓延的办法只有一句话：“在核心指标动起来之前只做一个工作流程；维护一份明确的‘暂不做’清单”（T4）。这份清单有三个作用：

• 它告诉提出请求的人：请求被听到了，而且有地方可去。
• 它把“不”变成“达到阈值之后”，让这位干系人有理由希望首个成果成功。
• 它会成为扩展计划。试点成功时，“暂不做”清单就是下一步计划的初稿。

每一项都写上原因和触发条件：“财产险理赔：文档太杂，30 天试点做不了；车险达到阈值后再议。”没有触发条件的条目，是一个你还没决定要兑现的承诺。

这份清单不是冻结的。Jarvis 描述 OpenAI 处理模糊交付的方式是“偏向快速行动，摸清所有的硬墙，然后把范围调整为我们能做的最有用的事”（Pragmatic Engineer，2025 年 8 月；T3，二手引用）。范围会在你撞上硬墙时改变，比如数据根本不存在，或者某个系统无法写入。它不会因为会上来了一位新干系人而改变。当它确实改变时，要把一页纸的范围、阈值和签字一起改，并记下哪些条目移入或移出了清单，以及原因。

雇主把这种权衡描述为这份工作的核心。他们的招聘启事是雇主要求什么的一手证据，但不是工作实际怎么做的证据（见下框）。

第一次演示

第一次演示首先是一个沟通工具，其次才是一个技术里程碑。它的任务是让范围对将来使用结果的人变得真实，而且要早到他们还来得及改。四条规则让它奏效。

用真实或脱敏的数据展示真实的工作流程，绝不用幻灯片。幻灯片要观众去想象产品；用他们自己的文档做演示，他们才能评判它。合成数据可以用来构建，但只用合成数据的演示，客户的专家从中看不到任何可信的东西，因为他们在里面看不到自己的边缘情况。如果权限还没到，就请数据所有者导出一小批脱敏数据。这比要一个副本小得多，通常也批得更快。

演示用户下一步要做什么，而不是模型能做什么。理赔员不在乎模型提取了表格上的每个字段。他们在乎的是案件已经分拣好进了自己的队列，警方报告放在最上面。在他们工作的界面里打开演示，或者在你能搭出的最接近的模拟界面里，然后走一遍他们的下一步操作。

把没做完的说出来。说出“暂不做”的条目、原型做错的案件，以及还没有对照阈值做过任何测量这一事实。Alpine Edge 列出了第二个预警信号，称之为概念验证陷阱：“演示很兴奋，基线没有”（T4）。跑在测量前面的演示，会制造出要靠数字去兑现的热情。说出缺了什么，能让阈值而不是掌声继续当标杆。

按你需要的决定挑选观众。第一次演示给阈值负责人和两三位将来使用它的人看，而不是给执行委员会看。你希望他们纠正你。给高管的演示放到后面，带着一个数字去。

“高管周五就要看演示”是第 1 周常见的压力。答应下来，但按你的条件来：真实的文档、用户的下一步，以及一份不用幻灯片的说明，讲清哪些已经测量、哪些还没有。如果到周五拿不出任何真东西，就展示基线。一个测得的“之前”，摆在高管面前比一个未经测量的“之后”更有分量。

演示之后，第一次接触真实使用也应该小。WeightWatchers 与 Sierra 合作时，计划先在“一小部分流量”上测试其客服智能体，“每次一百个左右的进线咨询”，以及“一小组用例”，然后再决定是否扩大（Sierra 客户案例；T2，供应商发布，页面没有说明结果由谁测量）。团队随后“迅速扩大了用例的范围”。页面报告该智能体“在第一周内就闭环处理了近 70% 的案件”。把它当作供应商对自己最好客户的叙述；有用的是其形态：先在一小片有边界的真实流量上跑，站稳之后才扩展。

模板：一页纸范围

只有一页，因为没有人会认真签一份更长的。它承载需求挖掘得出的观察到的问题、切分方式、数字和名字。放在客户可以编辑的地方，每当阈值或范围变化时重新签字。

ONE-PAGE SCOPE                                   version / date: ____

1. PROBLEM (observed, from discovery)
   Stated problem:   ______________________________________________
   Observed problem: ______________________________________________
   Business lever it moves: _______________________________________

2. IN SCOPE (one workflow)
   Workflow / step:  ______________________________________________
   Slice:            line of business / region / team / % traffic
   Agent authority:  propose only | act with approval | act
   Workflow owner:   ______________________________________________

3. NOT NOW (each with a reason and a trigger)
   - item: ____________  reason: ____________  revisit when: ______
   - item: ____________  reason: ____________  revisit when: ______

4. SUCCESS METRICS
   Metric        Baseline (how measured, when)   Threshold   Owner
   main:         ______________________________  _________   _____
   speed/cost:   ______________________________  _________   _____
   guardrail:    ______________________________  never       _____
   Threshold in the sponsor's words: _____________________________

5. HELD-OUT SET
   Source and size: _______________   Labelled by: ________________
   Owner (customer): ______________   Vendor tunes on it: NO

6. FIRST DEMO
   Date: ________   Audience: threshold owner + users: ____________
   Data: real / redacted (never synthetic only)

7. WEEK-BY-WEEK PLAN
   Week 1: __________________________________________________________
   Week 2: __________________________________________________________
   Week 3: __________________________________________________________
   Week 4: __________________________________________________________

8. TOP RISKS                      Earliest signal           By when
   - ____________________________  _______________________  _______
   - ____________________________  _______________________  _______

9. SIGN-OFF
   Sponsor (metric matters):        __________   date: ______
   Threshold owner (good enough):   __________   date: ______
   Vendor lead (we can build it):   __________   date: ______

下面是按合成案例填好的版本。按合成案例的规则，每个数字都是区间；真实的范围文件会写上测得的数字。

ONE-PAGE SCOPE: auto FNOL triage                 version 2 / week 2

1. PROBLEM (observed, from discovery)
   Stated problem:   "a customer chatbot"
   Observed problem: adjusters spend roughly a third to a half of
                     each day triaging incoming claim documents
   Business lever it moves: claims cycle time (the COO's KPI)

2. IN SCOPE (one workflow)
   Workflow / step:  first-notice-of-loss document triage
   Slice:            AUTO claims only, all regions
   Agent authority:  propose only (suggestion in the adjuster queue)
   Workflow owner:   claims director

3. NOT NOW (each with a reason and a trigger)
   - item: property claims   reason: documents too varied for 30 days
                             revisit when: auto meets threshold
   - item: customer chatbot  reason: not the observed problem
                             revisit when: triage is in production
   - item: write-back to claims system  reason: needs replica + review
                             revisit when: read access is stable

4. SUCCESS METRICS
   Metric        Baseline (how measured, when)   Threshold   Owner
   main:         routing accuracy; few hundred   >= senior   claims
                 week-1 claims, 2 seniors label  adjusters   director
   speed:        time to first action; system    same        claims
                 timestamps, week 1: 1-3 days    work day    director
   guardrail:    litigation-flagged claim sent   never       claims
                 to the fast queue                           director
   Threshold in the sponsor's words: "at least as accurate as my
   senior adjusters, and nobody waits a day for a first look"

5. HELD-OUT SET
   Source and size: week-1 sample      Labelled by: 2 senior adjusters
   Owner (customer): claims operations  Vendor tunes on it: NO

6. FIRST DEMO
   Date: end of week 2   Audience: claims director + 2 senior adjusters
   Data: redacted export of real auto claims

7. WEEK-BY-WEEK PLAN
   Week 1: discovery; timestamp baseline; request replica access
   Week 2: discovery sign-off; label held-out set; demo on
           redacted real claims
   Week 3: end-to-end workflow on sanitised fixtures; shadow-run on
           live auto claims once read access lands
   Week 4: measure against threshold on held-out set; readiness review

8. TOP RISKS                      Earliest signal           By when
   - replica access late          no read access            day 5
   - threshold owner disengages   misses the demo           week 2
   - model risk blocks pilot      no review date booked     week 2

9. SIGN-OFF
   Sponsor (metric matters):        COO                 date: week 2
   Threshold owner (good enough):   claims director     date: week 2
   Vendor lead (we can build it):   FDE lead            date: week 2

填好的版本里有两处容易被忽略。护栏没有基线目标，只有“never”（绝不），这是对的：有些错误不能拿来和速度做交换。还有，风险都有日期。没有最早信号的风险只是一种担心；有信号、有日期的风险，才是你能及时采取行动的东西。

失败信号

这些信号都出现得早，通常在头两周，并且每一个都指向一个解法。

进入下一阶段

当每一项都打上勾，就进入数据接入和构建：

• 指标、它的基线和它的阈值都已写下，并由发起人和阈值负责人签字。
• 留出集已经存在，由客户的专家标注，并在客户方有一位指定的负责人。
• “暂不做”清单已经商定，每一项都有原因和触发条件。
• 第一次演示已经和真实用户约好，使用真实或脱敏的数据。
• 有一份逐周计划，每个主要风险都有最早信号和日期。