企业官网建设流程全解析

零散的提示词管理一直是个让人头疼的事。我自己的习惯是随手在备忘录、聊天窗口、代码注释里丢各种提示词片段，时间一长，找起来比翻旧账还累。直到最近用 WorkBuddy 花五分钟搭了个指令系统，把散落各处的提示词全收进一个统一入口，才算把这件事理顺了。这篇就聊聊我是怎么做的、中间踩了哪些坑、以及为什么这套思路比单纯堆一个提示词文档要靠谱得多。

1. 为什么零散提示词迟早会变成负担

1.1 提示词散落的三种典型状态

先说清楚问题本身。大部分人的提示词管理，基本逃不出这三种状态。

第一种是备忘录式。手机备忘录、电脑便签、微信文件传输助手，随手记一句"帮我总结这段代码的逻辑"，下次想用的时候翻半天，翻到了发现当时没写清楚上下文，还得重新补。

第二种是聊天记录式。跟 AI 对话时调出一个好用的提示词，效果不错，但下次想复用，得往上翻几十条消息，复制粘贴的时候还容易带上无关内容。

第三种是代码注释式。写代码的时候顺手在注释里塞一句提示词模板，时间久了代码重构，注释被删，提示词也跟着没了。

这三种状态的共同问题是：提示词和它的使用场景是绑死的。你在哪个场景写的，就只能在哪个场景找。一旦场景变了，提示词就变成了"死数据"。

1.2 提示词复用的真正门槛不是"写得好"

很多人以为提示词管理的核心是"写出高质量的提示词"。这个认知只对了一半。

写得好当然重要，但真正卡住大多数人的是复用成本。一个提示词哪怕写得再精妙，如果每次用都要经历"打开某个 App → 找到某个文件 → 定位到某一段 → 复制 → 切换到目标工具 → 粘贴 → 补上下文"这七步，那它的实际使用频率会低得可怜。

我做过一个粗略统计：一个提示词如果复用步骤超过三步，我实际会去用的概率不到 20%。这不是懒，是注意力切换的成本太高。每次切换都要重新建立上下文，等切回来的时候，原本想干的事已经忘了一半。

所以指令系统的核心目标不是"存"，而是降低调用成本。存得再整齐，调不出来等于没存。

1.3 指令系统和提示词文档的本质区别

这里要区分两个概念：提示词文档和指令系统。

提示词文档是一份静态清单，你打开它、浏览它、复制它。它解决的是"我知道我有哪些提示词"。

指令系统是一个可调用的入口，你输入一个短指令，它自动展开成完整的提示词并带上必要的上下文。它解决的是"我能在需要的时候立刻用上对的提示词"。

打个比方：提示词文档像一本菜谱，指令系统像厨房里贴好标签的调料架。菜谱你得翻，调料架你伸手就够。

WorkBuddy 在这件事上的价值，就是让你能用很低的成本把"菜谱"变成"调料架"。它本身不是一个提示词管理工具，但它提供的指令定义能力，刚好能承载这个需求。

2. 用 WorkBuddy 搭指令系统的核心思路

2.1 先想清楚指令的粒度

动手之前，先定一个原则：一条指令只干一件事。

我见过有人把"写代码 + 写测试 + 写文档 + 提交信息"塞进一条指令里，结果每次调用都要手动删掉不需要的部分，反而更麻烦。

合理的粒度是这样的：

• 原子指令：只做一件事，比如"把这段代码转成 TypeScript"、"给这个函数写单元测试"、"把这段中文翻译成技术英文"。
• 组合指令：由多个原子指令按顺序拼成，比如"代码审查流程"= 静态检查 + 逻辑审查 + 安全审查 + 生成报告。

原子指令是积木，组合指令是搭好的模型。日常用得最多的是原子指令，组合指令用在固定流程上。

2.2 指令的命名要"能猜"

命名这件事看起来小，实际影响很大。我的经验是：指令名要让人能猜出它干什么，而不是让人记住它叫什么。

不好的命名：prompt_01、helper、tool_a。

好的命名：code-review、translate-zh2en、gen-test、explain-code。

判断标准很简单：隔一周回来，你看到这个名字，能不能不点开就知道它是干什么的。如果不行，就改。

WorkBuddy 里定义指令的时候，名称和描述是分开的。名称要短、要好猜，描述可以写详细一点，说明适用场景和注意事项。这样在列表里扫一眼就能定位。

2.3 参数化是指令系统的灵魂

