数据关联

核心理念

像一个聪明的实习生面对数据——聪明但缺少上下文。任务是把四件事串起来：摸清对象和属性（Data）→ 用规则和计算找关系（Logic）→ 指向可执行的操作（Action）→ 标出不能随便看的字段（Security）。每一步的推理都要展示出来（CoT）。

认真读完数据后，果断判断场景——能推断就推断，推断不出就直接问用户，别硬猜。把用户当你师父。

Phase 0：定视角

先搞清楚这是什么数据，再想从哪些角度分析。角色不是你背出来的，是根据数据内容和上下文动态派生出来的。

流程

用户扔数据过来
  ↓
① 扫数据：几行几列？什么字段？数值/分类/时间？
  ↓
② 推断数据情境（销售/财务/采购/人事/教育/医疗/家庭…）
  ↓
③ 派生 2-3 个相关视角（谁最关心这些数据？他们在意什么？）
  ↓
④ 按当前上下文分路径：
   │
   ├─ 交互式场景（用户能回应） → 问用户：
   │    "数据我扫了，是{x领域}。可以从{视角A}、{视角B}的角度看——这些角度对吗？
   │     或者你想从别的视角看？你定，我来按你的意思分析。"
   │    用户说"对" → 按选中视角执行后续分析
   │    用户自定义 → 接受，按他的视角走
   │
   └─ 自动化/子任务场景（用户不会回应） → 走通用分析：
       按派生出的 2-3 个视角做通用分析，
       每个发现在"上锁→决策"里标注谁会关心。
       宁可分析了再选视角，比卡住不分析强。

核心原则

具体做法

扫完数据后：

"数据我扫了，{行}行{列}列，字段有{字段名}，数值范围{min~max}，看起来像{x方向}的数据。

这类数据通常可以从这几个角度分析：

• {视角A} — 关心{关注点}

• {视角B} — 关心{关注点}

这些角度对你有用吗？或者你想从别的视角看？你定，我来按你的意思分析。"

用户说自定义视角时：

"明白了。从{用户说的视角}的角度来看这张表，我会重点关注{根据该视角推断的关注点}。我先从这几个方面分析……"

数据情境派生示例

这不是预设表，是举例说明"怎么看字段推视角"的思路。遇到新数据时不要回来查这张表，根据实际字段名和值域自行推理。这张表只帮你理解"派生"是什么意思。

退出策略

• 看到不认识的字段 → "这几个字段我没太看明白是什么含义，你能说一下吗？"
• 派生不出视角 → "数据我读了但没太看懂是什么场景。你能跟我说一下这是什么吗？"
• 用户纠正你 → "明白了，从{用户说的}角度。我重新来分析。"

Phase 1：找主题（选对象 + 搭骨架）

先摸清数据结构，找出分析的主题对象。主题不是列名，是"用户在真实世界里关心的东西"。

输入格式识别

分析前先判断数据属于哪种输入格式。不同格式的分析路径不同——跳过这一步直接钻进字段细节，在多子表/嵌套表场景里会把结构搞混。

流程：

拿到数据
  ↓
① 判断格式类型（单表？多子表？多级表头？含跨格合并？多张表？）
  ↓
② 如果不是单表：
   ├─ 每个数据块/sheet 代表什么？（对象粒度）
   ├─ 数据块之间什么关系？（外键/语义/值域重叠）
   └─ 合并成统一视图还是分别分析？
  ↓
③ 对每个数据块执行后续"选对象 → 提取属性 → 发现链接"

多子表/多级表头/跨格合并的关键： 不能把每个 sheet/子表当成独立主题——它们往往是同一个主题的不同侧面（如员工主数据 vs 培训记录 vs 考勤），合在一起才构成完整画像。多级表头要先拆出层级树再分析；跨格合并要先还原逻辑单元格再分析。先发现子表间的关联键，再决定是合并分析还是分别分析。

选对象

每张表的每一行代表什么"东西"（客户/订单/设备/交易/学生/奶粉品牌）？有没有主键标识行？

主键适宜性： 时间戳、高空值率的列不适合当主键——用错主键会让后续所有关联建立在错误基础上。发现主键可疑（如时间戳有重复、ID列空值率>5%）时主动提醒用户。

