很多本体项目的问题，并不是出在 本体建模 阶段，而是更早就已经埋下了。

业务负责人谈目标，一线人员讲痛点，产品经理记录功能，数据团队追问字段，AI 团队讨论模型。每个人说的都有道理，最后却很容易得到一份彼此无法验证的需求清单：做问答、加预警、自动生成报告、接入几个系统。

如果直接拿这份清单做本体建模，团队通常会走向两个极端：要么围绕已有表字段堆概念，要么试图建立一个覆盖全部业务的“大本体”。

此前在“本体驱动的数据治理”系列中，我分别讨论过 如何选择业务场景 和 如何从业务调研走向符号化业务模型 。这篇文章进一步把场景选择和调研方法展开，重点回答一个更具体的问题：

如何把一个模糊需求，转化为值得建模、边界清楚并且能够验证的业务场景？

这一阶段的目标还不是画本体，也不是确定数据库字段，而是形成一张经过业务、数据和技术团队共同确认的“场景定义卡初稿”。

完整路径可以概括为：

具体任务与真实案例 → 事实、规则、判断和假设 → 候选机会 → 场景筛选 → 价值叙事 → 场景边界 → 场景定义卡初稿

这套方法并不是本体项目专属，任何严肃的系统建设都需要先理解业务。 区别在于，传统应用设计通常服务于一个相对明确的系统边界，而本体模型还要被跨系统数据治理、语义查询、规则验证和 Agent 共同复用。一旦在调研阶段把经验判断当成业务事实，把流程节点误认为对象状态，或者忽略规则的适用范围，错误就会继续传播到数据映射、语义约束和 Agent 行动中。因此，本体建模尤其需要在前置调研中消除语义歧义，为后续识别对象、关系、事件、状态、规则和证据边界建立可信输入。

业务调研不是向用户收集功能

很多调研从一句话开始：

你希望系统增加什么功能？

这个问题并不是完全不能问，但它只能收集用户已经想象出来的解决方案，无法保证团队找到了真正的问题。

同样是“增加一个订单预警”，背后可能是完全不同的需求：

• 管理者希望增加一张经营看板；
• 客户经理希望减少跨系统核对；
• 风控人员希望统一逾期判断规则；
• 数据团队希望解决合同、订单和审批信息无法关联；
• AI 团队希望从非结构化合同中提取交付条款。

这些需求使用相似的功能名称，却服务不同角色、改变不同过程，也需要不同的数据、规则和治理边界。

因此，业务调研真正要回答的不是“做什么功能”，而是：

谁在什么业务过程中遇到了什么问题，问题为什么发生，当前依赖什么信息和判断，工作方式需要如何改变，业务结果需要改善到什么程度。

场景一旦清楚，功能、数据、模型和接口才有共同边界。

调研开始前，先准备四类输入

业务调研不是临时找几个人开一场会。正式走查前，至少要准备四类输入。

在进入正式调研前，团队通常已经根据业务痛点锁定了一个初步问题域或任务范围。但它只是调研入口，不是最终确认的建模场景。前者用于控制调研范围，后者需要经过真实案例走查、价值判断和准入评估后才能定型。

一项具体任务

不要以“合同管理”“客户服务”或“设备运维”这样的大领域作为直接调研对象，而要收敛到一项能够走完的任务，例如：

• 识别订单履约逾期风险；
• 审查合同中的高风险条款；
• 判断设备异常是否需要停机检查；
• 核对案件材料是否满足审查要求。

任务越具体，越容易找到起点、终点、参与角色和验证结果。

一组真实案例

至少准备一个正常案例和一个异常案例。只有标准流程，没有例外案例，团队很容易把制度规定误认为业务真实运行方式。

案例应尽量保留当时使用的合同、表单、系统记录、聊天信息、审批意见和最终处理结果，避免完全依赖事后回忆。

一组关键角色

负责人能讲目标，一线人员能讲真实过程，业务专家能讲规则和例外，数据与系统人员能讲已有记录，风控或合规人员能讲权限和责任边界。

只访谈领导，容易得到理想流程；只访谈一线人员，又可能缺少制度口径和整体目标。

一份待验证问题清单

调研前可以提出假设，但不能把假设当结论。例如：

