第 7 章 从业务诉求到产品定义

业务方对智能体的诉求，从来不会以产品的形态说出口，说的是“帮我看看上周损耗怎么高了”。从这句话到一个能开发、能验收的产品，中间隔着四层理解，任务是什么、拆成哪些能力、每个环节谁说了算、做成什么样算好。常见的失败方式是拿传统功能清单直接应对，照单开发出来的东西是一套带对话框的报表系统，能查、能筛、能导出，就是不替人干活。

本章用四件工具对应这四层理解。7.1 的任务故事把诉求写成岗位说明，7.2 的能力清单把一句话诉求摊成各归各档的能力，7.3 的决策点表逐环节确定谁说了算，7.4 把“做得好”定成裁判、判据、算法俱全的验收标准。7.5 拿案例线把四件工具拼成一页产品定义，7.6、7.7 给出从概念到 demo 的最小验证路径。本章是第二部分的起点，后面四章的形态、分工、信任、评测，都以这一页定义为输入。

7.1 需求挖掘的智能体语境

智能体语境下的需求挖掘，产出物从功能清单换成任务故事（task story），一句话写清谁、在什么处境下、要完成什么任务、做成什么样算成功。换载体的原因是交付物变了。传统调研产出功能清单，报表导出、日期筛选、门店切换、异常标红，一条条列清楚，研发照单开发，测试照单验收，这套办法的预设是产品给人用、人是操作者，清单上每一项都等人来操作；智能体交付的是一个能自行完成任务的行为者，功能清单开给它，等于只交代了有哪些操作，它需要的是岗位说明，任务是什么、干成什么样算完成。照功能清单开发出来的智能体产品，多半长成一套带对话框的报表系统。

四件要素里最值钱的是成功长什么样。业务方描述任务时往往说不清过程，但对“干成了是什么样子”有清楚的画像，这幅画像就是日后验收标准的来源，7.4 回来收它。案例线的两条任务故事可以这样写。运营小周的一条是，每周一早上交出上周经营周报，归因说清三家店销售为什么变动，成功的样子是数字与后台一致、每条结论有出处、改动不大就署名发出。店长老陈的一条是，周一打烊后对完三张报表，想知道损耗为什么比平时高，成功的样子是当天就拿到一个能向店员交代的说法，不把疑问留到第二天。两条故事念给本人听，对方认可，需求挖掘就算到位。

挖到这个深度，访谈的问法要换。业务方上门说的常常是方案，例如“我要一个预警功能”，任务藏在方案背后，往下追三问，“这个功能拿它干什么”“上一次遇到这事是什么时候、当时怎么处理的”“做完了交给谁”。三问问完，“预警功能”多半现出原形，可能是“损耗超标当天就得知道”，也可能是“老板问起来答不上话”，两个真需求长出的产品完全不同。

访谈之外有两个渠道更实在。一是跟班，坐在老陈旁边看他打烊后怎么把三个后台切来切去，一次跟班比十次访谈看得多。二是看存量产物，小周过去半年发的二十六份周报存档就是现成的需求文档，周报的栏目结构是管理层认可的样式，归因的深浅有历史记录做参照，哪些周写得费劲也能从发出时间上看出来。第 4 章过筛时留下的证据句，谁在为这件事花钱、产出谁用、错误谁先看见，在这里直接拼进任务故事。

接手的不只是新需求，还有一整个陌生行业时，需求挖掘前要加一道工序，快速懂一个行业，方法可以用点线面三个字记。点是一个个具体的任务和产物，三张报表、一份周报、一次订货、一场促销，先收上二三十个来，访谈和跟班收的正是这些点。线是任务连成的流程，从打烊对数，到损耗确认，到周报归因，到月度复盘，把点串成三四条主流程，串的过程中会发现哪个点卡在两条线中间，那种点往往就是产品的机会。面是行业的结构与约束，谁付钱给谁，利润压在哪几个环节，一年里什么季节是旺季什么季节是空档，监管和合规卡在什么地方。茶饮这一行，时段落差和季节落差决定排班和损耗的节奏，直营还是加盟决定数据能不能拿到手上，这两条约束不懂，定义必然外行。从点进，沿线走，到面收，跟一家店干一周、读完一个月的存量材料，就能到跟业务方对话的水平；检验标准是能用对方的词把一条流程讲一遍而对方不纠正。行业深处的门道交给回路里天天在场的人，产品经理要的是定义不外行，不是转行。

