WorkBuddy自定义指令实战：从玩具到工具的规矩与技巧

1. 为什么我要给 workbuddy 立规矩

workbuddy 这个工具，我用了大概小半年。最开始接触它的时候，我跟大多数人一样，就是把它当成一个“能聊天的搜索框”——问一句答一句，答得好算赚到，答得不好就换个问法再试。但用得越久越发现一个问题：同一个任务，今天让它干和明天让它干，出来的结果可能完全不一样。有时候它像个靠谱的老同事，有时候又像个刚入职的实习生，连最基本的格式都能给你搞错。

这种“薛定谔的靠谱”状态，在个人玩玩的时候还能忍，但一旦把它接入到实际工作流里，比如批量处理文档、自动生成周报、整理会议纪要，问题就大了。你不可能每次都在旁边盯着它，告诉它“这里要加粗”“那里要分点”“数据必须保留两位小数”。真正让 workbuddy 从“玩具”变成“工具”的转折点，就是自定义指令。

说白了，自定义指令就是给 workbuddy 立一套规矩。你提前把“我是谁”“我在什么场景下干活”“我期望的输出长什么样”“哪些事绝对不能干”这些信息一次性写清楚，之后每次对话它都会自动带上这套规矩。这就好比你给一个新来的助理写了一份详细的岗位说明书，他不用每次都被你耳提面命，自己就知道该怎么做事。

我现在的 workbuddy 工作台里，常驻着七八套自定义指令，分别对应不同的工作场景。写技术文档有一套，做数据分析有一套，整理会议纪要有一套，甚至回复客户邮件也有一套。自从把这套规矩立起来之后，我让 workbuddy 干活的质量稳定性至少提升了两个档次，很多时候它输出的初稿，我只需要微调几个词就能直接用。

这篇文章，我就把自己折腾自定义指令的完整经验拆开来讲。从底层逻辑到具体写法，从参数配置到踩坑记录，尽量说透。不管你是刚下载 workbuddy 还在摸索的新手，还是已经用了一段时间但总觉得“差点意思”的老用户，应该都能从里面找到能直接抄作业的东西。

2. 自定义指令到底在改什么

2.1 从“每次都说”到“说一次就够”

要理解自定义指令的价值，得先搞清楚 workbuddy 这类工具默认是怎么工作的。默认状态下，你每发起一次对话，系统都会把你的输入和一段通用的系统提示词拼在一起送给模型。这段通用提示词通常是“你是一个有用的AI助手，请根据用户的问题给出准确、有帮助的回答”之类的套话。它不包含任何关于你个人偏好、工作场景、输出格式的信息。

所以如果你想要特定格式的输出，就必须在每次提问时手动加上一堆限定条件。比如“请用 Markdown 格式输出，分三个部分，每部分用二级标题，数据保留两位小数，不要用‘综上所述’这种词”。一次两次还行，天天这么干，光是复制粘贴这些限定词就够烦的。

自定义指令做的事情，本质上就是把这段“每次都要重复的限定词”固化下来，存到你的账户配置里。之后每次对话，系统会自动把你写的这段指令拼接到系统提示词的位置，或者作为对话的“前置上下文”注入。对模型来说，它看到的就不再是干巴巴的通用提示，而是一份带着你个人印记的“工作手册”。

这里有个细节值得注意：不同平台对自定义指令的注入位置处理不一样。有的放在 system prompt 里，有的作为第一条 user message 注入。前者对模型行为的影响更“硬”，后者相对软一些。workbuddy 目前的做法更接近前者，所以指令的约束力比较强。

2.2 指令的四个核心模块

我折腾了这么久，总结下来一套好用的自定义指令基本包含四个模块。这四个模块不一定非要按顺序写，但缺了哪个，效果都会打折扣。

第一个模块是身份设定。你要告诉 workbuddy“你是谁”。比如“你是一位有十年经验的 Python 后端工程师”“你是一位专注于消费品牌的营销文案策划”“你是一位严谨的学术论文编辑”。身份设定决定了模型调用哪部分知识储备，以及用什么样的语气说话。你让它当工程师，它就会更注重逻辑和边界条件；你让它当文案，它就会更注重节奏和感染力。

