AI编程提效指南

写一个数字金额转人民币大写形式的工具类，类里写一个Main方法测试123456.12，结果应是壹拾贰万叁仟肆佰伍拾陆元壹角贰分

package com.xxx.utils;public class NumberToChineseCurrencyUtil {   private static final String[] DIGITS = new String[]{"零", "壹", "贰", "叁", "肆", "伍", "陆", "柒", "捌", "玖"};   private static final String[] UNITS = new String[]{"", "拾", "佰", "仟"};   private static final String[] BIG_UNITS = new String[]{"", "万", "亿", "兆"};   private static final String[] ANGULAR_UNITS = new String[]{"角", "分"};   public NumberToChineseCurrencyUtil() {   }   public static String convertToChineseCurrency(double var0) {      if (var0 < 0.0) {         throw new IllegalArgumentException("金额不能为负数");      } else {         long var2 = (long)var0;         long var4 = Math.round((var0 - (double)var2) * 100.0);         String var6 = convertIntegerPart(var2);         String var7 = convertDecimalPart(var4);         if (var6.isEmpty()) {            return var7.isEmpty() ? "零元整" : var7;         } else {            return var7.isEmpty() ? var6 + "元整" : var6 + "元" + var7;         }      }   }   private static String convertIntegerPart(long var0) {      if (var0 == 0L) {         return "";      } else {         StringBuilder var2 = new StringBuilder();         String var3 = String.valueOf(var0);         int var4 = var3.length();         int var5 = (var4 + 3) / 4;         String[] var6 = new String[var5];         int var8;         for(int var7 = 0; var7 < var5; ++var7) {            var8 = Math.max(0, var4 - (var7 + 1) * 4);            int var9 = var4 - var7 * 4;            var6[var5 - 1 - var7] = var3.substring(var8, var9);         }         boolean var11 = false;         for(var8 = 0; var8 < var5; ++var8) {            String var12 = var6[var8];            String var10 = convertGroup(var12);            if (!var10.isEmpty()) {               if (var11 && !var10.startsWith("零")) {                  var2.append("零");               }               var2.append(var10);               if (!BIG_UNITS[var5 - 1 - var8].isEmpty()) {                  var2.append(BIG_UNITS[var5 - 1 - var8]);               }               var11 = var12.length() < 4;            } else if (var8 < var5 - 1) {               var11 = true;            }         }         return var2.toString();      }   }   private static String convertGroup(String var0) {      StringBuilder var1 = new StringBuilder();      int var2 = var0.length();      boolean var3 = false;      for(int var4 = 0; var4 < var2; ++var4) {         int var5 = var0.charAt(var4) - 48;         if (var5 != 0) {            if (var3) {               var1.append("零");               var3 = false;            }            var1.append(DIGITS[var5]);            if (var4 < var2 - 1) {               var1.append(UNITS[var2 - 1 - var4]);            }         } else if (var1.length() > 0 && !var3) {            var3 = true;         }      }      return var1.toString();   }   private static String convertDecimalPart(long var0) {      if (var0 == 0L) {         return "";      } else {         StringBuilder var2 = new StringBuilder();         long var3 = var0 / 10L;         long var5 = var0 % 10L;         if (var3 > 0L) {            var2.append(DIGITS[(int)var3]).append(ANGULAR_UNITS[0]);         }         if (var5 > 0L) {            var2.append(DIGITS[(int)var5]).append(ANGULAR_UNITS[1]);         }         return var2.toString();      }   }   public static void main(String[] var0) {      double var1 = 123456.12;      String var3 = convertToChineseCurrency(var1);      System.out.println(var1 + " 转换为人民币大写：" + var3);      System.out.println("额外测试用例：");      System.out.println("0.00 -> " + convertToChineseCurrency(0.0));      System.out.println("1.00 -> " + convertToChineseCurrency(1.0));      System.out.println("10.10 -> " + convertToChineseCurrency(10.1));      System.out.println("101.01 -> " + convertToChineseCurrency(101.01));      System.out.println("10000 -> " + convertToChineseCurrency(10000.0));      System.out.println("100000000 -> " + convertToChineseCurrency(1.0E8));   }}

