零散的提示词管理一直是个让人头疼的事。我自己的习惯是随手在备忘录、聊天窗口、代码注释里丢各种提示词片段时间一长找起来比翻旧账还累。直到最近用 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 目前对工作流的支持还在完善中但用指令串联加脚本的方式已经能实现大部分需求。最后分享一个我自己的小习惯每次定义新指令的时候在描述里写一句这条指令解决什么问题。过一段时间回头看能快速判断这条指令还有没有用。没用的就归档有用的就优化。指令库跟代码库一样需要定期维护不然会变成技术债。