企业官网建设流程全解析

1. 从"knowledge-work-plugins"这个仓库名说起

第一次看到knowledge-work-plugins这个名字，我的直觉是：这不是一个普通的工具库，而是一套面向"知识工作"场景的插件集合。知识工作这个词覆盖面很广——写文档、做调研、整理会议纪要、维护代码库、管理项目进度，凡是围绕信息加工和产出展开的工作，都可以归到这个范畴里。而 plugins 这个词则说明它的组织形态是插件化的，也就是说，它不是一个单体应用，而是一组可以按需加载、按需组合的能力单元。

结合热搜词里高频出现的 Claude Code、slash commands、Claude Cowork 这些关键词，可以基本判断出这个仓库的定位：它是围绕 Claude Code 这类命令行智能体工具构建的一套插件体系，核心载体是 slash commands（斜杠命令），目标是把知识工作中反复出现的操作模式沉淀成可复用的命令。

为什么这件事值得单独拿出来讲？因为大多数人用 Claude Code 的方式还停留在"打开终端，敲一句话，等它回答"的阶段。这种方式在一次性任务上没问题，但一旦你每天都要做类似的事情——比如每天早上整理昨天的提交记录、每周生成一份项目周报、每次开会前拉取相关文档做背景调研——你就会发现自己在重复输入几乎相同的提示词。插件化的意义就在于把这些重复模式固化下来，变成一条 slash command，输入/weekly-report就能触发一整套预设好的工作流。

这个仓库适合谁来参考？三类人：一是已经在用 Claude Code 但还没系统化整理自己工作流的开发者；二是想把团队内部知识工作标准化的技术负责人；三是对智能体插件机制感兴趣、想自己动手写插件的人。哪怕你目前还没用过 Claude Code，理解这套插件设计思路对你设计自己的自动化流程也有直接帮助，因为它的核心思想是通用的：把高频操作抽象成命令，把命令组织成插件，把插件按场景组合。

2. 插件化知识工作的底层逻辑

2.1 为什么是 slash commands 而不是普通提示词

普通提示词的问题在于它是"一次性"的。你输入一段话，模型给你一个回答，这段对话结束之后，那段精心构造的提示词就散落在历史记录里了。下次想复用，要么翻历史，要么重新打一遍。slash command 解决的就是这个复用问题——它把提示词模板化、参数化、命名化。

我自己的体会是，一个成熟的 slash command 应该具备三个特征。第一是命名即意图，看到/review-pr就知道它是做代码审查的，不需要额外解释。第二是参数化输入，比如/review-pr 1234里的 1234 是 PR 编号，命令本身不写死具体对象。第三是输出结构化，每次执行的结果格式一致，方便后续处理或归档。

这三点看起来简单，但真正做到位需要设计功力。我见过不少自己写的命令，命名含糊（比如/do-stuff），参数靠自然语言描述（"帮我看看那个 PR"），输出每次格式都不一样。这种命令用两次就不想用了，因为它没有降低认知负担，反而增加了一层"我还要记住这个命令怎么用"的负担。

2.2 插件作为命令的容器

单个命令解决单个问题，但知识工作往往是成串的。比如"准备一次技术分享"这件事，拆开来看包括：调研主题相关资料、整理成大纲、生成讲稿要点、准备演示代码、写一份给听众的背景阅读材料。这五件事如果各写一个命令，散落在各处，用的时候要一个个找。插件的作用就是把这些相关命令打包在一起，形成一个"技术分享准备"插件。

这种组织方式的好处在于上下文共享。同一个插件里的命令可以共享配置、共享模板、共享参考资料。比如技术分享插件里可以内置一套讲稿模板，所有命令生成的内容都遵循这个模板的格式。这比每个命令各自维护一套模板要高效得多，也更容易保持一致。

从工程角度看，插件还提供了版本管理和分发的能力。你可以把团队共用的插件放在一个仓库里，通过版本号控制更新，新成员入职时拉取插件就能获得整套标准化的工作流。这一点对于团队协作场景特别有价值——它把"老员工脑子里的经验"变成了"新员工可以直接调用的命令"。

2.3 知识工作场景的特殊性

为什么这个仓库叫 knowledge-work-plugins 而不是 dev-plugins 或 coding-plugins？因为知识工作和纯编码工作有一个关键区别：输入和输出的边界更模糊。写代码时，输入是需求，输出是能跑的程序，对错相对明确。但知识工作的产出——一份调研报告、一次会议纪要、一个项目规划——质量高低往往取决于上下文是否充分、结构是否合理、表达是否清晰，这些都没有编译器帮你检查。

