第二章 进场诊断

2.4 从访谈到本体草图

承前：前三节你完成了访谈、画了干系人地图、做了交叉验证——现在手上有十几份纪要、一堆经过验证的事实、还有一张"三口径"矛盾清单。这些材料如果不加工，两周后就是一堆死文档。诊断周的最后一步，是把散落的语言材料压缩成一张本体草图（Ontology Sketch）：客户业务里的对象是什么、关系是什么、动作是什么。这张草图是后面所有工作的地基——W3 的需求定义、W4 的数据接入、W5 的本体专题，全都从它长出来。这一节讲提取方法，并带你为青禾优选画出会员、订单、门店、优惠券的本体草图。

---

2.4.1 为什么先要本体草图

先说清楚"本体"（Ontology）这个词。它在哲学里讨论"存在是什么"，在工程里朴素得多：一套对业务对象的正式定义——有哪些东西、东西之间什么关系、对东西能做什么动作。

为什么它是地基？因为 AI Agent 的一切行为都挂在本体上。你的标准 Agent 底座里，模型调用、会话、工具注册、日志这些是现成的；但 Agent 要回答"给这个会员发张券"，它必须知道：会员是什么（一个有 ID 的实体，不是一段备注文本）、券和会员怎么关联（谁持有、谁核销）、门店能对券执行什么动作（发放？核销？）。没有本体，Agent 的每句话都是猜的。

这个思路最成熟的工业实践是 Palantir Foundry 的 Ontology：对象类型（Object Types）、链接类型（Link Types）、动作类型（Action Types）三层——把企业的实体、关系和可执行变更全部显式建模，让分析和应用都挂在同一套语义上（据 Palantir 官方文档）。我们 FDE 进场第一周画的本体草图，就是这套东西的"低保真版"——先不追求完备，追求快速抓住骨架。

为什么用"草图"这个词？因为 W2 的目标不是数据字典。数据字典是数据团队花一个月做的东西；FDE 在五天里要的是一张手绘级别的图，能支撑 W3 的需求讨论就够。像建筑设计师先画草图再画施工图——草图的价值在快、可改、方便和人讨论。

从访谈材料到系统落地的链条

访谈纪要 ──→ 本体草图 ──→ 需求定义 ──→ 数据接入 ──→ 生产本体
(W2)        (W2末)      (W3)        (W4)       (W5+)
 原料         骨架        边界        血肉        硬化

        ↑ 本体草图是分水岭：
          之前是"听客户说"，之后是"跟客户对"

---

2.4.2 提取方法：名词=对象，动词=动作

本体提取的基本语法简单到可以用一句话说完：把经过验证的业务陈述拆开——名词是候选对象，动词是候选动作（或关系）。

拿青禾访谈里一句真实的（经过交叉验证的）话做例子：

"收银员在收银时看会员的手机号，查到会员就积分，然后用券抵扣。"

拆解：

• 名词：收银员、会员、手机号、积分、券 → 候选对象
• 动词：查（会员→查询动作）、积分（交易→积分事件）、抵扣（券→核销动作）

再补一句店长的话："总部每月给各店发一批券，我们店里核销。"

• 名词：总部、店、券 → "店"升格为对象"门店"，总部是组织，暂不入本体（见下文粒度规则）

连续拆几十句，你会得到一大坨名词动词——这时需要三条过滤规则来收敛：

**规则一：只留业务实体，剔除角色和组织。**收银员、店长是"人扮演的角色"，不是业务对象——但注意，有些系统里"员工"是实体（有工号、有权限），那时才建 Employee 对象。判断标准：**它有没有独立的数据记录和生命周期？**有就建，没有就先剔除。

规则二：动词分两类——改变状态的才叫动作。"查询"不改变任何东西，只是读取（对应 Agent 的工具调用里的 query 类）；"核销"改变了券的状态（未使用→已核销），才是本体意义上的 Action。这个区分在 Palantir 的 Ontology 里同样严格：Action 是"对对象、属性、链接的真实变更，提交后反映到所有应用"（据官方文档）。W5 讲语义层时会展开，这里记住原则：状态变更走动作，受权限管控；纯读取走工具，只要授权。