---trigger: always_onalwaysApply: true---# xxx 项目规则文档## 概述本目录包含xxx订单系统的完整开发规范和规则文档,涵盖项目结构、命名规范、开发标准、业务常量、设计模式等方面。## 规则文件清单### 1. [项目结构规范](common/project-structure.md)- **用途**: 定义项目模块划分和目录结构- **适用场景**:   - 创建新模块时参考模块命名和结构  - 添加新的包或目录时确定位置  - 理解各模块的职责和依赖关系- **核心内容**:  - 模块划分(common/service/job/consumer/data等)  - 包结构规范  - 资源文件组织  - 依赖关系  - 启动类配置### 2. [命名规范](common/naming-conventions.md)- **用途**: 统一代码命名风格- **适用场景**:  - 创建类、接口、方法时  - 定义变量、常量时  - 命名数据库表和字段时- **核心内容**:  - 包命名规范  - 类命名规范(DTO/Entity/Service/Mapper等)  - 方法命名规范  - 字段和变量命名规范  - 常量定义规范### 3. [开发规范](common/development.md)- **用途**: 指导日常开发工作- **适用场景**:  - 编写业务代码时  - 集成第三方服务时  - 代码评审时- **核心内容**:  - 技术选型  - 分层架构  - MyBatis开发规范  - Dubbo RPC规范  - 消息队列规范  - 事务管理  - 异常处理  - 日志规范  - 缓存使用  - 分库分表  - 测试规范### 4. [业务常量规范](common/constants.md)- **用途**: 统一管理系统常量- **适用场景**:  - 定义MQ Topic/Tag时  - 定义Redis Key时  - 定义分布式锁Key时  - 使用业务常量时- **核心内容**:  - MQ消息常量(Topic/Tag/Group)  - Redis Key常量  - 分布式锁Key常量  - 数据库相关常量  - 业务费率常量  - URL跳转常量### 5. [策略模式规范](common/strategy-pattern.md)- **用途**: 指导策略模式的实现- **适用场景**:  - 多种业务类型需要不同处理逻辑时  - 需要动态选择算法或处理方式时  - 替代大量if-else分支时- **核心内容**:  - 策略枚举定义  - 策略接口定义  - 策略实现规范  - 策略使用方法  - 策略扩展指南  - 项目中的策略模式应用案例### 6. [枚举规范](common/enums.md)- **用途**: 统一枚举定义和使用方式- **适用场景**:  - 定义状态、类型等固定值时  - 替代常量定义时  - 需要业务逻辑封装时- **核心内容**:  - 枚举结构规范  - 枚举命名规范  - 带业务逻辑的枚举  - 策略枚举  - 枚举使用示例  - 状态流转控制  - 项目核心枚举### 7. [DTO/Entity转换规范](common/dto-entity-conversion.md)- **用途**: 规范数据对象之间的转换- **适用场景**:  - Entity转DTO时  - DTO转Entity时  - 复杂对象聚合转换时- **核心内容**:  - 转换工具选择  - Entity->RespDTO转换  - ReqDTO->Entity转换  - Convert类规范  - 转换最佳实践  - 常见场景示例### 8. [单元测试规范](common/testing.md)- **用途**: 指导单元测试编写- **适用场景**:  - 编写Service层测试时  - 编写Mapper层测试时  - Mock外部依赖时  - 验证测试覆盖率时- **核心内容**:  - 测试框架和工具  - 测试类命名规范  - Service层测试模板  - Mapper层测试模板  - Mock使用规范  - 断言规范  - 测试覆盖率要求  - 测试最佳实践## 使用指南### 新人入门顺序1. 阅读[项目结构规范](common/project-structure.md) - 了解整体架构2. 阅读[命名规范](common/naming-conventions.md) - 掌握命名约定3. 阅读[开发规范](common/development.md) - 学习开发流程和技术规范4. 根据具体任务阅读其他专项规范### 开发时使用方式#### 场景1: 新增订单相关功能1. 查看[项目结构规范](common/project-structure.md)确定代码放置位置2. 查看[命名规范](common/naming-conventions.md)确定类名、方法名3. 查看[开发规范](common/development.md)了解Service、Mapper开发方式4. 查看[枚举规范](common/enums.md)定义订单状态或类型5. 查看[DTO/Entity转换规范](common/dto-entity-conversion.md)处理数据转换#### 场景2: 集成MQ消息1. 查看[业务常量规范](common/constants.md)定义Topic和Tag2. 查看[开发规范](common/development.md)的消息队列部分3. 查看[命名规范](common/naming-conventions.md)确定Listener类名#### 场景3: 实现多类型业务处理1. 查看[策略模式规范](common/strategy-pattern.md)学习策略模式2. 查看[枚举规范](common/enums.md)定义策略枚举3. 查看[命名规范](common/naming-conventions.md)确定策略类命名#### 场景4: 添加Redis缓存1. 查看[业务常量规范](common/constants.md)定义Redis Key2. 查看[开发规范](common/development.md)的缓存使用规范#### 场景5: 编写单元测试1. 查看[单元测试规范](common/testing.md)了解测试框架和规范2. 查看[命名规范](common/naming-conventions.md)确定测试类和方法命名3. 参考测试模板编写Service层和Mapper层测试4. 使用Mock框架隔离外部依赖## 规范更新流程1. **提出修改**: 发现规范需要补充或修改时,提交修改建议2. **讨论评审**: 团队讨论修改的必要性和合理性3. **更新文档**: 达成一致后更新相应规范文档4. **通知团队**: 通知所有成员规范变更内容5. **执行落地**: 后续开发严格遵循新规范## 技术架构总览### 技术栈- **框架**: Spring Boot + Dubbo- **注册中心**: Nacos- **配置中心**: Nacos- **数据库**: MySQL(分库分表) + PostgreSQL- **ORM**: MyBatis Plus- **缓存**: Redis- **消息队列**: RocketMQ- **搜索**: Elasticsearch- **调度**: XXL-Job### 模块结构```略略略```### 分层架构```Controller/Listener层 -> Service层 -> Manager层 -> Mapper/Repository层```## 代码质量要求1. **规范遵循**: 严格遵循本规范文档2. **代码审查**: 所有代码需经过Code Review3. **单元测试**: 核心业务逻辑覆盖率>70%4. **注释文档**: 关键类和方法必须添加注释5. **异常处理**: 合理捕获和抛出异常6. **日志记录**: 关键节点记录日志7. **性能优化**: 注意SQL优化和缓存使用## 常见问题### Q1: 新增一个服务接口应该放在哪里?A: 参考[项目结构规范](common/project-structure.md),RPC接口放在xxx-api模块的service/api包下,实现放在xxx-impl模块的service/impl包下。### Q2: 如何命名DTO和Entity?A: 参考[命名规范](common/naming-conventions.md),请求用ReqDTO结尾,响应用RespDTO结尾,Entity不加后缀。### Q3: 如何处理多种订单类型?A: 参考[策略模式规范](common/strategy-pattern.md),使用策略模式处理不同类型的业务逻辑。### Q4: MQ的Topic和Tag如何定义?A: 参考[业务常量规范](common/constants.md),统一在OrderConstant等常量类中定义。### Q5: Entity和DTO如何转换?A: 参考[DTO/Entity转换规范](common/dto-entity-conversion.md),简单转换用BeanUtil,复杂转换创建Convert类。### Q6: 如何编写单元测试?A: 参考[单元测试规范](common/testing.md),使用JUnit 5 + Mockito框架,Service层测试覆盖率要求≥80%。### Q7: 如何Mock外部RPC服务?A: 参考[单元测试规范](common/testing.md)的Mock使用规范,使用@Mock注解Mock外部依赖。## 联系方式如有疑问或建议,请联系技术负责人鹿Sir。---*本规范文档由开发团队共同维护,最后更新时间: 2025-12*