这就意味着知识工作插件需要更注重上下文的组织和输出的结构化。一个编码插件可能只需要把代码片段拼起来就行，但一个知识工作插件需要考虑：需要预先加载哪些背景资料？输出应该遵循什么结构？哪些部分需要人工确认？这些考量直接影响了插件的设计复杂度。

我在实际使用中的一个发现是，知识工作插件里最值钱的往往不是"生成"那一步，而是"准备上下文"那一步。比如做竞品调研，让模型直接写分析很容易流于表面，但如果插件能先把竞品的官网、文档、更新日志抓取整理好，再让模型基于这些材料分析，质量会高出一个档次。所以好的知识工作插件，前半段功夫都花在"喂料"上。

3. 拆解一个知识工作插件的完整结构

3.1 目录布局与文件职责

一个典型的插件目录结构大致是这样的：

knowledge-work-plugins/ weekly-report/ plugin.json # 插件元信息：名称、版本、描述、作者 commands/ generate.md # /weekly-report generate 命令定义 preview.md # /weekly-report preview 命令定义 templates/ report.md # 周报输出模板 config/ default.json # 默认配置：数据源、时间范围等 README.md # 使用说明

这个结构里，plugin.json是入口，它告诉宿主工具"我是一个插件，我叫什么，我包含哪些命令"。commands/目录下每个.md文件对应一条 slash command，文件名就是命令名。templates/存放输出模板，config/存放默认配置。

这里有个容易忽略的细节：命令定义文件用 Markdown 而不是 JSON 或 YAML。这是刻意的设计选择。因为命令定义里最核心的部分是提示词，而提示词本质上是自然语言文本，用 Markdown 写最自然，还能顺便用标题、列表来组织结构。如果强行用 JSON 写，提示词就得塞在一个字符串字段里，换行和格式都很别扭。

3.2 命令定义文件里到底写什么

一条 slash command 的定义文件，核心包含四块内容：元信息、参数说明、提示词主体、输出约定。

元信息部分声明这条命令叫什么、做什么用、需要什么参数。参数说明部分告诉使用者怎么传参，以及参数缺失时的默认行为。提示词主体是重头戏，它决定了模型收到命令后实际执行什么逻辑。输出约定部分则规定结果应该以什么格式呈现。

我拿一个"会议纪要整理"命令举例，提示词主体大概是这样组织的：

## 任务 将原始会议记录整理成结构化纪要。 ## 输入 原始记录：{{input}} 参会人列表：{{attendees}} ## 处理要求 1. 提取所有决议事项，每条注明负责人和截止时间 2. 提取待办事项，按优先级排序 3. 标记存在分歧未达成一致的话题 4. 保留关键讨论中的数字和事实性信息 ## 输出格式 遵循 templates/meeting-notes.md 的结构

注意这里的{{input}}和{{attendees}}是占位符，执行时会被实际参数替换。这种模板化的写法让同一条命令可以处理任意一次会议，而不是写死某一次。

3.3 模板与配置的分离

把模板和配置从命令定义里抽出来单独存放，这个设计初看有点多余，但实际用起来会发现很关键。原因是命令逻辑相对稳定，但输出格式和配置经常变。比如周报模板，这个季度可能想突出项目进度，下个季度可能想突出数据指标。如果模板写在命令定义里，每次改格式都要动命令逻辑，容易改出问题。分开之后，改模板就是改一个 Markdown 文件，风险低得多。

配置分离的道理类似。数据源地址、默认时间范围、输出语言这些配置项，不同人、不同项目可能不一样。放在config/default.json里，使用者可以覆盖而不影响命令本身。这种"逻辑与数据分离"的思路，和软件开发里的配置外置是同一个道理。

提示：模板文件建议用纯 Markdown 写，不要嵌入复杂的条件逻辑。如果发现模板里需要大量 if-else，说明应该拆成多个模板，而不是把逻辑塞进模板。

4. 从零构建一个可用的知识工作插件

4.1 先想清楚要解决哪个重复劳动

动手写插件之前，最该做的一件事是记录自己一周内重复输入了哪些提示词。我的做法是连续记三天，每次发现自己"又在打差不多的话"就记一笔。三天下来通常会浮现出三到五个高频模式，这些就是最值得做成命令的候选。

选第一个要做的命令时，有个原则：选那个你每天都会用、且逻辑相对简单的。不要一上来就挑战最复杂的场景，因为复杂场景往往需要反复调试提示词，容易打击积极性。先做一个简单的跑通全流程，把插件结构、命令定义、模板配置这套机制摸熟，再去做复杂的。

我第一个做的命令是"整理今日提交记录"。逻辑很简单：读取 git log，按模块分组，生成一段人话描述。这个命令我每天下班前跑一次，用了两周之后发现确实省事，才开始做第二个。

