技能介绍

要解决什么问题

企业里同一业务概念往往在多套系统、Word/Excel 台账和 SQL DDL 里各叫一名；Agent 若只靠对话上下文，容易把表名当业务对象、把局部文档当全局事实。本技能面向把既有数据里的隐式模型显式化：产出可审阅的本体候选或个人知识图谱，而不是从零画一张空架构图。

技能如何工作

分工很明确：Python 脚本负责扫描目录、格式转换、表格抽取与索引；当前对话中的大模型负责实体识别、属性取舍、关系发现、命名与跨源合并。全程不调用外部语义 API，产物只写入你指定的本地目录，且脚本采用仅追加写入，不删改你的原始文件。

三种运行模式可按场景切换：

Mode A（库表/文档抽取）：对 SQL、数据字典、Word/Excel 模式说明做 P1–P7 优先级扫描，经抽取与合并输出 ontology.json 与 review.md
Mode B/C（文件系统图谱）：先机械建 Document/Project 索引；Step 1.5 必须人工确认扫描范围（重点/普通/忽略）后才读内容；再采样与全文读取（含「列表/台账」类文件的逐行实体规则），写入 graph.jsonl 与 schema.yaml
可选导出：将本体或图谱对齐 TuGraph 批量导入 JSON（Domain/Table 顶点与 BELONGS_TO、REFERENCES 边）

对话阶段还可按证据追加 source.type=runtime 的实体，用于日常补全图谱，而非整盘重扫。

适用边界

若实体规模小、信息本就装在一人脑子和一张 Excel 里，图谱多半只是复述已知事实，增量价值有限。跨系统命名不一致、Agent 需要事实底座、或咨询交付「数据资产长什么样」时更值得投入。建模原则是业务概念优先于表名、覆盖率优先于过度深挖，最终裁决权在人——技能输出的是待审候选与 review.md 中的待决项。