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