4.2 提示词主体的写法要点

写命令的提示词主体时，有几个反复踩过的坑值得说。

第一个坑是指令太笼统。比如写"帮我分析这段代码"，模型不知道你要分析什么维度——是找 bug、看性能、还是评可读性？好的写法是明确列出分析维度，甚至给出每个维度的判断标准。

第二个坑是没有给输出示例。知识工作的输出质量很依赖格式，如果你希望纪要里每条决议都带负责人和截止时间，最好在提示词里给一个示例条目，模型会照着这个格式来。光用文字描述"要带负责人和截止时间"，模型可能理解成"在段落里提一下负责人"。

第三个坑是忽略了边界情况。比如输入为空怎么办？输入格式不对怎么办？这些在提示词里最好有兜底说明，否则模型可能编造内容来填补空白。我一般会在提示词末尾加一句"如果输入信息不足以完成某项要求，明确标注'信息不足'，不要推测"。

4.3 参数传递与默认值设计

slash command 的参数传递方式，不同宿主工具实现不一样，但核心思路相通：命令名后面跟的内容会被解析成参数。设计参数时要注意位置参数和命名参数的区别。

位置参数适合必填的、顺序固定的输入，比如/review-pr 1234里的 1234。命名参数适合可选的、有默认值的输入，比如/weekly-report --range=7d --format=markdown。命名参数的好处是使用者可以只传自己关心的那个，其他走默认值。

默认值的设计要遵循"最常用即默认"原则。比如周报命令的默认时间范围，如果团队习惯是按周汇报，那默认就是 7 天；如果习惯按双周，默认就设 14 天。默认值设对了，大部分时候使用者不需要传任何参数，直接敲命令名就行，这才是真正降低负担。

4.4 本地测试与迭代节奏

插件写完不是终点，而是起点。我的习惯是新命令先自己用一周，期间记录每次用的时候哪里别扭、哪里输出不对。一周后集中改一次，改完再用一周。两轮下来基本就稳定了。

测试时有个技巧：故意传一些边界输入。比如空输入、超长输入、格式混乱的输入，看命令会不会崩或者输出离谱内容。知识工作场景的输入往往来自真实世界，格式千奇百怪，提前测过边界情况能省很多事。

迭代时还要注意版本管理。每次改动命令逻辑，在plugin.json里升一下版本号，并在 README 里记一笔改了什么。这样如果改出问题，能快速回退到上一个可用版本。我吃过这个亏——有次改了个命令的提示词，结果输出格式全乱了，又没记改了什么，只能凭记忆往回找。

5. 插件组合与工作流编排

5.1 单命令的局限与组合的必要性

单个命令能解决单点问题，但真实的知识工作往往是多步骤的。比如"准备一次客户沟通"，涉及：拉取客户历史沟通记录、整理当前待解决问题、生成沟通议程、准备可能被问到的问题及回答。这四步如果各是一个命令，手动依次执行也能完成，但中间需要人工传递上下文——第一步的输出要手动复制给第二步。

插件组合要解决的就是这个上下文传递问题。理想情况下，一个"客户沟通准备"插件里，命令之间可以共享中间产物。第一步拉取的记录存到一个临时文件，第二步直接读这个文件，不需要人工搬运。

5.2 用主命令编排子命令

实现组合的一种常见做法是设计一个主命令，它负责按顺序调用子命令并传递上下文。使用者只需要执行主命令，比如/client-meeting prepare --client=acme，主命令内部依次触发拉取、整理、生成议程、准备问答这几个步骤。

主命令的提示词主体里，会明确写出"先执行 X，将结果作为 Y 的输入，再执行 Z"。这种编排逻辑写在提示词里，而不是写在代码里，好处是灵活——想调整顺序或增删步骤，改提示词就行，不需要改代码。

不过这种方式的代价是调试难度上升。多步骤串联时，如果最终输出不对，很难定位是哪一步出的问题。我的应对办法是在主命令里加一个"详细模式"，开启后每一步的中间产物都会打印出来，方便排查。

5.3 跨插件协作的接口约定

比插件内组合更复杂的是跨插件协作。比如"项目周报"插件可能需要调用"代码统计"插件的能力来获取本周提交数据。这种跨插件调用需要一个稳定的接口约定。

接口约定的核心是输入输出格式的标准化。如果"代码统计"插件的输出格式是固定的 JSON 结构，那"项目周报"插件就可以放心地解析它。反过来，如果输出格式随版本变化，跨插件调用就会很脆弱。

