第一次用 CodeBuddy 跑一个前端改造任务我的感受是它确实能干活但干出来的活儿不像我这个团队的人干的。函数命名方式不同组件拆分粒度不同注释风格不同甚至连错误处理的位置都跟我们平时写的不太一样。结果能用但代码 review 时会非常痛苦。后来我才意识到问题不在 CodeBuddy 本身而在我从来没有告诉过它我们这个项目的规矩。就像来了一个很聪明的新同事能力很强但你不告诉他团队的编码规范、技术选型和历史包袱他交出来的第一版代码一定和你的预期差得很远。CodeBuddy 里的“用户规则”就是用来解决这个问题的。它不是情怀式的设定而是给 AI 一份可执行的、属于你和团队的“工作守则”。规则写得好不好直接决定 CodeBuddy 是“聪明但外行”的临时帮手还是“懂你这个项目的老同事”。1. 先想清楚你是在给 AI 立规矩还是在帮 AI 补记忆很多人第一次听说“创建用户规则”第一反应是哦就是给 AI 设定角色嘛让它扮演一个资深前端工程师。这个理解没错但太浅了。1.1 CodeBuddy 为什么需要用户规则先想一个很现实的问题一个大语言模型在训练阶段看过全世界的开源代码它什么都懂一点。但“什么都懂”恰恰意味着它对你一无所知。它不知道你的项目用的是 Vue 2 还是 Vue 3不知道你们的组件库是 Element Plus 还是自研的不知道你们是必须写 JSDoc 还是注释越少越好不知道哪些历史函数是“虽然看起来很怪但绝对不能动”的。这些信息官方文档里查不到开源代码里也不一定出现。它是一个团队的私有知识是代码评审时反复强调的“隐性共识”。在 CodeBuddy 创建用户规则本质上是把这些隐性共识显式写下来变成 AI 每次对话、每次补全、每次重构时都会参考的上下文。你可以把它理解成给 AI 补上了一段“入职培训”。我见过很多用户规则里只写了“你是一名资深 Java 开发工程师请给出高质量代码”。这种规则不能说没用但它只是给 AI 设定了一个姿态没有给它具体的行为约束。1.2 规则不是在限制 AI而是在降低 AI 的错误率这里要纠正一个常见误区规则越多越细AI 是不是就越死板恰恰相反。对 CodeBuddy 这类工具来说规则的作用是缩小它的猜测范围。模型在生成代码时本质上是在做概率选择。没有规则时它会在多种合理的写法里挑一个概率最高的。但概率最高不一定适合你的项目。有了明确规则它就不用猜了直接按你写明的方向走出错的概率反而低很多。所以好的规则不是“限制 AI”而是“给 AI 提供信息”。每一条规则都是在消解一个不确定性。2. 用户规则、项目规则、Agent 规则先分清这三层打开 CodeBuddy 的规则配置很多新手会困惑到底有哪些入口我该配置哪一个这里要先建立一个分层概念否则后面很容易配置错地方导致规则不生效或者生效了但优先级不是你想要的样子。2.1 三层规则的定位与优先级按照通用实践CodeBuddy 这类 AI 编程工具通常会有三种不同粒度的规则载体规则层级作用范围典型用途维护方式用户级规则当前账号在所有项目内个人编码偏好、通用语言规范、常用技术栈约定IDE 设置或账号配置项目级规则当前项目仓库内团队协作规范、框架版本、目录结构、不被允许的写法随仓库提交并共享Agent / Skill 级规则执行某个特定任务或技能时特定任务的步骤约束、输入输出格式、审查清单和具体技能绑定优先级的通用规则是越具体、作用范围越小的规则优先级越高。也就是说如果用户级规则里写了“注释用中文”项目级规则里写了“对外 API 注释必须用英文”AI 通常会优先遵守项目级规则。这个设计是合理的。用户级规则是你的个人习惯项目级规则是团队在该项目上的共同契约。二者冲突时项目利益通常优先于个人偏好。2.2 什么时候创建用户规则什么时候只用项目规则我的建议是如果你只有一个人在用 CodeBuddy或者你主要在个人项目里使用那用户级规则就够了直接配置当前账号的默认规则。如果你是团队协作项目代码共享那建议优先配置项目级规则并随仓库提交让每个成员 clone 下来就自动生效不需要各自手动设置。如果你有比较固定的任务流程比如“每次改完代码必须跑单测”那可以把这部分写进项目规则或者更进一步做成一个 Agent / Skill。另外从实际工程经验来看项目级规则一定要放进版本控制。代码是团队资产规则同样也是。没有纳入版本控制的规则换一台机器就丢了New 一个同事进来也看不到时间一长就又变成了某个人电脑里的私有配置。3. 创建 CodeBuddy 用户规则从哪里进怎么写确认了层级之后下一步就是实际操作。CodeBuddy 目前主要在 IDE 插件和独立应用里使用不同版本的设置入口可能略有差异但整体思路是一致的。3.1 先确认入口和生效范围常见做法是在 CodeBuddy 设置面板里找到“规则”或“自定义规则”相关入口创建用户级规则。如果你用的是 IDE 插件通常在插件设置页里能找到如果是独立应用一般在账号设置或个人偏好里。有一点要注意入口不同生效范围就不同。如果你在某个项目的工作区设置里写的规则它只对这个项目生效如果你在用户设置或账号设置里写的规则它会对当前账号的所有项目生效。创建之前先想清楚你要写的是哪一个层级的规则。还有一个容易忽略的地方规则保存之后通常不会立即对已经打开的会话生效。很多工具会要求新会话才会重新加载规则或者在修改规则后需要刷新一下。遇到“明明改了规则但行为没变化”的情况先别急着怀疑工具先重新开一个对话试试。3.2 一份能用的用户规则至少包含五个模块我建议不要从网上复制一份看起来很全面、很长很长的规则就完事。规则不是越全越好而是越贴近你自己的使用场景越好。一份真正能用的规则至少应该覆盖五个模块身份与目标定位你希望 CodeBuddy 在你这个场景里扮演什么角色优先解决什么问题。通用编码行为约束命名规范、注释语言、函数拆分粒度、错误处理方式、代码风格。技术栈与项目背景你常用的语言、框架、版本、构建工具、UI 组件库、目录结构。任务执行流程改代码前要不要先解释方案、写完要不要自测、要不要给出改动清单。明确禁止事项哪些事情绝对不能做比如不要随意改公共配置、不要删除看似无用的代码、不要使用某些依赖。下面是一个参考模板你可以按自己的情况裁剪# CodeBuddy 用户规则模板 ## 身份定位 你是一名熟悉前后端全栈开发的工程师当前主要协助我完成 Web 项目的编码、调试和代码评审。 ## 通用行为约束 - 代码注释一律使用中文但命名变量、函数、类使用英文。 - 函数命名使用 camelCase组件命名使用 PascalCase。 - 先分析现状再给出方案不要直接输出一整个文件的重写代码。 - 每次修改后列出变更清单标注涉及的文件和改动原因。 ## 技术栈约定 - 前端Vue 3 TypeScript Vite组件库使用 Element Plus。 - 后端Node.js Express使用 Prisma 作为 ORM。 - 涉及接口返回时统一使用 { code, message, data } 结构。 ## 任务流程 - 接到需求后先简要复述需求再给出实现方案。 - 涉及核心逻辑修改时要求我确认后你再生成代码。 - 代码生成后检查是否存在类型错误和边界条件问题。 ## 禁止事项 - 不要修改 vite.config.ts 之外的构建配置。 - 不要新增没有经过确认的第三方依赖。 - 不要删除测试用例或跳过测试。这个模板可以用但它只是骨架。真正用起来之后你会慢慢往里面加自己的习惯。比如你发现自己特别容易被 AI 的“额外发挥”困扰那就加一条“只完成要求的事不要顺手改动无关代码”。比如你发现 AI 总喜欢把简单问题复杂化那就加一条“优先给出最小改动方案而不是大范围重构方案”。4. 规则不是越多越好关键要写“让 AI 能执行”的话规则写得好不好判断标准只有一个AI 拿到这段话之后能不能稳定地按照它执行。很多规则写得很漂亮但 AI 看完之后还是不知道该怎么做这不是 AI 的问题是规则本身不够“可执行”。4.1 无效规则和有效规则的差别先看两组对比。无效写法“请生成高质量代码。”“注意代码的可维护性。”“请遵守社区最佳实践。”这些话不是不对而是太抽象了。什么叫高质量什么叫可维护每个工程师的理解都不一样AI 更不知道你的标准指什么。有效写法“工具函数必须放在 src/utils 目录并导出为具名函数。”“新增组件时必须拆分为基础组件和业务组件两层。”“所有接口请求必须经过 request.ts 封装禁止在页面里直接调用 axios。”这些规则每一句都可以被验证AI 生成代码后你扫一眼就知道它有没有遵守。规则写得越具体AI 的执行率就越高你后续纠偏的成本就越低。这里有一个很实用的判断标准如果一条规则连你的同事都能一眼看懂并执行那它大概率可以被 AI 执行。如果还需要解释、举例、补充背景那它就还需要继续拆细。4.2 规则数量要克制别把上下文塞爆另一个常见问题是规则越写越长从几行膨胀到几千字。要知道规则并不是无限免费的空间。CodeBuddy 每次处理任务时会把规则作为上下文的一部分传给模型。规则越长留给用户对话和代码内容的上下文空间就越小。规则写到一定程度收益会急剧下降甚至因为过度占用上下文导致模型忘记用户真正想让它做的事情。从经验看用户级规则控制在 300 到 600 字左右比较合适。项目级规则可以稍微长一点但也不要超过 1000 字。重要的不是全而是精。如果你发现自己需要写的规则非常多那就要反思一下是不是这些规则其实更适合放到 Skill 或者 Agent 里规则管理的是“默认状态”Skill 管理的是“特定任务”两者分工不同。一个很现实的建议规则只写那些你反复纠正过 AI 多次的行为。如果某个问题你只遇到一次那就不要写进规则。规则的价值在于长期稳定生效不是记录所有偶发问题。5. 规则建好后为什么有时还是“不听话”配置好规则和规则真正生效中间还隔着一层。我在实际使用中遇到过几次“规则没生效”的情况排查下来发现原因五花八门。5.1 排査链路从现象到原因遇到规则不生效建议按下面的顺序排查不要上来就怀疑是工具 bug看现象是完全没有遵守还是部分遵守是完全无视还是优先级不对先搞清楚具体是哪种“不听话”。看入口和层级你配置的是用户级规则还是项目级规则当前打开的项目有没有它自己的项目级规则把用户级行为覆盖掉了看保存状态规则有没有保存成功保存后有没有重新开一个会话很多工具不会对旧会话重新加载规则。看内容本身规则里有没有相互矛盾的描述比如一边说“不要使用第三方库”一边又说“优先使用成熟的库”这种冲突会让 AI 陷入两难。看上下文占用规则是不是太长了导致模型实际生成时已经“记不住”前面的规则内容。看 IDE 或版本差异CodeBuddy 在插件和独立应用里的行为可能不完全一致。如果你在两个环境之间切换使用规则文件未必同步。这六步里最容易被忽略的是第 2 步。团队项目里经常存在多份规则文件比如项目根目录有自己的规则文件团队仓库里还有一份通用规范。当多份规则同时存在时AI 会按优先级机制处理但处理结果不一定符合你的直觉。5.2 常见坑点规则冲突、过度约束、版本切换规则写多了之后还会出现一个反向问题约束过强AI 变得畏手畏脚。比如你写了一条规则“所有修改都必须列出影响范围”AI 每次都会在任务开始前先输出一大段分析即使只是改一个变量名也不放过。这个时候规则就从“帮助判断”变成了“降低效率”。处理办法是给规则加边界条件。比如改成“涉及接口协议变更或公共组件改动时必须列出影响范围常规参数修改可以直接完成。”也就是说规则也要分主次、分场景不能一刀切。再有一个坑CodeBuddy 相关的工具链迭代很快规则配置本身也可能随版本更新发生变化。比如 WorkBuddy 时代的项目和规则配置迁移到 CodeBuddy 后某些路径、文件名、格式可能不再兼容需要重新调整。迁移旧项目时不要假设所有配置都能原样使用先检查规则文件是否被正确识别再逐步补齐。注意规则配置是一个需要长期维护的对象。不是写完一次就永远不用管每次工具大版本升级、项目技术栈变化、团队规范调整都要同步检查规则是否仍然适用。6. 从规则到 Skill 再到 Agent把 CodeBuddy 用成一套工作流用户规则只是 CodeBuddy 使用的第一层。真正想把它从“对话助手”变成“能稳定交付任务的协作工具”你还需要把规则、Skill、Agent 这三件事串起来。6.1 规则、Skill 和 Agent 怎么配合规则负责定义“AI 在所有场景下的默认行为”它是底座。Skill 负责定义“某个特定领域的专业知识和操作方式”比如常见的“前端页面脚手架生成 Skill”“代码评审 Skill”“数据库变更脚本 Skill”。Agent 则是在 Skill 基础上结合具体任务上下文形成一个可以自主执行多步骤任务的流程单元。用一个类比来理解规则像是公司的员工手册它规定了所有员工的基本原则Skill 像是岗位说明书它定义了某个岗位需要掌握的操作方法Agent 则是一个在明确任务驱动下按照手册和岗位要求去完成一件具体事情的人。如果你只写规则不配置任何 Skill码 CodeBuddy 也能干活但它的能力上限是“通用工程师”。如果你配置了符合你项目场景的 Skill再配合规则里的行为约束CodeBuddy 就更像一个“熟悉你们项目的老工程师”。从社区讨论的热度来看很多人在找 CodeBuddy 的常用前端 Skill说明大家已经意识到单靠提示词和规则覆盖不了深度任务。Skill 的价值在于把复杂的专业知识打包好让 AI 在调用时不需要临时从零组织思路。对大多数开发者我的建议路径是先用规则把你的“默认偏好”固定下来。再为高频任务创建 Skill比如代码生成、测试编写、日志分析。最后再去尝试 Agent 类的多步任务编排。不要一开始就追求完整的 Agent 流程。先让规则和 Skill 跑顺再考虑自动化会稳妥很多。6.2 把规则当成团队资产来维护聊到这里我想再把话题拉回一个持续价值的问题用户规则怎么维护很多个人开发者一开始兴致勃勃写了一套很详细的规则用了一个月之后就再也不更新了因为后面发现 AI 犯的错逐渐减少了规则也就没必要动了。这是好现象但不代表规则不需要维护。更值得推荐的做法是把规则当成代码来管理。它有版本有讨论有变更记录。团队内部每隔一段时间比如一个迭代或一个月review 一次规则文件看看哪些规则已经失效哪些行为反复被纠正但规则里还没覆盖。这个习惯的价值会在团队规模变大、项目复杂度上升之后越来越明显。另外有一个现实问题有用户反馈 CodeBuddy 消耗积分很快。规则在这里也能帮上忙。规则写得好AI 第一次生成的结果就更接近你的预期不需要反复对话修正自然就减少了无效调用。反过来如果规则缺失或写得模糊AI 每次都要靠多轮对话来“猜”你的意图积分消耗自然更大。所以与其抱怨积分不够用不如先检查一下自己的规则是不是太笼统了。建议如果你发现 CodeBuddy 经常需要多轮纠正才能给出可用结果先别急着换工具回头看看自己的规则文件。很多时候不是模型不够聪明是你没有把“什么是可用”说清楚。这篇文章写到这里核心想传递的其实就一句话CodeBuddy 的规则系统是你和 AI 协作的“接口”。接口设计得清晰协作效率就高接口模糊任何模型都很难稳定地产出你满意的结果。如果你现在还没有写过任何规则下一步最该做的事很简单打开 CodeBuddy 的规则设置先写四条规则——我是谁、我用的什么技术栈、代码要遵守哪些基本规范、什么东西绝对不能碰。先写这四条跑一次真实任务再根据结果逐步补充。规则这个东西不追求一次到位追求的是不断靠近你真实的工作方式。它有价值不是因为写得长而是因为它让 AI 变成了一个知道你的规矩、记得住你的规矩、愿意遵守你的规矩的协作对象。