1. 从“knowledge-work-plugins”这个名字说起它到底在解决什么问题第一次看到knowledge-work-plugins这个仓库名很多人会下意识地把它当成又一个“插件合集”。但如果你真的在 Claude Code 或 Claude Cowork 里干过几天活就会明白它想解决的是一个更根本的痛点知识工作者的重复劳动能不能被封装成可复用的命令。我自己的日常是这样的写技术方案时要反复查同一批内部文档、做竞品分析时要按固定模板拉数据、每周复盘时要手动整理一堆散落的笔记。这些活儿单看都不难但架不住天天做。knowledge-work-plugins的核心思路就是把这些“知识工作流”抽象成 slash commands斜杠命令和配套的插件结构让你在 Claude Code 里敲一个/就能触发一整套预设动作。它适合谁三类人最该关注。第一类是重度使用 Claude Code 的开发者尤其是已经把 CLI 当成主力工作台的人第二类是做知识管理、内容运营、研究分析的知识工作者你们的工作流最容易被标准化第三类是想给自己团队搭一套内部 AI 工具链的技术负责人这个仓库的结构可以直接当模板抄。需要先说明一点knowledge-work-plugins本身不是一个开箱即用的成品软件它更像一套约定和骨架——告诉你插件目录怎么放、命令怎么定义、元数据怎么写、Claude Code 怎么发现并加载它们。理解了这套约定你就能把自己的工作流塞进去。下面我会从目录结构、命令定义、加载机制、实战封装、排错这几个角度把它拆开讲透。2. 插件目录结构与加载机制Claude Code 是怎么“看见”你的插件的2.1 一个插件的最小构成在 Claude Code 的插件体系里一个可被识别的插件通常包含这几个部分一个描述插件元信息的清单文件、若干命令定义文件、可选的技能skills目录、以及可选的资源文件。knowledge-work-plugins的价值在于它给出了一套经过实践检验的目录约定而不是让你从零猜。我实测下来最稳妥的最小结构是这样的knowledge-work-plugins/ ├── plugin.json # 插件元信息名称、版本、描述、作者 ├── commands/ # 斜杠命令定义 │ ├── summarize.md │ └── review.md ├── skills/ # 可复用的技能片段 │ └── doc-reader/ │ └── SKILL.md └── README.md这里的关键是plugin.json。它相当于插件的“身份证”Claude Code 启动时会扫描插件目录读取这个文件来判断“这是个什么插件、有哪些命令可用”。很多人第一次做插件失败就是因为清单文件的字段名写错或者路径没对上导致命令根本不出现。2.2 命令是怎么被解析成动作的斜杠命令的本质是一个带 frontmatter 的 Markdown 文件。你在 Claude Code 里敲/summarize它做的事情是找到commands/summarize.md读取里面的元数据比如命令描述、参数提示然后把正文内容作为提示词注入到当前会话上下文里。这意味着什么意味着命令的“智能”完全取决于你写的提示词质量。我见过太多人把命令写成一句干巴巴的“请总结这段内容”结果输出质量惨不忍睹。正确的做法是把命令当成一个微型工作流脚本来写明确输入是什么、处理步骤分几步、输出格式长什么样、遇到边界情况怎么处理。举个我实际在用的例子一个用于“技术方案评审”的命令正文大致是这样的逻辑先让模型提取方案的核心目标和技术选型再逐条对照检查清单可扩展性、成本、风险点最后按固定模板输出评审意见。这套东西写一次之后每次评审都省下十几分钟。2.3 加载顺序与优先级别踩这个坑Claude Code 加载插件时是有顺序的。通常它会先加载全局配置目录下的插件再加载项目级目录下的插件项目级的优先级更高。这个设计很合理——你可以在全局放一套通用命令在具体项目里放针对性的命令同名时项目级覆盖全局级。但这里有个很容易踩的坑如果你在项目里改了命令文件但 Claude Code 已经缓存了旧的你会发现改动不生效。解决办法是重启会话或者用命令重新加载插件。我一开始不知道这点改了半天提示词以为没生效白白浪费了半小时。记住改完插件文件先重启再验证。3. 把重复劳动变成斜杠命令三个真实工作流的封装过程3.1 工作流一会议纪要的标准化提炼知识工作者最烦的事情之一就是开完会还要花时间整理纪要。我的做法是封装一个/meeting-notes命令输入是原始会议记录可以是语音转文字后的草稿输出是结构化的纪要。命令正文我设计成三段式第一段让模型识别会议主题、参与角色、时间线第二段提取“决议事项”和“待办事项”待办必须带负责人和截止时间第三段生成一个简短的“下次会议前需要确认的问题”列表。为什么要分三段因为一次性让模型干太多事它容易漏项。分段处理每段聚焦一个目标输出质量明显更稳。实测下来有个细节值得分享在命令里明确要求“如果某项信息原文没有提到标注为‘待确认’而不是编造”这一句话能大幅降低模型幻觉。我早期版本没加这句结果纪要里经常冒出原文根本没有的“决议”差点造成误会。3.2 工作流二竞品资料的批量结构化做市场或产品分析的人经常要处理一堆竞品资料——官网截图、功能列表、定价页、用户评价。手动整理这些一天下来眼睛都花了。我封装了一个/competitor-digest命令配合 skills 目录里的一个“网页内容提取”技能。这个命令的设计要点是定义统一的输出 schema。我要求输出必须包含产品定位一句话、核心功能最多五条、定价模式、目标用户、明显短板。为什么强制 schema因为后续我要把这些结果汇总成对比表格如果每次输出格式都不一样汇总就是灾难。统一 schema 之后我甚至可以直接把多次输出拼成一张 Markdown 表格。这里有个经验把 schema 写进命令正文并且给出一个填写示例。模型看到示例输出格式的稳定性会高很多。纯文字描述格式它经常自由发挥。3.3 工作流三周报的自动草稿生成周报这东西写的人痛苦看的人也未必爱看。我的思路是让命令帮我生成草稿我再改。/weekly-draft命令的输入是我这一周的零散记录git commit、笔记、待办完成情况输出是一份按“本周进展 / 遇到的问题 / 下周计划”组织的草稿。关键在于输入的组织方式。我一开始直接把一堆杂乱文本丢进去结果模型抓不住重点。后来我改成在命令里要求“先按项目分组再在每个项目下提炼进展”输出立刻清爽了。这告诉我一个道理命令的提示词里处理步骤的顺序设计比措辞华丽重要得多。4. 命令提示词的写法决定插件好不好用的分水岭4.1 好命令和坏命令的差距在哪我对比过自己和同事写的同类命令差距非常明显。坏命令通常是这样的“请帮我分析这份文档。”好命令则是“你是一名资深技术评审请按以下步骤分析文档第一步提取核心论点第二步识别论据是否充分第三步指出逻辑漏洞第四步给出改进建议。输出用 Markdown每个部分用二级标题。”差距的本质是约束的密度。模型是个能力很强但需要明确指令的执行者你给的约束越具体它越不容易跑偏。但约束也不是越多越好太多会互相打架。我的经验是角色设定 步骤拆解 输出格式 边界处理这四样齐了就够再多就是过度设计。4.2 参数化让一个命令适配多种场景斜杠命令支持参数这是它比普通提示词强的地方。比如一个/translate命令可以通过参数指定目标语言和语气风格。参数化的好处是一个命令顶好几个不用为每种情况单独写。但参数化也有代价命令正文会变复杂维护成本上升。我的判断标准是——如果两种场景的处理逻辑有 70% 以上重合就参数化否则宁可拆成两个命令。硬把不相关的场景塞进一个命令最后谁都记不住怎么用。4.3 版本管理命令也是代码这一点很多人忽略。命令文件改来改去改坏了想回滚都难。我的做法是把插件目录纳入 git 管理每次改动写清楚 commit message。别小看这个习惯我有一次把一个用了半年的命令改崩了靠 git 五分钟就回滚了要是没版本管理得凭记忆重写。另外命令正文里我习惯留一个“变更记录”注释块记录每次改了什么、为什么改。过几个月回头看能省下大量“我当时为啥这么写”的困惑。5. 插件加载失败的排查链路从“命令不出现”到定位根因5.1 第一步确认插件目录被扫描到了命令敲了没反应先别急着改命令内容。第一步是确认 Claude Code 到底有没有扫描到你的插件目录。通常插件目录有固定的位置约定放错地方它根本不会看。我的排查顺序是先确认目录路径对不对再确认plugin.json是否存在且格式合法。plugin.json最常见的错误是 JSON 语法问题——多一个逗号、少一个引号整个文件就废了。我建议用编辑器的 JSON 校验功能先过一遍别靠肉眼。5.2 第二步确认命令文件的命名和位置命令能不能被识别取决于文件名和所在目录。commands/目录下的summarize.md对应/summarize。如果你把文件放错目录或者文件名带了不该有的字符命令就不会出现。我遇到过有人把命令放在command/少了个 s目录下排查了半天。还有一个隐蔽的坑文件名大小写。在某些系统上大小写不敏感换个系统就失效了。统一用小写加连字符是最稳的命名方式。5.3 第三步确认 frontmatter 格式正确命令文件顶部的 frontmatter 是元数据区格式错了命令可能加载但行为异常。常见问题是分隔符写错、字段名拼错。我建议直接复制一个能正常工作的命令文件当模板改内容不改结构能避开大部分格式坑。5.4 第四步看日志别猜前面三步都排除了就该看日志了。Claude Code 在加载插件时通常会输出一些信息告诉你哪些插件加载成功、哪些失败、失败原因是什么。养成看日志的习惯比盲目试错快十倍。我早期就是不看日志靠改文件反复重启效率极低。6. 从个人用到团队用插件体系的扩展思路6.1 把命令拆成“通用层”和“业务层”一个人用的时候命令怎么放都行。但一旦团队共用就得考虑分层。我的做法是通用层放跨项目都能用的命令比如文档总结、翻译、格式转换业务层放特定项目或团队的命令比如内部术语解释、特定报告模板。通用层放全局目录业务层放项目目录各取所需。这样分层的好处是新人入职只需要拉项目目录就能拿到业务相关的命令不用被一堆用不上的通用命令干扰。6.2 用 skills 目录沉淀可复用能力skills/目录是插件体系里被低估的部分。它适合放那些被多个命令共享的能力片段比如“读取并解析 PDF”“提取网页正文”“调用某个内部 API”。把这些能力抽成 skill命令里引用它避免重复写同样的提示词。我自己的经验是当发现三个以上命令都在重复同一段提示词时就该把它抽成 skill 了。这是典型的 DRY 原则在提示词工程里的应用。6.3 团队协作中的命名约定团队共用插件命名混乱是最大的敌人。我们内部定了一套约定命令名用“动词-名词”结构如summarize-doc、review-planskill 名用“能力”结构如pdf-reader、web-extractor。统一命名之后找命令、记命令都轻松很多。还有一点每个命令都要写清楚用途和输入要求放在命令描述里。团队里最怕的就是有人写了个命令别人不知道干嘛用的最后没人用白写。7. 我踩过的几个坑和对应的解法7.1 坑一命令提示词太长模型反而抓不住重点我一开始追求“把话说全”一个命令写了上千字提示词结果模型输出反而变差。后来我明白了提示词不是越长越好而是要结构清晰。把长提示词拆成带编号的步骤比堆成一大段效果好得多。现在我的命令正文基本控制在合理长度重点靠结构而不是字数。7.2 坑二忽略输出格式的稳定性早期我不太在意输出格式觉得内容对就行。直到我要把多次输出汇总成表格时才发现格式不统一有多痛苦。现在我写命令输出格式是必写项而且会给一个示例。这一条改动让我的后续处理效率提升了一大截。7.3 坑三没有给命令做“输入校验”有些命令对输入有要求比如必须是 Markdown、必须包含特定字段。如果输入不符合要求模型可能给出莫名其妙的输出。我的解法是在命令开头加一句“如果输入不符合以下要求请先指出问题而不是强行处理”。这一句话帮我避免了很多无效输出。7.4 坑四忘了命令也会“过时”工作流会变命令也得跟着改。我有几个命令用了半年没动后来发现里面的检查清单已经和实际流程脱节了。现在我养成了习惯每个季度过一遍常用命令该改的改该删的删。插件体系是活的不是写完就一劳永逸。8. 关于 knowledge-work-plugins 的一点个人判断用了一段时间下来我对knowledge-work-plugins这类插件体系的判断是它的价值不在于提供了多少现成命令而在于它把“知识工作流可被封装”这件事变得具体可操作了。以前我们谈 AI 提效总是停留在“让模型帮我写点东西”的层面有了插件体系你可以把一整套流程固化下来变成敲一个斜杠就能触发的东西。如果你刚开始接触我的建议是别贪多。先挑一个你每天都要做、且步骤相对固定的活儿把它封装成一个命令用上一周感受一下哪里别扭再迭代。一个打磨好的命令胜过十个半成品。等你摸清了命令的脾气再往 skills 和团队协作方向扩展节奏会顺很多。最后分享一个我自己的小习惯我会在插件目录里放一个ideas.md专门记录“哪些重复劳动值得封装成命令”。想到就记周末挑一个实现。这个习惯让我半年内攒下了十几个真正在用的命令比一开始憋大招写一个“万能命令”靠谱得多。 
长河君 · 2026/10/18 22:55:51 · 阅读 1.2k Claude Code插件开发实战：用knowledge-work-plugins封装知识工作流
1. 从“knowledge-work-plugins”这个名字说起它到底在解决什么问题第一次看到knowledge-work-plugins这个仓库名很多人会下意识地把它当成又一个“插件合集”。但如果你真的在 Claude Code 或 Claude Cowork 里干过几天活就会明白它想解决的是一个更根本的痛点知识工作者的重复劳动能不能被封装成可复用的命令。我自己的日常是这样的写技术方案时要反复查同一批内部文档、做竞品分析时要按固定模板拉数据、每周复盘时要手动整理一堆散落的笔记。这些活儿单看都不难但架不住天天做。knowledge-work-plugins的核心思路就是把这些“知识工作流”抽象成 slash commands斜杠命令和配套的插件结构让你在 Claude Code 里敲一个/就能触发一整套预设动作。它适合谁三类人最该关注。第一类是重度使用 Claude Code 的开发者尤其是已经把 CLI 当成主力工作台的人第二类是做知识管理、内容运营、研究分析的知识工作者你们的工作流最容易被标准化第三类是想给自己团队搭一套内部 AI 工具链的技术负责人这个仓库的结构可以直接当模板抄。需要先说明一点knowledge-work-plugins本身不是一个开箱即用的成品软件它更像一套约定和骨架——告诉你插件目录怎么放、命令怎么定义、元数据怎么写、Claude Code 怎么发现并加载它们。理解了这套约定你就能把自己的工作流塞进去。下面我会从目录结构、命令定义、加载机制、实战封装、排错这几个角度把它拆开讲透。2. 插件目录结构与加载机制Claude Code 是怎么“看见”你的插件的2.1 一个插件的最小构成在 Claude Code 的插件体系里一个可被识别的插件通常包含这几个部分一个描述插件元信息的清单文件、若干命令定义文件、可选的技能skills目录、以及可选的资源文件。knowledge-work-plugins的价值在于它给出了一套经过实践检验的目录约定而不是让你从零猜。我实测下来最稳妥的最小结构是这样的knowledge-work-plugins/ ├── plugin.json # 插件元信息名称、版本、描述、作者 ├── commands/ # 斜杠命令定义 │ ├── summarize.md │ └── review.md ├── skills/ # 可复用的技能片段 │ └── doc-reader/ │ └── SKILL.md └── README.md这里的关键是plugin.json。它相当于插件的“身份证”Claude Code 启动时会扫描插件目录读取这个文件来判断“这是个什么插件、有哪些命令可用”。很多人第一次做插件失败就是因为清单文件的字段名写错或者路径没对上导致命令根本不出现。2.2 命令是怎么被解析成动作的斜杠命令的本质是一个带 frontmatter 的 Markdown 文件。你在 Claude Code 里敲/summarize它做的事情是找到commands/summarize.md读取里面的元数据比如命令描述、参数提示然后把正文内容作为提示词注入到当前会话上下文里。这意味着什么意味着命令的“智能”完全取决于你写的提示词质量。我见过太多人把命令写成一句干巴巴的“请总结这段内容”结果输出质量惨不忍睹。正确的做法是把命令当成一个微型工作流脚本来写明确输入是什么、处理步骤分几步、输出格式长什么样、遇到边界情况怎么处理。举个我实际在用的例子一个用于“技术方案评审”的命令正文大致是这样的逻辑先让模型提取方案的核心目标和技术选型再逐条对照检查清单可扩展性、成本、风险点最后按固定模板输出评审意见。这套东西写一次之后每次评审都省下十几分钟。2.3 加载顺序与优先级别踩这个坑Claude Code 加载插件时是有顺序的。通常它会先加载全局配置目录下的插件再加载项目级目录下的插件项目级的优先级更高。这个设计很合理——你可以在全局放一套通用命令在具体项目里放针对性的命令同名时项目级覆盖全局级。但这里有个很容易踩的坑如果你在项目里改了命令文件但 Claude Code 已经缓存了旧的你会发现改动不生效。解决办法是重启会话或者用命令重新加载插件。我一开始不知道这点改了半天提示词以为没生效白白浪费了半小时。记住改完插件文件先重启再验证。3. 把重复劳动变成斜杠命令三个真实工作流的封装过程3.1 工作流一会议纪要的标准化提炼知识工作者最烦的事情之一就是开完会还要花时间整理纪要。我的做法是封装一个/meeting-notes命令输入是原始会议记录可以是语音转文字后的草稿输出是结构化的纪要。命令正文我设计成三段式第一段让模型识别会议主题、参与角色、时间线第二段提取“决议事项”和“待办事项”待办必须带负责人和截止时间第三段生成一个简短的“下次会议前需要确认的问题”列表。为什么要分三段因为一次性让模型干太多事它容易漏项。分段处理每段聚焦一个目标输出质量明显更稳。实测下来有个细节值得分享在命令里明确要求“如果某项信息原文没有提到标注为‘待确认’而不是编造”这一句话能大幅降低模型幻觉。我早期版本没加这句结果纪要里经常冒出原文根本没有的“决议”差点造成误会。3.2 工作流二竞品资料的批量结构化做市场或产品分析的人经常要处理一堆竞品资料——官网截图、功能列表、定价页、用户评价。手动整理这些一天下来眼睛都花了。我封装了一个/competitor-digest命令配合 skills 目录里的一个“网页内容提取”技能。这个命令的设计要点是定义统一的输出 schema。我要求输出必须包含产品定位一句话、核心功能最多五条、定价模式、目标用户、明显短板。为什么强制 schema因为后续我要把这些结果汇总成对比表格如果每次输出格式都不一样汇总就是灾难。统一 schema 之后我甚至可以直接把多次输出拼成一张 Markdown 表格。这里有个经验把 schema 写进命令正文并且给出一个填写示例。模型看到示例输出格式的稳定性会高很多。纯文字描述格式它经常自由发挥。3.3 工作流三周报的自动草稿生成周报这东西写的人痛苦看的人也未必爱看。我的思路是让命令帮我生成草稿我再改。/weekly-draft命令的输入是我这一周的零散记录git commit、笔记、待办完成情况输出是一份按“本周进展 / 遇到的问题 / 下周计划”组织的草稿。关键在于输入的组织方式。我一开始直接把一堆杂乱文本丢进去结果模型抓不住重点。后来我改成在命令里要求“先按项目分组再在每个项目下提炼进展”输出立刻清爽了。这告诉我一个道理命令的提示词里处理步骤的顺序设计比措辞华丽重要得多。4. 命令提示词的写法决定插件好不好用的分水岭4.1 好命令和坏命令的差距在哪我对比过自己和同事写的同类命令差距非常明显。坏命令通常是这样的“请帮我分析这份文档。”好命令则是“你是一名资深技术评审请按以下步骤分析文档第一步提取核心论点第二步识别论据是否充分第三步指出逻辑漏洞第四步给出改进建议。输出用 Markdown每个部分用二级标题。”差距的本质是约束的密度。模型是个能力很强但需要明确指令的执行者你给的约束越具体它越不容易跑偏。但约束也不是越多越好太多会互相打架。我的经验是角色设定 步骤拆解 输出格式 边界处理这四样齐了就够再多就是过度设计。4.2 参数化让一个命令适配多种场景斜杠命令支持参数这是它比普通提示词强的地方。比如一个/translate命令可以通过参数指定目标语言和语气风格。参数化的好处是一个命令顶好几个不用为每种情况单独写。但参数化也有代价命令正文会变复杂维护成本上升。我的判断标准是——如果两种场景的处理逻辑有 70% 以上重合就参数化否则宁可拆成两个命令。硬把不相关的场景塞进一个命令最后谁都记不住怎么用。4.3 版本管理命令也是代码这一点很多人忽略。命令文件改来改去改坏了想回滚都难。我的做法是把插件目录纳入 git 管理每次改动写清楚 commit message。别小看这个习惯我有一次把一个用了半年的命令改崩了靠 git 五分钟就回滚了要是没版本管理得凭记忆重写。另外命令正文里我习惯留一个“变更记录”注释块记录每次改了什么、为什么改。过几个月回头看能省下大量“我当时为啥这么写”的困惑。5. 插件加载失败的排查链路从“命令不出现”到定位根因5.1 第一步确认插件目录被扫描到了命令敲了没反应先别急着改命令内容。第一步是确认 Claude Code 到底有没有扫描到你的插件目录。通常插件目录有固定的位置约定放错地方它根本不会看。我的排查顺序是先确认目录路径对不对再确认plugin.json是否存在且格式合法。plugin.json最常见的错误是 JSON 语法问题——多一个逗号、少一个引号整个文件就废了。我建议用编辑器的 JSON 校验功能先过一遍别靠肉眼。5.2 第二步确认命令文件的命名和位置命令能不能被识别取决于文件名和所在目录。commands/目录下的summarize.md对应/summarize。如果你把文件放错目录或者文件名带了不该有的字符命令就不会出现。我遇到过有人把命令放在command/少了个 s目录下排查了半天。还有一个隐蔽的坑文件名大小写。在某些系统上大小写不敏感换个系统就失效了。统一用小写加连字符是最稳的命名方式。5.3 第三步确认 frontmatter 格式正确命令文件顶部的 frontmatter 是元数据区格式错了命令可能加载但行为异常。常见问题是分隔符写错、字段名拼错。我建议直接复制一个能正常工作的命令文件当模板改内容不改结构能避开大部分格式坑。5.4 第四步看日志别猜前面三步都排除了就该看日志了。Claude Code 在加载插件时通常会输出一些信息告诉你哪些插件加载成功、哪些失败、失败原因是什么。养成看日志的习惯比盲目试错快十倍。我早期就是不看日志靠改文件反复重启效率极低。6. 从个人用到团队用插件体系的扩展思路6.1 把命令拆成“通用层”和“业务层”一个人用的时候命令怎么放都行。但一旦团队共用就得考虑分层。我的做法是通用层放跨项目都能用的命令比如文档总结、翻译、格式转换业务层放特定项目或团队的命令比如内部术语解释、特定报告模板。通用层放全局目录业务层放项目目录各取所需。这样分层的好处是新人入职只需要拉项目目录就能拿到业务相关的命令不用被一堆用不上的通用命令干扰。6.2 用 skills 目录沉淀可复用能力skills/目录是插件体系里被低估的部分。它适合放那些被多个命令共享的能力片段比如“读取并解析 PDF”“提取网页正文”“调用某个内部 API”。把这些能力抽成 skill命令里引用它避免重复写同样的提示词。我自己的经验是当发现三个以上命令都在重复同一段提示词时就该把它抽成 skill 了。这是典型的 DRY 原则在提示词工程里的应用。6.3 团队协作中的命名约定团队共用插件命名混乱是最大的敌人。我们内部定了一套约定命令名用“动词-名词”结构如summarize-doc、review-planskill 名用“能力”结构如pdf-reader、web-extractor。统一命名之后找命令、记命令都轻松很多。还有一点每个命令都要写清楚用途和输入要求放在命令描述里。团队里最怕的就是有人写了个命令别人不知道干嘛用的最后没人用白写。7. 我踩过的几个坑和对应的解法7.1 坑一命令提示词太长模型反而抓不住重点我一开始追求“把话说全”一个命令写了上千字提示词结果模型输出反而变差。后来我明白了提示词不是越长越好而是要结构清晰。把长提示词拆成带编号的步骤比堆成一大段效果好得多。现在我的命令正文基本控制在合理长度重点靠结构而不是字数。7.2 坑二忽略输出格式的稳定性早期我不太在意输出格式觉得内容对就行。直到我要把多次输出汇总成表格时才发现格式不统一有多痛苦。现在我写命令输出格式是必写项而且会给一个示例。这一条改动让我的后续处理效率提升了一大截。7.3 坑三没有给命令做“输入校验”有些命令对输入有要求比如必须是 Markdown、必须包含特定字段。如果输入不符合要求模型可能给出莫名其妙的输出。我的解法是在命令开头加一句“如果输入不符合以下要求请先指出问题而不是强行处理”。这一句话帮我避免了很多无效输出。7.4 坑四忘了命令也会“过时”工作流会变命令也得跟着改。我有几个命令用了半年没动后来发现里面的检查清单已经和实际流程脱节了。现在我养成了习惯每个季度过一遍常用命令该改的改该删的删。插件体系是活的不是写完就一劳永逸。8. 关于 knowledge-work-plugins 的一点个人判断用了一段时间下来我对knowledge-work-plugins这类插件体系的判断是它的价值不在于提供了多少现成命令而在于它把“知识工作流可被封装”这件事变得具体可操作了。以前我们谈 AI 提效总是停留在“让模型帮我写点东西”的层面有了插件体系你可以把一整套流程固化下来变成敲一个斜杠就能触发的东西。如果你刚开始接触我的建议是别贪多。先挑一个你每天都要做、且步骤相对固定的活儿把它封装成一个命令用上一周感受一下哪里别扭再迭代。一个打磨好的命令胜过十个半成品。等你摸清了命令的脾气再往 skills 和团队协作方向扩展节奏会顺很多。最后分享一个我自己的小习惯我会在插件目录里放一个ideas.md专门记录“哪些重复劳动值得封装成命令”。想到就记周末挑一个实现。这个习惯让我半年内攒下了十几个真正在用的命令比一开始憋大招写一个“万能命令”靠谱得多。