---type: project_commanddescription: 生成快捷指令---## 指令说明根据用户需求生成符合规范的快捷指令，用于快速创建项目中的各类标准化文档和代码模板，确保开发流程的一致性和效率。## 核心规范（必守）1. 指令结构规范- 文件头：必须包含type、description字段- 指令类型：type统一为"project_command"- 描述信息：description需简洁明确地说明指令功能（10个字以内）2. 指令命名规范- 文件名：使用有意义的命令名称，采用驼峰式命名法- 命名原则：应能准确反映指令的核心功能3. 指令内容要素（每个指令必含）- 指令说明：清晰描述指令的用途和功能- 执行逻辑：说明指令的执行步骤和流程- 输入输出：明确指令的输入要求和预期输出- 验收标准：定义指令完成的判断标准## 执行步骤（3步闭环）1. 需求分析阶段：深入理解用户对快捷指令的需求，明确指令的目标功能、输入输出要求、使用场景等2. 指令设计阶段：按照规范设计指令结构，包含文件头、功能说明、执行逻辑、使用示例等必要元素3. 验证完善阶段：验证指令的可用性和完整性，确保指令能够正确执行预期功能## 输出规范（文件结构+内容）1. 文件结构所有指令文件统一存放于：.qoder/commands/ 目录下2. 文件命名规则- 指令文件：使用驼峰式命名，如：genCmd.md、spec.md、genDoc.md- 需理解用户需求进行命名，简短3. 文件内容模板（必含模块）- type: project_command（固定值）- description: 指令简要描述- 指令说明：详细功能描述- 使用方法：如何使用该指令的说明案例，如：/genCmd 生成修复AI生成的代码的指令，用于评估AI生成的代码，必要时修复AI生成的代码。需用户提供AI代码片段或类（必须）、重构前的代码片段或类（涉及重构可选）- 参数说明：指令所需参数的详细说明（如有）- 示例：使用示例和场景说明- 验收标准：指令完成的标准## 使用说明用户可通过该指令快速生成符合项目规范的快捷指令，提高开发效率和标准化程度。生成的指令应能够独立执行特定功能，同时与其他指令保持良好的兼容性和一致性。

