我最近把 WorkBuddy 从一个“随叫随到的问答机器人”调教成了“按规矩办事的靠谱开发搭子”关键就靠它的自定义指令功能。说白了自定义指令就是给 AI 一份可以长期生效的“员工手册”你在里面写明代码风格、技术栈偏好、回复语气、禁止事项它做任务前先读这份手册再动手干活。以前我总吐槽 AI 写的代码风格飘忽、注释一股 AI 味、改需求的时候还自作聪明现在我把这些诉求全部固化进规则文件之后实测下来同一批任务输出的稳定性和一致性比我手写还稳。这篇内容就是分享我的完整玩法怎么区分全局规则和项目规则、怎么写指令才不容易翻车、如何验证规则真的生效以及我踩过的几个典型坑。不管你是刚接触 WorkBuddy 的新手还是已经用了一段时间想进一步提升输出质量的老手这份“定规矩”的思路应该都能直接用。1. 内容整体设计与思路拆解1.1 自定义指令到底管什么AI 模型本身是没有记忆的每次新会话都是“失忆”状态。你上次让它“用 pnpm 装依赖”这次换了话题它可能就默认用 npm 了。自定义指令的核心作用就是给 AI 注入一份可长期读取的“行为基线”让它在每次对话开始时都先加载这些约束再生成回答。以我使用的 WorkBuddy 版本为例自定义指令通常分成两层作用域。第一层是全局规则放在客户端设置里对所有项目、所有会话生效。适合放那些“无论做什么项目都不该变”的内容比如默认用中文回复、代码块必须标注语言类型、不要输出“总之”“综上所述”这类套话、回答前先复述一遍需求确认理解。这些是个人工作习惯放在全局最省事。第二层是项目规则放在项目根目录的配置目录里比如.workbuddy/rules文件夹只对当前项目生效。适合放项目特性相关的内容技术栈、目录结构约定、命名规范、禁用的依赖、测试要求等等。比如我在某个 React 前端项目里就写了“组件统一用函数组件 hooks禁止使用 class 组件”“样式优先用 Tailwind不要写内联样式”“API 调用统一走 src/api 目录下的封装函数”。为什么这么划分我吃过一次亏有段时间我把“统一用 pnpm 作为包管理器”写进了全局规则结果同事在一个历史悠久的 npm 项目上让我改代码AI 直接给出pnpm install的命令把那个老项目的依赖树搞得一团糟。从那以后我就严格按作用域分开凡是项目特有的约束一律不进全局规则。1.2 为什么“定了规矩”之后比我自己还靠谱人干活最大的问题是状态不稳定。我写代码时上午精神好命名规范、边界处理都记得下午累了就开始糊弄变量名乱起异常处理草草带过。AI 恰恰相反只要规则被正确加载它一百次都会按同一套标准执行不会因为“今天心情不好”就漏掉某条约定。自定义指令还有一个隐藏价值可复用、可沉淀。团队里如果有新人接手项目不需要你逐条口头叮嘱“我们这不用 class 组件”“接口都在 src/api 下”他让 AI 读一下项目 rules 就全明白了。我把规则文件提交进 Git 仓库之后相当于把个人经验和团队规范同步进了项目历史里每次规则调整都能回溯对比。这里可以用一个生活化的类比你带实习生与其每天重新叮嘱一遍工作规范不如给他一本员工手册。员工手册写得好你只需要验收结果不用每次纠正过程。自定义指令就是这个员工手册。2. 核心细节解析与实操要点2.1 先分清全局规则和项目规则避免规则写错地方很多初学者最容易踩的坑就是把规则一股脑全塞进全局设置。比如他只在当前这个前端项目里用 Vue却把“所有页面组件放在 src/views 目录”写进了全局规则。等他切到另一个 Node 后端项目时AI 还在固执地找 src/views非常崩溃。这里我给一张简单的对照表方便你快速判断一条规则该放哪规则内容推荐作用域原因默认使用中文回复全局跨项目通用代码块标注语言类型全局输出格式偏好使用 pnpm 作为包管理器项目可能因项目而异组件命名用 PascalCase项目或全局均可若团队统一规范可放全局接口请求统一走 src/api项目强依赖项目目录结构禁止使用“总之”等套话全局跨项目通用判断标准其实就一句话换一个完全不相关的项目这条规则还应不应该生效应该生效的就放全局否则就放项目规则。项目规则通常放在项目根目录下的.workbuddy/rules文件夹里并且要记得提交到 Git否则团队其他人拉取代码时看不到规则。另外要注意优先级项目规则会覆盖全局规则。如果两条规则冲突以项目规则为准。这一点在 2.2 里还会展开讲但你先记住这个结论排查问题时会省很多力气。2.2 指令话术的写法与禁忌自定义指令写得不好AI 就容易“装模作样地遵守”。我总结了几条非常实用的写法原则。第一用肯定句代替否定句。比如你写“不要使用 npm”AI 可能理解为“尽量别用 npm”但遇到具体场景时还是容易跑偏。更稳的写法是“使用 pnpm 作为包管理器”直接给一个明确的行为指令比禁止式指令更容易被执行。第二模糊词是规则的大敌。“尽量”“通常”“可能”“等等”这些词AI 会当成友好建议而不是硬性约束。我踩过坑写了“组件命名要尽量有意义”结果它生成了data、item、temp这种一眼看不懂的变量。后来改成“组件命名必须使用 PascalCase文件名与组件名保持一致布尔变量用 is/has 开头”效果立刻不一样。第三必要时要给出优先级裁定规则。当规则数量超过 5 条就可能会冲突。我现在的做法是给每条规则编号比如rule-001、rule-002并在规则文件开头声明“编号越小优先级越高规则冲突时按编号顺序裁决”。这样 AI 在犹豫时能给出一个可预期的判断而不是随机挑一条执行。第四示例比描述更有效。与其写“注释要清晰”不如写“注释只解释为什么不要复述代码本身语义代码是自解释的时候可以省略注释”。如果条件允许直接在规则里附上一小段好代码和坏代码的对比AI 的学习效果会翻倍。最后是禁忌清单不要堆砌几十条规则模型注意力资源有限抓不住重点不要把临时任务写进规则比如“帮我重构登录模块”这种指令应该放在对话里而不是规则文件里也不要用情绪化语言比如“绝对不能用 class 组件否则我会疯掉”模型可能理解不了你的情绪反而会削弱指令强度。2.3 让自定义指令“可审计”的三个小技巧规则配置完之后最难确认的一件事是AI 到底有没有在读规则我摸索出三个办法基本能判断规则是否真的被模型吸收。第一个办法是“规则复述测试”。新开一个会话直接问 AI“当前项目的规则有哪些请列成清单。”如果它能准确复述出你写进去的关键条目说明规则加载成功。如果答得似是而非或者漏掉核心内容那就要检查配置文件路径和优先级是否写错了。第二个办法是“真实任务对比测试”。把同一个任务分别在“有规则”和“没规则”的环境下各跑一遍对比输出的差异。比如我写了一个“前端页面落地页”的任务没规则时它给我生成了 class 组件加内联样式有规则时它自动用了函数组件、hooks、Tailwind 类名差别非常明显。通过这种对比你能直观看到每条规则是否生效也能找出哪些规则其实没起作用。第三个办法是“违规自纠测试”。故意让 AI 做一件违反规则的事比如规则里写了“不要输出 emoji”你在对话里问它“帮我加个笑脸表情好吗”看它是否会拒绝或者至少提示“当前项目规则限制了 emoji 的使用”。如果它二话不说直接输出 emoji说明规则可能没被加载或者被当前用户消息的指令覆盖了。这个测试能帮你找出规则与用户指令之间的优先级问题。3. 实操过程与核心环节实现3.1 我的全局规则配置模板直接抄作业下面是我目前一直在用的全局规则参考你可以根据自己的习惯调整。注意只保留了最核心的几条每条都尽量具体、可验证。# 语言与输出 - 所有回复默认使用中文除非用户明确要求使用其他语言。 - 代码块必须标注语言类型例如 python javascript。 - 回答复杂问题时先复述需求再给出方案最后给出代码。 # 代码风格 - 不要使用“总之”“综上所述”“需要注意的是”这类套话作为开头或结尾。 - 代码注释解释“为什么”不解释“是什么”。 - 状态管理优先使用异步方式避免阻塞主线程。 # 交互约定 - 如果需求存在歧义列出 2~3 个假设选项并标注推荐项。 - 当规则之间存在冲突时按规则编号顺序裁决编号越小优先级越高。写好之后我想强调几个细节。第一点是“代码块必须标注语言类型”这条看起来很基础实际能极大提升代码的可读性。没有这条规则时AI 经常输出不带语言标注的代码块复制粘贴到编辑器里没有语法高亮很影响效率。第二点是“先复述需求”这条它帮我过滤了大量无效回答。以前 AI 经常答非所问我写了一大段需求它只抓到一个关键词就开始写代码。现在它必须先复述一遍需求相当于帮我检查了一遍自己的描述是否清晰同时也让 AI 更准确地锁定任务边界。第三点是“如果需求有歧义列出假设选项”。这一点特别适合需求捉急的情况。有一次我让它“优化一下用户反馈页面的加载速度”它没有直接埋头改而是列出了三个假设是否优先减少首屏图片体积、是否把统计数据拆成异步加载、是否对列表做虚拟滚动。我看完之后直接选了 1 和 2省了自己写澄清描述的时间。3.2 一个让我少写一半废代码的规则迭代实例这里分享一个我印象最深的规则迭代过程关于注释。第一版规则我写的是“注释要清晰。”结果 AI 生成的注释长这样// 获取用户列表 const userList await fetchUsers(); // 定义一个变量 name const name user.name;这些注释不能说错但完全没有价值。它们复述了代码本身的语义属于典型的“AI 味注释”。更气人的是AI 还会在一些关键逻辑上不加注释真正需要解释的地方它反而沉默了。我把规则改成- 注释只解释“为什么这样做”不要复述代码做了什么。 - 如果代码本身是自解释的可以省略注释。 - 禁止使用“// 定义一个变量”这类废话注释。修改之后AI 生成的注释变成这样// 用户分页查询需要保留游标避免用户量增长后全表扫描 const { items, nextCursor } await fetchUsers({ cursor }); // 当前会话使用 base64 编码兼容旧版客户端 const payload encodeBase64(data);说实话看完第二次输出我是有点惊讶的。它开始像一个有经验的同事在写注释而不是一个刚学编程的助手在复述代码。类似的迭代还发生在命名上。第一版规则“命名要有意义”基本没用后来我改成“布尔变量用 is/has 开头数组用复数名词事件处理函数用 handleXxx组件文件名与组件名保持一致”。这些具体的命名模式让 AI 生成的代码风格跟我手写的几乎一致。3.3 如何验证自定义指令真的生效了拿到一份规则配置之后别急着开始干活先花两分钟验证一下。我一般按三步来。第一步是新开会话问 AI 当前项目的规则清单。新会话很关键因为很多规则文件是在会话创建时加载的。如果你开着旧会话改规则AI 不一定能即时感知到变更。确认它能正确复述规则再进入下一步。第二步是跑一个“规则测试用例”。找一个小而典型的开发任务比如“写一个 React 组件从接口读取数据并展示列表”然后看 AI 是否严格按照规则来。如果规则里写了“组件用函数组件 hooks”它生成了 class 组件说明规则没生效。如果它正确用了函数组件还主动加了加载状态和错误处理说明规则已经起作用了。第三步是对 AI 做一次“违规自纠测试”。直接在对话里给它一个明显违反规则的命令比如“这段代码不用写注释了直接跑通就行”看它如何应对。如果它坚持遵守规则说明约束足够强如果它立刻妥协那说明规则优先级不足需要调整规则编号或者改写成更强的肯定句。我把这三步固化成了一个模板每次调整规则后都跑一遍能省掉很多“规则失效”的烦恼。4. 常见问题与排查技巧实录4.1 规则不生效排查思路按这个顺序来规则配置不生效是使用自定义指令时最头疼的问题。按我这几年的经验90% 的情况都能通过下面这个顺序排查出来。现象可能原因解决动作新写的规则完全没反应配置文件路径错误检查.workbuddy/rules目录是否存在文件名是否在约定范围内规则在旧会话里不生效旧会话未加载新规则新开会话再试规则时而生效时而不生效与用户消息中的指令冲突在规则中明确优先级或避免在对话中下达相反指令规则太多导致模型抓不住重点规则数量超过合理范围精简到核心 5~10 条按优先级编号项目规则没被团队成员看到规则文件未提交到 Git确认.workbuddy/rules未被 .gitignore 忽略有一次我排查了很久最后发现项目规则文件被 .gitignore 忽略了导致同事 clone 之后根本没有规则文件。检查顺序上先看配置路径对不对再看文件是否被版本管理忽略最后再考虑规则优先级和冲突问题通常不会跑偏。还有一个容易被忽略的点如果你在对话中给 AI 发了一条明确指令比如“忽略所有项目规则直接帮我生成”那 AI 会优先响应这条用户消息因为当前对话的上下文中用户指令的权重更高。这是模型机制决定的不是规则写错了。遇到这种情况重开会话或者撤回那条用户消息就行。4.2 还是一股“AI 味”减少 AI 味的规则清单很多用 WorkBuddy 的人都会遇到同一个问题代码没问题但生成的说明文字一股“AI 味”。具体表现就是“总之”“综上所述”“需要注意的是”“在这个快速发展的时代”这些空洞套话还有满屏的 emoji 和夸张的形容词。针对这个问题我总结了一段专门的规则你也可以直接用- 不要使用“总之”“综上所述”“需要注意的是”作为开头或结尾。 - 不要使用 emoji 表情。 - 不要使用“数字化时代”“赋能”“闭环”等空泛词汇。 - 自然语言部分使用短句一句只说一个意思。 - 代码注释和回答内容要像工程师之间的日常交流而不是像营销文案。实际效果我验证过。加了这些规则之后AI 写的项目总结、代码注释、需求说明都自然了很多。最明显的变化是它不再用“需要注意的是”来引出一个无关紧要的细节而是直接说结论。这里还有一个进阶玩法在项目规则里放一段你自己写的“风格样本”明确告诉 AI“这是我的写作风格请模仿”。比如你习惯把技术方案写成“背景 - 方案 - 风险 - 结论”的结构就把一个实际文档片段放进去。模型在上下文里对比样本时输出的风格会像你的风格靠拢效果比口头说“写口语一点”好得多。4.3 规则冲突与维护我的优先级编号方案最后聊聊规则多了之后的管理问题。规则数量一旦上来冲突几乎无法避免。比如我有一条规则是“所有接口调用统一走 src/api 封装”另一条是“避免过度设计优先在现有类型上做扩展”。如果 AI 觉得现有封装不符合某个新需求它就会纠结该听哪条。我的解决方案是提前给规则编号并在规则文件开头声明优先级逻辑。具体格式可以这样# 规则优先级 - 每条规则按编号排序rule-001 优先级最高。 - 如果两条规则冲突按编号顺序裁决编号小的优先。 # 规则列表 rule-001: 使用 TypeScript禁止使用 any。 rule-002: 组件文件使用 PascalCase 命名。 rule-003: 所有接口调用统一走 src/api 封装。这个方案的好处是让 AI 在冲突时有明确的判断依据减少“随机发挥”。另外每次调整规则时我的习惯是在项目 CHANGELOG 里加一行说明比如“调整规则rule-003 增加缓存请求的约束原因是后端接口存在重复调用”。这样后续回看规则历史时能知道每条变更的前因后果。维护规则还有一个重要时机项目技术栈升级之后。比如我有个项目从 JavaScript 迁移到 TypeScript旧规则里那些“不要求类型标注”的条目就成了绊脚石。我一般会在每个迭代结束时快速复盘一次规则文件把已经过时的、与当前技术栈冲突的条目清理掉保持规则的“新鲜度”。写在最后的一点个人体会我现在已经把 WorkBuddy 的自定义指令当成项目知识库的一部分来维护了。新项目 clone 下来第一件事是先配置好 rules再开始写代码。踩过几次坑之后最大的体会是规则不是越多越好而是越具体越好。宁可少而准不要多而杂。如果一开始不知道怎么写建议先写 5 条你最在意的规则用上一周再根据实际效果迭代。等规则沉淀得差不多了你会发现自己对“AI 靠不靠谱”这件事的掌控感会比以前强很多。