AI 编程如何在团队中真正落地？

# 目标在创建元素、修改元素后，所有新增的元素信息都要通过统一的审核系统。其中包括两个步骤：提交审核和接收审核回流信息。我们现在要将审核系统接入现有装修元素相关的流程中。
# 业务规则## 1. 提交审核规则...
## 2. 审核回流规则...
# 现有知识背景1. 已经将审核系统的交互规则整理为《审核交互规则.md》放在.cursor/docs目录下。提交审核我们采用“2.1 HSF请求方式”进行。2. 现有代码已经实现了创建元素、修改元素等流程。3. 审核回流的处理框架流程可以参考别的工程的Consumer，《audit.java》放在.cursor/docs目录下。但是要对其进行重构精简。
# 核心要求送审是所有模块通用的能力，请尽量可通用。对于不同模块区分的内容（主要是提审字段准备），采用策略模式进行，不同模块的子类重写父类方法。
# 核心任务## 1. 仔细阅读上述知识背景文档，仔细阅读现有new-b-dolphin-*的代码实现。## 2. 根据上述规则和现有new-b-dolphin-*的代码实现，将你对这部分的详细设计输出到文档。注意，至少要精确到类和方法的定义，所有图都使用mermaid格式。## 3. 文档输出后，等待人类确认。确认该文档技术方案可行后，生成具体代码到对应文件。

