企业官网建设流程全解析

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. 可读性：命名、结构、注释 输出格式： - 按严重程度从高到低排列问题 - 每个问题给出：位置、原因、修改建议（附代码示例） - 最后给出总体评价 代码： $ARGUMENTS

3.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.md

4.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里写清楚这是哪个层级的命令，避免混淆。团队协作时，把命名规范写进文档，从源头杜绝冲突。

6. 进阶玩法与扩展方向

6.1 把插件做成可配置的

基础插件是写死的提示词，进阶玩法是让它可配置。你可以在命令目录旁边放一个配置文件，提示词里引用配置项。比如审查严格程度、输出语言、是否包含示例，都可以做成配置。

这样一条命令能适配不同场景，不用维护多个变体。配置的读取方式取决于 Claude Code 的能力，如果它支持读取文件，那配置文件就能直接注入；如果不支持，可以用参数传递的方式模拟。

6.2 插件与外部工具的联动

Claude Code 能执行 shell 命令，这意味着插件可以调用外部工具。比如一个/test命令，可以先运行测试套件，再把失败结果交给模型分析。一个/deploy命令，可以调用部署脚本，再让模型检查部署日志。

这种联动把 Claude Code 从“对话工具”变成了“工作流引擎”。但要注意安全边界，涉及写操作、删除操作、生产环境操作的命令，一定要加确认步骤，别让模型自动执行危险操作。

6.3 建立团队插件库

当团队规模上来之后，零散的插件文件就不够用了。你需要一个团队级的插件库，包含：统一的命名规范、提示词编写指南、插件模板、review 流程、版本管理策略。

knowledge-work-plugins本身就是一个很好的参考模板。你可以 fork 它，删掉不需要的，加上自己团队的，形成内部版本。关键是建立维护机制，插件库不是建完就完事，需要持续迭代。

我个人的体会是，插件库的价值随时间增长。刚开始可能只有几个命令，用着用着你会发现越来越多可以沉淀的场景，半年下来就是一套相当完整的资产。而且这套资产是跟着团队走的，人走了知识还在，这是它比“个人提示词笔记”强的地方。

6.4 持续迭代的节奏把控

最后说说迭代节奏。我的建议是小步快跑，按需新增。不要一开始就想设计一套完美体系，那只会让你迟迟不动手。先用起来，遇到重复劳动就沉淀一个命令，用着不顺手就改，改完继续用。

每个月花半小时回顾一下这个月新增和修改的命令，清理掉不再用的，合并重复的，优化高频使用的。这个习惯坚持下来，你的插件库会越来越贴合实际工作，而不是变成一堆没人用的僵尸文件。

插件这东西，写得好不好，用一周就知道。别追求一次到位，追求持续可用。