FDE 怎么做需求调研？把“我要一个 AI”变成真正的技术需求

FDE 怎么做需求调研把“我要一个 AI”变成真正的技术需求一、需求调研的产物不是客户愿望清单二、先找到正确的人再安排正确的访谈三、从“最近一次怎么做”而不是“将来想不想用”开始四、观察动作把证据、解释和假设分开五、画出当前流程再描述准备改变的那一步六、数据盘点必须包含“谁允许谁看什么”七、先测当前表现才知道“提高效率”是什么意思八、优先级看证据和依赖不制造精确幻觉九、用“证据 → 需求 → 验收”避免越写越飘十、带着不确定性回放需求让客户确认同一件事十一、实战练习用一次任务完成一份调研包FDE Thinking为什么客户说“做个知识库”不能马上开始写 RAG专栏《AI FDE 实战从 Demo 到生产》第 05 篇 / 共 18 篇本篇目标完成一次围绕真实任务的需求调研把访谈与观察转成可追踪、可验收的工程需求。适合读者需要直接接触客户、定义 AI 应用范围的软件工程师、AI 应用开发者和技术负责人。“我们有很多文档你们帮忙做一个 AI 知识库吧。”听到这句话你可能已经开始选择向量数据库、设计文档切分策略甚至盘算是否加一个 Agent。先暂停一下。客户目前究竟是找不到文档还是找到了却不知道哪个版本有效他想让新人独立处理问题还是让资深客服减少重复操作真正耗时的是搜索还是等待主管确认如果这些问题没有搞清楚技术方案越完整后面需要推翻的工作可能越多。第 04 篇介绍了项目从接触客户到交付的整体过程。这一篇只放大其中一个动作怎样通过调研把客户口中的解决方案翻译成有证据支持的用户任务和工程约束。我们继续使用“星河设备售后 AI 助手”。星河设备、访谈人物、对话、产品、任务记录和数值均为虚构教学示例不是实际访谈或效果测量。第一阶段仍限定为内部客服的授权保修材料政策问答不自动批准赔付、不修改订单、不自动发送消息。订单查询和人工确认后的工单提交属于后续规划。一、需求调研的产物不是客户愿望清单“支持智能问答”“答案准确”“响应很快”看起来像需求实际上还没有回答工程团队最关心的问题谁在什么情况下使用输入是什么输出需要支持什么决策遇到例外怎么办最后由谁判断做对了。同样一句“答案准确”客服可能理解为材料清单不要漏项主管可能理解为不能承诺赔付知识管理员可能理解为必须使用适用的政策版本。这些要求相关却不能相互替代。调研结束时我希望桌上至少有五样东西一张当前任务流程图、一份可定位到原始材料的证据记录、一份数据与权限清单、一组带验收例子的需求以及一份尚未解决的问题列表。它们不需要厚重但必须能支撑下一步决定。GOV.UK 的用户需求指导强调应从证据理解用户要完成的事需求描述应聚焦问题而不是预先选定解决方案。这是本文借用的方法原则不意味着企业项目必须照搬政府服务流程。来源Learning about users and their needs所以“我们需要 RAG”暂时只能记为一个方案建议“客服需要确认当前产品适用的材料要求以免让客户反复补交”才更接近待验证的用户需求。二、先找到正确的人再安排正确的访谈企业客户不是一个人。提出预算的人、每天使用系统的人、维护资料的人和承担错误后果的人可能坐在不同楼层。在星河设备案例中我们先画出一张简洁的参与者表参与者需要理解什么不能替谁回答售后主管业务目标、当前损失、可接受的使用边界不能代替客服描述每次查资料的过程新客服不熟悉术语、适用条件和升级路径时如何工作不能代表所有熟练用户资深客服隐性判断、快捷办法、疑难问题处理不能把自己的记忆当成每个人都具备的能力知识管理员生效版本、修改流程、资料所有权不能单独批准业务赔付身份与系统负责人用户身份来源、访问范围、现有技术限制不能单独定义业务答案是否正确首轮可以从不同熟练度、不同产品线的少量参与者开始。例如预约两名新客服、两名资深客服及相关负责人是一个组织调研的起点不是“访谈这些人就一定足够”的统计结论。若发现夜班、外包团队或辅助技术使用者面对不同障碍就需要补充对应样本。还要记录谁没有被覆盖。只访谈最积极的员工会低估使用阻力只找部门推荐的优秀员工会高估大家的知识水平。主管在场也可能让客服回避真实问题因此实际任务观察可以与管理层目标讨论分别进行。三、从“最近一次怎么做”而不是“将来想不想用”开始最容易让访谈失效的问题是把你的方案藏进问题里。“如果有一个能自动回答的 AI你是不是会更方便”很容易得到肯定回答但它并不能证明用户真的需要这个工具也不能说明当前困难在哪里。更有用的开场是“请找一次最近处理过的保修材料咨询带我看一下你从收到问题到准备好答复的过程。”把抽象意见拉回具体事件才能继续追问。容易诱导的问题可以替换成的问法你们搜索是不是特别难用上一次你怎样找到需要的材料AI 帮你总结会不会更快哪一步花的时间最多你怎样判断你是不是需要自动提交工单得到材料要求以后你接下来做什么这个页面是不是很清晰你会根据这里的信息采取什么行动如果准确率很高你会用吗上次遇到不确定的答案你怎么处理开放、中性的提问以及围绕真实故事继续追问也是 GOV.UK 深度访谈指南所推荐的做法。来源Using in-depth interviews下面是一段为教学编写的模拟访谈FDE最近一次查保修材料是什么情况小林新客服昨天有人问 XH-200 要寄修需要准备什么。我先搜“XH200 保修”看到两份文件。FDE你接下来怎么选小林我先点修改日期比较新的但里面又写适用于另一类销售合同所以去问了老同事。FDE当时哪里让你不能继续小林材料清单我看得懂主要是不确定这次适用哪份。FDE老同事怎么确认的小林他让我补看购买时间和渠道再去政策目录核对生效范围。FDE如果找不到能确定适用范围的依据你通常怎么办小林留下咨询记录转给值班主管不会直接告诉客户一定能保修。这段对话并没有证明“搜索引擎很差”更没有证明“必须上 Agent”。它揭示了三个值得继续验证的线索搜索别名可能不一致文件修改日期不能替代政策适用条件缺少上下文时需要补问或升级处理。下一步可以查看这次任务实际打开的文档找知识管理员确认版本规则再观察其他客服处理相似任务。这样才能判断一个人的经历是否反映了更广泛的问题。四、观察动作把证据、解释和假设分开用户通常会概括说“我就是搜索一下再回给客户。”实际观察时你可能看到他在文件夹和聊天软件之间切换复制一个旧回复询问同事又返回文档检查脚注。那些被习惯省略的步骤往往才是设计的关键。观察前说明用途、记录方式、可见人员和保留安排并取得参与者对记录的同意。尽量使用获准且经过必要处理的任务材料不要为了制作调研报告把客户合同和个人信息随手复制到公共协作空间。在真实环境中观察任务可以帮助发现设备、资料和工作干扰造成的障碍但不断要求用户边做边解释也会改变他的自然节奏。GOV.UK 的情境观察指南明确区分了静默观察、偶尔追问和逐步讲解这些方式。来源Contextual research and observation因此用来理解流程的讲解型演示不要直接拿来当“日常平均耗时”。我们需要给记录贴上“自然任务”“任务重演”或“研究者引导”等标签。图 2原始记录、解释和方案假设分别保存验证结果可以推翻前面的判断。一个实用的记录方式如下层次教学示例这条记录能证明什么证据 E-01任务重演中小林打开两份政策随后询问同事适用范围在这一任务里他需要额外确认解释 I-01现有入口没有帮助他识别政策适用条件团队对现象的暂时解释仍可能不完整假设 H-01同屏展示型号、有效期、适用渠道及依据可能减少复核切换一个待比较验证的设计想法验证 V-01用同类任务比较现有流程与可核对来源的结果卡检查是否更快完成且没有增加误用证据记录还应带日期、参与者匿名编号、任务编号和原始笔记位置。不同任务里重复出现的问题可以汇总为模式不同用户的相反经历也要保留。GOV.UK 的研究分析指南建议先记录实际看到、听到的内容再提炼发现与后续行动。本文进一步用“解释”和“假设”两个字段方便工程团队检查自己的推断。来源Analyse a research session这里尤其要防止一种跳跃“用户找了很久”是现象“用户需要语义检索”则已经是方案。也许统一文件命名和入口就能解决大部分困难。保留这种可能性才能做出有根据的技术选择。五、画出当前流程再描述准备改变的那一步流程图不必覆盖售后的全部业务。我们只画“回答一次保修材料问题”并明确起点和终点。起点是客服收到问题并开始处理终点是客服形成经过复核、可以按现有流程使用的答复。正式对外发送仍由原流程负责不算 AI 自动执行。图 3To-be 是待验证的目标流程。它没有承诺自动解决全部情况也没有新增业务写入权限。当前步骤As-is观察到的困难目标行为To-be读问题识别产品型号别名与销售名称不一致帮助确认型号不能确定时补问搜目录与历史回复入口分散旧回复未必可靠在获准资料范围内寻找依据对比政策版本修改日期与生效时间混淆展示适用条件、版本和来源整理材料清单脚注中的例外容易漏掉清单与限制条件同时可见复核、询问同事信息不足时不知道找谁可核对原文不足时走明确升级路径这里有一个重要判断AI 能否减少前面的查找成本必须连同后面的复核成本一起看。如果回答很漂亮用户却要重新检索全部资料才能相信它目标流程没有真正改善。还要问“如果暂时没有 AI这条流程能怎样改”。一个按型号和渠道筛选的政策目录也值得作为比较方案。FDE 需要证明具体改动有效而不是证明所有问题都适合大模型。六、数据盘点必须包含“谁允许谁看什么”“客户已经有几千份 PDF”不等于项目拥有可用数据。文件存在、内容可信、能够解析、允许使用是四个不同条件。对于第一阶段可以从一张小表开始资料必须确认的事项第一阶段处置已审核通用保修政策所有者、生效范围、版本替换关系审核和授权确认后纳入旧版保修政策是否仍适用历史购买场景按适用规则保留或排除不能只凭新旧删除客户专属合同合同归属、可访问人员、是否进入范围本阶段排除不能借检索间接暴露历史客服回复是否正确、是否含个人信息、能否代表政策不作为权威政策依据订单及工单数据实时接口、字段权限、操作边界记录后续依赖本阶段不接入不要只问“这个文件夹能不能访问”。还要问登录账号从哪里来应用如何得到角色与组织信息同一员工调岗后权限何时变化撤回的资料何时停止进入回答已经生成的摘要和缓存如何同步处理这些问题尚未回答时应标记为依赖或阻塞条件。工程师不能因为拿到了文件副本就推定有权让所有用户通过 AI 检索它。政策适用性与访问权限也要分开。用户获准查看某份文件并不表示其中规则适用于当前问题某份政策确实适用也不表示每个人都有权阅读其全文。两种判断都需要各自的可信依据。七、先测当前表现才知道“提高效率”是什么意思很多项目写“效率提升 50%”但既没有基线也没有统一的任务完成定义。到验收时每个人都能算出一个不同的结果。在星河设备案例里先定义三个观测指标完成一条材料咨询的总耗时、材料与条件是否完整、是否正确走了补问或升级路径。记录任务难度、客服熟练度和是否等待他人避免把不同情况混成一个平均值。下面是用于说明计时口径的虚构单任务数据不代表基线或优化结果环节现有流程示例候选工具示例理解问题、补齐已知条件45 秒45 秒寻找和整理信息170 秒35 秒人工复核、修改答复85 秒230 秒总计300 秒310 秒如果只看“寻找和整理信息”工具好像很成功计入复核后总耗时反而增加。下一轮应该查明复核为什么变慢例如引用难定位、适用条件隐藏或回答包含无关建议而不是继续单纯优化模型首字延迟。真实测量还要做到两件事。第一质量判定最好由熟悉政策的人按预先约定的规则复核不能把“用户点击采用”直接等同于正确。第二失败、超时和转人工都保留不能只统计答出来的简单问题。比较现有流程与候选工具时应尽量保持任务组合相近并考虑熟悉题目产生的练习效应。可以交错安排不同但难度相近的任务按新人、熟练员工分别查看结果。小规模样本首先用于发现问题不宜包装成精确的长期收益预测。八、优先级看证据和依赖不制造精确幻觉调研结束后功能清单可能很长语音输入、自动摘要、政策问答、订单查询、工单提交、智能赔付。此时给每项填一个“价值 9.2 分”看起来科学却可能只是把主观意见写成小数。第一轮排序可以更朴素这是不是已观察到的高频或高影响任务有没有可信且可授权的数据能否在可控范围内验证错误后果是什么需要先解决哪些依赖决定例子依据或下一步本阶段必须材料清单带适用条件与原文依据对应版本判断困难直接影响任务正确性先澄清再做文档版本冲突处理需要知识管理员确认权威规则后续评估查询订单人工确认后提交工单属于不同数据与操作边界另做调研当前排除自动批准赔付、修改订单、对外发消息不在本次任务和授权范围有证据再加语音入口、多 Agent目前没有证明是完成任务的必要条件优先级不是一次永久排序。假设发现主要耗时其实来自等待合同确认那么通用政策问答的价值判断就应调整。承认证据改变了方案远比保护最初的功能清单更有用。九、用“证据 → 需求 → 验收”避免越写越飘需求最好能回答两个方向的问题向前追溯为什么要做向后追溯怎样证明已经做到。图 4每个需求都有来源与可观察的结果验收样例不把模型必须使用某句固定措辞当成目标。例如把“答案准确”拆成下面几条证据或约束工程需求可观察的验收行为E-01用户无法判断政策适用范围R-01展示结论的适用条件、版本与依据A-01给定已知条件采用正确规则引用能够打开并支持结论E-02缺少购买背景时需询问同事R-02依据不足时补问或升级A-02缺关键条件的样例不直接给确定材料结论C-01管理员确认存在受限资料R-03仅使用当前用户获准内容A-03无权用户的请求中答案、引用和标题不泄露受限内容E-03人工需要核对脚注R-04保留影响材料要求的例外A-04含例外的样例中必要限制可见且未被摘要删除下面把 A-02 写成一个能够交给开发和测试共同讨论的例子。它是行为规格示例不是可执行测试代码场景问题缺少判断政策适用性所需的购买背景 假设 当前登录客服有权访问试点通用政策 并且 同一产品在不同购买条件下有不同材料要求 当 客服只提供产品型号并询问保修材料 那么 系统说明还缺少哪些条件 并且 不自行猜测适用版本或承诺保修结果 并且 在无法补齐时展示现有人工处理路径要求还应说明实际判定人和测试资料来源。针对 R-01知识管理员确认政策规则售后人员判断结果能否支持任务技术团队验证引用和权限处理。不要让模型单独给自己的回答打分再以此宣称验收通过。验收数量和阈值应在样本与风险明确后约定。这里展示的是如何写可验证行为几个样例通过并不等于系统对全部问题都可靠。十、带着不确定性回放需求让客户确认同一件事调研结束不是把会议录音转成几十页文档。更有效的是带着一次完整任务向用户和负责人回放“我们看到你这样做困难出现在这里因此本次准备改变这些行为。”可以使用下面这份模板# 星河设备售后 AI 助手调研回放与范围确认 ## 任务与用户 - 内部售后客服查找指定产品范围内的保修材料要求。 - 起点收到问题终点形成经复核、可使用的答复。 ## 证据与解释 - 已观察证据[编号、任务、记录位置] - 当前解释[解释及反例] - 待验证假设[验证方法、负责人] ## 本阶段需求与验收 - R-01[行为]关联证据[编号]验收[样例] - 权限、政策适用性与不足信息处理[具体规则] - 基线口径[开始/结束/复核/失败/任务分类] ## 排除范围 - 不自动批准赔付、不修改订单、不自动对外发送消息。 - 订单查询和确认后工单提交留作后续评估。 ## 未决事项 - [问题][影响]负责人[角色]下一步[证据] - 哪些事项会阻塞试点哪些可以受限验证[说明] ## 确认记录 - 实际用户流程描述是否真实、是否遗漏关键例外。 - 业务负责人范围、验收与预期价值。 - 数据/权限负责人资料和访问边界。 - 技术负责人依赖、可行性及尚未承诺的部分。 - 版本、确认日期、不同意见及待处理项[记录]回放时别只问“大家有没有意见”。拿出一个常见问题、一个条件不足的问题和一个受限资料问题请参与者分别说明期望的处理结果。如果他们给出的答案互相冲突就还没有形成可执行的共识。未知问题也要有主人。例如“政策无版本号时如何识别适用性”应由知识维护负责人提出规则“员工角色从哪个系统获取”应由身份系统负责人确认。FDE 可以组织验证、解释技术影响但不能替业务所有者发明事实。会议沉默不等于批准。需要按客户既有协作流程记录谁确认了什么、哪些条件尚未满足。需求确认之后仍然可以变化但变化应留下原因、受影响的验收项和范围影响。十一、实战练习用一次任务完成一份调研包这一篇不用急着写应用代码。找一个你熟悉的内部资料查询场景若无法接触真实用户就使用虚构材料模拟并明确标注。写出五个不包含“AI”“RAG”“Agent”的问题了解最近一次任务如何完成。观察或重演一次任务记录起点、步骤、卡点、资料和完成条件注明是否有人引导。从记录里选三条证据分别写解释、替代解释和可验证假设。画一张 As-is/To-be 流程图解释每个改动准备减少什么成本。盘点资料所有者、适用条件、访问范围和更新责任。写三条“证据 → 需求 → 验收”至少包含一个信息不足或无权限的例子。填写回放模板把未知事项与已确认内容分开。练习完成后自查一个问题如果把所有技术名词删掉另一位同事能否说清楚你准备帮助谁完成什么工作以及怎样知道做对了如果不能需要继续澄清需求。FDE Thinking为什么客户说“做个知识库”不能马上开始写 RAG因为“知识库”只是客户能想到的一种办法。真正要改善的可能是判断资料是否适用也可能是政策维护没人负责或者遇到例外时没有明确的处理人。需求调研的价值在于让这些不同问题浮现出来。数据治理的问题需要明确所有者与更新规则权限的问题需要可靠的身份和访问边界查找与理解的问题才可能通过新的检索和交互方式改善。它们可以同时存在但不能被一个聊天输入框自动解决。FDE 不需要在调研结束时已经知道所有答案却需要知道哪些事实已经有证据、哪些判断仍是假设以及下一步怎样减少最影响项目的那部分不确定性。当你可以用真实任务解释每个需求用明确样例说明如何验收再讨论技术栈才有了可靠的起点。下一篇我们就以这些已经澄清的工程需要为依据讨论 Python、TypeScript、模型接口、数据库和部署工具分别在项目中承担什么角色。