我先说个判断这类“直接拿来用”的提示词市面上百分之八十都是标题党。拿回来复制进去要么答非所问要么第一次好用第二次就飘根本原因在于提示词本身没有结合工具的工作机制。WorkBuddy 不是普通聊天机器人它是带工作台、带 skill、带上下文管理能力的 AI 编程助手提示词只有踩着它的工作方式写才能真正“一次粘贴长期生效”。这篇文章我把实际工作中沉淀下来的 5 条 WorkBuddy 提示词完整贴出来每条都会拆清楚三件事它解决什么问题、为什么这样写、放进 WorkBuddy 之后预期看到什么效果。最后再补一部分调优和避坑经验都是文档里不会写的。1. 为什么 WorkBuddy 需要“定制提示词”而不是随口问先对齐一个概念WorkBuddy 和普通 AI 编程工具最大的区别在于它有一个“工作台”的概念。你可以把任务、上下文、规则、技能全部挂在同一个工作区内所有后续对话都共享这套背景信息。这意味着提示词不再只是一次性指令而是一种可以沉淀、继承、复用的“工作约定”。所以给 WorkBuddy 写提示词本质上是在做两件事一是把任务说清楚二是把约束条件固定下来。很多新人拿它当普通聊天框用每开一个新任务就重新描述一遍背景结果 AI 每次都从零理解输出质量随缘。真正高效的用法是像给新员工写入职手册一样把默认规则、质量标准、交互方式一次性定好之后每次对话自动继承。另一个关键点WorkBuddy 支持 skill 机制也就是可以把某类任务的执行流程封装成技能。提示词和 skill 的配合关系是——提示词负责“这次任务怎么干”skill 负责“这类任务一直怎么干”。两者结合才能既保持灵活性又保证一致性。下面这 5 条提示词覆盖了全局规则、单任务执行、代码审查、测试生成四个最常用场景是我在真实项目里反复验证过的写法。2. 先立规矩让 WorkBuddy 后续所有任务都遵守同一套规则2.1 全局规则提示词模板第一条提示词不是解决某个具体任务而是给整个工作台“立法”。我在拿到一个新项目或者搭建新的工作台时第一件事绝对不是让它写代码而是先把协作规则说清楚。否则后面每轮对话都在跟它博弈“你要不要解释一下再动手”“你能不能别在代码里写废话注释”非常消耗耐心。请作为我的 AI 编程搭档记住以下全局规则后续所有任务未经我明确说明变更都必须默认遵守 1. 代码输出默认使用简体中文注释和提交说明变量名和函数名使用英文语义要准确禁止拼音命名。 2. 提问策略当任务描述中有歧义时先列出你理解的需求要点和假设条件等我确认后再开始动手如果我有明显错误直接指出并给替代方案。 3. 输出格式涉及代码修改时先一句话概括改动思路再给出 diff 或完整文件内容最后用列表说明改动点禁止输出大段与任务无关的说明。 4. 技术选型默认倾向稳定、社区活跃的方案引入新依赖前必须说明理由和替代方案对比。 5. 安全要求禁止给出明显存在注入、越权、明文密码等安全缺陷的代码如有相关风险要主动提示。这条提示词的价值在于“默认值”。就像给打印机设置默认双面打印你不需要每次打印都叮嘱一次它天然就是那个行为。WorkBuddy 的特点是会保留同一工作台内的上下文所以只要你把这段贴进第一轮对话后面所有任务它都会遵守。我实测下来设置完规则之后后续输出的代码注释风格、回答结构、提问方式都会稳定下来很少再出现答非所问的情况。2.2 规则为什么能生效上下文继承机制有人可能问我把规则贴在对话里WorkBuddy 就一定会记住吗这里要说明它的上下文机制。WorkBuddy 在同一工作台内会维护一个持续性的上下文窗口也就是说你后续发的每一条消息它都会结合之前所有对话来理解。规则声明放在最前面相当于在它的小脑里写入了长期偏好后续所有任务都会在这个偏好之上叠加执行。但有个坑必须提醒上下文窗口是有上限的。如果你的对话特别长早期规则可能被“挤”出有效窗口行为就会开始漂移。我的习惯是每工作 50 到 80 轮之后重新粘贴一条精简版规则或者把规则写进一个独立的 skill让 WorkBuddy 在需要时自动加载。这种做法比反复口头强调有效得多。3. 核心干货5 条 WorkBuddy 提示词逐条拆解3.1 提示词一新任务冷启动模板适用场景开启一个全新功能开发、新文件编写、新模块设计时。这条提示词解决的核心问题是“启动信息不完整”。很多人开门见山一句“帮我写个登录功能”AI 只能猜猜错了就来回返工。新任务启动请按以下结构执行 任务目标[一句话描述你要实现的功能] 技术栈[语言/框架/版本如 Python 3.11 FastAPI PostgreSQL] 约束条件[性能要求、兼容性要求、禁止使用的依赖或写法] 验收标准[完成这个任务后怎样算做好了列出可检查的指标] 交付形式[完整代码 / 代码片段 / 方案说明 / 重构建议] 第一步请先根据以上信息补充你的技术实现思路列出关键决策点 第二步说明你计划的文件结构和模块划分 第三步在得到我确认后再开始生成代码。这条提示词最重要的是最后两行——它强制 AI 先出方案再动手。你可能会觉得多了一步很麻烦但实测下来这个“确认环节”能省掉至少一半的返工。因为 AI 在列方案的过程里会把模糊的需求具体化你只需要扫一眼它列的假设条件就知道它理解得对不对。如果不对这时候纠正成本最低。我实际用 WorkBuddy 开发一个内部工具时把任务目标写成“批量处理 Excel 并生成统计报表”AI 列出的方案里包含了对数据量级、内存占用、输出格式的假设。我一看它默认输入是 xlsx 格式赶紧补充了还有 csv 旧数据避免了后面整段返工。这就是“先方案后代码”的价值。3.2 提示词二代码审查提示词替代人工 Review 首轮适用场景写完一段代码之后让 WorkBuddy 以资深工程师视角做一次 code review。这条我几乎每天用尤其适合那些写完感觉自己看不出问题的新手以及重构完代码怕埋雷的老手。请以资深代码审查者的身份审查以下代码并严格按顺序输出 1. 问题分级清单 - 严重问题会导致崩溃、数据错误、安全漏洞 - 一般问题影响可维护性、扩展性、性能 - 建议优化代码风格、可读性、命名 2. 每个问题必须说明 - 具体位置行号或函数名 - 为什么这是问题解释影响不要只说“这样不好” - 修复建议给出可直接替换的代码片段 3. 最后给一句总体评价说明代码是否可以提交。 审查时请重点关注边界条件处理、资源释放、异常捕获、安全性、并发问题。这条提示词强烈建议配合 WorkBuddy 的上下文功能使用——把待审查的代码直接粘贴在上下文之后它会基于工作台已有的项目背景来理解代码逻辑而不是孤立地看片段。我实测过脱离上下文的审查经常会误报“缺少 import”之类的问题而结合工作台会话的审查准确率明显高很多。一个特别的用法审查之前先把你的代码意图用一两句话说清楚。比如“这个函数用来解析日志文件输入最大 100MB必须在低内存设备上运行”。有了这个约束AI 会重点审查内存相关逻辑而不是泛泛看语法层。这让审查结果更有针对性。3.3 提示词三重构与迁移助手适用场景旧代码迁移到新框架、调整项目结构、把一个函数拆成多个模块。重构类任务最怕的是“改坏了但不知道哪里坏了”。这条提示词的设计目标就是最大限度降低重构风险。我将要对现有代码进行重构/迁移请协助我完成要求如下 当前代码[粘贴代码或描述代码位置] 目标改动[说明要改成什么样例如将 A 函数拆为 B 和 C、从 Flask 迁移到 FastAPI、引入类型注解] 请按以下方式执行 1. 先分析当前代码的行为逻辑用列表说明“输入-处理-输出”链路 2. 识别改动会影响到的外部调用方和测试用例 3. 给出逐步重构方案每步规模尽量小保证中间步骤可运行 4. 每完成一步说明如何验证该步骤没有改变原有行为 5. 全程禁止引入与目标无关的格式调整即使现有代码格式不美观。 额外要求重构完成后用对比表格列出改动前后差异并标注哪些文件需要重点回归测试。写“每步规模尽量小保证中间步骤可运行”这句话非常关键。AI 重构和人有同样的毛病——喜欢一次性把文件改得面目全非。加上这条约束后它会倾向于给出渐进式方案每步都能跑。我迁移一个 Django 项目的部分模块到 FastAPI 时WorkBuddy 给出的步骤分成了 6 步每一步都会标注“此时路由尚未切换旧接口仍然可用”这样我可以在每步之间独立测试整个迁移过程几乎没有出现长时间不可运行的状态。还有一个小细节明确禁止无关的格式调整。因为 AI 重构时经常顺手把单引号改双引号、把缩进调整、把函数顺序重排这些噪音会让 code review 变得极难。加一句禁止diff 就干净很多。3.4 提示词四测试用例生成器适用场景写完功能代码后让 WorkBuddy 自动生成配套测试。很多人的第一反应是让 AI“写个测试”结果得到的往往是一堆 happy path 用例边界、异常、性能全都没覆盖。这条提示词强制它从需求出发反推测试。请根据以下信息设计测试用例并生成可直接运行的测试代码 被测对象[函数/类/接口描述或粘贴代码] 需求行为[说明这个功能应该做什么包括正常的和异常的场景] 测试框架[如 pytest / JUnit / Go testing] 运行环境[如 Python 3.11 Linux] 请严格按以下顺序组织测试代码 1. 基础功能用例覆盖正常输入下主流程的 3-5 个关键场景 2. 边界条件用例空值、极值、特殊字符、最大长度、最小长度、零值、负数 3. 异常与错误处理用例非法输入、依赖服务异常、超时、权限不足 4. 数据一致性用例重复调用、并发调用、状态持久化 5. 测试数据说明每个用例基于什么假设数据来源是什么 生成后请额外列出你觉得当前实现中最脆弱的 3 处逻辑并说明对应的测试用例设计考量。这条提示词的巧妙之处在于最后一条“最脆弱的 3 处逻辑”。它迫使 AI 不只是机械地从代码行号生成覆盖而是主动思考哪里容易出问题。实际用过一次你就知道这个逆向设计比盲目全量生成更有价值。我拿到过一份 AI 生成的测试它自己标出的脆弱点之一是一个容易被忽略的时区处理问题这个问题恰恰是我交付后最担心的点。这种“思考过程外显”的效果是普通“帮我写测试”拿不到的。补充一点测试代码生成后一定要让 WorkBuddy 在项目的真实环境中先跑一遍。WorkBuddy 支持执行命令你可以直接让它“运行 pytest 并分析失败原因”。这比生成代码后自己手动复制到终端再跑要高效得多。3.5 提示词五任务拆解与自我驱动执行适用场景一个大任务包给 WorkBuddy让它自动规划并逐步执行每完成一步向你汇报。这是 WorkBuddy 工作台模式的核心用法也是最接近“AI 员工”的操作方式。这是一个较大的任务请按工程化方式推进 任务总目标[描述整个任务例如开发一个命令行工具支持通过配置文件批量重命名文件] 执行要求 1. 先拆解为 3-7 个可独立验收的子任务每个子任务必须包含明确交付物和验收标准 2. 从最核心的子任务开始执行不要按依赖顺序反着来 3. 每完成一个子任务输出简短的执行报告格式为已完成内容 / 验收结果 / 下一步计划 4. 如果某个子任务遇到前置条件不满足停下来说明原因和可选择方案不要自作主张换技术方案 5. 全部完成后输出完整的项目总结包括技术方案、使用说明、已知局限、潜在扩展点。 请先输出任务拆解方案等我确认后再开始执行第一个子任务。这条提示词的核心价值就一句话让 AI 自己管理自己的任务队列。我在开发一个文件批处理工具的时候让它拆解任务它给出了“配置文件解析-核心重命名逻辑-命令行交互-日志与错误处理-测试”五个子任务并且在每个子任务结束时主动总结经验为下一步做铺垫。这种自我驱动模式真的能给你一种“带了个实习生”的感觉。但这里有一个实操要点最后一行“等我确认后再开始执行第一个子任务”不能省。很多教程为了省事直接让 AI 一口气跑完结果它花了半小时做出来的东西方向从一开始就错了。多花两分钟确认拆解方案后面至少省两小时。4. 把这些提示词变成 WorkBuddy 的长期能力4.1 Skill 封装把提示词从“复制粘贴”升级为“一键调用”每次手动复制粘贴也挺烦的尤其是当你有七八条常用提示词时。WorkBuddy 支持 skill 机制可以把上面这些提示词封装成可复用的技能。操作上不复杂在技能配置里给每一条提示词起一个固定的名称和描述后续对话中直接说“使用代码审查技能检查一下 XX 文件”它就会自动加载对应的提示词逻辑执行。我自己的做法是建了四个技能全局规则、代码审查、任务拆解、测试生成。全局规则放在技能的“启动项”里每次新开工作台自动生效其余三个按需触发。这样用下来整个工作流非常顺滑基本不需要记忆长提示词。值得注意Skill 和直接贴提示词还有一个区别。Skill 可以附带额外的指令和约束比如“审查代码时不看测试文件”“拆解任务时每个子任务必须给出时间预估”。相当于是给提示词加了一层“参数化配置”灵活度更高。4.2 提示词的迭代没有一次到位的提示词只有不断调优再好的提示词也是改出来的。我基本每用一周就会微调一次。判断标准很简单如果一条提示词在三次不同类型的任务中表现都不理想不是它写得不好就是它用错了场景。切忌一条提示词打天下。调优技巧方面我建议用“鹈鹕测试法”来验证提示词是否真的稳健。这个方法的思路是给提示词配一个最离谱、最刁钻的测试输入看它会不会被带偏。比如你把代码审查提示词拿去喂一份“明显是新手写的、充满反模式的代码”它如果还能保持审查结构不乱、该怎么分级怎么分级说明提示词的框架足够稳。这类测试我在拿到新提示词时必做一次专治“看起来很长很专业、实际经不起变化”的虚胖模板。另外每次修改提示词之后顺手做一次回归拿旧任务再跑一遍确认修改没有让之前好用的行为退化。这个习惯帮我躲过了不少“改坏了”的情况。5. 常见问题与排查技巧实录5.1 AI 回答越来越“水”明显没有一开始聪明这是 WorkBuddy 使用中最常见的问题通常不是工具变笨了而是上下文被大量无关内容污染。排查思路很简单检查对话长度。如果已经连续聊了很多轮、中间还夹杂大量无关话题AI 的注意力焦点会涣散。解决方法是“重置上下文”新开一个工作台把全局规则重新粘贴一次然后把当前任务的背景用两三句话重新描述一遍。实测下来这种做法比在旧对话里继续追问要高效得多。另一个思路是把关键资料写进 skill让 AI 在需要时自行加载不占用日常对话的窗口。5.2 提示词明明写得很详细AI 还是不听这种时候先别急着怪提示词先检查一个细节你的提示词里“禁止”和“必须”是不是混用了。心理学和工程实践上都有类似结论——AI 对“必须做什么”的理解严格程度远高于“不要做什么”。同一件事把“不要啰嗦”改成“每条回答控制在 100 字以内”效果立竿见影。另一个常见问题是提示词里同时包含多个目标但没有排序。AI 会自己“猜”优先级而它猜的往往不是你想要的。解决办法是明确优先级比如“正确性 性能 代码简洁度”让它知道取舍时的顺序。5.3 规则漂移聊了几十轮后AI 开始不遵守早期规则这是一个我在实际使用中踩过比较深的坑。根源在于 WorkBuddy 的上下文窗口是有限的早期规则随对话增长逐渐失效。应对办法有两个一是在每个子任务开始时重贴精简版规则二是把核心规则写进 skill 并在关键节点触发加载。我个人推荐第二种长期使用更省心而且不会因为手动粘贴导致规则版本不一致。还能做的一个小操作给规则加上“版本号”。比如“全局规则 v1.1”这样当你改了规则内容时AI 能明确感知到这是更新而不是固守旧版。别小看这个细节它确实能减少不少“说了新版规则但 AI 继续按旧版执行”的尴尬。6. 我踩过的坑和你绕道走顺着上面的问题继续聊一点心得。最开始用 WorkBuddy 时我犯的最大错误是期望“一句话解决所有问题”。后来才发现真正适合这个工具的人是那些愿意把思考过程外显、把任务边界划清楚的人。提示词不是咒语它是一份“协作契约”——你越是清晰表达AI 越是稳定输出。另一个体会是不要把提示词当成一次性的要当成自己的“数字资产”来经营。我每完成一个阶段就把用得顺手的提示词整理进自己的模板库标注适用场景、已知局限、迭代记录。三个月下来这个库就成了我最值钱的生产力工具比收藏夹里几百条别人的“万能提示词”有用得多。最后分享一个我最近试出来的小技巧在给 WorkBuddy 布置大任务时第一步先不让它写任何代码只让它“描述完成这个任务需要经过的全部决策点”。这一步做完你会发现后面所有步骤都顺了因为它已经帮你在脑子里把路走了一遍。这和写代码前先写文档是同一个道理只不过现在有人能陪你一起想。