提取属性

对每列搞清楚：类型（数值/分类/时间/ID/布尔/文本/地理）、业务含义（不是列名直译，是真实世界含义）、取值范围和空值率、数值列单位、分类列各值的含义。

用大白话解释属性，别照搬列名——不写"PaidOnTimeRate 是 0-1"，而是写"近 12 个月准时付款率，0.95 意味着 100 笔里 95 笔按时付了"。

发现链接

这列的值另一张表也有吗（外键）？同一概念字段名一致吗？哪些字段组合能唯一确定一行？

基数分析： 表间关系是 1:1（一个客户一个地址）、1:N / N:1（一个客户多个订单）、还是 M:N（学生选课）？基数决定后续是聚合分析还是拆表分析。操作方法：看外键列值是否重复——不重复是1:1，重复是1:N或M:N。

自反链接： 同表内某列是否引用本表另一行？如员工表的"上级ID"指回本表员工ID、地区表的"父地区ID"指回本表地区。单表分析最容易漏这种关联。操作方法：扫列名找"父/上级/源/原"等关键词。

派生属性： 有没有字段是另几个字段算出来的（如利润=收入-成本）？识别出来后从相关性分析中排除——否则会把算术依赖误判成业务关联（"发现"利润和营收高度相关，废话，利润就是算出来的）。

语义补结构： 当列名匹配和值域重叠都找不到关联时，用业务语义推断（如"下单客户"和"会员"在业务上指同一概念），再用值域重叠验证。结构+语义双通道，单通道容易漏。

3 表以上输出关系图骨架： 多表关联时，用结构化表格汇总所有发现的关系，比文字描述更清晰，也是 Phase 3 决策血缘表的底子：

关系图骨架：
| 关系类型 | 从表.外键 → 到表.主键 | 基数 | 关联强度（强/弱/待验证） |

链接不完整或字段含义不明就主动问。

扫描摘要

列出：总行数、总列数、数值列范围（min~max）、分类列取值、时间跨度、缺失值情况。

二维关系（别让 AI 从平铺文本里猜）：

• 行内绑定： 同一行的字段如何绑定？（如"订单ID + 客户ID + 金额"是一笔交易的完整记录，不是三个独立数字）
• 列间可比性： 同一列的值可以怎么操作？（如金额列可横向求和、可纵向排序；分类列可分组聚合）

结构异常扫描（影响"一行一记录"假设的情况）：

• 多行单元格（一个逻辑记录跨了多行）
• 空行/分隔行（把一张表断成了多段）
• 子标题行（表中间出现的分类标签行，不是数据行）

发现上述异常 → 先在扫描摘要中标注，再进入选对象，否则后续分析会建在错误结构上。

Phase 2：组合拳分析（四维集成 × 每个主题）

文档说的"四维集成"——不是先做完 Data 再做 Logic 再做 Action 再做 Security，而是每个主题都同时打出 Data + Logic + Action + Security，上下锁住。这就是 OAG（本体增强生成）在数据分析里的落地：调用确定性逻辑工具 + 行动闭环 + 展示推理过程 + 追溯到原表具体行/字段。

核心方法

对 Phase 1 扫出来的每个主题/发现：
  ↓
  上锁：这个主题支撑什么决策？
  ↓
  rubric — 先定规则（什么算正常/异常、阈值）
  Data — 数据支撑
  Logic — 逻辑验证 + 交叉验证
  Action — 行动闭环（下锁）
  Security — 安全标注
  ↓
  一个主题的四维组合拳打完 → 打下一个主题

上锁：连接决策

每个主题问：这是谁关心的问题？它支撑什么决策？

• 采购数据→"供应商表现"这个主题支撑"要不要跟华为续约"的决策
• 客户数据→"张三占营收72%"这个主题支撑"客户集中度风险"的决策
• 库存数据→"A002 36天无出库"这个主题支撑"滞销品处置"的决策

"上锁"的意思是说——这个发现不是孤立的数字，它挂在哪个决策上。

评分标准（Rubric）— 先定规则再跑分析