**规则三：矛盾的说法先挂起。**运营经理说"券是会员维度的"，店长说"券是门店维度的"——两个说法对应两种建模（券挂在 Member 下 vs 挂在 Store 下）。别急着裁决，在草图上把两种候选关系都画出来，标注"口径冲突待 W3 定"。本体草图允许并存未决问题，这正是它比直接写 ER 图高级的地方：未决冲突显式可见，而不是被建模者悄悄拍板。

---

2.4.3 青禾优选本体草图：会员/订单/门店/优惠券

把访谈材料全部拆完、过滤完，青禾优选的核心骨架是四个对象、一组关系、三类动作。画出来：

青禾优选 · 本体草图 v0.1（W2 诊断产物）

┌──────────────┐         ┌──────────────┐
│   会员 Member │         │ 门店  Store   │
│──────────────│         │──────────────│
│ member_id     │◄───────│ store_id      │
│ phone         │ 归属    │ 商圈/客群标签  │
│ (注意：双轨ID) │ (多对一) │ (备注字段隐患)│
└──────┬───────┘         └──────┬───────┘
       │ 持有                    │ 发放批次
       ▼                         ▼
┌──────────────┐         ┌──────────────┐
│优惠券 Coupon  │         │ 订单  Order   │
│──────────────│◄─核销于─│──────────────│
│ coupon_id     │         │ order_id      │
│ 面额/规则      │         │ member_id  ◄──┼──→ 关联会员
│ 状态:未用/已核 │         │ store_id   ◄──┼──→ 关联门店
└──────────────┘         └──────────────┘

动作（Action，改变状态）：
  ① 发放券  ：运营/门店 → Coupon.状态=未使用
  ② 核销券  ：门店收银 → Coupon.状态=已核销 + Order.优惠金额
  ③ 积分变动：交易触发 → Member.积分余额

【未决冲突】券的主体归属：Member 维度(运营口径)
                     vs Store 维度(门店口径) → W3 定
【已知数据坑】Member.member_id 新旧双轨；
             Member.标签 存于自由文本备注

逐个对象讲这张图里值得注意的设计判断：

会员（Member）：草图的灵魂对象，也是坑最深的一个。两个已验证的事实直接写在图上——ID 双轨（新旧系统两套主键，去重靠手机号）、标签无结构（收银员手工写备注）。注意草图阶段不需要解决这两个坑，只需要标注它们。这两个标注会在 W4 变成数据清洗任务，在 W5 变成会员对象标准化设计。诊断的价值就在于把地雷提前插旗。

门店（Store）：看起来简单，但注意"商圈/客群标签"属性——店长的核心抱怨（"总部的券和我的客群不匹配"）说明这个属性目前质量极差或根本没被用于发券决策。它是后续"智能发券"能力的抓手。

优惠券（Coupon）：本项目的关键对象——北极星指标（复购率）的主要干预手段就是它。状态机很轻（未使用→已核销/过期），但归属关系挂着 W3 要裁决的冲突。

订单（Order）：连接会员和门店的枢纽。复购率的计算最终落在"同一 member_id 在时间窗口内出现于多少笔 Order"——注意这句话里藏着的整个诊断链条：member_id 双轨没解决之前，复购率在数学上就是不可计算的。这就是 W2 拆"三个会员数"和本体设计环环相扣的地方。

---

2.4.4 映射到标准产品本体的扩展接口

你带的不是白纸——你厂商的标准 Agent 底座已经有自己的产品本体（会话、工具、trace、评估这些概念是现成的）。客户本体草图不是另起炉灶，而是映射 + 扩展到产品本体上。

映射逻辑分三类：

客户本体元素	映射到标准产品本体	说明
业务对象（会员/券/订单）	扩展实体（自定义 Entity）	走底座的实体注册接口，声明属性与主键
状态变更（发券/核销/积分）	工具注册（Tool Registry）	每个动作注册为一个工具，带权限与审计
只读查询	查询工具（query/read 类）	同样注册，但走只读授权通道

这样做的好处：Agent 的所有动作自动获得底座现成的日志、trace、评估接口——你在 W9 生产硬化时需要的可观测性，W2 这一步的规范映射就埋好了。反过来的坏处也直白：跳过映射、把客户业务硬编码进 prompt，短期快、长期每一次业务变更都要求你改提示词——这是 FDE 最常见的返工来源。