第二个模块是场景描述。你要说清楚“在什么情况下干活”。比如“用户会给你一段原始数据，要求你生成分析报告”“用户会粘贴一篇英文文章，要求你翻译成中文并保留专业术语”“用户会描述一个 bug 现象，要求你给出排查步骤”。场景描述越具体，模型对任务的理解就越准确，跑偏的概率就越低。

第三个模块是输出规范。这是最直接影响最终结果的部分。包括格式要求（Markdown、JSON、纯文本）、结构要求（分几部分、每部分标题怎么写）、长度要求（多少字以内、多少字以上）、风格要求（正式、口语、简洁、详细）。我见过很多人写自定义指令只写身份和场景，不写输出规范，结果就是内容对了但格式乱七八糟，还得手动调。

第四个模块是禁止事项。这个模块最容易被忽略，但往往最能提升质量。你要明确告诉 workbuddy“哪些事不能干”。比如“不要使用‘综上所述’‘通过本文’这类套话”“不要编造数据，没有数据就说没有”“不要输出与问题无关的背景介绍”“不要用 emoji”。把你不喜欢的东西提前禁掉，比事后修改省事得多。

2.3 为什么“规矩”比“技巧”更重要

网上有很多关于 prompt 技巧的文章，教你什么“角色扮演法”“思维链法”“少样本示例法”。这些技巧当然有用，但它们解决的是“单次对话怎么问得更好”的问题。自定义指令解决的是“长期协作怎么更稳定”的问题。

打个比方，prompt 技巧像是你跟一个临时工交代任务时用的沟通方法，而自定义指令像是你给正式员工写的岗位手册。临时工你每次都得从头交代，正式员工看一眼手册就知道该怎么干。对于高频重复的任务，岗位手册的价值远大于单次沟通技巧。

而且自定义指令还有一个隐藏好处：它强迫你把模糊的需求想清楚。很多时候我们觉得 workbuddy 不好用，其实是因为我们自己都没想清楚到底要什么。写自定义指令的过程，就是一次需求梳理的过程。你得明确身份、场景、输出、禁忌，这四个模块写下来，你对任务的理解也会清晰很多。

3. 手把手写一套能用的自定义指令

3.1 从模板开始，别从空白页开始

workbuddy 的自定义指令入口一般在设置里，找到“自定义指令”或“个性化”相关的选项就能看到。点进去之后，你会看到一个输入框，可以写最多几千个字符的指令内容。我的建议是，不要对着空白页硬想，先找一个模板套着写。

下面这个模板是我自己用的，你可以直接复制过去改：

# 身份 你是一位[具体职位]，拥有[多少年]经验，擅长[具体技能领域]。 # 工作场景 用户会给你[描述输入内容]，你需要[描述任务目标]。 # 输出要求 1. 格式：[Markdown/JSON/纯文本] 2. 结构：[分几个部分，每部分标题怎么写] 3. 长度：[字数范围] 4. 风格：[正式/口语/简洁/详细] 5. 数据：[保留几位小数/是否标注来源] # 禁止事项 1. 不要使用[具体套话列表] 2. 不要[具体禁止行为] 3. 不要[具体禁止行为]

这个模板看起来简单，但每个空都填好之后，指令的约束力就已经很强了。我拿一个实际例子来演示。假设我要让 workbuddy 帮我处理技术文档的翻译和润色，我会这么写：

# 身份 你是一位资深技术文档工程师，拥有八年以上中英技术文档互译经验，熟悉软件开发、云计算、数据库等领域的专业术语。 # 工作场景 用户会给你一段英文技术文档或中文技术草稿，你需要将其翻译或润色为符合中文技术写作规范的最终稿。 # 输出要求 1. 格式：Markdown 2. 结构：保留原文的标题层级，代码块保持原样，表格保持原样 3. 长度：与原文相当，不随意增删内容 4. 风格：简洁、准确、客观，避免口语化表达 5. 术语：专业术语首次出现时用“中文（English）”格式标注 # 禁止事项 1. 不要使用“通过本文”“综上所述”“值得注意的是”等套话 2. 不要改变原文的技术含义 3. 不要添加原文没有的解释性内容 4. 不要使用 emoji

