Skip to content
Back to skills

Multi Source Knowledge Synthesis

ASecurity

当手头有来自多个渠道(聊天/邮件/云文档/任务系统/Wiki 等)的检索结果、需要去重合并成一个连贯且可溯源的答案时使用;做的是跨源去重、按主题聚类、按时效×权威性×一致性评估置信度、产出「先结论后细节+逐条署名」的综合回答;不适用于单一来源直接可答、原始资料尚未检索到、或用户只要罗列原文不要综合的场景。触发词:综合、汇总、去重、多源、跨来源、可溯源、谁说了算、最终结论

  • 3 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 19, 2026
ai-agentsapi

Works with

  • cursor
  • cli
  • api

Security analysis

A100/100

Scanned September 19, 2026

npx -y skills add findscripter/everything-skills --skill multi-source-knowledge-synthesis --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Multi Source Knowledge Synthesis?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Multi Source Knowledge Synthesis
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/findscripter-multi-source-knowledge-synthesis/badge)](https://www.skillsdirectory.com/skills/findscripter-multi-source-knowledge-synthesis)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: multi-source-knowledge-synthesis
title: 多源知识综合
description: 当手头有来自多个渠道(聊天/邮件/云文档/任务系统/Wiki 等)的检索结果、需要去重合并成一个连贯且可溯源的答案时使用;做的是跨源去重、按主题聚类、按时效×权威性×一致性评估置信度、产出「先结论后细节+逐条署名」的综合回答;不适用于单一来源直接可答、原始资料尚未检索到、或用户只要罗列原文不要综合的场景。触发词:综合、汇总、去重、多源、跨来源、可溯源、谁说了算、最终结论
domain: 通用/communication
triggers: [综合多个来源, 汇总检索结果, 跨来源去重, 多源信息整合, 把这些结果整理成结论, 带出处的答案, 哪个是最终决定, 信息冲突怎么判, synthesize sources, deduplicate results]
tags: [知识综合, 信息整合, 去重, 来源署名, 置信度评估, 企业检索, 多源, 结论先行, rag 后处理]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: []
requires: []
related: [query-decomposition-search, activity-digest-generator, fact-checking, notebooklm-source-grounded-qa]
combines_with: [query-decomposition-search, news-sentiment-briefing]
license: Apache-2.0
source: anthropics/knowledge-work-plugins
source_license: Apache-2.0
---
## 何时使用

当你已经从**多个来源**(聊天、邮件、云文档、项目/任务系统、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+)的详略策略及反模式清单等关键约束。

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…