如果指令是写死的，那它跟复制粘贴没区别。指令系统的价值在于参数化。

举个具体例子。我有一条指令叫explain-code，它的作用是解释一段代码。如果写死成"请解释以下代码"，那每次用都要手动补代码。但如果定义成带参数的：

指令：explain-code 参数：{code}、{language}、{level} 模板：请用 {level} 的详细程度，解释以下 {language} 代码的逻辑、边界条件和潜在问题： {code}

调用的时候只需要填三个参数，输出就自动带上合适的详细程度和语言上下文。level可以填"一句话"、"中等"、"逐行"，对应不同的解释深度。

参数化的另一个好处是可组合。explain-code的输出可以作为gen-test的输入，gen-test的输出可以作为code-review的输入。指令之间能串起来，才叫系统。

2.4 五分钟能搭出什么

说"五分钟"不是夸张，但要说清楚这五分钟搭的是什么。

五分钟能搭出的是最小可用版本：三到五条高频原子指令，每条带一两个参数，能在 WorkBuddy 里正常调用。这个版本已经能解决 80% 的日常复用需求。

五分钟搭不出的是完整的指令库。完整的库需要你花时间梳理自己到底有哪些高频场景，哪些提示词值得沉淀，哪些是一次性的。这部分工作没法压缩，但可以边用边补。

我的做法是：先搭最小版本，用起来，用的时候发现缺什么就补什么。不要一开始就想着搭一个完美的库，那样大概率会卡在"整理"阶段，永远用不上。

3. 从零搭建指令系统的完整操作

3.1 环境准备与 WorkBuddy 基础配置

WorkBuddy 的安装不复杂，官网下载对应平台的安装包，按提示走就行。安装完之后第一次启动，会让你选工作目录和默认模型，这两个按自己的习惯来。

这里有一个容易被忽略的点：工作目录的选择。WorkBuddy 的指令定义文件默认存在工作目录下，如果你后面要同步或者备份，工作目录的位置就很关键。我的建议是放在一个你经常备份的目录里，比如~/Documents/workbuddy或者某个云同步文件夹下。不要放在临时目录或者桌面，桌面文件多了容易被误删。

配置模型的时候，如果你有多个模型可用，建议先配一个主力模型和一个备用模型。主力模型用于日常指令调用，备用模型用于主力不可用时的降级。WorkBuddy 支持在指令级别指定模型，这个后面会用到。

3.2 定义第一条指令：从最高频的场景开始

不要一上来就定义十条。先定义你每天都会用到的那一条。

对我来说，最高频的场景是"解释代码"。每天看别人的代码、看开源项目、看自己一周前写的代码，都需要快速理解逻辑。所以第一条指令就是explain-code。

在 WorkBuddy 里定义指令，大致是这样的结构：

name: explain-code description: 解释一段代码的逻辑、边界和潜在问题 parameters: - name: code required: true - name: language required: false default: auto - name: level required: false default: 中等 template: | 请用{level}的详细程度解释以下{language}代码。 要求： 1. 先说明这段代码的整体目的 2. 再逐段说明关键逻辑 3. 指出边界条件和可能的异常情况 4. 如果有明显的性能或安全问题，单独列出 代码： {code}

定义完之后，调用的时候只需要提供code参数，其他两个有默认值。如果某次需要特别详细的解释，把level改成"逐行"就行。

这里有个细节：模板里要写清楚输出结构。很多人写提示词只写"请解释这段代码"，结果模型输出的详略程度完全看心情。把输出结构写死，每次拿到的结果格式就稳定，后续处理也方便。

3.3 参数设计：哪些该做成参数，哪些该写死

参数设计是搭指令系统时最容易做错的地方。我的经验是：变化频率高的做成参数，变化频率低的写死在模板里。

拿explain-code举例：

• code每次都变，必须做成参数。
• language大部分时候能从代码里推断出来，做成可选参数，默认auto。
• level大部分时候用"中等"，偶尔需要调整，做成可选参数。
• "先说明整体目的，再逐段说明"这个结构，几乎不变，写死在模板里。

判断标准是：如果某个部分你十次里有八次都用同一个值，就写死；如果十次里有三次以上要改，就做成参数。

参数太多也是问题。一条指令超过五个参数，调用的时候光填参数就累了，反而降低使用频率。如果发现参数太多，说明这条指令该拆了。

3.4 指令的存储与版本管理

WorkBuddy 的指令定义是文本文件，这意味着你可以用 Git 来管理。

