我用 workbuddy 差不多快半年了坦白讲前期我差点把它卸载掉。写代码时它给出的东西看着有模有样可真到执行阶段经常能给我制造一些“看起来很合理、但跑起来就露馅”的事故。后来我慢慢意识到问题可能不在模型本身而在我从来没有告诉它“按什么标准干活”。我这个人习惯给团队里的搭档立规矩工位上贴一张手写的准则哪些不能做、哪些必须先做、事情做到什么程度才算完成。抱着这个心态我在 workbuddy 的“设置-自定义指令”里填了第一版规矩。改完之后最直接的变化是它从一个“笨拙但努力的新人”变成了一个“懂规矩、知进退的老员工”。连续几周它独立处理我指派的任务交付稳定到我敢把任务直接整包丢给它而不是一句一句地纠正它。这篇文章把整套配置思路、规则原文、实际踩过的坑都摊开来讲。适合两类人一类是刚开始用 workbuddy、不知道怎么设置自定义指令的新手另一类是已经用了很久但总觉得输出不够稳定、想通过规则减少无效沟通的老用户。如果看完只记住一句话我希望是规矩不是限制它的锁链而是让它能自主运转的轨道。1. 先搞清楚机制自定义指令到底在什么时候生效1.1 它不是一句临时提示而是每次开工前都读一遍的“工位守则”自定义指令和普通聊天里敲一句提示完全是两码事。临时提示好比路过同事工位时顺嘴说一句“这个文档你写详细点”对方能不能持续记住取决于他今天忙不忙。自定义指令则像贴在工位上的一张纸上面写着这个岗位的要求是文档必须写详细、提交前必须自测。它每次接到任务都会先把这张纸读一遍再按标准展开工作。在 workbuddy 里这个配置入口一般在“设置-自定义指令”页面同时项目工作台也能挂项目独立的规则面板。很多人打开过一次就再没管过但这里其实是决定这个工具靠不靠谱的核心区域。为什么这么说因为自定义指令会在会话启动时被注入上下文之后每一轮任务处理都默认以此为基础。你在对话框里说“这次务必认真一点”只能影响当前这几轮但你在自定义指令里写“提交前必须跑测试”它以后每一轮都会默认遵守。1.2 三个生效环节决定了什么该写、什么不该写根据我实际使用的观察workbuddy 对自定义指令的加载不是一次性的它会在至少三个环节被激活会话启动时新会话建立、读取项目信息后第一件事就是加载自定义指令这是所有后续判断的地基。每轮回复前在生成回复或决定调用工具之前核心规则会和当前任务一起进入上下文影响它这轮怎么做。工具调用返回后当文件读取、命令执行、测试运行等动作返回结果时规则里的约束条款会影响它下一步选择。把这三个环节理清楚你自然就明白什么内容适合写进去。凡是希望它“一直默认遵守”的比如不臆想 API、提交前要自测、回复用中文都适合放进自定义指令凡是希望它“临时帮个忙”的比如“这轮只改这一个文件”“先写原型不要测试”就放在对话里单独说。千万别把临时要求固化到全局配置里不然以后每个任务都会被这句多余的规矩干扰。1.3 区分“行为规则”和“任务规则”不然写了也白写我第一次填自定义指令时写的都是这类话请注意准确性、逻辑要严密、全面考虑各种情况。听起来没毛病实际效果约等于零因为这些全是不可能操作的宏观词。准确的标准是什么逻辑严密如何检查模型只能靠猜。后来我把规则拆成两类效果立刻不一样了。第一类是行为规则它不绑定任何具体技术栈是所有项目通用的底线。比如不要编造不存在的文件、依赖和 API改完代码必须跑测试或构建报错时给出可复现信息不要空泛解释。第二类是任务规则只针对具体场景或技术栈生效。比如Python 项目必须写完整类型注解改动前端时只修改问题对应的文件提交信息用特定格式。两类规则混在一起写模型容易把注意力平均分配重点反而不突出。分开之后行为规则长期稳定在全局层任务规则按项目单独配置互相不干扰冲突时还能明确说明哪条优先。2. 我第一版真实在用的自定义指令长什么样2.1 直接可抄的全局规则模板下面这段是我现在仍在用的全局“打底规矩”你可以在 workbuddy 的设置-自定义指令里直接套用。它不是针对某个语言只解决可靠性和协作习惯问题。你是一位务实的资深工程师目标是把任务做完而不是给建议。 任何时候优先考虑直接修改文件或执行命令不要只说“你可以这样做”。 不要臆想不存在的文件、依赖和 API没把握时先查项目结构再动手。 修改代码后必须跑对应的测试或构建并在回复里说明执行结果。 提交信息用 conventional commits 风格正文一句话以内。 默认使用简洁的工作日志口吻不要客套不要输出大段评语。 翻译、说明类任务除外其余场景回复默认使用中文。 如果规则之间有冲突以项目级指令为准。为什么这些简短句子有效因为每一条都对应了一个可以验证的具体行为。它会真正动手改文件而不是站在原地讲道理它不会凭空写出一个不存在的接口它提交信息格式固定翻译类任务有豁免权不影响正常使用。这些全都是我从一次次失望里总结出来的比“拒绝胡说八道”之类的空话有用得多。2.2 为什么“不要编造 API”是刚需条款这一条我要单独拎出来讲。AI 工具最让人头疼的毛病就是一本正经地胡说八道。我在一个老项目上让它写某个模块它调用了一个当时项目里根本不存在的库版本编译直接失败。我排查了小半天才意识到依赖版本写错是因为它对版本号的记忆已经过时了。从那以后“查了再写”成为我的铁律而且会写进几乎所有层级的规则里。有些人不敢写这条怕限制太死让工具畏手畏脚。实际上完全不会。它不会因为你不让它臆想就罢工它只是把“先查证、再动手”的优先级提上来了。你可以在规则末尾补一句“查证优先级别高于完成任务的速度。”这样在需要快速产出原型时它会灵活过渡但在真正改生产代码时它知道先确认事实。从我的测试结果看这句话带来的稳定收益远大于效率损失。2.3 去掉“AI 味”的三个具体约束热搜里很多人都在找“workbuddy 减少 AI 味”的方法。所谓 AI 味其实就是套话、总结句、多余解释和空洞肯定。我的处理方式不是写“请自然一点”而是列禁令禁止用“综上所述”“总的来说”“关于这个问题”这类废话开头。禁止复制原需求后再重新解释一遍。禁止在回复里写“这是一个很好的问题”“希望以上内容对你有帮助”之类评价语。把这几条放进规则后输出可读性提升非常明显。有人觉得这些是小事但对每天要和它打几小时交道的人来说少一句废话、少一段复读工作体验完全是两个量级。写到这里我想补一句自定义指令也好普通提示也好最好都采用“要做什么”加“不要做什么”的并列结构比单一方向的表述更有约束力。3. 分层立规矩我把规则拆成了三个层级3.1 项目级规则每个仓库有自己的“本地习俗”全局规则只是打底真正让 workbuddy 干得顺手的是项目级规则。在 workbuddy 工作台的项目配置里可以单独设置一个只对当前仓库生效的指令区。这个区域的职责是告诉它“这个仓库有什么特殊习惯”。我一般会写入以下内容技术栈和语言版本目录结构约定测试、构建、格式化、lint 的命令禁止手动改动的目录或文件代码风格约定比如缩进、引号、命名方式。举个例子我在一个 Node.js 项目里配的项目规则长这样项目为 Node.js 20 TypeScript 5测试用 vitest。 所有新增代码必须有单元测试测试文件放同目录 __tests__。 lint 命令是 pnpm lint提交前必须通过。 src/generated/ 下的文件不要手工修改需要改时要先说明原因。 组件命名用 PascalCase函数命名用 camelCase。 跨文件改动前先列一个简短的改动计划再动手。这段规则不长但它足以让 workbuddy 在一开始就走上正确路径不用每次猜目录结构、不用重新找测试命令。配合全局规则里的“项目级指令优先”这套配置直接在每次会话开始时帮它形成一个正确的框架剩下的事情就是按框架执行。3.2 会话级规则临时需求随用随加不是所有事都值得写进项目规则。有些约束只对当次任务有效那就直接放在会话开头说。比如你只想让它“先写一个原型不做完整工程化”那就先声明本次任务以原型验证为主不需要测试。这条很重要因为项目规则里写了“必须有测试”如果不声明例外它每一步都停下来写测试做原型的体验极其痛苦。会话级规则是项目规则的补充和临时覆盖。我处理复杂任务时会先花十几秒把会话目标、交付标准、边界条件说完整然后再分配任务。比如“本次会话目标是实现登录接口的重构保持对外接口不变不需要补充新文档但如果发现安全问题要立即停下来报告。”这一句话就能避免它在重构过程中自作主张改了接口签名或者写了一堆无关文档。3.3 用户级规则把个人偏好放在全局配置里很多人分不清全局配置和项目配置把技术细节写进了全局结果在另一个技术栈完全不同的项目里它还在用上一套规则导致很多荒谬行为。我见过有人把 npx、pnpm 这类命令写进全局级规则结果在纯 Python 项目里 workbuddy 还在尝试用 Node 工具链当然非常奇怪。正确的做法是用户级/全局配置放个人偏好比如默认回复语言是中文、提交信息风格、遇到不确定信息先查证、不要在回复里加没用的客套话等。项目配置放技术细节和目录约定。这样全局规则稳定通用项目规则精准适应当前仓库二者界限清晰既能保证一致性又不会让全局被技术栈绑架。4. 调优与排坑让规矩真正变得稳定4.1 规则写了但不生效大概率是这三个原因我改了规则之后经常出现“本次说规则已经生效但行为没变”的情况。排查下来 95% 的原因出在三个地方层级放错了想把个人偏好写进项目规则但项目规则被某个全局规则覆盖或者反过来。措辞太模糊写“注意质量、认真点”模型不知道怎么审校自然无法稳定执行。会话提示覆盖规则你在会话里临时说“这次先不要测试”把项目规则里的“提交前必须测试”覆盖了但它没有能力自动识别优先级。对应的解法也明确先检查配置位置是否正确把模糊要求改成可验证的客观条件比如“提交前跑一下 pnpm lint且确保无报错”在规则里加一条优先级声明比如“本指令中的不可变约束不能因为会话提示而省略除非用户明确说明取消”。加了这个声明多数冲突都能自动化解。4.2 规则太重反而失去作用我也踩过“塞得越多越安心”的坑为了让它多面手一次性往全局规则里塞了三四十条。结果回复变慢、上下文被拉长、关键条款被稀释。压缩到十几条之后回复质量不降反升。原因是模型处理长指令时注意力会均匀分配规则条目越多权重越分散核心约束自然变弱。我的建议是把规则总量控制在一屏半以内通常 12 到 15 条核心条款就够了。实在有很多想约束的内容就把它们拆成任务规则的选项在项目需要时再启用。规则是给模型划定边界的不是给模型背课文用的边界越简单它越能守得住。4.3 常见故障排查速查表症状原因解决方法规则没生效配置层级弄错或放在不生效的空白区域确认配置位置重建新会话再测试规则生效但不稳定句子太泛模型不知道怎么判断改成可验证的客观条件比如“运行 pnpm lint”会话提示覆盖掉固定规则规则里没有优先级声明加“不可变约束优先于会话提示”输出越来越啰嗦限制不够具体加入“禁止……”形式的明确约束多个项目间串规则全局规则里存了技术细节把技术细节迁移到项目级配置配置丢失或无法保存缓存目录被清理或路径不对检查持久化缓存目录设置确认配置保存位置4.4 验证规则是否生效的小技巧每次改完规则后我都会用一个小技巧来验证注入是否成功。新建一个会话把任务清空只输入一句话“请复述当前生效的自定义指令里前三条约束并举例说明你会怎么执行。”如果它能完整复述说明规则正常加载如果答非所问多半是配置位置不对或上下文被其他内容干扰了。还有一个更稳妥的办法让它做一个不写代码的小任务比如“读一下当前目录结构告诉我你打算怎么开始”。这样如果规则里要求先查目录、先看 README它能自然体现出来。这种静默验证方式不消耗任务额度也不影响生成代码是检查配置是否生效的安全路径。5. 效果与心得它确实变得像个熟手5.1 规则前后对比从多轮拉扯到一轮到位给 workbuddy 配规则前后的效率差异是很直观的。以前我说“给某个接口加上缓存”它往往先解释一遍缓存的好处再给出代码片段接着我要求它改、它再改反复几轮才落地。同样一句话有了规则之后它会先查接口代码位置按项目已有缓存风格写实现然后直接跑测试验证最后在回复里告诉我运行结果。整个过程从“要我盯节奏”变成“它自己推进”交互次数从四轮左右压到一两轮。更让我放心的是多文件任务。有一次它需要迁移 40 个文件我设定的项目规则里明确写了“没有测试不许提交”结果它真的在无人介入的情况下按批次改代码、跑测试、修复报错最后提交。虽然中途两次因为依赖版本问题报错但它能自己读日志、查依赖、调整步骤再继续。这在旧配置下是几乎不可能发生的更多时候是做到一半就停下来等我去处理。5.2 它守规矩但我需要给它规划边界说实话“现在干活比我自己还靠谱”只是一句情感化表达。我更愿意这样描述我原本靠自觉的地方它靠规则我靠经验的地方它靠快速试错。两者补位之后它在重复性任务上的可信度确实大幅提升。我放心不是因为模型变得像人而是因为它稳定重复我的边界。这其实提醒了一件事规则的价值不在于限制它而在于让它在每次开工时保持一致不出现的随机发挥。同时我也意识到规则体系不是一次建好就永久有效。项目会升级、技术栈会变化、团队规范也会调整定期把规则拿出来重新过一遍删除废条款、更新命令、增加新约束是维护和使用 workbuddy 的必要习惯。我自己一般每个季度会整体复盘一次配置保证规则和项目现状始终一致。5.3 给新手的下一步建议如果你现在还没有建立过自定义指令建议先复制前面那段全局规则跑一个真实任务感受一下差异。跑完别急着增加条款先用一周每天把让你不满意的地方记下来然后在周末把这些问题翻译成“禁止……”或“必须……”的句式逐条加进去。这样形成的规则不是凭空想象而是从真实需求里长出来的每条都能对应到一个具体痛点。等规则积累到十几条你会发现自己已经可以把一些固定的、重复性的任务整包丢给它自己只负责验收。最后分享一个小技巧如果你同时管理多个不同技术栈的项目请在规则顶部写一句“每次开始时先查看当前目录的 README 或项目配置文件确认技术栈后再按项目规则执行”。这一句话能省掉很多因为默认印象不一致而引发的低级返工。