我用 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 | 知识卡片生成 | #卡片 | 核心概念+案例+一句话记忆 | 读书笔记 |
| 08 | Bug复现与定位 | #bug | 复现步骤+假设清单+修复方案 | 排障 |
| 09 | 代码Review清单 | #review | 安全/可读/性能检查表 | 代码评审 |
| 10 | 重构建议 | #重构 | 问题列表+风险+分步方案 | 技术债清理 |
| 11 | API调试助手 | #api | 请求示例+错误排查 | 接口联调 |
| 12 | 正则生成器 | #正则 | 正则表达式+测试样例 | 文本处理 |
| 13 | SQL优化器 | #sql | 慢查询分析+改写SQL | 数据库调优 |
| 14 | 日志分析员 | #日志 | 异常归类+时间线 | 线上问题 |
| 15 | 自动化测试生成 | #测试 | 测试用例+边界情况 | 提测准备 |
| 16 | 周报数据汇总 | #周报 | 数据事实→业务结论→下一步 | 每周汇报 |
| 17 | 数据归因分析 | #归因 | 因子排序+影响权重 | 运营分析 |
| 18 | 会议纪要转行动项 | #行动项 | 决策列表+负责人+截止时间 | 会后跟进 |
| 19 | 项目复盘结构化 | #复盘 | 做得好/待改进/行动项 | 项目总结 |
| 20 | 用户反馈分类 | #反馈分类 | 分类表格+优先级 | 需求池维护 |
| 21 | 任务拆解器 | #拆解 | 子任务清单+依赖关系 | 复杂项目 |
| 22 | 优先级排序 | #优先级 | 四象限排序+理由 | 每日待办 |
| 23 | 日程冲突检查 | #日程 | 冲突列表+调整建议 | 排期 |
| 24 | 会议邀请生成 | #会议 | 议程+参会说明+会前材料 | 发起会议 |
| 25 | 目标拆解OKR | #okr | O→KR→关键动作 | 季度规划 |
| 26 | 收件箱清零 | #清邮箱 | 分类处理列表+回复草稿 | 邮件处理 |
| 27 | 全局格式化规则 | #格式化 | 统一Markdown输出 | 所有任务 |
| 28 | 跨对话记忆同步 | #记忆 | 上次结论摘要+待办 | 多会话衔接 |
| 29 | MCP技能配置模板 | #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，不处理其他任务"。这句话的隔离效果出乎意料地好，能明显减少跨指令污染。如果你也发现多个指令的输出互相串味，可以试试这个办法。
指令集这个东西，整理起来确实上瘾，尤其是一口气跑出一堆"看起来能用"的规则时，特别有成就感。但这个内容不是写字数，不是比收集数量，而是看哪条指令真正改变了你的工作方式。写了删、删了写大半年，我最深的体会是指令的价值不在多，而在于你愿不愿意每次都调用它。最后分享一个我一直在用的小技巧：新增任何指令之前，先问自己一句"明天我还会用它吗"，如果答案有一点犹豫，就干脆别进库。
