Multi source knowledge synthesis

何时使用

当你已经从多个来源（聊天、邮件、云文档、项目/任务系统、Wiki 等）拿到一批原始检索结果，需要把它们合成一个连贯、可信、每句话都能溯源的答案时使用。这是企业检索的「最后一公里」——从一堆零散命中到一段能直接给人看的结论。

典型触发：

• 用户问一个问题，命中分散在 N 个系统里，需要合并成一个回答而非贴 N 段原文。
• 同一信息在多处出现，需要去重并统一署名。
• 来源之间互相矛盾或随时间演进，需要判定「哪个是最终结论」并暴露分歧。

不该用于：

• 单一来源即可直接回答 —— 不需要综合流程，直接引用作答。
• 原始资料还没检索到 —— 本技能是检索的后处理，不负责去各系统拉数据；先用检索类技能取回结果。
• 用户明确只要原始片段、不要你加工综合时。
• 把不相关命中硬塞进答案（仅因关键词匹配）—— 宁可丢弃也不污染结论。

步骤

固定 6 步流水线，输入是「全部来源的原始结果」，输出是「带署名的连贯答案」：

[原始结果]
  ↓ 1. 去重    跨源合并同一信息
  ↓ 2. 聚类    按主题/话题分组相关结果
  ↓ 3. 排序    按与问题的相关度给簇和条目排序
  ↓ 4. 评置信  时效 × 权威性 × 一致性
  ↓ 5. 综合    写成叙事式答案 + 逐条署名
  ↓ 6. 选格式  按结果数量决定详略层级
[连贯答案 + 来源清单]

1. 去重（cross-source dedup） —— 判定「是同一件事」的信号：文本高度相似 / 同一作者发件人 / 时间戳相近（同日或相邻日）/ 指向同一实体（项目名、文档、决策）/ 一处引用另一处（「如聊天里讨论的」「见那封邮件」「参文档」）。 合并办法：归为一条叙事，列出全部出现来源，以最完整的版本为主文，补入各来源独有细节。 合并优先级：① 最完整（上下文最全）② 最权威（正式文档 > 聊天）③ 最新（演进型信息以最新为准）。

不要去重（保留为独立条目）的情形：同话题但结论不同 / 不同人表达不同观点 / 信息在来源间实质演进（决策 v1 vs v2）/ 代表不同时间段。

4. 评置信度 —— 两维度交叉：

时效（状态类问题重时效，政策/事实类问题时效次要）：

时效	影响
今天/昨天	对当前状态高置信
本周	较好置信
本月	中等——可能已变
超过一个月	偏低——标注「可能过期」

权威性：

来源类型	权威级别
官方 Wiki / 知识库	最高（经维护策展）
共享文档（终版）	高（有意发布）
邮件公告	高（正式沟通）
会议纪要	中高（可能不全）
聊天（话题结论句）	中（非正式但实时）
聊天（话题中段）	偏低（未必是最终立场）
草稿文档	低（未定稿）
任务评论	视评论者而定

指令

署名规则（每条断言都必须可溯源）：

• 始终标出来源类型（聊天 / 邮件 / 云文档 …）+ 具体位置（频道、文件夹、线程）+ 日期或相对时间 + 相关时的作者 + 可得的文档/线程标题。
• 聊天注明频道名；邮件注明主题+发件人；云文档注明文档标题。
• 行内引用 +「Sources:」末尾清单 双管齐下。

按置信度调整措辞：

• 高（多个新鲜且权威来源一致）→ 直接陈述：「团队决定 API 改用 REST。」
• 中（单一来源或略旧）→ 加限定：「据上月 #engineering 的讨论，团队当时倾向 REST，此后可能有变。」
• 低（数据旧/来源非正式/信号冲突）→ 明确不确定 + 建议核实：「找到三个月前一条 API 迁移讨论，但没有正式决策文档，信息可能过期，建议向团队确认现状。」

信息冲突时：永远显式暴露冲突，不要悄悄挑一个版本。列出各方时间线，再给出「最新来源指向 X，但早期 Y 也探讨过」的判断。

按结果数量选详略：

• 1–5 条：逐条给上下文，不压缩，把全部信息给用户 + 完整署名。
• 5–15 条：按主题分组，每组小结，给「Key sources（最相关 3–5 个）」+ 总命中数。
• 15+ 条：高层综合 + 可下钻。给「Summary：要点（各由 N 个来源支撑）」「Top sources」「共 X 条横跨 Y 个来源，需要深挖哪块？」。

综合规则：结论先行（别先讲检索过程）/ 不罗列原始结果而是叙事化 / 跨源相关项归并到一起 / 保留重要细微差别与告诫 / 结果集大时主动提议继续深挖。

示例

把分散命中合成一个答案：

输入（原始命中）：

聊天：Sarah 在 #eng 说「就用 REST，GraphQL 对我们这场景过重」
邮件：主题「API Decision」——Sarah 确认 REST 方案及理由
云文档：「API 设计文档 v3」——第 2 节已更新为 REST 决策
任务系统：任务「敲定 API 方案」——Sarah 标记完成

输出（综合答案）：

团队在 API 改造中决定用 REST 而非 GraphQL。这个决定由 Sarah 拍板，理由是
GraphQL 对当前场景过重。周二在 #engineering 讨论，周三邮件确认，设计文档已
同步更新，相关任务也已标记完成。

Sources:
- 聊天：#engineering 线程（1 月 14 日）—— 初始决策讨论
- 邮件：「API Decision」来自 Sarah（1 月 15 日）—— 正式确认
- 云文档：「API 设计文档 v3」（1 月 15 日更新）—— 更新后的规范
- 任务系统：「敲定 API 方案」（1 月 15 日完成）

冲突示例：

关于 API 方案我找到了相互矛盾的信息：
- 1 月 10 日的聊天讨论倾向 GraphQL
- 但 Sarah 1 月 15 日的邮件确认了 REST
- 设计文档（1 月 15 日更新）也写的是 REST
最新来源表明 REST 是最终决定，但早期聊天确实先探讨过 GraphQL。

注意事项

不要做（反模式）：

• 按来源逐条罗列（「聊天里说…邮件里说…云文档里说…」）——要按主题组织，不按来源。
• 仅因关键词匹配就塞入不相关结果。
• 把答案埋在方法论解释之下——结论先行。
• 不标注就呈现冲突信息 / 漏掉来源署名。
• 把不确定信息说得和铁证一样笃定。
• 压缩过度，丢掉有用细节。

要做： 结论先行 / 按话题分组 / 适当标置信度 / 显式暴露冲突 / 所有断言署名 / 结果集大时主动提议深挖。

互见

• requires：fact-checking —— 综合前对关键断言做查证，区分「来源原文」与可能的误读。
• related：notebooklm-source-grounded-qa —— 单源锚定问答；多源场景升级用本技能做合并。
• combines_with：entity-research-dossier —— 把多源综合的结论沉淀进结构化调研档案；citation-management —— 规范化「Sources:」清单与行内署名。

---

采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可证），原技能 knowledge-synthesis（enterprise-search 插件）。本条为适配中文「技能大典」的重写版，保留其 6 步综合流水线、跨源去重信号与优先级、时效×权威性置信度评级表、冲突显式暴露、按结果数量分级（1–5 / 5–15 / 15+）的详略策略及反模式清单等关键约束。