/genCmd 生成修复AI生成的代码的指令/bugfix，用于评估AI生成的代码，必要时修复AI生成的代码。用户须提供AI代码片段或类（固定第一项）、用于参考的代码片段或类（可选，固定第二项），参考代码禁止修改

#遵循既定的 DAO/Service/Controller 层模式

# AGENTS.md本文件为 Qoder 在此代码仓库中工作时提供指导。## 项目概述XX 项目是一个基于 Maven 的多模块 Java 应用程序，用于XX活动平台。它采用模块化架构，不同模块处理特定的业务领域。## 项目结构略略略## 架构和依赖关系- 所有业务模块都依赖于 `xx-common`- `xx-service` 是核心模块，被大多数其他模块依赖- `xx-rule` 依赖于 `xx-service`- 使用 Java 8 和 Maven 构建系统- 使用 LiteFlow 实现规则引擎- 使用 Redis 进行缓存，MySQL 进行数据持久化- 使用消息队列系统 (RMQ) 进行异步处理## 开发命令### 构建项目- `mvn clean install` - 构建包含所有模块的整个项目- `mvn clean compile` - 编译项目但不运行测试- `mvn clean package` - 打包项目但不运行测试### 测试- `mvn test` - 运行所有单元测试- `mvn test -Dtest=TestClassName` - 运行特定测试类- `mvn clean test -Dtest=*ServiceTest` - 运行所有服务测试### 模块特定命令- `mvn clean install -pl 模块名` - 仅构建特定模块- `mvn clean test -pl xx-platform` - 测试特定模块## 编码规范- Java 类名使用帕斯卡命名法，方法和变量使用驼峰命名法- 常量全部大写并用下划线分隔- 包名全部小写- 4个空格缩进- 每行最多120个字符- 每个方法最多80行## API 设计- RESTful API 使用名词复数形式的资源名称- URL 路径使用小写字母和连字符- 标准 HTTP 方法：GET, POST, PUT, DELETE- 通过 URL 路径进行 API 版本控制（例如 `/api/v1/users`）- 标准 HTTP 状态码：200, 201, 400, 401, 404, 500## 数据库设计- 表名使用小写字母和下划线- 表名应具有明确的业务含义- 主表名使用复数形式，关联表使用单数形式- 字段名使用小写字母和下划线- 主键字段命名为 `id`- 外键字段命名为 `{引用表名}_id`- 索引命名：`pk_表名`（主键），`uk_表名_字段名`（唯一索引），`idx_表名_字段名`（普通索引）## 开发指南- 添加新功能时遵循现有的模块化结构- 将共享的工具类、常量和数据传输对象放在 xx-common 中- 对复杂业务逻辑使用规则引擎模块- 在服务层实现缓存策略- 使用消息队列进行异步处理- 遵循既定的 DAO/Service/Controller 层模式

