简诗 AI 文本转知识图谱

这个技能解决什么问题

面对一份技术文档、产品说明、会议纪要或新闻稿时，最麻烦的往往不是“读不懂”，而是机器无法稳定复用其中的结构：实体散落在不同句子里，关系靠上下文暗示，版本、角色、依赖、事件等信息容易被忽略。人工梳理可以画出一张图，但图不可查询、规则不可复现，后续做语义搜索、推荐或领域建模时还要重新拆解。

这个技能把“非结构化文本 → 结构化知识”的过程固定成可重复的工作流，重点不是生成一张好看的关系图，而是产出能被 Neo4j、JSON-LD 或其他下游工具使用的图三元组。

工作方式：从文本到可查询图谱

它按六个步骤执行：

1. 分析源材料：判断文本领域、范围和复杂度，并确定实体粒度。技术架构文档适合拆到组件级，新闻稿则通常保留角色级即可。
2. 抽取实体：识别人名、组织、技术、概念、事件、地点等实体，记录规范名、类型和属性；同一实体的不同叫法或缩写会被合并。
3. 映射关系：把实体间的交互写成有向三元组 (Subject) -[PREDICATE]-> (Object)，谓词使用一致词表，例如 WORKS_AT、DEPENDS_ON、CREATED_BY、PART_OF、COMPETES_WITH，并保留来源句便于追溯。
4. 生成图数据与轻量 schema：输出 Cypher CREATE 语句、JSON-LD，或 (subject, predicate, object) 的 CSV；同时列出可用实体类型和关系类型。
5. 可视化：用 Mermaid 生成可嵌入 Markdown 的图，或描述适合 D3.js、Gephi、Neo4j Browser 的布局，并突出中心节点和关键关系簇。
6. 校验精化：检查孤儿节点、文本暗示但缺失的关系、过于宽泛的谓词，邀请用户确认、纠正或扩展特定子图。

输出形态与适用场景

适合需要理解复杂领域、做语义搜索、发现隐式连接或构建推荐系统的工程师：架构评审时整理服务依赖，产品梳理时确认团队与系统关系，技术写作时检查实体和关系是否完整。图谱节点带类型、描述和元数据，关系是有向边，后续查询和审计都更直接。

使用边界与注意点

该技能不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容。涉及发送、发布、删除、付款、部署等外部写入时，会先展示目标与影响并取得明确确认。凭据仅用于用户指定的对应官方服务，不回显、不记录、不转发到无关地址；命令和代码默认作为参考，只有用户明确要求且目标范围清楚时才可运行。

处理大文本时应分块构建并合并去重；节点过多会提示可能超出实用可视化规模。对文本中矛盾的信息，应保留双方并标记冲突；对隐含关系应标记为推断。医疗、法律、金融等专业领域可对齐领域本体，如 SNOMED CT 或 FIBO。