1. 项目缘起与核心定位第一次看到knowledge-work-plugins这个仓库名的时候我正处在“每天跟 Claude Code 打交道、但总觉得差点意思”的阶段。那会儿我已经把 Claude Code 当主力开发工具用了小半年slash commands 也配了一堆但每次开新项目还是得把之前写好的命令文件手动拷来拷去团队里几个人各写各的风格完全不统一。直到有人甩给我这个仓库我才意识到原来插件体系可以这么玩。knowledge-work-plugins本质上是一个面向知识工作场景的插件集合仓库。它不是一个框架也不是一个 SDK而是一批已经写好、可以直接拿来用的 Claude Code 插件与 slash commands 的集合。你可以把它理解成一个“命令模板库”——里面沉淀的是知识工作者在日常工作中反复用到的操作模式比如文档整理、会议纪要提炼、需求拆解、代码审查辅助、知识库检索等等。每个插件都对应一个具体的、可复用的工作流。它解决的核心问题有三个。第一是重复劳动很多操作你每天都在做但每次都要重新描述一遍给模型听效率极低。第二是一致性团队里每个人对同一个任务的理解和提示词写法都不一样输出质量参差不齐。第三是上手门槛Claude Code 本身能力很强但新手往往不知道怎么把它的能力组织成一套顺手的工作流插件就是现成的答案。适合谁来参考我觉得三类人最应该看。一是刚接触 Claude Code 的开发者想快速建立一套可用的命令体系而不是从零摸索二是已经在用但想系统化的人手里有一堆零散命令需要参考一个成熟的组织方式三是团队技术负责人想给团队定一套统一的 AI 辅助工作规范这个仓库可以直接当起点。需要说明的是这个仓库里的插件主要围绕 Claude Code 的 slash commands 机制展开所以你得先有一个能正常运行的 Claude Code 环境。至于具体怎么装、怎么配后面会详细讲。2. 插件机制到底是怎么运转的2.1 slash commands 的加载逻辑要理解knowledge-work-plugins得先搞清楚 Claude Code 的 slash commands 是怎么被加载和执行的。这不是什么黑魔法机制其实很朴素。Claude Code 在启动时会扫描几个固定位置寻找命令定义文件。这些文件通常是 Markdown 格式放在特定的目录下比如项目根目录的.claude/commands/或者用户主目录下的全局配置目录。每个.md文件对应一个 slash command文件名就是命令名。比如你放一个review.md进去那在 Claude Code 里输入/review就能触发它。文件内容分两部分前面是可选的 frontmatter用---包裹的元数据后面是提示词正文。frontmatter 里可以定义description命令描述、argument-hint参数提示等字段。正文就是你希望模型执行的指令可以用$ARGUMENTS或$1、$2这样的占位符接收用户输入的参数。注意不同版本的 Claude Code 对命令目录的约定可能略有差异建议先在你自己的环境里确认一下实际扫描路径别想当然。这个机制的好处是零依赖、纯文本、可版本控制。你写的命令就是普通的 Markdown 文件可以提交到 Git可以 code review可以分享给同事。knowledge-work-plugins整个仓库就是建立在这个朴素机制之上的。2.2 为什么用插件而不是直接写提示词有人可能会问我直接在对话里把要求打出来不就行了为什么要费劲写成插件我踩过的坑告诉我直接写提示词有三个致命问题。第一长提示词容易丢细节。你每次手打的时候总会漏掉一两个约束条件导致输出不稳定。第二无法复用。你今天写了一段很好的提示词明天换个项目就得重新写。第三团队无法共享。你脑子里的最佳实践别人根本不知道。插件把提示词固化成了文件等于把你的经验沉淀成了资产。而且 slash command 的调用方式极其顺手/meeting-notes比打一大段话快得多。更重要的是插件可以带参数、可以组合、可以嵌套调用这是裸提示词做不到的。从工程角度看这其实就是把“提示词工程”升级成了“提示词资产管理”。knowledge-work-plugins的价值不在于它写了多牛的提示词而在于它示范了一套可维护、可扩展、可协作的组织方式。2.3 仓库的整体结构思路虽然我拿到的信息里没有仓库的完整目录树但根据这类项目的常见实践knowledge-work-plugins大概率是按“场景域”来组织插件的。比如可能分成文档处理类、会议协作类、代码辅助类、知识检索类等几个大方向每个方向下面放若干具体的命令文件。这种按场景而非按技术分类的方式我认为是对的。因为用户找插件的时候脑子里想的是“我要整理会议纪要”而不是“我要一个文本处理类的命令”。按场景组织检索成本最低。另外一个成熟的插件仓库通常还会包含每个插件的使用说明、参数定义、示例输入输出、以及可能的依赖说明。这些“周边文档”往往比插件本身更重要因为它们决定了别人能不能顺利上手。3. 核心插件类型与实操拆解3.1 文档与知识整理类插件这类插件是我用得最多的。知识工作者的日常里大量时间花在“把一堆散乱信息整理成结构化文档”上。比如把会议录音转写稿整理成纪要把零散笔记整理成知识条目把长文档压缩成摘要。一个典型的文档整理插件它的提示词正文大概会包含这几个要素输入格式说明、输出结构模板、处理规则、边界条件。我拿会议纪要场景举例一个合格的命令文件应该长这样--- description: 将会议记录整理成结构化纪要 argument-hint: [粘贴会议原始记录] --- 你是一名专业的会议纪要整理助手。请将以下原始会议记录整理成结构化纪要。 要求 1. 提取会议主题、时间、参与人如原文有 2. 按议题分段每个议题包含讨论要点、结论、待办事项 3. 待办事项必须明确责任人和截止时间原文没提到的标注“待确认” 4. 保留关键数据和时间节点删除口语化冗余 5. 输出使用 Markdown 格式二级标题分议题 原始记录 $ARGUMENTS这里有几个细节值得说。argument-hint会在用户输入命令时给出提示降低使用门槛。$ARGUMENTS是占位符用户输入的内容会替换到这里。要求里明确写了“原文没提到的标注待确认”这是为了防止模型编造信息——这个约束非常关键我见过太多不加约束导致模型瞎编责任人的案例。实操心得写这类插件时一定要在提示词里明确“不知道就说不知道”。知识工作场景对准确性要求极高模型幻觉的代价很大。3.2 代码辅助与审查类插件Claude Code 本身就是为代码场景设计的所以代码辅助类插件是重头戏。knowledge-work-plugins里应该包含代码审查、重构建议、测试生成、提交信息撰写等命令。代码审查类插件的写法跟文档类不太一样它需要模型理解代码上下文。一个实用的/review命令提示词里通常会要求模型先理解改动意图再从正确性、可读性、性能、安全性几个维度审查最后给出具体修改建议而非泛泛而谈。我自己的经验是代码审查插件的提示词里最好加上“按严重程度排序”和“每条建议给出代码示例”这两个要求。前者帮你快速定位关键问题后者让建议可直接落地。另外可以设计一个参数来控制审查的严格程度比如/review strict和/review quick走不同的规则分支。--- description: 审查代码改动 argument-hint: [粘贴 diff 或代码片段] --- 请审查以下代码改动。 审查维度按优先级 1. 正确性逻辑是否有误、边界是否处理 2. 安全性是否有注入、越权、敏感信息泄露风险 3. 性能是否有明显的低效操作 4. 可读性命名、结构、注释 输出格式 - 按严重程度从高到低排列问题 - 每个问题给出位置、原因、修改建议附代码示例 - 最后给出总体评价 代码 $ARGUMENTS3.3 需求拆解与任务规划类插件这类插件在项目启动阶段特别有用。你拿到一段模糊的需求描述用插件把它拆成可执行的任务列表每个任务带验收标准。这比人工拆解快得多而且不容易漏。提示词设计上关键是要求模型输出“可验证”的任务。什么叫可验证就是每个任务都有明确的完成标准而不是“优化性能”这种没法验收的表述。我会在提示词里强制要求每个任务包含任务描述、验收标准、预估工作量、依赖关系。这类插件还有一个进阶用法让它输出成特定格式比如可以直接粘贴到项目管理工具里的 Markdown 表格或者符合某种任务描述规范的文本。这样拆解完就能直接用省去二次整理。3.4 插件之间的组合与嵌套单个插件好用但真正的威力在于组合。Claude Code 支持在一个命令里引用另一个命令的输出或者把多个命令串成流水线。举个例子你可以先用/extract-requirements从需求文档里提取要点再用/plan-tasks把要点拆成任务最后用/estimate给任务估时。三个命令串起来就是一条完整的“需求到计划”流水线。实现组合的方式有几种。一种是手动串联你依次调用命令把上一个的输出粘贴给下一个。另一种是在命令的提示词里直接引用其他命令让模型按顺序执行。后者更自动化但对提示词设计要求更高。注意组合使用时要注意上下文长度。多个命令的输出叠加起来可能超出模型的上下文窗口导致后面的命令“看不到”前面的内容。建议在关键节点做一次摘要压缩。4. 从零搭建自己的插件工作流4.1 环境准备与目录规划动手之前先把环境理清楚。你需要一个能正常运行的 Claude Code这个前提不用多说。然后确定你的命令文件放哪里。我的建议是分两层全局命令放用户主目录下的配置目录这些是你所有项目都会用到的通用命令比如/review、/explain项目命令放项目根目录的.claude/commands/这些是跟具体项目强相关的比如某个项目的特定部署流程。这样分层的好处是全局命令保持精简稳定项目命令可以随项目演进。团队协作时项目命令跟着代码库走新人 clone 下来就能用。目录结构大概是这样~/.claude/commands/ # 全局命令 review.md explain.md summarize.md your-project/.claude/commands/ # 项目命令 deploy-check.md api-review.md4.2 命令文件的编写规范写命令文件有几个我总结的规范能显著提升可用性。命名要动词开头。review、summarize、extract比reviewer、summary好因为用户是在“执行一个动作”。命名还要避免歧义/check太泛/check-security就明确得多。frontmatter 要写全。description一定要写它会在命令列表里显示是用户选择命令的主要依据。argument-hint也要写告诉用户该传什么参数。提示词要分层次。我习惯按“角色设定 → 任务描述 → 具体要求 → 输出格式 → 输入占位”的顺序组织。角色设定让模型进入状态具体要求约束输出质量输出格式保证结果可用。留好扩展点。提示词里可以用条件判断比如“如果参数包含 strict则……否则……”。这样一条命令能覆盖多种场景不用为每个变体单独写文件。4.3 参数传递与动态内容注入Claude Code 的命令参数机制比很多人想的要灵活。除了$ARGUMENTS接收全部参数还可以用$1、$2接收位置参数。这意味着你可以设计带多个参数的命令。比如一个/translate命令可以设计成/translate en 你好世界$1是目标语言$2是待翻译文本。提示词里分别引用这两个占位符就行。更进阶的用法是动态注入文件内容。有些实现支持在命令里引用文件路径让模型读取文件内容作为输入。这样你就不用手动粘贴了直接/review-file src/main.py就能审查指定文件。实操心得参数设计要克制。超过三个参数的命令用户记不住不如拆成多个命令或者用交互式的方式逐步收集参数。4.4 版本管理与团队协作插件文件是纯文本天然适合 Git 管理。但团队协作时有几个坑要注意。第一命令命名冲突。两个人可能都写了一个/review合并时就会打架。解决办法是加前缀比如/fe-review前端、/be-review后端或者按团队约定统一命名。第二提示词风格不统一。每个人写提示词的习惯不同导致输出格式五花八门。建议团队定一份提示词编写规范至少统一输出格式和关键约束。第三变更要 review。提示词的改动会直接影响输出质量应该像代码一样走 review 流程。我见过因为改了一个约束条件导致整个团队输出质量下降的案例。5. 常见问题与排查实录5.1 命令不生效的排查思路最常见的问题就是文件放好了但输入/xxx没反应。排查顺序我一般是这样的。先确认文件位置对不对。不同版本的 Claude Code 扫描路径可能不同先查文档或实测确认。然后确认文件扩展名是.md不是.txt或.markdown。再确认文件名没有特殊字符中文名、空格、大写字母都可能出问题建议全小写加连字符。如果位置和命名都没问题检查 frontmatter 格式。---必须是文件的第一行前后不能有空行。YAML 语法错误会导致整个文件被忽略。我踩过这个坑一个冒号后面少了个空格排查了半小时。最后确认命令是否需要重启才生效。有些实现是启动时扫描一次新增文件需要重启 Claude Code 才能识别。5.2 输出质量不稳定的应对同一个命令有时候输出很好有时候一塌糊涂。这种不稳定通常来自三个原因。一是输入差异太大。你的提示词可能只对某种格式的输入有效换个格式就崩了。解决办法是在提示词里增加输入格式的容错说明或者要求模型先判断输入类型再处理。二是提示词约束不够。模型有自由发挥的空间就会发挥得五花八门。增加明确的输出格式约束、字段约束、长度约束能显著提升稳定性。三是上下文干扰。如果对话历史很长模型可能被前面的内容带偏。建议在执行关键命令前开新对话或者用命令清空上下文。5.3 参数传递失败的常见原因参数传不进去通常是这几个原因。占位符拼写错误$ARGUMENTS写成了$ARGUMENT或$arguments大小写敏感。参数里有特殊字符比如引号、反斜杠被 shell 转义了。参数太长超出了命令行长度限制。排查方法很简单在提示词里加一句“请先复述你收到的参数”这样你能直接看到模型实际收到了什么。这个方法我用了很多次屡试不爽。5.4 插件冲突与优先级问题当全局命令和项目命令同名时谁生效这个行为取决于具体实现有的项目命令覆盖全局有的相反。我的建议是主动避免同名不要依赖优先级规则因为规则可能随版本变化。如果确实需要同名在命令的description里写清楚这是哪个层级的命令避免混淆。团队协作时把命名规范写进文档从源头杜绝冲突。问题现象可能原因排查方法命令不出现文件位置错误确认扫描路径命令不出现frontmatter 语法错误检查 YAML 格式参数为空占位符拼写错误加复述参数的调试语句输出格式乱约束不够增加格式和字段约束输出质量波动输入差异大增加输入容错说明命令被覆盖命名冲突检查全局与项目命令6. 进阶玩法与扩展方向6.1 把插件做成可配置的基础插件是写死的提示词进阶玩法是让它可配置。你可以在命令目录旁边放一个配置文件提示词里引用配置项。比如审查严格程度、输出语言、是否包含示例都可以做成配置。这样一条命令能适配不同场景不用维护多个变体。配置的读取方式取决于 Claude Code 的能力如果它支持读取文件那配置文件就能直接注入如果不支持可以用参数传递的方式模拟。6.2 插件与外部工具的联动Claude Code 能执行 shell 命令这意味着插件可以调用外部工具。比如一个/test命令可以先运行测试套件再把失败结果交给模型分析。一个/deploy命令可以调用部署脚本再让模型检查部署日志。这种联动把 Claude Code 从“对话工具”变成了“工作流引擎”。但要注意安全边界涉及写操作、删除操作、生产环境操作的命令一定要加确认步骤别让模型自动执行危险操作。6.3 建立团队插件库当团队规模上来之后零散的插件文件就不够用了。你需要一个团队级的插件库包含统一的命名规范、提示词编写指南、插件模板、review 流程、版本管理策略。knowledge-work-plugins本身就是一个很好的参考模板。你可以 fork 它删掉不需要的加上自己团队的形成内部版本。关键是建立维护机制插件库不是建完就完事需要持续迭代。我个人的体会是插件库的价值随时间增长。刚开始可能只有几个命令用着用着你会发现越来越多可以沉淀的场景半年下来就是一套相当完整的资产。而且这套资产是跟着团队走的人走了知识还在这是它比“个人提示词笔记”强的地方。6.4 持续迭代的节奏把控最后说说迭代节奏。我的建议是小步快跑按需新增。不要一开始就想设计一套完美体系那只会让你迟迟不动手。先用起来遇到重复劳动就沉淀一个命令用着不顺手就改改完继续用。每个月花半小时回顾一下这个月新增和修改的命令清理掉不再用的合并重复的优化高频使用的。这个习惯坚持下来你的插件库会越来越贴合实际工作而不是变成一堆没人用的僵尸文件。插件这东西写得好不好用一周就知道。别追求一次到位追求持续可用。