---name: TestAgentdescription: |  当您需要为Java代码生成单元测试并执行它们以验证功能时，请使用此代理。此代理在实现新功能、进行代码更改或需要提高测试覆盖率时特别有用。代理将按照项目编码标准创建全面的单元测试并执行它们，以确保代码质量和正确性。
  <example>  Context：用户实现了一个新的服务方法并希望确保它正常工作  user: "我刚刚实现了新的用户认证服务方法，可以创建单元测试并运行吗？"  assistant: "我将使用TestAgent代理为您的认证服务方法创建并运行单元测试。"  </example>
  <example>  Context：用户希望改进现有组件的测试覆盖率  user: "OrderService需要更好的测试覆盖率，能帮忙吗？"  assistant: "我将使用TestAgent代理为OrderService生成全面的单元测试并运行它们以验证功能。"</example>---您是Java应用程序的专家级测试生成和执行代理。您的主要职责是根据项目的编码标准和最佳实践，为Java代码创建全面的单元测试并执行它们以验证功能。您的任务包括：1. 分析提供的Java代码以了解其功能并识别可测试的组件2. 生成涵盖正面案例、负面案例、边界案例和边界条件的全面单元测试3. 遵循项目的编码标准，包括命名约定、代码格式和结构4. 确保测试遵循JUnit最佳实践和模式5. 执行生成的测试并报告结果6. 提供关于测试覆盖率的反馈并根据需要提出改进建议具体要求：- 使用项目标准的Spring Boot测试框架，继承BaseTest类配置测试环境- 根据项目标准使用JUnit 4或5进行测试生成（项目中同时使用@Test和@Test注解）- 遵循项目的命名约定（方法使用camelCase，测试方法名称应具有描述性）- 使用@Autowired或@Resource注入依赖项- 创建验证预期行为和错误条件的测试- 包含边界案例和边界条件的测试- 在适当情况下使用Mockito或类似框架模拟依赖项- 确保测试是独立的，可以按任意顺序运行- 遵循项目的代码格式标准（4空格缩进，每行最多120个字符）- 将测试放在与源代码匹配的适当测试目录结构中- 测试方法中可使用System.out.println或日志输出结果- 必要时使用JSON工具进行数据转换和验证- 添加作者和日期注释（可选）执行测试时：- 基于项目结构使用适当的Maven命令运行测试- 报告测试结果，包括通过/失败状态和任何错误消息- 识别任何失败的测试并提供修复指导- 如果覆盖率不足，建议改进测试质量保证：- 验证生成的测试与代码的实际功能一致- 确保测试是可维护和可读的- 检查测试不会引入任何副作用- 验证测试正确隔离了被测试的组件- 确保测试符合项目架构和依赖注入模式输出格式：- 以正确的Java语法提供生成的测试代码- 包括测试执行结果的摘要- 突出显示测试期间发现的任何问题- 如有需要，对代码或测试提出改进建议

请以「TestAgent」的角色（遵循 @TestAgent.md 规范），对 @Helloworld.java 进行测试

/test @Helloworld.java

## SubAgent 配置### 1. 测试专用 SubAgent：TestAgent- 领域：Java单元测试生成与执行- 技术栈：Java 8 + JUnit4/JUnit5 + Spring Boot + Mockito + Maven- 触发关键词：["测试一下", "单元测试", "模块测试", "ServiceTest", "DAO测试", "运行测试", "测试覆盖率"]- 关联模块：所有业务模块（xx-service/rule/platform等）- 核心规则引用：.qoder/agents/TestAgent.md（包含详细职责、测试规范、质量要求）- 执行逻辑（核心命令）：mvn clean test -pl ${target_module} -Dtest=${test_class_name}

# 手动指定SubAgent拆分规则任务：实现用户管理模块SubAgent拆分：1. UserCodingAgent：编写用户增删改查核心逻辑（Java）2. TestAgent：编写JUnit单元测试3. ApiDocAgent：生成Swagger接口文档执行顺序：1→2→3

---type: project_commanddescription: 使用Context7插件查询第三方库文档---# context7 - 第三方库文档查询指令## 指令说明该指令用于查询和获取第三方库的文档、API信息和使用示例。通过Context7插件连接外部知识库，为开发者提供实时的第三方库文档支持，帮助快速了解和使用各种开源库。## 执行逻辑1. **库识别**：根据用户提供的库名，识别并解析对应的第三方库2. **文档获取**：获取库的官方文档、API参考和使用示例3. **信息整理**：整理和呈现相关的文档信息，便于理解和使用## 输入输出### 输入要求- **库名称（必需）**：需要查询的第三方库名称，如Spring Boot、MyBatis、Redis等- **查询主题（可选）**：具体需要了解的功能或API主题### 输出格式- 库的详细文档信息- API使用示例- 相关配置说明## 验收项- [ ] 库识别是否正确- [ ] 文档信息是否完整准确- [ ] 示例代码是否可运行## 使用方法```Prompt: /context7 [库名称] [可选查询主题]```### 示例```Prompt: /context7 SpringBoot Configuration```或```Prompt: /context7 MyBatis```## 适用场景1. **库学习**：了解新的第三方库的基本用法2. **API查询**：查找特定API的使用方法和参数说明3. **配置参考**：获取库的配置选项和最佳实践4. **问题解决**：通过官方文档解决使用中遇到的问题## 注意事项1. 确保提供的库名称准确，以便正确识别和查询2. 查询主题应具体明确，以获得更精确的文档信息3. 使用获取的文档信息时，注意版本兼容性4. 结合项目实际情况，适当调整文档中的示例代码

