knowledge-work-plugins 企业搜索实战search 技能如何用一条查询打通聊天、邮件、文档与项目追踪【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins本文基于knowledge-work-plugins仓库中 enterprise-search 插件的 search 技能 展开。它定义了企业搜索的核心命令用户只需用一句自然语言提问Claude 就会对问题做意图解析、按各连接源的原生语法分解成多个子查询、并行检索所有已接入的 MCP 数据源最后把零散结果去重、排序并合成为带出处标注的单一答案。读完本文你将掌握 search 技能的完整执行流程、过滤器语法、输出模板与边界场景处理策略并能结合仓库中的 search-strategy、source-management 与 knowledge-synthesis 三个辅助技能理解其底层工作机制。一、技能定位一条查询搜遍所有连接源search 技能SKILL.md是 enterprise-search 插件对外暴露的核心命令其 frontmatter 声明了它的用途与触发方式name: search description: Search across all connected sources in one query. Trigger with find that doc about..., what did we decide on..., where was the conversation about..., or when looking for a decision, document, or discussion that could live in chat, email, cloud storage, or a project tracker. argument-hint: query触发短语find that doc about...、what did we decide on...、where was the conversation about...以及任何针对可能存在于聊天、邮件、云盘或项目追踪器中的决策、文档或讨论的查找需求。argument-hintquery即技能接收一个查询参数。核心动作在单次查询中横跨所有已连接的 MCP 数据源进行搜索——先分解用户问题再并行执行子搜索最后合成结果。用插件 README.md 中的示意图可以直观理解这条流水线You: What did we decide about the API redesign? ↓ Claude searches ~~chat: #engineering thread from Tuesday with the decision ~~email: Follow-up email from Sarah with the spec ~~cloud storage: Updated API design doc (modified yesterday) ↓ Claude synthesizes The team decided on Tuesday to go with REST over GraphQL. Sarah sent the updated spec Thursday. The design doc reflects the final approach.这背后的设计哲学是把所有工具当作一个可检索的知识库。知识工作者每周要花数小时在各工具间切换寻找信息而企业搜索把逐工具搜索 交叉比对 猜测正确位置的整体成本压缩成一次提问。二、前置检查确认可用数据源Step 1执行搜索前先根据当前可用的工具列表判断哪些 MCP 源已连接。技能列出的常见数据源类别包括~~chat—— 聊天平台工具消息、线程、频道、私信~~email—— 邮件工具邮件、附件、会话~~cloud storage—— 云存储工具文档、表格、幻灯片、PDF~~project tracker—— 项目追踪工具任务、问题、里程碑~~CRM—— 客户关系管理工具账户、联系人、机会~~knowledge base—— 知识库工具内部文档、runbook其中~~category是仓库 CONNECTORS.md 定义的占位符机制它代表用户在该类别下实际接入的具体工具插件刻意保持工具无关tool-agnostic。例如~~chat可能指 Slack也可能指 Microsoft Teams 或 Discord。该插件在搜索结果中广泛使用~~chat:、~~email:这类动态类别标签它们会在运行时解析为实际连接的工具。各类别下仓库预置/可选的 MCP 服务器见 CONNECTORS.md 的汇总表类别占位符内置服务器其他可选聊天~~chatSlackMicrosoft Teams、Discord邮件~~emailMicrosoft 365—云存储~~cloud storageMicrosoft 365Dropbox知识库~~knowledge baseNotion、GuruConfluence、Slite项目追踪~~project trackerAtlassianJira/Confluence、AsanaLinear、monday.comCRM~~CRM未预配置Salesforce、HubSpot办公套件~~office suiteMicrosoft 365Google Workspace如果没有连接任何 MCP 源技能要求直接、诚实地告知用户To search across your tools, youll need to connect at least one source. Check your MCP settings to add ~~chat, ~~email, ~~cloud storage, or other tools. Supported sources: ~~chat, ~~email, ~~cloud storage, ~~project tracker, ~~CRM, ~~knowledge base, and any other MCP-connected service.更多关于如何引导用户连接新源、源优先级排序、限流感知的细节由 source-management 技能 承载search 技能会与之协同。三、解析用户查询意图、实体与过滤器Step 2拿到查询后需要从五个维度拆解Intent意图用户在找什么决策、文档、人员、状态更新还是一段对话Entities实体提到的人、项目、团队、工具有记忆系统时可用它辅助解码。Time constraints时间约束新鲜度信号如本周、上个月、具体日期。Source hints源提示对特定工具的引用如in ~~chat、that email、the doc。Filters过滤器显式提取查询中的过滤条件技能定义了五类标准过滤器过滤器含义from:按发送者/作者过滤in:按频道、文件夹或位置过滤after:只返回该日期之后的结果before:只返回该日期之前的结果type:按内容类型过滤message、email、doc、thread、file这些过滤器与 search-strategy 技能 中的查询类型识别直接衔接——搜索策略技能先把问题归类为 Decision / Status / Document / Person / Factual / Temporal / Exploratory 七种类型之一再据此决定优先级与搜索侧重。search 技能本身则负责把这些理解落实为每个源上的具体子查询。四、分解子查询每种源用它的原生语法Step 3针对每个可用源用该源的原生搜索语法构造一条针对性子查询。技能为六类源分别给出了翻译规则~~chat聊天用聊天平台的搜索与读取工具from:映射为发送者in:映射为频道/房间日期映射为时间范围过滤器语义型问题用自然语言查询精确匹配用关键词查询。~~email邮件用邮件搜索工具from:映射为发送者日期映射为时间范围过滤器按需把type:映射为附件过滤或主题行搜索。~~cloud storage云存储用文件搜索工具翻译为文件查询语法文件名包含、全文包含、修改日期、文件类型同时考虑文件名和内容——这是云盘场景最容易遗漏的一点。~~project tracker项目追踪用任务搜索或 typeahead 工具映射为任务文本搜索、负责人过滤、日期过滤、项目过滤。~~CRM用 CRM 查询工具跨 Account、Contact、Opportunity 及其他相关对象搜索。~~knowledge base知识库概念性问题用语义搜索精确匹配用关键词搜索。search-strategy 技能进一步给出了过滤器到各源原生语法的具体映射例如 ~~chat 的映射表企业过滤器~~chat 语法from:sarahfrom:sarah或from:USERIDin:engineeringin:engineeringafter:2025-01-01after:2025-01-01before:2025-02-01before:2025-02-01type:threadis:threadtype:filehas:file~~project tracker 的映射则体现为参数形式企业过滤器~~project tracker 参数from:sarahassignee_any或created_by_anyafter:2025-01-01modified_on_after: 2025-01-01type:milestoneresource_subtype: milestone另外当主题可能存在多种叫法时要生成多个查询变体例如用户问 Kubernetes setup 时子查询应覆盖Kubernetes、k8s、cluster、container orchestration。五、并行执行失败不阻塞Step 4子查询必须同时在所有可用源上执行绝不能等一个源完成再搜下一个——总耗时应接近最慢的单源耗时而不是所有源耗时之和这一原则在 search-strategy 技能 中有同样的强调。对每个源执行翻译后的查询连同元数据一起捕获结果时间戳、作者、链接、源类型记录失败或报错的源但绝不让单个源的失败阻塞其他源。完整的执行链路源自 search-strategy 技能可以概括为[User query] ↓ decompose [~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query] ↓ ↓ ↓ ↓ ↓ (parallel execution) ↓ [Merge Rank Deduplicate] ↓ [Synthesized answer]六、排序与去重让答案有主次Step 5去重Deduplication同一信息常常在多个源中重复出现比如一个决策在 ~~chat 里讨论过、又通过邮件确认。技能给出的去重规则识别同一信息的信号文本内容相同或高度相似作者/发送者相同时间戳处于同一短窗口同一天或相邻天引用了同一实体项目名、文档、决策一个源引用了另一个源as discussed in ~~chat、per the email、see the doc。合并方式合并为一条叙事条目列出它出现过的所有源以最完整版本为正文补充各源的独有细节。去重优先级最完整版本 最权威来源官方文档 聊天 最新版本信息演进时以最新为准。不要过度去重同一主题却有不同结论、不同人持不同观点、信息在源之间发生了实质演进决策 v1 vs v2、代表不同时间段——这些应保留为独立条目。排序因子Ranking factors技能定义了四个排序维度并按查询类型调整侧重Relevance相关性结果与查询意图的匹配度Freshness新鲜度状态/决策类查询中越新的结果排名越高Authority权威性事实性问题遵循官方文档 wiki 聊天消息而我们讨论了什么类问题则相反会话 文档Completeness完整性上下文更完整的结果排名更高。search-strategy 技能给出了更细粒度的加权参考按查询类型分配各因子权重总和为 1因子决策类状态类文档类事实类关键词匹配0.30.20.40.3新鲜度0.30.40.20.1权威性0.20.10.30.4完整性0.20.30.10.2同时它还定义了按查询类型变化的权威层级例如事实/政策类Wiki/官方文档 共享文档 邮件公告 聊天消息发生了什么/决策类会议纪要 线程结论 邮件确认 聊天消息状态类任务追踪器 近期聊天 状态文档 邮件更新。七、统一呈现合成答案而非罗列结果Step 6技能要求把响应格式化为合成后的答案而不是原始结果清单。按查询类型给出三种输出模板事实/决策类查询[Direct answer to the question] Sources: - [Source 1: brief description] (~~chat, #channel, date) - [Source 2: brief description] (~~email, from person, date) - [Source 3: brief description] (~~cloud storage, doc name, last modified)探索类查询what do we know about X[Synthesized summary combining information from all sources] Found across: - ~~chat: X relevant messages in Y channels - ~~email: X relevant threads - ~~cloud storage: X related documents - [Other sources as applicable] Key sources: - [Most important source with link/reference] - [Second most important source]查找类查询找某个具体东西[The thing theyre looking for, with direct reference] Also found: - [Related items from other sources]这与 knowledge-synthesis 技能 的产出要求一脉相承用答案开头而不是用搜索过程开头按主题分组而不是按源分组给所有结论附上出处。knowledge-synthesis 技能还补充了信心评估新鲜度 × 权威性 × 一致性、结果量分级汇总1-5 条全量呈现、5-15 条按主题归纳、15 条高层综述并可下钻、冲突信息显式呈现等规则search 技能在合成结果这一步会承接这套方法论。八、边界情况处理Step 7歧义查询当查询可能指向多个不同含义时在搜索前先问一个聚焦的澄清问题而不是猜测API redesign could refer to a few things. Are you looking for: 1. The REST API v2 redesign (Project Aurora) 2. The internal SDK API changes 3. Something else?只有存在会产生截然不同结果的不同解释、歧义会显著影响该搜哪些源时才问如果查询已足够产出有用结果、或歧义可以通过返回多种解释的结果来化解就不要打断用户。search-strategy 技能对此补充了相同的判断准则参考其 Handling Ambiguity 一节。无结果I couldnt find anything matching [query] across [list of sources searched]. Try: - Broader terms (e.g., database instead of PostgreSQL migration) - Different time range (currently searching [time range]) - Checking if the relevant source is connected (currently searching: [sources])部分成功某些源失败[Results from successful sources] Note: I couldnt reach [failed source(s)] during this search. Results above are from [successful sources] only.search-strategy 技能还给出了一整套降级fallback策略源不可用就跳过并标注缺口某源无结果就放宽关键词、去掉日期过滤、尝试同义词所有源都无结果就向用户建议修改查询遇到限流就说明限制、返回其他源的结果并建议稍后重试。查询放宽时应按顺序移除约束先日期过滤再源/位置过滤再次要关键词最后只保留核心实体/主题词。九、使用须知Notes技能在结尾重申了几条贯穿始终的准则永远并行搜索多个源绝不串行把结果合成为答案而不是罗列原始搜索结果包含出处标注让用户可以自行深入核实尊重用户的过滤器语法并针对每个源正确应用查询中提到具体某人时要跨所有源搜索 TA 的消息/文档/提及对时间敏感的查询排序时优先新鲜度即使只连接了一个源也要尽力从该源给出有用的结果。十、实战串联命令、工作流与技能协同在 enterprise-search 插件 README 中search 命令的调用形式为/enterprise-search:search whats the status of Project Aurora? /enterprise-search:search from:sarah about:budget after:2025-01-01 /enterprise-search:search decisions made in #product this week它支持from:、in:、after:、before:、type:过滤器并被智能地应用到各源的原生查询语法中。安装方式# 1. 安装插件 claude plugins add knowledge-work-plugins/enterprise-search # 2. 一条查询搜遍所有已连接源 /enterprise-search:search [your question here] # 3. 生成每日摘要 /enterprise-search:digest --dailyREADME 中给出的一组典型工作流与 search 技能的流程一一对应查找决策when did we decide to switch to Postgres?—— Claude 同时搜 ~~chat#engineering、#infrastructure 中的 postgres、switch、decision、~~email主题含 postgres 的线程、~~cloud storage提及数据库迁移的文档最终合成为一条带时间线的答案3 月 3 日在 #infrastructure 作出决定、Sarah 3 月 4 日邮件确认、迁移计划文档 3 月 5 日更新。查找专家who knows about our Kubernetes setup?—— 综合消息历史与文档作者信息给出候选人与主要 runbook 链接。search 技能在插件中并非孤军奋战它与同目录下的三个技能构成完整的企业搜索体验见 README.md 的 Skills 一节search-strategy查询分解与源特定翻译——把自然语言问题拆成每个源的定向搜索处理歧义源不可用时优雅降级source-management知道哪些 MCP 源可用、引导连接新源、管理源优先级、处理限流knowledge-synthesis把多源结果合并为连贯答案——跨源去重、出处标注、按新鲜度与权威性评估信心、对大量结果做摘要。search 技能负责找到并行检索 合并排序knowledge-synthesis 负责讲清楚合成叙事答案source-management 负责保底源可用性与限流search-strategy 负责瞄准拆解与翻译。四条链路合在一起才构成 README 所描述的一条查询、全部数据源、合成结果。参考与延伸阅读search 技能原文本文主体来源完整执行流程共 7 步 Notes。enterprise-search 插件 README命令用法、安装步骤与工作流示例。CONNECTORS.md~~category占位符机制与各源类别支持的服务器清单。search-strategy 技能查询类型识别、源特定语法映射、加权排序与降级策略。source-management 技能源检测、引导连接、优先级排序与限流处理。knowledge-synthesis 技能去重、出处标注、信心评估与分级摘要。digest 技能search 的姊妹命令按主题生成每日/每周活动摘要。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考