很多开发团队在落地 AI 编程助手时都经历过同一个阶段装好插件体验了几天代码补全和智能问答然后就停在原地了。原因很简单——传统的 AI 编程助手默认情况下是“被动应答”的你问一句它答一句任务一旦跨文件、跨步骤或者需要同时满足团队规范它就很难独立完成。CodeBuddy 的出现其实改变了这个局面。它不只是又一个“能写代码的聊天框”而是一套可以自定义 Agent智能体、Skills技能和 Rules规则的 AI 开发工作台。换句话说你完全可以把 CodeBuddy 当成团队里的“可编程员工”给它定岗位、定职责、定边界让它像游戏里的 NPC 一样在固定的场景下稳定地完成特定任务。本文会围绕“开发团队 AI 员工”这个主题完整拆解 CodeBuddy 的 Agent 相关能力。你会看到Agent 和普通对话有什么区别Skill、Rules 在团队协作里分别承担什么作用如何从零创建一个“测试工程师 NPC”和“代码评审 NPC”以及在实际项目中落地时的避坑经验。这个系列内容的读者可以是前端、后端、测试工程师也可以是技术团队的管理者。读完你不需要对底层大模型原理有多深的理解只需要跟着步骤就能在 IDE 里配置出第一个能够稳定承担重复工作的 AI 员工。1. 从“AI 助手”到“AI 同事”为什么要聊 CodeBuddy 与 Agent1.1 传统 AI 编程助手的三个瓶颈先用最简单的方式描述当前大多数开发者使用 AI 编程助手的现状。第一是单轮问答。大多数时候我们是把代码片段贴给 AI让它“解释一下”“优化一下”“补个注释”。这种用法本质上还是搜索引擎的替代品AI 没有任务闭环的概念自然也无法主动反馈“这里缺少单元测试我需要你确认两个边界条件。”第二是上下文碎片化。团队开发中一个需求往往涉及多个文件、多个模块。普通聊天模式下AI 只能看到你在当前会话中贴出的信息无法在项目维度理解业务背景。于是经常出现“改了一个 bug引出一个新 bug”的情况。第三是缺少角色意识。同一个模型既回答代码问题又回答部署问题还回答产品逻辑问题。输出的风格、深度、关注点和团队期望完全对不上。测试工程师看到的是“一把抓”的回答架构师看到的也是“一把抓”的回答。这三个瓶颈本质上都不是模型能力不够而是“使用方式”的问题。Agent 的出现恰恰就是为了解决这三件事。1.2 Agent 是什么一句话解释Agent 在 AI 领域的严格定义可以写很长但落到工程实践里一句话就能说清楚Agent 是一个能拆解目标、调用工具、查看结果、并在循环中调整执行策略的 AI 执行单元。把它拆成四个部分看目标拆解Agent 拿到一个任务后会先把任务拆成多个步骤例如“先读接口文档再生成 Mock 数据最后输出测试代码”。工具调用Agent 不只是“想”它还能“做”。在 IDE 场景下它可以读取当前文件、搜索项目代码、执行特定命令甚至调用外部 API。结果反馈每执行完一个步骤Agent 会观察输出是否正确再决定继续还是重试。循环调整如果第一次生成结果不符合预期Agent 可以根据错误信息进行自我修复而不是结束会话。普通对话模式的逻辑是“输入 - 输出”Agent 的模式则是“输入 - 拆解 - 执行 - 观察 - 调整 - 输出”。这就是为什么说 Agent 更像“员工”而不是“助手”。1.3 CodeBuddy 在 AI 编程工具里的定位CodeBuddy 是腾讯推出的一款 AI 编程助手支持 VS Code、JetBrains 系列 IDE 以及命令行环境。它包含基础的代码补全、代码解释、测试生成、代码评审等功能也提供了面向更复杂任务的自定义 Agent 与 Skills 机制。在实际使用体验中CodeBuddy 有几个特征比较适合团队场景支持在 IDE 内直接会话读取当前项目上下文支持配置 Rules把团队规范固化到 AI 的生成行为里支持创建自定义技能与 Agent让不同角色使用不同的提示词与执行策略可以在对话中切换模型给不同任务分配不同成本的模型。当然CodeBuddy 本身还在快速迭代中不同版本的界面和参数名可能会有调整。本文中的示例以通用配置思路为主具体按钮位置和字段名请以你当前安装的版本为准。1.4 本文能帮你获得什么读完本文你将能够分清 Agent、Skill、Rules 三个概念在 CodeBuddy 中分别承担什么作用从零创建一个“测试工程师 NPC”并让它按照团队规范生成可用的测试代码设计一个包含“需求分析 - 编码 - 评审 - 测试”的多角色 AI 协作流程掌握 Agent 落地过程中的常见报错排查方法和安全边界设置。后面的内容不会只讲概念而是会一步步带你创建出真实可用的配置。2. 核心名词拆解NPC、Agent、Skill、Rules2.1 NPC把 AI 角色化先解释标题里的 NPC。NPC 原本是游戏术语指“非玩家角色”Non-Player Character。游戏里的 NPC 通常有固定的身份、职责、对话内容和行为边界比如“铁匠 NPC 只负责锻造装备不负责发布主线任务”。把这个概念迁移到开发团队里你就很好理解什么叫“AI 员工”了与其用一个万能的 AI 回答所有问题不如把工作拆成一个个角色让每个 AI 只负责一类职责。比如测试工程师 NPC只负责测试用例设计、测试代码生成、边界条件分析。代码评审 NPC只负责审查代码规范、发现潜在 bug、输出评审意见。文档 NPC只负责根据代码和需求生成接口文档、变更说明、README。角色化的好处是显而易见的提示词更聚焦输出质量更稳定团队规范和约束更容易注入也更容易被其他成员信任。这就是“AI 员工”和“AI 助手”最大的区别。2.2 AgentAI 员工的最小执行单元在 CodeBuddy 的体系里Agent 可以理解为承载某个 NPC 角色的“执行单元”。它通常包含以下几个要素角色定义告诉模型你是谁负责什么。目标描述明确接到任务后要输出什么结果。可用工具允许模型使用哪些 IDE 能力比如读取文件、运行测试、搜索代码。边界约束哪些事情不能做哪些文件不能改。一个好的 Agent 定义读起来应该像一份“岗位说明书”。岗位说明书写得越清楚员工干活的偏差就越小。反之如果你只写一句“你是一个测试工程师”大模型输出的内容一定会非常飘。2.3 Skill可复用的技能包Skill技能在 CodeBuddy 中的定位是“某个 Agent 可以调用的能力模块”。举个例子测试工程师 NPC 可能需要多项技能JUnit 单元测试生成技能Mock 数据生成技能覆盖率分析技能API 冒烟测试技能。每一项技能都可以单独维护、单独升级。这样当团队从 JUnit 切到 TestNG 时只需要修改对应技能文件而不需要重写整个 Agent。从实现角度一个 Skill 通常包含技能用途说明、触发条件、执行步骤、输出格式、约束条件。说得通俗一点它就是你喂给大模型的一份“操作手册”。2.4 Rules 与三者组合方式Rules 是团队级的“法律法规”。在团队开发中最让人头疼的问题之一就是 AI 生成代码“风格不对”。有的人用 4 空格缩进有的人用 2 空格有的项目要求所有接口返回 Result 包装有的项目禁止在 Service 里直接操作 Entity。这类规范如果只写在文档里大模型是看不到的。通过 Rules你可以把团队的编码规范、目录结构约定、提交信息格式、命名规则等内容固化到 AI 的执行上下文中。这样无论哪个成员、哪个 Agent 去生成代码都会自动遵守这些约束。用一个简单的层次关系来理解三者组合最底层是 Rules规定“团队允许什么、禁止什么”中间层是 Skill提供“完成某类任务的具体方法”最上层是 Agent定义“什么角色在什么场景下调用哪些 Skill遵守哪些 Rules”。当三者对齐之后AI 就不再是一个随机发挥的对话模型而是一个行为可预期的团队成员。下面我们从环境准备开始把这一套组合实际搭起来。3. 环境准备与版本说明3.1 安装 CodeBuddy 插件VS Code 示例以 VS Code 为例安装步骤很简单打开 VS Code进入扩展市场Extensions搜索 “CodeBuddy”找到官方插件后点击 Install安装完成后在侧边栏找到 CodeBuddy 图标点击进入登录页。登录时一般支持企业账号或个人账号。如果你是团队使用建议由团队负责人统一申请并分配权限这样后续管理 Rules 和技能也更方便。3.2 JetBrains 系 IDE 的安装方式JetBrains 系的 IDEA、PyCharm 等安装方式类似在 Settings - Plugins 中搜索 CodeBuddy 并安装重启 IDE 后即可看到入口。不同 IDE 的插件市场可能存在小差异如果搜索不到可以到 CodeBuddy 官方文档中查看当前支持的 IDE 列表。由于 JetBrains 系 IDE 和 VS Code 的项目模型不同CodeBuddy 在两端能够访问的上下文细节也会有差异。团队内部建议统一主力 IDE方便沉淀相同的使用经验。3.3 登录、模型选择与网络要求登录后通常需要在设置面板里选择一个默认模型。CodeBuddy 一般会提供多个模型供选择不同模型在代码生成速度、理解能力、价格上各有差异。作为起步阶段建议遵循两条原则日常补全和简单问答选响应更快的模型复杂 Agent 任务和长上下文分析选推理能力更强的模型。需要说明的是不同版本对模型的支持范围不一样本文不具体指定某个模型名称。你只需要在模型选择界面找到当前可用的选项按任务复杂度做分配即可。另外Agent 执行过程中可能需要读取远程上下文或调用在线服务请确保你的网络环境能够正常访问 CodeBuddy 服务。如果企业网络存在访问控制需要让网络负责人按公司 IT 流程申请放行 CodeBuddy 相关服务域名并且只能通过公司批准的网络策略访问。不要使用任何非正规方式绕过企业网络限制这是团队落地时必须要守住的红线。3.4 建议的测试项目结构为了验证 Agent 效果建议先在一个小项目中做实验不要直接在生产仓库里调试。下面是一个最小可用的实验目录结构demo-project/ ├── .codebuddy/ │ ├── rules/ │ │ └── team-rules.md │ └── skills/ │ └── java-unit-test-generator.md ├── src/ │ └── main/ │ └── java/ │ └── com/example/demo/ │ └── OrderService.java └── pom.xml将 CodeBuddy 相关的规则和技能文件放在项目目录下并通过版本管理工具提交可以保证团队所有成员使用同一套配置。这个做法对团队落地尤其重要。4. 实战创建第一个团队 AI 员工现在进入本文的核心部分。我们按照“测试工程师 NPC”这个角色完整走一遍从设计到验证的流程。4.1 选定角色测试工程师 NPC在创建 Agent 之前先明确测试工程师 NPC 的岗位说明书。这个角色的职责是根据方法签名和业务逻辑生成符合团队规范的单元测试分析需求变更输出测试矩阵识别高风险边界条件补充特殊场景测试不修改业务代码只生成测试文件。岗位边界是不能直接修改 src/main 下的业务代码不能依赖真实数据库或外部服务做测试生成的测试必须遵循团队使用的测试框架版本。把这份“岗位说明书”写成提示词就构成了 Agent 的核心。4.2 设计 Skill单元测试生成技能接下来创建一个 Skill 文件用它描述“如何生成单元测试”。下面是一个参考格式使用 Markdown 编写。不同版本的 CodeBuddy 可能对技能文件的格式要求不同请以你当前版本的“新建技能”向导为准以下内容更多是表达配置思路。--- name: java-unit-test-generator description: 根据方法签名和业务逻辑生成 JUnit 5 单元测试 version: 1.0.0 triggers: - 生成单测 - generate unit test - 补充测试 --- # 执行步骤 1. 阅读目标方法的源码提取参数、返回值、异常路径。 2. 识别外部依赖如数据库、Redis、RPC 客户端。 3. 使用 Mockito 对依赖进行隔离确保测试不依赖外部环境。 4. 按团队规范生成测试类类名规则为 {ClassName}Test.java。 5. 生成完成后检查代码覆盖率补充关键分支用例。 # 输出格式 - 测试文件位置src/test/java/{包路径}/{ClassName}Test.java - 每个测试方法必须注明覆盖的业务场景。 - 测试方法命名采用 given_when_then 风格。 # 约束 - 只允许新增测试文件不允许修改被测业务类。 - 不使用真实数据库连接所有外部依赖必须 mock。 - 遵守团队 Checkstyle 与 SpotBugs 规则。这份 Skill 文件里包含了“触发词、执行步骤、输出格式、约束条件”四类信息。大模型在执行时会参考这些内容而不是凭空发挥。4.3 配置 Rules团队测试规范然后把团队规范写入 Rules 文件。# 团队 Rules测试相关 - 测试代码统一放在 src/test/java 目录禁止放在 main 目录。 - 单元测试使用 JUnit 5断言使用 AssertJ。 - 外部依赖数据库、缓存、消息队列必须通过 Mockito mock。 - 禁止在测试代码中使用 Thread.sleep如需等待请使用 Awaitility。 - 新代码的单元测试覆盖率不得低于 80%核心业务模块不得低于 90%。 - 测试用例必须覆盖正常流程、异常流程和边界值。 - 提交前必须本地执行 mvn test确保全部通过。Rules 文件本身是 Markdown 文本CodeBuddy 会在合适的上下文中把它注入给模型。它的价值在于不同成员、不同 Agent 生成的测试代码会保持一致的风格减少代码评审阶段的返工。4.4 组装 Agent测试工程师 NPC现在把角色定义、Skill、Rules 组合成一个 Agent。在 CodeBuddy 的 Agent 配置界面中你可以填写类似下面的内容角色测试工程师 NPC 职责 - 负责项目中所有与测试质量相关的工作 - 接到需求或代码变更后优先输出测试计划 - 可以调用技能java-unit-test-generator - 必须遵守项目 Rules 中与测试相关的全部约束 工作流程 1. 当收到测试任务时先读取相关业务代码和最近的需求描述 2. 输出测试矩阵包含用例编号、业务场景、输入、预期结果 3. 调用技能生成测试代码 4. 运行测试若发现失败分析原因并修复测试 5. 输出测试结果摘要 禁止事项 - 不修改 src/main 下任何业务代码 - 不绕过 Rules 中的覆盖率要求保存后这个测试工程师 NPC 就创建完成了。下面我们来实际调用它。4.5 在 IDE 中调用并验证以 VS Code 为例在 CodeBuddy 对话窗口中切换到刚才创建的 Agent然后在对话中输入请为 OrderService 中的 createOrder 方法生成单元测试如果配置正确Agent 会按照 Skill 中的步骤执行读取 OrderService 的源码识别其中的外部依赖例如订单号生成器、库存服务生成 Mock 依赖的测试代码给出测试类文件和用例说明。系统会自动生成一个类似下面的测试摘要测试文件 CodeBuddy实战：用Agent、Skill、Rules打造团队AI测试工程师
很多开发团队在落地 AI 编程助手时都经历过同一个阶段装好插件体验了几天代码补全和智能问答然后就停在原地了。原因很简单——传统的 AI 编程助手默认情况下是“被动应答”的你问一句它答一句任务一旦跨文件、跨步骤或者需要同时满足团队规范它就很难独立完成。CodeBuddy 的出现其实改变了这个局面。它不只是又一个“能写代码的聊天框”而是一套可以自定义 Agent智能体、Skills技能和 Rules规则的 AI 开发工作台。换句话说你完全可以把 CodeBuddy 当成团队里的“可编程员工”给它定岗位、定职责、定边界让它像游戏里的 NPC 一样在固定的场景下稳定地完成特定任务。本文会围绕“开发团队 AI 员工”这个主题完整拆解 CodeBuddy 的 Agent 相关能力。你会看到Agent 和普通对话有什么区别Skill、Rules 在团队协作里分别承担什么作用如何从零创建一个“测试工程师 NPC”和“代码评审 NPC”以及在实际项目中落地时的避坑经验。这个系列内容的读者可以是前端、后端、测试工程师也可以是技术团队的管理者。读完你不需要对底层大模型原理有多深的理解只需要跟着步骤就能在 IDE 里配置出第一个能够稳定承担重复工作的 AI 员工。1. 从“AI 助手”到“AI 同事”为什么要聊 CodeBuddy 与 Agent1.1 传统 AI 编程助手的三个瓶颈先用最简单的方式描述当前大多数开发者使用 AI 编程助手的现状。第一是单轮问答。大多数时候我们是把代码片段贴给 AI让它“解释一下”“优化一下”“补个注释”。这种用法本质上还是搜索引擎的替代品AI 没有任务闭环的概念自然也无法主动反馈“这里缺少单元测试我需要你确认两个边界条件。”第二是上下文碎片化。团队开发中一个需求往往涉及多个文件、多个模块。普通聊天模式下AI 只能看到你在当前会话中贴出的信息无法在项目维度理解业务背景。于是经常出现“改了一个 bug引出一个新 bug”的情况。第三是缺少角色意识。同一个模型既回答代码问题又回答部署问题还回答产品逻辑问题。输出的风格、深度、关注点和团队期望完全对不上。测试工程师看到的是“一把抓”的回答架构师看到的也是“一把抓”的回答。这三个瓶颈本质上都不是模型能力不够而是“使用方式”的问题。Agent 的出现恰恰就是为了解决这三件事。1.2 Agent 是什么一句话解释Agent 在 AI 领域的严格定义可以写很长但落到工程实践里一句话就能说清楚Agent 是一个能拆解目标、调用工具、查看结果、并在循环中调整执行策略的 AI 执行单元。把它拆成四个部分看目标拆解Agent 拿到一个任务后会先把任务拆成多个步骤例如“先读接口文档再生成 Mock 数据最后输出测试代码”。工具调用Agent 不只是“想”它还能“做”。在 IDE 场景下它可以读取当前文件、搜索项目代码、执行特定命令甚至调用外部 API。结果反馈每执行完一个步骤Agent 会观察输出是否正确再决定继续还是重试。循环调整如果第一次生成结果不符合预期Agent 可以根据错误信息进行自我修复而不是结束会话。普通对话模式的逻辑是“输入 - 输出”Agent 的模式则是“输入 - 拆解 - 执行 - 观察 - 调整 - 输出”。这就是为什么说 Agent 更像“员工”而不是“助手”。1.3 CodeBuddy 在 AI 编程工具里的定位CodeBuddy 是腾讯推出的一款 AI 编程助手支持 VS Code、JetBrains 系列 IDE 以及命令行环境。它包含基础的代码补全、代码解释、测试生成、代码评审等功能也提供了面向更复杂任务的自定义 Agent 与 Skills 机制。在实际使用体验中CodeBuddy 有几个特征比较适合团队场景支持在 IDE 内直接会话读取当前项目上下文支持配置 Rules把团队规范固化到 AI 的生成行为里支持创建自定义技能与 Agent让不同角色使用不同的提示词与执行策略可以在对话中切换模型给不同任务分配不同成本的模型。当然CodeBuddy 本身还在快速迭代中不同版本的界面和参数名可能会有调整。本文中的示例以通用配置思路为主具体按钮位置和字段名请以你当前安装的版本为准。1.4 本文能帮你获得什么读完本文你将能够分清 Agent、Skill、Rules 三个概念在 CodeBuddy 中分别承担什么作用从零创建一个“测试工程师 NPC”并让它按照团队规范生成可用的测试代码设计一个包含“需求分析 - 编码 - 评审 - 测试”的多角色 AI 协作流程掌握 Agent 落地过程中的常见报错排查方法和安全边界设置。后面的内容不会只讲概念而是会一步步带你创建出真实可用的配置。2. 核心名词拆解NPC、Agent、Skill、Rules2.1 NPC把 AI 角色化先解释标题里的 NPC。NPC 原本是游戏术语指“非玩家角色”Non-Player Character。游戏里的 NPC 通常有固定的身份、职责、对话内容和行为边界比如“铁匠 NPC 只负责锻造装备不负责发布主线任务”。把这个概念迁移到开发团队里你就很好理解什么叫“AI 员工”了与其用一个万能的 AI 回答所有问题不如把工作拆成一个个角色让每个 AI 只负责一类职责。比如测试工程师 NPC只负责测试用例设计、测试代码生成、边界条件分析。代码评审 NPC只负责审查代码规范、发现潜在 bug、输出评审意见。文档 NPC只负责根据代码和需求生成接口文档、变更说明、README。角色化的好处是显而易见的提示词更聚焦输出质量更稳定团队规范和约束更容易注入也更容易被其他成员信任。这就是“AI 员工”和“AI 助手”最大的区别。2.2 AgentAI 员工的最小执行单元在 CodeBuddy 的体系里Agent 可以理解为承载某个 NPC 角色的“执行单元”。它通常包含以下几个要素角色定义告诉模型你是谁负责什么。目标描述明确接到任务后要输出什么结果。可用工具允许模型使用哪些 IDE 能力比如读取文件、运行测试、搜索代码。边界约束哪些事情不能做哪些文件不能改。一个好的 Agent 定义读起来应该像一份“岗位说明书”。岗位说明书写得越清楚员工干活的偏差就越小。反之如果你只写一句“你是一个测试工程师”大模型输出的内容一定会非常飘。2.3 Skill可复用的技能包Skill技能在 CodeBuddy 中的定位是“某个 Agent 可以调用的能力模块”。举个例子测试工程师 NPC 可能需要多项技能JUnit 单元测试生成技能Mock 数据生成技能覆盖率分析技能API 冒烟测试技能。每一项技能都可以单独维护、单独升级。这样当团队从 JUnit 切到 TestNG 时只需要修改对应技能文件而不需要重写整个 Agent。从实现角度一个 Skill 通常包含技能用途说明、触发条件、执行步骤、输出格式、约束条件。说得通俗一点它就是你喂给大模型的一份“操作手册”。2.4 Rules 与三者组合方式Rules 是团队级的“法律法规”。在团队开发中最让人头疼的问题之一就是 AI 生成代码“风格不对”。有的人用 4 空格缩进有的人用 2 空格有的项目要求所有接口返回 Result 包装有的项目禁止在 Service 里直接操作 Entity。这类规范如果只写在文档里大模型是看不到的。通过 Rules你可以把团队的编码规范、目录结构约定、提交信息格式、命名规则等内容固化到 AI 的执行上下文中。这样无论哪个成员、哪个 Agent 去生成代码都会自动遵守这些约束。用一个简单的层次关系来理解三者组合最底层是 Rules规定“团队允许什么、禁止什么”中间层是 Skill提供“完成某类任务的具体方法”最上层是 Agent定义“什么角色在什么场景下调用哪些 Skill遵守哪些 Rules”。当三者对齐之后AI 就不再是一个随机发挥的对话模型而是一个行为可预期的团队成员。下面我们从环境准备开始把这一套组合实际搭起来。3. 环境准备与版本说明3.1 安装 CodeBuddy 插件VS Code 示例以 VS Code 为例安装步骤很简单打开 VS Code进入扩展市场Extensions搜索 “CodeBuddy”找到官方插件后点击 Install安装完成后在侧边栏找到 CodeBuddy 图标点击进入登录页。登录时一般支持企业账号或个人账号。如果你是团队使用建议由团队负责人统一申请并分配权限这样后续管理 Rules 和技能也更方便。3.2 JetBrains 系 IDE 的安装方式JetBrains 系的 IDEA、PyCharm 等安装方式类似在 Settings - Plugins 中搜索 CodeBuddy 并安装重启 IDE 后即可看到入口。不同 IDE 的插件市场可能存在小差异如果搜索不到可以到 CodeBuddy 官方文档中查看当前支持的 IDE 列表。由于 JetBrains 系 IDE 和 VS Code 的项目模型不同CodeBuddy 在两端能够访问的上下文细节也会有差异。团队内部建议统一主力 IDE方便沉淀相同的使用经验。3.3 登录、模型选择与网络要求登录后通常需要在设置面板里选择一个默认模型。CodeBuddy 一般会提供多个模型供选择不同模型在代码生成速度、理解能力、价格上各有差异。作为起步阶段建议遵循两条原则日常补全和简单问答选响应更快的模型复杂 Agent 任务和长上下文分析选推理能力更强的模型。需要说明的是不同版本对模型的支持范围不一样本文不具体指定某个模型名称。你只需要在模型选择界面找到当前可用的选项按任务复杂度做分配即可。另外Agent 执行过程中可能需要读取远程上下文或调用在线服务请确保你的网络环境能够正常访问 CodeBuddy 服务。如果企业网络存在访问控制需要让网络负责人按公司 IT 流程申请放行 CodeBuddy 相关服务域名并且只能通过公司批准的网络策略访问。不要使用任何非正规方式绕过企业网络限制这是团队落地时必须要守住的红线。3.4 建议的测试项目结构为了验证 Agent 效果建议先在一个小项目中做实验不要直接在生产仓库里调试。下面是一个最小可用的实验目录结构demo-project/ ├── .codebuddy/ │ ├── rules/ │ │ └── team-rules.md │ └── skills/ │ └── java-unit-test-generator.md ├── src/ │ └── main/ │ └── java/ │ └── com/example/demo/ │ └── OrderService.java └── pom.xml将 CodeBuddy 相关的规则和技能文件放在项目目录下并通过版本管理工具提交可以保证团队所有成员使用同一套配置。这个做法对团队落地尤其重要。4. 实战创建第一个团队 AI 员工现在进入本文的核心部分。我们按照“测试工程师 NPC”这个角色完整走一遍从设计到验证的流程。4.1 选定角色测试工程师 NPC在创建 Agent 之前先明确测试工程师 NPC 的岗位说明书。这个角色的职责是根据方法签名和业务逻辑生成符合团队规范的单元测试分析需求变更输出测试矩阵识别高风险边界条件补充特殊场景测试不修改业务代码只生成测试文件。岗位边界是不能直接修改 src/main 下的业务代码不能依赖真实数据库或外部服务做测试生成的测试必须遵循团队使用的测试框架版本。把这份“岗位说明书”写成提示词就构成了 Agent 的核心。4.2 设计 Skill单元测试生成技能接下来创建一个 Skill 文件用它描述“如何生成单元测试”。下面是一个参考格式使用 Markdown 编写。不同版本的 CodeBuddy 可能对技能文件的格式要求不同请以你当前版本的“新建技能”向导为准以下内容更多是表达配置思路。--- name: java-unit-test-generator description: 根据方法签名和业务逻辑生成 JUnit 5 单元测试 version: 1.0.0 triggers: - 生成单测 - generate unit test - 补充测试 --- # 执行步骤 1. 阅读目标方法的源码提取参数、返回值、异常路径。 2. 识别外部依赖如数据库、Redis、RPC 客户端。 3. 使用 Mockito 对依赖进行隔离确保测试不依赖外部环境。 4. 按团队规范生成测试类类名规则为 {ClassName}Test.java。 5. 生成完成后检查代码覆盖率补充关键分支用例。 # 输出格式 - 测试文件位置src/test/java/{包路径}/{ClassName}Test.java - 每个测试方法必须注明覆盖的业务场景。 - 测试方法命名采用 given_when_then 风格。 # 约束 - 只允许新增测试文件不允许修改被测业务类。 - 不使用真实数据库连接所有外部依赖必须 mock。 - 遵守团队 Checkstyle 与 SpotBugs 规则。这份 Skill 文件里包含了“触发词、执行步骤、输出格式、约束条件”四类信息。大模型在执行时会参考这些内容而不是凭空发挥。4.3 配置 Rules团队测试规范然后把团队规范写入 Rules 文件。# 团队 Rules测试相关 - 测试代码统一放在 src/test/java 目录禁止放在 main 目录。 - 单元测试使用 JUnit 5断言使用 AssertJ。 - 外部依赖数据库、缓存、消息队列必须通过 Mockito mock。 - 禁止在测试代码中使用 Thread.sleep如需等待请使用 Awaitility。 - 新代码的单元测试覆盖率不得低于 80%核心业务模块不得低于 90%。 - 测试用例必须覆盖正常流程、异常流程和边界值。 - 提交前必须本地执行 mvn test确保全部通过。Rules 文件本身是 Markdown 文本CodeBuddy 会在合适的上下文中把它注入给模型。它的价值在于不同成员、不同 Agent 生成的测试代码会保持一致的风格减少代码评审阶段的返工。4.4 组装 Agent测试工程师 NPC现在把角色定义、Skill、Rules 组合成一个 Agent。在 CodeBuddy 的 Agent 配置界面中你可以填写类似下面的内容角色测试工程师 NPC 职责 - 负责项目中所有与测试质量相关的工作 - 接到需求或代码变更后优先输出测试计划 - 可以调用技能java-unit-test-generator - 必须遵守项目 Rules 中与测试相关的全部约束 工作流程 1. 当收到测试任务时先读取相关业务代码和最近的需求描述 2. 输出测试矩阵包含用例编号、业务场景、输入、预期结果 3. 调用技能生成测试代码 4. 运行测试若发现失败分析原因并修复测试 5. 输出测试结果摘要 禁止事项 - 不修改 src/main 下任何业务代码 - 不绕过 Rules 中的覆盖率要求保存后这个测试工程师 NPC 就创建完成了。下面我们来实际调用它。4.5 在 IDE 中调用并验证以 VS Code 为例在 CodeBuddy 对话窗口中切换到刚才创建的 Agent然后在对话中输入请为 OrderService 中的 createOrder 方法生成单元测试如果配置正确Agent 会按照 Skill 中的步骤执行读取 OrderService 的源码识别其中的外部依赖例如订单号生成器、库存服务生成 Mock 依赖的测试代码给出测试类文件和用例说明。系统会自动生成一个类似下面的测试摘要测试文件