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 ├──>