这套指令写完之后，我每次只要把英文文档粘贴进去，workbuddy 就会自动按照技术文档工程师的标准来处理。输出的结果直接可以用在内部 wiki 上，省掉了我大量手动调整格式和术语的时间。

3.2 身份设定的颗粒度怎么把握

身份设定是自定义指令里最微妙的部分。写得太宽泛，比如“你是一个助手”，等于没写；写得太窄，比如“你是一个专门处理 2019 年之后发布的 MySQL 8.0 版本中 JSON 字段查询优化的助手”，又可能限制模型在其他相关任务上的发挥。

我的经验是，身份设定的颗粒度控制在“职业+领域+经验水平”这个层级比较合适。比如“资深后端工程师，专注于高并发系统设计”就比“程序员”好，比“专门处理每秒十万级请求的 Go 语言微服务架构师”更通用。

另外，身份设定里加一句“经验水平”的描述，对输出质量有微妙但明显的影响。你写“拥有十年经验”和“拥有三年经验”，模型给出的回答在深度和自信程度上会有差异。这不是玄学，而是因为训练数据里“十年经验”这个描述通常关联着更深入、更果断的表达方式。

还有一个技巧是在身份里埋入“工作原则”。比如“你是一位注重代码可读性的工程师，宁可多写一行注释也不写晦涩的一行代码”。这种原则性的描述会渗透到模型的输出风格里，让结果更符合你的价值观。

3.3 输出规范要写到什么程度

输出规范这部分，很多人写得太粗。比如只写“用 Markdown 格式”，结果模型给你输出一堆乱七八糟的标题层级。你得写到“二级标题用 ##，三级标题用 ###，代码块必须标注语言类型”这个程度。

我一般会把输出规范拆成五个维度来写：

维度	要写清楚的内容	示例
格式	用什么标记语言	Markdown，代码块标注语言
结构	分几部分，层级怎么定	三个二级标题，每个下面不超过四个三级标题
长度	字数或段落数范围	正文 800-1200 字，每段不超过 5 行
风格	语气和用词偏好	简洁直接，避免形容词堆砌
数据	数字和引用的处理方式	百分比保留一位小数，引用标注来源

这五个维度写清楚，模型输出的东西基本就不需要你再调格式了。我实测下来，输出规范写得越细，后期手动修改的时间就越少。前期多花十分钟写规范，后期能省下几十次的复制粘贴调整。

3.4 禁止事项才是真正的护城河

如果说身份和场景决定了 workbuddy 能做什么，那禁止事项就决定了它不会做什么。而“不会做什么”往往比“会做什么”更能体现一套指令的成熟度。

我自己的禁止事项列表里，常年躺着这么几条：

• 不要使用“通过本文”“综上所述”“随着技术的发展”“为……提供了有力支持”这类模板化表达
• 不要在回答开头重复我的问题
• 不要在没有数据支撑的情况下使用“显著提升”“大幅改善”这类程度副词
• 不要输出与任务无关的背景介绍和客套话
• 不要用 emoji
• 不要编造参考文献或数据来源

这几条禁下来之后，workbuddy 的输出明显“干净”了很多。以前它总喜欢在开头来一句“您提出的这个问题非常好”，现在直接进入正题。以前它喜欢在结尾加一段“总之，通过以上分析我们可以看出”，现在说完最后一点就停。

禁止事项的写法有个小技巧：用“不要”开头，后面跟具体的行为描述，而不是抽象的品质描述。写“不要使用套话”不如写“不要使用‘综上所述’‘通过本文’‘值得注意的是’这三个短语”。越具体，执行效果越好。

4. 不同场景下的指令实战配置

4.1 技术文档场景：准确优先于流畅

技术文档是我用得最多的场景。这个场景的核心诉求是准确，其次才是流畅。一个术语翻译错了，可能导致整个理解偏差；一个步骤顺序写反了，可能让人卡半天。

我的技术文档指令里，除了前面提到的身份和输出规范，还加了几条特殊规则：

# 特殊规则 1. 遇到不确定的专业术语，保留英文原文并在括号内给出中文翻译 2. 代码示例必须包含必要的注释，注释用中文 3. 操作步骤必须编号，每步只做一件事 4. 如果原文有歧义，在输出末尾用“译者注”标注