---type: project_commanddescription: 复杂需求拆解---## 指令说明将需求文档转化为可落地、有依赖、分阶段的开发/测试任务，配套生成标准化文档，确保任务执行逻辑清晰、验收标准明确。## 拆解核心规范（必守）1. 阶段拆分原则- 整体结构：统一为「1个整体规划 + 最多5个主阶段」，总阶段数不超过6个（除非指定）- 拆分依据：以代码量、功能复杂度为核心，每个主阶段对应1个独立可执行任务- 重构类特殊要求：必须拆分至少2步——① 搭建新代码结构框架（标注TODO待迁移部分）；② 执行原有代码迁移；若迁移工作量大，可拆分为最多10个子任务2. 任务依赖规则- 顺序优先：严格遵循「前置任务→后续任务」的依赖顺序，不可颠倒- 依赖边界：前置任务不得依赖后续任务的任何产出；后续任务可直接复用前置任务的输出结果3. 任务核心要素（每个任务/子任务必含）- 输入内容- 预期输出- 验收标准- 前置依赖阶段- 风险点及应对措施## 执行步骤（3步闭环）1. 需求分析阶段：深度解读需求文档，明确核心功能、技术难点、潜在风险，梳理任务间潜在依赖关系2. 任务拆解阶段：按规范拆分「整体规划+主阶段」，明确各阶段目标与交付物，定义阶段间依赖关系；需拆分子任务的，补充子任务拆分（不超过10个/主阶段）3. 文档生成阶段：按目录规范创建全套文档，填充任务详情## 输出规范（文档+命名+内容）1. 目录结构所有文档统一存放于：doc/spec/{需求名称}/（{需求名称}需替换为实际需求的核心名称）2. 文件命名规则- 整体规划文档：{需求名称}整体规划.md（例：用户管理模块重构整体规划.md）- 主任务文档：StageN_{任务概述}.md（N为阶段序号，从1开始；例：Stage1_数据库表设计.md）- 子任务文档（如有）：StageN.N_{子任务概述}.md（前N为主阶段序号，后N为子任务序号；例：Stage3.1_用户查询功能迁移.md）3. 文档内容模板（必含模块）- 前置依赖阶段（明确该任务需依赖的前序任务/阶段）- 任务概述（核心目标、任务范围）- 详细需求说明（对应需求文档的具体要求，需量化）- 技术方案设计（核心思路、技术选型、实现步骤）- 验收标准（可量化、可验证的完成条件，含边界场景）- 风险评估及应对措施（潜在技术/进度风险、解决方案）

/genCmd 生成修复AI生成的代码的指令，用于评估AI生成的代码，必要时修复AI生成的代码。用户须提供AI代码片段或类（固定第一项）、用于参考的代码片段或类（可选，固定第二项），参考代码禁止修改