• 风险发现滞后可能是因为数据分散；
• 延期审批可能没有和订单正确关联；
• 合同交付日期可能主要存在于非结构化文档；
• 客户经理可能花费大量时间重复核对。

这些内容只是待验证问题。调研的任务是寻找证据、修正假设，而不是证明技术团队原先的判断正确。

第一步，跟着一项真实任务走到底

业务人员在会议室里描述的，通常是制度规定的标准流程。真正影响效率和风险的，却可能是跨系统查询、临时沟通、手工核对、经验判断、异常补救和反复确认。

调研可以组合使用四种方式：

• 跟岗观察（Shadowing）： 观察任务实际如何触发、信息如何流转和人员如何操作；
• 案例复盘： 围绕一件已经完成的真实任务，还原当时发生了什么；
• 流程走查： 从起点走到终点，确认角色、判断、交接和异常路径；
• 材料核对： 用制度、合同、记录和日志验证口头描述是否成立。

不要一上来让业务人员回答“有哪些对象、状态和关系”，而是沿着时间顺序追问：

• 什么事件触发了任务；
• 谁最先处理，之后交给了谁；
• 每一步查看、创建、判断或改变了什么；
• 信息来自哪些系统、文档、日志或人工沟通；
• 哪些节点需要查找、比对、解释或反复确认；
• 哪些判断依赖经验，依据能否说清；
• 出现缺失、冲突、超时或例外时如何处理；
• 谁确认任务完成，结果和修正是否留下记录。

以订单履约为例，不要只接受“订单新建后发货，超期就预警”这种概括，而要拿一笔真实且经过 脱敏 的异常订单继续追问：风险最早是怎么发现的？当时查看了哪个合同版本、哪个交付日期和哪条系统记录？延期审批保存在哪里？不同材料发生冲突时由谁确认？最终如何处置，修正结果是否回写并留痕？

只有沿着真实案例追到最后，团队才能分清哪些是已经发生的事实，哪些是制度规则，哪些依赖专业判断，哪些只是尚未验证的推测。

业务人员负责讲真实过程，业务架构师、产品经理或知识工程师负责从叙述中抽象结构。 不能把建模工作转嫁给业务人员，也不能让技术人员在会后凭访谈纪要猜测业务现实 。

第二步，区分事实、规则、判断和假设

一次业务访谈中，经常会混合四类不同信息。如果不加区分，它们很容易一起进入需求文档，最终被误认为已经确认的业务知识。

这四类信息进入后续设计的处理方式也不同：

• 业务事实： 寻找数据、文档、日志或人工记录作为证据，并建立数据映射；
• 制度规则： 记录规则来源、适用范围和例外，再决定由规则引擎、工作流或人工执行；
• 专业判断： 明确判断依据、上下文和责任角色，再判断 AI 可以辅助到什么程度；
• 待验证假设： 制定验证计划，明确样本、指标、数据来源和判断标准。

调研记录最好明确标注这四类信息，同时记录来源、提供人、发生时间和待确认问题。

例如，“这个客户经常延期”只是经验描述；“过去六个月存在三次经批准的延期”才是可核验事实；“因此本次也可以延期”则是一项需要规则和证据支持的判断。

本体建模需要的是经过确认的业务知识，不是把会议中出现的所有说法都结构化。

第三步，从业务摩擦中形成候选机会

业务调研的目的不是把现状记录得越详细越好，而是找到值得改变的关键节点。

候选机会通常出现在五类业务摩擦中：

• 信息分散，需要跨系统和文档反复查找；
• 相同内容被重复录入、比对和校验；
• 关键判断依赖少数人员的隐性经验；
• 异常发现太晚，已经错过低成本处理窗口；
• 人工修正和处置结果没有形成反馈。

例如，业务人员最初提出“需要一个订单智能问答”。沿着真实任务走查后，团队可能发现真正的问题是：客户经理每天需要跨合同、订单和审批系统核对交付日期、履约记录和延期审批，风险经常在客户投诉后才被发现。

这时得到的候选机会不是“建设智能问答”，而是：

帮助客户经理及时识别存在履约逾期风险的订单，汇总判断依据，并在人工确认后进入后续处置。

候选机会只说明值得继续分析什么，还不是项目承诺。

此前《如何选择业务场景》中所说的“价值机会点”，在这里对应候选机会阶段，用于概括值得继续分析的方向；候选场景通过筛选后，才进一步用价值叙事补齐角色、工作方式、基线、目标值和业务边界。

