1. 从knowledge-work-plugins这个名字说起它到底在解决什么问题第一次看到knowledge-work-plugins这个仓库名很多人会下意识地把它当成又一个插件合集。但如果你真的在 Claude Code 或 Claude Cowork 里干过几天活就会明白这个名字背后藏着一个很具体的痛点知识工作者的重复劳动没有被工具化。什么叫知识工作的重复劳动举几个我自己天天遇到的场景。每周要写周报格式固定但每次都要重新翻聊天记录、翻提交历史、翻会议纪要然后手动拼成一段话。每次做竞品调研都要打开十几个网页复制粘贴到文档里再手动整理成对比表格。每次代码 review 完都要把意见按必须改/建议改/可以不改三档分类再逐条回复。这些事情单看都不难但加起来一天能吃掉两三个小时。knowledge-work-plugins这个项目想做的事情就是把这些高频、有固定套路、但每次都要手动做的知识工作封装成 Claude Code 可以一键调用的插件。它不是一个软件产品而是一套面向 Claude Code / Claude Cowork 的插件集合通过 slash commands斜杠命令的方式暴露给用户。你在对话框里敲一个/weekly-report它就能自动帮你把这一周的零散信息整理成周报敲一个/competitor-scan它就能按你预设的维度去抓取和对比竞品信息。这里有个关键点需要先讲清楚Claude Code 的插件机制和传统 IDE 插件比如 VS Code 插件完全不是一回事。VS Code 插件是跑在编辑器进程里的代码有完整的 UI 能力而 Claude Code 的插件本质上是一组预定义的 prompt 模板 工具调用编排 上下文注入规则。它不渲染界面它改变的是你按下回车之后Claude 会怎么思考、会调用哪些工具、会按什么格式输出。理解这一点后面所有的设计取舍就都能说得通了。所以knowledge-work-plugins的定位就很清晰了它面向的是每天用 Claude Code 处理非纯编码任务的知识工作者——产品经理、技术写作者、研究员、独立开发者、运营。这些人不一定写代码但他们每天都在和信息整理、格式转换、结构化输出打交道而这恰好是 Claude 最擅长、也最容易被插件化的事情。2. 拆开一个 knowledge-work-plugin 看内部结构2.1 一个插件目录里到底放了什么我拿一个典型的 knowledge-work-plugin 来拆。假设这个插件叫weekly-report它的目录结构大致长这样weekly-report/ ├── plugin.json # 插件元信息名称、版本、描述、作者 ├── commands/ │ └── weekly-report.md # slash command 定义核心就是这个文件 ├── prompts/ │ └── system.md # 系统提示词定义角色和输出规范 ├── templates/ │ └── report.md # 输出模板占位符形式 └── README.md看起来很简单对吧但真正决定这个插件好不好用的是commands/weekly-report.md这个文件。它里面写的不是代码而是一段结构化的自然语言指令告诉 Claude当用户敲/weekly-report的时候你应该先做什么、再做什么、最后按什么格式输出。一个真实的 command 文件大概长这样--- description: 生成本周工作周报 allowed-tools: Read, Grep, Bash --- 请按以下步骤生成本周周报 1. 读取当前目录下 notes/ 文件夹中本周修改过的所有 .md 文件 2. 读取 git log 中本周的提交记录使用 git log --since7 days ago --oneline 3. 将上述信息按完成事项 / 进行中 / 下周计划 / 风险与阻塞四个维度归类 4. 按 templates/report.md 的格式输出不要添加额外解释 注意如果某个维度没有内容写无不要省略该维度。2.2 为什么用 Markdown 而不是 JSON 或 YAML 来定义命令这是我在实际改插件时想明白的一个设计点。很多人第一反应是命令定义应该用结构化格式啊JSON 多清晰。但 Claude Code 的插件偏偏用了 Markdown frontmatter 的组合原因很实在因为 command 的本质是给模型看的 prompt不是给程序解析的配置。模型对自然语言的理解远好于对嵌套 JSON 的理解。你用 JSON 写先读文件再归类再输出模型还得在脑子里把 JSON 翻译成步骤你直接用 Markdown 写步骤模型是直接执行的。frontmatter 里那几个字段description、allowed-tools才是给程序解析的正文部分是给模型看的。这个配置与指令分离的思路是理解整个插件体系的关键。2.3 allowed-tools 字段权限控制的第一道闸门上面例子里有个allowed-tools: Read, Grep, Bash这个字段特别重要但新手最容易忽略。它的作用是限制这个命令能调用哪些工具。为什么需要限制因为 Claude Code 默认可以调用很多工具包括写文件、执行任意 shell 命令。如果一个只是读文件生成周报的命令却拥有写文件和执行任意命令的权限那风险就大了——万一 prompt 被注入或者模型理解偏了可能就把你的文件改了。我自己的经验是给每个 command 分配最小必要权限。只读的命令就只给 Read 和 Grep需要跑 git 的才给 Bash而且最好在 prompt 里明确限定只能用哪几条命令。这个习惯能帮你避开很多模型自作主张的坑。工具典型用途是否建议默认开放Read读取文件内容是风险低Grep搜索文件内容是风险低Glob按模式匹配文件是风险低Bash执行 shell 命令否需明确限定Write写入/修改文件否除非命令本身就要产出文件Edit精确编辑文件否同上3. slash command 的触发逻辑与上下文注入机制3.1 敲下斜杠命令之后Claude 内部发生了什么很多人以为 slash command 就是个快捷输入敲了之后等于帮你打了一段字。这个理解只对了一半。实际上当你敲/weekly-report的时候Claude Code 做了这么几件事第一它去插件目录里找到对应的 command 文件读取 frontmatter 和正文。第二它把正文内容作为系统级指令注入到当前对话的上下文里而不是作为用户消息。第三它根据allowed-tools字段临时调整当前会话的工具权限。第四它把用户在命令后面跟的参数比如/weekly-report --weeklast作为变量传给指令。这个流程里最关键的是第二步指令是作为系统级内容注入的优先级高于普通用户消息。这意味着插件作者写的输出格式要求、步骤约束会比用户随口说的随便写写就行更有约束力。这也是为什么好的插件能保证输出格式稳定——因为它把格式要求写在了系统级指令里。3.2 上下文注入的边界什么该塞进去什么不该写插件最容易犯的错就是恨不得把所有可能用到的信息都塞进上下文。我早期写过一个会议纪要整理插件为了让模型理解会议背景把过去三个月的所有会议纪要都读进来当上下文。结果呢token 爆了响应慢得要死而且模型被大量无关信息干扰输出质量反而下降。后来我总结出一个原则上下文注入要按需、分层、可裁剪。具体来说必注入当前任务直接相关的文件、用户显式提供的参数、输出格式模板。按需注入通过工具调用动态获取的信息比如让模型自己决定要不要读某个文件而不是一次性全塞进去。绝不注入历史对话的完整记录、与当前任务无关的目录内容、大体积的日志文件。在 command 文件里你可以用先判断再读取的写法来实现按需注入。比如1. 先列出 notes/ 目录下的文件 2. 只读取文件名中包含本周日期范围的文件 3. 如果文件数量超过 10 个只读取最近修改的 10 个并提示用户这种写法把读什么的决策权交给了模型而不是在 prompt 里写死。灵活性高很多也不容易爆上下文。3.3 参数传递让一个命令适配多种场景好的 slash command 应该支持参数否则你就得为每个细微差别写一个新命令。参数传递的语法很简单在 command 正文里用$ARGUMENTS或者$1、$2这样的占位符就行。举个我实际在用的例子一个文档翻译命令--- description: 翻译指定文档 allowed-tools: Read, Write --- 将文件 $1 翻译成 $2 语言输出到 $1.translated.md。 要求 - 保留原文的 Markdown 格式 - 代码块内的内容不翻译 - 专业术语首次出现时用中文English格式标注这样/translate README.md 日文就能直接用了。参数机制让插件的复用性上了一个台阶你不用为每种语言写一个命令。4. 从零写一个自己的 knowledge-work-plugin4.1 先想清楚这个任务值不值得做成插件不是所有重复劳动都值得插件化。我踩过的坑是花两小时写了个插件结果那个任务一周才做一次省下的时间还不够写插件的时间。所以动手之前先过一遍这个判断清单这个任务每周至少做 3 次吗频率太低不值得。这个任务的输入和输出格式相对固定吗如果每次都要临时决定格式插件帮不上忙。这个任务的**核心难点是信息整理而不是判断决策**吗插件擅长前者不擅长后者。这个任务用一段 prompt 能描述清楚步骤吗如果步骤复杂到要写几百行可能更适合做成脚本。四条都满足才值得动手。我现在的插件库里只留了 6 个命令都是高频且格式固定的其余的都删了。4.2 手把手写一个竞品信息对比插件假设你要做一个竞品调研插件输入是几个竞品名称输出是一张对比表格。步骤如下。第一步建目录结构。mkdir -p ~/.claude/plugins/competitor-scan/commands mkdir -p ~/.claude/plugins/competitor-scan/templates第二步写 plugin.json。{ name: competitor-scan, version: 1.0.0, description: 按指定维度对比多个竞品信息, author: your-name }第三步写 command 文件commands/competitor-scan.md。--- description: 对比多个竞品的关键信息 allowed-tools: Read, Write, WebFetch --- 对以下竞品进行信息对比$ARGUMENTS 按以下维度逐一调研每个竞品 1. 核心功能定位一句话 2. 目标用户群体 3. 定价模式 4. 主要差异化点 5. 已知的明显短板 输出要求 - 用 Markdown 表格呈现每个竞品一列 - 信息不确定的维度标注待确认不要编造 - 表格下方附一段 200 字以内的综合观察 如果某个竞品信息严重不足单独列出并说明缺什么。第四步测试。在 Claude Code 里敲/competitor-scan 产品A 产品B 产品C看输出是否符合预期。第一次大概率不完美重点看维度是否齐全、有没有编造信息、表格格式是否稳定。第五步迭代。我一般会跑三到五次真实任务每次记录哪里不满意然后回去改 prompt。改的时候一次只改一个点否则你分不清是哪个改动起了作用。4.3 调试插件的三个实用技巧调试插件和调试代码不一样你没有断点只能靠观察输出。我常用的三个方法技巧一让模型说出它的计划。在 command 开头加一句在开始执行前先用一句话说明你打算怎么做。这样你能看到模型的理解是否和你的意图一致。确认没问题后再把这句删掉。技巧二用最小输入测试。别一上来就用真实的大任务测先用一两个文件的假数据跑通流程再上真实数据。这样出问题时容易定位。技巧三把中间结果写出来。如果命令涉及多步处理让模型在每一步后输出中间结果。比如读取文件后先列出你提取到的关键信息再开始归类。这样你能看到是哪一步出的问题。注意调试阶段可以放宽 allowed-tools但调试完一定要收回来。我见过有人调试时开了 Write 权限忘了关结果正式用时模型把源文件覆盖了。5. 插件组合使用把单点工具串成工作流5.1 为什么单个插件往往不够用一个插件解决一个任务但真实工作往往是任务链。比如写周报这件事前面其实还有整理本周会议纪要和汇总本周代码提交两个前置任务。如果你有三个独立插件你得手动依次调用中间还要自己搬运数据。这就没省多少事。Claude Code 的插件体系支持命令嵌套调用——你可以在一个 command 里让模型去调用另一个命令。这样就能把多个单点插件串成一条工作流。5.2 串接实战一个周五收尾工作流我实际在用的一个组合命令叫/friday-wrapup它内部依次调用了三个子命令--- description: 周五收尾工作流整理纪要 汇总提交 生成周报 allowed-tools: Read, Grep, Bash, Write --- 按顺序执行以下步骤 1. 调用 /meeting-summary 整理本周所有会议纪要输出到 notes/weekly-meetings.md 2. 调用 /commit-digest 汇总本周代码提交输出到 notes/weekly-commits.md 3. 读取上面两个文件调用 /weekly-report 生成最终周报输出到 reports/本周周报.md 每一步完成后简要报告该步的产出。如果某一步失败停止后续步骤并说明原因。这个组合命令把我周五下午原本要花 40 分钟的事情压缩到了 5 分钟——敲一个命令等它跑完检查一下输出。关键在于每一步的产出都落盘成文件这样即使中间某步出问题前面的成果不会丢可以手动接着做。5.3 组合时的依赖管理与失败处理串接多个命令时最大的风险是前一步的输出格式变了后一步读不懂。我的应对办法是在子命令的 prompt 里明确约定输出格式并且在组合命令里做格式校验。比如/meeting-summary的输出我约定必须是## 会议名 / 日期 / 参会人 / 决议事项 / 待办这样的固定结构。组合命令在调用/weekly-report之前会先检查文件里是否包含这几个标题缺了就报错而不是硬着头皮往下走。另外组合命令里要明确失败即停止。默认情况下模型可能倾向于尽力而为某步失败了还继续往下做结果产出一堆垃圾。加一句如果某一步失败停止后续步骤并说明原因能避免这个问题。组合模式适用场景风险点串行链式有明确先后依赖的任务前步失败导致后步全废并行汇总多个独立信息源汇总结果合并时格式冲突条件分支根据输入类型走不同流程分支判断错误6. 那些文档里不会写的坑6.1 prompt 里的隐含假设是最隐蔽的 bug我写过一个代码注释生成插件测试时一直很好用直到有次在一个 Python 项目里用它生成的注释全是 JavaScript 风格。排查了半天才发现我的 prompt 里写的是为函数生成 JSDoc 风格注释——我默认了所有项目都是 JS。这就是隐含假设。解决办法在 prompt 里显式声明先判断项目类型再选择对应的注释规范。凡是你在写 prompt 时脑子里默认成立的前提都要写出来让模型去验证而不是让它猜。6.2 输出格式的漂移问题同一个命令跑十次可能有两次输出格式不一样。这不是模型坏了而是 prompt 里的格式约束不够硬。我总结的经验是格式约束要给例子而不是给描述。你说输出一个表格模型可能给你三种不同风格的表格你直接给一个填好示例的表格模板它就会严格照着来。按以下格式输出严格照抄表头和分隔线 | 维度 | 竞品A | 竞品B | |------|-------|-------| | 定位 | ... | ... |6.3 权限开太大导致的越界操作前面提过 allowed-tools这里再强调一次实际案例。我有个朋友写了个整理下载文件夹的插件给了 Bash 权限prompt 里写把重复文件删掉。结果模型判断重复的标准和他想的不一样删掉了一批他其实想保留的文件。凡是涉及删除、覆盖、移动的操作一定要在 prompt 里加先列出计划等用户确认后再执行。这一句话能救你很多次。6.4 插件版本升级后的静默失效Claude Code 本身在快速迭代有时候一次版本更新会让某些 command 的行为发生变化。我遇到过升级后某个命令突然不读文件了排查发现是新版本对 allowed-tools 的解析更严格了。建议给每个插件在 plugin.json 里标注它适配的 Claude Code 版本范围升级后跑一遍回归测试。我现在的习惯是每次 Claude Code 大版本更新就把六个常用命令各跑一遍确认没问题再继续用。7. 关于插件生态的一点个人观察knowledge-work-plugins这类项目的价值不在于它提供了多少个现成命令而在于它示范了一种把个人工作流沉淀成可复用资产的方法。我用了大半年 Claude Code 插件之后最大的体会是真正提升效率的不是插件本身而是写插件这个动作逼着你去复盘自己的工作——哪些步骤是真正重复的哪些判断其实可以标准化哪些信息每次都要重新找。我现在维护的插件库不大就六个命令但每一个都是被真实工作反复打磨过的。它们不追求通用只解决我自己的具体问题。如果你刚开始接触这块我的建议是别急着去装一堆别人的插件先挑一个你每周都要做、且做得最烦的任务自己写一个命令试试。写的过程比用现成的收获大得多。最后分享一个我最近在用的扩展思路把插件的输出直接接到下一个插件的输入上形成信息采集 → 结构化 → 输出成品的流水线。比如竞品调研插件产出的表格可以直接喂给一个生成分析报告的插件。这种流水线式的组合比单个命令的威力大一个量级但前提是每个环节的输出格式都要足够稳定——这又回到了前面反复强调的那件事格式约束是插件可靠性的地基。