这几条规则解决了我长期以来的几个痛点。以前 workbuddy 翻译技术文档时，总喜欢把一些约定俗成的英文术语硬翻成中文，比如把 “token” 翻成“令牌”，把 “cache” 翻成“高速缓存”，读起来特别别扭。现在它会在首次出现时写成“令牌（token）”，后面直接用英文，阅读体验好很多。

还有操作步骤，以前它喜欢把好几个动作塞在一句话里，比如“打开设置面板并找到高级选项然后点击确认”。现在强制每步只做一件事，步骤清晰多了。

4.2 数据分析场景：格式和精度是生命线

数据分析场景对格式和精度的要求比技术文档还高。一个数字格式不对，整张表就废了；一个小数点位置错了，结论就反了。

我的数据分析指令里，输出规范部分写得特别细：

# 输出要求 1. 所有百分比保留一位小数，如 23.5% 2. 所有金额保留两位小数，并标注货币单位 3. 数据表格必须包含表头，表头加粗 4. 如果数据量超过 20 行，只展示前 10 行和后 10 行，中间用“...”省略 5. 所有计算过程必须展示，不能只给结果

“所有计算过程必须展示”这一条特别重要。以前 workbuddy 做数据分析，经常直接给一个结果数字，我根本不知道它是怎么算出来的。现在它会写出“总销售额 = 单价 × 数量 = 23.5 × 1200 = 28200.00 元”这样的过程，我一眼就能看出有没有算错。

另外我还加了一条禁止事项：“不要对数据进行四舍五入以外的任何修饰性处理”。因为有一次它把一组明显异常的数据自动“平滑”掉了，导致我差点做出错误判断。数据就是数据，异常值也要如实呈现，这是分析的基本伦理。

4.3 会议纪要场景：结构化和行动项是核心

会议纪要这个场景，我踩过的坑最多。最开始让 workbuddy 整理会议录音转文字，它给我输出一大段流水账，谁说了什么全混在一起，根本没法用。

后来我重新设计了指令，核心思路是强制结构化：

# 输出要求 1. 必须包含三个部分：会议基本信息、讨论要点、行动项 2. 讨论要点按主题分组，每个主题用三级标题 3. 行动项必须包含：负责人、截止时间、具体任务 4. 如果原文没有明确负责人或时间，标注“待确认” 5. 不要逐字复述发言，提炼核心观点即可

这套指令跑了几次之后，我基本可以做到“录音转文字丢进去，五分钟出纪要初稿”。行动项那部分特别有用，它会自动把“这个事小王你跟进一下”识别成“负责人：小王，任务：跟进该事项，截止时间：待确认”。虽然时间经常需要手动补，但至少负责人和任务不会漏。

会议纪要场景有个隐藏技巧：在指令里加一句“如果同一件事被多人提及，合并为一条并标注所有提及人”。这样能避免同一个议题在纪要里出现三四次，让文档更紧凑。

4.4 邮件回复场景：语气和长度要可控

邮件回复是我最近才加的场景。起因是我发现自己每天要花大量时间回复各种常规邮件，内容大同小异，但语气和长度需要根据收件人调整。

我的邮件指令里，身份设定是“一位注重效率的职场沟通专家”，输出规范里重点控制语气和长度：

# 输出要求 1. 默认语气：专业、友好、简洁 2. 如果收件人是上级或客户，语气更正式，开头加称呼，结尾加敬语 3. 如果收件人是平级同事，语气可以稍轻松，省略客套话 4. 正文控制在 150 字以内，超过则分点 5. 不要使用“您好，见信好”这类过于传统的开头

“不要使用过于传统的开头”这条是我特意加的。以前 workbuddy 写邮件总喜欢用“您好，见信好”开头，读起来像上个世纪的商务信函。现在它直接用“Hi [名字]”或者“关于 [事项]，我的回复如下”，干净利落。

长度控制也很关键。150 字以内的限制逼着模型把废话砍掉，只留核心信息。我实测下来，限制长度比要求“简洁”更有效，因为“简洁”是主观的，而“150 字”是客观的。

5. 那些年我踩过的坑和排查方法

5.1 指令冲突：当两条规则打架时