---description: globs: alwaysApply: false---# 代码探索规则## 前置信息收集(1) 首先查阅探索结果文件 `.cursor/rules/project-structure.mdc`,优先阅读文件内容获取当前项目的整体路径结构,后续的分析基于该文件内容进行改写优化  (2) 其次查询git提交忽略文件`.gitignore`,文件内部标注非代码路径,在后续探索中忽略这些路径的以及文件的探索  (3) 结合前置收集到的信息,确定探索文件的范围,**注意:不要遗漏路径，也不要省略路径的探索**  ## 确定探索顺序> 探索时需要参考前置信息收集的结果,对于忽略的路径、文件则无需探索.  > `<example></example>` 为示例，根据实际情况进行分析### 1. **探索前先要分析项目中的模块依赖关系**：   - 对于Java项目，可以先阅读项目的主POM配置`pom.xml`,然后逐个去探索子POM配置  #### (1) 先探索主POM文件内容，确认总共有哪些模块：<example>```xml<modules>    <module>A</module>    <module>B</module>    <module>C</module>    <module>D</module></modules>```</example>  #### (2) 再逐个阅读分析模块的子POM文件,确认模块之间真实的依赖关系  <example>  ```xml<dependencies>    <dependency>      <groupId>xxxxx</groupId>      <artifactId>A</artifactId>    </dependency></dependencies>```</example>  #### (3) 整理出模块之间真实的依赖关系，一般是有向无环图（DAG），依赖模块的版本号不一致可以忽略. **当整理完后需要再阅读各子pom，确认依赖的正确和无遗漏**     <example>  ```mermaidgraph TD  A --> B  B --> C  A --> D```</example>### 2. **按模块依赖顺序,自底向上探索;探索过程中按照广度优先遍历文件路径**：<example>  ```ModuleA/└── src/    ├── api/    │   ├── service_A/                      │   └── service_B/                      ├── enum/                       └── dto/   ````src/`路径下，先遍历`api/`、`enum/`、`dto/`，再遍历`src/api/service_A/`、`src/api/service_B/`</example>## 确定路径用途**1.通过阅读路径下的若干文件来确认该目录是文件存放规则，路径功能包括但不限于** - 存放常量、枚举：路径下存放的代码主要是常量/枚举信息，文件命名一般以`Constant.java`、`Enum.java`等结尾 - 存放服务接口：路径下存放定义的接口，文件一般都是`Interface` - 存放服务实现：路径下存放接口的逻辑实现,文件命名一般以`InterfaceImpl.java`、`ServiceImpl.java`等结尾 - 存放工具类：路径下存放项目中使用的工具,文件命名一般以`Utils.java`、`Util.java`等结尾 - 存放配置、开关：路径下存放项目中使用的配置开关，路径一般为`switches/`、`config/`、`diamond/`等 - 存放核心领域模型：一般在领域module下，module命名一般包含`core`、`domain`等关键字;路径下存放核心业务模型，路径一般为`domain/`、`model/`、`core/`等 - 存放核心领域服务：一般在领域module下，module命名一般包含`core`、`domain`等关键字;路径下存放核心业务服务 - 存放数据库仓储服务：路径一般包含`mysql`、`repository`、`db`等关键字;路径下的代码文件一般都是连接数据服务或数据库的交互逻辑**2.设计模式相关结构识别指引**- 在探索目录和文件时，需特别关注以下常见设计模式相关命名，若路径或文件名中包含这些关键词，应优先判断其是否为该模式的实现，并在结构输出和规范中予以标注：  - handler/Handler：处理链、事件分发、命令等（如handler、eventhandler、xxxHandler.java）  - strategy/Strategy：策略模式实现（如strategy、xxxStrategy.java）  - wrapper/Wrapper：装饰器/包装器模式（如wrapper、xxxWrapper.java）  - factory/Factory：工厂模式（如factory、xxxFactory.java）  - adapter/Adapter：适配器模式（如adapter、xxxAdapter.java）  - proxy/Proxy：代理模式（如proxy、xxxProxy.java）  - builder/Builder：建造者模式（如builder、xxxBuilder.java）  - observer/Observer：观察者模式（如observer、xxxObserver.java）  - command/Command：命令模式（如command、xxxCommand.java）  - visitor/Visitor：访问者模式（如visitor、xxxVisitor.java）  - state/State：状态模式（如state、xxxState.java）  - template/Template：模板方法模式（如template、xxxTemplate.java）**3.结合模块下的文件信息，确认该模块的定义，包括但不限于**- 项目启动模块：一般模块命名包含关键字`start`、`starter`等- 对外接口模块：一般模块命名包含关键字`client`、`gateway`等，系统对外提供的RPC/HTTP/网关服务- 外部接口对接模块：一般模块命名包含关键字`integration`等，包含对接二三方服务- 基础设施模块：包含数据仓储、项目基础框架、工具类等- 领域模块：一般模块命名包含关键字`core`、`domain`等，包含系统稳定的核心领域模型和服务- 业务模块：一般模块命名包含关键字`bussiness`、`application`、`biz`、`app`等，包含业务逻辑，对外接口的实现逻辑**4.常见系统框架结构识别指引**- 在探索目录和文件时，需特别关注以下主流企业级架构的典型分层和命名：  - **阿里COLA框架**：    - 典型分层：client（接口层）、app（应用层）、domain（领域层）、infrastructure（基础设施层）、integration（外部集成层）、web（表现层）    - 目录命名示例：client/dto/、app/service/、domain/model/、infrastructure/repository/、integration/、web/controller/    - 用途说明：各层职责分明，DTO、Command、Query、DO、Repository、Service等应放在对应分层包下  - **高德GBF框架**：    - 典型分层：platform（Process流程层）、node（NodeService节点层）、domain（DomainService领域层）、ability（扩展点接口层）、app（行业/场景定制层）    - 目录命名示例：platform/、node/、domain/、ability/、app/food/、app/retail/    - 用途说明：Process、NodeService、DomainService、Ability、Action等应放在对应分层包下- **如发现项目采用上述主流框架，应优先按其分层和命名规范输出结构和放置建议。**## 探索结果输出1、内容输出到文件中 `.cursor/rules/project-structure.mdc`，如果该文件存在则进行内容更新  2、只需要输出目录路径，不要输出具体代码文件；路径下没有文件可以进行合并，有文件的路径不能擅自合并.   <case>  ```A/└── src/    └── main/        └── java/            └── B/                ├── aaa.java                ├── domainservice/                │   └── bbb.xml                └── domainmodel/```  1、`A/src/main/java/B/` 可以合并输出2、但是 `domainservice/` `domainmodel/` 不能合并  3、`aaa.java` 、`bbb.xml` 是具体文件，不需要输出所以最终正确输出如下    ```A/src/main/java/B/    ├── domainservice/    └── domainmodel/```</case>  3、在洞察过程中发现的规范，输出到代码文件放置规范中.**重要规则:不要自己乱写代码文件放置规范，所有规范都需要有依据**  **4.设计模式相关结构输出要求**- 输出结构时，若发现有上述设计模式相关的包或类，应在输出中加注释说明其用途（如"# 策略模式实现"）。- 在规范部分，补充"常见设计模式类的放置建议"，并举例说明。### 输出格式如下> `<example></example>` 为示例，根据实际分析结果进行填写;填写时不需要用`<example></example>` 包装  ``````mdc  ---description: `此规则包含了本项目的代码路径结构和规范，所有代码编写时必须按照该模块化结构进行放置`globs: *.java,*.xmlalwaysApply: true---# 项目模块及依赖关系  <example>    ```mermaidgraph TD  A --> B  B --> C  A --> D```</example># 项目目录及使用规范```<example>  systemA/├── systemA-start/         # 项目的启动模块├── systemA-client/        # 系统对外暴露的RPC接口门面模块│   └── src/main/java/systemA/client│       ├── api/                   # 对外接口│       └── dto/                   # 对外模型,请求,响应等├── systemA-domain/        # 领域基础模块,作为项目的最基础的模块;所有二三方服务依赖在此引入│   └── src/main/java/systemA/domain│      ├── domainservice/     # 基础服务框架│      ├── constant/          # 常量│      ├── enum/              # 枚举│      ├── exception/         # 异常│      ├── gateway/           # 二三方服务的接入的防腐层;所有外部服务需要在此建立防腐层interface│      ├── switch/            # 领域基础层的开关配置│      ├── util/              # 系统基础工具│      ├── model/             # 领域模型│      ├── strategy/          # 策略模式实现 # 设计模式示例│      ├── handler/           # 处理链/事件分发/命令模式实现 # 设计模式示例│      ├── wrapper/           # 装饰器/包装器模式实现 # 设计模式示例│      └── observer/          # 观察者模式实现 # 设计模式示例└── systemA-application/   # 最上层业务应用层;    └── src/main/java/systemA/application       ├── client/         # 对应服务RPC服务实现       ├── controller/     # 对外暴露的http服务       ├── gateway/        # 注册在网关上的网关服务接口       │  ├── request/         # 网关接口请求定义       │  ├── response/         # 网关接口响应定义       │  └── impl/            # 网关接口的实现       ├── converter/           # 模型转换器,主要将领域或者db模型转换成对外DTO、VO模型       ├── service/            # 业务服务接口       │   ├── factory/        # 工厂模式实现 # 设计模式示例       │   ├── adapter/        # 适配器模式实现 # 设计模式示例       │   └── proxy/          # 代理模式实现 # 设计模式示例       └── service/impl/       # 业务服务实现```</example> # 代码文件放置规范<example>1、数据对象(DO)规范：数据对象(DO)必须放在XXX模块下的dataobject包中2、传输数据对象(DTO)规范：传输数据对象(DTO)必须放在XXX模块下的xxx包中3、视图数据对象(VO)规范：视图数据对象(VO)必须放在XXX模块下的xxx包中4、工具类(Util)规范：工具类必须放在XXX模块下的xxxx包中5、单测类(Test)规范：单测类型必须放在Test模块下的xxx包中6、策略模式(Strategy)规范：策略相关类应统一放在strategy包下，命名以Strategy结尾，如XxxStrategy.java7、处理链/命令模式(Handler/Command)规范：相关类应统一放在handler或command包下，命名以Handler或Command结尾8、装饰器/包装器模式(Wrapper)规范：相关类应统一放在wrapper包下，命名以Wrapper结尾9、工厂模式(Factory)规范：相关类应统一放在factory包下，命名以Factory结尾10、适配器模式(Adapter)规范：相关类应统一放在adapter包下，命名以Adapter结尾11、代理模式(Proxy)规范：相关类应统一放在proxy包下，命名以Proxy结尾12、建造者模式(Builder)规范：相关类应统一放在builder包下，命名以Builder结尾13、观察者模式(Observer)规范：相关类应统一放在observer包下，命名以Observer结尾14、访问者模式(Visitor)规范：相关类应统一放在visitor包下，命名以Visitor结尾15、状态模式(State)规范：相关类应统一放在state包下，命名以State结尾16、模板方法模式(Template)规范：相关类应统一放在template包下，命名以Template结尾....</example>