7.2 场景抽象与能力定义

从一句话诉求得到能力清单，方法是先把任务全程摊开，按每段做法说不说得清切成几段，各归各档，写得清的写死，说不清的交给模型，不该做的写明不做。摊开的依据是工时和操作，不是字面诉求。小周的原话是“我想快一点出周报”，字面上是速度诉求，照字面做，产品方向多半做成导出更快一点；按工时口径，他每周归因全程约一个半工作日，拉数对数占掉大半天，写稿改稿到晚八九点，这句话底下压着一整条活，拆开是四段。

段	内容	特征	归属
取数	把三个后台的上周数据拉齐、对上	字段固定、口径固定、步骤固定，操作手册写得出来	流程自动化，不必用模型
指标	环比、同比、结构占比，按公司口径算清	口径是公司的资产，写死可审计	写死的计算
归因	查明销售为什么变动	步骤事先说不清，跨销售、损耗、促销三处数据查证，查了才知道下一步查什么，任务画像三笔全中（步骤说不清、要查证、错了可发现）	智能体
建议	从“为什么变动”走到“下周要不要调整”	判断题，答案在数据里没有事实锚点	第一版不做

建议这一段第一版不做，理由有三个。判断题的对错验收不了；管理层这一环只是被动收结果，回路里没有人能为一条错误建议把关；店长一旦照错误建议调整订货，责任链说不清。这段留到产品立住、回路磨合好之后再议，不做的理由记进定义文档，免得日后翻旧账。四段拆完，“出周报”这个任务就变成四条能力，每条各归各档，第 4 章的分层判定在这里落地，取数拼表交给固定自动化，归因初稿交给智能体。

能力的写法一句话说得清，动词加对象，再加做到什么程度。“查数”两个字不算能力，“把三家门店上周的销售、损耗、排班数据拉齐，按固定口径对上，数字与后台一致”才算，后一种写法交代了三件事，接什么活，活干到什么份上，什么叫干成了。

抽象的程度有一把尺子，一条能力底下能数出至少三个真实用例，这条能力就成立；数不出三个，它其实是一条用例，写小了；底下什么都装得下的，例如“数据分析”四个字，是口号不是能力。用这把尺子量，取数底下有日取数、周取数、月取数，成立；归因底下有周报复盘、临时归因、异动追查，也成立。

拆分时还要防一个方向性错误，就是按部门或按系统切能力。切出“销售分析能力”“库存分析能力”，看起来完整，依据却是组织结构图，不是任务。取数这一条能力，从任务看是一件事，放到系统上就横跨三个后台，硬按系统切，一条活断成三段，还要再补一层拼接的活把三段接回来。能力的边界跟着任务走，不跟着系统走，这是能力清单与功能清单的又一处不同，功能清单天然对应系统的界面，能力清单对应任务本身。

能力清单和功能清单的根本不同，是功能清单写“产品有什么”，能力清单写“它接什么活、干到什么程度”。能力清单有一份下游产物，交给模型的能力到了研发手里就是工具清单，接哪几支工具、每支权限多大、切多粗，第 5 章讲工具时铺过这三层。每支工具还要配一份说明，写清名字、用途、触发条件，这份说明是写给模型看的产品文档，写得清楚，模型就用得准；查促销那支工具的说明里没写日期口径，查回来的数就可能差着一周，归因从第一步就歪了。

7.3 决策点建构

决策点表把第 3 章那条判据，谁决定下一步，反过来对准自己的产品，把流程的每个环节逐行标出来，下一步是写死的规则、模型当场判断，还是人拍板。归属的判据是两问。这一步的做法说不说得清，说得清的写死，说不清的交给模型；这一步错了多贵，越贵，越往写死和人审那边放。这张表是研发搭系统的直接输入。

两种走极端各有各的损失。全部写死，产品退化成流程自动化，第 4 章的选项阶梯早有判定，这类活本不该上模型，白白背上验证和兜底的成本。全部交给模型，每一步都概率化，取数的路径每次不同、指标的算法每次微调，核对定不了基准，验证、兜底、成本三头一起涨。模型还有一种浪费的用法，是在本来没有选择的地方让它选，拉哪三张表是定死的，让它“自行决定拉什么”，除了引入不确定性，什么也换不来。健康的做法在中间，第 5 章讲编排谱系时给过那条光谱，一端是工程师事先写定的流程，另一端是模型运行时现场定，生产系统多在中间地带；定义阶段的活，就是把每个环节在这条轴上的位置标出来。

