洞见重建流程：从材料、证据到可复核结果

洞见重建不能设计成一个“点击后让模型重新总结”的接口。只保存最后一段文字，会导致三个问题：不知道它依据了哪些材料，不知道中间处理到哪一步，也无法在更换模型或清洗规则后重新得到同样的结果。

因此重建首先是任务管理问题，其次才是模型调用问题。一次重建应该有自己的 ID、模式、状态、输入范围和处理统计：

{
  "rebuildId": "rebuild_123",
  "mode": "full",
  "status": "running",
  "startedAt": "2026-07-13T08:00:00.000Z",
  "finishedAt": null,
  "totalMaterials": 120,
  "processedMaterials": 45,
  "failedMaterials": 2,
  "modelProfile": "insight-balanced"
}

full 和增量处理必须区分。增量处理只分析新材料及其关联主题，全量重建则重新读取所有有效材料，重新计算主题、观点和关系。采集页面上的“是否触发洞见重建”检查项，控制的就是这两个业务动作之间的边界，而不是一个普通的刷新按钮。

先处理材料状态，再调用模型

材料进入知识库后，不应立即全部送给模型。每份材料都需要经过状态流转：

captured -> cleaning -> cleaned -> processing -> ready
                         \
                          -> failed

被删除的材料进入 deleted，不再参与后续重建。只有 cleaned 或 ready 的材料可以进入分析阶段。这样可以避免一篇正文为空、图片下载失败或格式不完整的材料污染整个重建任务。

清洗完成后，文本需要切成可追溯的内容块。切分顺序应当优先遵守标题、段落、列表和引用，再对过长段落做二次切分。每个块都要保留来源定位：

{
  "chunkId": "chunk_001",
  "materialId": "mat_123",
  "index": 4,
  "text": "一个完整的语义段落",
  "sourceLocator": {
    "blockIndex": 7,
    "charStart": 1200,
    "charEnd": 1680
  }
}

如果分块只保存文字，不保存 materialId 和位置，模型生成的结论就无法回到原文。结果页面可以显示一个来源链接，但用户点击后仍然要自己在长文中寻找依据，这不算真正的证据链。

主题、观点和关系分开保存

主题是材料的组织方式，观点是对材料的判断，关系是它们之间的连接，三者不应该合并成一张“洞见文本”表。

主题可以先作为候选结果保存：

{
  "topicId": "topic_001",
  "name": "本地优先应用",
  "aliases": ["local-first", "本地化架构"],
  "evidenceChunkIds": ["chunk_001", "chunk_014"],
  "confidence": 0.82,
  "status": "candidate"
}

多个材料重复出现同一主题时，再根据别名和上下文合并。用户手工标签是明确输入，应该和模型推断的主题分开保存，不能在重新处理时被模型覆盖。

观点则使用固定模板，限制模型只输出业务需要的字段：

{
  "claim": "本地优先架构可以减少外部服务不可用对核心工作流的影响。",
  "scope": "桌面知识工作台",
  "evidence": [
    {
      "materialId": "mat_123",
      "chunkId": "chunk_001",
      "quote": "原文中的关键句子"
    }
  ],
  "counterEvidence": [],
  "assumptions": ["应用主要面向单用户或小团队使用"],
  "confidence": "medium"
}

claim 是观点，evidence 是证据，assumptions 是前提，confidence 是当前可信度。没有证据的句子不能直接进入已发布洞见。模型认为两个来源互相矛盾时，也不能强行选一个答案，而应保存一条关系：

{
  "relationType": "contradicts",
  "from": "claim_001",
  "to": "claim_009",
  "reason": "两个来源对部署方式的要求相反",
  "status": "unresolved"
}

这一步是知识图谱的基础。图谱不是把文章标题连成网络，而是把材料、内容块、主题、观点和冲突关系都保存成可查询的节点和边。

结果发布前必须校验

洞见生成完成后，不能直接显示给用户。至少要检查：

1. 是否至少引用一份有效材料
2. 引用内容是否真实存在于原文
3. 来源材料是否已被删除
4. 是否把假设写成了事实
5. 是否存在未处理的冲突观点
6. 标题和摘要是否为空
7. 是否和已有洞见重复

校验通过的结果进入 reviewable 或 published，失败的结果保留为 draft 或 invalid，并记录失败原因。系统宁可少展示一条结果，也不能把没有证据的推断伪装成确定结论。

模型配置也要按任务拆开。清洗、分类、主题合并、复杂观点提取对模型能力的要求不同，不应该所有环节都调用最大模型。每次调用记录模型、任务类型、提示词版本和输入指纹：

{
  "model": "configured-model-id",
  "task": "claim-extraction",
  "promptVersion": "insight-v3",
  "inputHash": "sha256:...",
  "outputHash": "sha256:..."
}

将来更换模型时，可以根据输入指纹判断哪些结果需要重建，而不是整库盲目重跑。

最终结果要能沿链路返回原文

最终洞见至少保存以下内容：

{
  "insightId": "insight_001",
  "title": "本地优先并不等于完全离线",
  "summary": "洞见摘要",
  "claimIds": ["claim_001"],
  "evidenceMaterialIds": ["mat_123", "mat_145"],
  "relatedTopicIds": ["topic_001"],
  "confidence": "medium",
  "status": "reviewable"
}

用户看到一条洞见时，应当能够按下面的顺序回溯：

洞见
  -> 观点
  -> 证据内容块
  -> 清洗后的材料
  -> 原始文章和来源链接

这条链路决定了洞见是可复核的知识结果，还是一段无法解释的模型输出。全量重建的价值也不只是重新生成文字，而是让同一批材料在规则、模型或关系结构变化后，仍然可以按照明确步骤重新计算。只要材料、分块、观点和证据关系都被保存，知识库就具备持续演进的基础。