客户嘴上说的和心里想要的，往往不是同一件事；调研负责把两者对齐，需求说明书负责把对齐的结果钉死成文字。这里给你一套可以直接上场的完整做法：访谈提纲怎么设计、现状怎么走查、痛点怎么记录、需求怎么拆解，最后把调研成果写成可验收的《需求规格说明书》并通过"客户"签字定稿。学完本课，你能独立完成从一次访谈到一份定稿说明书的完整闭环。
一、需求调研：FDE的第一场硬仗
调研为什么放在项目最前面？因为返工多半源自需求理解歪了。
这张图把需求失真的三种典型方式画在同一条传递链上：客户原话在"转述一概括一成文"的每一环都可能被扭曲，越往后偏得越远。看清失真发生在哪一环，调研时才能对症设防本章后面三节分别给出访谈、走查、说明书三道防线。
1.需求失真的典型方式
所谓需求失真，是指客户的真实诉求在传递过程中被扭曲，最终变成一个"做出来了但没人用"的功能的现象——它是AI项目返工的第一大来源。失真主要有三种典型方式：
愿望式表达：客户要的是"查找快"，说出来的是"给我们上一个AI"——把手段当成了目
的。
场景遗漏：客户只描述典型场景，不提边界场景（文档更新了怎么办、答案不确定怎么
办），上线后问题集中爆发。
指标含糊：“答得准一点""用起来智能一点"这类表述无法验收，双方对"完成"的理解天然不
一致。
举一个具体场景。以主线项目智能问答系统为例，看需求是怎么在转述中走样的。客户运营主管的原话是：“员工总在群里重复问同样的操作问题，我们两个人每天要回答几十遍，烦死了。“这句话经过两层转述，就可能变成需求文档里的"建设智能客服机器人，提升智能化水平"——痛点（人力被重复咨询占用）不见了，衡量标准（每天几十遍）也不见了。FDE 的本事，就是从原话出发把需求拉回真实。
这里要特别提醒一种高频错误：
- 错误做法：把客户转述过的话直接当需求写进文档。正确做法：追到原始场景和原始数据（谁、在哪儿、花多少时间、错一次代价多大），再形成需求表述。
需求失真的根源是"用转述代替现场”，FDE调研的第一纪律是回到原始场景。
2.调研三步法
三步调研法是把一次需求调研组织成"访谈前准备、访谈中倾听追问、访谈后整理确认"三个阶段的标准化方法，保证调研不靠临场发挥。三个阶段各有各的关键动作：
访谈前：查背景资料、列访谈提纲、约对访谈对象（既要约到管理者，也要约到一线使用
的人）。
访谈中：多听少说、追问细节、当场复述确认；控制节奏但不照本宣科。
访谈后：24小时内整理记录、形成痛点清单、发回客户确认，有异议当天澄清。
三类对象对应三种信息来源：管理层给目标，一线给场景，数据给证据。约访谈时对照这三类逐一核对名单，缺一类，需求画像就少一块拼图。
落实到操作上，三步法的整体流程是一个带确认回路的闭环：
三个步骤之间有反馈箭头，表示客户的异议随时会把流程拉回上一步。看图时重点记住确认回路的位置：没有客户签字确认，流程不算走完。
为智能问答系统项目做访谈前的准备清单（骨架）：
背景研究：客户所在行业、部门职能、现有咨询渠道(群、工单、电话)
提纲准备：按四类问题列好提纲 (下一节展开)
对象约定：运营主管（管理视角）+一线客服（使用视角）+IT支持(环境约束)
材料约定：请客户提前准备文档样本 (多少篇、什么格式、放哪里)
实际执行中还有两个高频问题：
- 常见问题1：只约到管理层，没约一线使用者，需求听起来合理但落不了地。?应对：访谈对象必须覆盖"出需求的人"和"天天用的人"两类角色。常见问题 2：访谈记录隔了几天才整理，细节全忘。应对：24小时内出整理稿并发回确认，过时不候。
调研的质量取决于准备和闭环，而不是临场口才；三步法把好印象变成好记录。
二、访谈提纲设计：四类问题覆盖客户全貌
有了三步法打底，访谈现场的抓手就是提纲：用四类问题问全客户全貌。
这张图给出访谈提纲的四类问题框架：业务现状、痛点定位、期望目标、约束边界——四类问题由面到点、由今到后，问全客户的完整图景。现场执行时不必逐字照念，但四类覆盖一个都不能少，漏掉哪类，说明书里就缺哪块。
1.业务现状类问题
业务现状类问题用于摸清客户"现在是怎么干活的"，它是四类问题的地基——不知道现状，就无法判断痛点的严重程度。现状类问题聚焦四个层面：
知识资产：文档存在哪、多少篇、什么格式、谁在维护、多久更新一次。
工作流程：员工遇到问题后的典型动作链（先翻文档、再问同事、还是直接问客服）。
渠道与负载：现有咨询渠道有哪些、每天多少咨询量、谁在承接。
历史尝试：之前有没有用过类似工具、为什么放弃。
落到智能问答系统项目的访谈现场，现状类问题可以这样问：
"咱们的操作规范、产品资料这些文档，现在放在哪儿？大概多少篇？都是什么格式？“
"一位新员工入职后，一般要多久才能独立回答客户咨询？卡在哪儿？＂
"咱们两个人每天大概要回答多少个重复问题？高峰期是什么时候？＂
现状类问题的价值在于拿到可量化的基线数据——没有基线，后面的改进效果就无从证明。
2.痛点场景类问题
痛点场景类问题用于定位"哪个环节最疼、疼到什么程度”，把抽象的不满落到具体场景和具体代价上。痛点类问题遵循三个追问方向：
最高频：哪类问题被问得最多？占咨询量几成？
最耗时：哪个环节最花时间？一次典型查找要多久？
代价最大：哪种出错最要命？答错一次的后果是什么？
还是智能问答系统的访谈现场，痛点类问题这样问：
“员工问得最多的前三类问题是什么？能各举一个最近的真实例子吗？“
“有没有因为回复慢或者答错，闹出过麻烦的情况？当时怎么收的场？“
您觉得这些问题里，哪些是靠一套系统能解决的，哪些是系统也解决不了的？“
最后一个问题尤其关键——客户自己会帮你划出系统的能力边界，这直接决定需求说明书的范围。
痛点要问到"场景+频率+代价"三个要素齐活，缺一个都写不进痛点清单。
3.期望目标类问题
期望目标类问题用于弄清客户认为"做成什么样算成功"，把成功标准从口号变成指标。目标类问题沿三层递进：
业务目标：上线后什么指标变好（咨询量下降、响应变快、新人上手加快）？
衡量方式：这个指标现在多少、期望到多少、谁来统计？
验收共识：做到什么程度客户愿意签字验收?
智能问答系统项目把"答得准一点"翻译成可验收目标的过程：
客户："希望系统答得准一点，别乱说。“
追问：“咱们现在员工自己回答，大概十个问题能答对几个？“
客户：“熟练的九个吧，新来的可能六个。“
翻译成验收标准：“口语化提问命中率不低于 85%，每条回复标注出处文档，用50条真实
测试问答对来评估。“
期望目标类问题的产出是一张"指标对照表"——现状值、目标值、统计方式三列齐了，验收才有抓手。
4.约束条件类问题
约束条件类问题用于摸清项目的"硬边界"：预算、数据安全、现有系统、网络环境，这些约束往往直接否决某些技术方案。约束类问题覆盖四个维度：
预算与周期：预算区间、期望上线时间、有没有硬性节点。
数据安全：数据能否出企业内网、能否用公网模型服务、有无合规要求。
系统集成：要与哪些现有系统对接（OA、工单、IM）、能否提供接口。
运维能力：客户有没有IT运维人员、服务器资源归谁管。
智能问答系统项目的约束条件清单（来自访谈）：数据安全：文档不能出企业内网，生产环境必须私有化部署——这一条直接决定了模型选
型方向。
集成约束：员工习惯在企业 IM 里提问，系统要能嵌入IM 入口。
运维约束：客户没有专职运维，系统必须"部署简单、坏了能自动恢复"。
约束条件是需求说明书"范围边界"一节的直接来源，漏问一条约束，方案设计就可能整体返工
5.5Why追问法
5Why追问法是对一个表面诉求连续追问"为什么"，直到挖出根因的访谈技巧，它是对付"愿望式表达"的利器。使用规则有三条：
每一问都针对上一答的原因，不跳步、不诱导。
通常三到五层就能见根因，不必凑满五次。
追到的根因要用一句话复述给客户确认。
以"客户说AI答不准"为例的追问链：
同样的方法用在智能问答系统客户身上：客户最初说"我要一个AI问答机器人"，追问后得到根因链——为什么要机器人？因为重复咨询太多；为什么重复咨询多？因为文档不好找、新人不会查；为什么不好找？因为文档分散在各部门网盘、没有统一入口。根因浮现后，需求从"做个机器人"变成"建一个统一的知识问答入口，答案必须可溯源"一两者的技术方案完全不同。
这里要特别提醒：
- 错误做法：把客户提的方案（"我要个APP"）直接当成需求去实现。
- 正确做法：用5Why追到根因，把"方案"翻译回"要解决的问题"，再由你来设计真正的方案。
客户有权利提方案，但FDE有责任挖根因需求调研的深度，决定方案设计的高度。
三、客户现状走查：用数据代替印象
访谈拿到客户的说法，走查拿到系统的事实。本章用走查清单与记录规范，让痛点立得住。
这张图列出走查清单的四个核查项：文档资产、咨询渠道、现有系统与数据现状，每项都标注了"查什么、记什么"。走查的产出不是印象，而是一手记录——访谈里客户说的每一句，最好都能在走查记录里找到对应的实证。
1.现状走查清单
现状走查是FDE对客户现有环境（文档、渠道、系统、数据）的实地核查，用一手数据校验访谈结论。走查聚焦四项内容：
文档盘点：总量、格式分布、分类结构、更新频率、有无权威版本。
渠道盘点：现有咨询渠道及各自日咨询量、响应时长、承接人。
系统盘点：现有IT系统（IM、OA、工单）及可对接能力。
样本抽查：随机抽5-10个真实问题，人工走一遍"找答案"的完整过程，记录耗时。
智能问答系统项目走查结果记录（骨架）：
走查清单的价值在"抽样耗时"这类一手数据一—它们日后就是向客户证明效果的对比基线。
2.痛点记录规范
痛点记录规范是把访谈和走查得到的痛点，按统一格式逐条落表的记录方法，保证痛点可排序、可追溯、可翻译成需求。每条痛点记录四要素:
现象：发生了什么（一句话，含场景）。
影响：造成什么损失（时间、人力、风险）。
频率：多久发生一次（每天／每周／偶发）。
涉及角色：谁在承受这个痛点。
四个要素缺一个，这条痛点就说不清楚：少了场景不知道何时发生，少了频次排不了优先级。记录时逐格检查，四格填满才算一条合格记录。
智能问答系统项目痛点清单片段:
编号现象影响频率涉及角色
T-01员工在群里重复问操作每条回答占客服约每天约 40 条一线客服
类问题10 分钟
对照格式读这三行：每条痛点都有场景、代价、频次、角色，数字全部来自访谈实录。整理自己的清单时，凡是填不出数字的条目，都要回访谈记录里找依据。
这里要特别提醒一种写法通病：
- 错误做法：痛点写成"沟通效率低"这类无法度量的形容词。?正确做法：四要素齐活，频率和影响必须有数字或明确的量级表述。
痛点清单是需求说明书的地基四要素记录法让每个痛点都"带着证据进文档"。
四、需求收集与拆解：从痛点到可开发的需求
痛点清单是问题侧，开发要的是方案侧：本章把痛点翻译成可开发、可排期的需求条目。
这张图把用户故事拆成三个必备要素：角色（谁在用）、功能（要什么）、价值（为什么）——三要素缺一不可，缺了角色就不知道为谁做，缺了价值就无法排优先级。后面按这个句式把痛点清单逐条翻译成需求条目。
1.用户故事写法
用户故事是以使用者视角描述需求的标准句式："作为〈角色〉，我希望〈功能〉，以便〈价值〉"，让每条需求都带着角色和价值。写法上有三条要求:角色具体：写"一线客服"而不是"用户"，写"新员工"而不是"大家"。
功能可做：愿望部分必须是系统能实现的一个具体行为。
价值可验：以便后面接的是可衡量的收益，不是形容词。
智能问答系统痛点T-01翻译成用户故事的过程:
原痛点：员工在群里重复问操作类问题，客服每天花大量时间重复回答。
用户故事：作为一线客服，我希望常见操作问题由系统自动回答并附上出处文档，以便我
把时间留给真正需要人工处理的咨询。
对照检查：角色（一线客服）具体、功能（自动回答附出处）可做、价值（腾出人工时
间）可验——合格。
用户故事是痛点与需求之间的翻译器：一句合格的用户故事，能同时通过角色、功能、价值三道检查。
2.需求拆解三法与优先级
需求拆解是把大需求切成可开发、可排期的小需求的方法；优先级排序则决定"先做什么、后做什么、哪些不做"。三种拆解方法按场景选用：
自顶向下拆：从大功能逐层拆到可开发粒度（适合目标明确的系统建设）。
按场景拆：以用户旅程为主线切需求（适合流程类应用）。
按优先级拆：PO必做（不做就不能上线）、P1应做（首版尽量带）、P2可缓（列入二
期）。
三级优先级从必须做到可以缓做逐层放宽。拆解时逐条问自己：这条不做能不能上线，答不能就进PO，答能就往外放，避免什么都想塞进第一版。
智能问答系统需求按优先级拆解的结果（骨架）：
优先级不是拍脑袋：P0对应"客户签字验收的底线”，P1对应"锦上添花"，P2进二期的范围边界。
3.功能性需求与非功能性需求
功能性需求描述系统"做什么”（具体的feature）；非功能性需求描述系统"做得怎么样"（性能、安全、可靠性等质量属性）。后者最容易被遗漏，也最容易在验收时扯皮，常见维度有四类:
性能：响应时间、并发量、首字延迟。
准确与质量：命中率、引用正确率。
安全合规：数据不出域、敏感信息脱敏、审计留痕。
可运维：部署简单、故障自恢复、日志完备。
智能问答系统项目两类需求的对照：
这张表把两类需求放在一起对照：功能性需求看"系统能做什么"，天然显眼；非功能性需求看"系统做得怎么样"，不问不说、验收才爆雷。命中率、响应时长、数据不出内网三条，就是典型的非功能性验收口径调研时必须主动问出来。
看图时左右对照：左边的功能客户开口就会要，右边的质量指标不问不说、验收才现形。调研提纲要给右边留专门的问题，漏一项，验收时就多一次返工。
这里要特别提醒：
- 错误做法：需求说明书只列功能清单，不写性能与安全指标。正确做法：非功能需求逐项量化（数字+测试方式），并在验收标准表中与功能需求并列。
功能决定系统"能不能用”，非功能决定系统"敢不敢用"一—调研阶段就把两类需求都问出来。
五、需求说明书：把调研成果变成规范文档
调研成果还是半成品，本章把它写成客户签字、开发依据、验收标尺三位一体的说明书。
这张图给出说明书的六章骨架：从项目概述到附录层层递进，验收标准一章是后面验收演练的锚点。各章素材都来自前面三节的产出访谈记录、走查清单、痛点条目各归其位，写说明书不需要另起炉灶。
1.需求说明书的作用与结构
需求规格说明书是正式记录项目范围、需求条目与验收标准的文档，是开发、验收、变更管理三方共用的唯一依据。作用与结构可以合起来看：
三重作用：开发的依据（按它排期开发）、验收的标尺（按它逐项验收）、变更的基线
(改动都要对照它评估）。
六章结构：项目背景、用户与场景、功能性需求、非功能性需求、范围边界、验收标准。
智能问答系统需求说明书的验收标准表（骨架）：
每行三要素齐才算一条合格的验收标准：指标名、量化口径、取证方式。特别注意最右列，写不清怎么取证的指标，验收时必然各说各话。
这里要特别提醒验收标准的写法：
- 错误做法：验收标准写成"运行稳定、体验良好"。正确做法：每一项都是"数字+测试方式"，双方签字前逐条确认没有歧义。
无文档=无边界=无限返工；说明书六章中，“范围边界"和"验收标准"两章最值钱。
2.AI辅助编写与人工三查
AI辅助编写，是把访谈记录和痛点清单交给 AI 开发工具，按模板生成说明书初稿，再由人完成审核修订的写作方式。分工原则是 AI负责成型，人负责把关:
给足输入：把访谈记录、痛点清单、验收指标连同模板一起交给工具，约束章节格式。
人工三查：一查范围是否越界（AI爱加戏）、二查验收是否可测（指标有没有数字）、三
查场景有无遗漏（对照痛点清单逐条核）。
红线纪律：文档中的数字与指标必须来自调研结论，不得让模型编造。
看图时分两条线：机器负责快，人负责准。三道检查缺一道，说明书里就可能留下模型编造的细节；数字与指标永远以调研结论为准，模型只代笔不代言。
落实到操作上，AI辅助编写分四步:
1．把需求说明书模板、痛点清单、访谈纪要放进工作目录。
2．用 AI开发工具发出指令：“按模板结构，基于痛点清单生成需求规格说明书初稿，验收标
准表保留占位待填。“
3．逐章过稿，执行人工三查，修订后定稿V1.0。
4．全程用 Git管理版本，每次修订留提交记录。
举一次真实的初稿问题记录：AI生成的初稿里，“非功能性需求"一节出现了"系统可用性达到
99.99%"——回查访谈纪要，客户从未提过这个数字。这正是"AI爱加戏"的典型症状：它按行业惯
例补了一个漂亮数字。人工三查的作用就是把这类无出处的指标全部揪出来，改回有据可依的表述。
这里要特别提醒：
- 错误做法：AI生成后直接定稿，不做核对。正确做法：AI只出初稿，三查通过才算定稿；查出来的每一处改动都要能说出去源。
AI把"写文档"的时间从一天压到一小时，但"对文档负责"永远是人一—三查通过前，初稿只是草稿。
3.范围边界与变更管理
范围边界，是需求说明书中"本期做什么、明确不做什么"的章节；变更管理，是上线前需求发生改动时的处理流程。两者共同防止范围蔓延，构成双保险：
- 把"不做什么"写清楚：明确不做的事项列入二期清单，客户签字时一并确认。
变更四步流程：提出→评估影响→双方确认→版本记录；没有走完四步的变更不进开
发。
智能问答系统教学版的范围边界（骨架）：
本期范围：知识库管理（20O 篇 MD文档入库）、RAG 检索问答与引I用溯源、答不了自动
转人工、会话历史与多轮追问。
二期清单：完整管理后台、工单流转全流程、合规审计报表、多端APP。
变更示例：客户中途提出"能不能加个满意度评价"——按流程先评估（改造成本约一天,
不阻塞P0），确认后排入P2并更新说明书版本号V1.0→V1.1。
这里要特别提醒：
- 错误做法：口头答应客户"小事我们顺手做了"，范围悄悄膨胀。正确做法：所有新增需求都走四步流程，进不了本期的一律白纸黑字写进二期清单。
范围边界的本质是管理客户预期：写清楚"不做什么”，比多承诺十句"我们尽力"更能保住交付日期。
六、实战演练：从访谈到需求说明书v1.0
前五节的方法现在连起来跑一遍，交付物《需求规格说明书》V1.0在本节产生。
对照《进度地图》：M0工程骨架与密钥模块已就绪——主线仓库三端可启动、密钥走环境变量（回指"岗位认知与交付思维"课表1-9 的M0行），仓库侧的地基已经打好；本课要做的，是把"客户口中的需求"变成"可开发、可验收的规格"，为整个项目定靶，同时回看任务卡T-M0-1的能力自评——你圈出的最弱项，正是在本课这类实战里补齐的。
这张图把本课方法串成一条闭环：访谈拿说法、走查拿实证、痛点清单做归纳、说明书定规格、客户签字做确认——闭环走完，“客户口中的需求"就正式变成了"可开发、可验收的规格"。本节实战就沿这条闭环完整走一遍。
1.场景设定
自包含场景：你所在的FDE项目组刚接到智能问答系统项目，客户是企业运营与客服团队(约200 篇MD文档、每天数十条重复咨询、文档分散在各部门网盘）。讲师扮演客户方（运营主管+一线客服双角色），各组需在 20 分钟访谈内完成需求调研，随后完成痛点清单整理与《需求规格说明书》V1.0编写。
2.前置材料
(1）客户访谈提纲模板（四类问题框架，提前填写背景研究栏）。
(2）现状走查清单（文档、渠道、系统、抽样四项）与痛点清单表（四要素空表）。
(3）需求规格说明书模板（六章结构＋验收标准表）。
(4）分工建议：一人主问、一人记录、一人计时并负责 5Why追问。
3.操作步骤
按下面的步骤顺序推进，每步都标注了时长与完成标准。
(1）组内5分钟备战
按四类问题分配提问责任，约定追问手势。
(2）讲师以客户身份接受访谈
各组轮流主问20分钟，观察组同步记录提问质量。
(3）访谈结束立即整理
20分钟内把记录填进痛点清单表（至少5条），并把P0痛点翻译成用户故事。
(4）用AI开发工具生成说明书初稿
按模板生成初稿，经人工三查后修订定稿。
(5)组间交叉评审
用检查单互相挑问题，每份至少挑出2条；讲师扮演客户逐条确认并"签字"，形成V1.0。
4.返回呈现
一组合格交付物的形态（示例节选）：痛点清单6 条，T-01"每天约 40 条重复咨询、每条占客服约10分钟"四要素齐全；说明书六章齐全，验收标准表含四条可测指标（命中率≥85%、引I用100%、转人工15%、首字≤3秒，均为教学示例口径）；范围边界明确列出四项二期清单；文档标注版本v1.0与"客户确认：已签字"。
5.诊断与修正
某组第一次演练的真实失败样例照录：该组开场直接问"您想要什么功能"，客户顺势列了八个功能愿望，访谈变成功能清单大杂烩；整理出的说明书里"验收标准"一栏写的是"系统运行稳定、体验良好"，交叉评审组一眼指出"无法测试"。归因有二：访谈阶段把"听方案"当成"听问题"；编写阶段跳过了人工三查，AI初稿的含糊指标没有被打磨。修正动作：第二轮访谈改按"现状→痛点→目标→约束"顺序提问，并当场追问数字；说明书修订时把每条验收项改写为"数字+测试方式"。复跑后该组的验收表四项全部可测，顺利拿到"客户签字"。
6.复跑结论与可迁移规则
复跑后各组全部拿到v1.0定稿。可迁移规则有四条：第一，访谈永远从现状问起，不从功能问起；第二，每个痛点当场追到数字，没有数字的记入遗留问题清单限时补齐；第三，AI只出初稿，人工三查通过才算定稿，数字必须有调研出处；第四，签字不是形式——客户确认的范围边界和验收标准，就是后面所有设计与开发的最高依据。
七、产出物与《进度地图》登记
本课产出《需求规格说明书》V1.0，这是全程第一份正式接力物。
把本行登记进进度登记表（模板见"岗位认知与交付思维"课的表1-12），它同时是交付文档与验收演练课全程接力物总账上需求阶段的对账行。
读法自上而下：产出物是什么、放在哪、什么算合格、谁接着用——四栏读完，这份文档就从"本课作业"升级为"项目接力物"，概要设计课拿到它即可直接开工。
这张登记表沿用《进度地图》接力物的四栏口径：名称回答"产出了什么"，存放位置回答"搁在哪”，完成判据回答"什么形式算合格"，下游使用者回答"谁接着用"。四栏填齐，这份产出才算从"本课的作业"变成"项目的接力物"——下一场实战拿到它就能直接开工。
本课小结
本课打通了"从访谈到需求说明书"的完整闭环。核心要点有五：第一，需求失真有三种典型方式（愿望式表达、场景遗漏、指标含糊），对策是回到原始场景拿一手数据；第二，访谈提纲按业务现状、痛点场景、期望目标、约束条件四类展开，配合 5Why 追问挖到根因；第三，痛点用"现象、影响、频率、角色"四要素落表，需求用用户故事翻译并按 PO／P1／P2 排优先级；第四，需求说明书六章结构中，"范围边界"与"验收标准"两章最值钱，验收标准必须是"数字+测试方式"；第五，AI辅助编写提效，人工三查（范围越界、验收可测、场景遗漏）保质量，定稿必须经客户签字确认。这份V1.0 说明书是后面所有工作的最高依据一—接下来，我们就以它为输入，画出智能问答系统的概要设计蓝图。
思考与练习
1．客户说"给我们上一个 AI客服，让业务智能化起来"，这句话属于哪种需求失真？你会怎么
追问？
2.四类访谈问题中，哪一类最容易漏问？漏问的后果是什么?
3.需求说明书的六章中，为什么"范围边界"和"验收标准"最值钱？少了它们会发生什么?
4.如何把"员工希望快点找到文档里的答案"写成一条合格的用户故事，并为它设计一条可测试
的验收标准?
实操：对照现状走查清单，为你所在小组的工作环境做一次迷你走查，你能产出至少3 条
带四要素的痛点、并把其中1条写成需求条目吗？
参考答案
(以下为参考思路与示例，思考类题目言之有理、实操类题目以能跑通、能复盘为准。)
1.愿望式表达的追问
参考要点：属于典型的"愿望式表达"一把手段（上AI）当成了目的。追问路径：先问现状（"现在客服咨询是怎么承接的？一天多少条？"），再问痛点（"哪些问题最占用人力？"），再用5Why挖根因（"为什么要智能化？是想省人力，还是想提速度，还是想少出错？"）。追到根因后把方案翻译回问题，由你重新设计方案。
2.最容易漏问的一类
参考要点：约束条件类最容易漏问。后果示例：漏问数据安全，方案里用了公网模型服务，验收前发现数据不能出内网，架构整体返工；漏问集成约束，上线时发现系统进不了企业IM，入口落空。对策：把约束四维度（预算周期、数据安全、系统集成、运维能力）做成访谈提纲的固定检查项，逐项打钩。
3.两章最值钱的原因
参考要点：范围边界决定"做什么"，是排期与报价的依据，少它会范围蔓延、交付日期失控;验收标准决定"做到什么程度算完成"，是双方签字的合同条款，少它会在验收时无限扯皮。两者的共同点是把口头共识变成书面依据——没有它们，说明书其余章节写得再好也只是"愿望清单"。
4.用户故事与验收标准参考写法
参考要点：用户故事——作为新入职员工，我希望用口语描述问题就能从系统里得到带出处的答案，以便不用翻网盘就能在几分钟内完成操作。验收标准——口语化提问命中率≥85%，用50条真实测试问答对评估，逐条记录命中情况。检查：故事三要素（角色具体、功能可做、价值可验）齐全；验收标准有数字、有测试方式，双方无歧义。
5.迷你走查参考要点
参考要点：走查按四项展开——文档盘点（小组资料放哪、多少份、谁维护）、渠道盘点（问题在哪个群问、谁响应）、系统盘点（用了哪些协作工具）、样本抽查（抽3个真实问题人工找答案并计时）。痛点示例：T-01课程资料分散在三个目录，找一份操作指南平均5分钟（现象：分散；影响：每次5分钟；频率：每天多次；角色：全体组员）。需求条目：作为小组新成员，我希望在统一入口按关键词检索到全部课程资料并标明出处，以便1分钟内找到所需文件。注意走查结论要回填痛点清单，与访谈结论互相印证。