周报的流程两问过完，归属列成一张表。归属共四类，写死、规则筛、模型、人审；规则筛是写死的一种，写死的内容是筛选的阈值，表里单列一行。

环节	谁定	为什么
每天定时拉取三个后台的数据	写死	步骤固定，定时任务跑一万次一个样
指标口径计算	写死	口径可审计，写死有台账
异动识别，哪些指标超常	规则筛	阈值写得出来，先由规则筛一遍
查证方向，先查促销还是先查天气	模型	每周要查的原因不同，说不清
证据检索，翻数取证据	模型	查了才知道下一步查什么
归因结论成文	模型	开放文本，写不出手册
发出前核对	人	小周署名发出，天然是那道关口
发送动作	人先点，授权后再自动化	发出去的东西代表公司的信誉

表里每一行定的是谁说了算这一问，这一问之外还有两问要跟着记。模型定的话，判断依据给到什么程度，给三张表还是连促销记录一起给；判错了怎么办，兜底动作指向第 10 章。三问都答上，一行决策点就算完整。决策点表往大了看，就是这件产品在第 3 章那根自主度轴上的位置，第 8 章谈形态与分工、第 9 章谈信任，都要回这张表核对。

归属不是一次定死的。上线之后信任攒起来，人的环节可以逐档放权。影子期是新旧并跑的过渡带，智能体照常跑真任务，产出只记录、不生效，8.2 的 L0 影子运行就是这一档；放权怎么走、走到哪一格，第 15 章讲上线节奏时细说。定义阶段要先把第一版归属钉下来，含糊的“到时候看情况”，到了时候没有人说得清。

写死与交模型的分界，试饮报废那一周给出现成的对照。那一周损耗表上试饮报废突然抬高，写死的流程只能照固定路数走，先查促销日历，没有活动，再查天气，正常，流程到头，输出一句“未查明”。实际查到答案的路径是，促销和天气都排除之后，想到那几天吧台来了新学徒，翻交接班记录，再问店长一句，才知道试饮的流程改过，报废的口径跟着变了。这条查证的路径每次都不同，事先写不出手册，只能现场定。表里“查证方向”那一行交给模型，交的就是这种段；写死的错处不在笨，在把说不清的段当成了说得清，流程跑到头，答案还没有影。

7.4 验收标准与可验证的完成定义

验收标准把“做得好”拆成三个部件，裁判、判据、算法，第四个动作是拿偷懒执行者检验一遍，绕得过去的标准改到绕不过去。这套做法的必要性由交付物决定。传统产品的功能验收照单点，点击导出按钮，出来一份固定八列的表，点了、出了，就过了；智能体交付的是行为，行为没有按钮可点，功能是点出来的，行为是测出来的，要测试就得先有评分标准。没有标准，验收会开成印象评审会，每个人按自己心里那套“好”的标准打分，会开完分歧原样带回工位，问题留到上线后由用户发现。模糊验收是智能体项目最常见的失败原因之一，概率性的行为配上没写清的标准，等于把产品质量交给运气。

定这套标准走三步。先找裁判，定谁说了算，周报的裁判天然是小周，署名发出的人，东西代表他，他有十足的动力较真。再找判据，跟裁判一起把“好”掰开，初稿拿去能当底稿、改动不超过几处、没有事实错误，算合格，要推翻重写，不算。最后找算法，合格份数除以总份数，得出周报初稿可用率，一个能按周追踪的指标。归因方向正确率同理立起来，裁判换成小周加店长，店长守着店，归因说错方向他一眼识破；判据定为主要结论的方向对不对，不苛求每条细节全对，方向错了比细节漏了伤得多；算法是拿历史周报当测试题，每周的归因小周都写过真答案，现成的对照答案。这套做法怎么做成正式的评测计划，第 11 章展开，本章把标准立在这里。

偷懒执行者检验防的是有空子可钻的标准。检验的办法是想象一个偷懒的执行者，可能是模型，也可能是承建的团队，问一句，不解决真问题，能不能也通过这条标准。“所有测试通过”是典型，测试写松了，通过不代表问题解决；“用户满意度九成”也是，抽样抽谁、什么时候问，门道多得能绕着真问题走。这条纪律借自工程侧的规格审查，在智能体产品上分量加倍，受检验的一方自己就会找空子，模型的输出本来就是奔着通过判据去的，开发全程都在拿判据量产出、照着判据改提示词和选版本，产出自然贴着判据长，判据松一寸，产出就滑一寸。

