用了小半年WorkBuddy我最大的体会是AI助手这东西你不给它立规矩它就永远在“自由发挥”。同样是让它写一个接口上午还规规矩矩按项目现有风格来下午就开始自作主张改目录结构你说要单元测试它嘴上答应得挺好交出来的代码里却全是print。后来我在WorkBuddy的自定义指令里认认真真给它定了一套规矩干活的稳定性和风格一致性肉眼可见地上来了——甚至有些重复性比较强的活儿它交出来的结果比我自己做还靠谱。这篇文章不聊虚的直接把我设置自定义指令背后的思路、完整模板和踩过的坑写出来给同样在用WorkBuddy、但总嫌它“AI味太重”或者“时好时坏”的朋友做个参考。自定义指令并不是多高深的东西你可以把它理解成每次开会前你都要反复叮嘱新来的实习生“别碰线上数据”“改完代码要跑测试”“提交信息按格式来”。现在你把这些话一次性写进WorkBuddy的设置里让它每次干活前先读一遍这就是自定义指令。它解决的不是“AI能不能干”的问题而是“AI能不能稳定地按你的标准干”的问题。下面我把整个设置过程、规则写法、避坑经验和进阶玩法完整展开新手可以直接照着抄作业老手也能从规则分级和团队协作这几节里找到有用的东西。1. 为什么我要给WorkBuddy立规矩1.1 不设规则的AI像一个每次都失忆的实习生先说一个很多人忽略的事实AI模型本身没有长期记忆。上一次对话里你反复强调过的代码风格、目录规范、命名习惯新会话里它完全不记得。它只会依据当前这段对话的上下文再加上模型训练时学到的“平均化习惯”来工作。这个特性决定了你口头叮嘱一次、两次都只是暂时有效换一个新会话就全打回原形。这个“平均化习惯”才是最坑的地方。你用AI编程工具应该也有感受让它写Python它默认给你套一个“看起来标准、但和你项目完全不搭”的结构让它补个函数它顺手把旁边不相关的文件也改了你问它“这个改法有没有风险”它拍胸脯说没问题部署上线才暴雷。为什么因为模型在训练数据里见过太多“正确但庞大”的工程案例它天然倾向于展示自己的“全面性”而不是克制自己。所以我把自定义指令类比成“入职培训手册”。新人能力再强不告诉他你们团队的代码规范、目录约定、禁止事项他也只能按自己习惯来。AI也一样。一次性的口头叮嘱管不了一整天写进设置的规则才能每次都生效。我后来把规则写好之后明显感觉WorkBuddy像变了一个人准确说是变成了一个“懂规矩的老员工”。1.2 自定义指令到底在管哪几件事我现在用下来觉得WorkBuddy里的自定义指令主要能干三件事管输出风格、管行为边界、管工作流程。这三件事覆盖面很广基本解释了我日常让AI干活时九成的不满意。管输出风格解决的是“像不像你写的”的问题。包括代码用什么命名风格、注释写中文还是英文、提交信息按什么格式、文档的层级怎么组织。这些不写清楚AI每次给的都不太一样今天这样明天那样最后归档的时候看不出是同一个人做的。管行为边界解决的是“什么事能做什么事不能做”的问题。比如“未经确认不得删除文件”“只能在src目录下修改”“禁止改动测试数据”。这些是保护项目安全的关键条款。AI胆子一大就容易越界规则里的边界条款存在的意义就是把它那些过于大胆的想法拦在栅栏里面。管工作流程解决的是“先干什么后干什么”的问题。比如“拿到需求先分析影响范围再动手”“改完代码必须跑一遍单测”“涉及数据库迁移必须先给方案”。AI有了规定动作就不会跳过关键步骤也不会一上来就闷头写代码。这三个方向不管是写代码、整理文档还是做数据分析都可以按这个框架来梳理你自己的规则。1.3 不是只有程序员需要这套玩法很多人以为“自定义指令”是程序员专属其实完全不是。WorkBuddy这类工具能处理文档总结、表格整理、内容批量改写、甚至邮件起草只要它参与工作就同样需要立规矩。举个例子你让AI帮你整理一个月的会议纪要如果不设置规则它可能这次用表格下次用列表这次提炼成三行下次展开成两页。你在自定义指令里写清楚“所有纪要必须包含结论、待办事项、负责人、截止时间且待办事项用表格列出”那么无论谁来操作、无论项目进行到哪一步输出都是一致的。所以我始终觉得自定义指令真正的价值不在于“把AI调教得多聪明”而在于“把AI的产出变得可预期”。这比单纯追求“生成速度快”重要得多。我自己宁可用一个每次输出都符合规范的AI也不用一个偶尔惊艳、经常跑偏的AI。这个认知是我用WorkBuddy踩了好几个坑之后才真正想明白的。2. 动手之前先搞清楚WorkBuddy的指令层级2.1 全局规则、项目规则、临时叮嘱的区别在WorkBuddy里设置自定义指令通常有三个层级全局规则、项目规则、临时叮嘱。我建议你在动手写之前先分清这三者的边界否则容易把规则堆成一锅粥最后哪个都没让AI真正记住。层级作用范围适合写什么典型示例全局规则所有项目、所有会话通用风格、通用禁止事项“代码注释一律用中文”“不得删除未纳入版本控制的文件”项目规则当前项目仓库项目专属规范、技术栈约束“后端只在server目录下修改”“数据库表名统一用snake_case”临时叮嘱当前会话一次性需求、临时约束“今天只改登录接口其他文件不要动”优先级上临时叮嘱通常最优先其次项目规则再是全局规则。最合理的形态是全局管通用底线项目管具体约束临时管当次重点。我见过不少朋友把所有规矩全塞进全局规则里结果不同项目互相冲突。比如A项目用ESLint默认规则B项目自定义了组件命名前缀写在全局里只会让AI在B项目里反复“违规”。所以哪怕你图省事也建议至少把项目相关的规则拆到项目层级去。2.2 入口去哪找别急着写先认门WorkBuddy的版本更迭比较快不同版本的设置入口长不太一样。我这边用的版本一般在设置或者偏好设置里能找到“自定义指令Custom Instructions / Rules”的入口有的版本是在新建会话时有个“项目规则”的展开项。还有一些版本支持在项目根目录放一个规则文件比如RULES.md这类它会在每次会话时自动加载。具体入口以你现在安装的版本为准不要死记我这里的路径。我强烈建议你用“配置文件”的方式来管理规则而不是只填UI里那个输入框。原因很简单配置文件可以进版本管理改了什么、谁改的、为什么改都有迹可循还能跟着项目仓库走UI输入框里的内容换台机器就丢了。不管入口长什么样设置页里一般都会有一段提示文字告诉你这些指令会被添加到每次请求的上下文中。看到这个说明你就知道规则的生效机制了它是一次次“注入”到对话里的而不是只在某个角落存着。理解了这一点后面排查“规则不生效”的时候就不会像没头苍蝇一样乱试了。2.3 写规则前先准备一份“项目上下文说明”很多人在设置界面里上来就写“你要遵守代码规范”这种规则约等于没写。因为“规范”太抽象了WorkBuddy不知道你说的规范具体长什么样。我自己的做法是在设置自定义指令之前先单独整理一份项目上下文说明包括项目是干什么的主要技术栈和框架是什么目录结构长什么样每个目录大概负责什么项目里已有的代码风格规范链接或关键约定哪些文件绝对不能动哪些是构建生成文件代码提交前必须检查的事项有哪些这份说明不强求你一次性写全你可以边用边补。但它非常重要它决定了你的规则是“放之四海而皆准的空话”还是“针对你项目的具体约束”。先花二十分钟把项目情况梳理清楚再把它和你的“规矩”一起写进WorkBuddy的自定义指令里效果完全不一样。我见过很多人跳过这一步结果规则写了二十条AI还是经常做出和项目实际结构矛盾的事情。3. 核心实操我给WorkBuddy定规矩的完整过程3.1 第一步把角色和目标写清楚我个人习惯在自定义指令最开头先给WorkBuddy一个角色定义。不是那种“你是世界上最强的程序员”的空话而是类似这样你是一个参与本项目开发的资深工程师。你的目标是在当前代码库的既有约定下完成用户交代的任务保持代码风格一致不引入额外负担。所有改动必须围绕用户请求展开不主动“顺手优化”与任务无关的代码。这段角色定义的作用是给整个规则定基调。模型在生成时会在很大程度上顺着这个角色设定走你写了“资深工程师”比写“助手”更容易得到严谨的回答你写了“保持代码风格一致”比不写更容易让它在动手前先看一眼周边代码。而“你是世界最强程序员”这种话不仅没有帮助反而会让AI过度自信产出更多冒险改动。角色设定的要点是具体、可执行、和真实工作场景绑定。给AI一个它能在代码里“扮演”的身份比给它一个抽象的“强者”标签有用得多。我后来把角色调成“资深工程师”之后WorkBuddy回答问题时明显更愿意补充风险提示和实现权衡而不只是给个能跑的答案。3.2 第二步立行为规矩重点写“什么是好代码”角色定完之后我会接着写行为层。这一层我踩过最大的坑是写规则时全是形容词没有可判定的标准。比如“写出优雅的代码”“高质量的解决方案”这种属于AI听了也不知道该干吗。后来我改成动词加可验收结果效果立刻不一样行为规则 - 命名风格优先沿用当前目录下已有代码的风格新命名遵循项目约定。 - 函数和变量名要能自解释禁止使用a、b、tmp这类无意义命名。 - 每个公共函数必须有简要注释说明用途、参数和返回值。 - 涉及异常处理的代码必须有明确的错误信息和向上层抛出的策略。 - 测试代码必须能独立运行禁止依赖真实网络请求或外部服务。你看每一条都是一个能判断“做没做到”的指标。WorkBuddy在生成时就能对照执行而不是靠猜。这里我建议大家在写行为规则时多从“验收”角度出发而不是从“态度”角度出发。态度条款AI永远会答应但验收条款它必须认真对待。比如“认真处理异常”就远不如“涉及异常处理时必须写清错误信息”来得管用。3.3 第三步给工作流程立“规定动作”代码风格管住之后真正让AI干活靠谱起来的是工作流程的规定动作。这个环节解决的是“先想后写”的问题。大模型一个常见的毛病就是“抢答”你刚把需求说完它代码已经出完了中间的分析、权衡、风险确认全被跳过。这在简单任务上没问题但一旦任务稍微复杂抢答就会埋雷。我的流程类规则是这样写的工作流程 1. 接到任务后先简述你的理解和对现有代码的影响范围再开始动手。 2. 如果任务涉及多文件修改按“逐个文件说明改动原因、修改、验证”的顺序推进。 3. 涉及数据库、配置、依赖升级等敏感改动必须先给出方案并等待确认。 4. 所有改动完成后运行一次相关测试或自查清单并汇报结果。 5. 修改结束后用一句话总结本次变更方便提交信息复用。这套规定动作写进去之后WorkBuddy的干活节奏一下子正常了。它不再是那个“一听需求就冲”的实习生而是会先跟我确认一下理解再动手改完还会主动汇报。我后来把同样的流程规则套用在文档整理、数据清洗这些非编程任务上效果同样明显。只要是复杂任务规定动作永远是稳定输出的前提。3.4 一份能直接抄的完整指令模板接下来给一份我现在在用的精简版模板你可以复制到WorkBuddy的自定义指令里再按自己的项目改改。# WorkBuddy项目规则 ## 角色 你是一名参与本项目开发的资深工程师。你的任务是帮助用户在该项目的既有约定下完成工作保持改动最小、风格一致、过程可验证。 ## 项目背景 - 项目类型基于[技术栈]的[业务类型]应用 - 主要目录src为业务代码tests为测试docs为文档 - 参考规范见项目根目录CONTRIBUTING.md和docs/style.md ## 行为规则 - 只修改与当前任务直接相关的文件禁止顺带优化无关代码。 - 命名风格延续目录内已有代码新命名遵循小写加连字符或项目约定的其他方式。 - 公共函数、接口、组件必须写注释说明用途与关键参数。 - 错误处理要显式给出错误类型和提示信息禁止静默吞掉异常。 - 测试代码必须可以独立运行不依赖真实外部服务。 ## 工作流程 - 开始任务前先用三句话说明任务理解与涉及文件范围。 - 按“分析→修改→验证→总结”的顺序推进不跳过验证。 - 数据库、配置文件、依赖版本等敏感改动必须先给方案得到确认后再继续。 - 任务完成后给出提交信息建议。 ## 禁止事项 - 禁止删除没有明确要求的文件或代码块。 - 禁止把原本正常的格式改造成另一种风格。 - 禁止在未确认的情况下重命名已有接口、组件或函数。模板不长但每个部分都有明确作用。你用的时候不要直接照搬“项目背景”那段而是替换成你自己项目的真实情况。尤其是“参考规范”这一条只有你真的在仓库里放了对应文档AI才会去读否则这句话就是空配置。规则文件记得纳入版本管理后续谁改了都能看到diff这一点对团队使用尤其重要。4. 设置完不生效问题排查与实战避坑4.1 指令没生效先查这两类原因我自己刚设置的时候也遇到过“规则写了不少但AI完全不理”的情况。排查下来九成是两类原因。第一类是层级覆盖问题。比如你在全局规则里写了“只修改相关文件”但当前会话里临时叮嘱了一句“顺便帮我把那个文件也格式化一下”那临时叮嘱优先AI就会违反全局规则。这不是规则没生效是优先级被临时指令覆盖了。遇到这种情况别急着改规则先看会话里有没有和规则冲突的临时指令有的话要么改需求要么明确告诉AI“临时指令只对当前任务有效其他规则继续遵守”。第二类是入口读错文件。有些版本的项目规则不是自动扫描根目录所有文件而是有固定文件名或固定配置目录。如果你把规则写在了一个不被识别的文件里那自然是“不生效”。排查方法是把规则文件名字、所在路径和设置里指定的路径逐一核对确定加载的是同一个文件。我补充一个非常实用的检查技巧设置完规则后先开一个新会话问它“根据当前配置你在本项目里有哪些必须遵守的规则”如果它能完整复述出来说明加载成功如果一脸茫然说明根本没读进去先修加载路径。4.2 规则太硬容易把AI写“废”避坑方面要重点说说过度限制。有一段时间我为了让AI绝对安全把规则写得极其严格每一类操作都规定死。结果AI变得畏手畏脚遇到稍微需要判断的任务就回复“根据规则我不能自动处理”反而更不好用。那几天我甚至怀疑自定义指令是个负优化后来才意识到是自己把规则写成了枷锁。后来我调整了策略把规则分成硬规则和软规则。硬规则是底线比如“禁止删除文件”“禁止改动依赖版本”这类必须无条件遵守软规则是希望比如“尽量保持代码风格一致”“优先使用项目已有的工具函数”这类允许AI根据上下文灵活处理遇到和自己判断矛盾时先说明再做。这个调整效果非常明显AI该谨慎的时候谨慎该自主推进的时候也不会故意卡壳。写规则的尺度有点像带新人红线明确边界内给空间。全是红线新人不敢动没有红线新人到处闯祸。规则文件里我会专门开一节写“硬性禁止”其余行为规则都留出“合理范围内自主判断”的余地这样既稳又不僵。4.3 几条只有实操才知道的细节再分享几个细节这些是文档里一般不会写的。第一规则条目宁少勿多。我实测下来一版指令里核心规则控制在8到12条左右模型遵循率最高。一旦超过二十条模型在生成时容易顾此失彼可能把后面的规则直接忽略掉因为上下文注意力是有限的。规则没被遵守很多时候不是AI不听话而是你一下子规定太多它记不住。宁可把规则写得少而精也不要贪多求全。第二用词要具体到动词。写“不要乱改文件”AI还是不知道该怎么做写“只修改当前任务涉及的文件其他文件保持原样”它就懂了。规则的生命力在于可执行而不是听起来有道理。第三定期让AI做“规则体检”。我每隔一两周会问一次“你认为当前这些自定义指令里有哪些在实际执行时最容易被忽略”它的回答经常能暴露一些规则冲突。比如它告诉我项目规则里写了“禁止改文档”但工作流程里又要求它“总结本次变更”于是它不知道该不该在文档里记录。这种冲突靠人眼反复读很难发现让AI自己说出来效率极高。5. 进阶玩法让规则随项目“活起来”5.1 用文件引用方式让规则自动跟上项目变化如果你的项目规则文件是静态的项目规范一更新指令就过时了。我的做法是在自定义指令里加一句“开工前先阅读项目根目录下的CONTRIBUTING.md和docs/rule.md以其中内容为准。”这样做的妙处在于项目规范文件在版本控制里是活的任何人更新了规范AI下次会话就会自动按新规范来。你不需要频繁去改设置里的自定义指令只要项目文档保持更新就行。类比一下这相当于你不再自己复述一遍公司制度而是告诉AI“制度在墙上干活前自己去看”。省心也不会出现制度和指令不同步的情况。前提是你真有这几份文档存在并且内容确实值得AI参考。没有的话先建一份精简版再引用它。我见过有个项目组把整个团队的编码公约、提交信息规范、分支命名规则全写进一份文档然后在WorkBuddy规则里只留了一行“所有工作遵循仓库docs/team-rules.md的约定”。之后每次规范更新他们只需要改那一份文档所有成员的AI会话第二天自动对齐效率高了不少。5.2 分场景规则一个规则文件搞定多种任务项目跑久了你会发现自己给AI派的任务类型不止一种有时候是写新功能有时候是查旧Bug有时候是写文档有时候是重构代码。不同类型的任务希望AI表现的方式其实不太一样。我现在会在自定义指令里按场景组织规则每个场景用一个触发词开头当任务类型是“写新功能”时 - 先阅读任务相关目录下的现有代码沿用其中的模式和命名风格。 - 新功能要补充对应的测试文件。 当任务类型是“排查Bug”时 - 先复现和定位问题给出可能的原因列表再逐项验证。 - 不要通过大范围重写来掩盖问题优先最小改动修复。 当任务类型是“写文档”时 - 文档按“背景、用法、示例、注意事项”四段组织。 - 代码示例必须简洁能直接复制运行。用这种“当……时……”的结构一份规则文件就能覆盖多种任务还不会互相干扰。我发现WorkBuddy对这种条件式指令的理解比我预想的要好因为它本质上是让模型在拿到任务后先分类再按对应分支执行正好落在它擅长的那类任务模式里。你甚至可以再加一个分支处理“快速答疑”场景告诉它在不确定答案时先说“我不确定”而不是硬编一个方案。5.3 团队共用一套指令的协作姿势如果你不是一个人用WorkBuddy而是整个团队都在用那自定义指令的协作价值会更大。我帮团队整理过一套公共规则做法是建一个rules目录放进仓库里面分“通用规范.md”和按项目拆分的规则文件通过自定义指令统一引用。这样每个成员不需要自己从零写规则只要在WorkBuddy里把规则文件的路径配上就行。团队的规则文件必须像代码一样走评审和更新记录。否则很容易出现“老张改了一版规则老李的AI行为突然变了”的情况。我建议在规则文件开头加一段变更记录表写上日期、修改人、修改原因来源可追溯。这和给代码写提交信息是一回事但很多人忘了规则文件也需要版本管理。另外新成员加入项目时直接把规则文件的路径发给他让他在WorkBuddy里配置引用即可。原来那种“师傅带徒弟式”的挨个叮嘱被一套规则文件替代之后带人效率和输出一致性都会高不少。这也是我比较推荐团队去投入时间的原因统一了“做事的纪律”比统一任何单一代码风格都更根本。最后再分享一个我自己的体会吧。自定义指令这东西不是写一次就能一劳永逸的。随着项目变复杂、踩的坑变多你需要不断给WorkBuddy补新规矩、删旧规矩。我一般每两周会完整过一遍规则文件把最近踩坑总结出的新约束加进去把已经被AI内化成习惯的旧规则删掉让它保持精简。另外第一次设置千万别贪多。先定几条你最在意、最容易踩雷的规则跑一周看看稳定了再加新的。等你慢慢把WorkBuddy“养”出习惯它输出的东西越来越接近你想要的风格你会明显感觉到那些重复性高的活儿交给它比自己做还要稳。这也是我标题里那句话的由来给WorkBuddy定了规矩之后它干活确实比我自己还靠谱。