WorkBuddy指令集整理：从200条到30条，精选高效指令实战指南

我前后折腾 WorkBuddy 三个多星期，把社区里流传的、官方文档里写的、还有自己一点点试出来的指令全部过了一遍，差不多攒下来两百多条。真正留下来天天用的，只有 30 条。这个数字不是拍脑袋定的，是我把“看起来有用”和“实际有用”区分开之后，剩下的全部家底。

先解释一下我为什么要浪费时间干这件事。WorkBuddy 这类工具的核心价值其实不在模型本身，而在于你怎么指挥它。模型像一个能力很强但不太主动的新人，指令就是你交给他的工作手册。手册写得好，他能顶一个半熟手；手册写得烂，他连打印文件都能给你打歪。我在前期测试阶段踩过太多坑，比如指令太笼统导致输出千篇一律，又比如指令太死板导致换一个场景直接失灵，所以才动了彻底整理一遍的心思。

这篇文章会把我筛选指令的完整思路、最终留下的 30 条指令全览、其中最难调教好的几类指令的实操细节，以及我在落地过程中遇到的典型问题和排查方法全部摊开讲。如果你也在用 WorkBuddy，或者准备开始用，这篇能帮你少走至少一个星期的弯路。

1. 为什么要整理指令集——先把 WorkBuddy 的运行逻辑说清楚

1.1 WorkBuddy 的指令到底是什么

先说个基本概念。WorkBuddy 里的指令，本质上就是一段结构化的提示词，但它比普通提示词多了一层“可复用”的属性。普通提示词是你今天问一句、明天问一句，每次都要重新组织语言；指令则是把一种高频场景下的完整要求固化成一段文本，之后每次调用只需要一个简短触发词，WorkBuddy 就会按指令里写好的规则去执行。

举个例子。你直接说“帮我把这篇产品介绍改得正式一点”，模型会按它自己的理解随便改一版。但如果你事先写好一条指令叫“商务润色”，里面规定了语气、用词倾向、段落结构、禁止出现的表达方式，那么下次你说“用商务润色处理这篇产品介绍”，输出质量就会稳定得多。

我整理指令集的核心逻辑就是这个：把不可控的对话变成可控的标准化操作。

WorkBuddy 和 CodeBuddy 这类工具通常会把指令分成几种类型，比如全局规则、任务型指令、记忆型指令。全局规则是常驻的，对所有对话生效；任务型指令是接到具体任务时才触发；记忆型指令则负责跨对话保存关键信息。我最后留下的 30 条里，三种类型都有，但比例上任务型指令最多，因为这种指令最容易产生立竿见影的效果。

1.2 我整理指令集时的筛选标准

整理之前我先定了几条硬标准，防止自己什么都想留。

第一条，必须能解决具体问题，而不是描述一种愿望。有些指令写得很漂亮，比如“提升回答质量”“增强逻辑性”，但实际操作时你会发现，这种指令什么都没约束住，模型该怎么说还是怎么说。真正有用的指令一定包含了明确的动作，比如“先列出大纲再展开”“每段不超过 100 字且首句必须是结论”。

第二条，必须有稳定的输出格式或行为变化。我会对每条候选指令做三到五轮测试，每次换不同的输入内容。如果输出质量时好时坏，那这条指令的表述一定有问题，要么太模糊，要么约束条件互相矛盾，这种直接淘汰。

第三条，不能依赖特定版本的潜在能力。有些指令我用着效果很好，但换一个模型版本后就明显变差，这种我也不要。我要的是在不同版本之间表现都比较稳的指令，而不是碰运气式的玄学调参。

第四条，必须具备不可替代性。如果一条指令的效果和我直接对话时随手说一句差不多，那它没有资格占据指令位。真正值得做成指令的，必须是我每次都要手打一大段要求、且频率足够高的场景。

最后筛下来，30 条，每一名都有留下来的理由。

2. 30 条指令全览与分类逻辑

2.1 按用途划分的五大类

我把留下的 30 条指令分成五个大类，这个分类方式比较贴近实际使用场景，你可以直接拿来当参考框架。

这个比例不是我预先设计的，完全是筛完之后自然形成的。写作输出类和工作流自动化类占了大头，说明 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 的合理使用方式——它不是一个能替你思考的工具，而是一个能把你已经想清楚的动作自动化执行的助手。它的上限取决于你对任务的理解深度，指令只是把你脑中的标准翻译成机器能读懂的语言。

如果你准备系统性整理自己的指令集，我的建议很简单：先盯着一个场景写到极致，不要一开始就想把所有事情都覆盖全。把最痛的那个问题解决到顺手，再往下一个场景扩展。指令这种东西，自己从痛里打磨出来、真正适合自己的，远比直接搬运别人的成品值得长期依赖。