标准立好之后分三层放。

1. 单次判据，这份初稿合格吗，给核对人用的一页清单。
2. 批量指标，可用率、正确率，给版本之间的对比，这个月比上个月好了还是差了一目了然。
3. 放行门槛，上线前可用率要达到多少、影子期跑几周算过，给放量的决策线。

本章立起前两层，第三层只立形状，数值不能拍脑袋，要用测试题算出来，第 11 章的评测计划给出算法。

三层里单次判据最具体，小周核对那道关口上用的，是一页四条的清单，数字与后台对得上，每条结论有出处，拿不准的地方有标注，口径跟现有报表一致。四条都是半分钟内能勾完的动作，核对环节的人工成本就压得下来。清单短，是因为判据挑得狠，程序能核对的不用人看，规则能写死的不靠感觉，留给人的只剩程序判不了的那几样。

最后是定义文档本身的篇幅。规格写得比改动还长，多半是把实现细节错当成了需求；定义要短，短到一页纸装得下，这是审查纪律，不是文风偏好。一份完整的产品定义有七件。

1. 目标，一句话写清。
2. 验收标准，照本节三层立。
3. 不变的边界，无论如何不许做的事。
4. 与现有系统的接口，数据从哪来、到哪去。
5. 完成定义，做到什么份上算完。
6. 前车之鉴，以前在这类事上栽过的跟头。
7. 开放问题，还悬着的，写明留给谁、什么时候关掉。

七件之外多出来的，多半该挪进设计文档或者删掉。照这七件列提纲，能直接动笔的一页定义就有了。

7.5 【案例线进一】经营分析产品的定义实战

本节把 7.1 到 7.4 的四件工具在周报归因这一单上跑完，产出是一页能直接拿进评审会的产品定义。案例线背景不变，茶饮连锁三家店，ST001 店长老陈最资深，ST002 开在成熟社区，ST003 在大学城，运营小周一个人管三家店的数据，管理层月度复盘、被动收结果；第 4 章的判定沿用，值得做，分层做，第一单选周报归因。

三条任务故事先定稿。小周那条是主线，每周一早上交出上周经营周报，归因说清三家店销售为什么变动，成功的样子是数字与后台一致、每条结论有出处、初稿改动不大就署名发出，周一傍晚前交出，不再熬到晚上八九点。老陈那条排进第二单，打烊对完三张表，损耗比平时高的时候，当天拿到一个能向店员交代的说法。管理层那条按第 4 章的判定不单独做产品，搭小周那条的便车，周报链路快了，月度复盘拿到数自然也快，临时问数的口子留给第二单的店长问答去接。第一单的范围锁在小周这条线上，怎么锁的记进定义文档，免得范围悄悄长回去。

能力清单四条，从 7.2 的拆解直接落下来。取数，把三家门店上周的销售、损耗、排班数据拉齐，按固定口径对上，数字与后台一致，交给流程自动化。指标，按公司口径算出环比、同比、结构占比，口径写死，可审计。归因初稿，对异动指标查明变动原因，每条结论注明数据出处，查不明的如实标注，交给模型。建议，第一版不做，理由照 7.2 记的三条写进开放问题。每条都过了三个用例的尺子。决策点表照 7.3 那张用到这一单上，八行原样适用，那张表本来就是照这条流程画的。

验收标准立三条，裁判、判据、算法一一配齐。第一条数字零差错，判法是核对，周报里每个数字回后台对得上，对不上一票否决，这条没有商量，数字错了归因再漂亮也是废品。第二条周报初稿可用率，裁判是小周，判据是初稿可当底稿、改动小且无事实错误，算法按周统计可用份数占比。第三条归因方向正确率，裁判是小周加店长，判据是主要结论方向正确，算法拿历史周报当测试题。三条里第一条是硬线，后两条是水平线，硬线管底线，水平线看版本长进。放行门槛的数值留空，标注“第 11 章评测后填”，数值要从测试题里算出来，不是评审会上拍出来的。

