1. 为什么这5条提示词值得单独拎出来讲WorkBuddy 这类 AI 编程助手很多人装完就开始用结果发现输出质量忽高忽低——同一个需求有时候一遍过有时候来回改七八轮还是不对味。问题往往不在模型本身而在于你给它的指令够不够“结构化”。我用了大半年从最初随手打一句话到后来慢慢沉淀出一套固定模板中间踩的坑基本都集中在“提示词没写清楚”这件事上。这篇要聊的5条提示词是我日常用得最频繁、复用率最高的。它们分别对应五种典型场景新项目初始化、代码审查、Bug 定位、重构、以及文档生成。每一条都可以直接复制粘贴改掉方括号里的变量就能用。适合刚接触 WorkBuddy 的新手快速上手也适合已经用了一段时间但觉得输出不够稳定的朋友做参考。先说一个底层逻辑WorkBuddy 本质上是一个“带上下文的代码生成器”它的输出质量取决于你给它的约束条件有多明确。你给的信息越具体——技术栈、目录结构、命名规范、边界条件——它一次给对答案的概率就越高。下面这5条提示词核心思路都是“把模糊需求翻译成可执行的约束”。2. 第一条新项目脚手架生成提示词2.1 这条提示词解决什么问题新建项目时最烦的不是写业务代码而是搭架子——目录怎么分、配置文件放哪、依赖怎么装、lint 规则怎么定。如果直接跟 WorkBuddy 说“帮我建一个 React 项目”它给的结构往往太通用跟你团队的实际规范对不上。这条提示词的作用是把你脑子里的项目结构用文字描述清楚让 WorkBuddy 一次性生成可运行的骨架。2.2 提示词原文与使用说明我需要创建一个新项目请按以下约束生成完整的项目骨架 【技术栈】 - 语言/框架[例如 React 18 TypeScript] - 构建工具[例如 Vite] - 包管理器[例如 pnpm] - 样式方案[例如 Tailwind CSS] - 状态管理[例如 Zustand] 【目录结构要求】 - src/components/ 存放通用组件 - src/pages/ 存放页面级组件 - src/hooks/ 存放自定义 hooks - src/utils/ 存放工具函数 - src/types/ 存放全局类型定义 - src/api/ 存放接口请求封装 【编码规范】 - 所有组件使用函数式写法 hooks - 类型定义优先使用 interface联合类型用 type - 禁止使用 any必要时用 unknown 类型守卫 - 导入顺序第三方库 → 项目内模块 → 样式文件 【需要生成的文件】 1. package.json含所有依赖及 scripts 2. tsconfig.json严格模式 3. vite.config.ts 4. 上述目录结构及每个目录下的 .gitkeep 或示例文件 5. 一个示例页面展示组件、hooks、api 的调用方式 请直接输出每个文件的完整内容不要省略。2.3 为什么这样写有效关键在于最后那句“请直接输出每个文件的完整内容不要省略”。WorkBuddy 默认行为是“挑重点说”如果你不明确要求它可能只给你目录树和几个关键文件剩下的让你自己补。但搭架子这件事缺一个配置文件就跑不起来所以必须强制它输出完整内容。另外技术栈部分一定要写具体版本号。我试过只写“React”它给我生成了 class 组件写法写了“React 18 函数式组件”之后输出就完全对味了。版本号决定了 API 风格和语法特性这个信息不能省。2.4 实操心得如果你的项目需要接入内部组件库或私有 npm 源在提示词里加一句“依赖安装使用公司私有源地址为 [地址]”WorkBuddy 会在 package.json 里帮你配好 registry。生成完之后先跑一遍pnpm install和pnpm dev确认能启动再往里加业务代码。我遇到过生成的 vite.config.ts 里 alias 路径没配全的情况早发现早改。目录结构不用一次定死但第一版尽量贴近你团队的实际规范后面改起来成本低。3. 第二条代码审查与优化建议提示词3.1 这条提示词解决什么问题代码写完了想让人帮忙看看有没有问题但同事不一定有空。WorkBuddy 可以充当第一道审查关卡但它默认的审查太“客气”——只会说“整体不错建议关注性能”这种反馈没有实操价值。这条提示词的作用是强制 WorkBuddy 按固定维度逐项检查并给出可直接替换的修改代码。3.2 提示词原文与使用说明请对以下代码进行审查按以下维度逐项输出 【审查维度】 1. 类型安全是否存在 any、类型断言滥用、隐式 any 2. 边界条件空值、越界、并发、异常路径是否处理 3. 性能隐患不必要的重渲染、重复计算、内存泄漏风险 4. 可读性命名是否清晰、函数是否过长、嵌套是否过深 5. 安全性是否存在注入风险、敏感信息硬编码 【输出格式】 对每个维度 - 问题描述指出具体行号或代码片段 - 严重程度高/中/低 - 修改建议给出修改后的完整代码片段 【待审查代码】 [粘贴你的代码]3.3 为什么这样写有效“按维度逐项输出”这个约束很关键。不加的话WorkBuddy 会给你一段笼统的总结比如“代码整体质量较好建议增加错误处理”。加了维度约束之后它会逐条对照检查输出密度完全不一样。“给出修改后的完整代码片段”也很重要。只说“建议增加空值判断”没有用我需要看到具体怎么加。强制它输出修改后的代码等于让它把建议落地成可执行方案。3.4 实操心得审查维度可以根据项目特点调整。比如做的是金融类应用把“安全性”维度展开成“数值精度、并发一致性、审计日志”等子项。如果代码超过 200 行建议分段审查一次贴太多 WorkBuddy 会“偷懒”后面的部分审查质量明显下降。严重程度标注很有用我一般优先处理“高”级别的问题“低”级别的攒一批统一改。4. 第三条Bug 定位与修复提示词4.1 这条提示词解决什么问题遇到 Bug 时最怕的是“猜”。东改一下西改一下问题没解决反而引入新问题。这条提示词的作用是让 WorkBuddy 按“复现→定位→根因→修复→验证”的流程走一遍把排查过程结构化。4.2 提示词原文与使用说明我遇到一个 Bug请按以下流程帮我定位和修复 【Bug 现象】 - 期望行为[描述期望结果] - 实际行为[描述实际结果] - 复现步骤[1. xxx 2. xxx 3. xxx] - 报错信息[粘贴完整报错栈] 【相关代码】 [粘贴相关代码文件] 【环境信息】 - 运行环境[例如 Node 18 Chrome 120] - 相关依赖版本[例如 React 18.2.0] 【要求】 1. 先分析可能的根因按可能性从高到低排列每条根因说明判断依据 2. 针对最可能的根因给出修复方案和修改后的代码 3. 说明如何验证修复是否生效 4. 指出这个 Bug 是否可能在其他地方也存在类似问题4.3 为什么这样写有效“按可能性从高到低排列每条根因说明判断依据”这一句是这条提示词的核心价值。没有它WorkBuddy 可能直接给你一个修复方案但你不确定它是不是真的找到了根因。有了这个约束它会先做推理再给方案你能看到它的思考路径判断是否合理。“指出这个 Bug 是否可能在其他地方也存在类似问题”是加分项。很多 Bug 不是孤立的比如一个空值处理遗漏可能在十几个地方都有同样的问题。让 WorkBuddy 帮你扫一遍能省不少事。4.4 实操心得报错栈一定要贴完整的不要只贴最后一行。WorkBuddy 需要从调用链判断问题出在哪一层。如果 Bug 跟特定数据有关把触发问题的数据样本也贴上脱敏后。我遇到过一个问题只有某个特定字段为空时才复现贴了数据样本之后 WorkBuddy 秒定位。修复方案出来后先在小范围验证确认没问题再全量应用。AI 给的修复方案大部分时候是对的但偶尔会有“修了一个问题引入另一个问题”的情况。5. 第四条代码重构提示词5.1 这条提示词解决什么问题代码能跑但看着难受——函数太长、嵌套太深、重复逻辑到处都是。想重构又怕改出问题。这条提示词的作用是让 WorkBuddy 在保持功能不变的前提下按你指定的重构目标输出新代码并说明每处改动的理由。5.2 提示词原文与使用说明请对以下代码进行重构重构目标如下 【重构目标】可多选 - [ ] 拆分过长函数单个函数不超过 50 行 - [ ] 消除重复逻辑提取公共函数或 hooks - [ ] 降低嵌套深度不超过 3 层 - [ ] 改善命名变量、函数、类型 - [ ] 提取魔法数字为常量 - [ ] 其他[自定义目标] 【约束条件】 - 不改变现有功能和行为 - 不改变对外暴露的接口签名 - 保持现有测试用例通过 【输出要求】 1. 重构后的完整代码 2. 逐条说明每处改动对应的重构目标和理由 3. 指出重构后可能需要注意的风险点 【待重构代码】 [粘贴你的代码]5.3 为什么这样写有效“不改变现有功能和行为”和“不改变对外暴露的接口签名”这两条约束是重构的安全带。没有它们WorkBuddy 可能会“顺手”帮你改掉一些它认为不合理的接口设计导致调用方全部报错。“逐条说明每处改动对应的重构目标和理由”这一条让你能审查它的重构是否真的达成了目标。比如你选了“拆分过长函数”它输出之后你可以对照检查原来 200 行的函数是不是真的拆成了几个 50 行以内的函数。5.4 实操心得重构前先确保有测试覆盖。没有测试的话至少手动跑一遍核心流程记录下正常行为重构后对照验证。一次只选 2-3 个重构目标选太多 WorkBuddy 会顾此失彼。我一般分多轮进行第一轮拆函数第二轮消重复第三轮改命名。重构后的代码不要直接合并先跑一遍完整测试再 code review 一遍。AI 重构偶尔会漏掉一些边界条件尤其是异常处理路径。6. 第五条自动化文档生成提示词6.1 这条提示词解决什么问题代码写完了文档没人写。README 过时了API 文档对不上新人接手一脸懵。这条提示词的作用是让 WorkBuddy 根据代码自动生成结构化文档包括 README、API 说明、以及关键模块的设计说明。6.2 提示词原文与使用说明请根据以下代码生成项目文档包含三部分 【第一部分README】 - 项目简介一句话说明项目做什么 - 环境要求Node 版本、包管理器等 - 安装步骤 - 启动命令开发、构建、测试 - 目录结构说明 【第二部分API 文档】 对每个导出的函数/组件 - 名称和签名 - 参数说明类型、是否必填、默认值、说明 - 返回值说明 - 使用示例 【第三部分关键模块设计说明】 - 模块职责 - 核心流程用文字描述不要用图表 - 依赖关系 - 扩展点 【代码文件】 [粘贴相关代码文件]6.3 为什么这样写有效“用文字描述不要用图表”这一条是专门加的。WorkBuddy 默认喜欢生成 Mermaid 流程图但很多平台的 Markdown 渲染不支持或者渲染出来很丑。强制用文字描述文档的可移植性更好。“对每个导出的函数/组件”这个约束确保 API 文档的覆盖率。不加的话它可能只挑几个重要的写剩下的略过。加了之后它会逐个扫描导出项一个不漏。6.4 实操心得生成的文档不要直接发布先人工过一遍。WorkBuddy 有时候会把内部实现细节写进 API 文档这些不应该暴露给使用者。README 的“目录结构说明”部分建议手动补充每个目录的用途AI 只能根据文件名猜不一定准。如果项目有多个模块建议分模块生成文档最后再合并。一次贴太多代码文档质量会下降。7. 这5条提示词的通用设计原则7.1 约束比描述更重要回头看这5条提示词有一个共同点约束条件占了很大篇幅。技术栈要写具体版本目录结构要列清楚输出格式要指定边界条件要说明。这些约束看起来繁琐但正是它们让 WorkBuddy 的输出从“差不多能用”变成“直接能用”。我刚开始用的时候提示词写得很随意比如“帮我写个登录页面”。WorkBuddy 给了一个能跑的版本但样式方案不是我想要的表单验证逻辑也不符合项目规范改起来跟自己写差不多。后来我把提示词改成“用 React Hook Form Zod 做表单验证样式用 Tailwind错误提示用 toast登录成功后跳转到 /dashboard”一次就对了。7.2 输出格式要显式指定WorkBuddy 默认的输出格式是“解释 代码片段”但很多时候我只想要代码不想要解释。或者反过来我想要详细的推理过程。这时候就需要在提示词里明确说“直接输出代码不要解释”或者“先分析再给方案”。上面5条提示词里每一条都指定了输出格式。比如代码审查那条要求“按维度逐项输出”Bug 定位那条要求“按可能性从高到低排列”。这些格式约束让输出更结构化也更容易审查。7.3 让 WorkBuddy 自己检查一个很实用的技巧在提示词末尾加一句“输出前请自行检查是否满足上述所有约束”。WorkBuddy 会在生成过程中做一次自检遗漏约束的概率明显降低。我实测下来加了这句话之后输出完整度大概能提升两三成。7.4 提示词要迭代这5条提示词不是一次写成的每一条都经过了好几轮调整。比如代码审查那条最初没有“严重程度”标注后来发现没有优先级排序改起来没有重点才加上了高/中/低的标注。Bug 定位那条最初没有“指出是否可能在其他地方也存在类似问题”后来发现很多 Bug 是批量出现的才加上了这个要求。建议你把这5条提示词存成一个模板文件每次用的时候复制出来改改变量。用一段时间之后根据实际效果再调整。提示词这东西没有“最好”只有“最适合你当前项目”。8. 几个容易踩的坑8.1 不要一次给太多任务我试过在一条提示词里同时要求“生成代码 写测试 生成文档”结果三样都做得马马虎虎。WorkBuddy 的注意力是有限的任务越多每个任务分到的“精力”越少。后来我改成一次只做一件事做完再开新对话做下一件质量明显提升。8.2 上下文要控制长度WorkBuddy 有上下文窗口限制贴太多代码进去它会“忘记”前面的内容。我的经验是单次对话的代码量控制在 300 行以内超过就分段处理。如果必须处理大文件先让它生成一个“处理计划”然后按计划分步执行。8.3 不要完全信任输出AI 生成的代码我一般会重点检查这几个地方边界条件处理、错误处理路径、类型定义是否准确、是否有硬编码的敏感信息。这几个地方是 AI 最容易出问题的地方。尤其是错误处理AI 倾向于“乐观路径”异常情况经常被忽略。8.4 版本兼容性要自己确认WorkBuddy 的训练数据有截止日期它给的依赖版本可能不是最新的也可能跟你项目里其他依赖不兼容。生成 package.json 之后我一般会手动检查一遍版本号确认没有已知的冲突。9. 怎么把这5条提示词变成自己的直接复制粘贴能用但效果最好的方式是根据自己的项目特点做定制。我的做法是建一个prompts目录里面放5个 Markdown 文件每个文件对应一条提示词。文件里把固定部分写好变量部分用[方括号]标注。用的时候复制出来替换变量粘贴到 WorkBuddy 里。另外我会在每条提示词后面附一个“本次调整记录”比如“2024-01-15增加了对 React Server Components 的支持”。这样过一段时间回头看能知道这条提示词是怎么演化过来的也方便团队其他成员参考。如果你团队里有多个人用 WorkBuddy建议把这5条提示词放到共享文档里大家用同一套模板。这样输出的代码风格更一致review 起来也省事。我们团队用了这个方式之后代码规范相关的 review 意见少了大概一半。最后分享一个我最近在用的技巧把 WorkBuddy 的输出直接喂给另一个 AI 做二次审查。比如让它生成代码之后把代码贴给另一个对话问“这段代码有什么问题”。两个 AI 互相检查能发现不少单次生成遗漏的问题。这个方式有点“左右互搏”的意思但实测下来确实能提升最终代码的质量。