1. 从零认识 knowledge-work-plugins它到底解决什么问题第一次看到knowledge-work-plugins这个仓库名很多人会以为它只是某个工具的插件合集随手 clone 下来翻两眼就丢到一边。但如果你真正在 Claude Code 或 Claude Cowork 里干过一段时间的活就会发现这个仓库解决的是一个非常具体的痛点把散落在各个项目里的斜杠命令、技能定义、工作流脚本收敛成一套可复用、可版本管理、可跨项目迁移的插件体系。说白了它就是一个“知识工作者的插件工具箱”。你在日常使用 Claude Code 的时候是不是经常遇到这种情况——每次开一个新项目都要重新写一遍.claude/commands/下面的斜杠命令每次想让 Claude 按照固定的格式输出周报、会议纪要、代码审查意见都要重新粘贴一遍提示词团队里几个人各自维护一套命令风格不统一改了一个忘了同步另一个knowledge-work-plugins就是冲着这些问题来的。它把常见的知识工作场景——文档处理、代码审查、会议记录、任务拆解、研究调研——抽象成一个个独立的 plugin每个 plugin 里包含 slash commands、skills、hooks 以及配套的配置文件。你只需要把仓库克隆到本地或者通过 Claude Code 的插件机制挂载进去就能在任何项目里直接调用这些命令不用重复造轮子。这个仓库适合谁三类人最应该关注第一类是重度使用 Claude Code 的开发者尤其是那些已经把 Claude Code 当成日常主力工具、每天要敲几十次斜杠命令的人第二类是需要统一团队 AI 工作流的技术负责人你们团队可能已经在用 Claude Code但每个人的用法五花八门需要一个标准化的插件层来收敛第三类是对 Claude Cowork 感兴趣的知识工作者比如产品经理、研究员、技术写作者你们不一定写代码但需要 AI 帮你们处理大量结构化和非结构化的信息。我自己的使用场景比较典型手头同时维护四五个项目每个项目都有自己的.claude目录以前每次改一个命令都要手动同步到所有项目烦不胜烦。后来把knowledge-work-plugins作为统一的插件源挂上去所有项目共享同一套命令定义改一处全局生效省下来的时间够我多写两篇文档。这也是我写这篇东西的原因——这个仓库值得被更多人知道但网上的中文资料几乎为零很多人连它和普通 Claude Code 配置的区别都搞不清楚。2. 核心概念拆解Plugin、Slash Command、Skill 到底怎么区分在深入实操之前有必要把几个容易混淆的概念理清楚。我见过太多人把 plugin、slash command、skill 混着用结果配置的时候一头雾水出了问题也不知道该查哪一层。下面这张表是我自己总结的对照关系你先看一遍后面实操的时候会反复用到。概念本质存放位置调用方式典型用途Plugin一个独立的功能包仓库根目录下的子目录通过插件机制挂载打包一组相关命令和技能Slash Command用户主动触发的命令commands/目录/命令名周报生成、代码审查SkillClaude 自动判断调用的能力skills/目录模型自主决定特定格式解析、领域知识Hook生命周期钩子hooks/目录事件触发提交前检查、输出后处理Config插件级配置plugin.json等自动加载声明依赖、元信息2.1 Plugin 是容器不是功能本身很多人第一次接触 plugin 这个概念会下意识觉得“plugin 就是功能”。不对。Plugin 是一个容器它本身不干活干活的是它里面装的 slash command 和 skill。你可以把 plugin 理解成一个工具箱工具箱本身不会修水管但里面装的扳手和螺丝刀会。knowledge-work-plugins这个仓库的组织方式就是典型的“一个 plugin 一个目录”。每个目录下面有commands/、skills/、hooks/这些子目录还有一个plugin.json用来声明这个 plugin 的元信息。这种结构的好处是边界清晰——你想加一个新功能就在对应的 plugin 里加一个 command 文件你想删掉一个不用的功能直接删掉那个文件就行不会影响到其他 plugin。我踩过的一个坑是早期我把所有命令都塞在一个大 plugin 里结果文件越来越多找个命令要翻半天而且不同项目的需求不一样有的项目只需要代码审查命令有的项目只需要文档处理命令全都塞在一起导致加载慢、维护乱。后来按照场景拆成多个 plugin每个 plugin 只负责一类事情清爽多了。2.2 Slash Command 是“你叫它才动”Slash command 的核心特征是用户主动触发。你在 Claude Code 的输入框里敲/后面跟命令名回车Claude 就按照这个命令预定义的提示词去执行。它不会自己冒出来必须你叫它。这种设计的好处是可控性强。比如/review这个命令你明确知道敲下去之后 Claude 会按照代码审查的模板去分析你指定的文件不会跑偏。坏处是你得记住命令名命令多了之后容易忘。所以knowledge-work-plugins里每个 plugin 都会在 README 或者plugin.json里列出它包含的所有命令方便你查阅。写一个 slash command 其实很简单本质上就是一个 Markdown 文件里面写清楚这个命令要做什么、接受什么参数、输出什么格式。但写好一个 slash command 很难难在提示词工程——你得让 Claude 在不同上下文下都能稳定输出你想要的结果而不是这次给你一段分析、下次给你一段代码。2.3 Skill 是“Claude 觉得该用就用”Skill 和 slash command 最大的区别是触发方式。Slash command 是你主动敲的skill 是 Claude 根据当前任务自主判断要不要调用的。比如你定义了一个“解析会议纪要”的 skill当你在对话里贴了一段会议记录并问“帮我整理一下”Claude 会自己判断“哦这个任务适合用那个会议纪要 skill”然后自动调用。这种设计的好处是无感——你不需要记住什么时候该用什么技能Claude 帮你判断。坏处是不可控——有时候 Claude 判断错了该用 skill 的时候没用或者不该用的时候用了。所以 skill 的定义要非常精确触发条件要写清楚否则容易误触发或者漏触发。我在实际使用中的体会是高频、固定流程的操作写成 slash command低频、需要判断的操作写成 skill。比如“生成周报”是每周固定要做的写成 command而“从一堆杂乱信息里提取待办事项”这种任务什么时候遇到什么时候用写成 skill 更合适。2.4 Hook 是“到点自动执行”Hook 是生命周期钩子在特定事件发生时自动执行。比如你可以在“Claude 输出完成之后”这个事件上挂一个 hook自动把输出内容格式化一遍或者在“命令执行之前”挂一个 hook做权限检查。knowledge-work-plugins里的 hook 用得比较克制主要用在两个场景一是输出后处理比如把 Claude 生成的 Markdown 自动转成特定格式二是安全检查比如在执行某些敏感操作前做一次确认。Hook 用多了会让整个系统变得难以调试所以我的建议是能不用就不用非用不可的时候再上。3. 环境准备与安装从零把插件跑起来这一节讲实操。假设你现在什么都没装从零开始把knowledge-work-plugins跑起来。我会把每一步的命令和背后的原因都讲清楚你照着做就行。3.1 前置条件确认在装插件之前你得先确认 Claude Code 本身是能用的。打开终端敲claude --version如果能看到版本号比如2.1.278这种说明 Claude Code 已经装好了。如果提示command not found那你得先装 Claude Code。安装方式取决于你的系统macOS推荐用 Homebrewbrew install --cask claude-code或者从官网下载桌面版Ubuntu / Debian用官方提供的安装脚本或者通过 npm 全局安装Windows 11建议用 WSL2在 WSL 里按照 Ubuntu 的方式装原生 Windows 版本虽然能用但坑比较多提示如果你在 Windows 上遇到unable to connect to anthropic services这类报错先检查网络配置和 API Key 是否正确不要急着怀疑插件的问题。插件层的问题和连接层的问题是两码事排查的时候要分开看。确认 Claude Code 能用之后再确认一下你的工作目录里有没有.claude目录。这个目录是 Claude Code 的项目级配置目录插件最终是要挂载到这里面的。ls -la .claude/如果没有这个目录手动建一个mkdir -p .claude/plugins3.2 获取 knowledge-work-plugins 仓库仓库的获取方式有两种取决于你的使用场景。方式一直接克隆到本地git clone https://github.com/你的组织/knowledge-work-plugins.git ~/.claude/plugins/knowledge-work-plugins这里我建议克隆到用户级的~/.claude/plugins/目录下而不是项目级的.claude/plugins/。原因是用户级插件对所有项目生效你装一次所有项目都能用项目级插件只对当前项目生效换个项目就得重新装。除非你有特殊的隔离需求否则一律用用户级。方式二作为 git submodule 挂载如果你的项目本身是 git 仓库而且你希望插件的版本跟着项目走可以用 submodulegit submodule add https://github.com/你的组织/knowledge-work-plugins.git .claude/plugins/knowledge-work-plugins这种方式的好处是版本锁定——项目 A 用插件 v1.0项目 B 用插件 v2.0互不影响。坏处是更新麻烦每次插件更新你都得手动git submodule update。我自己的做法是个人项目用方式一团队项目用方式二。个人项目追求方便全局装一次就行团队项目追求稳定版本锁定避免“昨天还能用今天就不行了”的尴尬。3.3 挂载插件到 Claude Code仓库克隆下来之后还需要让 Claude Code 知道这个插件的存在。这一步通过修改配置文件完成。打开~/.claude/settings.json如果没有就新建一个加入插件路径{ plugins: [ ~/.claude/plugins/knowledge-work-plugins ] }如果你只想在特定项目里启用就改项目级的.claude/settings.json格式一样。改完之后重启 Claude Code或者在会话里执行/reload命令如果版本支持的话。然后敲/help看看命令列表里有没有出现插件里定义的命令。如果出现了说明挂载成功。注意不同版本的 Claude Code 对插件配置的字段名可能略有差异有的版本用plugins有的版本用pluginDirs。如果挂载不成功先查一下你当前版本的文档别死磕一个字段名。3.4 验证安装是否成功挂载完成之后做一次快速验证。挑一个最简单的命令试一下比如/knowledge-work-plugins:hello或者仓库里提供的任意一个 demo 命令。# 在 Claude Code 会话里 /plugin-list这个命令会列出当前加载的所有插件和它们包含的命令。如果你能看到knowledge-work-plugins以及它下面的命令列表说明一切正常。如果看不到按下面的顺序排查检查settings.json的 JSON 格式是否正确有没有多余的逗号检查插件路径是否存在ls ~/.claude/plugins/knowledge-work-plugins能不能列出文件检查插件目录下有没有plugin.json这个文件是插件的“身份证”没有它 Claude Code 不认检查 Claude Code 版本是否支持插件机制太老的版本可能不支持4. 核心插件逐个拆解每个命令到底怎么用knowledge-work-plugins仓库里包含多个 plugin每个 plugin 针对一类知识工作场景。这一节我挑几个最常用的 plugin把里面的命令逐个拆开讲包括它们的设计意图、参数用法、实际效果以及我自己用下来的心得。4.1 文档处理插件把杂乱信息变成结构化文档文档处理插件是我用得最多的一个。它的核心场景是你手头有一堆杂乱的输入——会议录音转写、聊天记录、零散笔记——需要把它们整理成结构化的文档。里面最常用的命令是/doc:summarize用法/doc:summarize 会议记录.md --formatminutes --lengthmedium三个参数的含义会议记录.md输入文件支持 Markdown、txt、甚至直接粘贴文本--formatminutes输出格式可选minutes会议纪要、summary摘要、outline大纲--lengthmedium输出长度可选short、medium、long这个命令背后的提示词设计很有意思。它不是简单地说“帮我总结一下”而是分了三步第一步提取关键信息点第二步按照指定格式组织第三步做一次自检确保没有遗漏重要内容。这种“分步走”的设计是knowledge-work-plugins里很多命令的共同特点也是它比你自己随手写一个提示词效果好的原因。我实测下来的效果一段 3000 字的会议记录用--formatminutes --lengthmedium输出大概 800 字的纪要关键决策、待办事项、责任人基本都能覆盖到。偶尔会漏掉一些细节但整体可用度很高。实操心得如果你的会议记录里有大量口语化的内容建议先用/doc:clean命令做一次清洗把“嗯”“啊”“那个”这些语气词去掉再做总结效果会好很多。直接总结口语化文本Claude 容易被带偏。4.2 代码审查插件让审查意见有章可循代码审查插件解决的是“审查意见质量不稳定”的问题。以前让 Claude 审查代码这次给你挑出三个问题下次给你挑出十个标准不统一。用了这个插件之后审查维度固定下来每次输出都覆盖相同的检查项。核心命令是/review:diff用法/review:diff --staged --severityhigh--staged审查暂存区的改动也可以换成--filexxx审查指定文件--severityhigh只输出高严重级别的问题可选low、medium、high这个命令的提示词里内置了一个检查清单覆盖了空指针风险、边界条件、错误处理、命名规范、注释完整性、性能隐患、安全漏洞。每个维度都有明确的判断标准Claude 按照清单逐项检查输出格式统一。我拿它审查过一段有并发问题的代码它准确识别出了“共享变量没有加锁”这个隐患而且给出了具体的修复建议。当然也有误报的时候比如它会把一些刻意的设计模式当成“重复代码”报出来。所以我的用法是把它当成第一道筛子筛出来的问题人工再过一遍而不是完全信任它的输出。4.3 任务拆解插件把大目标拆成可执行的小步骤任务拆解插件的场景是你有一个模糊的大目标比如“重构用户认证模块”需要把它拆成一个个具体可执行的任务。命令是/task:breakdown/task:breakdown 重构用户认证模块 --depth3 --estimatetrue--depth3拆解层级3 表示拆到“可以直接动手做”的粒度--estimatetrue是否估算每个任务的工作量这个命令的输出是一个树状结构大目标下面挂子任务子任务下面挂具体步骤。每个步骤都有明确的输入、输出、验收标准。我拿它拆过一个“搭建数据管道”的任务拆出来的步骤里有一项是“确认数据源的字段类型和空值率”这个细节我自己一开始没想到后来发现确实很关键——字段类型不对后面的转换逻辑全白写。注意任务拆解的质量高度依赖你给的目标描述。如果你只给一句“优化系统性能”拆出来的任务会很泛如果你给“把首页加载时间从 3 秒降到 1.5 秒”拆出来的任务就具体得多。输入越具体输出越可用这是所有 AI 辅助工具的通则。4.4 研究调研插件快速摸清一个陌生领域研究调研插件适合那种“老板让你三天内摸清某个技术方向”的场景。它的核心命令是/research:survey/research:survey 向量数据库选型 --aspectsperformance,cost,ecosystem --outputreport.md--aspects调研维度可以指定多个用逗号分隔--output输出文件路径这个命令会按照你指定的维度逐个维度去搜集信息、对比分析最后输出一份结构化报告。报告里每个维度都有对比表格表格后面有分析文字。我用它调研过“前端状态管理方案”输出了一份对比 Redux、Zustand、Jotai、Valtio 的报告覆盖了包体积、学习曲线、生态成熟度、TypeScript 支持四个维度。报告的质量嘛框架和维度是靠谱的具体数据需要你自己核实。因为 Claude 的知识有截止日期最新的版本信息它不一定知道。所以我的用法是用它搭框架用搜索引擎填数据。5. 自定义插件开发写一个属于自己的命令用了一段时间之后你肯定会遇到“内置命令不够用”的情况。这时候就需要自己写插件。好消息是knowledge-work-plugins的插件格式非常简单一个 Markdown 文件就是一个命令不需要写代码。5.1 插件目录结构一个标准的插件目录长这样my-plugin/ ├── plugin.json ├── commands/ │ ├── hello.md │ └── report.md ├── skills/ │ └── parse-meeting/ │ └── SKILL.md └── hooks/ └── post-output.shplugin.json是必须的其他目录按需创建。plugin.json的内容{ name: my-plugin, version: 1.0.0, description: 我自己的知识工作插件, author: 你的名字, commands: [commands/hello.md, commands/report.md], skills: [skills/parse-meeting] }5.2 写一个最简单的命令新建commands/hello.md--- description: 打个招呼测试插件是否正常工作 --- 你是一个友好的助手。用户调用这个命令时请用一句话打招呼 并告诉用户当前时间是 {{current_time}}。就这么简单。---之间的部分是元信息description会显示在命令列表里。下面的部分是提示词正文。{{current_time}}是变量Claude Code 会在执行时替换成实际值。写完之后把插件路径加到settings.json里重启敲/hello就能看到效果。5.3 写一个带参数的命令带参数的命令稍微复杂一点需要在提示词里声明参数--- description: 生成指定主题的周报 arguments: - name: topic description: 周报主题 required: true - name: period description: 时间范围 required: false default: 本周 --- 请帮我生成一份关于「{{topic}}」的周报时间范围是{{period}}。 周报格式要求 1. 本周完成事项3-5 条 2. 遇到的问题1-3 条 3. 下周计划3-5 条 4. 需要协调的资源可选 每条事项要具体不要写“推进了项目”这种空话 要写“完成了用户登录模块的接口联调覆盖了 5 个边界场景”。调用的时候/report:weekly topic用户认证模块重构 period2024年第12周5.4 写一个 SkillSkill 和 command 的区别前面讲过这里给一个 skill 的例子。新建skills/parse-meeting/SKILL.md--- name: parse-meeting description: 当用户提供会议记录并需要提取待办事项时使用 trigger: 用户提到会议记录待办action item等关键词 --- 从用户提供的会议记录中提取所有待办事项输出格式 | 待办事项 | 责任人 | 截止时间 | 优先级 | |----------|--------|----------|--------| | ... | ... | ... | ... | 如果某项信息在记录中没有明确提到填未指定。 不要自己编造信息。Skill 的触发是 Claude 自主判断的所以你不需要记住命令名遇到相关任务时 Claude 会自动调用。实操心得写 skill 的时候description和trigger这两个字段非常关键。它们决定了 Claude 什么时候会想起这个 skill。写得太宽泛Claude 会频繁误触发写得太窄Claude 又想不起来。我的经验是description 写“做什么”trigger 写“什么时候用”两者配合覆盖要精准。6. 常见问题与排查技巧实录这一节整理我在使用knowledge-work-plugins过程中遇到的各种问题以及排查思路。你遇到问题的时候可以当速查表用。问题现象可能原因排查方法解决方案命令列表里看不到插件命令插件未挂载成功检查 settings.json 格式修正 JSON重启 Claude Code命令执行报错“command not found”命令文件路径不对检查 plugin.json 里的 commands 字段修正路径确保文件存在Skill 不触发trigger 条件写得太窄查看 Claude 的思考过程放宽 trigger 关键词Skill 频繁误触发description 太宽泛观察哪些场景误触发收窄 description增加排除条件Hook 不执行事件名写错查文档确认事件名修正事件名插件加载慢插件太多或文件太大看启动日志拆分插件按需加载输出格式不稳定提示词约束不够对比多次输出增加格式示例明确禁止项6.1 命令不生效的三层排查法命令敲下去没反应是最常见的问题。我的排查顺序是从外到内分三层第一层配置层。检查settings.json里插件路径对不对JSON 格式有没有语法错误。这一步能解决 80% 的问题。很多人栽在 JSON 的尾逗号上{plugins: [path,]}这种写法在某些解析器里会报错。第二层插件层。检查插件目录下有没有plugin.json里面的commands字段有没有正确列出命令文件。我遇到过一种情况命令文件明明存在但plugin.json里忘了加进去结果命令就是加载不出来。第三层命令层。检查命令文件本身的格式---元信息部分有没有写错提示词正文有没有语法问题。这一步的问题比较隐蔽通常需要看 Claude Code 的调试日志才能发现。6.2 输出质量不稳定的调优思路同样的命令这次输出很好下次输出很烂这是提示词工程的经典问题。我的调优思路是加约束、给示例、设边界。加约束在提示词里明确写出“不要做什么”。比如“不要输出超过 500 字”“不要使用第一人称”“不要编造数据”。负面约束往往比正面要求更有效。给示例在提示词里放一个输入输出的例子。Claude 看到例子之后模仿的准确率会大幅提升。示例不用太长一个输入一个输出就够。设边界明确告诉 Claude 遇到不确定的情况怎么处理。比如“如果信息不足输出‘信息不足需要补充 XXX’不要猜测”。这样能避免 Claude 胡编乱造。6.3 插件版本冲突的处理如果你同时装了多个插件而且它们定义了同名的命令就会冲突。Claude Code 的处理方式是后加载的覆盖先加载的但具体哪个先加载取决于配置顺序很容易搞混。我的做法是给命令加命名空间前缀。比如文档插件的命令都叫/doc:xxx代码插件的命令都叫/review:xxx。这样即使两个插件都有summarize命令也不会冲突因为一个是/doc:summarize一个是/review:summarize。命名空间在plugin.json里声明{ name: doc, namespace: doc }6.4 性能问题的排查插件装多了之后Claude Code 启动会变慢。原因是启动时要加载所有插件的元信息。我的经验是用户级插件控制在 5 个以内项目级插件按需加载。如果你确实需要很多插件可以考虑懒加载——只在用到的时候才加载。不过这个功能取决于 Claude Code 版本是否支持不是所有版本都有。另一个性能问题是命令文件太大。有的命令提示词写了几千字每次执行都要加载拖慢响应速度。我的建议是单个命令文件的提示词控制在 500 字以内超出的部分拆成 skill 或者外部引用。7. 进阶玩法把插件和现有工作流串起来基础用法掌握之后可以玩一些进阶的。这一节分享几个我自己在用的组合玩法都是实测有效的。7.1 插件 Git Hook提交前自动审查把代码审查插件和 Git 的 pre-commit hook 结合起来每次提交前自动跑一遍审查。配置方式# .git/hooks/pre-commit #!/bin/bash claude /review:diff --staged --severityhigh /tmp/review.txt if grep -q 严重 /tmp/review.txt; then echo 发现严重问题请先修复 cat /tmp/review.txt exit 1 fi这样每次git commit之前Claude 会自动审查暂存区的改动发现严重问题就阻止提交。我用了两个月拦下了好几次低级错误比如忘了处理空值、日志里打印了敏感信息。注意这个 hook 会让每次提交都多花几秒钟如果你赶时间可以临时用git commit --no-verify跳过。但别养成习惯跳过多了 hook 就形同虚设。7.2 插件 定时任务自动生成日报把文档处理插件和系统的定时任务结合起来每天下班前自动生成日报。以 Linux 的 cron 为例# 每天 18:00 执行 0 18 * * * cd /path/to/project claude /doc:summarize today-log.md --formatsummary --outputdaily-report.md前提是你得有一个地方记录当天的工作内容比如today-log.md。我自己的做法是用一个简单的脚本把当天的 git commit 记录、修改的文件列表、终端历史里的关键命令汇总到这个文件里然后让 Claude 生成日报。7.3 插件 团队共享统一团队工作流如果你带团队可以把knowledge-work-plugins作为团队的标准插件源。做法是Fork 一份仓库到团队的组织账号下根据团队需求定制命令和 skill在团队的开发环境初始化脚本里自动克隆插件并配置到settings.json这样新同事入职跑一遍初始化脚本所有标准命令就都配好了。团队里谁想加新命令提 PR 到插件仓库review 通过后合并所有人下次拉取就能用上。我帮一个五人团队做过这套配置效果很明显以前每个人写周报格式都不一样现在统一用/report:weekly格式一致汇总的时候省了大量时间。7.4 插件 多模型切换不同任务用不同模型Claude Code 支持切换底层模型。你可以针对不同插件配置不同的模型代码审查用推理能力强的模型文档总结用速度快的模型。配置方式是在plugin.json里声明{ name: review, model: claude-sonnet-4-20250514 }这样调用/review:xxx的时候会自动切换到指定模型其他命令不受影响。这个功能在需要平衡成本和质量的时候特别有用。8. 我踩过的坑和给你的建议最后分享几个我自己踩过的坑都是真金白银换来的教训希望能帮你少走弯路。第一个坑插件路径用了相对路径。早期我在settings.json里写plugins: [./plugins/knowledge-work-plugins]结果换个目录启动 Claude Code 就找不到插件了。后来改成绝对路径~/.claude/plugins/knowledge-work-plugins才稳定。插件路径一律用绝对路径这是铁律。第二个坑命令名用了中文。有一次我图省事把命令文件命名为周报.md结果调用的时候各种编码问题。命令文件名一律用英文小写加连字符比如weekly-report.md这是最稳妥的。第三个坑提示词里写了太多“最好”“尽量”。这种模糊的词汇 Claude 理解起来有歧义输出质量不稳定。后来我把所有“最好”改成“必须”把“尽量”改成“如果 X 则 Y”输出立刻稳定了。提示词要精确不要模糊。第四个坑一次性装了太多插件。刚开始兴奋把仓库里所有插件都挂上了结果启动慢、命令列表长、还经常冲突。后来精简到只留常用的四个体验好多了。插件按需装不要贪多。第五个坑忘了备份自定义插件。有一次重装系统自定义的插件全丢了只能凭记忆重写。现在我的做法是把自定义插件单独放一个 git 仓库定期 push。自定义的东西一定要版本管理这是血泪教训。如果你刚开始用knowledge-work-plugins我的建议是先从文档处理和代码审查这两个插件入手用熟之后再逐步加其他插件。不要一上来就追求大而全先把一两个场景用透比装一堆插件但每个都用不明白强得多。另外这个仓库本身是开源的遇到问题可以去提 issue也可以自己 fork 一份改。我自己的几个自定义命令就是从仓库里的现有命令改出来的改着改着就摸清了提示词设计的门道。最好的学习方式就是改别人的东西改多了自然就会写了。