立“可用”的判据时还有一步不能省，跟裁判一起校尺。判据初稿写的是“改动不大”，多大算不大，小周手上正好有上个月几份周报的修改记录，翻出来一起回看，一份只改了两处措辞，算可用，另一份归因段落整段重写，不算。两三个案例过完，“改动不超过两三处、不动结论方向”就写成文字。裁判的尺感先校准，判据再写下来，这一步省了，上线后裁判和指标就会各说各话。

四件东西合成一页纸的产品定义，一段目标，四条能力，八行决策点，三条验收标准，外加三条范围裁剪的记录和一条开放问题。这一页纸在后面各章各有去处，研发拿能力和决策点开搭，评测拿验收标准出测试题，第 8 章拿决策点谈形态，第 10 章拿判错环节设计兜底；第 6 章六阶段里需求定义阶段的产出物就是这一页。评审会上有人问怎么证明这东西做出来是好的，答案就在纸面上，三条标准，每条都配着裁判和算法。

7.6 从概念到 demo 的最小路径

PoC 用最小的成本回答一个问题，概念成不成立，路径三步，提示词原型、低代码搭壳、真数据跑三个真实场景，每步只回答一个问题。PoC 这一步对应第 6 章周期的第二站，也兑现第 4 章粗算留下的那句话，成本与收益说不清但又不死心的场景，先花小钱做快速验证。

概念必须真跑，纸面推演不够用，原因在智能体的特性。传统产品的需求想清楚了，可行性基本就清楚，成本算得平就能排期；智能体不一样，同一件事换个说法、换种给料，产出可能天差地别，做过 AI 产品的人反复提到同一个教训，这类产品的最小可用版本最难划界，应用实际会表现成什么样、能力边界在哪里，只有跑过才知道（口径见本章参考资料）。定义写完先别急着立项排期，第一个动作是找一条便宜的路让它先跑一次。

第一步，提示词原型。打开任何一个现成的大模型对话产品，把能力清单里最核心的一条，周报归因里自然是归因，写成一段话交给它，配上一份真数据，看它交回来的东西。这一步回答的问题是，模型干得了这个活吗。成本几乎为零，花的只是写提示词和贴数据的时间，改的也只是说法和给料。三种结果各有各的用，干得好，概念有了底；干得勉强，调一调给料和说法再试，第 2 章的提示词知识在这里够用；干不了，当场知道，省下的是整个项目的钱。

第二步，低代码搭壳。对话产品里的原型是一次一次手工跑的，要演示给业务方看、要请人试，得有个壳。第 3 章品类划分里的第五类，搭建平台，就是干这个的，把数据、提示词步骤、输出页面连起来，不写代码。原型阶段用它划算，该有的组件都是现成的，模型调用、数据接入是平台备好的件；流程画在明面上，哪一步干了什么看得见；改起来快，上午的想法下午就能换成新的连法；产品经理自己就能动手，不占研发排期（口径见本章参考资料）。这一步回答的问题是，这些环节拼成一件产品，说不说得通。

第三步，拿真数据跑三个真实场景。这一步回答的问题是，换到真实的日常数据，成色还有多少。一个平常的周，数据规整、归因直白，看基本盘；一个异常的周，有明显的异动，看归因的成色；一个边缘的周，节假日或开学季，看口径在特殊时段是否仍然成立。用假数据跑 demo 等于自欺，真数据会脏、会缺、会口径打架，那些脏和缺是产品上线后天天要面对的日常，PoC 阶段碰上它们，比上线后碰上便宜得多。

三步之外有两条纪律。一条管钱，PoC 先定上限，时间论天不论周，几天内出结论，只买现成服务，不搭基础设施，不拉研发正式排期。另一条管名分，PoC 不等于最小可用产品，前者验证概念成立，产出是一个继续或不继续的决定；后者验证产品可用，产出是交给真用户的东西。把 PoC 当最小可用产品直接上线，概念刚验完就背上运营的担子，是最常见的误用方式。

最后一样东西最值钱，也最容易漏掉，就是识破 demo 效应的本事。demo 惊艳不等于产品可用，惊艳可以有三个来路，场景是挑过的，演示自然挑模型最擅长的场面；一次跑通不等于次次跑通，概率系统的单次表现没有代表性；没有真实负荷，并发、成本、脏数据都不在演示现场。识破别人的 demo 有两招，当场换一个没排练过的场景再跑一次，问一句这个演示的场景挑了多久。识破自己的 demo 用同一套，最有效的用法是拿一个已经有标准答案的场景，当众跑，跑完对答案，下一节的周末实战用的正是这一招。

