workbuddy自定义指令配置指南：从零搭建高效AI协作体系

1. 从“它听不懂”到“它比我还靠谱”：自定义指令到底解决了什么问题

刚上手 workbuddy 这类智能协作工具的时候，我踩过最大的一个坑就是：默认配置下它确实能干活，但干出来的活总差那么点意思。你让它整理会议纪要，它给你按时间顺序罗列一遍，重点全埋在流水账里；你让它写周报，它把一周的琐碎操作全堆上去，领导看完根本抓不住核心产出。问题不在于工具不行，而在于我没告诉它“我要什么”。

自定义指令这个功能，本质上就是给 workbuddy 立一套属于你自己的“工作规矩”。它不像普通的提示词那样一次性的、用完就丢，而是持久化地写进配置里，每次调用都自动生效。你可以把它理解成给一个新来的助理写了一份《岗位操作手册》——什么该做、什么不该做、遇到什么情况用什么格式输出、语气该正式还是轻松，全部提前定好。之后你每次派活，它都按这套规矩来，不用反复交代。

我实测下来，配好一套自定义指令之后，同样的任务，输出质量的提升大概在 40% 到 60% 之间。这个数字怎么来的？我拿同一个会议纪要任务做了对照：默认配置下我需要花 15 分钟手动调整格式和提炼重点，配好指令后只需要 3 到 5 分钟做微调。省下来的时间就是实打实的效率。

这篇文章适合三类人看：第一类是刚接触 workbuddy、还在用默认配置硬扛的，第二类是已经会用但输出总不稳定、每次都要反复调教的，第三类是想把 workbuddy 接入团队流程、让多人共用一套标准的。不管你是哪种，下面的内容都能直接抄作业。

2. 自定义指令的底层逻辑：为什么它比每次手动写提示词强

2.1 持久化配置 vs 一次性提示词的本质区别

很多人觉得自定义指令不就是把提示词存起来嘛，有什么大不了的。这个理解只对了一半。持久化配置和一次性提示词之间，有三个本质区别。

第一个区别是上下文占用。每次手动写提示词，你都得在对话里占掉一大段 token，尤其是当你的要求比较细的时候，光交代规矩就花掉几百上千 token，真正留给任务本身的上下文就少了。自定义指令是独立于对话上下文的，它不占用你每次交互的 token 预算，但效果一样在。

第二个区别是一致性。手动写提示词，你今天心情好写得细一点，明天赶时间写得糙一点，输出质量就飘了。自定义指令是写死的，每次触发都一模一样，输出稳定性直接拉满。

第三个区别是可维护性。你发现某个规则不好用，改一处就行，所有调用自动生效。手动提示词你得每次改，改漏一次就出问题。

提示：自定义指令的优先级通常高于对话中的临时指令。也就是说，如果你在自定义指令里写了“输出必须用表格”，然后在对话里说“这次用列表就行”，最终大概率还是走表格。所以规则要留好弹性空间。

2.2 指令生效的优先级与冲突处理机制

workbuddy 处理指令冲突的逻辑，我实测下来大概是这么个顺序：系统内置规则 > 自定义指令 > 对话临时指令。但这个顺序不是绝对的，具体要看冲突的类型。

如果是格式类冲突，比如自定义指令要求用 Markdown 表格，对话里要求用纯文本，系统一般会听自定义指令的。如果是内容类冲突，比如自定义指令说“不要输出代码”，对话里说“给我一段 Python 示例”，这种时候系统会尝试折中——可能会输出代码但加个注释说明这是特例。

我踩过的一个坑是：在自定义指令里写了“所有输出必须包含总结段落”，结果有一次让它写一个纯代码文件，它硬生生在代码后面加了一段文字总结，导致代码没法直接用。后来我把规则改成“除非任务类型为纯代码生成，否则输出需包含总结段落”，问题就解决了。

所以写自定义指令的时候，一定要留例外条款。不要写死，要写“在什么情况下走什么规则”。

2.3 什么样的任务适合写进自定义指令

不是所有要求都值得写进自定义指令。我的判断标准是：这个要求是不是每次都会用到。如果是，写进去；如果只是偶尔用，留在对话里说就行。

适合写进自定义指令的：

• 输出格式偏好（比如所有列表用数字编号、所有对比用表格）
• 语气和风格（比如正式、简洁、不用感叹号）
• 通用质量要求（比如必须标注信息来源、必须给出至少两个方案）
• 常见任务的默认处理方式（比如会议纪要默认按“结论-待办-讨论”三段式输出）