我自己的做法是在工作目录下建一个instructions文件夹，每条指令一个文件，然后用 Git 跟踪。这样有几个好处：

• 改坏了能回滚。
• 换电脑能同步。
• 能看出某条指令是什么时候加的、为什么加的。

提交信息我一般写清楚"加了什么指令"或者"改了哪条指令的哪个参数"。比如add: explain-code 指令，支持 level 参数。这样过几个月回头看，能快速回忆起当时的思路。

如果你不想用 Git，至少要做到定期备份。指令库是你长期积累的资产，丢了很麻烦。

3.5 跑通第一条指令的验证方法

定义完第一条指令，不要急着定义第二条。先用一周，看它是不是真的解决了你的问题。

验证的方法很简单：每次需要解释代码的时候，强迫自己用指令调用，而不是直接复制粘贴。如果一周下来你发现自己还是习惯直接复制粘贴，说明这条指令要么不好用，要么场景选错了。

我第一条指令跑通之后，发现两个问题：一是level参数我几乎没改过，说明这个参数可以去掉；二是输出里经常缺少"这段代码在项目里的位置"这个信息，后来在模板里加了一句"如果代码里有 import 或依赖，说明它们的作用"。

这两个调整都是用了之后才发现的。所以先跑起来，再优化，不要想着一次定义完美。

4. 实测中遇到的坑和调整

4.1 指令名冲突和覆盖问题

WorkBuddy 里如果两条指令重名，后定义的会覆盖先定义的。这个机制本身没问题，但容易踩坑。

我遇到过的情况是：先定义了一条review，后来想加一条代码审查的指令，顺手也命名为review，结果把原来的覆盖了。等发现的时候，原来那条已经找不回来了。

避免这个坑的方法有两个：

• 命名加前缀。比如代码相关的用code-开头，文档相关的用doc-开头，翻译相关的用trans-开头。这样不同领域的指令不会撞名。
• 定义前先搜一下。WorkBuddy 的指令列表支持搜索，定义新指令之前先搜一下名字，确认没有重名。

如果已经覆盖了，检查 Git 历史或者备份，看能不能恢复。恢复不了就只能重写，所以备份很重要。

4.2 参数默认值设错导致的输出偏差

参数默认值设错是个隐蔽的坑。因为默认值不对的时候，输出看起来"也能用"，但质量会悄悄下降。

我踩过的一个坑是explain-code的level默认值。一开始我设的是"详细"，结果每次解释一段简单代码，模型都输出一大篇，看的时候要跳着看。后来改成"中等"，输出长度才合理。

另一个坑是language的默认值。我一开始设的是auto，但模型有时候会把 Python 代码识别成伪代码，解释的时候用错术语。后来改成必填，虽然多填一个参数，但输出质量稳定多了。

默认值的调整原则是：宁可让用户多填一个参数，也不要让默认值产生低质量输出。低质量输出比多填一个参数更消耗时间。

4.3 模板里的"隐形假设"

模板写多了会发现，很多提示词里藏着"隐形假设"。这些假设在你写的时候是成立的，但换个人用、或者过一段时间用，就不成立了。

比如我有一条gen-test指令，模板里写的是"为以下函数生成单元测试，使用 Jest 框架"。这个"Jest 框架"就是隐形假设。如果某天我要给一个 Python 项目生成测试，这条指令就不适用了。

解决办法是把隐形假设显式化成参数。gen-test改成带framework参数，默认jest，需要的时候改成pytest或者junit。

检查隐形假设的方法：把模板读一遍，问自己"这句话在什么情况下不成立"。不成立的情况越多，越应该做成参数。

4.4 多指令串联时的上下文丢失

指令串联是指令系统的高级用法，但也是最容易出问题的地方。

我试过把explain-code的输出直接喂给gen-test，结果gen-test拿到的是一段解释文字，而不是原始代码，生成的测试完全对不上。

问题出在上下文传递上。explain-code的输出是"解释"，gen-test需要的是"代码"。两者格式不匹配，直接串联就会出错。

解决办法有两个：

• 中间加一步提取。用一条extract-code指令从解释文字里把代码提取出来，再喂给gen-test。
• 让上游指令输出结构化数据。explain-code的输出里把代码单独放在一个代码块里，gen-test只读代码块部分。

我选的是第二种，因为少一步调用。具体做法是在explain-code的模板里加一句"最后把原始代码原样放在一个代码块里输出"。这样下游指令能直接定位到代码块。

