我前后折腾 WorkBuddy 三个多星期把社区里流传的、官方文档里写的、还有自己一点点试出来的指令全部过了一遍差不多攒下来两百多条。真正留下来天天用的只有 30 条。这个数字不是拍脑袋定的是我把“看起来有用”和“实际有用”区分开之后剩下的全部家底。先解释一下我为什么要浪费时间干这件事。WorkBuddy 这类工具的核心价值其实不在模型本身而在于你怎么指挥它。模型像一个能力很强但不太主动的新人指令就是你交给他的工作手册。手册写得好他能顶一个半熟手手册写得烂他连打印文件都能给你打歪。我在前期测试阶段踩过太多坑比如指令太笼统导致输出千篇一律又比如指令太死板导致换一个场景直接失灵所以才动了彻底整理一遍的心思。这篇文章会把我筛选指令的完整思路、最终留下的 30 条指令全览、其中最难调教好的几类指令的实操细节以及我在落地过程中遇到的典型问题和排查方法全部摊开讲。如果你也在用 WorkBuddy或者准备开始用这篇能帮你少走至少一个星期的弯路。1. 为什么要整理指令集——先把 WorkBuddy 的运行逻辑说清楚1.1 WorkBuddy 的指令到底是什么先说个基本概念。WorkBuddy 里的指令本质上就是一段结构化的提示词但它比普通提示词多了一层“可复用”的属性。普通提示词是你今天问一句、明天问一句每次都要重新组织语言指令则是把一种高频场景下的完整要求固化成一段文本之后每次调用只需要一个简短触发词WorkBuddy 就会按指令里写好的规则去执行。举个例子。你直接说“帮我把这篇产品介绍改得正式一点”模型会按它自己的理解随便改一版。但如果你事先写好一条指令叫“商务润色”里面规定了语气、用词倾向、段落结构、禁止出现的表达方式那么下次你说“用商务润色处理这篇产品介绍”输出质量就会稳定得多。我整理指令集的核心逻辑就是这个把不可控的对话变成可控的标准化操作。WorkBuddy 和 CodeBuddy 这类工具通常会把指令分成几种类型比如全局规则、任务型指令、记忆型指令。全局规则是常驻的对所有对话生效任务型指令是接到具体任务时才触发记忆型指令则负责跨对话保存关键信息。我最后留下的 30 条里三种类型都有但比例上任务型指令最多因为这种指令最容易产生立竿见影的效果。1.2 我整理指令集时的筛选标准整理之前我先定了几条硬标准防止自己什么都想留。第一条必须能解决具体问题而不是描述一种愿望。有些指令写得很漂亮比如“提升回答质量”“增强逻辑性”但实际操作时你会发现这种指令什么都没约束住模型该怎么说还是怎么说。真正有用的指令一定包含了明确的动作比如“先列出大纲再展开”“每段不超过 100 字且首句必须是结论”。第二条必须有稳定的输出格式或行为变化。我会对每条候选指令做三到五轮测试每次换不同的输入内容。如果输出质量时好时坏那这条指令的表述一定有问题要么太模糊要么约束条件互相矛盾这种直接淘汰。第三条不能依赖特定版本的潜在能力。有些指令我用着效果很好但换一个模型版本后就明显变差这种我也不要。我要的是在不同版本之间表现都比较稳的指令而不是碰运气式的玄学调参。第四条必须具备不可替代性。如果一条指令的效果和我直接对话时随手说一句差不多那它没有资格占据指令位。真正值得做成指令的必须是我每次都要手打一大段要求、且频率足够高的场景。最后筛下来30 条每一名都有留下来的理由。2. 30 条指令全览与分类逻辑2.1 按用途划分的五大类我把留下的 30 条指令分成五个大类这个分类方式比较贴近实际使用场景你可以直接拿来当参考框架。分类指令数量核心作用典型触发场景写作输出类7 条控制文章结构、语气、风格和篇幅写周报、写产品文案、写邮件、写方案研究整理类6 条信息检索、归纳、去重和结构化输出查资料、读文献、整理会议纪要工作流自动化类8 条批量处理、任务拆解、模板生成生成批量数据、格式化文档、制作清单代码工程类5 条代码编写规范、调试辅助、日志分析写脚本、修 bug、看日志、做测试跨对话与记忆类4 条保持角色设定、记住偏好、长期规则新开会话、切换任务、团队协作这个比例不是我预先设计的完全是筛完之后自然形成的。写作输出类和工作流自动化类占了大头说明 WorkBuddy 在文本生成和标准化事务处理上最能发挥价值而代码工程类的占比不高原因是这类场景对准确性要求极高我倾向于用更专精的工具去处理WorkBuddy 只承担辅助角色。2.2 那些看起来很唬人、实际被淘汰的指令说完了留下的再聊聊被我淘汰的这样你能更清楚我的筛选尺度。淘汰最惨的一类是“万能型指令”。比如我试过一条号称“全面提升输出质量”的指令里面写了十几个要求从逻辑清晰到语言优美到数据准确应有尽有。实测下来效果确实有一点但非常不稳定。原因也好理解约束条件太多互相之间容易打架模型执行时反而不知道重点是什么只能在各个要求之间和稀泥。第二类淘汰的是“场景绑定过死”的指令。我有一段时间想让 WorkBuddy 帮我写一种固定风格的产品测评指令里指定了非常具体的口头禅和句式。刚开始用很爽但换一批产品再测内容就变得极其机械读起来像机器人复读。后来我把这类指令拆成了两层一层管语气偏好一层管内容结构分开控制之后灵活多了。第三类是“伪技术型”指令。有些指令写满了术语什么 CoT、few-shot、temperature 调整之类看起来专业但在 WorkBuddy 这种封装好的工具里很多底层参数根本接触不到写了也是白写。这种指令效果不稳定还会干扰正常输出直接删。我特别想强调一点指令不是越多越好。指令集臃肿带来的最大问题不是占用多少存储空间而是每次触发时模型要处理的上下文变长了反而可能干扰回答质量。30 条对我来说是经过取舍后的平衡点。3. 核心指令详解与实操示例——挑几条最有代表性的拆开讲3.1 写作输出类让输出从“能看”变成“能用”写作输出类指令是大多数人最先需要的也是我投入测试时间最多的类别。这里先展示一条我觉得通用性最强的指令命名为“结论先行”。这条指令的核心要求只有几句话回答任何问题时第一句话直接给出结论第二段开始再补充原因、过程或论据禁止以背景介绍或铺垫开头。写这条指令之前我受够了模型输出时先扯一段背景、再绕来绕去、最后才给出真正答案的毛病。在信息类场景下这种表达方式的效率极低。实测下来这条指令的效果非常稳定。不管问的是“这份报告的核心问题是什么”还是“比较一下 A 方案和 B 方案”输出都会先给一个明确的判断后面再展开分析。它几乎成了我所有基础指令的底座其他写作类指令很多都建立在它的基础上。再展示一条更具体的叫“三段式邮件”。触发场景是写任何商务邮件或工作沟通消息。指令内容是全文控制在三到四个短段落内第一段说明事由和背景第二段写清楚需要对方做什么或确认什么第三段补充时间节点和备选方案最后用一句话收尾并留下联系方式。整个过程中禁止使用“衷心感谢”“打扰了”这类空泛客套语。这条指令太实用了。我以前写一封邮件要来回改好几遍不是语气不对就是漏了关键信息。设定这条指令后WorkBuddy 生成的邮件基本就是标准答案我只需要改几个细节就能直接发出去。写作输出类的调优经验是约束条件要尽量可验证。比如“不要写超过50字的句子”模型能否遵守容易被检查而“语言要生动”模型无法明确衡量执行时就会各显神通。所以我在筛选指令时会刻意把那些不可验证的形容词要求删掉换成可检查的定量或结构化约束。3.2 研究整理类信息处理的效率倍增器研究整理类指令的价值在于把“帮我查一下 XX”这种模糊指令变成一套标准化的信息处理流程。这类指令里我最推荐的是“三维总结法”。这条指令的运行逻辑是针对用户提供的任何文章、报告或对话记录按三个维度分别输出总结——核心论点是什么、关键数据或事实有哪些、对用户而言可执行的行动项是什么。核心论点部分限制不超过 200 字关键事实列出不超过 5 条行动项明确到具体步骤。我用它来处理日常收集到的各种长文和资料。以前看一篇一万字的行业分析至少花二十分钟看完还不一定能记住多少。现在直接把全文丢给 WorkBuddy用这个指令生成总结五分钟内就能掌握核心内容然后决定要不要深读原文。另一条常用的叫“会议纪要格式化”。触发词是“纪要”。指令规定输出必须包含四个部分讨论了什么、决定了什么、谁负责做什么、下一步的时间节点是什么。禁止把发言原话逐字记录必须转换成决策和行动导向的语言。值得说明的是研究整理类指令的难点不在“整理”本身而在“判断哪些信息值得保留”。我的解决办法是给指令加上用户视角的倾向性要求指定归纳时的侧重点。比如“纪要”这条指令里我明确写了本团队关注的是决策结果和责任分配过程性讨论只要保留影响结论的部分即可。有了这个约束输出的摘要精准度提升非常明显。这类指令还有一个隐藏好处长期使用后WorkBuddy 在接收新任务时会自动模仿这种总结风格即使你不明确触发指令它给出的回答也会更有结构感。这算是规则渗透带来的正外部性。3.3 工作流自动化类批量场景下的效率放大器工作流自动化类指令适合那些结构性很强、每次操作模式几乎相同的任务。这类指令我留了 8 条是所有分类里数量最多的因为它们最能节省时间。最典型的一条叫“批量为王”。它的触发场景是我需要 WorkBuddy 同时处理多个同类型对象例如给一批案例写摘要、把多段散乱数据整理成统一格式、为多个产品各生成一句卖点描述。指令要求是先确认共有几个对象然后逐个处理每个对象输出单独成段段首标注对象名称全部处理完后给出一个总览表。这条指令解决了两个实际问题。一是防止模型漏项——以前让它批量处理时经常做着做着就丢了几个对象二是方便我核对——输出按对象分段后谁缺了、谁格式不对一目了然。我还在这条指令的结尾加了一句兜底要求如果某个对象因信息不足无法处理必须明确标注“无法处理”并列明缺什么绝不允许编造内容填补。另一条是“模板工程师”专门用来生成可重复使用的模板文件。这套指令的逻辑比较特别当你说“做一个 XX 模板”时WorkBuddy 不是直接给你一份模板而是先问你三个问题——使用场景是什么、使用者是谁、需要包含哪些必填项然后基于回答生成第一版模板最后附上一段使用说明。为什么要先反问而不是直接生成因为模板类任务最关键的是了解使用场景一旦搞错方向生成的模板再精美也没用。实测中我发现加了反问环节后模板的修改次数大大减少。这条指令的背后是“对话式需求澄清”的思路很值得复制到其他指令设计中。自动化类指令要特别注意边界控制。你要在指令里明确告诉模型“什么不该做”比如不要自动添加案例、不要补充未提供的参数、不要额外生成解释。模型天生有过度发挥的倾向你不设置边界它就会在输出里掺杂各种“合理推测”这些在批量场景下都是灾难。3.4 代码工程类辅助为主不包办代码工程类指令我留下的数量不多但每条都很精细。核心原则是WorkBuddy 不是用来直接写完整项目的而是用来辅助完成那些高重复性、低创造性的代码相关任务。最常用的一条是“逐行注释”。触发场景是我把一段代码贴给它要求逐行添加中文注释。指令规定注释必须说明该行代码的作用和上下文关联禁止把显而易见的语法翻译成废话。这条指令主要用于交接给同事之前补注释或者自己回头看老代码时快速恢复记忆。实际使用中这条指令的问题在于注释粒度不好控制。模型经常出现该解释的不解释、不该解释的长篇大论。后来我在指令里加了一条约束只在包含业务逻辑、条件判断、数据转换的地方重点注释纯声明和导入语句跳过。加了之后输出质量提升了一个档次。另一条我经常用的是“报错溯源”。用法是把一段报错信息连同相关代码一起发给 WorkBuddy指令要求先解释报错出现的最可能原因再按概率从高到低列出可能诱因最后给出逐一排查的操作步骤。禁止直接甩一段完整改好的代码因为这会让用户跳过思考过程。这条指令的实践价值在于帮助排查问题的时候不丢思路。人在面对报错时容易慌乱病急乱投医地乱改代码。WorkBuddy 按指令给出的排查步骤能让整个过程有条理得多。代码类指令最重要的一条经验是要求模型给你方法而不是只给你结果。代码场景里结果不一定可靠但方法是可以验证的。我把这个原则写进了所有代码类指令的第一条要求里。3.5 跨对话与记忆类让指令沉淀为长期能力跨对话与记忆类指令是我最后才开始研究的也是收获最大的一类。它的使用逻辑是通过某些关键词或规则设定让 WorkBuddy 在后续对话中保持你在意的行为偏好。最基础的一条叫“开场即对齐”。它在每次对话开始时被触发要求 WorkBuddy 先复述本次任务的目标、约束条件和预期输出格式确认无误后再开始正式处理。这个动作看似多余实际上能避免大量后期返工。我举一个真实案例。有次我让 WorkBuddy 根据一段数据写分析报告它直接生成了完整报告。但我其实只想让它先列个框架口头表述不够明确导致它误解了需求。后来我加上“开场即对齐”之后每次下达任务它都会先跟我确认范围和输出形式我再说“开始”它才会生成最终内容。这个流程多花十秒但省掉了大改的时间。另一条比较有深度的是“身份预设”。这条指令的工作方式是在会话开始时设定一个角色身份例如“资深数据分析师”WorkBuddy 之后的回答语气、措辞、分析深度都会以此身份为基准。实测下来这比每次对话临时说“请以资深数据分析师的身份回答”要稳定得多因为角色设定一旦固化模型在多个轮次中都会保持同一套行为模式。记忆类指令的设计要格外小心因为它影响范围大、持续时间长一旦设置错误会让后续所有对话都受到错误干扰。我的建议是记忆型指令应该只约束行为风格和信息偏好不要涉及具体内容判断。比如“回复时优先提供方法论而不是直接给答案”是安全的但“用户技术水平较低要避免专业术语”这类主观判断就不太安全因为它会持续影响你之后所有对话的信息深度。4. 指令落地实战——从创建一条指令到形成一套体系4.1 创建指令的基本流程与文件结构很多人拿到 WorkBuddy 后第一件事是到处找别人分享的指令集然后一股脑导入这种做法的效率其实很低。别人的指令即使写得好也是为别人的场景服务的直接拿来用经常会水土不服。我更推荐的做法是把别人分享的指令当素材按自己的需求重新组装。创建一条新指令时我习惯按四段结构来写你可以直接套用。第一段是“角色与目标”一句话说明这条指令让 WorkBuddy 充当什么角色、完成什么目标。第二段是“执行步骤”把处理任务的过程拆成可以照做的步骤这一步是核心也是我觉得最需要花时间打磨的地方。第三段是“输出格式”明确最终结果应该长什么样最好用示例或结构描述。第四段是“禁止事项”把你不想看到的行为全部列出来比如不要编造数据、不要过度展开、不要使用特定语气。格式上我倾向于用 markdown 来组织指令文本。标题、列表、表格可以帮助模型快速抓取优先级纯段落式的指令易被忽略。WorkBuddy 本身对英文关键词的响应通常比中文更稳但正文用中文完全没问题关键是动作动词要具体。文件组织上我在本地维护了一个指令仓库每个大类的指令放在独立子目录里文件名用“序号_用途_版本号”的格式。比如“03_批量为王_v2.md”。版本号很重要因为指令迭代太频繁没有版本管理你根本不知道当前生效的指令内容和最初版差了多少。4.2 测试方法如何判断一条指令算不算合格每写一条新指令我都会跑一个固定测试流程大概分四步。第一步是“简单任务测试”拿一个最简单的同类任务去触发指令看看基本输出是否符合预期。这一步的目的是排查指令里有没有结构性错误比如格式要求是否自己矛盾、有没有理解不了的概念。第二步是“边界任务测试”故意用超出寻常范围的输入去测试。比如写“批量为王”的时候我给了一个只有一项的列表和一个有五十项的列表分别测试确认输出结构在极端情况下不会崩。第三步是“连续触发测试”连续多次执行同一条指令检查输出稳定性。如果第一次好用第二次就飘了多半是指令里存在模糊的、不可验证的描述需要继续收紧。第四步是“跨会话测试”开一个新对话触发同一条指令确认它没有依赖前文信息。这一步主要为了排查指令是否隐含了对特定语境的假设。四步测试全部通过后我才会把指令放进正式使用目录。即便如此我也会在实际使用的头一周持续观察因为真实场景的输入远比测试用例复杂。4.3 优先级与冲突处理多条指令同时触发怎么办指令数量一多冲突问题就显现了。最典型的场景是我既设了“结论先行”这种全局风格型指令又用了“报告生成”这种任务型指令两条指令里的某些要求可能对同一个行为给出了不同指示。我的处理方式是在 WorkBuddy 的全局规则里明确一条优先级声明任务型指令高于全局风格型指令最新触发的指令高于较早触发的指令具体格式描述高于抽象风格描述。这句话看起来简单但相当管用它给模型提供了一套清晰的裁决依据不至于在多指令环境下无所适从。另外我还养成了一个习惯在每条任务型指令的开头加一句“本条指令优先于全局规则执行”。这是一种显式冲突覆盖机制可以确保特殊场景的指令不会被通用规则稀释掉效果。还有一个细节很多人会忽略指令文件里的标题大小写和关键词一致性也会影响触发准确率。WorkBuddy 的指令触发主要依赖语义匹配如果同一类指令在文件里用了多种叫法模型可能把它们识别成不同的东西导致自治程度降低。我把每条指令的触发词统一成两到三个固定表达并在全局规则里列了完整清单明确哪个词对应哪条指令。5. 常见问题排查与避坑实录——这些坑你一定也会踩5.1 指令生效不稳定最优先排查的四个点如果一条指令有时候管用有时候不管用先别急着怀疑模型智商绝大多数情况是指令本身的问题。我遇到过无数次这种场景把排查经验整理成了下面这张表。现象最常见原因解决方向同一指令两次执行结果差异巨大指令中包含了不可验证的模糊要求如“高质量”“生动”把模糊要求拆成可验证的定量或结构约束指令只在前几轮对话生效后面失效指令约束被对话中的新信息覆盖在全局规则里声明该指令持续有效或在关键节点重复触发指令在复杂任务下明显变笨执行步骤过多模型处理不过来拆成多条子指令或精简步骤到不超过五个新导入的指令根本没反应指令命名或触发词与现有全局规则冲突检查全局规则里是否有更高优先级的同名指令我在调试“逐行注释”这条指令时就遇到过效果时好时坏的情况。一开始以为是模型抽风后来仔细检查发现指令里写了一句“提供清晰的注释”这句话看起来没毛病但它不可验证模型对“清晰”的理解完全随机。我把这句删掉替换成“注释必须解释该行代码的业务目的或逻辑作用禁止翻译字面语法”问题立刻解决。5.2 指令之间互相干扰怎么定位真凶当多条指令同时存在时你会发现输出质量莫名其妙地下降了。这种情况定位起来比较麻烦因为单独测试每条指令都是好的组合起来就出问题。我自己开发了一套“二分排查法”。把所有指令分成两组测试目标场景看哪一组能复现问题然后把有问题的那组再对半分重复操作直到定位到具体某条指令。这种方法跟查 bug 的思路一样效率很高十几分钟就能揪出元凶。定位到之后解决思路有两条。一是给那条指令降低权重把它里面的强约束改成弱建议二是把冲突的两条指令合并成一条把重叠部分整合、冲突部分按优先级取舍。大多数情况下我选择后者因为两条功能高度重叠的指令本身就不该分开存在。另外要特别提醒一句不要在自己的指令文本里用太多临时的、口语化的表达。指令毕竟是后续反复调用的规范文件语气随意会影响模型对严肃程度的判断。我见过有人写“发个周报给我要好看一点”这种指令缺乏可复用的稳定性不适合做成正式命令。5.3 指令不断累积变臃肿定期归档是一次必要的“断舍离”用了一个月之后你会发现指令越攒越多但常用的其实还是那么几条。如果不定期清理指令库会很臃肿处理时占用的上下文也会变长响应速度和质量都可能下降。我把每月最后一天设为指令归档日操作很固定先用查看指令触发记录统计本月每条指令被触发的次数。触发次数为零的要么是场景真的没出现要么是已经被更好的指令替代了我会先做一次复审然后决定是否归档。触发次数低但功能和另一条高度重叠的考虑合并。触发频率高但输出质量总是差一口气的安排一次专项迭代。这轮整理最直接的收益是我的指令从两百多条精简到现在的几十条触发成功率显著上升输出质量也更稳定。更重要的是这个过程让我彻底想明白了 WorkBuddy 的合理使用方式——它不是一个能替你思考的工具而是一个能把你已经想清楚的动作自动化执行的助手。它的上限取决于你对任务的理解深度指令只是把你脑中的标准翻译成机器能读懂的语言。如果你准备系统性整理自己的指令集我的建议很简单先盯着一个场景写到极致不要一开始就想把所有事情都覆盖全。把最痛的那个问题解决到顺手再往下一个场景扩展。指令这种东西自己从痛里打磨出来、真正适合自己的远比直接搬运别人的成品值得长期依赖。