上周和一位创业者吃饭，他刚帮一家大型企业做完知识图谱项目的评估。结论让人倒吸一口凉气：要达到替代中级岗位能力的水平，算上数据采集、清洗、标注、图谱构建和持续维护，预算需要一个亿。
企业听完直接搁置了。
这不是个例。过去三年，我见过不下十个类似的项目——企业想做知识库，供应商画了一个「知识图谱+智能问答」的大饼，然后企业发现投入产出比根本算不过账。
但今年情况变了。模型能力的跃迁正在催生一个新范式：不再靠人工标注堆数据，而是让 LLM 做编排，结合企业搜索，人做优化调整和确认。
知识整理的起点也不再是宏大的「企业知识图谱」，而是每个人手边的 Journal——每日工作日记。通过钉钉这样的组织连接工具，个人知识可以自然地流转、沉淀为企业知识。
一、旧范式为什么走不通
1.1 一个亿花在哪里
传统知识图谱项目的成本结构大致如下：
| 阶段 | 内容 | 占比 | 说明 |
|---|---|---|---|
| 数据采集 | 文档收集、系统对接 | 10% | 相对可控 |
| 数据清洗 | 去重、格式化、结构化 | 15% | 人力密集 |
| 知识标注 | 实体识别、关系标注、质量校验 | 40% | 核心瓶颈 |
| 图谱构建 | 本体设计、图谱存储 | 15% | 技术成熟 |
| 应用开发 | 问答系统、推荐引擎 | 10% | 效果不确定 |
| 持续维护 | 知识更新、模型迭代 | 10%/年 | 隐性成本 |
标注环节占了 40%，而且这是持续性成本。企业知识不是静态的——新产品上线、新流程发布、新政策出台，图谱需要不断更新。这意味着标注团队不能解散，要长期养着。
1.2 根本矛盾：知识获取瓶颈
传统范式的核心假设是：知识必须通过人工标注才能结构化。
这个假设导致了几个无解的矛盾：
- 专家不愿标注：真正懂业务的人没时间做标注，做标注的人不懂业务
- 标注质量不可控：外包标注的错误率通常在 15-25%，需要多轮校验
- 知识时效性差：标注周期通常 3-6 个月，等图谱建好，知识已经过时了
- 长尾知识无人覆盖：80% 的标注精力花在 20% 的高频知识上，长尾永远没人碰
传统知识图谱构建流程
┌─────────────────────────────────────────────────────┐
│ │
│ 原始文档 ──→ 人工清洗 ──→ 人工标注 ──→ 图谱构建 │
│ (海量) (耗时) (瓶颈!) (效果存疑) │
│ │
│ 成本: ───────────→ 递增 ──────────────────────→ │
│ 质量: ───────────→ 递减 ──────────────────────→ │
│ 时效: ───────────→ 衰减 ──────────────────────→ │
│ │
└─────────────────────────────────────────────────────┘
二、新范式：LLM 编排 + 人在回路
2.1 范式转移的本质
2025-2026 年模型能力的提升，让一个关键假设被推翻了：
知识不再需要人工标注才能结构化。LLM 本身就是一个通用的知识提取和结构化引擎。
新范式的核心逻辑是：
- LLM 做初筛和编排：从原始文档中自动提取实体、关系、摘要
- 搜索做召回和增强：RAG 架构确保答案有据可查
- 人做确认和优化：关键节点由领域专家审核，而非逐条标注
这把 40% 的标注成本砍到了 5% 以下——人只需要做审核，不需要做生产。
新范式：LLM编排 + 人在回路
┌─────────────────────────────────────────────────────┐
│ │
│ 原始文档 ──→ LLM提取 ──→ 自动结构化 ──→ 知识存储 │
│ (海量) (自动) (自动) (向量+图谱) │
│ │ │
│ ▼ │
│ 人在回路 ──→ 确认/修正/补充 │
│ (审核者，非生产者) │
│ │
│ 成本: ───────────→ 递减 ──────────────────────→ │
│ 质量: ───────────→ 递增 ──────────────────────→ │
│ 时效: ───────────→ 实时 ──────────────────────→ │
│ │
└─────────────────────────────────────────────────────┘
2.2 「人在回路」的三层模型
我把这个新范式总结为 「知识涌现三层模型」（Knowledge Emergence Layered Model, KELM）：
┌─────────────────────────────────────────────────┐
│ │
│ Layer 3: 企业知识库 (Organizational Knowledge) │
│ ┌─────────────────────────────────────────┐ │
│ │ 已验证、可复用的组织级知识 │ │
│ │ 来源: Layer 2 的沉淀 + 专家审核 │ │
│ │ 形态: 结构化FAQ、SOP、最佳实践库 │ │
│ └─────────────────────────────────────────┘ │
│ ▲ │
│ │ 审核 + 沉淀 │
│ Layer 2: 团队知识流 (Team Knowledge Flow) │
│ ┌─────────────────────────────────────────┐ │
│ │ 项目复盘、技术分享、问题排查记录 │ │
│ │ 来源: Layer 1 的聚合 + LLM 编排 │ │
│ │ 形态: 项目Wiki、会议纪要、技术方案 │ │
│ └─────────────────────────────────────────┘ │
│ ▲ │
│ │ 聚合 + 编排 │
│ Layer 1: 个人Journal (Personal Journal) │
│ ┌─────────────────────────────────────────┐ │
│ │ 每日工作记录、思考片段、问题笔记 │ │
│ │ 来源: 个人日常工作自然产生 │ │
│ │ 形态: 日记、备忘录、聊天中的关键信息 │ │
│ └─────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────┘
三层模型的关键洞察：
- Layer 1 是源头：知识不是被「建设」出来的，而是在日常工作中自然产生的。Journal 是最低摩擦的知识记录方式。
- Layer 2 是枢纽：LLM 在这里发挥作用——自动从多个人的 Journal 中提取共性话题、关联信息、生成摘要。
- Layer 3 是结果：经过团队验证的知识自然沉淀为企业资产，不需要专门的知识工程团队。
2.3 技术架构：LLM 如何做编排
新范式的技术核心是 LLM 驱动的编排层（Orchestration Layer）：
┌──────────────────────────────────────────────────────┐
│ 用户 (员工/管理者) │
└──────────────────────┬───────────────────────────────┘
│ 查询 / 确认 / 反馈
┌──────────────────────▼───────────────────────────────┐
│ 编排层 (Orchestrator) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 意图理解 │→│ 路由决策 │→│ 多步推理/工具调用 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 向量搜索 │ │ 全文搜索 │ │ 结构化数据查询 │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────┘
│
┌──────────────────────▼───────────────────────────────┐
│ 知识存储层 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
│ │ 向量数据库│ │ 搜索引擎 │ │ 关系型/图数据库 │ │
│ │ (语义) │ │ (关键词) │ │ (结构化关系) │ │
│ └──────────┘ └──────────┘ └──────────────────┘ │
└──────────────────────────────────────────────────────┘
编排层的关键能力：
- 意图理解：判断用户是想查知识、贡献知识，还是确认/修正知识
- 路由决策：选择最合适的检索方式（向量/全文/结构化）
- 多步推理：复杂问题拆解为多步查询，LLM 自动组装答案
- 人在回路：答案生成后，关键节点推送给领域专家确认
2.4 成本对比
| 维度 | 旧范式（知识图谱） | 新范式（LLM编排+人在回路） |
|---|---|---|
| 初始投入 | 5000万-1亿 | 200万-500万 |
| 年维护成本 | 500万-1000万 | 50万-100万 |
| 上线周期 | 6-12个月 | 1-3个月 |
| 知识覆盖率 | 20-30%（高频知识） | 60-80%（含长尾） |
| 知识时效性 | 月级更新 | 日级/实时 |
| 对人的依赖 | 专职标注团队 | 领域专家兼职审核 |
三、从 Journal 到企业知识：钉钉的连接价值
3.1 为什么 Journal 是最佳起点
Journal（工作日记）有几个被严重低估的优势：
- 零摩擦：不需要额外的知识管理系统，就是每天写几句话
- 高保真：记录的是当天实际发生的事情，不是事后回忆
- 有上下文：Journal 天然包含时间、项目、人物等元数据
- 可追溯：每一条知识都能追溯到具体的时间、人和事件
3.2 钉钉的连接能力
钉钉作为组织协同平台，天然具备连接「人-知识-组织」的能力：
┌─────────────────────────────────────────────────┐
│ │
│ 钉钉组织协同平台 │
│ │
│ ┌──────┐ ┌──────┐ ┌──────────────┐ │
│ │ 个人 │───→│ 群组 │───→│ 组织知识库 │ │
│ │Journal│ │讨论/ │ │ 沉淀/检索/ │ │
│ │ AI辅助│ │共享 │ │ AI问答 │ │
│ │记录 │ │ │ │ │ │
│ └──────┘ └──────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 个人知识 团队知识 组织知识 │
│ (私有) (半公开) (公开) │
│ │
└─────────────────────────────────────────────────┘
钉钉的连接价值体现在：
- 身份连接：知道知识是谁产生的，在什么组织上下文中产生的
- 沟通连接：群聊中的讨论、决策、问题排查，天然就是知识素材
- 流程连接：审批、日志、待办，这些流程中产生的信息自动进入知识流
- AI 连接：钉钉 AI 可以在 Journal 记录时自动提取关键信息，在群聊中自动总结讨论要点
3.3 一个具体的场景
想象这样一个工作流：
工程师小王今天在 Journal 里记录：「排查了线上 P0 故障，根因是 Redis 连接池耗尽。解决方案是调整 maxActive 参数从 50 到 200，并增加连接泄漏检测。」
钉钉 AI 自动提取了这条记录的关键信息：故障类型（P0）、根因（Redis 连接池）、解决方案（参数调整）。
两周后，另一个团队的工程师遇到类似问题，在钉钉知识库搜索「Redis 连接池」，直接找到了小王的排查记录和解决方案。
团队 leader 看到这条知识被多次引用，点击「沉淀为 SOP」，AI 自动生成了一份标准化的故障排查流程文档。
在这个过程中：
- 小王没有做任何额外的「知识贡献」动作
- 没有专职的知识工程师参与
- 知识从产生到被使用，再到沉淀为组织资产，全程自然流转
四、总结：从「建设」到「涌现」
旧范式的根本错误在于，它把知识当成了一种需要「建设」的工程产物。
但知识不是建出来的，是涌现出来的。
- 个人在工作中产生经验 → Journal 记录
- LLM 从 Journal 中提取模式 → 团队知识流
- 团队在实践中验证知识 → 企业知识库
KELM 模型的核心价值在于：它把知识管理的成本从「一个亿」降到了「几乎为零的边际成本」，同时把知识的时效性从「月级」提升到了「日级」。
这不是技术的渐进优化，而是范式的根本转移。
你的团队是如何做知识管理的？有没有试过从 Journal 开始，让知识自然涌现？欢迎留言讨论。