第四步，判断是否值得做、能不能做、是否需要 AI

本体驱动的数据治理不适合一开始就全域建模，更不应该为一个价值模糊的需求建设复杂 语义资产 。

如果调研后形成了多个候选场景，可以先使用此前《如何选择业务场景》中介绍的 痛点地图 ，按照业务影响和解决紧迫性排序。痛点地图解决的是“先分析哪个”，但排在前面并不意味着场景已经具备试点和建模条件。

进入准入评估后，每个候选场景至少要经过六项判断：

• 业务价值： 是否影响收入、成本、效率、风险、合规或客户体验；
• 闭环清晰度： 能否说清起点、关键判断、状态变化、结果和反馈；
• 证据基础： 是否存在可追溯的数据、文档、日志、制度和人工确认；
• 实施可行性： 关键数据是否可以访问，源系统是否支持必要集成，责任角色是否愿意参与，试点成本和周期是否可控；
• 结果可验证性： 是否能够建立当前基线、目标值和验收样例；
• 语义资产复用性： 能否沉淀可复用的对象、关系、状态、规则、数据映射或 Agent 能力。

其中还有一些不能被综合高分抵消的准入条件。如果关键证据无法追溯、责任人不愿参与、高风险动作没有人工确认、合规边界尚未明确，场景就不应直接进入试点。

同时还要单独追问：这个问题是否真的需要 AI？

如果输入已经完全结构化、判断规则确定、动作路径固定，系统集成、规则引擎或工作流通常比大模型更稳定。AI 更适合处理合同和审批意见等非结构化材料，完成语义提取、信息归并、冲突识别、证据汇总、解释生成和辅助判断。

在订单履约案例中，可以这样分工：

• 合同交付条款和延期说明的提取，可以由 AI 辅助；
• 工作日计算、逾期规则和状态流转，应由确定性机制执行；
• 证据冲突和重要例外，由业务人员确认；
• 正式预警、处罚或额度调整，受权限和审批约束。

一个场景可以同时包含数据治理、规则计算、工作流和 AI 能力，不必把所有环节都交给大模型。

是否需要 AI，决定的是能力实现方式，不直接决定这个场景是否需要本体建模。即使不使用大模型，只要仍然存在跨系统对象不一致、规则语义不清、业务事实缺少统一证据等问题，本体驱动的治理依然有价值。

第五步，用价值叙事确定目标

场景通过筛选后，先不要讨论页面、按钮和接口，而要用价值叙事建立共同目标。

价值叙事主要回答：为谁，在什么流程中，把当前工作方式变成什么目标工作方式，最终改善什么业务结果。

价值叙事公式

为了帮助【具体角色或对象】，在【明确业务流程或场景】中，把【当前低效、断裂或高风险的工作方式】转变为【目标工作方式】，并将【关键指标】从【当前基线】改善到【目标值】。

订单履约场景可以定义为：

为了帮助客户经理在订单履约监控中，把依赖人工跨系统核对、风险发现滞后的当前工作方式，转变为系统主动汇总交付和延期证据、提示疑似风险并由人员确认的目标工作方式，并将风险发现时长、漏查率和确认时长从试点前基线改善到共同约定的目标值。

价值叙事不是宣传口号，也不是把无法证明的收益写成精确 ROI。如果当前基线还不知道，就应先安排测量，而不是编造一个数字。

基线测量至少要关注四类信息：

• 一段时间内的任务量、发生频率和异常占比；
• 平均处理时长、等待时长和跨系统查询次数；
• 漏查率、返工率、改判率和异常发现时点；
• 人工投入、业务损失或风险后果。

每项基线还要记录统计周期、样本范围和数据来源。否则，即使写出了一个目标值，也无法判断场景实施后是否达到了约定目标。

一段合格的价值叙事还要能够约束范围：服务谁、发生在哪个流程、改变什么工作方式，以及什么结果不属于本期目标。

这里的“当前工作方式”和“目标工作方式”，描述的是业务价值变化，不等同于后续业务模型中的订单状态、风险任务状态等对象状态。

第六步，把场景边界写清楚

价值叙事解决“为什么做”，场景边界解决“这次究竟做到哪里”。