不适合写进自定义指令的：

• 特定项目的专有名词和背景
• 一次性的特殊要求
• 需要频繁调整的参数

我自己的做法是：先跑一周，把每次都要重复交代的要求记下来，周末统一整理进自定义指令。这样迭代出来的指令最贴合实际使用习惯，不会一开始就写一大堆用不上的规则。

3. 手把手配置：从零搭一套能打的指令体系

3.1 配置入口与基础结构

workbuddy 的自定义指令配置入口一般在设置页面的“个性化”或“高级设置”里，不同版本可能位置不太一样，但关键词搜“指令”或“自定义”基本都能找到。找到之后你会看到一个文本编辑区，这就是你写规矩的地方。

基础结构我建议按这个框架来写：

# 角色定义 你是一个[具体角色]，服务于[具体场景]。 # 输出规范 1. 格式要求：... 2. 语气要求：... 3. 长度要求：... # 任务处理规则 - 当遇到[情况A]时，执行[操作X] - 当遇到[情况B]时，执行[操作Y] # 禁止事项 - 不要... - 避免...

这个结构的好处是层次清晰，workbuddy 解析起来不容易漏掉规则。我试过把所有规则堆成一段话，结果它只记住了前面几条，后面的全忽略了。分段落、加标题之后，规则遵守率明显提升。

3.2 角色定义怎么写才不空泛

角色定义是最容易被写废的部分。很多人写“你是一个专业的助理”，这种等于没写。什么叫专业？专业的方向是什么？助理的职责边界在哪里？全都没说。

我的写法是：角色 + 服务对象 + 核心目标。举个例子：

你是一个面向技术团队的项目协调助理，服务于一个 5 到 10 人的开发小组。你的核心目标是让信息传递不失真、让待办事项不遗漏、让每次输出都能直接转发给相关人员而不需要二次编辑。

这样写的好处是，workbuddy 知道自己在什么场景下工作、为谁工作、工作的质量标准是什么。它输出的时候就会自动往“可直接转发”这个标准靠，而不是随便给你一段需要大改的文字。

再举一个偏个人使用的例子：

你是一个个人效率助理，服务于一个同时处理多个项目的独立开发者。你的核心目标是减少我的决策负担，每次输出都要给出明确的建议而不是罗列选项。

这个角色定义直接影响了输出风格——它会倾向于给结论，而不是让你自己选。

3.3 输出规范：格式、语气、长度的三要素

输出规范是自定义指令里最直接影响阅读体验的部分。我把它拆成三个要素来写。

格式方面，我通常会指定：

• 标题层级怎么用（比如“一级标题用##，二级用###”）
• 列表什么时候用数字、什么时候用圆点
• 表格的适用场景（对比类信息必须用表格）
• 代码块的语言标注要求

语气方面，我的偏好是：

• 直接、不绕弯子
• 不用“可能”“也许”“建议考虑”这类模糊词
• 不用感叹号和表情符号
• 专业术语该用就用，但第一次出现时要加简短解释

长度方面，我一般会设一个弹性区间：

• 简单问题回答控制在 200 字以内
• 分析类任务不少于 500 字
• 除非明确要求，否则不写超过 2000 字的输出

这三个要素写清楚之后，输出的可预期性会大幅提升。你大概能猜到它会给你什么形态的东西，而不是每次开盲盒。

3.4 任务处理规则：用条件语句覆盖常见场景

任务处理规则是自定义指令里最“智能”的部分。它的写法就是 if-then 逻辑：如果遇到什么情况，就执行什么操作。

我常用的几条规则：

• 当用户输入包含“总结”时，默认按“核心结论-支撑要点-待办事项”三段式输出
• 当用户输入包含“对比”时，默认用表格呈现，对比维度不少于三个
• 当用户输入包含“方案”时，至少给出两个可选方案，并标注各自的适用场景
• 当用户输入包含“问题”时，先给排查步骤，再给解决方案，最后给预防建议

这些规则覆盖了我 80% 的日常使用场景。配好之后，我只需要说“帮我总结一下这个文档”，它自动就走三段式，不用我再交代格式。

注意：条件语句不要写太多，一般 5 到 8 条就够了。写太多会导致规则之间互相干扰，反而降低输出质量。我试过写 15 条，结果它经常搞混触发条件。

3.5 禁止事项：比“要做什么”更重要的是“不要做什么”