7.7 【案例线进二】周报产品的周末 PoC

定义写了下来，概念还没验，负责这一单的产品经理用一个周末把 PoC 做出来，周一例会上让管理层看见东西。投入三样，两支提示词、一份门店真数据、一个低代码的壳，零代码，全程一个人。

周六上午写第一支提示词，归因这支，大意如下。

你是一家茶饮连锁的经营分析师。下面给你三家门店上周的销售日报、损耗表、排班人效表，以及上周的促销安排和天气记录。请找出销售变动的主要原因，每条结论注明依据来自哪张表的哪个数字。查不出原因的地方，如实写“未查明”，不要编。

这段话有四个机关。开头给角色，经营分析师，把口吻和视野框住，免得写成泛泛的商业评论。中间给材料，三张表加促销和天气，材料不给足，归因就只能靠编，产品给它的材料，就是它的全部已知。然后是要求，每条结论注明出处，这一句把 7.5 立的验收标准直接写进提示词，标准说每条结论要有出处，就让它在源头做到。结尾给退路，查不出就写未查明，不许编，这一句是给幻觉设的一道关口，归因场景里一条编出来的原因，比一句“未查明”有害得多。这支提示词当天在对话产品里试了几轮，改到给料的说法顺了为止，改的全是措辞和给料，没碰任何代码。

第二支是成文提示词，短得多，把归因结果按公司周报的既有栏目排成初稿，栏目顺序照小周存档里的老样子，总览、分店、异常、下周关注，不添新栏目。这支干的是排版和口吻的活，价值不在聪明，在跟存量样式一致，管理层看了两年的周报长什么样，初稿就得长什么样，形态的突兀会吃掉内容的信任，这个话题第 9 章正面讲。

下午备数据。跟小周要了一个真实历史周的三张表数据，做脱敏处理，门店和顾客的信息抹掉，数字保留。挑历史周有一个用处，那一周的周报小周写过、发过、管理层用过，归因有现成答案，demo 跑完直接对答案，不用请任何人现场评判好坏。这正是 7.4 说的拿历史周报当测试题的头一次实地使用，也是拿有标准答案的场景当众跑的那一招。

周日搭壳，在搭建平台上把三样东西连成一条线，数据文件先进，接归因提示词，归因结果再接成文提示词，最后连一个能看的输出页面，连线的活不到半天。真正花时间的是数据对齐，真数据果然脏，同一天的日期，收银后台记到秒，库存后台只记到日，两边对不上，先在表里把格式抹平再喂；损耗表还有一个品类的名字跟销售日报对不上，翻了小周的手工对照表才对齐。这些脏活正是三步路径里真数据那一步要碰的，也是 PoC 最实在的收获之一，上线前就知道数据要过哪几道筛。搭完的产出物是一个链接，点开，选周，跑，出一份周报。

周一例会，讲的顺序是先定义后演示。先把 7.5 那页纸念一遍，能力四条，决策点八行，验收标准三条，然后打开链接，当众跑那个历史周。跑出来的周报和小周当周真发的那份并排放在屏幕上，一条条对，数字对不对，归因方向偏没偏，漏了什么，多说了什么。管理层看懂的门道不在技术，在这个对法，产品好不好，当场有答案，不用信谁的一张嘴。演示结束，老板问了那个必来的问题，下周一能不能全区都用上。产品经理的回话分三层，概念验证过了，模型干得了这个活；一次跑通不算数，接下来拿一段历史周报当测试题系统地测试，测多少算过，标准纸上已经写了；测过了先影子运行，影子期里小周双份对照，智能体写的和他自己写的并排几周，对够了周数再谈放开。这三层回话本身就是 demo 效应的自防，把惊艳的一次，换成要测试的一批。

一个周末，四样产出，两支提示词，一条可演示的链路，一个跑下来对得上答案的历史周，一份写满真实脏点的数据清单。四样加上周一那场当众对答案，凑齐第 6 章说的那份 PoC 报告，干得动吗，当场跑了；差多远，一条条对了；下一步怎么走，三层话讲了。周报产品从一句话诉求，变成有定义、有测试题、有 demo 的东西。

本章小结