至少要确认六类边界：

• 目标角色： 谁使用结果，谁承担业务责任；
• 触发事件： 什么发生后进入场景；
• 结束条件： 达到什么结果后离开场景；
• 核心对象： 本期真正管理、判断和改变什么；
• 人工边界： 哪些判断和动作必须由人确认；
• 排除范围： 哪些对象、流程、动作和例外暂不处理。

边界不能只写“覆盖订单履约管理”。更具体的表达应该是：

场景从每日履约检查开始，到疑似风险被客户经理确认、排除或转人工复核结束。首期只覆盖交付日期明确、能够关联合同和交付记录的订单，不自动处罚客户，不自动修改信用额度，也不替代合同争议认定。

这样的边界才能决定后续需要建哪些对象、关系、状态和规则，也能防止试点在调研过程中不断扩张。

第七步，把调研结果沉淀为场景定义卡初稿

业务调研结束后，不应只留下访谈纪要和功能清单。更有用的交付物是一张场景定义卡初稿。

这里的对象、证据和规则都还是候选内容。场景卡的作用是建立建模边界，不是提前替代业务模型。

候选机会、筛选结论和场景定义也不一定需要三张独立卡片。更实用的做法，是让同一张卡逐步演进：调研阶段记录机会，筛选阶段补充准入结论，定义阶段补充目标和边界，进入建模前锁定版本并保留未决事项。

场景定义卡负责汇总结论，但不能替代原始调研记录。事实来源、规则依据、冲突证据、待决问题和确认记录，应保留在配套的调研证据与问题台账中，并与场景卡版本关联。

一次业务调研应该如何组织

场景调研不能由产品经理独自完成，也不能让技术团队根据访谈纪要自行推断。

至少需要业务负责人、一线人员、业务专家、数据与系统负责人、风控或合规人员，以及负责抽象和记录的业务架构师、产品经理或知识工程师参与。

一次有效的业务调研可以分成三个阶段：

1. 调研前： 确定具体任务、真实案例、参与角色、已有材料和待验证假设；
2. 调研中： 沿时间线还原正常与异常案例，区分事实、规则、判断和假设；
3. 调研后： 整理候选机会和场景定义卡，标记证据来源、冲突、待确认问题及责任人。

不要试图在第一次会议中同时完成场景选择、业务建模、数据映射和技术设计。调研完成后，应先让业务负责人确认价值和范围，再进入下一阶段的业务建模。

什么情况下可以进入业务建模

前面的六项判断解决“这个场景是否值得做、能不能做”，下面的七个问题解决“调研成果是否已经准备好进入业务建模”。前者是场景准入评估，后者是阶段成果验收。

场景定义卡是否具备进入建模的条件，可以用七个问题检查：

1. 是否明确到一个具体角色和一项真实任务；
2. 是否有正常案例和异常案例作为依据；
3. 是否说清触发事件、结束条件和排除范围；
4. 是否形成可以验证的价值叙事、基线和目标指标；
5. 是否找到关键业务事实可能依赖的数据和制度证据；
6. 是否初步分清 AI、确定性规则、工作流和人工的责任；
7. 是否记录仍未确认的问题、责任人和处理计划。

如果这些问题仍然只能用“后面再讨论”“让大模型自己去猜”或“先把功能做出来看看”来回答，就不应该急着画本体。因为本体不会自动消除业务模糊性，反而可能把未经确认的假设固化为可查询、可推理甚至可执行的语义。一旦这些语义被数据映射、规则机制和 Agent 共同复用，错误还会沿着判断和动作链继续传播。

小结

本体建模前的业务调研，不是向用户收集一份功能愿望清单，也不是先看表字段再反推业务。

更完整的方法是：准备具体任务和真实案例，沿实际工作过程发现业务摩擦，区分事实、规则、判断和假设，再判断场景是否值得做、能不能做、是否需要 AI，最后用价值叙事和明确边界形成场景定义卡初稿。

业务调研的阶段成果，不是“用户想要什么功能”，而是“哪个角色在什么业务边界内遇到了什么问题，这个问题为什么值得建模，以及后续业务模型需要解释和验证什么”。

场景清楚之后，下一步才是从真实案例中提取对象、关系、事件、过程、状态、规则、证据和行为，把场景定义转化为可验证的业务模型。