1. 从knowledge-work-plugins这个命名说起它到底想解决什么问题第一次看到knowledge-work-plugins这个仓库名我的直觉是这不是又一个工具集合而是一套面向知识工作者的能力扩展层。知识工作knowledge work这个词本身就很有意思——它指的不是写代码、不是跑数据而是那些以信息处理、文档撰写、方案设计、研究分析、会议纪要、需求梳理为核心的脑力劳动。这类工作的共同特点是输入是零散的信息输出是结构化的成果中间过程高度依赖个人的经验、模板和判断力。而plugins这个词在 Claude Code 和 Claude Cowork 的语境下指的是一套可以挂载到 CLI 或协作环境里的扩展机制。它通常包含 slash commands斜杠命令、技能定义、提示词模板、工作流编排等。把这两个词拼在一起knowledge-work-plugins的定位就很清楚了把知识工作中反复出现的套路沉淀成可复用的命令和技能让 AI 助手从通用聊天变成懂你业务的专业助手。我为什么对这个方向特别有感触因为过去一年我见过太多人用 Claude Code 的方式是打开终端问一句等回答复制粘贴。这种方式在写代码时还行但一旦进入知识工作场景——比如写一份竞品分析、整理一次访谈记录、生成一份周报——效率就断崖式下跌。原因很简单知识工作的上下文太长、格式要求太细、个人偏好太强靠每次现敲提示词根本不可能稳定复现。knowledge-work-plugins这类项目的价值就在于它把提示词工程升级成了工作流工程。你不再需要每次重新描述我要一份什么样的文档而是通过一个 slash command 直接触发一整套预设好的流程读取指定文件、按固定结构分析、输出符合你团队规范的格式。这才是知识工作者真正需要的东西。提示如果你之前只用过 Claude Code 的对话模式从没接触过 plugins 和 slash commands建议先花半小时把官方文档里关于 plugin 目录结构和 command 定义格式的部分读一遍否则后面很多设计思路会看不懂。2. 拆解 knowledge-work-plugins 的核心构成不只是命令集合2.1 plugin 目录结构里藏着设计者的意图一个典型的 Claude Code plugin目录结构大致是这样的knowledge-work-plugins/ ├── .claude-plugin/ │ └── plugin.json ├── commands/ │ ├── summarize.md │ ├── weekly-report.md │ └── meeting-notes.md ├── skills/ │ └── research-assistant/ │ └── SKILL.md └── README.md这个结构看起来简单但每一层都有讲究。plugin.json是插件的元数据入口声明插件名称、版本、作者、包含哪些命令和技能。commands/目录下每个.md文件就是一个 slash command文件名就是命令名。skills/目录则是更重量级的能力封装通常包含更复杂的提示词逻辑和工具调用编排。我特别想强调的是commands/和skills/的区别这是很多人第一次接触时最容易混淆的地方。command 是一次性动作skill 是持续能力。比如/summarize是一个 command你给它一段文本它给你摘要任务结束。而一个 research-assistant skill 可能包含搜索资料→筛选来源→交叉验证→生成报告的完整链路它会在多轮交互中持续生效。2.2 slash command 的本质把提示词模板化slash command 的文件内容通常长这样--- description: 将输入内容整理为结构化摘要 --- 请将以下内容整理为结构化摘要要求 1. 提取 3-5 个核心观点 2. 每个观点附带原文依据 3. 输出格式为 Markdown 列表 4. 如果内容涉及数据单独列出数据要点 待处理内容 $ARGUMENTS这里有几个关键设计点值得说。第一frontmatter 里的description决定了这个命令在命令列表里怎么显示写得好不好直接影响你会不会想起来用它。第二$ARGUMENTS是参数占位符用户输入命令时跟的内容会替换到这里。第三提示词里明确规定了输出格式这是保证结果稳定的核心。我自己的经验是写 command 时格式约束比内容约束更重要。你告诉 AI分析得深入一点它可能给你一堆废话但你告诉它输出必须是三级标题加无序列表每点不超过 50 字它就会老老实实按格式来。知识工作的产出物往往是要给别人看的格式一致性直接决定了专业度。2.3 为什么用 Markdown 而不是 JSON 或 YAML 定义命令这个问题我被问过好几次。答案其实很实际Markdown 的 frontmatter 加正文结构天然适合元数据 长文本提示词这种组合。JSON 写长提示词要转义换行YAML 的多行字符串缩进容易出错而 Markdown 正文就是纯文本怎么写都行。更重要的是Markdown 文件本身可读性极强团队成员 review 一个 command 的时候直接打开就能看懂逻辑不需要任何工具。3. 知识工作场景下最值得做的几类 plugin3.1 文档处理类摘要、改写、格式转换这是最基础也最高频的一类。知识工作者每天要处理大量文档会议记录、需求文档、研究报告、邮件往来。这类 plugin 的核心价值是把非结构化输入转成结构化输出。我做过一个/digest命令专门处理长文档。它的逻辑是先让 AI 识别文档类型是会议记录还是技术方案还是市场报告然后根据类型选择不同的摘要模板。会议记录重点提取决议事项待办负责人技术方案重点提取背景方案风险市场报告重点提取数据趋势建议。这个先分类再处理的思路比直接摘要的效果好很多因为不同文档的信息密度分布完全不同。实操中有一个坑要注意长文档不要一次性塞给 AI。超过一定长度后模型对中间部分的注意力会下降摘要容易漏掉关键信息。我的做法是先用命令把文档按章节切分逐段摘要最后再合并。虽然多了一步但准确率提升明显。3.2 研究分析类竞品调研、资料综述这类 plugin 更接近 skill 的形态因为它需要多步骤、多轮次。一个典型的竞品调研 skill 可能包含读取用户提供的竞品列表和调研维度对每个竞品生成结构化的信息采集清单引导用户补充缺失信息或调用搜索工具按统一框架生成对比分析输出结论和建议这里的关键设计是框架先行。你不能让 AI 自由发挥去分析竞品那样每次输出的维度都不一样没法对比。正确做法是在 skill 里硬编码一套分析框架比如产品定位、目标用户、核心功能、定价策略、优劣势所有竞品都按这个框架填。注意研究分析类 plugin 最容易出现的问题是幻觉引用。AI 可能会编造不存在的数据或来源。我的应对方法是在提示词里强制要求所有数据必须标注来源无法确认的信息标注为待核实并且在输出后人工过一遍。3.3 沟通协作类周报、会议纪要、邮件草稿这类 plugin 的特点是模板化程度极高但个性化需求也极强。每个团队的周报格式都不一样每个领导的邮件偏好都不同。所以这类 plugin 的设计重点不是通用而是可配置。我的做法是在 command 里留出配置区让用户可以在文件顶部定义自己的模板变量--- description: 生成本周工作周报 --- 本周周报请按以下结构生成 - 本周完成$DONE - 进行中$DOING - 下周计划$NEXT - 风险与阻塞$RISK 语气要求简洁、客观、不夸大然后用户只需要在调用时填入对应内容或者让 AI 从 git log、任务管理工具里自动提取。这种半自动的方式比全自动更实用因为知识工作的很多信息是存在人脑子里的工具提取不全。3.4 个人知识管理类笔记整理、标签生成这类 plugin 面向的是 Obsidian、Notion、Logseq 这类笔记工具的用户。核心需求是把随手记的碎片信息整理成有结构、有标签、可检索的知识卡片。我见过一个很聪明的设计一个/atomic命令把一段长笔记拆成多个原子笔记每条只讲一个概念然后自动生成双向链接建议。这个思路来自 Zettelkasten 卡片盒笔记法用 AI 来做拆分和链接效率比手动高太多。4. 从零搭建一个 knowledge-work plugin 的完整流程4.1 环境准备与目录初始化假设你已经装好了 Claude Code安装方式这里不展开官方文档写得很清楚接下来是创建 plugin 目录。我建议不要直接在全局配置目录里改而是新建一个独立目录方便版本管理和分享。mkdir -p ~/my-knowledge-plugins/.claude-plugin mkdir -p ~/my-knowledge-plugins/commands mkdir -p ~/my-knowledge-plugins/skills cd ~/my-knowledge-plugins然后创建plugin.json{ name: knowledge-work-plugins, version: 0.1.0, description: 面向知识工作的命令与技能集合, author: your-name, commands: [./commands], skills: [./skills] }这里有个细节commands和skills字段是数组意味着你可以把命令分散在多个目录里。我一般会按场景分子目录比如commands/writing/、commands/research/这样命令多了之后不会乱。4.2 写第一个 command从最简单的摘要开始创建commands/summarize.md--- description: 将长文本整理为结构化摘要 --- 你是一位专业的信息整理助手。请对以下内容进行处理 处理要求 1. 先用一句话概括整体主题 2. 提取 3-5 个核心要点每个要点用一句话说明 3. 如果内容包含数据、日期、人名等关键信息单独列出 4. 如果内容有明显的逻辑结构如总分、并列、递进在摘要中体现出来 输出格式 ## 主题 一句话 ## 核心要点 - 要点1 - 要点2 ## 关键信息 - 信息1 - 信息2 待处理内容 $ARGUMENTS写完保存然后在 Claude Code 里加载这个 plugin 目录输入/summarize加上一段文本就能看到效果。4.3 调试与迭代怎么判断一个 command 写得好不好我的判断标准有三条第一输出格式是否稳定。连续跑五次如果五次输出的结构完全一致说明格式约束到位了。如果每次结构都不一样说明提示词里的格式描述不够硬。第二边界情况是否处理。给一段超长文本、一段空文本、一段乱码文本看命令会不会崩。好的 command 应该在提示词里就考虑到这些情况比如如果输入内容为空直接返回未检测到有效内容。第三是否真的省时间。如果一个 command 用起来比手动做还慢那它就没有存在价值。我一般会记录使用前后的耗时对比只有明显提效的 command 才会保留。4.4 把 command 升级成 skill 的时机当你的需求从单次处理变成多轮协作时就该考虑 skill 了。比如摘要 command 只能处理你给它的文本但如果你想要一个能主动追问、能读取文件、能分章节处理的摘要助手那就需要 skill。skill 的SKILL.md结构更复杂通常包含--- name: research-assistant description: 协助进行资料研究和信息整理 --- ## 能力说明 这个 skill 能做什么 ## 工作流程 分步骤描述 ## 工具使用 需要调用哪些工具怎么调用 ## 输出规范 最终产出物的格式要求skill 的核心是流程编排它定义的不是一次回答而是一套工作方法。5. 实操中踩过的坑与应对经验5.1 命令命名冲突与覆盖问题我一开始把所有命令都放在commands/根目录下结果命令一多就出现了命名冲突。比如我写了一个/report用于生成周报后来又写了一个/report用于生成研究报告后者直接把前者覆盖了。解决办法是按场景分目录 前缀命名。比如commands/weekly/report.md对应/weekly-reportcommands/research/report.md对应/research-report。虽然命令名变长了但不会冲突而且一看就知道是干什么的。5.2 提示词里的隐性假设导致输出跑偏有一次我写了一个/translate命令本意是中英互译。结果测试时输入一段日文它给我翻译成了中文但我根本没要求处理日文。问题出在提示词里我写了将输入内容翻译为中文或英文AI 就默认所有输入都要翻译。后来我改成如果输入是中文则翻译为英文如果是英文则翻译为中文如果是其他语言则先询问用户目标语言。这个改动看起来小但避免了大量误操作。提示写提示词时一定要把不做什么也写清楚。只写做什么的提示词在边界情况下很容易失控。5.3 长上下文下的性能问题知识工作的输入经常很长一份报告可能几万字。我实测下来当输入超过一定长度后命令的响应时间会明显变长而且输出质量会下降。我的应对策略是分块处理 结果合并。具体做法是在 command 里加一段逻辑如果输入超过阈值先按段落切分逐块处理最后合并结果。虽然实现起来麻烦一点但效果稳定得多。另一个技巧是用文件引用代替直接粘贴。Claude Code 支持读取本地文件与其把几万字粘贴到命令行不如让命令去读文件。这样既避免了终端卡顿也方便重复处理。5.4 团队协作时的版本管理plugin 一旦要在团队里共享版本管理就很重要。我的做法是每个 command 文件顶部用注释标注作者和最后修改时间用 git 管理整个 plugin 目录重大改动前先复制一份到commands/_archive/备份在 README 里维护一份命令清单说明每个命令的用途和用法这样即使有人改坏了某个命令也能快速回滚。6. 让 plugin 真正融入日常工作流的几个建议6.1 从最高频的场景开始不要贪多我见过很多人一上来就想做一个全能知识工作助手结果写了二十个命令最后常用的就两三个。正确的做法是先找出你每天重复次数最多的动作把它做成命令用顺了再扩展。对我来说最高频的是整理会议记录和生成周报这两个命令我每天都在用。其他命令都是后来慢慢加的。6.2 命令的输出要能直接进入下一个环节知识工作是一个链条调研→分析→撰写→review→发布。如果你的命令输出格式和下一个环节的输入格式对不上那每次都要手动调整效率就没了。我的做法是统一中间格式。所有分析类命令的输出都用同一套 Markdown 结构这样撰写类命令可以直接读取分析结果不需要额外转换。6.3 定期清理和重构命令写多了之后会出现功能重叠、命名混乱、提示词过时等问题。我一般每个月花半小时做一次清理删掉三个月没用过的命令合并功能相似的命令更新提示词里过时的信息。这个习惯看起来不起眼但能让你的 plugin 库始终保持可用状态而不是变成一个越积越大的垃圾堆。6.4 把个人经验沉淀进提示词这是我觉得最有价值的一点。知识工作的核心竞争力是个人经验而 plugin 是把经验固化的最佳载体。比如你在写方案时有一套自己的检查清单那就把它写进 command 的提示词里你在做调研时有一套固定的信息源那就把它写进 skill 的流程里。时间长了你的 plugin 库就变成了你的第二大脑它不只是工具而是你工作方法的数字化身。这也是knowledge-work-plugins这个方向最吸引我的地方——它让 AI 助手真正长成了懂你的样子而不是一个每次都要重新调教的陌生人。我在实际使用中最大的体会是不要追求一次写完美而是在使用中不断打磨。我最早的/summarize命令和现在的版本已经完全不同了中间改了十几版。每一版都是因为在实际使用中发现了问题然后针对性优化。这个过程本身就是知识工作的一部分而 plugin 只是把这个过程变得可复用、可积累。