自定义指令写多了，难免会出现规则冲突。比如我在输出规范里写了“正文控制在 800 字以内”，又在禁止事项里写了“不要省略任何关键细节”。这两条在某些任务上就会打架：要保留所有细节，800 字根本装不下。

遇到这种情况，workbuddy 的表现通常是随机偏向某一条，有时候超字数，有时候丢细节。我的解决办法是给规则加优先级。在指令开头加一句“当输出要求与禁止事项冲突时，优先满足输出要求”，或者在具体规则后面标注“（此条优先）”。

还有一种冲突是身份冲突。比如我同时写了“你是一位严谨的学术编辑”和“你是一位创意文案策划”，模型就不知道该用哪种语气。这种冲突只能靠拆分指令来解决——不同场景用不同的指令集，不要试图用一套指令覆盖所有场景。

5.2 指令失效：为什么它又不听话了

有时候明明指令写得好好的，用了一段时间之后突然不灵了。我遇到过几次，排查下来主要有三个原因。

第一个原因是指令太长，超出了模型的上下文窗口。自定义指令是每次对话都要注入的，如果指令本身有三千字，再加上对话历史，很容易把上下文塞满。模型在上下文快满的时候，会优先保留最近的对话内容，把前面的系统指令“挤”出去。解决办法是精简指令，把不常用的规则删掉，或者拆成多个指令集按需切换。

第二个原因是平台更新了底层模型。模型换代之后，对同一段指令的理解方式可能发生变化。我遇到过某次更新后，之前写得好好的“不要使用套话”突然失效了，模型又开始输出“综上所述”。后来我把禁止事项改成了更具体的短语列表，才恢复效果。

第三个原因是对话轮次太多。在一个超长对话里，早期的指令影响力会逐渐衰减。这时候需要开新对话，或者手动在对话中重申关键规则。

5.3 常见问题速查表

下面这张表是我自己整理的排查清单，遇到问题的时候按顺序过一遍，基本能定位到原因：

现象	可能原因	排查方法	解决措施
输出格式不对	输出规范写得太粗	检查是否明确了格式、结构、长度	细化输出规范，写到具体标记符号
语气不对	身份设定太宽泛	检查身份描述是否包含领域和经验	补充“专注于XX领域”“拥有XX经验”
套话又出现了	禁止事项不够具体	检查禁止列表是否只有抽象描述	改成具体短语列表
指令时灵时不灵	指令太长或对话太长	检查指令字数和对话轮次	精简指令或开新对话
内容跑偏	场景描述不清晰	检查是否说明了输入类型和任务目标	补充“用户会给你XX，你需要XX”
数据格式错乱	缺少数据规范	检查是否有小数位、单位等要求	添加数据格式的具体规则

这张表我放在 workbuddy 的备忘录里，每次调整指令之后如果效果不对，就对着过一遍，通常五分钟内能找到问题。

5.4 一个真实的翻车案例

说一个我印象最深的翻车案例。有一次我让 workbuddy 帮我整理一份竞品分析报告，指令里写了“输出 Markdown 格式，包含表格”。结果它输出的表格里，有一列数据全部错位了，把 A 产品的价格填到了 B 产品那一行。

我排查了半天，最后发现原因是：我在指令里写了“表格列数不超过 5 列”，但实际数据有 7 个维度。模型为了满足“不超过 5 列”的规则，强行把两列数据合并了，导致错位。

这个案例给我的教训是：规则要留有余地，不能把模型逼到“为了满足规则而扭曲数据”的地步。后来我把那条规则改成了“表格列数根据数据维度决定，不设上限”，问题就解决了。

写自定义指令的时候，一定要站在模型的角度想一遍：如果我是模型，看到这条规则，会不会为了满足它而做出违背任务目标的事？如果会，这条规则就需要加一个“除非”或者“优先保证数据准确性”的补充说明。

6. 让指令越用越顺手的几个习惯

6.1 建一个指令版本库

我现在的做法是，每套自定义指令都在本地存一个 Markdown 文件，用 Git 管理。每次调整都提交一次，写清楚改了什么、为什么改。这样万一改坏了，可以随时回滚到之前的版本。

版本库的目录结构大概是这样的：

workbuddy-instructions/ ├── tech-doc.md ├──>