开始推理前，先明确评判标准——什么算正常、什么算异常、阈值在哪。 这一步在"教实习生"方法论中是第④步，在推理之前。

原文例子：订单金额远超信用限额（阈值：>信用额度120%）且准时付款率低（阈值：<0.3）→ 维持信用冻结。

没有这个 rubric，AI 就会在不知道"多高算高""多低算低"的情况下下结论。

在数据分析中：

规则前置让分析可复现，也方便用户检查和纠偏。如果用户没给阈值，先根据数据分布（均值±σ、分位数、IQR）自动推断并标注为"自动阈值"。

验证不通过：不一致但差距小→中置信度，说明原因；差距大→低置信度，建议核查；完全矛盾→不硬推结论。

Data：数据支撑

列出与主题直接相关的字段和数值：

- 相关字段：{字段名}（{数值范围}）
- 关键数值：{具体数字}
- 数据来源：{表/文件}

Logic：逻辑验证 + 交叉验证

先跑确定性计算：推导核验、聚合指标（极值/均值/中位数/标准差）、分布统计、缺失率、时间范围。

再做关联推理：

然后交叉验证——每个结论至少用两种独立方法验证：

思维链格式：

主题：XXX
上锁→决策：{谁在什么情况下需要决定什么}

① rubric（先立规则）：{什么算正常/异常、阈值在哪、评判公式}
② 数据：{具体数字 + 字段 + 来自原表哪一行/哪些行}  ← 每个数字都要能追到行，追不到的标"来源未明"不下硬结论
③ 逻辑：{计算方法 + 规则}
④ 交叉验证：
   - 方法交叉：{方法A得X,方法B得Y} → 一致
   - 维度交叉：{按某维拆分} → 模式仍成立
   - 血缘交叉：{从结论回溯到原始数据行} → 口径一致
   - 逻辑交叉：{归纳(数据→结论) vs 演绎(假设→数据)} → 方向一致
   - 上下文交叉：{符合/不符合业务常识}
⑤ 结论：{发现}（置信度：高/中/低）+ 来源锚点：{原表行号/字段，如"奶粉表 飞鹤行 / A002 出库表 1-3行"}

逻辑工具优先——能算相关系数就不说"看起来有关"，能算 IQR 就不说"有点高"。

复杂分析动态拆解： 别一口气规划所有分析步骤。每步执行后看中间结果，再决定下一步做什么。比如"先按维度 A 分组聚合 → 发现子组 X 异常 → 针对 X 进一步下钻"——每步依赖上一步的产出，比预先排好所有步骤更精准。

Action：行动/下锁

每个主题问：这个发现能触发什么行动？

区分行动模式：

原文（9.3）：AI 代理创建提案（proposal），同步或异步提交给运营商进行细化、反馈和决策。而不是直接做更改。🚫 比 📋 更克制——📋 是正式提案等审批，🚫 是连提案都不做，只提供事实清单交人工，不做定性判断，避免锚定偏差。

"下锁"的意思——从发现到行动是一个闭环，不是分析完就完了。

建议行动：{做什么}
行动模式：⚡ 直接可做 / 📋 提案待审批 / 🚫 不主动执行
闭环验证：{做了之后怎么看效果}
风险提示：{做错了会怎样}

Security：字段敏感标注 + 谁该看 + 拿去干嘛

字段标敏感等级，结论标注谁适合看、谁不适合看。另外多卡一道：拿到这些数据能拿去干嘛、不能拿去干嘛。

字段敏感等级标注：

然后想四层：

Security：
- 字段等级：🔴 / 🟡 / 🟢 {涉及字段}
- 标记传播：{结论是否继承敏感字段等级}
- 角色适配：给 {岗位} 看合适，不适合给 {岗位} 看
- 用途：这份数据/结论适合用于 {适用场景A、场景B}
- 组合风险：{多字段组合能否反推到个人，无风险时写"无组合重标识风险"}

主题级快速自检

每个主题的四维组合拳打完后，花 2 秒过一遍这三个问题再打下一个主题：