---type: project_commanddescription: 校验并修复AI生成的代码---# bugfix - AI代码修复指令## 指令说明该指令用于评估和修复AI生成的代码片段或类，识别并修复错误、逻辑缺陷、性能问题或不符合最佳实践的部分。修复过程将保持原有代码的核心功能和意图不变。## 执行逻辑1. **代码评估**：分析AI生成代码的正确性、质量、功能完整性和最佳实践2. **修复执行**：根据评估结果修复逻辑错误、边界条件处理、异常处理、性能问题等3. **验证输出**：提供修复后的代码及详细说明## 输入输出### 输入要求- **目标代码（必需）**：AI生成的代码片段或类，需要被评估和修复- **参考代码（可选）**：正确的代码片段或类，作为修复时的参考标准### 输出格式- 修复后的代码- 修复说明（解释修复的原因和内容）## 验收项- [ ] 代码评估结果- [ ] 修复项说明- [ ] 修复后的代码是否保持原有核心逻辑功能和意图不变（如有参考代码）## 使用方法```Prompt: /bugfix [@目标代码，AI生成的代码片段或类]、[@可选参考代码，正确的代码片段或类]```### 示例```Prompt: /bugfix @HelloWorldNew.java @HelloWorld.java 66-72```或```Prompt: /bugfix @HelloWorldNew.java```## 评估标准1. **代码正确性**：逻辑错误、边界条件处理、异常处理等2. **代码质量**：代码规范、可读性、性能优化等3. **功能完整性**：确保代码实现预期功能4. **最佳实践**：遵循编程规范和设计模式## 修复要求1. 保持原有代码的核心功能和意图不变、log日志打印也尽可能保持不变2. 修复发现的问题和缺陷3. 提供修复说明，解释修复的原因和内容4. 如有参考代码，修复应与参考代码的风格和逻辑保持一致

---type: project_commanddescription: 代码迁移---# move - 代码迁移指令## 指令说明该指令用于将旧代码复制迁移到新的位置进行补全，保持原有逻辑不变，日志打印也尽量保持一致。参考的原始代码片段或类禁止修改，确保迁移过程中业务逻辑的一致性。## 执行逻辑1. **代码分析**：分析原始代码的结构、逻辑和依赖关系2. **迁移执行**：将代码迁移到新位置并进行必要的补全和适配3. **验证输出**：提供迁移后的代码及详细说明，确保逻辑保持不变## 输入输出### 输入要求- **原始代码（必需）**：需要被迁移的参考代码片段或类，不可修改- **目标位置（必需）**：需要迁移或补全的目前代码片段或类- **迁移要求（可选）**：具体的迁移和补全要求### 输出格式- 迁移后的代码- 迁移说明（解释迁移的原因和内容）- 保持原有逻辑的验证## 验收项- [ ] 代码迁移结果- [ ] 迁移项说明- [ ] 迁移后的代码是否保持原有核心逻辑功能不变- [ ] 日志打印是否与原始代码保持一致- [ ] 新位置代码是否正常工作## 使用方法```上下文: [原始代码，需要被迁移的参考代码片段或类]、[目标代码，需要迁移或补全的目前代码片段或类]Prompt: /move```### 示例```Prompt: /move [需要被迁移的参考代码片段或类] [需要迁移或补全的目前代码片段或类] [可选的迁移要求]```或```上下文: [需要被迁移的参考代码片段或类] [需要迁移或补全的目前代码片段或类]Prompt: /move [可选的迁移要求]```## 迁移要求1. 保持原有代码的核心功能和逻辑不变 2. 迁移后的代码需要适应新代码的整体代码结构，确保代码在新位置能够正常工作3. 日志打印格式和内容尽量与原始代码保持一致4. 参考的原始代码片段或类禁止修改5. 补全必要的依赖和引用

归纳总结已有测试类写法@{工程目录}，编写子代理规范：.qoder/agents/TestAgent.md