4.5 指令库膨胀后的检索问题

指令库超过二十条之后，检索就成了问题。列表翻起来慢，搜索又经常搜不到想要的。

我的应对方法是分层：

• 常用层：五到八条每天都会用的指令，放在最前面，命名短、好记。
• 场景层：按场景分组，比如"代码相关"、"文档相关"、"翻译相关"，每组五到十条。
• 归档层：不常用但不想删的，放到单独的分组里，需要的时候再翻。

WorkBuddy 支持给指令加标签或者分组，用这个功能把指令分好，检索效率会高很多。

另外，定期清理也很重要。每个月花十分钟过一遍指令库，把三个月没用过的指令归档或者删掉。指令库不是越大越好，是越精越好。

5. 指令系统跑顺之后的实际收益

5.1 调用成本从七步降到两步

搭完指令系统之后，最直观的变化是调用成本。

以前用一条提示词，要经历"打开备忘录 → 找到文件 → 定位段落 → 复制 → 切换工具 → 粘贴 → 补上下文"七步。现在只需要"打开 WorkBuddy → 输入指令名和参数"两步。

步骤少了，使用频率自然就上去了。以前一周用两三次的提示词，现在每天都会用。用得多了，对提示词的理解也更深，反过来又能优化提示词本身。

5.2 提示词质量在复用中自然提升

这一点是我没想到的。指令系统跑顺之后，提示词的质量会自动提升。

原因是：每次调用都是一次测试。用得多了，哪些地方输出不稳定、哪些参数经常要改、哪些结构模型理解不了，都会暴露出来。暴露出来就能改，改了之后下次调用质量就更好。

这跟写代码是一个道理。代码跑得多了，bug 才会暴露，暴露了才能修。提示词如果一直躺在备忘录里，永远不知道它哪里有问题。

5.3 从"找提示词"变成"用提示词"

最后一个变化是心态上的。

以前用提示词，大部分时间花在"找"上。找到之后匆匆用一下，效果不好也懒得改，因为改的成本比重新写还高。

现在用提示词，时间花在"用"上。调用快，改起来也快，效果不好当场就调。调完下次调用就是新版本。

这个转变看起来小，实际影响很大。它把提示词从"一次性消耗品"变成了"可迭代资产"。资产是会增值的，消耗品用完就没了。

6. 后续可以继续扩展的方向

6.1 把指令系统接到自动化流程里

指令系统跑顺之后，下一步可以接到自动化流程里。

比如提交代码之前自动跑一遍code-review，把审查结果附在提交信息里。或者每天定时跑一遍summarize-changes，把当天的代码变更总结成日报。

WorkBuddy 支持命令行调用，这意味着它可以被脚本调用。写一个简单的 shell 脚本，把指令调用嵌进去，就能实现自动化。

6.2 多模型切换与降级策略

如果手头有多个模型可用，可以在指令级别做模型切换。

我的做法是：日常指令用主力模型，对速度要求高的指令用轻量模型，对质量要求高的指令用大模型。WorkBuddy 的指令定义里可以指定模型，切换起来很方便。

降级策略也值得配一下。主力模型不可用的时候，自动切到备用模型，虽然质量可能差一点，但至少不中断。

6.3 指令库的团队共享

如果团队里多个人都用 WorkBuddy，指令库可以共享。

共享的方式很简单：把instructions文件夹放到一个共享仓库里，每个人拉下来用。这样团队里积累的好指令，所有人都能用上。

共享的时候要注意命名规范和参数约定。不然 A 定义的review和 B 定义的review参数不一样，用起来会乱。建议团队里定一个简单的命名规范，比如统一用领域-动作的格式。

6.4 从指令系统到工作流系统

指令系统的下一步是工作流系统。

指令是单步的，工作流是多步的。把常用的指令按顺序串起来，加上条件判断和循环，就是一个简单的工作流。

比如"代码提交前检查"这个工作流：先跑lint，通过后跑gen-test，测试通过后跑code-review，审查通过后生成提交信息。每一步的指令都是现成的，串起来就是一个完整的工作流。

WorkBuddy 目前对工作流的支持还在完善中，但用指令串联加脚本的方式，已经能实现大部分需求。

最后分享一个我自己的小习惯：每次定义新指令的时候，在描述里写一句"这条指令解决什么问题"。过一段时间回头看，能快速判断这条指令还有没有用。没用的就归档，有用的就优化。指令库跟代码库一样，需要定期维护，不然会变成技术债。