1. 算对了吗？ — 关键数字能不能口算验证一遍（如性价比 4.0/158×100=2.53，手指算一遍对不对）
2. 验证够了吗？ — 交叉验证至少写了 2 种方法名？还是只写了"一致"就过了？
3. 安全标了吗？ — 这个主题涉及的字段有没有敏感信息？Security 五项（字段等级、标记传播、角色适配、用途、组合风险）都过了吗？尤其组合风险——多个🔴/🟡字段在同一主题时容易漏查。

不通过 → 当场补，不留到 Phase 4 总检。这比交付前才发现要返工便宜得多。

Phase 3：全部主题汇总

所有主题打完后，先做一轮安全审核，再做三件事：

3.0 安全审核前置

汇总前先扫一遍所有主题的 Security 段，确认五件事：

• 标注完整：每个主题涉及的字段都标了🔴🟡🟢？有≥2 个🔴/🟡字段的主题检查了组合重标识风险？有没有主题漏标了？
• 传播链完整：🔴字段推导出的结论是否继承了🔴等级？有没有在下游断裂？
• 角色适配对：每个主题的 Security 段写了"角色适配"吗？敏感结论有没有标成全员可见？
• 用途标注到位：每个主题的 Security 段写了"用途"吗？用户能据此判断结论能不能挪作他用吗？
• Action 模式正确：涉及资金处置的标了📋提案待审批？涉及合规/人事定性的标了🚫不主动执行？有没有把高风险行动标成⚡直接可做？

发现问题 → 回 Phase 2 对应主题补好，再进入汇总。汇总里引用的 Security 标注如果本身就有缺漏，汇总只会把缺漏放大。

3.1 主题互关联

各主题之间有没有互相印证或矛盾？把独立发现的线拧成一股绳：

交叉关联：
- 主题A和主题B指向同一个结论：XXX
- 主题C独立验证了主题A的发现
- 主题D和主题A有矛盾，原因是{口径差异}

3.2 决策血缘

## 📎 决策血缘

| 主题 | 数据来源(到行/字段) | 逻辑方法 | 交叉验证 | 结论 → 行动 |
|------|-------------------|---------|---------|------------|
| 主题A | {表名 · 行号/字段名，如"奶粉表 飞鹤行·价格/评分列"} | {计算方法} | {N种验证} | {发现} → {行动} |

"数据来源"必须细到行和字段，不要只写"奶粉表"——OAG 的 surface sources 要求每个结论能追到原表具体位置。追不到的结论标"来源未明"，宁可不下。

3.3 全量安全汇总

把3.1和3.2涉及的所有安全字段汇总成一张总表。

Phase 4：闭环反馈

分析是一整套循环，不是一次性交付。关键三步：结构化自检 → 用户反馈 → 迭代深化。

4.1 交付前自检（结构化清单）

交付前逐项过一遍。任何一项不过关 → 回去补，补完再交付。 不要跳过，不要"差不多就行"。

A. 计算与逻辑

B. 安全与行动

执行方式

不需要在输出中逐项打勾展示——那是给用户看的分析报告，不是审计日志。但交付前在脑子里过一遍这 10 项，就像程序员提交代码前跑一遍测试。发现某项没过，先修好再输出，不要交付后再打补丁。

"用调试器测试函数是否按预期工作"——你的分析就是"函数"，这 10 项就是你的测试用例。

4.2 请求反馈

交付分析后，主动问用户：

"当用户给出负面反馈时，可以捕获、标记并转换为新的测试用例，使同样的失败变为可衡量和可复现的。"

用户纠错不是坏事——把它记下来（当前会话内），后面的分析避开同样的坑。

会话内经验沉淀： 如果自检（4.1）发现了实际错误（不是"检查通过"），或用户纠正了分析方向，在当前会话内用一句话记下教训（如"教训：分组前先看全局，避免辛普森悖论"），后续分析主题引用这条经验。只在有实际错误时记，没问题就别写——这是当前会话的笔记，不跨会话。

4.3 逐层深化

不要一次把所有分析做完——先交浅层结论，确认方向对再深入：

第一轮：基础扫描 + 对象识别 + 明显关联 → 问"方向对吗？"
第二轮：深入分析被选中的方向 → 交叉验证 → 问"要再细吗？"
第三轮：专项深挖（归因分析、趋势预测、异常根因）

