销售团队已经在报表里统计试驾、下订和交付。到了给 Agent 配置业务语义时，却又要解释一遍什么叫客户、什么叫订单、什么叫成交。此前积累的模型、指标和 SQL，能不能直接用起来？
可以从它们开始。已有数据说明系统怎样记录业务，查询逻辑说明团队怎样计算结果；但两者都需要与业务人员确认的定义核对。逆向建模的价值，是把这些依据整理成可以审阅的候选模型，减少从空白开始的工作。候选模型能否用于业务判断，要靠对象归属、字段映射和已知记录逐项检验。
沿用前文的汽车销售问题，本文展开一条可操作的路径：先选定要回答的问题，再限定数据范围；生成候选定义后，核对它的依据，最后通过已知记录检验语义。 产品步骤以 WinNexo 的逆向建模指南为依据，汽车销售记录用于说明审阅方法，不代表一次已经完成的客户运行。
企业本体建设需要把对象、关系与业务规则表达清楚。逆向语义建模可以帮助整理已有数据中的定义线索，生成的语义模型仍需与团队确认的含义逐项核对。
希望先了解现有产品怎样支持本体语义建设，可以查看 WinNexo 的本体构建与语义建模介绍。本文进一步展开候选定义如何生成、审阅与检验。
先选一个问题，再决定要读哪些数据
「把销售数据库建成业务模型」很难验收。「找出已经试驾、尚未下订的购车机会」则可以检验，因为对象、节点和结果范围都能说清楚。
围绕这个问题，第一轮只需整理购车机会、参与人、体验活动和订单等相关数据。产品配置、报价或交付记录，可以随着任务需要再加入。这样做也让审阅更集中：团队可以先确认一条关键链路，而不用同时处理所有表的歧义。
生成前，需要把第二篇已经确定的定义写进业务背景。家庭作为客户单元，个人以不同角色参与一次购车机会；重复试驾仍可能属于同一机会；本文的教学下订条件，是订单已确认且订金已到账。还要补上试驾的有效条件、观察截止时点，以及取消订单如何处理。
这里有一个容易忽略的区别。团队今天希望采用的定义，未必等于旧报表一直使用的计算方式。旧 SQL 可以作为核对依据，不能因为它已经运行多年，就把其中的统计口径自动视为本轮业务定义。
把表结构、计算逻辑和业务背景放在一起看
表结构能告诉我们有哪些字段、类型和关联键。它通常不能完整回答「订单状态为某个值，是否已经收到订金」。这些含义可能写在指标定义、查询条件或业务说明里。
因此，逆向建模的输入应围绕同一问题组织。表结构提供可查询的字段，已有模型和指标提供业务含义，SQL 与血缘提供计算及来源线索，业务背景说明此次采用的定义。各项材料是否可取得，要以当前数据源和实际读取结果为准。
例如，试驾记录里可能同时有参与人标识和机会标识。只看参与人字段，很容易把一次家庭试驾拆成多个客户行为。核对业务模型和关联条件后，才有机会判断统计单位应该落在哪一层。字段名中的「客户」也需要进一步追问：它指联系人、合同购买方，还是客户家庭？
输入越多，不一定越准确，关键是材料之间能否互相核对。若业务说明要求按购车机会统计，而 SQL 按联系电话去重，这个差异应成为审阅项，不能在生成时悄悄合并。
准备进入具体操作时，可以查看候选语义的审阅与保存指南，核对定义、生成依据和不同模式的保存路径。
选择生成方式，也是在选择变更范围
WinNexo 的逆向建模提供三种方式。已有模型只需补充新表或调整局部定义时，可以选择更新当前语义模型；需要重新整理整体定义时，可以选择重建；准备切换数据库时，可以为目标数据库生成备用语义模型，形成独立的 YAML（一种结构化文本配置格式）。
三种方式的差异会影响审阅重点。更新时，要检查所选变更是否恰好覆盖此次任务；重建时，要查看完整结果，避免已有的重要定义被遗漏；备用模型要核对目标数据库，不能因为语义名称相同，就默认它适用于当前环境。
使用 Dataphin 辅助逆向建模前，还要确认应用连接、数据源关联和相应凭据已配置。数据源关联用于建立对应关系，本身不会立即导入数据或改变模型。两侧授权也要分别完成：能看到某个业务对象，不等于已经具备读取源端数据的权限。
这些准备工作影响的是生成所依据的材料。审阅时最好同时查看本次输入摘要，确认选中了哪些 Schema 和表，提交了哪些业务背景，而不只看生成结果是否像一个完整模型。
图：候选生成与正式语义之间需要经过审阅、校验和记录检验——图示为更新或重建当前模型后的审阅与验收路径，不表示各环节自动串行执行。
审阅时，先看能否指向正确的记录
一个候选对象叫「购车机会」，并不意味着它已经表达了购车机会。需要检查它能否稳定地找到同一笔需求，以及相关活动和订单是否归属正确。
WinNexo 的结果审阅页可以查看定义、生成依据和 YAML。审阅应顺着业务问题展开，优先处理会改变查询结果的地方。
先查对象身份。 机会标识是否独立于电话号码？同一家庭第二次购车，能否建立新的机会？否则，历史成交可能混入本次跟进。
再查关系与角色。 两个人参加同一次试驾，应指向同一机会；联系人、合同购买方和预期用车人可能不同。不能把某个人在一次机会中的角色，固化成他所有购车活动中的永久身份。
接着查字段映射和节点条件。 展示名称相近的字段，未必来自正确的物理列。订单已创建、订金已到账、订单已取消，也需要分别对应可核对的记录。候选定义若只保留一个「成交状态」，就可能丢失这几个业务差异。
最后查时间。 「当时尚未下订」和「现在尚未下订」会返回不同的机会。历史事件需要保留发生时间，当前状态需要明确查询时点。若分析试驾后的转化，还要说明是哪一批试驾机会、观察多久。
下面三条教学检查，可以直接用来设计审阅样本： 1. 一个机会发生两次试驾，机会数仍应为一； 2. 两位家庭成员参加同一次试驾，不应产生两次活动； 3. 一笔订单确认并收取订金后又取消，不能只剩一个无法还原过程的最终状态。
遇到冲突时，应回到产生冲突的材料。字段映射错误，就核对表结构；统计对象不同，就核对业务定义和查询条件；关系依据缺失，就请业务负责人确认。仅仅把 YAML 改得语句通顺，不能解决这些问题。
图：WinNexo 已有候选的审阅界面——示例仅使用产品分类的表结构生成，内部库名与物理表名已遮挡；截图展示候选定义与生成依据的核对方式，不代表汽车销售模型的实测结果。
保存和发布之后，还要用已知答案检验
更新或重建当前模型时，审阅页支持将结果保存为草稿，也可以导入选中的定义并启动语义校验。校验通过后的发布，需要另行确认。草稿、导入、校验和发布是不同状态，不能把「保存成功」当作整个建模工作已经完成。
备用模式则将定义保存为目标数据源图谱（为该数据源专用的语义模型）。之后在数据源配置中选择对应备用图谱，完成语义校验并确认发布，才会应用模型并切换数据源。应在切换前核对目标库及定义，避免把准备好的备用模型当成当前已经生效的模型。
语义校验用于发现模型能否按产品规则成立。业务验收还要回答另一个问题：模型是否表达了团队已经确认的业务含义。
可以选取少量经过业务人员核对的机会记录，包含重复试驾、多人参与、取消订单和观察窗口外下订等情况，分别写出预期归属及统计结果。再用相同的问题查询，检查返回的对象、关联记录、口径和来源。即使结果数量正确，也要查看是否恰好返回了那几条应当出现的机会，避免两个错误相互抵消。
若查询与预期不一致，先定位是源数据、语义定义还是查询使用的问题。把修正及复查结果记下来，再决定是否将这套定义用于业务任务。后续字段、口径或数据源发生变化时，同一组样本还能继续用于回归检查。
逆向建模节省了整理候选定义的工作，业务负责人仍需确认对象和节点，数据人员仍需确认映射和来源。两者共同审阅的结果，才有可能成为 Agent 可以持续使用的业务语义。
具体操作可继续阅读 WinNexo AI 逆向建模使用指南。希望评估已有数据能否用于业务语义建设，可以通过瓴羊官方联系入口说明数据来源和目标任务，并咨询 WinNexo 相关方案。
继续阅读：07 本体在汽车销售中的应用：从试驾记录到下一次有效跟进
回顾：03 Dataphin与企业本体：业务语义怎样落到数据模型与知识图谱中？· 05 从本体语义到业务行动：Dataphin × WinNexo 的产品架构
