WorkBuddy提示词工程实战：5条规则让AI稳定高效输出

1. 为什么你需要一套能直接用的 WorkBuddy 提示词1.1 WorkBuddy 到底是什么样的工作台先说结论WorkBuddy 不是一个普通的对话式 AI 工具而是一个把“规则设定”“Skill 扩展”“多任务编排”揉到一起的智能工作台。你可以在里面定义长期生效的规则把重复性工作封装成 Skill再通过提示词把一个个独立任务串成完整流程。和直接打开一个聊天窗口随口提问相比WorkBuddy 更像是在给自己配一个“按你的规矩办事”的固定搭档。我大概是在半年前开始重度使用 WorkBuddy 的。刚开始跟很多人一样把它当成一个普通问答工具来用结果发现同一个问题今天问和明天问得到的答案风格完全不同代码质量也忽高忽低。后来我才意识到问题不在模型本身而在于我从来没有给它立过规矩。这也是我写这篇文章的初衷。网上关于 WorkBuddy 的讨论不少但大部分都停留在“怎么安装”“怎么打开某个功能”的层面真正把提示词本身拿出来拆给你看的内容很少。所以这一篇我不想聊太多概念直接给你 5 条我已经实测过、放进日常流程里就能生效的提示词每一条的适用场景、设计思路、容易踩的坑都会讲到。1.2 提示词工程的底层逻辑不是“说得客气”而是“定规矩”很多人对提示词有一个误解觉得提示词就是“请你帮我看一下这段代码”这类客气话。真正的提示词工程完全不是这样。它的核心是两件事约束行为和定义输出格式。约束行为是让 AI 知道“你该做什么、不该做什么、遇到不确定时怎么办”。比如你希望它不要编造不存在的 API那就要在提示词里明确写“没有把握时必须说不知道”。定义输出格式是让 AI 每次都用同一种结构回报结果。比如代码审查你可以规定它先列问题清单再按严重程度排序最后给修复建议。这样做的价值在于你不需要每次都在一大堆自然语言回复里翻找关键信息。WorkBuddy 的提示词体系和普通对话工具还不太一样。它支持把某一段提示词设置为“全局规则”也就是我常说的“给 WorkBuddy 定几条规则后续对所有任务都生效”。这是它作为工作台最有价值的地方。你可以在全局规则里写清楚你的代码风格偏好、你需要的默认输出结构、它应该用中文还是英文回复。设定好之后新建任何任务都会自动带上这份约束不用每次重复啰嗦。1.3 这 5 条提示词的设计原则这 5 条提示词不是我从网上抄来的是我在实际项目里反复调整后沉淀下来的。它们遵循三个原则。第一每条提示词都对应一个高频场景。全局规则、代码审查、重构优化、测试用例、Skill 编排这五个场景基本覆盖了一个程序员日常工作的八成需求。你不需要记一百条提示词把这几条吃透效率就能有大变化。第二每条提示词都刻意做了“容错设计”。所谓容错设计就是不给 AI 含糊其辞的空间。我会在提示词里明确要求“如果不确定直接说不确定”“如果缺少信息先提问再执行”“不要输出没有被要求的代码片段”。这些细节是普通提示词和高质量提示词之间最大的差别。第三每条提示词都能和 WorkBuddy 的规则、Skill 机制结合。单独拿出来复制到聊天框里能用放进全局规则或封装成 Skill 效果更稳定。下文会单独讲怎么接进去。2. 5 条提示词逐一拆解与使用场景2.1 提示词一全局规则给所有任务定基线你是我的全职 AI 工作助手代号 WB。本规则对后续所有任务永久生效除非我明确要求覆盖。你的行为基线如下第一所有回答先理解意图再动手必要时向我确认第二每次涉及代码输出时必须给出完整可运行的版本禁止为了“看起来简洁”而省略 import 或关键逻辑第三当你对某个方案没有把握时请直接说“这里我不确定”并给出你判断的依据禁止编造并不存在的函数或 API第四默认使用中文回复代码注释用中文第五如果任务是修改现有代码先简要总结你将要做的改动再执行。这条提示词我放在 WorkBuddy 的全局规则里。它的设计思路很简单把 AI 的默认行为往“严谨、可交付、不吹牛”的方向拉。我不要求它变得多么聪明我只要求它稳定。聪明是模型决定的稳定是用提示词约束出来的。使用场景非常广。比如我经常让 WorkBuddy 帮我写一些一次性脚本处理日志、批量改文件名这类小任务。没有全局规则的时候它偶尔会给出一个依赖某个没引入的第三方库的代码或者丢给我一段“示意性质”的伪代码。加了规则之后它的回答基本都能直接跑通。听起来很基础但长期用下来省掉的是大量来回追问的时间。要注意一个细节全局规则的表述必须具体。我见过有人写“请保持代码质量”这种话太抽象AI 没法执行。真正有效的全局规则必须写清楚“什么是质量”比如“必须考虑空值输入”“必须错误处理”。这也是提示词工程和普通聊天的分水岭。2.2 提示词二代码审查用红队思维找出问题现在请你担任代码审查员用红队思维审查我发你的这段代码。审查范围包括潜在安全漏洞、错误处理缺失、性能瓶颈、可读性问题、边界条件遗漏。输出格式必须如下第一问题清单按严重程度从高到低排列第二每个问题标注代码行号和具体原因第三针对最严重的三个问题给出修复代码第四最后用两句话总结整体评价。注意如果代码没有任何问题直接说“未发现明显问题”不要为了凑数而强行提意见。这条提示词解决的是“AI 当老好人”的问题。直接用普通方式问“你看这段代码有没有问题”它通常会给出不痛不痒的建议比如“可以考虑优化性能”这种没有任何信息量的话。红队思维的意思是让 AI 主动去“挑刺”站在攻击者或苛刻测试者的角度看问题。我试过把一个有明显 SQL 拼接风险的代码片段丢给它在没有红队提示词的时候它的反馈是“代码逻辑清晰”加了这条提示词之后它第一项就指出了注入风险还给出了参数化查询的修复版本。差别就是这么大。关键点在输出格式的强约束。你不需要 AI 在代码审查时展示创意你需要的是标准化的检查结果。固定格式的另一个好处是方便后续处理问题清单直接复制到任务系统里就能用不需要二次整理。2.3 提示词三重构优化避免“改坏代码”的增量方案这是一次重构请求。要求在不改变对外行为和接口签名的前提下优化下面这段代码。优化优先级从高到低可读性、错误处理、性能。执行方式必须遵循增量策略第一步先分析代码现有问题给出问题清单第二步一次性给出完整重构后的代码第三步用表格对比重构前后每个函数的行为变化确认无行为变更第四步如有必要补充这一段代码依赖的外部条件说明。如果这段代码存在逻辑错误先指出错误再谈重构不要掩盖原有问题。重构是最容易出事的操作。让 AI 直接“优化一下”代码很多时候它会顺手改变接口签名或者把本来能跑通的逻辑改成看似更优雅但实际行为不一致的版本。这条提示词的核心就是限制它在“不改变对外行为”的框架内动手。增量策略是我后来加进去的。因为有一次我把一个老模块交给它重构它直接重写了整个文件对外行为变了导致下游调用全部报错。从那以后我强制要求它先列问题清单再给完整代码再做行为对比。这样做的道理很简单AI 重构代码时你至少要有能力快速判断它有没有偷偷改变原有逻辑。表格对比就是一种低成本的人工复核方式。这里补充一个实用经验如果是特别复杂的代码我会在提示词最后加一句“如果这段代码超过 300 行请先说明你计划拆成哪几个步骤再逐步执行”。这能防止 WorkBuddy 在单次回复里硬塞一个巨型代码块既难审查也容易出错。2.4 提示词四测试用例把“鹈鹕测试”思路带进日常请为以下函数设计一套测试用例覆盖以下维度正常输入、边界输入、空值/非法输入、以及一个“鹈鹕测试”用例。鹈鹕测试的定义设计一个看起来荒谬但严格来说仍满足输入条件的测试输入用来验证实现是否真正理解意图而不是只处理了最常见情况。输出格式每个测试用例包含输入、预期输出、测试动机三部分。如果被测函数存在你无法理解的约定先提问再生成用例。鹈鹕测试是社区里一个很有意思的测试思路。它来源于一个经典案例用“一只鹈鹕骑着自行车”这种完全反常识但描述清晰的输入去考验模型是真正理解了抽象需求还是在顺着问法迎合答案。放在测试领域它的意思是设计一种游离在常规思考路径之外的输入验证代码的健壮性。比如一个处理订单状态的函数常规测试会覆盖“已支付”“已发货”“已取消”鹈鹕测试则可能传一个“已支付但金额为负数”的状态组合。我把这个概念写进测试用例提示词之后WorkBuddy 生成的测试用例质量明显上了一个台阶。普通的测试提示词生成的都是教科书式用例鸭子和天鹅都在唯独没有“看起来像鸭子但会飞”的怪东西。鹈鹕测试要的就是这种怪东西因为它最擅长逼出代码里的隐性假设。需要提醒的是这个提示词里我专门加了“如果存在无法理解的约定先提问再生成”。因为有时候调用方的业务约定写在文档里模型并不知道。与其让它硬猜一个错误的预期输出不如让它先问清楚。2.5 提示词五Skill 编排把重复流程封装成能力创建一个名为“需求拆解”的 Skill。该 Skill 的职责是输入任意产品需求描述输出四段结构文档。第一段用户场景与核心痛点用 3 句话以内概括第二段技术方案建议列出关键选型并说明理由第三段任务拆解清单按依赖关系排序每项任务标注预估工作量第四段验收标准明确列出可测试的完成条件。在执行过程中如果需求描述存在明显歧义必须在文档开头单独列出你的假设然后基于假设继续输出。Skill 是 WorkBuddy 里最有“工作台”味道的功能。它相当于把一条提示词固化成一个随时可调用的模块。我经常把一些会重复用到的流程做成 Skill例如“需求拆解”“代码评审”“发布前检查”。每做一个新项目不需要重新写完整提示词直接调用对应 Skill 就能获得标准化的输出。这条提示词的价值在于模板化。很多时候我们不愿意用 AI是因为每次都要重新组织语言描述需求太麻烦。但封装成 Skill 之后你只需要给一句话输入剩下的事情全部由它完成。我目前最常用的是“需求拆解”任何一个新需求进来我先丢给这个 Skill拿到四段结构文档再决定怎么排期。效率提升非常明显。关于 Skill 设计我的经验是“一个 Skill 只做一件完整的事”。不要试图创造一个能处理所有问题的超级 Skill那只会让输出变得泛泛而谈。需求拆解就专注拆解审查就专注审查。边界清晰效果才稳定。3. 实操怎么把这 5 条提示词接进 WorkBuddy3.1 规则和 Skill 的配置步骤先讲最直接的方式。如果你只是想立刻体验效果打开 WorkBuddy 新建会话把 2.1 那一条全局规则粘贴进去发送然后再开始你原本要做的任务就能感受到行为变化。如果你想让它长期生效就需要配置到规则里。WorkBuddy 的界面入口是“工作台设置”里的“规则管理”不同版本位置稍有差异英文版一般在 Settings 下的 Instructions 或 Rules 区域。新建一条规则把内容粘进去保存后对所有会话生效。2.1 的全局规则就是这样配置的一次搞定以后不用管。Skill 的创建路径一般是“Skill 管理”或“技能中心”新建 Skill 时会有两个框一个是 Skill 的名称和描述另一个是具体的执行提示词内容。把 2.5 的提示词整体粘进内容框名称填“需求拆解”保存即可。创建完可以直接在会话里用“调用需求拆解 Skill”来触发。3.2 上下文工程如何让规则在后续任务中不失效光配置还不够这里有一个很多人不知道的细节WorkBuddy 对上下文长度有限制长会话中过远的早期规则可能会被截断或遗忘。这属于上下文工程要解决的问题而不是简单的“提示词写得好不好”。我常用的办法是把全局规则放在每个新会话的第一条消息里不依赖系统侧的记忆。这样即使会话很长规则也始终在最近的上下文窗口中被模型感知到的概率最大。同时我会把全局规则压缩到最精简的长度去掉语气词和解释性文字只留干巴巴的指令。原因很简单上下文窗口是稀缺资源规则越长留给实际任务内容的空间就越小。另外WorkBuddy 如果支持“置顶规则”或“固定提示词”功能尽量开启。一些版本里还可以给规则设置优先级。我把全局规则设置为最高优先级这样即便某个任务自身带了其他指令也不会覆盖我的行为基线。3.3 实测效果用与不用的差别到底有多大我拿一个实际任务做了对比。任务背景写一个 Python 脚本读取 CSV 文件按日期聚合销售额输出结果到新文件。这是一个非常常见的需求。没有配置任何规则时WorkBuddy 给出的代码虽然能跑但存在几个问题没有异常处理CSV 文件路径写死日期格式假设得太死板。最关键的是它没有校验文件是否存在文件路径不对就直接崩溃。代码风格也偏“教学式”注释比逻辑都多。配置了全局规则后同一任务的表现完全不同。它先在回答开头说明了自己的改动计划然后生成完整版本包含文件存在性检查、异常处理、灵活的时间格式解析最后还主动提醒我“如果 CSV 有表头不一致的情况可以启用容错模式”。同样是解决一个问题一个是交作业的心态一个是交付代码的心态。这就是提示词工程带来的实际差距。4. 常见问题提示词不生效、效果漂移、版本差异4.1 提示词不生效怎么办首要是检查位置。如果你把提示词放在普通对话里那它只对当前会话有效新会话就忘了。必须确认提示词是不是放在了规则区或全局配置里。其次是检查是否被其他指令覆盖。WorkBuddy 的指令执行顺序是全局规则 会话内指令 单次消息指令。如果你在某个会话里给它发过一条和全局规则冲突的指令后者会临时覆盖前者。还有一种情况是提示词写得太抽象。我见过不少“请保持高质量输出”这种规则模型不知道怎么执行。遇到不生效首先要做的是把规则改得更具体比如把“请保持高质量”改成“所有回答必须包含可运行的完整代码”。4.2 上下文被冲掉效果漂移的解法长时间使用过程中AI 突然“忘了规则”的现象我称它为效果漂移。这不是模型被换了而是早期规则被挤出了上下文窗口。解决思路只有一个让关键规则始终出现在最近上下文中。我现在的习惯是每切换一个新任务第一句话都是“重申全局规则”然后贴上压缩版规则。这样虽然多打几个字但可以保证它在每个关键节点上都保有行为约束。如果你创建了比较长的 Skill也建议在 Skill 内部重复一遍关键约束因为 Skill 触发时可能不会完整读取你的全部历史对话。4.3 版本与环境相关的坑WorkBuddy 不同版本的配置入口和功能支持确实有差异。我见过有人拿着国际版的截图去国内社区问“为什么我找不到这个按钮”那自然是找不到的。你手上是什么版本就按对应版本去找规则和 Skill 的入口。这里不涉及哪个版本更好的问题功能设计本来就不同重点是别拿 A 版的教程硬套 B 版。缓存目录能不能改到 D 盘这类问题不同版本支持程度也不一样。Windows 上有些版本的系统缓存目录可以在设置里自定义位置有些版本必须在安装时指定。如果你用的是便携版或旧版建议直接去官方文档查对应版本的说明不要轻信网上过时的教程。4.4 分享几个我踩过的坑最后说几个我自己的教训。第一不要把提示词写得太长。我早期写全局规则动辄五六百字结果模型反而抓不住重点。现在压缩到 200 字左右效果明显更好。第二不要让 AI 在“代码审查”和“代码修改”两个模式里反复横跳。审查就是审查修改就是修改混在一起它往往两个都做不好。第三Skill 命名别太随意。我一开始创建了一堆“优化”“处理”这种名字过两周自己也记不清哪个是干什么的命名时直接带上场景比如“需求拆解-Skill”“代码审查-前端”这样最好。根据我个人经验把这 5 条提示词真正跑顺之后WorkBuddy 从“一个能聊天的代码工具”变成了“一个不需要催的初级同事”。它不会给你惊喜式的灵感但它稳定输出、按规矩办事光是这一点就已经帮了大忙。如果你刚开始用 WorkBuddy建议从全局规则那一条起步先感受一下“被约束过的 AI”和“散养的 AI”之间的差别。那一步迈出去你自然就知道接下来该怎么调了。