“我们想做一个AI质检看板，每天自动统计客服的问题，再给主管一些建议。”

听完这句话，你大概已经能想象界面：问题分类、人员排名、趋势图，再加一个生成建议的按钮。需求似乎足够清楚，可以开始画原型了。

但在一家虚构的家居电商企业里，主管真正为难的是另一件事：看完问题以后，他找不到对应通话片段，也不知道建议应该发给谁；下周再看，同类错误仍然出现，却无法判断辅导是否做过。

看板可以展示问题，主管还需要完成识别、核对、辅导和回访。FDE若没有看见后半段工作，很可能把统计做得更漂亮，却没有改善最费力的部分。

听懂别人想要什么，是调查的开始。理解业务，还要知道他准备完成什么工作、依据什么判断，以及现在具体卡在哪里。

把“想做一个功能”，还原成正在发生的工作

这个案例中的企业叫“禾木家居”。以下人物、记录和对话都是用于讲解方法的教学材料，不是某家客户的调研实录。

客服主管每周抽查售后沟通，整理问题，找组长安排辅导。当前资料分散在质检表、通话系统和群消息里。AI可以帮助整理文本，但怎样进入现有工作，还需要进一步调查。

面对最初的看板需求，FDE可以先问：“最近一次你看到了一个问题，接下来做了什么？”这比直接问“希望看板有哪些功能”更容易得到实际工作细节。

主管举出一条记录：质检表标注“解释退款条件不完整”，他打开通话系统搜索客户，听完以后，发现员工已经说明主要条件，只是质检摘要漏了一句。他撤销了问题标签，又在群里提醒组长不要安排这次辅导。

如果只记录“需要问题分类”，就会漏掉证据核对和纠错。如果进一步观察，还会发现：主管花时间寻找的是哪段原始材料，谁有权改标签，修改后哪些地方需要同步。

再问另一条真正需要辅导的记录。主管找到片段，写下建议，发给组长；组长后来是否开展辅导，没有统一记录。下次相同问题出现时，大家也难以区分“没有辅导”和“辅导后仍未改善”。

两条记录说明了不同困难。第一条涉及判断依据和更正，第二条涉及任务承接与后续观察。它们可能需要不同处理，不宜在调研早期都归入“AI分析不够强”。

此时，可以把初始需求改写成待验证的问题：“主管在从质检发现进入辅导行动时，需要反复查找证据，且缺少可核对的承接记录。”这句话仍需更多材料支持，但已经指出了准备调查的工作范围。

业务理解往往就是这样逐步变清楚的：保留对方提出的解决办法，同时回到具体任务，找出办法希望改变的困难，再检查困难是否真实存在、是否值得处理。

先安排一次有目标的观察，再补访谈

访谈可以帮助理解规则，观察可以看见规则在实际操作中怎样被使用。两者结合，比单独收集功能意见更容易发现遗漏。

BABOK在“准备发掘”“执行发掘”“核实发掘结果”等任务中强调，信息获取需要明确目的、组织参与，并核对结果。它对访谈和观察法也分别给出了讨论。本文把这些方法转成一次适合FDE练习的小型调查。

假设你获得了查看脱敏样本和观察操作的许可，可以安排一次约45分钟的工作回放。这个时长只是练习安排，不是保证足够完成调研的标准。

开始的几分钟，用来约定范围：今天跟随一条质检发现，看到主管如何核对、处理和交给下一位同事。不是评价员工个人表现，也暂不讨论所有报表需求。

接着请主管打开一条最近处理过的记录，按当时的顺序操作。记录他在哪个页面寻找什么，离开当前页面的原因，以及某一步没有资料时怎样继续。不要急着把每个手工动作都标成可以自动化。

例如，他复制通话编号到另一个系统，发现没有权限播放，于是请组长转发片段。这说明当前身份与取证路径需要调查，不能直接据此断定应该让AI访问全部通话。

观察时，提问方式也会影响结果。如果每一步都打断解释，记录的耗时就包含了你的提问；若要测量工作时间，应事先约定观察方式，另行记录打断与等待，不能把回放耗时当成日常效率数据。

任务走完以后，再追问关键判断：“什么条件下可以撤销标签？”“哪类问题必须复核？”“建议发出以后，怎样知道有人承接？”开放式问题帮助发现内容，确认式问题用于核对你是否理解正确。

还需要找一条不同情况。比如，没有录音权限的记录、主管不同意AI标签的记录，或者需要跨组处理的记录。只看一次顺利完成的任务，很容易把偶然条件当成常规做法。

最后留出时间复述：“我看到你先核对原文，再决定是否形成辅导任务；当前最不清楚的是任务是否被接手。”请主管修正这段理解，并确认哪些材料还需要由组长或系统负责人补充。