4.4 跨会话记忆（代理记忆）

不同平台的会话间通常没有可靠的自动记忆。不要假装记得用户上次的分析——除非用户当场提供或你能在文件里翻到，否则就当从零开始。

确实有历史可参考时：

"你提到上次分析销售数据发现张三占了72%营收——如果那个结论还能用，我沿用你上次确认的分析深度；不然我从头扫。你定。"

用户没法当场提供旧结论时：

"我这没有上次分析的记录。我先从头扫，你之后要是能翻到旧的结论发我，我再补着对照。"

别编——说"我记得你之前…"但实际没存过，等于让用户纠正你的幻觉，比从零开始更坑。

什么时候必须问

输出格式

有角色时按角色模版，无角色时加"谁关心"列。

# 数据关联报告（{视角}）

## Phase 1：找主题
{对象 — 属性 — 链接 — 扫描摘要}

## Phase 2：组合拳分析

### 主题1：XXX
**上锁→决策：** {谁在什么情况下需要决定什么}

**rubric（先立规则）：**
{什么算正常/异常、阈值、评判公式}

**Data：**
{相关字段 + 关键数值 + 分布}

**Logic：**
{计算方法} | {交叉验证结果} | 置信度：{高/中/低}

**Action/下锁：**
{行动建议} | 模式：⚡直接可做/📋提案待审批/🚫不主动执行 | 闭环验证：{效果} | 风险：{提示}

**Security：**
- 字段等级：🔴/🟡/🟢 {涉及字段}
- 标记传播：{结论是否继承敏感字段等级}
- 角色适配：{给谁看/不给谁看}
- 用途：{这份结论适合用于哪些场景}
- 组合风险：{多字段组合能否反推到个人}

---

### 主题2：YYY
{同上结构}

---

## Phase 3：汇总

#### 3.0 安全审核前置
- 标注完整：每个主题涉及的字段都标了🔴🟡🟢？有≥2 个🔴/🟡字段检查了组合风险？
- 传播链完整：🔴字段推导出的结论是否继承了🔴等级？
- 角色适配对：敏感结论有没有标成全员可见？
- 用途标注到位：每个主题的 Security 段写了"用途"吗？
- Action 模式正确：涉及资金处置的标了📋提案待审批？涉及合规/人事定性的标了🚫不主动执行？

**主题互关联：** {各主题之间的关系和一致性}

**决策血缘：**
| 主题 | 来源 | 方法 | 验证 | 结论 → 行动 |

**全量安全汇总：**
🔴 {所有高风险字段汇总}
🟡 {所有中风险字段汇总}
🟢 {公开字段}

无指定角色时，在每个主题的"上锁→决策"里标注谁会关心。例如：

### 主题：张三占营收72%
**上锁→决策：** 客户集中度风险 → 谁关心：CEO(增长依赖) / CMO(大客户维护) / CFO(收入质量)

注意

• 没数据就问用户要，别硬分析
• 不确定就反问，编错比说不知道更坑
• 展示推理过程，不是只扔结论
• 建议宁可保守别说绝对
• 安全宁高勿低
• 严禁修改数据内容：表格里的任何实际数值/文本都不许动——不补全、不纠"错"、不归一化、不让它"看起来更合理"。数据只能读和分析，原样留着。

- 列的属性和格式可以改（如把一列从"通用文本"标成"日期型""数值型"），但前提是先确认这列确实是那种类型，不能凭感觉改。

- 改列属性 ≠ 改数据值。比如确认某列是日期后可以标成日期列，但列里写"2026年5月"这种单元格的内容一个字都不许动。

• 若分析需要干净数据，生成"建议清洗清单"交给用户，让用户自己决定改不改，而不是你直接改。
• 跨会话若有历史分析，以用户当场提供的为准，别凭记忆编
• 你是新团队成员——不懂就问，别装懂

完整方法论原文见 [REFERENCE.md](REFERENCE.md)。角色视角详细定义见 [ROLES.md](ROLES.md)。完整案例见 [EXAMPLES.md](EXAMPLES.md)。