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 混着用，结果配置的时候一头雾水，出了问题也不知道该查哪一层。下面这张表是我自己总结的对照关系，你先看一遍，后面实操的时候会反复用到。

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：推荐用 Homebrew，brew 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/plugins

3.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 仓库，而且你希望插件的版本跟着项目走，可以用 submodule：

git 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以及它下面的命令列表，说明一切正常。

如果看不到，按下面的顺序排查：

1. 检查settings.json的 JSON 格式是否正确，有没有多余的逗号
2. 检查插件路径是否存在，ls ~/.claude/plugins/knowledge-work-plugins能不能列出文件
3. 检查插件目录下有没有plugin.json，这个文件是插件的“身份证”，没有它 Claude Code 不认
4. 检查 Claude Code 版本是否支持插件机制，太老的版本可能不支持

4. 核心插件逐个拆解：每个命令到底怎么用

knowledge-work-plugins仓库里包含多个 plugin，每个 plugin 针对一类知识工作场景。这一节我挑几个最常用的 plugin，把里面的命令逐个拆开讲，包括它们的设计意图、参数用法、实际效果，以及我自己用下来的心得。

4.1 文档处理插件：把杂乱信息变成结构化文档

文档处理插件是我用得最多的一个。它的核心场景是：你手头有一堆杂乱的输入——会议录音转写、聊天记录、零散笔记——需要把它们整理成结构化的文档。

里面最常用的命令是/doc:summarize，用法：

/doc:summarize @会议记录.md --format=minutes --length=medium

三个参数的含义：

• @会议记录.md：输入文件，支持 Markdown、txt、甚至直接粘贴文本
• --format=minutes：输出格式，可选minutes（会议纪要）、summary（摘要）、outline（大纲）
• --length=medium：输出长度，可选short、medium、long

这个命令背后的提示词设计很有意思。它不是简单地说“帮我总结一下”，而是分了三步：第一步提取关键信息点，第二步按照指定格式组织，第三步做一次自检确保没有遗漏重要内容。这种“分步走”的设计是knowledge-work-plugins里很多命令的共同特点，也是它比你自己随手写一个提示词效果好的原因。

我实测下来的效果：一段 3000 字的会议记录，用--format=minutes --length=medium，输出大概 800 字的纪要，关键决策、待办事项、责任人基本都能覆盖到。偶尔会漏掉一些细节，但整体可用度很高。

实操心得：如果你的会议记录里有大量口语化的内容，建议先用/doc:clean命令做一次清洗，把“嗯”“啊”“那个”这些语气词去掉，再做总结，效果会好很多。直接总结口语化文本，Claude 容易被带偏。

4.2 代码审查插件：让审查意见有章可循

代码审查插件解决的是“审查意见质量不稳定”的问题。以前让 Claude 审查代码，这次给你挑出三个问题，下次给你挑出十个，标准不统一。用了这个插件之后，审查维度固定下来，每次输出都覆盖相同的检查项。

核心命令是/review:diff，用法：

/review:diff --staged --severity=high

• --staged：审查暂存区的改动，也可以换成--file=xxx审查指定文件
• --severity=high：只输出高严重级别的问题，可选low、medium、high

这个命令的提示词里内置了一个检查清单，覆盖了：空指针风险、边界条件、错误处理、命名规范、注释完整性、性能隐患、安全漏洞。每个维度都有明确的判断标准，Claude 按照清单逐项检查，输出格式统一。

我拿它审查过一段有并发问题的代码，它准确识别出了“共享变量没有加锁”这个隐患，而且给出了具体的修复建议。当然也有误报的时候，比如它会把一些刻意的设计模式当成“重复代码”报出来。所以我的用法是：把它当成第一道筛子，筛出来的问题人工再过一遍，而不是完全信任它的输出。

4.3 任务拆解插件：把大目标拆成可执行的小步骤

任务拆解插件的场景是：你有一个模糊的大目标，比如“重构用户认证模块”，需要把它拆成一个个具体可执行的任务。

命令是/task:breakdown：

/task:breakdown "重构用户认证模块" --depth=3 --estimate=true

• --depth=3：拆解层级，3 表示拆到“可以直接动手做”的粒度
• --estimate=true：是否估算每个任务的工作量

这个命令的输出是一个树状结构，大目标下面挂子任务，子任务下面挂具体步骤。每个步骤都有明确的输入、输出、验收标准。我拿它拆过一个“搭建数据管道”的任务，拆出来的步骤里有一项是“确认数据源的字段类型和空值率”，这个细节我自己一开始没想到，后来发现确实很关键——字段类型不对，后面的转换逻辑全白写。

注意：任务拆解的质量高度依赖你给的目标描述。如果你只给一句“优化系统性能”，拆出来的任务会很泛；如果你给“把首页加载时间从 3 秒降到 1.5 秒”，拆出来的任务就具体得多。输入越具体，输出越可用，这是所有 AI 辅助工具的通则。

4.4 研究调研插件：快速摸清一个陌生领域

研究调研插件适合那种“老板让你三天内摸清某个技术方向”的场景。它的核心命令是/research:survey：

/research:survey "向量数据库选型" --aspects=performance,cost,ecosystem --output=report.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.sh

plugin.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="用户认证模块重构" period="2024年第12周"

5.4 写一个 Skill

Skill 和 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过程中遇到的各种问题，以及排查思路。你遇到问题的时候可以当速查表用。

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 --severity=high > /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 --format=summary --output=daily-report.md

前提是你得有一个地方记录当天的工作内容，比如today-log.md。我自己的做法是用一个简单的脚本，把当天的 git commit 记录、修改的文件列表、终端历史里的关键命令汇总到这个文件里，然后让 Claude 生成日报。

7.3 插件 + 团队共享：统一团队工作流

如果你带团队，可以把knowledge-work-plugins作为团队的标准插件源。做法是：

1. Fork 一份仓库到团队的组织账号下
2. 根据团队需求定制命令和 skill
3. 在团队的开发环境初始化脚本里，自动克隆插件并配置到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 一份改。我自己的几个自定义命令就是从仓库里的现有命令改出来的，改着改着就摸清了提示词设计的门道。最好的学习方式就是改别人的东西，改多了自然就会写了。