我在设计跨插件接口时，会遵循一个原则：输出尽量用结构化格式，且字段名保持稳定。哪怕人类阅读时更喜欢看自然语言段落，但为了能被其他插件消费，关键数据要以结构化形式同时输出。比如既输出一段人话总结，也输出一个 JSON 块，各取所需。

6. 实际使用中踩过的坑与应对

6.1 提示词过长导致的注意力稀释

知识工作插件的提示词往往很长，因为要交代背景、列要求、给示例、写兜底。但提示词太长会有一个副作用：模型对靠后内容的注意力下降。我遇到过提示词写到两千字，结果模型只执行了前半部分要求，后半部分的格式约定完全忽略。

应对办法是把最重要的要求放在最前面，并且用醒目的标记（比如加粗、单独成段）突出。另外，如果提示词确实很长，考虑拆成多个命令，每个命令的提示词控制在合理长度内。我现在的习惯是单条命令的提示词尽量不超过八百字，超了就拆。

6.2 输出格式不稳定的排查思路

输出格式不稳定是知识工作插件最常见的问题。同样的命令，有时候输出带标题层级，有时候不带；有时候用列表，有时候用段落。排查这个问题，我一般按这个顺序看：

先看提示词里格式要求是否明确。如果只写了"输出结构化"，那模型自由发挥很正常，得改成"输出必须包含以下三级标题：背景、进展、问题"。

再看是否有示例。给了示例的输出格式，稳定性会明显提升。

最后看输入是否影响了格式。有时候输入本身格式混乱，模型会"入乡随俗"跟着乱。这种情况需要在提示词里明确"无论输入格式如何，输出一律遵循以下格式"。

6.3 命令命名冲突与命名空间

当插件多起来之后，命令命名冲突会成为一个实际问题。两个插件里都有/summary命令，执行时到底调哪个？解决办法是用命名空间隔离，比如/weekly-report:summary和/meeting:summary，冒号前面是插件名，后面是命令名。

设计命名空间时，插件名要短且有辨识度。weekly-report比weekly-report-generation-plugin好，因为使用者要手打这个前缀。命令名则要动词优先，generate、preview、export这种，比generation、previewer更符合直觉。

6.4 权限与敏感信息的处理

知识工作经常涉及内部资料，插件在处理这些内容时要注意不要把敏感信息写进日志或临时文件。我的做法是：涉及敏感数据的命令，中间产物写到内存或临时目录，命令执行完自动清理；输出里如果需要展示敏感信息，做脱敏处理。

另外，插件配置里如果包含访问凭证，不要提交到版本库。用环境变量或本地配置文件的方式管理，并在 README 里明确说明需要哪些环境变量。这一点在团队共享插件时尤其重要，否则很容易把凭证泄露出去。

7. 把插件体系用出复利效应

7.1 从个人工具到团队资产

插件一开始往往是个人的效率工具，但它的价值在团队场景下会放大。当一个人把自己沉淀的命令分享出来，其他人直接就能用，省去了各自摸索的时间。更进一步，团队可以约定一套共用的插件集，新成员入职时拉取这套插件，等于继承了整个团队的工作方法。

从个人工具变成团队资产，中间需要补的是文档和约定。个人用的命令，命名随意一点、参数少一点都没关系，因为自己记得。但团队共用时，每条命令都需要有清晰的使用说明，参数要有明确含义，输出格式要稳定。这些在个人阶段可以偷懒，在团队阶段偷不得。

7.2 定期回顾与淘汰机制

插件用久了会积累，但不是每个都值得留着。我每季度会回顾一次自己写的命令，看哪些还在用、哪些已经很久没碰。很久没碰的，要么删掉，要么合并到别的命令里。留着不用的命令会增加认知负担——每次敲命令时看到一长串列表，还得想"这个命令是干嘛的"。

淘汰的标准很简单：过去一个月用过没有。没用过就考虑删。如果舍不得删，说明它可能还有潜在价值，那就把它移到"归档"分类里，不占用主命令列表的位置。

7.3 插件设计的可迁移经验

最后说一点跳出具体工具的体会。这套插件设计的思路——把高频操作抽象成命令、把命令组织成插件、用模板和配置分离逻辑与数据、用命名空间管理冲突——这些经验不局限于某一个工具。任何需要把重复性知识工作自动化的场景，都可以套用这个框架。

我自己后来把这套思路用在了别的地方，比如整理一套自己的文档处理流程、搭建一个内容生产的流水线，底层逻辑是一样的：先识别重复模式，再抽象成可复用单元，最后组织成体系。工具会变，但这套方法论是通用的。

注意：插件体系的价值不在于命令数量多，而在于每条命令都真正被用起来。宁可只有五条天天用的命令，也不要五十条躺在那里吃灰的命令。