我用 WorkBuddy 有大半年前前后后往自己的指令集里塞了两百多条 Skill也就是大家常说的给 AI 定的规则。等真正跑完一轮之后发现绝大部分用了一两次就不想再碰能稳定出活、让我愿意反复调用的翻来覆去也就 30 条。这篇文章就是把这 30 条从收藏夹里重新捞出来梳理一遍讲清楚它们为什么能留下来以及怎么抄作业改成你自己的版本。如果你刚开始接触 WorkBuddy这篇可以帮你少走弯路如果你已经在用指令集有一阵子了这篇可以用来做一次对照体检。先说结论指令这东西不是写得越多越好而是越能预期越好。下面我把筛选逻辑、完整清单和实操拆解一次讲透。1. 在淘汰指令前先想清楚什么叫“真能用”1.1 我筛选指令的三个硬指标很多人收集指令喜欢看热闹看到别人贴一段很长的提示词就复制进库结果真正用的时候发现完全不顺手。我的判断标准其实特别朴素就三个可复用、可预期、可维护。可复用指的是这条指令不是一次性提示词。比如帮我写一封邮件这种我就不会收因为下次我还是要重新组织需求。真正可复用的指令是那种输入固定的上下文就能反复触发的东西比如邮件起草指令你只需要告诉它主题和收件人背景它就能按固定的结构给你出稿。可预期是说相同状态下跑这条指令产出的格式、风格、质量不会有太大波动。我见过太多指令开头写着请以最专业的态度、全方位地……结果每次回复的格式都不一样有时给你表格有时给你长段落这种就是不可预期。稳的指令必须把输出结构钉死。可维护是我后期才意识到的一点。指令是会失效的WorkBuddy 本身升级、模型版本调整、你自己的工作流改变都会让旧指令不再好用。如果一条指令本身逻辑复杂到你自己都看不懂那坏了也没法修。所以我现在收指令的第一眼不是看它的上限有多高而是看如果它哪天不正常了我能不能在两分钟之内找到问题在哪。1.2 被淘汰最多的三类废稿指令我删掉的一百多条里大部分都能归进三类。第一类是堆砌动词型就是那种请以行业专家的身份深度赋能、全面覆盖、多维度输出听起来很唬人但对模型没有任何约束力。模型不会因为你说全方位就真的全方位它只会按概率继续往下走最后给你一段正确但没用的空话。第二类是贪多求全型。一条指令里塞四五个任务比如帮我分析数据、写总结、做PPT大纲、顺便翻译成英文。WorkBuddy 在长上下文里最怕这种多线任务做到后面经常顾此失尾。后来我定了个规矩一条指令只解决一个核心问题宁可多建几条也不要让一条扛太多活。第三类是场景错位型。我看到过很多用角色扮演来定义任务的指令比如假设你是一位有十年经验的高级律师但实际要干的任务是写周报。角色设定和任务本身没有关系模型得先识别这个角色背景再结合任务中间很容易跑偏。真正好的指令应该把重点放在任务流程上角色设定最多一句带过不该喧宾夺主。2. 30条指令的整体分组与设计逻辑2.1 先看整理后的分组表最终留下的 30 条我按日常使用场景分成了五组。有人说指令集这个名字容易联想到 CPU 指令集架构其实这里说的纯粹是 WorkBuddy 里的 Skill / 提示词集合别混了。下面是完整清单每条都配了触发词、输出形态和典型场景。序号指令名触发词输出形态典型场景01标题生成器#标题5个标题适用场景表文章、视频起名02爆款文案改写#改写改写前后对比改动用意公众号、朋友圈03邮件起草#邮件主题正文备选语气商务沟通04口语转书面语#书面化转换稿保留词说明语音记录整理05多语言校对#校对修正列表翻译建议出海物料06产品卖点提炼#卖点卖点列表对应证据销售页07知识卡片生成#卡片核心概念案例一句话记忆读书笔记08Bug复现与定位#bug复现步骤假设清单修复方案排障09代码Review清单#review安全/可读/性能检查表代码评审10重构建议#重构问题列表风险分步方案技术债清理11API调试助手#api请求示例错误排查接口联调12正则生成器#正则正则表达式测试样例文本处理13SQL优化器#sql慢查询分析改写SQL数据库调优14日志分析员#日志异常归类时间线线上问题15自动化测试生成#测试测试用例边界情况提测准备16周报数据汇总#周报数据事实→业务结论→下一步每周汇报17数据归因分析#归因因子排序影响权重运营分析18会议纪要转行动项#行动项决策列表负责人截止时间会后跟进19项目复盘结构化#复盘做得好/待改进/行动项项目总结20用户反馈分类#反馈分类分类表格优先级需求池维护21任务拆解器#拆解子任务清单依赖关系复杂项目22优先级排序#优先级四象限排序理由每日待办23日程冲突检查#日程冲突列表调整建议排期24会议邀请生成#会议议程参会说明会前材料发起会议25目标拆解OKR#okrO→KR→关键动作季度规划26收件箱清零#清邮箱分类处理列表回复草稿邮件处理27全局格式化规则#格式化统一Markdown输出所有任务28跨对话记忆同步#记忆上次结论摘要待办多会话衔接29MCP技能配置模板#mcp技能描述参数定义扩展外部工具30指令自检器#自检指令问题诊断优化建议指令维护列表看起来不花哨但这 30 条是我逐条跑过很多轮之后才留下的。它们之间有个共同点每条都只守着一个固定的输入输出协议没有一条是笼统地请 AI 帮个忙。2.2 为什么按“场景”分组而不是按“复杂度”刚开始整理指令集时我也试过按难度分组比如基础指令进阶指令高阶指令结果没几天就乱了。后来才想明白指令是拿来用的不是拿来展览的一定要嵌进自己的工作流里才好使。按场景分组最大的好处是你不需要记指令的逻辑结构只需要记自己在什么场景下会干什么。比如我每周五写周报那我自然会用到 #周报每天开会自然会用到 #行动项。场景和触发词之间建立起条件反射指令才不会躺在收藏夹里吃灰。另外说一下总有人问的 WorkBuddy 和 CodeBuddy 的区别。这两个放在一起看更像是一个工作台和一个结对编程助手的差异。WorkBuddy 里的指令集偏向全流程任务管理从内容生成、数据归纳到日常效率都能覆盖CodeBuddy 则更聚焦在写代码这个具体动作上。正因为 WorkBuddy 的面更宽指令集的规划才更需要场景化否则散落各处的提示词很难真正沉淀成方法论。3. 精选指令拆解真的能稳定出活的那种3.1 内容与文案类5分钟出第一版草稿先说 01 号标题生成器。这条的原始指令特别短但约束得非常具体。请为下面的内容生成5个标题。 规则 1. 使用数字痛点解决方案的公式至少2个。 2. 每个标题不超过20字。 3. 输出时用表格展示包含三列标题 / 适用场景 / 使用理由。 4. 不要输出任何与标题无关的开场白。 内容{{粘贴内容}}它好用就三个原因数量固定、公式明确、格式钉死。生成 5 个标题既能给足选择空间又不会多到让人选择困难数字痛点解决方案是一种可以直接落地的标题结构不会让模型漫无边际地发挥表格输出则保证了每次结果都长一个样方便复制。02 号爆款文案改写也值得一提。很多人在改写时最怕 AI 乱改所以我这条强制要求输出改写前后对比和改动用意。这么做等于给模型加了检查机制它知道后面要解释自己为什么这么改落笔就会克制很多。实际测试下来有了这个要求之后无意义的同义替换明显减少了。03 号邮件起草是我的日常高频。它的核心不是让 AI 从零写一封邮件而是先给它关键信息用商务邮件格式写一封邮件。 必需信息 - 收件人关系{{例如合作方负责人}} - 主题{{一句话概括}} - 需要对方做的事{{明确提出}} 输出时给两个版本一个直接版本一个委婉版本。注意这里特意限定了需要对方做的事这是很多邮件指令漏掉的部分。没有明确的行动请求邮件写出来再漂亮也没用。两个版本的设计则是为了方便不同沟通对象实际用时先看一眼措辞再复制比自己干写快得多。3.2 代码与工程类让 AI 先复现再下结论08 号 Bug 复现与定位是我在排障场景里最常用的一条。很多 AI 收到报错就直接给答案但答案经常是泛泛而谈。我的指令强制它走完整流程你现在是一名调试工程师。 请按以下步骤处理问题 1. 先根据描述还原可能执行路径列出你推理出的复现步骤。 2. 再从日志和报错中提取关键异常按影响程度排序。 3. 给出 2-3 个合理的根因假设不要直接下唯一结论。 4. 对每个假设给出验证方法和对应的修复代码片段。 输出统一使用 Markdown 分节展示。这条最大的价值在第三点不直接下唯一结论。模型和人一样看到第一个明显错误就停住是常事。强制它列出多个假设之后很多隐藏问题都会被顺带挖出来。我试过不止一次最终根因恰恰就藏在第二条假设里。09 号代码 Review 清单则是把评审这件容易漏的事变成了固定动作。指令内容本质上是一张检查表安全性、可读性、性能、测试覆盖每一项都要逐条打钩并且必须标注问题所在行号。有了行号要求AI 就不好意思说空话了给的建议都能直接定位到代码。这条我每次合代码之前都会跑一遍已经成了习惯。3.3 数据与效率类从“记录”到“决策”16 号周报数据汇总这条写出来的效果比我预期要好。它的设计思路不复杂但是很讲究顺序基于我提供的原始数据按以下顺序输出周报 1. 罗列本周关键数据事实不要加判断。 2. 基于这些数据提炼2-3条业务结论。 3. 根据结论给出下一步具体行动项。 要求数据事实、业务结论、行动项分三块排版彼此不得混写。这个顺序其实是刻意安排的。大多数人做总结时最大的问题是把事实和结论混在一起AI 也一样。如果让它直接写个周报它会把猜测和事实搅成一锅粥。先把事实单列出来再让结论基于事实最后落行动项这样产出的周报基本能直接贴在汇报里。关键是每一条结论都能指回某个具体数据领导最吃这套。18 号会议纪要转行动项也是高频场景。原始会议记录往往又散又乱这条指令会要求模型先抽取所有决策再标注每项决策对应的负责人、截止时间和关联任务。如果原始记录里没有明确负责人它必须明确标出待确认而不是自己编一个。这样能避免 AI 幻觉也能真正把会议落到执行层。21 号任务拆解器解决的是活太大不知道从哪下手。它的做法是把任务拆解为可执行的子任务。 要求 1. 每个子任务必须是可以独立完成的动作不能是模糊方向。 2. 标注子任务之间的依赖关系用前置xxx标出。 3. 按依赖关系排序输出为清单。 4. 最后一个部分给“最早可启动项”建议。最大的收获是第四点最早可启动项。很多任务列表列完就完事了看完还是不知道今天干嘛。多了这个输出等于让 AI 顺手帮你拍板了一个切入点帮助非常大。3.4 系统与规则类让指令集自我维护27 号全局格式化规则属于基建型指令。它不是解决单个任务而是给所有任务定一个统一的输出规范。比如要求所有回复都用 Markdown 分节、列表不超过三级、表格前必须先有说明句。这些规则一旦放进全局每条指令的产出质量都会明显提升。我建议你在 WorkBuddy 里把全局规则控制在 5 条以内太多会让模型每条都要先过一遍规则反而拖慢反应。30 号指令自检器是很多人的盲区。指令写多了难免出问题与其自己苦想不如让 AI 帮你 debug。这条指令的内容是让它从指令目标是否清晰是否有冲突要求输出格式是否固定是否有模糊词汇四个维度诊断一段指令文本并给出修改后的版本。我现在每次新增指令都会先让 30 号跑一遍相当于给指令集加了一层质检。不要小看最后这两条系统级指令。指令集能不能长期维护下去靠的往往是这些看起来不直接产出的底层层。4. 怎么把这些指令变成你 WorkBuddy 里的常驻规则4.1 新指令三连测试法不管是从别人那里抄来的还是自己写的新指令进库前我都会做三连测试。做法很简单同一个指令准备三个不同但内容相关的输入连续跑三次然后检查两个东西。第一个是格式一致率。三次输出的结构是不是基本一样如果有一次给表格、一次给段落、一次给列表那说明指令里的格式约束还不够强需要补上更明确的输出规则。第二个是结论一致率。对于事实型任务三次输出的核心结论是不是一致如果三次说法都不一样这条指令就没有可预期性趁早优化。我的经验是格式一致率低于 80% 的指令不进正式库核心结论一致率低于 50% 的直接淘汰。这个门槛看着高实际上能达标的指令并没那么难写关键就看约束够不够具体。4.2 用触发词和场景标签降低使用门槛指令本身写得好只是第一步。真正让指令长期被使用的是触发方式足够顺手。我在 WorkBuddy 里给每条常用指令都配了一个短触发词比如 #周报、#bug、#拆解。触发词的设计原则很简单要短、要无歧义、要跟日常生活里的说法一致。不要用那种需要想半天的关键词比如开始进行每周工作汇报整理这太长了。我见过有人把触发词设置成英文长句结果真要用时总得翻列表。触发词最好是你不会跟其他人撞车的词比如改太泛改成#改写就清楚多了。另外给指令打场景标签也很重要。WorkBuddy 支持在技能配置里写适用场景我会把会议后提测前每周五下午这类时间或事件点标进去。这样当我在新对话里不知道用什么指令时扫一眼场景列表就能找到。使用频次是检验指令价值的最终标准所有降低触发成本的做法都值得做。4.3 全局规则与技能指令的边界很多人刚接触 WorkBuddy 时喜欢把所有规则一股脑塞进全局设置让它们对后续所有任务都生效。我踩过这个坑。全局规则一旦堆了十几条每次对话模型都要先消化这堆规则反应变慢不说不同规则之间还会互相打架。比如全局里说回复尽量简洁某条技能指令又说请输出详细表格最后模型就很容易陷入混乱。我的经验是全局规则只放真正的底线比如输出使用 Markdown、不得编造数据、回答前先说明假设。至于具体任务里的流程、格式、角色都放到对应的技能指令里。这样才能各司其职。顺带说一句跨对话记忆。WorkBuddy 的跨对话记忆功能挺实用但我是用 28 号指令来管理而不是让它自动记住所有内容。做法是在每次重要对话结束时用 #记忆 让模型生成一段本次结论未完成事项的摘要然后手动存到记忆库。这样既保留了上下文又不会被无关闲聊污染记忆。所谓对后续所有任务都生效的规则一定是你主动记录的而不是被动累积的。5. 常见问题与排查技巧实录5.1 指令“没生效”的排查顺序我经常收到类似的提问我明明配置了指令为什么 WorkBuddy 没反应遇到这种情况我的排查顺序是固定的省得东猜西猜。先看触发词是否真的被识别。很多人设置时写了触发词但使用时在对话框里输入的不是完整触发词比如漏了 # 号自然不生效。再看当前对话是否有其他规则覆盖。全局规则或早前对话里的要求可能会跟你的技能指令冲突。检查的方法是单独开一个新对话只输入触发词看它是否正常运行。如果单独跑没问题但在某个具体任务里没有生效那大概率是上下文里残留了旧指令的影响。WorkBuddy 本质上是把当前对话的所有文本一起交给模型处理的前面的要求会把后面的指令淹没。遇到这种情况最好的办法就是新开会话或者手动用 #记忆 同步关键上下文。5.2 输出偏离预期时的三板斧指令写好了但输出仍不理想我的调试方法很简单三板斧加约束、加例子、减要求。加约束是明确输出格式和边界。比如不要输出开场白直接用表格如果信息不足明确说信息不足。不加废话这四个字比请简洁回复有效得多。加例子是给模型一个模仿样本。比如想让 AI 按某种语气写文案就直接在指令里附带一段参考例句。模型在 few-shot 场景下对例子的模仿能力远强于干巴巴的描述。这个技巧尤其适合那些需要风格一致的任务。减要求是指如果指令太长导致稳定性下降就果断砍掉一部分。很多时候我们觉得指令写得越细越好但上下文窗口有限每条约束都在挤占信息空间。保留最关键的三个要求有时比列十个要求更稳。5.3 指令之间的相互污染问题最后提醒一个隐蔽的坑当你有二三十条指令后指令之间很容易相互污染。表现是模型在该模块化输出时突然混入另一条指令的表达习惯。比如我写过一条 #复盘里面用了做得好的/待改进/行动项三段式结果后来跑 #周报 时模型也给我套了复盘结构。原因就是指令写得太相似或者触发词太接近。我的对策有两个一是不同场景的指令在措辞和结构上刻意拉开差异二是在每条指令开头加一句本指令只负责XXX不处理其他任务。这句话的隔离效果出乎意料地好能明显减少跨指令污染。如果你也发现多个指令的输出互相串味可以试试这个办法。指令集这个东西整理起来确实上瘾尤其是一口气跑出一堆看起来能用的规则时特别有成就感。但这个内容不是写字数不是比收集数量而是看哪条指令真正改变了你的工作方式。写了删、删了写大半年我最深的体会是指令的价值不在多而在于你愿不愿意每次都调用它。最后分享一个我一直在用的小技巧新增任何指令之前先问自己一句明天我还会用它吗如果答案有一点犹豫就干脆别进库。