禁止事项这部分，很多人会忽略，但它其实特别重要。因为 workbuddy 的默认行为里有一些“坏习惯”，你不明确禁止，它就会一直犯。

我必写的几条禁止事项：

• 不要输出“根据您的要求”“以下是我为您生成的”这类前置说明
• 不要在结尾写“综上所述”“总之”这类总结套话
• 不要用“可能”“也许”“大概”这类不确定的词
• 不要在未经要求的情况下添加额外的建议或扩展阅读
• 不要重复我已经说过的内容

这几条写进去之后，输出的“水分”明显少了。以前它总喜欢在开头结尾加一堆客套话，现在直接给干货，阅读效率高了很多。

4. 实战调优：让指令越用越顺手的迭代方法

4.1 第一周：记录所有重复交代的要求

配好初始指令之后，不要急着优化。先正常用一周，但要做一件事：每次你在对话里额外交代了一个要求，就记下来。

比如你发现自己在对话里说了“这次用表格吧”“语气再正式一点”“不要写太长”，这些就是你的自定义指令还没覆盖到的点。记满一周之后，你会得到一份“遗漏清单”。

我第一周记了大概 20 多条，整理之后发现真正值得写进指令的只有 6 条。剩下的要么是一次性的，要么是已经有规则覆盖但触发条件没写对。

4.2 第二周：合并同类项，精简规则

第二周的任务是把遗漏清单里的要求合并同类项。比如“用表格”“用列表”“用分段”可以合并成一条“根据信息类型自动选择呈现方式：对比用表格、步骤用列表、叙述用分段”。

合并的原则是：一条规则能覆盖的场景越多越好，但触发条件要清晰。不要写“适当的时候用表格”这种模糊规则，要写“当信息包含两个以上对象的对比时，用表格”。

精简之后，我的指令从 20 多条压缩到了 10 条左右，但覆盖率反而提升了。因为每条规则都更精准了。

4.3 第三周：加入例外处理和边界条件

第三周开始处理例外情况。比如“所有输出必须包含总结段落”这条规则，遇到纯代码生成任务就不适用。那就改成“除纯代码生成任务外，所有输出需包含总结段落”。

例外处理写多了之后，你会发现指令变得越来越“聪明”。它不再是死板的规则，而是一套有弹性的决策逻辑。

我常用的例外处理写法：

• “除非……否则……”
• “在……情况下，优先执行……；其余情况执行……”
• “当……时，跳过……步骤”

4.4 长期维护：每月一次指令体检

自定义指令不是配好就一劳永逸的。你的工作内容会变，工具版本会更新，指令也需要定期体检。

我一般每个月花 15 分钟做一次指令体检，检查三件事：

1. 有没有规则从来没被触发过？如果有，要么删掉，要么检查触发条件是不是写错了
2. 有没有规则经常被违反？如果有，说明规则本身有问题，需要调整表述
3. 有没有新的重复性要求可以加进去？

这个习惯坚持了三个月之后，我的自定义指令基本稳定在 12 条左右，输出质量也稳定在一个比较高的水平。

5. 常见问题与排查技巧实录

5.1 指令不生效的几种典型情况

情况一：规则写得太模糊。比如“输出要简洁”，什么叫简洁？workbuddy 不知道。改成“输出控制在 300 字以内，不写背景介绍和总结段落”，效果立竿见影。

情况二：规则之间互相冲突。比如一条规则说“所有输出用表格”，另一条说“叙述性内容用段落”，那遇到叙述性内容时它就不知道该听谁的。解决办法是给规则排优先级，或者把冲突的规则合并成一条带条件的规则。

情况三：指令太长，超出处理上限。不同版本的上限不一样，但一般来说，自定义指令控制在 2000 字以内比较稳妥。超过之后，后面的规则可能会被截断或忽略。

情况四：缓存没刷新。改完指令之后，有时候需要新开一个对话才会生效。如果你在旧对话里测试，可能还是走的老规则。

5.2 输出质量不稳定的排查思路

输出质量忽好忽坏，一般不是指令本身的问题，而是触发条件没写清楚。我的排查步骤是这样的：

第一步，看这次的任务类型是不是在指令覆盖范围内。如果任务本身就不在规则覆盖的场景里，输出不稳定是正常的。

第二步，看对话里有没有临时指令和自定义指令冲突。如果有，以自定义指令为准，但冲突本身会导致输出摇摆。