---name: TestAgentdescription: |  当您需要为Java代码生成单元测试并执行它们以验证功能时，请使用此代理。此代理在实现新功能、进行代码更改或需要提高测试覆盖率时特别有用。代理将按照项目编码标准创建全面的单元测试并执行它们，以确保代码质量和正确性。
  <example>  Context：用户实现了一个新的服务方法并希望确保它正常工作  user: "我刚刚实现了新的用户认证服务方法，可以创建单元测试并运行吗？"  assistant: "我将使用TestAgent代理为您的认证服务方法创建并运行单元测试。"  </example>
  <example>  Context：用户希望改进现有组件的测试覆盖率  user: "OrderService覆盖测试"  assistant: "我将使用TestAgent代理为OrderService生成全面的单元测试并运行它们以验证功能。"</example>---您是Java应用程序的专家级测试生成和执行代理。您的主要职责是根据xx项目的编码标准和最佳实践，为Java代码创建全面的单元测试并执行它们以验证功能。## 测试类编写规范1. **继承BaseTest类**：所有测试类必须继承 `com.xx.BaseTest`，该基类已配置Spring Boot测试环境、Nacos配置和相关测试属性。2. **使用JUnit注解**：使用 `@Test` 注解标记测试方法，可使用JUnit 4或JUnit 5的@Test注解。3. **依赖注入**：使用 `@Autowired` 或 `@Resource` 注解注入需要测试的服务类或其他依赖项。4. **测试类命名规则**：   - ServiceImpl 测试类：`[Service实现类名]Test`，如 `XxxTest`   - 特定方法测试类：`[Service实现类名][特定方法名]Test`，如 `XxxSkuMinUnitPriceTest`   - Cache 类测试：`[Cache类名]Test`，如 `XxxTest`   - Mapper 类测试：`[Mapper类名]Test`，如 `XxxMapperTest`   - Listener 类测试：`[Listener类名]Test`，如 `XxxListenerTest`   - 所有测试类均以 `Test` 结尾5. **测试方法命名**：使用描述性的方法名，清晰表达测试的场景或目的，如 `testSkuMinUnitPriceWithUserProvidedParams` 或 `testBatchSpuMinUnitPriceV2`。6. **测试数据构建**：在测试方法中构建完整的测试数据，包括请求DTO对象和必要的业务参数。7. **测试逻辑组织**：   - 准备阶段：构建测试数据和参数   - 执行阶段：调用被测试的方法   - 验证阶段：输出结果或验证预期行为8. **输出和验证**：使用 `System.out.println` 输出测试结果以便验证，后续可添加断言进行自动化验证。9. **注释说明**：为复杂的测试逻辑添加注释，说明测试的目的和步骤。10. **异常处理**：根据需要在测试中包含异常处理逻辑。## 测试编写流程1. 分析被测试类和方法的功能2. 确定需要测试的场景和参数3. 构建测试数据和模拟对象4. 编写测试方法验证功能5. 执行测试并验证结果

---type: project_commanddescription: 单元测试---请以「TestAgent」的角色（遵循 .qoder/agents/TestAgent.md 规范），对指定类进行单元测试

/test 测试方法 @XxxService 52-53，参数：{"bizSourceEnum":"ECOM_GOODS","calScene":1,"supplierId":122xx320,"memberPrice":388,"price":388,"spuId":17194xx176,"skuMinUnitPriceSimpleReqDTO":{"minUnitPrice":155,"needBuyNum":3},"userType":2,"skuId":171941937xx272,"skuNum":1}&16641xx4469152

/** * XxxService 单元测试类 *  * @author TestAgent * @since 2025-06-26 */public class XxxServiceTest extends BaseTest {    @Autowired    private XxxService service;    /**     * 测试 singleSkuCouponCalculate 方法     * 使用用户提供的参数进行测试     */    @Test    public void testSingleSkuCouponCalculate() throws Exception {        // 构建请求参数，使用用户提供的参数        SingleCouponCalculateReqDTO reqDTO = new SingleCouponCalculateReqDTO()                .setBizSourceEnum(BizSourceEnum.ECOM_GOODS)  // bizSourceEnum: "ECOM_GOODS"                .setCalScene(1)  // calScene: 1                .setSupplierId(122xxx20L)  // supplierId:                 .setMemberPrice(388L)  // memberPrice: 388                .setPrice(388L)  // price: 388                .setSpuId(1719419xxx2176L)  // spuId:                 .setSkuMinUnitPriceSimpleReqDTO(new SingleCouponCalculateReqDTO.SkuMinUnitPriceSimpleReqDTO()                        .setMinUnitPrice(155L)  // minUnitPrice: 155                        .setNeedBuyNum(3))  // needBuyNum: 3                .setUserType(2)  // userType: 2 (店主)                .setSkuId(171941xxx1782272L)  // skuId:                 .setSkuNum(1);  // skuNum: 1        // 用户ID        Long userId = 1664138xxx69152L;        // 执行测试        SingleCouponCalculateRespDTO result = service.singleSkuCouponCalculate(reqDTO, userId);        // 验证结果不为null        assertNotNull("返回结果不应为null", result);
        // 根据业务逻辑验证结果的某些字段        // 注意：由于服务可能依赖于数据库和缓存，实际结果可能根据环境而变化        System.out.println("测试结果: " + result);    }}

关于「鹿Sir」

分享架构技术/IT资讯/牛马日常

电商·SaaS架构师/DDD极客，COLA-DDD/DDD4j框架作者

→关注公众号，撩小码鹿「已接入AI」

→加我备注“进群”，进技术大佬群学习

数据分析不踩坑

推荐关注「心里有点数」

专治数据看不懂，让你心里真有数

▼