---description: 此规则用于生成标准化的需求上线计划文档。当需要创建新的上线计划、准备发布新功能或更新现有系统时应用此规则。规则确保上线计划包含完整的发布定义、发布计划、灰度策略、配置管理、监控方案及回滚预案等关键信息，有助于团队高效协作并降低上线风险。适用于各类需求的发布与上线准备工作。globs: alwaysApply: false---# 需求上线计划模板规则## 关键规则- 所有需求上线计划必须包含完整的发布定义、发布计划、预发布、灰度发布和正式发布五个主要部分- 发布定义必须明确需求责任人、发布执行人、需求分级和风险等级- 需求分级必须明确区分：A级（测试测）、B级、C级、D级（自测）- 发布计划必须详细说明上下游发布节奏，包括模块依赖关系和发布顺序- 发布计划必须以工程为单位进行规划（如amap-mp-shop整体工程），而非以子模块为单位（如shop-app、shop-infrastructure等）- 灰度发布部分必须说明灰度策略、灰度验证点和对线上功能的影响评估- 正式发布部分必须包含配置项清单、影响面分析、监控方案和回滚预案（三板斧）- 所有依赖的配置项（如Diamond配置、消息队列、网关等）必须详细列出并指定负责人- 回滚预案必须针对不同阶段可能出现的问题制定详细的操作步骤- 模板中必须包含版本管理信息，记录文档的变更历史## 上线计划文档结构上线计划文档必须按照以下结构组织：```# 需求名称上线计划当前版本号：vX.X# 一、发布定义（需求负责人、发布执行人、需求分级、风险等级）# 二、发布计划（上下游发布节奏、内部工程发布顺序）# 三、预发布（预发状态、验证结果）# 四、灰度发布（灰度策略、灰度验证点）# 五、正式发布（发布节奏、配置项、影响面分析、监控方案、回滚预案）# 六、上线流程（具体上线步骤）# 七、评审回看（上线评审记录）# 版本管理（文档版本历史）```## 各章节详细规范### 一、发布定义-**需求一号位**：主要负责人，对整个需求负责-**发布执行人**：负责执行发布的人员列表-**需求分级**：标明需求的重要程度  - **A级**：完全测试测，需要最高级别的测试覆盖  - **B级**：部分测试测，部分自测  - **C级**：大部分自测，小部分测试测  - **D级**：自测，由开发人员自行测试-**风险等级**：标明发布风险（高/中/低）### 二、发布计划-**上下游发布节奏**：必须使用表格形式列出所有相关系统/工程的发布时间、跟进人和发布内容-**模块间依赖**：使用图表明确标示各工程间的依赖关系，区分强依赖和弱依赖-**工程发布顺序**：必须以整体工程为单位（如amap-mp-shop、amap-mp-shop-service），而非以子模块为单位（shop-app、shop-infrastructure等）### 三、预发布- 明确标明预发状态（已预发/未预发）- 如已预发，需说明预发验证结果### 四、灰度发布- 明确灰度发布时间- 使用表格形式列出各工程的灰度情况，包括：  - 是否有灰度环境  - 当前进度  - 发布后对线上功能的影响  - 灰度上线后核心验证点### 五、正式发布-**发布节奏**：明确正式发布的批次和时间安排-**配置项**：详细列出所有需要配置的项目，包括：  - 合并origin/master  - Diamond配置  - Switch配置  - 数据库建表及配置  - 消息队列（生产者/消费者）  - 网关ACTION配置：如果有新增hsf接口，则将其列到发布计划中，由开发人员决策是否需要发布网关ACTION  - autoconfig：如果代码有改动antx.properties文件  - SchedulerX  - 二方包：如果pom.xml文件有改动，则需要列举改动点，让用户确认是否需要更新二方包版本或发布二方包  - Sentinel：如果调整了sentinel相关逻辑，则需要列举sentinel配置项  - Jingwei  - Tair/Redis   - 其他中间件配置-**影响面梳理与验证方案**：分析发布影响面，制定验证方案-**三板斧**：  - **可灰度**：明确说明是否需要灰度及灰度策略  - **可监控**：列出关键监控指标  - **可回滚**：详细说明判定需要回滚的依据及回滚操作步骤### 六、上线流程- 列出上线的具体流程或引用相关流程文档### 七、评审回看- 存放上线评审记录或会议视频链接### 版本管理- 使用表格记录文档的版本历史，包括版本号、修订类型、修订时间、修订人、修订内容和生效时间## 配置项详细规范### Diamond配置使用表格列出所有Diamond配置，包括：- groupId- dataId- 配置项确认人- 配置值注意：如果dataId相同，则合并表格单元格### 消息队列配置分别列出生产者和消费者配置：- Topic- Group（消费者）- Tag- 功能说明### 网关配置列出所有需要配置的网关action，包括：- action名称- 配置地址- 功能说明### autoconfig如果代码有改动antx.properties文件,则需要配置autoconfig，包括- 配置key- 配置value## 回滚预案规范回滚预案必须包含：- 判定需要回滚的明确依据- 针对不同阶段（如代码上线阶段、业务灰度阶段）的回滚操作步骤- 回滚后的验证方法和后续操作## 示例<example># 用户身份认证系统升级上线计划当前版本号：v2.0# 一、发布定义### 需求一号位张三### 发布执行人张三、李四、王五### 需求分级A级（测试测）### 风险等级中# 二、发布计划### 1、上下游发布节奏模块间依赖: 实线箭头: 强依赖，必须按照顺序发布虚线箭头: 逻辑上有依赖关系，但可并行发布|   |  **发布时间**  |  **跟进人**  |  **发布内容**  || --- | --- | --- | --- ||  认证服务工程  |  10.15（已完成）  |  张三  |  1、支持新的认证方式 2、优化认证流程  ||  用户中心工程  |  10.16  |  李四  |  1、适配新的认证接口 2、增加用户安全等级  ||  前端系统工程  |  10.17  |  王五  |  1、更新认证页面 2、增加安全等级展示  |# 三、预发布*   [x] 已预发，验证通过所有测试用例    # 四、灰度发布*   [x] 10.18发布灰度    |   |  **是否有灰度环境**  |  **当前进度**  |  **发布后对线上功能的影响**  |  **灰度上线后核心验证点**  || --- | --- | --- | --- | --- ||  认证服务工程  |  有  |  已灰度  |  开关控制，对线上无影响  |  1、新旧认证方式切换正常 2、性能指标达标  ||  用户中心工程  |  有  |  已灰度  |  开关控制，对线上无影响  |  1、用户安全等级计算正确 2、与认证服务交互正常  ||  前端系统工程  |  有  |  未灰度  |  新界面默认关闭，对线上无影响  |  1、新旧界面切换正常 2、功能操作流畅  |# 五、正式发布## 发布节奏分两批发布：1. 第一批：10.20 认证服务工程 + 用户中心工程2. 第二批：10.21 前端系统工程## 配置项|   |  **是否已完成**  |  **负责人**  |  **deadLine**  |  **认证服务工程**  |  **用户中心工程**  |  **前端系统工程**  || --- | --- | --- | --- | --- | --- | --- ||  合并master  |  *   [ ]        |  张三  |  10.19  |  是  |  是  |  否  ||  diamond配置  |  *   [ ]        |  李四  |  10.19  |  是  |  是  |  是  ||  数据库脚本  |  *   [ ]        |  王五  |  10.19  |  是  |  是  |  否  |### Diamond配置|  **groupId**  |  **dataId**  |  **配置项确认人**  |  **配置值**  || --- | --- | --- | --- ||  auth-service  |  auth.switch.config  |  张三  |  { "newAuthEnabled": false, "authTimeoutMs": 3000 }  ||  user-center  |  security.level.config  |  李四  |  { "securityCheckEnabled": false, "defaultLevel": 1 }  |### 三板斧-可灰度认证功能通过配置中心开关控制，可实现新旧功能的平滑切换：* 配置开关关闭时，使用旧的认证流程* 配置开关开启时，使用新的认证流程* 可按用户分组灰度，先覆盖内部用户，再扩大到外部用户### 三板斧-可监控监控项：* 认证请求量* 认证成功率* 认证响应时间* 异常登录告警* 用户安全等级变更统计### 三板斧-可回滚**判定需要回滚的依据:** 1. 认证成功率下降超过3%2. 认证响应时间超过500ms3. 出现批量用户无法登录问题|  **阶段**  |  **回滚操作和后续操作步骤**  || --- | --- ||  代码上线阶段  |  1、同步问题 2、单独回滚故障服务 3、确认回滚后影响消除  ||  业务灰度阶段  |  1、将配置开关关闭，切回旧认证方式 2、排查问题 3、修复后重新灰度  |# 六、上线流程参考标准上线流程：[链接]# 七、评审回看[会议录制链接]# 版本管理|  **版本号**  |  **修订类型**  |  **修订时间**  |  **修订人**  |  **修订内容**  |  **生效时间**  || --- | --- | --- | --- | --- | --- ||  V1.0  |  新增  |  2023-10-10  |  张三  |  首次发布  |  2023-10-10  ||  V2.0  |  更新  |  2023-10-15  |  李四  |  增加前端系统发布计划  |  2023-10-15  |</example><exampletype="invalid"># 系统升级上线计划# 一、发布定义需求分级：中级  // 错误：未使用标准分级（A/B/C/D）负责人：张三时间：下周发布# 二、发布计划依赖关系：service模块 -> dao模块 -> controller模块  // 错误：以子模块而非工程为单位进行规划发布顺序：1. 发布dao子模块  // 错误：应以整体工程为单位，而非子模块2. 发布service子模块3. 发布controller子模块# 三、灰度说明先上线后端，再上线前端  // 错误：未提供足够的灰度策略和验证点详情# 回滚  // 错误：未按标准结构组织文档如有问题就回滚  // 错误：没有具体的回滚依据和步骤# 其他说明文档撰写于2023年10月  // 错误：未使用标准的版本管理格式</example>