1. 为什么我要给 workbuddy 立规矩刚上手 workbuddy 那阵子我跟大多数人一样把它当成一个更聪明的搜索框——丢一句话进去等它吐结果不满意就重来。用了两周我发现一个很尴尬的事实同一个任务我早上问和下午问得到的输出质量能差出一倍。有时候它像个靠谱的老同事有时候又像个刚入职的实习生连我上一句说过的约束都能忘。问题不在模型本身而在于我从来没告诉它我是谁、我要什么、别做什么。这就像你招了个能力很强但完全不了解你业务习惯的新人你不给他岗位说明书他只能靠猜。猜对了是运气猜错了是常态。后来我开始系统性地给 workbuddy 写自定义指令也就是在会话开始前就把角色、边界、输出格式、思考方式一次性钉死。效果立竿见影重复解释的成本没了输出风格稳定了最关键的是——它开始记得我的偏好不用我每次重复不要用那种客套话开头代码必须带注释结论放最前面。这篇内容适合三类人看一是刚接触 workbuddy、还在靠感觉提问的新手二是用了几个月但输出质量忽高忽低的进阶用户三是想把 workbuddy 接入团队工作流、需要统一输出规范的人。我会把自定义指令的设计逻辑、字段拆解、实操模板、踩过的坑全部摊开讲你照着抄就能用。2. 自定义指令到底在改什么从随机发挥到按规矩办事2.1 先搞清楚指令不是提示词是人格设定很多人把自定义指令和单次 prompt 混为一谈这是最大的认知误区。单次 prompt 是这一句话你帮我干什么自定义指令是你以后一直是谁、按什么标准干活。前者是任务后者是身份。打个比方prompt 是你去餐厅点菜说来份宫保鸡丁自定义指令是你进门就跟服务员说我是老顾客口味偏淡不要味精上菜前先给我一杯温水。后者一旦设定整场用餐体验都会被影响你后面点任何菜都自动套用这套偏好。workbuddy 的自定义指令通常作用在会话的系统层优先级高于你后面输入的每一句话。这意味着两件事第一它能覆盖你 80% 的重复性要求第二如果写错了它会持续污染你所有的对话。所以写之前要想清楚写之后要测试。2.2 一条合格指令的四个必备字段我试过几十版指令最后沉淀下来一个稳定结构四个字段缺一不可角色定位你是谁服务谁专业背景是什么任务边界做什么、不做什么、遇到模糊情况怎么处理输出规范格式、长度、语气、结构要求思考方式先分析还是先给结论要不要列假设要不要主动追问这四个字段对应的是四个不同层面的控制。角色定位解决它用什么知识库和视角回答任务边界解决它会不会跑偏或过度发挥输出规范解决结果能不能直接用思考方式解决它的推理过程可不可信。我见过太多人只写第一句你是一个专业的XX助手就完事了结果输出还是飘。因为角色只是起点边界和规范才是真正约束行为的东西。2.3 为什么定规矩比反复纠正更省事算一笔账。假设你每天和 workbuddy 交互 20 次每次平均要额外说 2 句纠正的话太长了重写一下不要用这个格式一天就是 40 句废话。一个月 1200 句。这些句子消耗的是你的注意力也消耗 token。而一套好的自定义指令写一次大概花 30 分钟之后每天省下的纠正成本是实打实的。更重要的是纠正式交互会让对话上下文变得混乱——你上一句说简短点下一句又说展开讲讲模型在矛盾指令里反复横跳输出质量必然下降。自定义指令把这些矛盾提前消解掉让整个会话保持一致的基调。提示自定义指令不是写得越长越好。超过 800 字的指令模型对后半段的遵循度会明显下降。宁可精炼不要堆砌。3. 手把手拆解我的 workbuddy 指令模板长什么样3.1 角色定位怎么写才不空你是一个专业的助手这种话等于没说。角色定位要具体到领域、经验年限、服务对象、工作风格四个维度。我常用的一个角色定位段落是这样的你是一位有 8 年一线经验的全栈工程师主要服务对象是 中小型技术团队的负责人。你的表达风格直接、务实不喜 欢堆砌术语遇到复杂概念会先用生活化类比解释再补充 专业细节。你默认读者有一定基础但不会假设对方精通所 有子领域。注意几个细节年限给了具体数字8 年服务对象明确了团队负责人风格描述用了不喜欢这种否定式表达比正面描述更有约束力最后一句主动划定了读者画像。这四句话加起来不到 100 字但已经把输出的基调锁死了。对比一下你是一个资深工程师前者能产出这个方案在 50 人以下团队够用再大就得考虑分库这种带判断的输出后者只会给你教科书式的通用答案。3.2 任务边界把不要做什么说清楚模型最大的毛病是过度热情——你问 A它顺带把 B、C、D 都讲了还贴心地给你加了一堆你没要的建议。任务边界就是给它划红线。我的边界段落通常包含三类约束范围约束只处理什么领域的问题超出范围直接说这不在我的职责内行为约束不主动扩展需求、不擅自改格式、不确定时先问不猜质量约束不编造数据、不假装知道、引用来源要标明举个实际例子。我做技术方案评审时会加这么一句当我的需求描述存在歧义时不要自行假设先列出你识别到 的 2-3 种可能理解让我确认后再继续。如果你不确定某个 技术细节直接说这点我不确定不要用模糊表述蒙混。这一句救过我很多次。以前它会在歧义处默默选一个方向往下写写完一大段我才发现方向错了全部重来。现在它会先停下来问反而更快。3.3 输出规范格式、长度、语气三件套输出规范是最容易见效的部分因为格式问题一眼就能看出来。我一般从三个维度约束维度常见要求我的实际写法格式标题层级、列表、表格用 Markdown二级标题带编号对比内容用表格长度字数上下限、详略默认 800-1500 字除非我明确说展开语气正式/口语、人称用你不用您不用客套开场白直接给结论这里有个反直觉的经验长度约束比格式约束更重要。因为格式错了你一眼能改长度失控会让你读一堆废话。我早期没设长度问一个小问题它能给我写 3000 字读到最后发现核心就三句话。语气约束里我特别加了一条不用客套开场白。因为模型默认喜欢说这是一个很好的问题让我们一起来探讨这些句子零信息量纯占地方。明确禁掉之后输出密度立刻上来了。3.4 思考方式让它先想后说这是最容易被忽略、但价值最高的一段。思考方式决定了模型是边想边说还是想清楚再说。我的写法是回答复杂问题前先在内部完成推理明确问题本质、 列出关键假设、评估 2-3 种方案。最终输出时先给结论 再给理由最后给可执行步骤。如果推理过程中发现我的 前提有误先指出前提问题再回答。这段指令带来的最大变化是它开始会反驳我了。以前我说帮我优化这段代码它直接改现在它会先说这段代码的性能瓶颈不在你指的地方而在循环里的重复查询。这种主动纠偏才是真正把工具用出了价值。注意思考方式这段不要写请一步步思考这种老式提示词。现在的模型对这类指令已经免疫甚至可能因为过度展开而变啰嗦。要写就写先结论后理由这种结构化的输出要求。4. 完整实操从零搭一套能用的指令4.1 第一步先跑 10 次裸对话收集痛点别急着写指令。先花两天时间正常用 workbuddy每次交互后记一笔这次哪里不满意是太长、太短、跑题、格式乱、还是结论不明确我当时的记录大概是这样第 1 次问 API 用法它给了 5 种方案我只想要最常用那种第 2 次让它写邮件语气太正式像公文第 3 次问报错原因它列了 8 条可能没告诉我最可能是哪条第 4 次让它总结文档它把原文抄了一遍10 次之后痛点自然聚类成几类方案要收敛、语气要口语、排查要排序、总结要提炼。这四类就是我的指令要解决的核心问题。没有这一步你写出来的指令是拍脑袋的覆盖不到真实需求。4.2 第二步按四字段结构起草初版把上一步的痛点翻译成指令语言。我的初版是这样的【角色】你是一位有 8 年经验的全栈工程师服务中小团队 负责人风格直接务实善用类比。 【边界】需求有歧义时先列可能理解让我确认不确定的信 息直接说不确定不主动扩展我没问的内容。 【输出】Markdown 格式二级标题带编号默认 800-1500 字用你不用您不要客套开场白结论放最前面。 【思考】复杂问题先内部推理输出时先结论、再理由、后 步骤发现我前提有误先指出。这版大概 200 字结构清晰。但直接用会发现还不够——它没解决方案要收敛和排查要排序这两个具体痛点。所以需要第三步。4.3 第三步针对高频场景加专项规则通用指令解决 70% 的问题剩下 30% 靠专项规则。我在指令末尾加了一段场景化约束【专项规则】 - 给方案时默认只给 1 个最优解 1 个备选说明选择理由 不要罗列所有可能性。 - 排查问题时按可能性从高到低排序每条附上验证方法。 - 总结内容时先给 3 句话核心结论再展开细节。 - 写对外文案时语气自然像同事之间说话不用尊敬的 敬请这类词。这四条对应我前面收集的四个痛点一一对应。加完之后输出质量肉眼可见地稳定了。4.4 第四步测试、迭代、固化写完不是结束是开始。我拿 5 个典型任务测了一遍写代码、排查报错、总结文档、写邮件、做方案对比。每个任务看三点格式对不对、长度合不合适、有没有解决专项痛点。测试中发现两个问题一是默认 800-1500 字对简单问题太长了它会把一句话的事撑成 800 字二是只给 1 个最优解在方案对比场景下不适用我需要看多个选项。于是改成长度根据问题复杂度自适应简单问题 200-400 字复杂问 题 800-1500 字。方案对比场景例外可以列 3-5 个选项 并用表格对比。迭代三轮之后指令基本稳定。现在我的完整指令大概 500 字覆盖了角色、边界、输出、思考、专项规则五个部分。4.5 一份可直接抄的完整模板把上面的内容整合给你一份可以直接用的版本按需替换领域相关部分【角色定位】 你是一位有 8 年一线经验的全栈工程师服务对象是中小型 技术团队负责人。表达直接务实善用生活化类比解释复杂 概念默认读者有基础但不精通所有子领域。 【任务边界】 需求有歧义时先列出 2-3 种可能理解让我确认不要自行 假设。不确定的技术细节直接说不确定不要模糊表述。 不主动扩展我没问的内容。 【输出规范】 Markdown 格式二级标题带编号。长度自适应简单问题 200-400 字复杂问题 800-1500 字。用你不用您。 不要客套开场白直接给结论。对比内容用表格。 【思考方式】 复杂问题先内部推理明确本质、列假设、评估方案。输出 时先结论、再理由、后步骤。发现我前提有误先指出。 【专项规则】 - 给方案默认 1 个最优解 1 个备选说明理由 - 排查问题按可能性排序每条附验证方法 - 总结内容先给 3 句核心结论再展开 - 对外文案语气自然不用尊敬的敬请5. 踩过的坑这些指令写法会让你越用越糟5.1 坑一指令里塞太多绝对化词汇我早期特别喜欢用必须绝对永远严禁觉得这样约束力强。结果适得其反——模型在遇到边界情况时会因为绝对指令和实际需求冲突而卡壳或者生硬地执行导致输出很怪。比如我写过永远不要用列表结果它在该用列表的地方硬写成段落可读性反而变差。后来改成默认用段落仅在整理步骤或要点时用列表灵活性就回来了。经验是用默认优先除非这类柔性词比必须绝对更有效。约束的目的是引导不是锁死。5.2 坑二把指令写成需求文档有人把自定义指令写成几千字的需求文档恨不得把公司所有业务规则都塞进去。这是典型的用力过猛。前面说过超过 800 字遵循度就下降而且指令越长内部矛盾的概率越高。我现在的原则是指令只放跨任务通用的规则具体业务规则放到单次 prompt 里。比如输出用 Markdown是通用的放指令里这次帮我写个 Python 脚本处理 CSV是具体的放 prompt 里。分工明确各司其职。5.3 坑三写完不测试直接上生产我见过有人写完指令就直接用来处理重要工作结果输出格式全乱。自定义指令一定要先拿低风险任务测确认稳定了再用到关键场景。测试清单我一般看这几项检查项合格标准格式遵循标题、列表、表格是否符合要求长度控制简单/复杂问题是否自适应边界响应歧义时是否主动追问语气一致是否去掉了客套话专项规则四个高频场景是否都覆盖五项全过才算可用。5.4 坑四一套指令打天下不同任务其实需要不同的指令侧重。写代码和写文案对语气、格式、思考方式的要求完全不同。我现在的做法是维护 2-3 套指令一套技术向、一套文案向、一套分析向按场景切换。如果你嫌切换麻烦至少把专项规则部分做成可替换的模块角色、边界、输出、思考这四段保持通用专项规则按任务换。5.5 坑五忽略指令冲突的排查有时候输出不对劲不是指令写错了而是指令之间打架了。比如你既要求简洁又要求详细解释每个步骤模型就会在两者之间摇摆。排查方法很简单把指令逐条读一遍看有没有互相矛盾的。常见冲突组合有简洁 vs 详尽、正式 vs 口语、固定格式 vs 灵活输出、先结论 vs 先铺垫。发现冲突就删掉优先级低的那条。6. 进阶玩法让指令活起来6.1 用变量让一套指令适配多个场景如果你的工作涉及多个领域可以在指令里留占位符用的时候替换。比如【角色定位】 你是一位有 {年限} 年经验的 {领域} 专家服务对象是 {对象}。表达风格 {风格}。用的时候把{领域}换成前端开发或市场营销一套骨架适配多个场景。这比维护多套完整指令省事得多。6.2 把指令和示例结合效果翻倍光有规则模型有时候还是抓不准你要的感觉。这时候给 1-2 个示例比写 10 条规则都管用。比如你想要结论先行的输出风格与其写请先给结论不如直接给一个示例示例输出 结论这个方案在 50 人以下团队可用。 理由... 步骤...模型看到示例会直接模仿这个结构。这叫少样本学习是提升指令遵循度最有效的手段之一。6.3 定期回顾指令也需要保养业务在变指令也得跟着变。我大概每个月回顾一次看有没有新的高频痛点需要加进专项规则有没有过时的约束需要删掉。回顾的时候问自己三个问题这个月有没有反复纠正同一件事有没有哪条规则从来没生效过有没有新的任务类型没被覆盖三个问题答完指令的迭代方向就清楚了。提示指令迭代不要频繁。每次改完至少用一周再评估频繁改动会让你分不清是指令的问题还是任务本身的问题。7. 我个人的几条实操心得用到现在我最大的体会是自定义指令的价值不在于让 workbuddy 变聪明而在于让它变稳定。聪明是模型的事稳定是你的事。一套好指令就是把你的工作习惯、质量标准、沟通偏好固化下来让每次交互都从同一个起点出发。第二个体会是写指令的过程其实是在梳理自己的工作方法。你得先想清楚我到底要什么样的输出才能写出对应的规则。很多人写不出好指令不是不会写是没想清楚自己要什么。所以写指令之前先问自己我理想中的输出长什么样第三个是别追求一次到位。我的指令改了十几版才稳定前几版都很粗糙。重要的是先写出来用起来在用的过程中发现问题、迭代优化。空想是写不出好指令的。最后分享一个小技巧把你最满意的一次输出保存下来作为黄金示例放进指令里。模型看到具体的好例子比看十条抽象规则更能抓住你要的感觉。这个技巧我用在文案类任务上效果特别明显——加上示例之后输出风格的一致性提升了不止一个档次。如果你也在用 workbuddy不妨今天就花 30 分钟按上面的四字段结构写一版自己的指令。写完拿三个日常任务测一测你会发现工具还是那个工具但干活的感觉完全不一样了。