第三步，看指令里有没有“软规则”。比如“尽量”“适当”“酌情”这类词，会让 workbuddy 每次的理解都不一样。把软规则改成硬规则，稳定性就上来了。

5.3 多人共用一套指令的注意事项

如果是团队共用，有几个额外的坑要注意。

第一，角色定义要写清楚服务对象是“团队”而不是“个人”。否则输出会偏向个人使用场景，不适合团队转发。

第二，禁止事项要加一条“不要假设读者的背景知识”。团队里每个人的专业背景不一样，输出要保证所有人都能看懂。

第三，格式规范要统一。比如表格的列数、标题的层级、代码块的语言标注，这些都要写死，不然每个人拿到的输出格式都不一样，汇总的时候很麻烦。

第四，留一个“团队自定义”的扩展区。不同项目组可能有自己的特殊要求，在通用指令下面留一段空间让他们自己加规则，但不要动通用部分。

5.4 常见问题速查表

6. 进阶玩法：把自定义指令用出花来

6.1 场景化指令模板：一套指令适配多种任务

如果你同时处理多种类型的任务，可以写一套“场景化指令”，让 workbuddy 根据任务类型自动切换模式。

我的做法是在指令里加一段“模式识别”规则：

当任务涉及会议记录时，进入“纪要模式”：按结论-待办-讨论三段式输出，待办事项必须标注负责人和截止时间。 当任务涉及方案设计时，进入“方案模式”：至少给出两个方案，每个方案包含适用场景、优缺点、实施步骤。 当任务涉及问题排查时，进入“排查模式”：先列可能原因，再给排查步骤，最后给解决方案和预防建议。

这样一套指令就能覆盖我大部分的工作场景，不用每次手动切换。

6.2 指令链：让多个指令协同工作

workbuddy 支持在对话中引用之前的输出，这就可以玩“指令链”。比如：

第一步，用“总结模式”把长文档压缩成核心要点。 第二步，用“方案模式”基于要点生成行动方案。 第三步，用“检查模式”对方案做风险排查。

每一步的输出自动成为下一步的输入，整个流程不需要手动复制粘贴。我实测下来，处理一份 20 页的文档，从总结到方案到检查，全程大概 5 分钟，以前手动做至少要半小时。

6.3 用变量让指令更灵活

部分版本的 workbuddy 支持在自定义指令里使用变量，比如{{当前日期}}、{{项目名称}}。这个功能用好了能省很多事。

比如我写了一条规则：“所有输出的页脚标注{{当前日期}}和{{项目名称}}”。这样每次输出自动带上日期和项目名，归档的时候特别方便，不用手动加。

变量的具体支持情况要看版本，你可以在配置页面找找有没有变量说明，或者试试常见的变量名看能不能识别。

7. 我踩过的坑和最后分享的几个技巧

第一个坑是一开始写太多规则。我第一版自定义指令写了 30 多条，结果 workbuddy 经常搞混，输出反而比默认配置还差。后来砍到 10 条左右，质量才上来。所以我的建议是：从 5 条核心规则开始，慢慢加，不要一次写满。

第二个坑是规则写得太抽象。“输出要专业”这种规则等于没写。什么叫专业？是术语多？是格式规范？是逻辑严密？后来我改成“输出必须包含数据支撑，每个结论后面标注依据来源”，效果就具体了。

第三个坑是忘了留例外。“所有输出必须包含总结”这条规则让我在生成纯代码时吃了亏。后来加了“纯代码生成任务除外”，才解决。

最后分享几个小技巧：

• 指令写完之后，用三个不同类型的任务测试一遍，看输出是否符合预期。如果有一个不符合，就调整对应的规则。
• 把自定义指令备份一份到本地。换设备或者重置配置的时候，直接粘贴回去就行，不用重新写。
• 如果 workbuddy 支持导入导出配置，定期导出一次，当作版本快照。改坏了可以回滚。
• 团队共用的时候，指定一个人负责维护指令，其他人提需求。不然每个人都改，规则会乱。

这套自定义指令我用了大半年，现在 workbuddy 的输出基本能做到“开箱即用”，不需要二次编辑的比例大概在 70% 左右。剩下的 30% 主要是任务本身太特殊，或者我临时改了要求。但比起最开始每次都要手动调格式、补重点、删废话，现在的体验好了太多。如果你也在用 workbuddy，强烈建议花一个小时把自定义指令配起来，后面省下来的时间绝对不止一个小时。