我最近把 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 靠不靠谱”这件事的掌控感，会比以前强很多。
