现场访谈与业务建模

1. 访谈不是收集功能愿望

本周接到三种说法：IT 认为会员数据完整，运营认为分群结果不可信，门店认为总部活动不符合本店情况。FDE 的任务不是判断谁更懂业务，而是将各自的说法拆成可验证命题。所谓“完整”可能指每天有数据，“可信”可能指人群中没有已退订会员，“适合”可能指门店无法执行某种活动。三个角色实际上在回答不同的问题。

访谈结束时，你应获得一份可追溯的事实账本、一张角色与责任地图，以及第一版本体草图。会议纪要只是材料，不是最终交付物。将一小时录音压缩成十条摘要，仍然可能遗漏后续工程最需要的时间范围、异常处理和数据来源。

2. 如何准备一场有效的现场访谈

先写访谈目标。例如“弄清运营如何判断沉默会员，以及分群在哪一步不可信”，而不是“了解会员业务”。准备待验证假设、需要观看的实际操作和希望取得的授权样例。访谈前向对方说明记录用途；如需录音或转录，应先确认必要同意和使用范围。

建议采用一个 40 分钟的教学安排：前 5 分钟确认角色与任务；中间 20 分钟复现最近一次完整操作；接着 10 分钟检查例外与失败；最后 5 分钟复述你的理解，并确认还缺什么证据。这是组织练习的方法，不是所有客户访谈的固定时长。

先开放式提问，再封闭式核实。不要为了证实自己的方案而只问支持它的问题。对“从来没有发生过”的情况，要追问记录方式；未被记录不等于没有发生。

3. 角色地图要记录利益与责任，而不只是职位

一个人是否支持项目，往往取决于项目给其增加了什么责任、改变了什么工作。运营可能希望更快生成活动，却担心错误人群导致投诉；门店希望少填表，却需要解释业绩波动；IT 可能欢迎统一接口，但不愿接手一个无人维护的脚本。

角色地图建议记录：参与角色、负责决定、关心的指标、当前证据、投入时间、必须参加的评审节点。对动机的解释应标注为假设并向本人核实，不要推断私人特征或把异议者简单归为“阻力”。

客户侧至少覆盖业务负责人、实际操作人员和数据/IT 负责人；财务或指标核算角色应在第 3 周范围冻结前参与。产品侧也要覆盖标准产品研发和负责验收承诺的角色。访谈人数不是质量指标，关键是重要决策和冲突是否有人解释、能否找到独立证据。

4. 建立事实账本，保留冲突

使用四种状态：已核实事实、单方陈述、解释或假设、尚待验证。模型可以帮助抽取，但不能自动把后两类提升成第一类。

以上都是合成示例。真实账本应增加来源位置、记录时间、确认角色和访问级别，但公开作品只保留匿名角色及合成证据。A 与 B 的说法冲突时，可以要求两人针对同一份冻结样本分别计算，比较中间结果。不要将两人的结论平均，或直接选择职位更高者的结论。

5. 从业务叙述提取 Object、Link 和 Action

“运营选出 A 店近期未复购的会员，确认预算后发一张券”至少包含 Member、Store、Order、Campaign、Coupon 五类对象；会员归属门店、订单关联会员、活动生成券等关系；选择人群、提出方案、发券等动作。注意“近期”“归属”“确认”都是待定义的业务语义，而不是自然语言里已经足够明确的词。

第一版配置不追求完整。它的价值是让后续访谈和工程有一个可修订的共同对象。下面是自编 JSON 设计片段，需在第 5 周补充键、关系约束、动作前后置条件和测试。

{
  "version": "0.1",
  "objects": {
    "Member": {"key": "canonical_member_id", "evidence": ["F-01"]},
    "Order": {"key": "source_order_id", "evidence": ["F-02"]}
  },
  "links": [
    {"from": "Order", "to": "Member", "type": "purchased_by"}
  ],
  "open_questions": [
    "退货是否改变最后一次有效购买时间？",
    "跨店购买时，运营可见范围如何确定？"
  ]
}

不要把自然语言直接转成生产 SQL 后执行。抽取结果必须有来源、字段类型和未知项。特别是“所有会员”“全渠道”“历史订单”等宽泛表达，可能扩大访问范围或计算口径，需要显式确认。

6. 如何使用模型辅助整理访谈

输入只使用允许处理的转录片段，尽量先去除不必要的身份信息。要求模型按固定结构提取原句、对象、动作、口径、假设和待确认问题，并允许返回空值。一个有用的约束是：“每项业务事实必须给出对应片段 ID；没有直接依据的内容放入 hypotheses，不补全为事实。”

人工复核三个重点：是否漏掉否定和例外；是否把不同角色的口径合并成一个规则；是否把未来愿望写成现状。保存抽取配置版本和人工修改记录，使后续本体变更能追溯到业务原因。内部记录不必保存完整敏感内容，可以保存受控资料的位置和引用 ID。

这个步骤的质量可用小样本人工标注集检验：抽取的事实是否有出处，重要约束是否遗漏，哪些条目需要人改。摘要读起来流畅并不是抽取正确的充分证据。

7. 案例研读与反例练习

阅读 AIG 核保工作流案例。资料接收、字段提取、交叉核对和专家判断承担不同工作。AIG 的公开材料描述了以数据组织与业务本体支持核保，再向理赔扩展的路径；本周练习把这种分工转成现场访谈与字段责任表。

请一位同学扮演专家，用合成资料演示一次审核：在哪一步找原文、何时补件、哪些信息冲突会阻止判断？FDE 不只记“希望更快”，还要保存高风险字段的定义、证据位置、错误后果与核验角色。例如两份附件数字相同但币种不同，应保留冲突并提出补证问题，不能自动合并总额。

提交资料流图、三项关键追问和一个反例。通过条件是每个问题都能影响方案选择，每个关键字段都有可核验来源与明确责任人。

反例练习：业务说“只给活跃用户发券”，IT 说“活跃字段每天更新”。你查看定义后发现一个是最近购买，一个是最近登录。正确动作不是把字段重命名为 active，而是保留两个概念、记录用途，在策略里明确使用哪一个并给出反例。

8. 必做作业、思考与验收

必做：完成业务、使用者、IT 三类角色的模拟或获授权访谈；提交至少一条被证据推翻或修正的假设；输出事实账本、角色地图和可解析的本体 JSON。若没有真实访谈对象，可由同学依据明确的角色脚本演练，但必须标为模拟，不得包装成客户访谈。

思考：如果使用者当面说愿意采用，却在演示后继续用旧表，你还需要观察什么？从额外操作、信任、考核、异常处理和管理要求中提出可验证解释，避免只归因为“用户不懂 AI”。

进阶：编写 JSON 校验，要求每个对象和动作至少关联一个证据 ID；为不存在的证据、缺键和重复定义各写一个测试。

验收要求：每条已核实事实有来源；冲突未被偷偷合并；业务术语能够映射到对象或规则；未知项有验证动作；原始记录和公开作业的访问范围被区分。另一位工程师应能据此列出待开发接口，而不需要重新听完整场会议。