mcpField
K
knowledge-synthesis

knowledge-synthesis

github.com/w95生产力28539 次安装35 周前更新
代码仓库

关于 knowledge-synthesis

Knowledge Synthesis 是将多个来源的搜索结果整理为连贯答案并标注出处的 Skill，涵盖去重、证据评估、冲突处理及按结果规模调整摘要。

主要功能

  1. 01跨来源去重
  2. 02来源标注指引
  3. 03时效性与权威性评估
  4. 04冲突与置信度处理
  5. 05按结果规模生成摘要

适用场景

  1. 01综合多个来源的搜索结果
  2. 02追溯决策及其支持记录
  3. 03报告相互冲突或过时的信息
  4. 04按主题总结大量结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/w95/awesome-claude-corporate-skills --skill knowledge-synthesis

安装后在 Claude Code 中输入/knowledge-synthesis确认已加载。

详细介绍

知识综合

企业搜索的最后一公里。整合多个来源的原始结果，生成连贯且可信的答案。

目标

将这个：

~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'"
~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale"
~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision"
~~project tracker result: "Task: Finalize API approach — marked complete by Sarah"

变为这个：

The team decided to go with REST over GraphQL for the API redesign. Sarah made the
call, noting that GraphQL was overkill for the current use case. This was discussed
in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has
been updated to reflect the decision. The related ~~project tracker task is marked complete.

Sources:
- ~~chat: #engineering thread (Jan 14)
- ~~email: "API Decision" from Sarah (Jan 15)
- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
- ~~project tracker: "Finalize API approach" (completed Jan 15)

去重

跨来源去重

同一信息常常出现在多个地方。需要识别并合并重复内容：

判断结果是否指向同一事物的信号：

  • 文本内容相同或非常相似
  • 同一作者/发送者
  • 时间戳相隔很短（同一天或相邻日期）
  • 引用同一实体（项目名称、文档、决策）
  • 一个来源提及另一个来源（如“如 ~~chat 中所讨论的”、“根据邮件”、“参见文档”）

合并方法：

  • 合并为单个叙述条目
  • 引用该信息出现过的所有来源
  • 以最完整的版本作为主文本
  • 补充各来源中独有的细节
去重优先级

当同一信息存在于多个来源时，优先采用：

1. The most complete version (fullest context)
2. The most authoritative source (official doc > chat)
3. The most recent version (latest update wins for evolving info)
不应去重的情况

以下情况应保留为独立条目：

  • 讨论的是同一主题，但得出的结论不同
  • 不同的人表达了不同的观点
  • 信息在来源之间发生了实质性演变（决策的 v1 与 v2 版本）
  • 涵盖不同的时间段

引用与来源归属

综合答案中的每一项论断都必须可追溯到来源。

归属格式

直接引用时使用行内格式：

Sarah confirmed the REST approach in her email on Wednesday.
The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3").

为便于查阅，在末尾附上来源列表：

Sources:
- ~~chat: #engineering discussion (Jan 14) — initial decision thread
- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
归属规则
  • 始终注明来源类型（~~chat、~~email、~~cloud storage 等）
  • 包括具体位置（频道、文件夹、线程）
  • 包括日期或相对时间
  • 在相关时包括作者
  • 在可用时包括文档/线程标题
  • 对于 ~~chat，注明频道名称
  • 对于 ~~email，注明邮件主题和发件人
  • 对于 ~~cloud storage，注明文档标题

置信度等级

并非所有结果都同样可靠。评估置信度时应考虑：

时效性
时间置信度影响
今天 / 昨天对当前状态有较高置信度
本周置信度良好
本月中等 — 情况可能已发生变化
一个月以前置信度较低 — 标记为可能已过时

对于状态类查询，应重点考虑时效性。对于政策/事实类查询，时效性的重要性较低。

权威性
来源类型权威等级
官方 wiki / 知识库最高 — 经过整理和维护
共享文档（最终版本）高 — 经过有意发布
邮件公告高 — 正式沟通
会议纪要中高 — 可能不完整
聊天消息（线程结论）中等 — 非正式但实时
聊天消息（线程中间内容）较低 — 可能不代表最终立场
草稿文档低 — 尚未定稿
任务评论视情况而定 — 取决于评论者
表达置信度

当置信度高时（多个新近且权威的来源相互一致）：

The team decided to use REST for the API redesign. [direct statement]

当置信度中等时（仅有单一来源或信息略显陈旧）：

Based on the discussion in #engineering last month, the team was leaning
toward REST for the API redesign. This may have evolved since then.

当置信度低时（数据陈旧、来源非正式，或信号相互矛盾）：

I found a reference to an API migration discussion from three months ago
in ~~chat, but I couldn't find a formal decision document. The information
may be outdated. You might want to check with the team for current status.
信息冲突

当来源之间存在分歧时：

I found conflicting information about the API approach:
- The ~~chat discussion on Jan 10 suggested GraphQL
- But Sarah's email on Jan 15 confirmed REST
- The design doc (updated Jan 15) reflects REST

The most recent sources indicate REST was the final decision,
but the earlier ~~chat discussion explored GraphQL first.

始终应呈现冲突，而不是悄悄选择其中一个版本。

摘要策略

小型结果集（1-5 条结果）

逐条呈现每个结果并提供上下文。无需摘要，将全部内容提供给用户：

[Direct answer synthesized from results]

[Detail from source 1]
[Detail from source 2]

Sources: [full attribution]
中型结果集（5-15 条结果）

按主题分组，并对每组进行摘要：

[Overall answer]

Theme 1: [summary of related results]
Theme 2: [summary of related results]

Key sources: [top 3-5 most relevant sources]
Full results: [count] items found across [sources]
大型结果集（15 条以上结果）

提供高层次的综合概述，并支持用户逐级深入查看：

[Overall answer based on most relevant results]

Summary:
- [Key finding 1] (supported by N sources)
- [Key finding 2] (supported by N sources)
- [Key finding 3] (supported by N sources)

Top sources:
- [Most authoritative/relevant source]
- [Second most relevant]
- [Third most relevant]

Found [total count] results across [source list].
Want me to dig deeper into any specific aspect?
摘要规则
  • 先给出答案，而不是搜索过程
  • 不要罗列原始结果，应将其整合为连贯的叙述
  • 将来自不同来源的相关条目归为一组
  • 保留重要的细节与注意事项
  • 提供足够的信息，使用户能够判断是否需要深入了解
  • 如果结果集较大，始终主动提出提供更多细节

综合工作流

[Raw results from all sources]
          ↓
[1. Deduplicate — merge same info from different sources]
          ↓
[2. Cluster — group related results by theme/topic]
          ↓
[3. Rank — order clusters and items by relevance to query]
          ↓
[4. Assess confidence — freshness × authority × agreement]
          ↓
[5. Synthesize — produce narrative answer with attribution]
          ↓
[6. Format — choose appropriate detail level for result count]
          ↓
[Coherent answer with sources]

反模式

请勿：

  • 按来源逐一罗列结果（"来自 ~~chat：…… 来自 ~~email：…… 来自 ~~cloud storage：……"）
  • 仅仅因为关键词匹配就纳入无关结果
  • 将答案埋没在方法论说明之中
  • 呈现相互矛盾的信息而不予标注
  • 省略来源标注
  • 对不确定的信息与有充分依据的事实使用相同的确定语气
  • 过度精简摘要，导致有用的细节丢失

应当：

  • 先给出答案
  • 按主题而非按来源分组
  • 在适当时标明置信度
  • 明确指出冲突之处
  • 为所有论断标注来源
  • 当结果集较大时，主动提出深入说明

评论

支持 Markdown