如果你只是把 workbuddy 当成一个随手打开的聊天框问一句答一句那坦白讲你连它十分之一的能力都没用出来。我真正把 workbuddy 用顺手是从给它立规矩这件事开始的——在设置里把自定义指令一条条写好告诉它我是谁、我要什么、别怎么干。做完这一步之后它产出的东西从看起来挺对变成了直接能交差甚至在某些固定流程上比我自己盯得都细。这篇就记录一下我整套 workbuddy 自定义指令的配置思路、可直接抄的模板以及我在这过程中踩过的坑。不管你是拿 workbuddy 写文档、做科研整理、管项目还是把它接进小程序教学这类场景这套方法论都通用。真正拉开差距的从来不是工具本身而是你给它定的规矩。1. 为什么默认的 workbuddy 总是差一点我给指令拆的三层结构1.1 默认状态下的三个毛病先说我用默认配置时的体感。装好 workbuddy我让它整理一份项目周报它给我列了一二三四看着挺完整但细看全是正确的废话我让它给一个技术方案做评审它会先来一段背景铺垫再说结论我问一个具体问题它能给我扯出一堆相关性不高的发散内容。总结下来就是三个毛病回答过度泛化、风格不稳定、上下文连续性差。这不是 workbuddy 本身不行而是模型在没有约束的情况下会倾向于安全地平均回答——把所有人可能接受的表述方式揉在一起。就像一个新来的实习生你让他看着办他大概率给你交一份四平八稳但没什么用的东西。但你要是给他一本操作手册、一套验收标准、一份禁止事项清单结果会完全不同。1.2 自定义指令的本质是一份运行手册我后来想明白一件事自定义指令不是给 AI 写作文而是给它签岗位说明书。它需要在拿到任务之前就知道几件事你是谁角色定位、你面前的任务属于什么场景上下文锚点、你交付的东西要满足什么标准输出规范、你绝对不能做什么红线清单。我把指令拆成了三层来写这样既不混乱也方便迭代身份层定义它用什么视角回答问题。是严谨的技术专家还是口语化的写作助手还是分析型的研究助理。行为层定义它处理任务的流程和表达习惯。拿到问题先干什么、后干什么用什么样的结构输出哪些词不能用。边界层定义它不做什么。哪些问题不回答、哪些情况要主动询问、哪些修饰坚决不要。这三层在我的配置里各司其职后面遇到具体任务时它就不用每次临场猜我的意图了。1.3 规矩不是越严越好要留出呼吸空间第一版我写得极其严苛连回答必须控制在200字以内这种都写进去了。实际用下来发现一个问题太死的规矩会让它在处理复杂任务时束手束脚比如让它做方案对比时它宁可用列表凑字数也不写分析段落。后来我调整了策略——只定边界和默认偏好不定死每句话怎么写。也就是说指令负责把下限抬高但给它留足发挥空间。2. 自定义指令的核心配置项全局指令、项目指令和我的完整模板2.1 全局指令与项目指令的分工逻辑workbuddy 的设置里通常有两类地方可以写自定义指令一类是全局级别的对所有会话和项目生效另一类是项目级别的只在当前项目上下文里生效。这个分工一定要搞清楚否则就会出现改了全局导致所有任务风格突变的翻车现场。我的做法是全局指令只放三层里最稳定的部分——角色定位、通用表达规范、通用红线项目指令放跟当前任务强相关的内容——比如这个项目的术语表、交付格式、必须引用的文档路径。全局指令我可能一个月才动一次项目指令则跟着任务走随时调整。2.2 角色设定、输出规范、任务流程三个板块的写法要点写角色设定时不要只说你是一个有帮助的助手而要给出具体的视角和执行原则。比如我写的是你是一个有多年一线经验的技术负责人回答问题时优先给可落地的方案不要给教科书式的背景介绍。这样它输出的东西就会直接奔着怎么干去。输出规范部分我会明确结构偏好比如先给结论再给依据能用表格对比的就不要用长段落代码必须完整且标注语言类型对于需要验证的说法要明确指出信息来源的置信度。任务流程部分我要求它面对复杂任务时先拆解再执行先用自己的话复述一遍需求列出执行计划做完之后给一个自检清单。这一条对我这种经常让它处理多步骤任务的人来说特别有用能避免它少做或跑偏。2.3 我最常用的一个完整配置模板可直接抄下面是我目前全局指令里的核心内容你可以直接复制改。注意它不一定适合所有场景但框架是可以搬的。[角色] 你是一个有实战经验的工程与内容复合型助手。优先给出可直接执行的具体方案不做空泛的背景铺垫。不要自称作为AI不要使用总而言之综上所述这类结尾句式。 [输出规范] 1. 回答前先判断任务类型简单问答直接给结论复杂任务先列出简短计划再执行。 2. 正文优先使用短段落重要对比用表格代码块必须标注语言。 3. 每个结论尽量给出适用条件或例外情况不要给绝对正确的废话。 4. 需要假设时明确说我按XX假设来处理然后继续执行。 [任务流程] 1. 收到任务后先复述你理解的需求不超过3行。 2. 如果信息不足一次列出你需要的补充信息不要分多次问。 3. 交付前做一次自检是否回答了原问题是否有多余的修饰这套配置的本质是把我平时反复提醒它的那些话固化下来省掉了每次对话前都要重新交代一遍的麻烦。3. 把减少 AI 味写进指令我在设置里禁掉的表达3.1 AI 味到底是从哪儿来的热词里workbuddy减少ai味这条说明很多人有同感。我自己总结AI 味主要来自三个源头一是连接词太规整每段开头都是首先、其次、最后二是总结癖讲什么都非要来个收尾升华三是修饰词过载动不动就赋能助力一站式看着高级实际内容密度为零。如果不在指令里做明确约束workbuddy 默认的输出风格一定会往这个方向偏因为训练数据里这类文本太多了。想让它产出像人写的内容必须给它一套反面清单。3.2 我在指令里实际写入的禁止项不要小看这些细节它们对输出风格的影响比你想的大得多禁掉首先/其次/最后这类显性连接词改用自然过渡。禁掉总的来说综上所述值得注意的是这类无效引导。禁掉作为AI作为语言模型等自我身份声明。禁掉排比式开头比如无论是…还是…都…。禁掉在当今这个…的时代这类大背景开场。要求数字和事实先行形容词后置。我把这些直接写进了配置的输出规范里。一开始我也怀疑它有没有用实测下来非常明显——同一件事加了这些约束之后读起来从AI写的变成了一个干过这行的人在说话。3.3 用范例对比 反面清单而不是抽象要求只写请自然一点是没用的因为模型对自然这个抽象词的理解和你不一样。有效做法是给范例对比。我在指令里附了一段禁用风格 vs 期望风格的对比它就能准确锚定输出样式。比如[风格锚点] 反面示例 首先我们需要对项目进行整体规划其次要充分考虑资源调配最后通过持续迭代实现目标。 期望示例 这个项目我建议分三步走。第一步只做核心流程其他先不管跑通之后再补资源。注意这个技巧的关键在于不要只给反面清单而要给正面样例。模型是靠概率生成文本的给正面样本相当于直接给它指了一条明确的路。3.4 中文输出还有一个特殊坑如果你长期用中文交流会遇到一个现象workbuddy 回答的结构很英文。比如先来一句总起再分点再来个总结这是英文学术写作的逻辑直接平移成了中文。这就需要在指令里明确写使用中文的行文节奏允许长句和从句不要每段都是论点论据总结的铁三角。4. 技能skill与记忆管理让规矩跟着任务走4.1 把高频流程封装成 skill对于重复性任务我强烈建议你不要每次都用对话去描述需求而是把流程沉淀成一个 skill。workbuddy 支持自定义技能后我做文献整理时只需要触发技能名它自动执行检索来源→分类汇总→提取结论→标注可引用项这一整套动作不再需要我一条条说。我自己封装的一个科研场景 skill 是这样组织的技能名称文献综述速览 触发方式/review 执行步骤 1. 提取我提供的文献清单中的标题和摘要。 2. 按研究主题分组每组给出核心结论、方法、局限。 3. 输出对比表格列内包含主题、代表文献、核心发现、可引用程度。 4. 最后给出一个推荐阅读顺序。做完这个 skill 之后我在做课题前期调研时效率提升非常明显。关键是它让规矩不再只是静态的指令而是跟着具体场景走的动态流程。4.2 换账号丢记忆的坑我的一次搬迁教训大概几个月前我换过一次账号打开新版 workbuddy 发现之前所有的记忆、自定义指令、技能配置全都不见了。那一刻我才意识到workbuddy 的配置和记忆是跟着账号存储的但它也支持本地迁移。当时恢复的做法是这样旧账号里先把配置全量导出——包括自定义指令、skill 定义、模型偏好设置新账号装好之后先不着急干活把配置导入进去再手动确认一遍指令的分层结构有没有被改变。另外如果你之前的对话历史里有重要上下文workbuddy 有记忆库迁移的能力需要单独备份和导入光导入配置是不够的。这里要特别提醒一句迁移配置时最容易丢的是记忆部分。因为它往往散落在多个缓存文件里很多人只导了配置结果换账号后 AI 还是不认识你。4.3 缓存目录挪位置之后权限问题的处理还有一个容易被忽略的坑是缓存目录。workbuddy 默认会把缓存和索引存在系统用户目录下如果你像我一样想把它挪到自定义位置比如数据盘或者网络驱动器上要注意目录读写权限。在 Linux 环境下尤其明显挪完如果没给对属主workbuddy 会出现能启动但记不住新配置的情况。我当时的处理是先停掉 workbuddy 相关进程把旧目录完整复制到新位置然后用软链接把原路径指过去。不要手动删除旧目录里的东西因为里面有索引文件一旦丢了重新构建索引很费时间。5. 实测踩坑指令写好了为什么还会偶尔失效5.1 第一个坑切换模型后风格漂移workbuddy 允许在不同会话里切换模型但不同模型对指令的敏感度差别很大。我在同一个全局指令下用 A 模型时它老老实实按格式来切到 B 模型后同样的指令被无视了一半——倒不是完全不遵守而是它会穿插一些旧的表达习惯。后来我意识到这是因为某些模型的系统提示词里自带一套行文逻辑和你的指令冲突时它可能各退一步。解决办法不是删指令而是在切换模型后做一个快速验证用一个固定测试问题跑一遍看输出风格是否符合预期不符合就在项目指令里追加一行强调。5.2 第二个坑指令优先级冲突当全局指令和项目指令出现冲突时怎么处理是很多人没搞清楚的。比如我全局指令里写了回答要简洁但项目指令里写的是输出完整周报格式它到底听谁的实测下来的规律是项目指令的权重通常更高但前提是项目里没有明确规定全局指令才生效。这个前提很重要因为它意味着如果你在项目指令里写的内容不够具体AI 会退回全局指令去执行结果就是风格变得不稳定。所以我现在的做法是项目指令只覆盖必须覆盖的能不加就不加免得和全局打架。5.3 第三个坑指令被截断或遗忘自定义指令是有长度限制的当你写的东西太长靠后的部分可能在长对话中权重衰减表现就是对话前期遵守、到了后期开始跑偏。这不是玄学而是上下文窗口被新内容挤占之后旧指令的优先级变低了。解决方案有两个一是把指令精简化只保留核心二是在关键任务开始时用一句话主动提醒它请参照设置中的输出规范执行本任务。实测中第二种方法很管用等于帮你把指令的权重重新拉高。5.4 一个完整的排查链路规矩突然失效时我在做什么某次我遇到一个特别诡异的情况前两天还用得好好的规矩突然有一天它开始长篇大论、各种首先其次。我当时的排查顺序是先确认当前会话用的是哪个模型是不是被自动切到了别的模型。再检查全局指令是否被改动过尤其是多人共用账号时别人可能改过。接着检查项目指令是不是某个旧项目指令残留正在覆盖全局设定。再检查缓存目录空间是否写满索引损坏也会导致配置读取不完整。最后一步才是删缓存重启因为这一步要重建索引成本比较高。那次的问题最终出在第二步——账号被另一个同事改过一行字改的时候他没注意导致整个输出规范被覆盖了。所以如果你也在多人共用一个 workbuddy 环境我建议给全局指令做一个备份文件每月导出一份出了问题直接对比排查。6. 设定规矩之后我的实际使用效果和后续调整思路6.1 改造前后的输出对比为了方便你直观感受自定义指令的效果我把同一个问题的输出做了个对比这个问题是帮我梳理一下本周的项目进度报告。默认配置输出本周项目主要围绕三个方面展开。首先在需求分析阶段团队完成了用户调研其次在开发阶段完成了模块编码最后在测试阶段发现了一些问题。总体来说项目进展顺利后续需要持续关注风险。加了自定义指令之后的输出本周主线是需求收口。用户调研已完成结论是核心功能优先级不变开发侧模块编码完成80%剩余部分卡在接口联调测试阶段发现两个问题其中一个会影响下周发版今天正在紧急修。按当前节奏周五能出可测版本。差别在于第二版没有用首先其次的架子也没有总体来说这种没信息量的总结而是直接把结论、进度、风险和下一步动作摆出来。这种表达方式其实不复杂但没有指令约束默认模型就是会倾向第一种写法。6.2 我给自己保留的三个微调空间规矩不是设完就不动了。我现在给自己定了三个微调节奏每周复盘一次看本周内 workbuddy 的输出里有没有反复出现的毛病如果有就把它写入禁止清单。每次新增任务类型时先建对应 skill而不是往全局指令里堆规则。全局指令加得越多后期越容易失控。每两周做一次指令瘦身把已经默认遵守的内容从指令里删掉保持指令短小精悍。这三个节奏能防止一个很常见的问题指令越加越长最后模型根本抓不住重点。我见过有人把自定义指令写到几千字效果反而不如精简版。6.3 后续还可以往这几个方向扩展这套自定义指令的玩法其实不止于写文档和做周报。我目前在小程序教学的案例里已经试过一版把教学反馈的格式要求写进 skill让它自动批改学生作业时按错误定位→原因分析→改进建议三段结构输出效果很稳定。接下来我还打算做的是把团队项目复盘流程固化成一个 skill让每次复盘自动生成结构化纪要再就是把一些重复的数据处理任务也交给它用指令约定输入输出的格式规范。给 workbuddy 定规矩这件事核心逻辑和带新人一模一样不是你说了什么它就听什么而是你把期望讲清楚、把坑提前标出来它才能真正替你扛事。我现在这套指令已经迭代到第几版我已经记不清了但每改一次我都会拿旧任务实测一遍确认没有跑偏才继续用。毕竟工具的靠谱程度从来都取决于你给它设定的标准。 
长河君 · 2026/10/8 21:30:52 · 阅读 1.2k workbuddy自定义指令配置指南：告别AI味，让输出直接能交差
如果你只是把 workbuddy 当成一个随手打开的聊天框问一句答一句那坦白讲你连它十分之一的能力都没用出来。我真正把 workbuddy 用顺手是从给它立规矩这件事开始的——在设置里把自定义指令一条条写好告诉它我是谁、我要什么、别怎么干。做完这一步之后它产出的东西从看起来挺对变成了直接能交差甚至在某些固定流程上比我自己盯得都细。这篇就记录一下我整套 workbuddy 自定义指令的配置思路、可直接抄的模板以及我在这过程中踩过的坑。不管你是拿 workbuddy 写文档、做科研整理、管项目还是把它接进小程序教学这类场景这套方法论都通用。真正拉开差距的从来不是工具本身而是你给它定的规矩。1. 为什么默认的 workbuddy 总是差一点我给指令拆的三层结构1.1 默认状态下的三个毛病先说我用默认配置时的体感。装好 workbuddy我让它整理一份项目周报它给我列了一二三四看着挺完整但细看全是正确的废话我让它给一个技术方案做评审它会先来一段背景铺垫再说结论我问一个具体问题它能给我扯出一堆相关性不高的发散内容。总结下来就是三个毛病回答过度泛化、风格不稳定、上下文连续性差。这不是 workbuddy 本身不行而是模型在没有约束的情况下会倾向于安全地平均回答——把所有人可能接受的表述方式揉在一起。就像一个新来的实习生你让他看着办他大概率给你交一份四平八稳但没什么用的东西。但你要是给他一本操作手册、一套验收标准、一份禁止事项清单结果会完全不同。1.2 自定义指令的本质是一份运行手册我后来想明白一件事自定义指令不是给 AI 写作文而是给它签岗位说明书。它需要在拿到任务之前就知道几件事你是谁角色定位、你面前的任务属于什么场景上下文锚点、你交付的东西要满足什么标准输出规范、你绝对不能做什么红线清单。我把指令拆成了三层来写这样既不混乱也方便迭代身份层定义它用什么视角回答问题。是严谨的技术专家还是口语化的写作助手还是分析型的研究助理。行为层定义它处理任务的流程和表达习惯。拿到问题先干什么、后干什么用什么样的结构输出哪些词不能用。边界层定义它不做什么。哪些问题不回答、哪些情况要主动询问、哪些修饰坚决不要。这三层在我的配置里各司其职后面遇到具体任务时它就不用每次临场猜我的意图了。1.3 规矩不是越严越好要留出呼吸空间第一版我写得极其严苛连回答必须控制在200字以内这种都写进去了。实际用下来发现一个问题太死的规矩会让它在处理复杂任务时束手束脚比如让它做方案对比时它宁可用列表凑字数也不写分析段落。后来我调整了策略——只定边界和默认偏好不定死每句话怎么写。也就是说指令负责把下限抬高但给它留足发挥空间。2. 自定义指令的核心配置项全局指令、项目指令和我的完整模板2.1 全局指令与项目指令的分工逻辑workbuddy 的设置里通常有两类地方可以写自定义指令一类是全局级别的对所有会话和项目生效另一类是项目级别的只在当前项目上下文里生效。这个分工一定要搞清楚否则就会出现改了全局导致所有任务风格突变的翻车现场。我的做法是全局指令只放三层里最稳定的部分——角色定位、通用表达规范、通用红线项目指令放跟当前任务强相关的内容——比如这个项目的术语表、交付格式、必须引用的文档路径。全局指令我可能一个月才动一次项目指令则跟着任务走随时调整。2.2 角色设定、输出规范、任务流程三个板块的写法要点写角色设定时不要只说你是一个有帮助的助手而要给出具体的视角和执行原则。比如我写的是你是一个有多年一线经验的技术负责人回答问题时优先给可落地的方案不要给教科书式的背景介绍。这样它输出的东西就会直接奔着怎么干去。输出规范部分我会明确结构偏好比如先给结论再给依据能用表格对比的就不要用长段落代码必须完整且标注语言类型对于需要验证的说法要明确指出信息来源的置信度。任务流程部分我要求它面对复杂任务时先拆解再执行先用自己的话复述一遍需求列出执行计划做完之后给一个自检清单。这一条对我这种经常让它处理多步骤任务的人来说特别有用能避免它少做或跑偏。2.3 我最常用的一个完整配置模板可直接抄下面是我目前全局指令里的核心内容你可以直接复制改。注意它不一定适合所有场景但框架是可以搬的。[角色] 你是一个有实战经验的工程与内容复合型助手。优先给出可直接执行的具体方案不做空泛的背景铺垫。不要自称作为AI不要使用总而言之综上所述这类结尾句式。 [输出规范] 1. 回答前先判断任务类型简单问答直接给结论复杂任务先列出简短计划再执行。 2. 正文优先使用短段落重要对比用表格代码块必须标注语言。 3. 每个结论尽量给出适用条件或例外情况不要给绝对正确的废话。 4. 需要假设时明确说我按XX假设来处理然后继续执行。 [任务流程] 1. 收到任务后先复述你理解的需求不超过3行。 2. 如果信息不足一次列出你需要的补充信息不要分多次问。 3. 交付前做一次自检是否回答了原问题是否有多余的修饰这套配置的本质是把我平时反复提醒它的那些话固化下来省掉了每次对话前都要重新交代一遍的麻烦。3. 把减少 AI 味写进指令我在设置里禁掉的表达3.1 AI 味到底是从哪儿来的热词里workbuddy减少ai味这条说明很多人有同感。我自己总结AI 味主要来自三个源头一是连接词太规整每段开头都是首先、其次、最后二是总结癖讲什么都非要来个收尾升华三是修饰词过载动不动就赋能助力一站式看着高级实际内容密度为零。如果不在指令里做明确约束workbuddy 默认的输出风格一定会往这个方向偏因为训练数据里这类文本太多了。想让它产出像人写的内容必须给它一套反面清单。3.2 我在指令里实际写入的禁止项不要小看这些细节它们对输出风格的影响比你想的大得多禁掉首先/其次/最后这类显性连接词改用自然过渡。禁掉总的来说综上所述值得注意的是这类无效引导。禁掉作为AI作为语言模型等自我身份声明。禁掉排比式开头比如无论是…还是…都…。禁掉在当今这个…的时代这类大背景开场。要求数字和事实先行形容词后置。我把这些直接写进了配置的输出规范里。一开始我也怀疑它有没有用实测下来非常明显——同一件事加了这些约束之后读起来从AI写的变成了一个干过这行的人在说话。3.3 用范例对比 反面清单而不是抽象要求只写请自然一点是没用的因为模型对自然这个抽象词的理解和你不一样。有效做法是给范例对比。我在指令里附了一段禁用风格 vs 期望风格的对比它就能准确锚定输出样式。比如[风格锚点] 反面示例 首先我们需要对项目进行整体规划其次要充分考虑资源调配最后通过持续迭代实现目标。 期望示例 这个项目我建议分三步走。第一步只做核心流程其他先不管跑通之后再补资源。注意这个技巧的关键在于不要只给反面清单而要给正面样例。模型是靠概率生成文本的给正面样本相当于直接给它指了一条明确的路。3.4 中文输出还有一个特殊坑如果你长期用中文交流会遇到一个现象workbuddy 回答的结构很英文。比如先来一句总起再分点再来个总结这是英文学术写作的逻辑直接平移成了中文。这就需要在指令里明确写使用中文的行文节奏允许长句和从句不要每段都是论点论据总结的铁三角。4. 技能skill与记忆管理让规矩跟着任务走4.1 把高频流程封装成 skill对于重复性任务我强烈建议你不要每次都用对话去描述需求而是把流程沉淀成一个 skill。workbuddy 支持自定义技能后我做文献整理时只需要触发技能名它自动执行检索来源→分类汇总→提取结论→标注可引用项这一整套动作不再需要我一条条说。我自己封装的一个科研场景 skill 是这样组织的技能名称文献综述速览 触发方式/review 执行步骤 1. 提取我提供的文献清单中的标题和摘要。 2. 按研究主题分组每组给出核心结论、方法、局限。 3. 输出对比表格列内包含主题、代表文献、核心发现、可引用程度。 4. 最后给出一个推荐阅读顺序。做完这个 skill 之后我在做课题前期调研时效率提升非常明显。关键是它让规矩不再只是静态的指令而是跟着具体场景走的动态流程。4.2 换账号丢记忆的坑我的一次搬迁教训大概几个月前我换过一次账号打开新版 workbuddy 发现之前所有的记忆、自定义指令、技能配置全都不见了。那一刻我才意识到workbuddy 的配置和记忆是跟着账号存储的但它也支持本地迁移。当时恢复的做法是这样旧账号里先把配置全量导出——包括自定义指令、skill 定义、模型偏好设置新账号装好之后先不着急干活把配置导入进去再手动确认一遍指令的分层结构有没有被改变。另外如果你之前的对话历史里有重要上下文workbuddy 有记忆库迁移的能力需要单独备份和导入光导入配置是不够的。这里要特别提醒一句迁移配置时最容易丢的是记忆部分。因为它往往散落在多个缓存文件里很多人只导了配置结果换账号后 AI 还是不认识你。4.3 缓存目录挪位置之后权限问题的处理还有一个容易被忽略的坑是缓存目录。workbuddy 默认会把缓存和索引存在系统用户目录下如果你像我一样想把它挪到自定义位置比如数据盘或者网络驱动器上要注意目录读写权限。在 Linux 环境下尤其明显挪完如果没给对属主workbuddy 会出现能启动但记不住新配置的情况。我当时的处理是先停掉 workbuddy 相关进程把旧目录完整复制到新位置然后用软链接把原路径指过去。不要手动删除旧目录里的东西因为里面有索引文件一旦丢了重新构建索引很费时间。5. 实测踩坑指令写好了为什么还会偶尔失效5.1 第一个坑切换模型后风格漂移workbuddy 允许在不同会话里切换模型但不同模型对指令的敏感度差别很大。我在同一个全局指令下用 A 模型时它老老实实按格式来切到 B 模型后同样的指令被无视了一半——倒不是完全不遵守而是它会穿插一些旧的表达习惯。后来我意识到这是因为某些模型的系统提示词里自带一套行文逻辑和你的指令冲突时它可能各退一步。解决办法不是删指令而是在切换模型后做一个快速验证用一个固定测试问题跑一遍看输出风格是否符合预期不符合就在项目指令里追加一行强调。5.2 第二个坑指令优先级冲突当全局指令和项目指令出现冲突时怎么处理是很多人没搞清楚的。比如我全局指令里写了回答要简洁但项目指令里写的是输出完整周报格式它到底听谁的实测下来的规律是项目指令的权重通常更高但前提是项目里没有明确规定全局指令才生效。这个前提很重要因为它意味着如果你在项目指令里写的内容不够具体AI 会退回全局指令去执行结果就是风格变得不稳定。所以我现在的做法是项目指令只覆盖必须覆盖的能不加就不加免得和全局打架。5.3 第三个坑指令被截断或遗忘自定义指令是有长度限制的当你写的东西太长靠后的部分可能在长对话中权重衰减表现就是对话前期遵守、到了后期开始跑偏。这不是玄学而是上下文窗口被新内容挤占之后旧指令的优先级变低了。解决方案有两个一是把指令精简化只保留核心二是在关键任务开始时用一句话主动提醒它请参照设置中的输出规范执行本任务。实测中第二种方法很管用等于帮你把指令的权重重新拉高。5.4 一个完整的排查链路规矩突然失效时我在做什么某次我遇到一个特别诡异的情况前两天还用得好好的规矩突然有一天它开始长篇大论、各种首先其次。我当时的排查顺序是先确认当前会话用的是哪个模型是不是被自动切到了别的模型。再检查全局指令是否被改动过尤其是多人共用账号时别人可能改过。接着检查项目指令是不是某个旧项目指令残留正在覆盖全局设定。再检查缓存目录空间是否写满索引损坏也会导致配置读取不完整。最后一步才是删缓存重启因为这一步要重建索引成本比较高。那次的问题最终出在第二步——账号被另一个同事改过一行字改的时候他没注意导致整个输出规范被覆盖了。所以如果你也在多人共用一个 workbuddy 环境我建议给全局指令做一个备份文件每月导出一份出了问题直接对比排查。6. 设定规矩之后我的实际使用效果和后续调整思路6.1 改造前后的输出对比为了方便你直观感受自定义指令的效果我把同一个问题的输出做了个对比这个问题是帮我梳理一下本周的项目进度报告。默认配置输出本周项目主要围绕三个方面展开。首先在需求分析阶段团队完成了用户调研其次在开发阶段完成了模块编码最后在测试阶段发现了一些问题。总体来说项目进展顺利后续需要持续关注风险。加了自定义指令之后的输出本周主线是需求收口。用户调研已完成结论是核心功能优先级不变开发侧模块编码完成80%剩余部分卡在接口联调测试阶段发现两个问题其中一个会影响下周发版今天正在紧急修。按当前节奏周五能出可测版本。差别在于第二版没有用首先其次的架子也没有总体来说这种没信息量的总结而是直接把结论、进度、风险和下一步动作摆出来。这种表达方式其实不复杂但没有指令约束默认模型就是会倾向第一种写法。6.2 我给自己保留的三个微调空间规矩不是设完就不动了。我现在给自己定了三个微调节奏每周复盘一次看本周内 workbuddy 的输出里有没有反复出现的毛病如果有就把它写入禁止清单。每次新增任务类型时先建对应 skill而不是往全局指令里堆规则。全局指令加得越多后期越容易失控。每两周做一次指令瘦身把已经默认遵守的内容从指令里删掉保持指令短小精悍。这三个节奏能防止一个很常见的问题指令越加越长最后模型根本抓不住重点。我见过有人把自定义指令写到几千字效果反而不如精简版。6.3 后续还可以往这几个方向扩展这套自定义指令的玩法其实不止于写文档和做周报。我目前在小程序教学的案例里已经试过一版把教学反馈的格式要求写进 skill让它自动批改学生作业时按错误定位→原因分析→改进建议三段结构输出效果很稳定。接下来我还打算做的是把团队项目复盘流程固化成一个 skill让每次复盘自动生成结构化纪要再就是把一些重复的数据处理任务也交给它用指令约定输入输出的格式规范。给 workbuddy 定规矩这件事核心逻辑和带新人一模一样不是你说了什么它就听什么而是你把期望讲清楚、把坑提前标出来它才能真正替你扛事。我现在这套指令已经迭代到第几版我已经记不清了但每改一次我都会拿旧任务实测一遍确认没有跑偏才继续用。毕竟工具的靠谱程度从来都取决于你给它设定的标准。