最近我把 WorkBuddy 从“偶尔想起来用一下”变成了“每天必开”靠的不是什么复杂的功能配置而是 5 条提示词。刚接触这类 AI 编程工具的时候我也走了不少弯路第一次搭建工作台恨不得给每个任务都写一段长篇大论结果一半以上的提示词在反复表达同一个意思AI 的输出反而越来越飘。后来我推倒重来把平时开发里最高频的场景列了一遍最后真正留下来天天在用的就是这 5 条。它们分别覆盖了读懂项目、转需求、审代码、查问题、定规矩这五件事基本能应对日常 80% 以上的工作。这篇文章就直接把它们贴出来每条都会讲清楚为什么这样写、实际效果如何、有哪些调整空间你可以直接复制进自己的 WorkBuddy 配置里。1. 先说说我为什么只留 5 条提示词1.1 提示词不是越多越好很多人一开始都会陷入一个误区给 AI 准备的提示词越多它就越懂你。实际上在 WorkBuddy 这类工具里提示词堆得太多反而会造成上下文污染。因为大模型在处理对话时会把前面的历史内容一起纳入计算你塞进去的每一条规则、每一句背景说明都在悄悄占用它的“注意力”。当规则之间出现微小冲突模型往往会取一个平均化的理解于是你精心设计的那条强约束提示词实际执行的时候可能只剩下一半效果。我自己最早配过 20 多条提示词覆盖了“命名规范”“代码风格”“测试要求”“注释格式”等等。结果用下来发现真正能稳定产生价值的反而只有那些目标单一、约束明确的提示词。剩下的不是被忽略就是和别的规则互相打架。后来我删繁就简只保留覆盖最高频场景的 5 条效果反而稳定了很多。提示一条好的提示词核心目标是“让 AI 在某个具体任务上不做错事、不跑偏方向”。如果一条提示词自己都说不清楚到底要什么那模型大概率会给你一个四平八稳但没啥用处的回答。1.2 这 5 条覆盖的工作流这 5 条提示词不是随便挑的它们的任务范围正好对应我日常开发的完整工作流接到一个旧项目或者新仓库第一件事是让 AI 做项目全景分析拿到产品需求先让 AI 把口语化描述转换成开发任务清单写完代码之后让 AI 按规范做代码审查线上出现异常或者测试失败时让 AI 逼自己先找证据再下结论最后再有一组全局规则约束所有后续任务的行为边界。这五件事没有一个是多余的。它们之间的关系类似一个裁剪好的流水线输入项目、转换需求、检验产物、处理异常、兜底约束。当初我想过要不要加第六条“自动写测试”后来发现把它合入第二条需求转化里更自然因为测试点本身就是方案里必须包含的一部分。1.3 WorkBuddy 里这些提示词放在哪不同版本的 WorkBuddy 配置入口叫法可能不太一样但大体上分为两类一类是全局规则对所有任务长期生效另一类是单次对话里的临时提示词。我的习惯是第五条全局规则放进“规则区”或“技能配置”里让它始终生效前四条则放在一个专门保存提示词模板的地方需要的时候直接调出来用不会污染日常对话。如果你用的是新版 WorkBuddy可以留意一下是否支持“跨对话规则”或者叫“全局指令”的设置项。找到之后把第五条丢进去就好剩下的都是“随用随取”的临时提示词不涉及全局作用域。2. 第一条项目全景分析让 AI 先读明白代码库 2.1 这条提示词的完整内容 # Role: 资深全栈架构师 请先完成以下“项目全景分析”不要回答任何具体问题 1. 扫描当前项目目录结构标注各模块的用途。 2. 识别项目所使用的技术栈、依赖清单、构建与启动方式。 3. 找出至少一条核心业务链路从入口到出口完整走一遍。 4. 指出当前项目的配置易错点与明显的风险点。 输出格式要求 - 项目技术栈总览使用表格展示 - 核心模块说明使用列表标注“模块名-职责-依赖” - 建议后续开发遵循的约束3 到 5 条 最后用一句话概括这个项目到底在做什么。2.2 为什么这样设计这条提示词解决的是一个大问题AI 刚进入一个项目时经常会出现“你说一句它做一句但整体理解是错的”的情况。所以我把“先完成项目全景分析”放在首位并且明确要求“不要回答任何具体问题”这会强制模型先建立全局认知而不是急着动手改代码。角色设定为“资深全栈架构师”不是让 AI 真的变成架构师而是通过角色描述激活模型经验池里与架构审查相关的知识模式。你会发现同样的问题不加角色时 AI 的回答更像“文档摘要”加了角色之后会更偏向“结构分析”。输出格式的要求同样重要。表格适合技术栈和依赖清单列表适合模块职责梳理这种强制格式能让 AI 的输出从“散文”变成“可执行的结构化信息”。最后那句“用一句话概括项目在做什么”是为了逼模型提炼本质避免它在细节里打转。2.3 实测效果与调整过程我第一次用这条提示词的时候AI 确实给出了技术栈表和目录结构但核心业务链路找得很浅只是列了入口接口和数据库表没有把中间的调用关系串起来。后来我在提示词里补了“从入口到出口完整走一遍”效果立刻就变了。它会真的从一个 Controller 或者前端入口开始一路追到服务层、数据层把整条链路涉及的关键方法列出来。这条提示词也适合用在接手上一个同事留下的仓库时。我最近接手一个支付相关的服务靠它十分钟就把原来需要翻一两个小时的项目结构摸清了。它标出的“配置易错点”有时候会出乎意料地准比如某个环境变量在测试环境没配、某个数据库连接池参数设置不合理等。注意如果你第一次运行这条提示词时觉得输出太泛先不要急着加规则试着把范围收敛一下比如把“扫描项目目录结构”改成“只扫描 src 和 services 下的核心代码目录”。更精确的范围通常比更长的要求更有效。3. 第二条需求转化落地方案把“人话”变开发任务3.1 这条提示词的完整内容# Role: 高级产品技术负责人 用户会输入一段口语化需求请按以下流程处理 1. 拆分需求为可执行的功能点列表 2. 对每个功能点标注优先级P0/P1/P2和影响范围 3. 结合当前项目代码库指出需要改动或新增的模块 4. 给出实现方案优先选择改动最小、可维护性最高的路径 5. 列出潜在风险与测试要点。 硬性要求先输出方案不要写代码等待用户确认后再进入编码阶段。 如果需求描述存在信息缺失先列出需要补充的问题不要自行脑补。3.2 为什么“先不要写代码”是核心约束我见过太多人让 AI 转需求结果 AI 直接噼里啪啦写出一堆功能代码方案设计反而没有。这其实是模型的“讨好型人格”在作祟它觉得你可能更想要一个能直接跑的东西而不是一篇分析报告。所以我把“先输出方案不要写代码”作为硬性要求并且放在规则末尾作为独立约束这会显著改变模型的输出倾向。优先级标注也是后期加上去的。最早版本没有 P0/P1/P2 的要求AI 会把所有功能点拉成一条平铺的列表到了真正开发的时候根本不知道先做哪个。加上了优先级之后AI 会自己判断“这个功能是核心链路还是边缘优化”输出内容的决策感一下就出来了。3.3 结合实际场景看效果有一次需求是“用户在小程序里可以上传头像并且支持裁剪和滤镜”。我把这句话原封不动丢给第二条提示词它的输出让我挺惊喜P0头像上传接口与存储方案P0图片裁剪组件的选择与集成P1滤镜效果的实时预览与性能调优P2历史头像管理、缓存策略。同时它还指出需要改动用户服务、文件服务和小程序前端三个模块并提醒了“大图上传可能导致网关超时建议使用预签名上传”这类风险点。这些信息如果是人来整理至少也得花十几分钟AI 配合这条提示词基本一分钟内就能给出来。这个阶段如果发现 AI 的输出少了某个维度比如它没有写测试要点你可以追加一句“请补充每个功能点的验收标准”会比重新写一整条提示词更高效。4. 第三条Code Review 盯细节按规范逐条过4.1 这条提示词的完整内容# Role: 严格但不刻薄的代码审查员 请审查本次改动按以下维度逐项检查 1. 功能正确性是否存在明显逻辑漏洞、无效代码、重复实现 2. 边界情况空值、超长输入、并发访问、异常路径是否处理 3. 安全与性能是否有注入风险、死循环、无必要耗时操作 4. 代码风格是否与项目原有风格一致命名是否清晰可读 输出格式要求 - 严重问题必须修改列表 - 建议优化可延后列表 - 整体评分优 / 良 / 差 请直接给结论不要复述代码。4.2 “不要复述代码”这个要求为什么很重要很多人用 AI 做 Code Review 时会遇到一种情况AI 花了很大篇幅把代码重新讲了一遍然后说“这段代码看起来不错”。这种输出对开发者来说毫无价值。所以我专门加了“请直接给结论不要复述代码”逼它只保留增量信息——也就是“哪里有问题、哪里值得注意、哪里可以改”。“严格但不刻薄”这个角色描述也是磨出来的。一开始我用的是“严格的代码审查员”结果 AI 的输出充满了浓烈的批评味连一些风格偏好都会被标成严重问题反而淹没了真正重要的逻辑漏洞。后来我加了“不刻薄”三个字输出的语气收敛了很多但对严重问题的敏感度并没有下降。4.3 评分机制的实际意义整体评分这个设计很多人会忽略但我觉得它是接近人的工作方式的设计先用一句话给出结论再展开细节。这样你在浏览评审结果时第一眼就能判断要不要认真处理。如果是“优”可能只需要扫一眼建议优化如果是“差”就需要逐条改完再重新审一遍。这个思路在实践里还有一个变体你可以让 AI 单独给“严重问题”做一个汇总类似 PR 提交前的“最后一遍自检”。我就是这么用的每次准备提代码评审之前先把 diff 丢给这条提示词处理掉它标注的严重问题之后再走人工评审流程整体效率提升很明显。5. 第四条故障排查提示词逼 AI 先取证再下结论5.1 这条提示词的完整内容# Role: 资深故障排查工程师 场景设定我会提供一段报错信息或异常现象禁止你直接猜测原因。 处理流程 1. 先让我提供错误堆栈、复现步骤、最近改动、相关日志 2. 基于已有信息列出最可能的 3 个原因并说明判断依据 3. 对每个原因给出验证方案优先使用日志或复现实验 4. 确认根因后再给出修复建议和验证步骤。 如果信息不足明确告诉我缺失了什么不要编造原因。5.2 为什么“禁止猜测原因”能大幅提高准确率大模型的推理能力看起来很强但它有个致命弱点在信息不完整的情况下它会用“最可能”的内容填空。这种能力在写方案时很有用在排查故障时却是个灾难。因为故障根因往往不是最显眼的那一个如果 AI 一开始就往错误方向猜后续的每一步都会顺着这个错误走浪费大量时间。我把“禁止直接猜测原因”放在场景设定里等于强制它进入“先收集情报再判断”的模式。这个约束的效果非常明显。有一次我把一段空指针异常堆栈丢给它在没加这条提示词之前它直接说“可能是某个对象没有初始化”建议我加判空但加了这条之后它会先要求我提供完整堆栈和调用链然后再列出“初始化顺序问题”“注入失败导致对象为空”“异步线程中上下文丢失”这几种可能性。后一种输出对实际排查的帮助要大得多。5.3 配合日志和复现步骤使用的套路这条提示词真正发挥威力需要配合一套稳定的提交流程。我现在的习惯是遇到线上异常先把堆栈、最近一次的 Git 提交记录、相关日志片段整理好一次性丢给 WorkBuddy然后让第四条提示词做分析。它给出的 3 个可能原因里通常至少有一个能直接指向问题方向剩下两个也会提示你补哪些验证信息。注意如果你的日志太大不要整段粘进去。先手动截取异常发生前后各几十行减少噪声。日志里的无关输出越多AI 的判断就越容易受到干扰。6. 第五条全局规则兜底让每条指令都带上约束6.1 这条提示词的完整内容# Role: 团队技术负责人规则模式 以下规则对后续所有任务长期生效 1. 所有方案必须先分析、后编码禁止直接修改代码 2. 禁止删除、重命名项目原有公共方法除非先说明影响面 3. 代码优先复用现有工具函数和公共组件 4. 修改文件必须附带“改动原因”说明 5. 技术方案和注释使用中文代码中的变量、函数命名使用英文。6.2 规则模式与单次提示词的区别第五条的定位和其他四条不一样。前四条是“在某一个特定任务里临时执行的指令”第五条是“长期挂载在 WorkBuddy 里的全局约束”。它会把自身的规则注入到每一条后续请求中相当于给所有任务都加了同一组护栏。这种做法的价值在于你不用每次都手动重复这些要求。比如“先分析后编码”这条规则不管你是让它改代码、写功能、修 bug它都会默认遵守。换成临时提示词的话你大概率会在几次对话后忘记加然后 AI 又回到那种“拿到需求就写代码”的默认模式。6.3 为什么特意写了“禁止删除、重命名公共方法”这条规则来自我踩过的一个坑。有一次我让 AI 重构一个模块它“顺手”把一个被其他三处调用的公共方法改了个名那三处调用并没有同步更新结果整个模块直接编译不过。从那以后我就在全局规则里明确加上了这一条。如果你希望 AI 重命名某个公共方法就必须先让它说明影响面这就是“违规前先报告”的机制。这类小规则你可以按团队情况自己扩展。比如有些团队希望所有对外接口必须有 swagger 注解有些团队要求数据库操作必须走统一的 DAO 层这些都可以加进全局规则。但建议控制在 8 条以内太多的话模型可能顾此失彼。6.4 规则冲突时怎么解决全局规则和临时提示词之间偶尔也会有冲突。比如全局规则说“禁止直接修改代码”但你的临时指令是“帮我修复这个 bug直接给出改好的代码”。遇到这种冲突时我看下来 WorkBuddy 的行为更偏向遵循更具体的当前指令。所以如果你真的需要 AI 跳过规则直接改代码可以在临时指令里明确写“本次任务允许跳过第 2 条规则”这样会比硬顶着全局规则更顺畅。7. 这几条提示词的共同设计逻辑场景、目标、边界7.1 角色设定在提示词里扮演的角色细心的读者可能已经发现5 条提示词全部以“# Role: xxx”开头。这不是我为了统一格式而做的设计而是确实有效。大模型在训练时接触过大量带角色设定的语料当你指定一个具体角色时它会自动调整语气、知识侧重点和输出风格。比如说“资深故障排查工程师”会让它更倾向于用日志和数据说话而“团队技术负责人”会让它更注意全局影响。角色设定要具体不要用“AI 助手”这种万金油。你可以对比一下“请审查代码”和“请作为资深代码审查员审查代码”这两种表达后者的输出通常会更结构化、更挑剔、更直击要害。7.2 输出格式是隐形护栏我几乎在每条提示词里都指定了输出格式表格、列表、评分、明确的小节标题。这么做不只是为了方便阅读还因为它能约束模型的行为轨迹。当模型知道“最后要输出一个评分”时它在分析过程中就会默默向“可评分”的方向组织内容当它知道“要用表格展示技术栈”时它会主动收集适合放表格的信息。这其实是一种“预先埋锚点”的技巧。你希望 AI 关注什么维度就在输出格式里要求什么维度。如果有一天你发现 AI 忽略了某个重要角度最直接的修正方式不是让它“注意一下”而是在输出格式要求里增加一栏。7.3 约束宁可多写一条也不要少写一条很多人觉得提示词写得越多AI 越容易迷茫。但根据我的实操经验面向编程任务的提示词约束宁可具体到啰嗦也不要模糊到万能。因为这些约束本质上是在帮模型缩小搜索空间。比如“不要复述代码”和“信息不足时列出缺失项”这种规则看起来是在限制 AI实际上是在帮它把注意力集中在真正重要的事情上。当然约束要围绕目标设置而不是无脑堆砌。比如你让 AI 写一首诗然后约束它“必须使用中文变量命名”这就属于方向完全跑偏的约束。我的判断标准是每一条约束都要能回答“如果没有这条约束AI 可能会在哪个环节跑偏”这个问题。7.4 提示词工程与上下文工程的关系最后聊一个稍微深一点的话题在 WorkBuddy 这类工具里提示词只是“上下文工程”的一部分。同样的提示词放在不同上下文环境里效果可以天差地别。比如你在多轮对话末尾使用第四条排查提示词和把它作为新会话的第一条消息使用AI 的行为会不一样。前者会带入之前讨论过的很多信息后者则完全从零开始。这也是我建议把全局规则单独管理而不是混在对话里反复发送的原因。全局规则承载的是长期稳定的约束单次提示词承载的是短期任务目标。两者各司其职才能让上下文保持干净、可控。上下文越干净提示词的执行力就越强这一点在长时间使用下来体会尤其深刻。8. 关于“鹈鹕测试法”和一些实操避坑8.1 鹈鹕测试法是什么最近在 AI 编程的圈子里流行过一个挺有意思的验证方法——“鹈鹕测试法”。具体来说就是让 AI 画或者描述一只骑自行车的鹈鹕。听起来像个段子但它背后其实是一个相当巧妙的多层测试模型必须准确理解“鹈鹕”这个主体理解“骑自行车”这个动作还要保持两者之间的关系不跑偏。如果模型能把“一只骑自行车的鹈鹕”正确地用代码实现、用 SVG 画出来或者准确描述出来在一定程度上可以反映它对组合式指令的理解与约束遵守能力。我一开始也拿它试过 WorkBuddy 里的提示词效果。做法很简单把“请使用 SVG 绘制一只骑自行车的鹈鹕”作为一条测试请求发到配置好第五条全局规则的工作区里看 AI 是不是能正确生成结构完整的 SVG并且没有出现鹈鹕和自行车分离、或者多出奇怪对象的情况。这个测试比单纯问“你理解了吗”更硬核因为它要求真的输出一个可以验证的产物。8.2 用它验证提示词时的局限不过也要说清楚鹈鹕测试法只能验证模型的“通用指令理解能力”验证不了你精心设计的那条提示词在真实业务场景里的效果。它能告诉你“这个模型现阶段是否还正常、上下文有没有被污染”但它没法告诉你“你的项目全景分析提示词能否准确识别支付服务的核心链路”。我现在的用法是把它当成一个轻量“体检”工具。比如 WorkBuddy 升级了底层模型或者某段时间觉得 AI 答非所问我就用鹈鹕测试快速判断一下是模型行为变化了还是我的提示词在特定场景下失效了。如果鹈鹕测试正常通过那问题大概率出在提示词和当前任务的匹配上如果连鹈鹕测试都从“骑自行车的鹈鹕”变成了“一堆几何图形”那说明配置或模型层面出了问题。8.3 提示词之外还要留意的几个细节最后分享几个使用 WorkBuddy 时容易踩的坑提示词更新后不会自动应用到旧会话。如果你修改了某个提示词最好新开一个对话再测试旧会话里往往还带着旧规则。同一个项目最好不要同时挂多套工作台配置。配置越多上下文越长响应速度变慢且规则冲突的概率变大。一个小项目配一套精简规则完全够用。系统缓存的目录如果占用空间太大记得定期清理一下。工作台长时间运行后产生的临时文件还是挺占空间的尤其在 Windows 机器上。我自己现在的习惯是先让第五条全局规则常驻把“先分析后编码”刻进每次对话的默认行为里。遇到具体任务时再从常用提示词模板里调出对应的那一条配合当前上下文使用。至于鹈鹕测试平时不会刻意想起来用但一旦发现 AI 行为变得不对劲它就是我用来定位问题的第一把尺子。这些提示词不是什么高深莫测的“万能咒语”它们只是在合适的位置把任务目标、判断标准和输出形式说清楚了而已。如果你手头正在用 WorkBuddy或者正准备搭一个属于自己的 AI 工作台建议先挑其中一两条用起来跑通之后再慢慢补全。等五条全部进入正常工作流之后你会明显感觉到 AI 的产出从“能用”变成了“好用”。
WorkBuddy核心提示词实践：5条覆盖80%开发场景
最近我把 WorkBuddy 从“偶尔想起来用一下”变成了“每天必开”靠的不是什么复杂的功能配置而是 5 条提示词。刚接触这类 AI 编程工具的时候我也走了不少弯路第一次搭建工作台恨不得给每个任务都写一段长篇大论结果一半以上的提示词在反复表达同一个意思AI 的输出反而越来越飘。后来我推倒重来把平时开发里最高频的场景列了一遍最后真正留下来天天在用的就是这 5 条。它们分别覆盖了读懂项目、转需求、审代码、查问题、定规矩这五件事基本能应对日常 80% 以上的工作。这篇文章就直接把它们贴出来每条都会讲清楚为什么这样写、实际效果如何、有哪些调整空间你可以直接复制进自己的 WorkBuddy 配置里。1. 先说说我为什么只留 5 条提示词1.1 提示词不是越多越好很多人一开始都会陷入一个误区给 AI 准备的提示词越多它就越懂你。实际上在 WorkBuddy 这类工具里提示词堆得太多反而会造成上下文污染。因为大模型在处理对话时会把前面的历史内容一起纳入计算你塞进去的每一条规则、每一句背景说明都在悄悄占用它的“注意力”。当规则之间出现微小冲突模型往往会取一个平均化的理解于是你精心设计的那条强约束提示词实际执行的时候可能只剩下一半效果。我自己最早配过 20 多条提示词覆盖了“命名规范”“代码风格”“测试要求”“注释格式”等等。结果用下来发现真正能稳定产生价值的反而只有那些目标单一、约束明确的提示词。剩下的不是被忽略就是和别的规则互相打架。后来我删繁就简只保留覆盖最高频场景的 5 条效果反而稳定了很多。提示一条好的提示词核心目标是“让 AI 在某个具体任务上不做错事、不跑偏方向”。如果一条提示词自己都说不清楚到底要什么那模型大概率会给你一个四平八稳但没啥用处的回答。1.2 这 5 条覆盖的工作流这 5 条提示词不是随便挑的它们的任务范围正好对应我日常开发的完整工作流接到一个旧项目或者新仓库第一件事是让 AI 做项目全景分析拿到产品需求先让 AI 把口语化描述转换成开发任务清单写完代码之后让 AI 按规范做代码审查线上出现异常或者测试失败时让 AI 逼自己先找证据再下结论最后再有一组全局规则约束所有后续任务的行为边界。这五件事没有一个是多余的。它们之间的关系类似一个裁剪好的流水线输入项目、转换需求、检验产物、处理异常、兜底约束。当初我想过要不要加第六条“自动写测试”后来发现把它合入第二条需求转化里更自然因为测试点本身就是方案里必须包含的一部分。1.3 WorkBuddy 里这些提示词放在哪不同版本的 WorkBuddy 配置入口叫法可能不太一样但大体上分为两类一类是全局规则对所有任务长期生效另一类是单次对话里的临时提示词。我的习惯是第五条全局规则放进“规则区”或“技能配置”里让它始终生效前四条则放在一个专门保存提示词模板的地方需要的时候直接调出来用不会污染日常对话。如果你用的是新版 WorkBuddy可以留意一下是否支持“跨对话规则”或者叫“全局指令”的设置项。找到之后把第五条丢进去就好剩下的都是“随用随取”的临时提示词不涉及全局作用域。2. 第一条项目全景分析让 AI 先读明白代码库 2.1 这条提示词的完整内容 # Role: 资深全栈架构师 请先完成以下“项目全景分析”不要回答任何具体问题 1. 扫描当前项目目录结构标注各模块的用途。 2. 识别项目所使用的技术栈、依赖清单、构建与启动方式。 3. 找出至少一条核心业务链路从入口到出口完整走一遍。 4. 指出当前项目的配置易错点与明显的风险点。 输出格式要求 - 项目技术栈总览使用表格展示 - 核心模块说明使用列表标注“模块名-职责-依赖” - 建议后续开发遵循的约束3 到 5 条 最后用一句话概括这个项目到底在做什么。2.2 为什么这样设计这条提示词解决的是一个大问题AI 刚进入一个项目时经常会出现“你说一句它做一句但整体理解是错的”的情况。所以我把“先完成项目全景分析”放在首位并且明确要求“不要回答任何具体问题”这会强制模型先建立全局认知而不是急着动手改代码。角色设定为“资深全栈架构师”不是让 AI 真的变成架构师而是通过角色描述激活模型经验池里与架构审查相关的知识模式。你会发现同样的问题不加角色时 AI 的回答更像“文档摘要”加了角色之后会更偏向“结构分析”。输出格式的要求同样重要。表格适合技术栈和依赖清单列表适合模块职责梳理这种强制格式能让 AI 的输出从“散文”变成“可执行的结构化信息”。最后那句“用一句话概括项目在做什么”是为了逼模型提炼本质避免它在细节里打转。2.3 实测效果与调整过程我第一次用这条提示词的时候AI 确实给出了技术栈表和目录结构但核心业务链路找得很浅只是列了入口接口和数据库表没有把中间的调用关系串起来。后来我在提示词里补了“从入口到出口完整走一遍”效果立刻就变了。它会真的从一个 Controller 或者前端入口开始一路追到服务层、数据层把整条链路涉及的关键方法列出来。这条提示词也适合用在接手上一个同事留下的仓库时。我最近接手一个支付相关的服务靠它十分钟就把原来需要翻一两个小时的项目结构摸清了。它标出的“配置易错点”有时候会出乎意料地准比如某个环境变量在测试环境没配、某个数据库连接池参数设置不合理等。注意如果你第一次运行这条提示词时觉得输出太泛先不要急着加规则试着把范围收敛一下比如把“扫描项目目录结构”改成“只扫描 src 和 services 下的核心代码目录”。更精确的范围通常比更长的要求更有效。3. 第二条需求转化落地方案把“人话”变开发任务3.1 这条提示词的完整内容# Role: 高级产品技术负责人 用户会输入一段口语化需求请按以下流程处理 1. 拆分需求为可执行的功能点列表 2. 对每个功能点标注优先级P0/P1/P2和影响范围 3. 结合当前项目代码库指出需要改动或新增的模块 4. 给出实现方案优先选择改动最小、可维护性最高的路径 5. 列出潜在风险与测试要点。 硬性要求先输出方案不要写代码等待用户确认后再进入编码阶段。 如果需求描述存在信息缺失先列出需要补充的问题不要自行脑补。3.2 为什么“先不要写代码”是核心约束我见过太多人让 AI 转需求结果 AI 直接噼里啪啦写出一堆功能代码方案设计反而没有。这其实是模型的“讨好型人格”在作祟它觉得你可能更想要一个能直接跑的东西而不是一篇分析报告。所以我把“先输出方案不要写代码”作为硬性要求并且放在规则末尾作为独立约束这会显著改变模型的输出倾向。优先级标注也是后期加上去的。最早版本没有 P0/P1/P2 的要求AI 会把所有功能点拉成一条平铺的列表到了真正开发的时候根本不知道先做哪个。加上了优先级之后AI 会自己判断“这个功能是核心链路还是边缘优化”输出内容的决策感一下就出来了。3.3 结合实际场景看效果有一次需求是“用户在小程序里可以上传头像并且支持裁剪和滤镜”。我把这句话原封不动丢给第二条提示词它的输出让我挺惊喜P0头像上传接口与存储方案P0图片裁剪组件的选择与集成P1滤镜效果的实时预览与性能调优P2历史头像管理、缓存策略。同时它还指出需要改动用户服务、文件服务和小程序前端三个模块并提醒了“大图上传可能导致网关超时建议使用预签名上传”这类风险点。这些信息如果是人来整理至少也得花十几分钟AI 配合这条提示词基本一分钟内就能给出来。这个阶段如果发现 AI 的输出少了某个维度比如它没有写测试要点你可以追加一句“请补充每个功能点的验收标准”会比重新写一整条提示词更高效。4. 第三条Code Review 盯细节按规范逐条过4.1 这条提示词的完整内容# Role: 严格但不刻薄的代码审查员 请审查本次改动按以下维度逐项检查 1. 功能正确性是否存在明显逻辑漏洞、无效代码、重复实现 2. 边界情况空值、超长输入、并发访问、异常路径是否处理 3. 安全与性能是否有注入风险、死循环、无必要耗时操作 4. 代码风格是否与项目原有风格一致命名是否清晰可读 输出格式要求 - 严重问题必须修改列表 - 建议优化可延后列表 - 整体评分优 / 良 / 差 请直接给结论不要复述代码。4.2 “不要复述代码”这个要求为什么很重要很多人用 AI 做 Code Review 时会遇到一种情况AI 花了很大篇幅把代码重新讲了一遍然后说“这段代码看起来不错”。这种输出对开发者来说毫无价值。所以我专门加了“请直接给结论不要复述代码”逼它只保留增量信息——也就是“哪里有问题、哪里值得注意、哪里可以改”。“严格但不刻薄”这个角色描述也是磨出来的。一开始我用的是“严格的代码审查员”结果 AI 的输出充满了浓烈的批评味连一些风格偏好都会被标成严重问题反而淹没了真正重要的逻辑漏洞。后来我加了“不刻薄”三个字输出的语气收敛了很多但对严重问题的敏感度并没有下降。4.3 评分机制的实际意义整体评分这个设计很多人会忽略但我觉得它是接近人的工作方式的设计先用一句话给出结论再展开细节。这样你在浏览评审结果时第一眼就能判断要不要认真处理。如果是“优”可能只需要扫一眼建议优化如果是“差”就需要逐条改完再重新审一遍。这个思路在实践里还有一个变体你可以让 AI 单独给“严重问题”做一个汇总类似 PR 提交前的“最后一遍自检”。我就是这么用的每次准备提代码评审之前先把 diff 丢给这条提示词处理掉它标注的严重问题之后再走人工评审流程整体效率提升很明显。5. 第四条故障排查提示词逼 AI 先取证再下结论5.1 这条提示词的完整内容# Role: 资深故障排查工程师 场景设定我会提供一段报错信息或异常现象禁止你直接猜测原因。 处理流程 1. 先让我提供错误堆栈、复现步骤、最近改动、相关日志 2. 基于已有信息列出最可能的 3 个原因并说明判断依据 3. 对每个原因给出验证方案优先使用日志或复现实验 4. 确认根因后再给出修复建议和验证步骤。 如果信息不足明确告诉我缺失了什么不要编造原因。5.2 为什么“禁止猜测原因”能大幅提高准确率大模型的推理能力看起来很强但它有个致命弱点在信息不完整的情况下它会用“最可能”的内容填空。这种能力在写方案时很有用在排查故障时却是个灾难。因为故障根因往往不是最显眼的那一个如果 AI 一开始就往错误方向猜后续的每一步都会顺着这个错误走浪费大量时间。我把“禁止直接猜测原因”放在场景设定里等于强制它进入“先收集情报再判断”的模式。这个约束的效果非常明显。有一次我把一段空指针异常堆栈丢给它在没加这条提示词之前它直接说“可能是某个对象没有初始化”建议我加判空但加了这条之后它会先要求我提供完整堆栈和调用链然后再列出“初始化顺序问题”“注入失败导致对象为空”“异步线程中上下文丢失”这几种可能性。后一种输出对实际排查的帮助要大得多。5.3 配合日志和复现步骤使用的套路这条提示词真正发挥威力需要配合一套稳定的提交流程。我现在的习惯是遇到线上异常先把堆栈、最近一次的 Git 提交记录、相关日志片段整理好一次性丢给 WorkBuddy然后让第四条提示词做分析。它给出的 3 个可能原因里通常至少有一个能直接指向问题方向剩下两个也会提示你补哪些验证信息。注意如果你的日志太大不要整段粘进去。先手动截取异常发生前后各几十行减少噪声。日志里的无关输出越多AI 的判断就越容易受到干扰。6. 第五条全局规则兜底让每条指令都带上约束6.1 这条提示词的完整内容# Role: 团队技术负责人规则模式 以下规则对后续所有任务长期生效 1. 所有方案必须先分析、后编码禁止直接修改代码 2. 禁止删除、重命名项目原有公共方法除非先说明影响面 3. 代码优先复用现有工具函数和公共组件 4. 修改文件必须附带“改动原因”说明 5. 技术方案和注释使用中文代码中的变量、函数命名使用英文。6.2 规则模式与单次提示词的区别第五条的定位和其他四条不一样。前四条是“在某一个特定任务里临时执行的指令”第五条是“长期挂载在 WorkBuddy 里的全局约束”。它会把自身的规则注入到每一条后续请求中相当于给所有任务都加了同一组护栏。这种做法的价值在于你不用每次都手动重复这些要求。比如“先分析后编码”这条规则不管你是让它改代码、写功能、修 bug它都会默认遵守。换成临时提示词的话你大概率会在几次对话后忘记加然后 AI 又回到那种“拿到需求就写代码”的默认模式。6.3 为什么特意写了“禁止删除、重命名公共方法”这条规则来自我踩过的一个坑。有一次我让 AI 重构一个模块它“顺手”把一个被其他三处调用的公共方法改了个名那三处调用并没有同步更新结果整个模块直接编译不过。从那以后我就在全局规则里明确加上了这一条。如果你希望 AI 重命名某个公共方法就必须先让它说明影响面这就是“违规前先报告”的机制。这类小规则你可以按团队情况自己扩展。比如有些团队希望所有对外接口必须有 swagger 注解有些团队要求数据库操作必须走统一的 DAO 层这些都可以加进全局规则。但建议控制在 8 条以内太多的话模型可能顾此失彼。6.4 规则冲突时怎么解决全局规则和临时提示词之间偶尔也会有冲突。比如全局规则说“禁止直接修改代码”但你的临时指令是“帮我修复这个 bug直接给出改好的代码”。遇到这种冲突时我看下来 WorkBuddy 的行为更偏向遵循更具体的当前指令。所以如果你真的需要 AI 跳过规则直接改代码可以在临时指令里明确写“本次任务允许跳过第 2 条规则”这样会比硬顶着全局规则更顺畅。7. 这几条提示词的共同设计逻辑场景、目标、边界7.1 角色设定在提示词里扮演的角色细心的读者可能已经发现5 条提示词全部以“# Role: xxx”开头。这不是我为了统一格式而做的设计而是确实有效。大模型在训练时接触过大量带角色设定的语料当你指定一个具体角色时它会自动调整语气、知识侧重点和输出风格。比如说“资深故障排查工程师”会让它更倾向于用日志和数据说话而“团队技术负责人”会让它更注意全局影响。角色设定要具体不要用“AI 助手”这种万金油。你可以对比一下“请审查代码”和“请作为资深代码审查员审查代码”这两种表达后者的输出通常会更结构化、更挑剔、更直击要害。7.2 输出格式是隐形护栏我几乎在每条提示词里都指定了输出格式表格、列表、评分、明确的小节标题。这么做不只是为了方便阅读还因为它能约束模型的行为轨迹。当模型知道“最后要输出一个评分”时它在分析过程中就会默默向“可评分”的方向组织内容当它知道“要用表格展示技术栈”时它会主动收集适合放表格的信息。这其实是一种“预先埋锚点”的技巧。你希望 AI 关注什么维度就在输出格式里要求什么维度。如果有一天你发现 AI 忽略了某个重要角度最直接的修正方式不是让它“注意一下”而是在输出格式要求里增加一栏。7.3 约束宁可多写一条也不要少写一条很多人觉得提示词写得越多AI 越容易迷茫。但根据我的实操经验面向编程任务的提示词约束宁可具体到啰嗦也不要模糊到万能。因为这些约束本质上是在帮模型缩小搜索空间。比如“不要复述代码”和“信息不足时列出缺失项”这种规则看起来是在限制 AI实际上是在帮它把注意力集中在真正重要的事情上。当然约束要围绕目标设置而不是无脑堆砌。比如你让 AI 写一首诗然后约束它“必须使用中文变量命名”这就属于方向完全跑偏的约束。我的判断标准是每一条约束都要能回答“如果没有这条约束AI 可能会在哪个环节跑偏”这个问题。7.4 提示词工程与上下文工程的关系最后聊一个稍微深一点的话题在 WorkBuddy 这类工具里提示词只是“上下文工程”的一部分。同样的提示词放在不同上下文环境里效果可以天差地别。比如你在多轮对话末尾使用第四条排查提示词和把它作为新会话的第一条消息使用AI 的行为会不一样。前者会带入之前讨论过的很多信息后者则完全从零开始。这也是我建议把全局规则单独管理而不是混在对话里反复发送的原因。全局规则承载的是长期稳定的约束单次提示词承载的是短期任务目标。两者各司其职才能让上下文保持干净、可控。上下文越干净提示词的执行力就越强这一点在长时间使用下来体会尤其深刻。8. 关于“鹈鹕测试法”和一些实操避坑8.1 鹈鹕测试法是什么最近在 AI 编程的圈子里流行过一个挺有意思的验证方法——“鹈鹕测试法”。具体来说就是让 AI 画或者描述一只骑自行车的鹈鹕。听起来像个段子但它背后其实是一个相当巧妙的多层测试模型必须准确理解“鹈鹕”这个主体理解“骑自行车”这个动作还要保持两者之间的关系不跑偏。如果模型能把“一只骑自行车的鹈鹕”正确地用代码实现、用 SVG 画出来或者准确描述出来在一定程度上可以反映它对组合式指令的理解与约束遵守能力。我一开始也拿它试过 WorkBuddy 里的提示词效果。做法很简单把“请使用 SVG 绘制一只骑自行车的鹈鹕”作为一条测试请求发到配置好第五条全局规则的工作区里看 AI 是不是能正确生成结构完整的 SVG并且没有出现鹈鹕和自行车分离、或者多出奇怪对象的情况。这个测试比单纯问“你理解了吗”更硬核因为它要求真的输出一个可以验证的产物。8.2 用它验证提示词时的局限不过也要说清楚鹈鹕测试法只能验证模型的“通用指令理解能力”验证不了你精心设计的那条提示词在真实业务场景里的效果。它能告诉你“这个模型现阶段是否还正常、上下文有没有被污染”但它没法告诉你“你的项目全景分析提示词能否准确识别支付服务的核心链路”。我现在的用法是把它当成一个轻量“体检”工具。比如 WorkBuddy 升级了底层模型或者某段时间觉得 AI 答非所问我就用鹈鹕测试快速判断一下是模型行为变化了还是我的提示词在特定场景下失效了。如果鹈鹕测试正常通过那问题大概率出在提示词和当前任务的匹配上如果连鹈鹕测试都从“骑自行车的鹈鹕”变成了“一堆几何图形”那说明配置或模型层面出了问题。8.3 提示词之外还要留意的几个细节最后分享几个使用 WorkBuddy 时容易踩的坑提示词更新后不会自动应用到旧会话。如果你修改了某个提示词最好新开一个对话再测试旧会话里往往还带着旧规则。同一个项目最好不要同时挂多套工作台配置。配置越多上下文越长响应速度变慢且规则冲突的概率变大。一个小项目配一套精简规则完全够用。系统缓存的目录如果占用空间太大记得定期清理一下。工作台长时间运行后产生的临时文件还是挺占空间的尤其在 Windows 机器上。我自己现在的习惯是先让第五条全局规则常驻把“先分析后编码”刻进每次对话的默认行为里。遇到具体任务时再从常用提示词模板里调出对应的那一条配合当前上下文使用。至于鹈鹕测试平时不会刻意想起来用但一旦发现 AI 行为变得不对劲它就是我用来定位问题的第一把尺子。这些提示词不是什么高深莫测的“万能咒语”它们只是在合适的位置把任务目标、判断标准和输出形式说清楚了而已。如果你手头正在用 WorkBuddy或者正准备搭一个属于自己的 AI 工作台建议先挑其中一两条用起来跑通之后再慢慢补全。等五条全部进入正常工作流之后你会明显感觉到 AI 的产出从“能用”变成了“好用”。