映射时还有一条纪律：客户口径优先于产品默认。比如你们产品默认的"用户"概念和青禾的"会员"有重叠，不要拿产品默认去覆盖客户语义——扩展接口的意义就是让客户本体保持第一公民地位。Palantir 的 Ontology 之所以被大企业接受，核心原因也是这一点：本体反映的是客户的业务现实（对象、关系、动作），平台是挂载方而不是定义方（据 Palantir 官方文档）。

---

2.4.5 LLM 辅助提取 + 人工校验工作流

五天访谈产生十几份纪要，手工拆名词动词要一整天。这正是 LLM 的用武之地——但要用对姿势。工作流是三段式：

LLM 辅助本体提取工作流

访谈纪要(已脱敏)
    │
    ▼ ①LLM 批量抽取
 候选实体/关系/动作清单（机器产出，噪音大）
    │
    ▼ ②人工过滤
 用三条规则过滤：有无独立生命周期？
                动词改不改状态？冲突挂起？
    │
    ▼ ③人工对齐
 和客户方懂行的人过一遍草图
 （他们能一眼看出你漏了什么）
    │
    ▼
 本体草图 v0.1 → 进 W3 需求定义

第①步的提示词骨架大致是："你是数据建模助手。从以下访谈纪要中抽取候选业务实体（名词）、候选动作（动词，区分状态变更与只读）、以及实体间关系。输出为表格，每条标注来源句子的编号。不要合并、不要猜测、只做抽取。"——最后一句是关键：抽取阶段要 LLM 当搬运工，不当建模师。让它做合并和判断，它会把不同口径的东西"聪明地"捏成一个，恰好毁掉你 2.3 节辛苦分离出来的矛盾信息。

第②步人工过滤是 FDE 不可外包的环节——三条过滤规则上一节讲过，此处的判断力（"总部该不该入本体""积分是属性还是事件"）是 FDE 的核心专业价值。

第③步最容易被跳过但最重要：拿着草图回去找客户校对。找个周五下午，把草图投在屏幕上，请运营经理和 IT 负责人各看二十分钟。两个收获：a) 他们会指出你漏的对象（比如"退货也是订单的一种，你们没画"）；b) 这个动作本身在建立信任——客户第一次看到自己嘴里说出的业务被认真地图画下来，"这个厂商在听我们说话"的感觉是后面所有协作的资本。

这套"LLM 起草、人工校验"的分工，是 AI 时代 FDE 工作方式变化的缩影：Anthropic 的 Applied AI 工程师自己就是第一批把 Claude 用进交付流程的人——他们驻场做方案、写评估、跑访谈分析，全程与 Claude 协作（据 Anthropic 官方披露）。工具换了，但判断责任不换：草图上的每一个对象签名，最终都得是人签的。

---

2.4.6 要点总结

• 本体草图是 W2 诊断的压缩产物和 W3-W5 的地基：定义业务对象（名词）、关系、动作（动词），像建筑草图一样追求快、可改、可讨论
• 提取语法一句话：名词=候选对象，动词=候选动作；三条过滤规则——只留有独立生命周期的实体、只有状态变更才算 Action、矛盾口径显式挂起不悄悄裁决
• 青禾四对象骨架：会员（双轨 ID+备注标签两个地雷插旗）、门店、优惠券（归属冲突留给 W3）、订单（复购率计算枢纽——ID 不通则北极星在数学上不可计算）
• 客户本体通过扩展接口映射到标准产品底座：对象走实体注册、动作走工具注册，自动继承日志/trace/评估；客户口径优先于产品默认
• LLM 辅助工作流三段式：LLM 只做抽取不做判断（保护矛盾信息）→ 人工三条规则过滤 → 拿草图回去和客户校对（同时收获信任）

---

参考资料

• Palantir Foundry Ontology 官方文档：Overview — 对象类型/链接类型/动作类型三层本体的权威定义
• Palantir Foundry：Action Types — Action 的严格定义：对对象/属性/链接的真实变更，提交后反映到所有应用
• Palantir Foundry Ontology 产品页 — 本体作为企业操作系统语义层的整体设计理念
• Building a new enterprise AI services company - Anthropic — Applied AI 工程师与客户共建方案、长期支持客户的驻场模式
• Novo Nordisk Claude Code case study — Anthropic 官方案例：驻场式协作中"人与 AI 协作交付"的实际形态