一次观察结束，产物不必很厚。任务步骤、证据位置、判断条件、卡点和待核实问题，足以帮助安排下一轮调查。记录太多却无法指导下一步，同样会增加工作负担。

用六个问题，把局部困难放回业务情境

看到一个卡点以后，还要判断它与业务目标有什么关系。否则，可能花很大力气解决一个偶发的不便，却没有触及真正重要的工作。

BABOK的商业分析核心概念模型讨论六个相互关联的概念：变革、需要、解决方案、相关方、价值和情境。对初学者而言，可以先把它们转成六个问题，不必急着记缩写。

主管提出看板，背后的需要可能是缩短取证时间、减少误判，或者让辅导有后续记录。几种需要的优先级不同，应请相应负责人确认。

第一轮可以只支持“从待复核发现到已确认的辅导任务”。是否要自动评分、影响绩效或向员工发送建议，属于额外决定，不能因功能相邻就默认纳入。

除了新建看板，也可以改善记录链接、增加承接字段、调整已有工作流程。AI适合承担哪部分，需要和规则处理、界面改进、人工判断一起比较。

主管、组长、客服、质检人员、系统负责人看到的问题可能不同。主管希望快速安排辅导，客服关心标签是否有依据，组长需要知道自己接手哪条任务。只访谈提出需求的人，会漏掉这些条件。

可以先约定观察取证与复核所需时间、任务承接完整程度、错误标签的更正情况。具体指标要有定义和基线，不能只写“提升效率与满意度”。

不同客服组的权限、业务类型和资料保存方式可能不同。如果只能读取文本摘要，就不能承诺核对全部原始通话；如果制度要求人工复核，就不能把自动生成标签直接当作最终评价。

六个问题相互影响。扩大自动处理范围，可能改变相关方和风险；增加证据保存，也会带来新的权限与维护要求。业务理解需要把这些变化连起来看。

这里可以借用库内商业论证笔记中的一个提醒：保留现状作为比较对象。当前流程也许不够方便，但它已经承担了一些判断和纠错功能。新方案应当说明如何保留必要能力，以及新增投入换来了什么。

这时不必编造一个漂亮的收益数字。可以先记录价值假设、需要取得的数据和比较条件。尚未测量的收益，应当继续写成假设。

让事实、解释和未知，各自留在正确的位置

调查笔记最容易出问题的地方，是把听到的解释写成已经证实的事实。

例如，“主管不会用系统，所以一直在群里处理”，可能只是某个人的判断。实际原因也许是记录缺链接、组长没有权限，或者系统没有承接状态。不同原因对应不同的处理方式。

已观察事实：“主管从质检表复制通话编号，到另一个系统检索。”同时记录样本范围、观察时间与材料位置，避免一句话看起来像覆盖整个部门的结论。

待验证解释：“跨系统检索可能是主要耗时来源。”这里需要继续计时或回放其他任务，检查是不是普遍问题，以及等待、复核、沟通各占多少。

尚未知条件：“能否按当前身份生成直达原始片段的链接。”需要系统负责人核实接口、权限和保存条件，不能因为演示环境能打开就默认所有用户都能访问。

这三类内容可以放在同一页里，但要让读者一眼分清。下一次讨论时，新增证据可能让解释得到支持，也可能迫使你改掉最初判断。

假设随后发现，主管查找录音很快，真正耗时的是等待组长判断是否需要辅导。那么，就应调整调查重点。继续建设检索功能，可能解决了一个存在但并不重要的问题。

相关方说法冲突时，也先记录差异。主管说每条任务都会跟进，组长说收到的消息经常没有明确要求；两句话可能分别来自不同类型的任务。拿出同一条记录，核对双方看到什么、何时行动，比直接判断谁说错更有效。

还要区分制度与实际做法。某位熟练主管习惯先私下确认，不代表所有组都必须如此；文件写有承接要求，也不代表现场已经执行。FDE应当将两者分别记录，再请负责人决定方案遵循和改善什么。

在这个过程中，本体建模可以提供一组有用的提问：我们正在谈哪个对象，它与什么相关，当前状态是什么，谁允许它发生什么动作？这些问题可以先用自然语言回答，并不要求立刻建设一套完整本体平台。

比如，“质检发现”“辅导任务”和“辅导记录”是否是同一件事？如果把它们塞进一个状态字段，“已处理”就可能同时表示已复核、已发送或已完成辅导。先把含义区分，后续系统才有机会记录清楚。

为了继续问清楚，可以把问题再分成四类。事实问题问“这条发现对应哪段资料”；关系问题问“它属于哪次沟通，由哪个组处理”；判断问题问“什么条件下需要复核”；行动问题问“确认以后谁可以创建辅导任务”。