• 7.1 任务故事。功能清单换成岗位说明，一句话写清谁、处境、任务、成功长什么样，成功的画像就是验收标准的来源；访谈话术追三问，跟班与存量产物两个渠道；陌生行业用点线面，二三十个点、三四条主流程、行业结构与约束。
• 7.2 能力清单。一句话诉求摊成四段，取数写死、指标写死、归因交模型、建议第一版不做；能力写法是动词加对象加到位程度，一条能力底下至少三个用例；能力边界跟任务走，不跟系统走。
• 7.3 决策点表。每个环节两问，做法说不说得清、错了多贵，定成写死、规则筛、模型、人审四种归属；谁定、依据给多少、判错怎么办，三问都答上，一行就算完整；第一版归属先钉死，上线后逐档放权。
• 7.4 验收标准。裁判、判据、算法三步立标准，偷懒执行者检验做第四个动作；标准分三层，单次判据、批量指标、放行门槛；定义文档七件，一页纸装得下。
• 7.5 定义实战。三条任务故事、四条能力、八行决策点、三条验收标准合成一页定义；数字零差错是硬线；判据写下来前跟裁判校尺。
• 7.6 PoC 三步。提示词原型问模型干不干得了，低代码壳问环节拼不拼得通，真数据三场景问日常成色；PoC 定上限、不当最小可用产品；demo 惊艳有三个来路，拿有标准答案的场景当众跑是最有效的检验。
• 7.7 周末 PoC。两支提示词、真数据、低代码壳，一个周末出可演示链路；真数据的脏点清单是实际收获；例会上先定义后演示，当众对答案。

本章的结论一句话，定义的价值在可测，四件工具每件都产出后面各章直接使用的输入。第 8 章解决这页定义长成什么形态、哪些环节留给人。

试一试

拿第 4 章试一试里过了关的那个需求，做三件事。先把功能清单式的想法改写成一条任务故事，四件要齐，谁，处境，任务，成功长什么样。再拆一张能力清单，每条用“数得出三个用例”的尺子量一遍，量不过的归回用例，量得过的标出各归哪档。最后立一条验收标准，写清裁判、判据、算法，过一遍偷懒执行者检验，不解决真问题，能不能也通过这条标准。三件事做完，这份定义就可以拿去与研发讨论。讨论完不要急着排期，先照三步路径跑一个 PoC，干得了再排，干不了，省下的就是一整个项目。

参考资料

• 《Building AI-Powered Products》（Marily Nika，O'Reilly 2025）第 4 章（AI 产品经理的日常工作与需求定义工作流：把业务目标翻译成可执行策略；AI 产品的最小可用版本难以划界，无法事先知道应用实际会表现如何；从业者以周末试提示词与参数、工作日交给工程师搭可扩展架构的节奏做原型；项目启动先弄清是否真需要机器学习），见 txt/building-ai-powered-products.txt（英文原文，第 4 章行 4599-5010）
• 《Agentic AI For Dummies》（Pam Baker，Wiley 2026）第 5 章（用例规划：目标须清晰可量，把“改善客服”改写成带时限、可度量的具体口径；问题定义、目标设定、评估框架三段完整性自查；没有清晰规划，再强的系统也会沦为到处找问题的昂贵方案；界定意图须吸纳一线员工），见 txt/agentic-ai-for-dummies.txt（英文原文，第 5 章行 4129-4365）
• 《AI Applications Made Easy》（Andrea De Mauro，Manning MEAP 2025）（低代码平台适合生成式 AI 原型的理由：预置组件免写底层、流程可视化设计、调试与协作直观、原型迭代快；编程抽象层级持续走高，低代码是自然的一步；开源平台可本地部署也有托管版），见 txt/ai-applications-made-easy.txt（英文原文，行 758-835）
• 《悟道智能体开发》（本书工程姊妹卷）第 10 章（显式控制与涌现控制的编排光谱：执行路径与控制流事先写定的一端，模型运行时现场决定的另一端，生产系统多落中间地带；同一任务两种控制方式的对照；本章 7.3 的知识底本，产品向转述），工程深挖按该书对应章指引
• 《悟道智能体开发》第 19 章（规格七类内容与篇幅纪律：目标、验收标准、不变量、集成边界、完成定义、前车之鉴、开放问题；规格不应比预期改动长；可被套利的验收标准：绕开真问题也能通过的标准，执行者一定会钻空子；本章 7.4 的知识底本，产品向转述），工程深挖按该书对应章指引