这组问法借鉴《企业本体建模方法与实战指南》中的能力问题设计。所谓能力问题，在这里指我们希望业务模型能够支持回答的问题。它帮助缩小建模范围，无需在第一次访谈里列出企业所有对象。

把回答写下来以后，再找反例。如果一条问题涉及两名客服，是否仍然只能指定一个接收人？如果原标签已撤销，已发出的辅导任务怎样处理？这些问题会影响对象关系与动作条件，应该在实现以前继续澄清。

把调查结果，写成别人能够继续工作的说明

理解业务最终需要落实为可以使用的材料。对于当前案例，可以先写一张简短的业务发现卡，再附样本与待核实问题。

这张卡还需要补充一条样本链：原始通话片段或获准摘要、初始问题标签、复核结论、任务内容、接收人和后续记录。拿不出的环节，就保留为资料缺口，不要补写成已经发生。

然后，将下一步写成可检验的工作：“选取获准使用的历史样本，请主管按现有方式与拟议方式分别回放；记录资料查找、复核和承接的差异，同时检查错误标签是否仍能更正。”

比较条件要说清。两次处理同一条记录，参与者可能已经记住内容；教学练习可以用来发现流程问题，但不能把这种回放的时间差直接宣布成真实收益。若要评估实际效果，需要另外设计更合适的比较与观察。

再把卡片交给工程同事，看他能否问出具体问题：记录标识从哪里来，什么资料允许读取，人工复核后保存什么，任务承接怎样确认？如果只能得到“希望智能一点”的回应，说明材料还需要细化。

也交给实际使用者确认：“照这个范围，是否覆盖你要完成的工作？哪一个必要动作遗漏了？”这一步能防止调查记录只在分析者之间流转，却没有被工作承担者核对。

还可以给这张卡补三条验收情景。第一条，主管认为标签有误，应能查看依据并保存更正原因；第二条，标签被确认，应能找到对应任务与接收人；第三条，资料无权访问，应明确停止在待核实状态，而不是生成一个看似完整的结论。

这些情景连接了业务调查与后续测试。它们还不是完整测试集，但已经告诉实现者哪些行为需要出现，也让业务方能够检查系统是否理解了自己的工作。

这条联系应当保留下来：某项需要对应哪些规则与设计，设计又由哪些情景检查。以后有人提出修改，就能沿着这条联系寻找影响范围。它借鉴需求跟踪的思路，形式可以很轻，不一定需要复杂管理系统。

如果业务方说“先做出来再说”，也可以选择一条已经确认的路径做小范围验证，同时把未确认的自动动作留在范围外。推进工作与保留未知可以同时进行；关键是不要让未核实假设悄悄进入正式执行。

换一个场景，检查方法能不能继续使用

回到制造企业采购，你也可以用相同的方法调查“想做一个智能申请助手”。先回放一笔退回记录，再观察申请人如何补充、核验员如何判断，最后核对资料怎样进入后续系统。

如果问题是“箱”与“只”无法确认，重点可能在物料依据；如果资料齐全却仍要重复录入，重点可能在系统衔接；如果入口无人使用，则需要继续调查权限、任务适用范围和支持方式。不要提前把答案固定为模型能力不足。

调查也有停止点。对于一轮有限原型，当目标任务、关键角色、必要资料、主要规则和几个重要异常已足够清楚，就可以进入验证；其他问题继续保留在待办中。追求一次问清全部业务，容易让调查长期没有结果。

不过，只要仍无法判断一个动作由谁批准，或者关键资料的含义尚有冲突，就应限制相关实现。不能用“后面再优化”掩盖决定所需的基本条件。哪些问题可以边做边查，哪些会阻止动作执行，要根据实际影响分别判断。

每一次调查，都试着带回一条能追踪的证据、一条经过核对的解释，以及一个尚待确认的条件。它们会帮助后续设计知道从哪里出发，也帮助团队在发现新情况时修改判断。

你今天就可以找一位熟悉的业务同事，请他回放最近一次遇到困难的任务。先看他怎么做，再问为什么这样判断；结束时用自己的话复述，并请他指出遗漏。

当你能够说明一项工作的对象、步骤、判断、协作与困难，并且知道哪些结论仍待验证，需求才开始变成可靠的实现依据。

下一篇，我们继续处理调查中最难问清的一类内容：老师傅说“凭经验”，怎样把判断规则问出来。

听懂需求之后，FDE还要怎样理解真实业务

副总裁

职业发展

后端

人工智能

从AI质检看板需求切入，通过工作回放揭示主管在证据核对、辅导承接中的真实卡点。提出六问框架与三类笔记法，区分事实、解释与未知，建立业务发现卡与验收情景，为FDE提供可操作的业务调研方法。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

听懂需求之后，FDE还要怎样理解真实业务

听懂需求之后，FDE还要怎样理解真实业务

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