03-Java+Vue技术栈前端后端项目提示词工程范例

一、后端项目提示词范例

说明：模板适配「SpringCloudAlibaba + MyBatis-Plus + JDK21 + MySQL + Redis + Nacos + Groovy + Hutool + RocketMQ + Thymeleaf + MapStruct + EasyExcel 等处理组件」，完全对齐你已有的全局SKILL规范，无需修改，每次需求直接粘贴，替换【需求描述】即可，AI输出可直接提交，大幅减少人工自测。

场景：小功能迭代/小改小修

适用场景：单个接口修改、实体/DTO加字段、列表加筛选排序、简单业务逻辑优化、简单bug修复、参数校验调整、权限微调、单接口联调适配

你现在基于我当前打开的后端项目（SpringCloudAlibaba+MyBatis-Plus+JDK21+MySQL+Redis+Nacos+Groovy+Hutool+RocketMQ+Thymeleaf+MapStruct+EasyExcel等处理组件）+ 已生效的后端全局SKILL规范，完成一次小功能迭代。
核心目标：最终代码可直接提交，无需人工二次自测、无需返工，完全符合项目规范，不破坏现有功能，无安全隐患。

【需求描述】
__________________________（直接粘贴你的小需求，例：用户实体新增“联系电话”字段，对应数据库表新增字段，接口返回该字段，新增字段非空校验；列表接口新增“联系电话”筛选条件）

【严格约束（必须100%遵守）】
1.  最小改动原则：只修改与需求直接相关的代码，不改动无关逻辑、不重构、不优化无关代码、不新增多余文件。
2.  规范对齐原则：严格遵循后端项目全局SKILL，包括但不限于：文件命名、包结构、类/方法/变量命名、MyBatis-Plus用法、Feign调用规范、异常处理、权限控制、日志规范。
3.  复用优先原则：必须复用项目现有工具类、常量、枚举、全局异常、统一返回值、Redis封装工具，以及Groovy、Hutool、RocketMQ、Thymeleaf、MapStruct、EasyExcel、PDF处理等组件的现有封装，不重复造轮子，组件使用符合项目现有规范。
4.  兼容安全原则：必须兼容现有业务逻辑，不破坏原有功能，不引入新的bug；禁止SQL注入、权限绕过、敏感信息泄露等安全风险。
5.  边界处理原则：所有边界场景必须自带完整处理，包括：空参数、数据不存在、接口调用异常、Redis缓存异常、数据库异常、权限不足、消息队列异常（RocketMQ）、文件处理异常（EasyExcel、PDF）。
6.  数据库规范原则：SQL写法符合项目规范，使用MyBatis-Plus条件构造器，禁止硬编码SQL、禁止select *、禁止无where条件的update/delete，新增字段需符合数据库设计规范。
7.  代码质量原则：禁止硬编码、禁止魔法值、禁止空指针异常、禁止未处理的异常、禁止冗余代码，事务注解使用规范，避免大事务；Groovy脚本、MapStruct映射、EasyExcel/PDF处理等需符合项目现有写法。

【输出要求（缺一不可）】
1.  第一步：【技术方案设计】
    输出适配本次小需求的简洁技术方案，包含：需修改/新增的文件（实体、DTO、Mapper、Service、Controller等）、核心业务逻辑实现、数据库调整方案（如需）、接口对接方式、缓存处理方案（如需）、消息队列使用方案（如需，基于RocketMQ）、文件处理方案（如需，基于EasyExcel/PDF组件）、对象映射方案（如需，基于MapStruct）、模板渲染方案（如需，基于Thymeleaf）、边界场景处理方案、与现有代码的兼容处理，方案需简洁明了、贴合需求及项目规范。
    输出后必须明确通知我：“技术方案设计已完成，请你检查、修改、增减技术方案内容，确认无误后，我将进入代码生成环节”，等待我的确认指令后，再进行下一步。
2.  第二步：【代码生成】
    待我确认技术方案无误后，明确标注每个修改/新增文件的完整包路径（必须与项目现有包结构完全一致），后跟完整可运行代码，无需修改可直接保存。
    代码自带清晰注释（类说明、方法说明、关键逻辑注释），结构、风格与项目现有代码完全统一，符合SKILL规范，包含必要的单元测试代码（核心方法）；涉及Groovy、Hutool、RocketMQ等组件的使用，需完全对齐项目现有写法。
3.  第三步：【自测清单生成与确认】
    代码生成完毕后，输出【自测验收清单】，逐条验证是否满足需求、技术方案及约束，每条必须打勾（✅）或明确说明未满足原因及修正方案。
    输出后必须明确通知我：“自测清单已生成，请你检查、修改、增减自测清单内容，确认无误后，我将完成自测并最终交付”，等待我的确认指令后，再进行最终自测交付。
4.  第四步：【最终交付】
    待我确认自测清单无误后，补充输出【兼容风险说明】，明确是否会影响原有功能、可能的影响点及规避方案，完成最终交付。
5.  禁止输出任何伪代码、示例代码、占位逻辑，所有代码必须真实可运行、无语法错误、无编译报错；未得到我的确认指令，不得擅自进入下一环节。

场景：大项目/新模块/新接口集群

适用场景：新建完整业务模块、新建接口集群、复杂业务逻辑开发、多表关联查询开发、涉及微服务调用/分布式事务/缓存设计的开发、新增数据库表及关联逻辑

你现在基于我当前打开的后端项目（SpringCloudAlibaba+MyBatis-Plus+JDK21+MySQL+Redis+Nacos+Groovy+Hutool+RocketMQ+Thymeleaf+MapStruct+EasyExcel等处理组件）+ 后端全局SKILL规范，完成一个完整模块/接口集群开发。
核心目标：代码可直接合并提交，基本无需人工自测、无需返工，结构规范、逻辑闭环、兼容现有项目，无安全隐患。

【需求描述】
__________________________（直接粘贴完整需求，例：新建“用户管理”模块，包含用户新增、编辑、删除、详情查询、列表分页查询接口，支持权限控制、Redis缓存用户信息、分布式事务处理，对接角色管理微服务接口，新增用户相关数据库表及关联逻辑）

【全局架构约束（必须100%遵守）】
1.  包结构约束：严格按项目现有包结构创建文件，规范如下（与项目保持一致），必须100%遵守，禁止任何跨包乱放文件、擅自修改包结构的行为：
    - 实体类：com.xxx.xxx.entity（与数据库表一一映射）
    - DTO/VO：com.xxx.xxx.dto（入参）/com.xxx.xxx.vo（出参）
    - Mapper接口：com.xxx.xxx.mapper（继承BaseMapper）
    - Mapper XML：resources/mapper/xxxMapper.xml（如需自定义SQL）
    - Service接口：com.xxx.xxx.service（业务接口）
    - Service实现：com.xxx.xxx.service.impl（业务实现，继承ServiceImpl）
    - Controller：com.xxx.xxx.controller（接口入口）
    - 工具类：com.xxx.xxx.util
    - 常量/枚举：com.xxx.xxx.constant/com.xxx.xxx.enums
    - 异常类：com.xxx.xxx.exception（模块自定义异常）
    - 配置类：com.xxx.xxx.config（模块私有配置）
    - Groovy脚本：com.xxx.xxx.script（如需）
    - 消息队列（RocketMQ）：com.xxx.xxx.mq（生产者/消费者，如需）
    - 文件处理（EasyExcel/PDF）：com.xxx.xxx.file（如需）
    - 对象映射（MapStruct）：com.xxx.xxx.mapper.struct（如需）
    - 模板渲染（Thymeleaf）：com.xxx.xxx.template（如需）
2.  复用约束：严格复用项目现有基础组件、工具类、全局异常处理器、统一返回值、Redis封装、Feign客户端、权限框架，以及Groovy、Hutool、RocketMQ、Thymeleaf、MapStruct、EasyExcel、PDF处理等组件的现有封装，不重复开发已有的组件和方法，组件使用符合项目现有规范。
3.  数据库约束：严格遵循项目数据库设计规范，表结构、字段命名（snake_case）、字段类型、索引设计符合要求；使用MyBatis-Plus逻辑删除、乐观锁、分页插件，禁止绕过多租户过滤（如需）。
4.  微服务约束：Feign调用遵循项目规范，必须定义fallback降级处理，服务间调用异常处理符合项目要求；分布式事务使用项目集成的Seata方案（如需），注解使用规范。
5.  缓存约束：Redis缓存使用项目封装的工具类，key命名符合项目规范，必须设置过期时间，禁止缓存敏感数据，缓存更新/删除逻辑闭环。
6.  接口约束：接口路径遵循Restful规范，请求方式与语义对齐（GET查询、POST新增、PUT修改、DELETE删除），入参校验完整，返回统一Result对象，接口文档注解完整。
7.  权限约束：接口权限控制与项目现有逻辑一致，使用项目统一的权限注解，禁止开发越权接口。
8.  组件使用约束：Groovy、Hutool、RocketMQ、Thymeleaf、MapStruct、EasyExcel、PDF处理等组件的使用，必须完全遵循项目现有写法、封装规范，禁止擅自修改组件使用方式、引入组件新特性导致不兼容。
9.  兼容安全约束：不引入任何新依赖，不改变现有项目架构，不破坏原有功能；禁止SQL注入、XSS攻击、敏感信息泄露、空指针异常，事务控制合理，避免大事务。

【输出结构要求（按顺序输出，缺一不可）】
1.  第一步：【技术方案设计】
    输出适配本次大模块/接口集群开发的完整技术方案，包含：模块包结构（严格对齐项目现有规范，100%遵守）、核心业务逻辑、数据库表设计（如需）、接口设计（路径、请求方式、入参出参）、缓存设计方案、微服务调用方案（如需）、分布式事务方案（如需）、消息队列方案（如需，基于RocketMQ）、文件处理方案（如需，基于EasyExcel/PDF）、对象映射方案（如需，基于MapStruct）、模板渲染方案（如需，基于Thymeleaf）、权限控制方案、边界场景处理方案、与现有项目的兼容方案。
    输出后必须明确通知我：“技术方案设计已完成，请你检查、修改、增减技术方案内容，确认无误后，我将进入代码生成环节”，等待我的确认指令后，再进行下一步。
2.  第二步：【代码生成】
    待我确认技术方案无误后，先输出【模块包结构树】，明确所有新增/修改的文件路径（严格与项目现有包结构一致，100%遵守），让我确认路径无误后，再按以下顺序输出完整可运行代码（每个文件必须完整，无需修改可直接保存）：
    - 第一步：数据库表SQL脚本（如需新增/修改表）
    - 第二步：实体类（entity）
    - 第三步：DTO/VO（数据传输对象）
    - 第四步：Mapper接口 + Mapper XML（如需）
    - 第五步：Service接口
    - 第六步：Service实现类
    - 第七步：Controller（接口入口）
    - 第八步：常量/枚举/工具类（如需）
    - 第九步：配置类/Feign客户端（如需）
    - 第十步：Groovy脚本/消息队列/文件处理/对象映射/模板渲染相关代码（如需）
    - 第十一步：单元测试代码（核心方法、接口）
    每个文件代码自带清晰注释（类说明、方法说明、参数说明、权限控制说明、关键逻辑注释），结构、风格与项目现有代码完全统一；包路径、组件使用完全符合项目规范。
3.  第三步：【自测清单生成与确认】
    代码生成完毕后，输出【功能自测清单】，覆盖正常场景、异常场景、边界场景、权限场景、缓存场景、数据库场景、组件使用场景（Groovy、RocketMQ等），逐条打勾（✅）验证，明确是否满足需求及技术方案。
    输出后必须明确通知我：“自测清单已生成，请你检查、修改、增减自测清单内容，确认无误后，我将完成自测并最终交付”，等待我的确认指令后，再进行最终自测交付。
4.  第四步：【最终交付】
    待我确认自测清单无误后，补充输出以下2项内容，完成最终交付：
    - 【与现有项目兼容说明】：明确是否会影响原有功能、可能的影响点及规避方案，确保无兼容风险；明确数据库脚本执行注意事项；明确组件使用（RocketMQ、EasyExcel等）的兼容风险及规避方案。
    - 【最终结论】：明确说明代码是否可直接合并提交、是否需要人工修改、是否需要额外配置（如Nacos配置、权限配置）。
5.  禁止任何伪代码、示例代码、占位逻辑，所有逻辑必须真实可运行、无语法错误、无编译报错、无类型错误，完全符合项目全局SKILL规范及包结构约束；未得到我的确认指令，不得擅自进入下一环节。

场景：分析后端接口逻辑流程1

【任务目标】
接口：`/v1/api/xxx`
文件名：`xxx接口全链路分析.md`
针对这个Java后端接口 ，对接口的完整业务逻辑进行**全链路递归分析**，最终生成一份结构化的Markdown文档，放在项目 `docs/` 目录下，文件名按照我给的命名。

---
【强制分析步骤（必须按顺序执行，不得跳过）】
1.  **定位入口**：先在后端项目目录下找到该接口对应的Controller类，记录文件路径、方法签名、请求方式、参数校验逻辑、返回值封装逻辑。
2.  **递归展开调用链**：
    - 第一步：分析Controller中调用的Service方法（记录Service接口/实现类的文件路径、方法名）
    - 第二步：深入该Service实现类，分析方法内部的所有逻辑：参数处理、分支判断、事务注解、缓存操作、异常处理、数据转换
    - 第三步：递归分析该Service方法中调用的其他Service、工具类、Mapper方法，直到所有调用链的终点（DAO层/数据库操作）
    - 注意：所有嵌套调用的方法都必须展开，不得省略任何层级，必须标注每个方法的所在文件路径
3.  **梳理数据流转**：从接口入参开始，记录每个步骤中参数的变化、赋值、校验、转换，直到最终的数据库操作和返回值。
4.  **提取分支与异常**：梳理所有if/else分支、try-catch异常处理、事务回滚条件，标注每个分支的触发条件和业务含义。
5.  **绘制流程图**：用Mermaid语法生成完整的业务流程图，包含：
    - 接口入口 → Controller → Service层 → 核心业务逻辑 → 依赖服务调用 → DAO层 → 数据库操作 → 分支/异常路径 → 最终返回
    - 必须包含所有成功/失败/异常分支，不能只画主流程

---
【文档强制结构（必须按此输出）】
# xxx接口全链路分析
## 1. 接口基础信息
- 接口地址：`替换为接口路径`
- 请求方式：（自动识别GET/POST/PUT等）
- 所在Controller文件路径：
- 核心功能说明：一句话描述接口的业务目标

## 2. 全链路调用链概览（Mermaid流程图）
```mermaid
flowchart TD
    A[接口入口] --> B[Controller层]
    B --> C[Service层入口方法]
    C --> D[核心业务逻辑方法1]
    D --> E[核心业务逻辑方法2]
    E --> F[依赖Service调用]
    F --> G[Mapper/DAO层数据库操作]
    G --> H[返回结果封装]
    %% 必须补充所有分支/异常路径

## 3. 逐层逻辑详细分析
### 3.1 Controller 层
- 方法签名：（完整方法定义）
- 文件路径：
- 核心逻辑：参数解析、参数校验、请求头处理、调用的 Service 方法、返回值封装
- 关键注解：@RequestMapping、@Valid、事务 / 权限相关注解
### 3.2 Service 层入口方法
- 接口文件路径 + 实现类文件路径
- 方法签名：
- 核心逻辑：参数校验、业务前置判断、事务注解、分支判断
- 调用的后续方法列表（标注文件路径）
### 3.3 核心业务逻辑方法（递归展开所有被调用的方法，按层级写）
示例：如果 Service 方法 A 调用了方法 B，方法 B 调用了方法 C，这里要按层级写 B 和 C 的逻辑
- 方法 B（文件路径）：核心逻辑、分支判断、参数处理
- 方法 C（文件路径）：核心逻辑、SQL 调用、数据更新 / 插入逻辑
### 3.4 DAO / 数据访问层
- 涉及的 Mapper 文件路径
- 核心 SQL 逻辑：新增 / 修改 / 查询操作的条件、字段
- 数据操作的影响表、字段

## 4. 关键分支与异常处理
- 所有 if/else 分支的触发条件、业务含义、处理逻辑
- try-catch 异常捕获的类型、处理方式、返回码
- 事务回滚的触发条件

## 5. 依赖服务与外部调用
- 接口中调用的其他 Service、工具类、第三方接口
- 每个依赖调用的作用、入参、返回值、异常处理

## 6. 数据流转说明
从接口入参 {id} 开始，记录每个步骤中参数的赋值、转换、校验，直到最终数据库操作和返回值的完整流转过程。

## 7. 注意事项与潜在风险
- 事务传播行为、并发安全、数据一致性相关的潜在问题
- 缓存操作、重复提交的处理逻辑
- 接口调用方需要注意的入参规范、返回码含义

---
【强制约束】
1. 只分析后端目录下的 Java 后端代码，不处理前端代码
2. 必须递归展开所有被调用的方法，包括嵌套的 Service、工具类、Mapper 方法，不得省略任何层级
3. 所有提到的方法必须标注完整的文件路径，不得只写方法名
4. 流程图必须包含所有分支，不能只画主流程
5. 所有业务逻辑必须结合项目实际代码分析，不得写伪代码或泛泛而谈
6. 最终生成的文件直接写入 docs/文件名，确保格式为标准 Markdown
---
【补充约束】
分析过程中，每调用一个新的方法，都要自动读取该方法的文件内容，确保完全理解该方法的所有逻辑，不得凭经验推测。

场景：分析后端接口业务流程1

# 替换参数1：待分析接口URL（示例：/v1/api/xxx）
接口URL：${接口URL}
# 替换参数2：接口对应的业务名称（示例：订单确认完成）
业务名称：${业务名称}

【核心任务】
针对Java后端接口 `${接口URL}`，以「业务视角」深度拆解「${业务名称}」的完整业务逻辑，生成一份以业务内容为核心的结构化Markdown文档，保存至项目 `docs/` 目录，文件名为「${业务名称}-业务全流程分析.md」。

---
【核心分析原则（优先级排序）】
1. 业务第一：所有分析围绕“为什么做（业务背景）→ 做什么（业务动作）→ 怎么做（业务规则）→ 做了之后有什么影响（业务结果）”展开，技术实现仅作为业务落地的补充说明；
2. 全链路覆盖：从接口触发的业务场景开始，递归梳理所有关联的业务环节，不遗漏任何业务分支、异常场景；
3. 贴近实际：所有分析必须结合项目代码中体现的真实业务规则，不得写通用化、无落地性的业务描述；
4. 通用适配：无论接口是查询/新增/修改/删除类型，均按此逻辑拆解，无需调整分析框架。

---
【强制分析步骤（按业务逻辑顺序执行）】
1.  **业务背景与场景定位**：
   - 该接口对应的核心业务场景（比如：哪个角色在什么系统操作下触发？是XX业务流程的哪个环节？）；
   - 该接口解决的核心业务问题（比如：完成XX操作后需要同步哪些业务数据？是否关联库存/订单/用户等业务实体？）；
2.  **业务入参与前置条件**：
   - 接口入参（如{id}/{code}）对应的业务实体核心属性；
   - 触发该接口的业务前置条件（比如：XX业务状态必须为XX？必须完成XX前置操作？）；
   - 不符合前置条件时的业务处理规则（比如：返回什么业务提示？是否阻断流程？）；
3.  **核心业务流程拆解（按执行顺序）**：
   - 从“触发接口”到“流程结束”的完整业务动作链（通用框架：校验→核心操作→数据同步→结果反馈）；
   - 每个业务动作的核心目的、执行规则、关联的业务实体；
   - 所有业务分支的触发条件与处理逻辑（比如：不同业务类型/角色/状态的差异化处理）；
4.  **业务异常与兜底规则**：
   - 所有业务异常场景（比如：参数不满足业务规则、关联数据不存在、操作权限不足）；
   - 每个异常的业务兜底策略（比如：回滚业务动作、记录异常日志、触发人工审核、返回业务错误码）；
5.  **业务结果与后续影响**：
   - 接口执行成功后，相关业务实体的状态变化；
   - 触发的后续业务流程（比如：消息通知、数据同步、自动生成关联单据）；
6.  **技术落地补充（仅为业务服务）**：
   - 简要说明核心业务动作对应的技术实现路径（Controller→Service→DAO），仅标注“哪个业务动作对应哪个核心Service方法”；
   - 用流程图关联“业务动作”与“技术实现”，体现业务到代码的落地逻辑。

---
【文档强制结构（业务内容占比≥80%）】
# ${业务名称}-业务全流程分析
## 1. 业务核心信息
- 接口关联业务场景：（描述该接口在业务流程中的定位，非技术定位）
- 核心业务目标：（一句话说明该接口解决的核心业务问题）
- 业务适用范围：（比如：仅适用于XX类型的业务、XX角色可操作）
- 接口基础信息（补充）：${接口URL}（自动识别请求方式：GET/POST/PUT/DELETE）

## 2. 业务全流程可视化（Mermaid流程图）
```mermaid
flowchart TD
    A[触发${业务名称}操作] --> B{业务前置校验}
    B -->|校验通过| C[核心业务动作1]
    B -->|校验失败| D[返回业务异常提示]
    C --> E[核心业务动作2]
    E --> F[同步关联业务数据]
    F --> G[反馈业务执行结果]
    G --> H[流程结束]
    %% 自动替换为实际业务动作，标注核心业务规则
    note[注：补充该流程的核心业务规则说明]
3. 核心业务流程拆解（按执行顺序）
3.1 业务前置条件校验
- 核心校验规则：
  1. （从代码中提取：比如 XX 业务状态必须为 XX、参数必须满足 XX 规则）；
  2. （从代码中提取：比如操作人必须有 XX 业务权限、关联数据必须存在）；
- 校验失败的业务处理：
  - 场景 1：XX 异常 → 返回 “XX 业务提示”，阻断流程；
  - 场景 2：XX 异常 → 返回 “XX 业务提示”，允许修改后重试。
3.2 核心业务动作 1（自动匹配实际动作）
- 业务目的：（该动作解决的核心业务问题）；
- 业务规则：（执行该动作需遵循的业务规则，如状态不可回退、数据维度约束）；
- 技术落地补充：对应 XXService.XX 方法（仅说明业务落地的核心方法，无需代码细节）。
3.3 核心业务动作 2（自动匹配实际动作）
- 业务目的：；
- 业务规则：；
- 技术落地补充：对应 XXService.XX 方法。
3.4 其他业务动作（按实际流程补充）
...
4. 业务异常与兜底规则
异常业务场景
触发条件
业务兜底策略
对后续流程的影响
（自动提取）
（从代码中提取触发条件）
（业务层面的处理方式，非技术报错）
（对业务流程的影响）
（自动提取）
（从代码中提取触发条件）
（业务层面的处理方式，非技术报错）
（对业务流程的影响）
5. 业务结果与后续影响
5.1 业务实体状态变化
业务实体
变更前状态
变更后状态
业务意义
（自动提取）
（变更前）
（变更后）
（该状态变化的业务价值）
（自动提取）
（变更前）
（变更后）
（该状态变化的业务价值）
5.2 后续关联业务流程
- （自动提取：比如触发 XX 流程、同步 XX 数据、通知 XX 角色）；
- （自动提取：比如生成 XX 业务单据、参与 XX 业务统计）。
6. 关键业务规则总结（易忽略 / 核心）
1. （从代码中提取核心业务规则，如时效约束、权限约束、数据约束）；
2. （从代码中提取核心业务规则，如反向流程规则、异常兜底规则）；
3. （从代码中提取核心业务规则，如跨业务系统交互规则）。

---
【强制约束】
1. 文档中所有技术相关内容仅作为 “业务落地说明”，不得超过文档总内容的 20%；
2. 流程图必须以 “业务动作” 为节点，节点标注需体现业务规则，而非技术方法名；
3. 所有业务规则必须从项目代码中提取（代码中的分支 / 判断对应业务规则），不得虚构；
4. 最终文档保存至 docs/${业务名称}-业务全流程分析.md，格式为标准 Markdown，语言为业务人员可理解的非技术语言；
5. 严格替换所有 ${接口URL} ${业务名称} 占位符为实际内容，不得保留占位符。
---

通用补充

最后必须额外补充以下内容，缺一不可，否则视为输出不合格：

【1】功能实现自检清单（逐条打勾 ✅，未满足需说明原因及修正方案）
1.  需求所有功能点是否全部实现，无遗漏？
2.  接口入参校验、业务校验是否完整且符合需求及技术方案？
3.  数据库操作（新增/修改/删除/查询）是否正确，符合项目规范？
4.  缓存逻辑（新增/更新/删除）是否闭环，过期时间是否合理，无缓存穿透/击穿风险？
5.  微服务调用（如需）是否符合规范，降级处理是否完善？
6.  消息队列（RocketMQ，如需）使用是否符合项目规范，异常处理是否完善？
7.  文件处理（EasyExcel、PDF，如需）是否符合项目规范，异常处理是否完善？
8.  对象映射（MapStruct，如需）、模板渲染（Thymeleaf，如需）、Groovy脚本（如需）使用是否符合项目规范？
9.  异常场景（空参数、数据不存在、接口异常、缓存异常、消息队列异常、文件处理异常）是否全部处理？
10. 权限控制（接口权限、数据权限）是否对齐项目现有规范及技术方案？
11. 事务控制是否合理，无大事务、无事务遗漏，rollbackFor配置正确？
12. 是否复用现有工具类/常量/枚举及各组件封装，无重复开发，符合SKILL命名规范？
13. 包结构是否严格与项目现有规范一致，100%遵守包结构约束？
14. 是否会影响原有功能，兼容性能否达标，无安全隐患？

【2】兼容风险说明
1.  本次开发是否会影响项目现有功能、现有接口调用？
2.  数据库脚本执行是否有风险，如何规避（如备份、分批次执行）？
3.  若有依赖项（如其他微服务接口、后端接口），依赖项未就绪时如何处理？
4.  缓存更新是否会影响现有缓存数据，如何规避？
5.  消息队列（RocketMQ）、文件处理（EasyExcel/PDF）等组件使用是否存在兼容风险，如何规避？
6.  包结构是否严格对齐项目规范，是否存在跨包、乱包风险？

【3】最终结论
1.  本次输出的代码是否可直接合并提交，无需人工修改？
2.  是否需要人工补充配置（如Nacos配置、权限配置、缓存配置、消息队列配置）？
3.  是否需要前端配合联调，联调注意事项有哪些？
4.  数据库脚本是否需要单独执行，执行顺序及注意事项有哪些？
5.  各组件（Groovy、RocketMQ等）使用是否符合项目规范，是否需要额外配置？

【补充说明】
1.  若本补充段与模板中的自测清单内容冲突，以模板中经我确认后的自测清单为准。
2.  所有环节必须严格遵循“技术方案确认→代码生成→自测清单确认→最终交付”的流程，未得到我的确认，不得擅自推进。
3.  包结构约束为核心强制约束，必须100%遵守项目现有规范，任何违反包结构的代码均视为不合格。

二、前端项目提示词范例

说明：模板适配「Vue3 + Element Plus + TypeScript + Axios（封装） + Pinia + 管理后台」，完全对齐你已有的全局SKILL规范，无需修改，每次需求直接粘贴，替换【需求描述】即可，AI输出可直接提交，大幅减少人工自测。

场景：小功能迭代|小改小修

适用场景：单个接口修改、表单加字段/改校验、列表加筛选排序、小交互优化、简单bug修复、文案/样式/权限微调、单个组件修改

你现在基于我当前打开的前端项目（Vue3+Element Plus+TS+Pinia+Axios封装）+ 已生效的前端全局SKILL规范，完成一次小功能迭代。
核心目标：最终代码可直接提交，无需人工二次自测、无需返工，完全符合项目规范，不破坏现有功能。

【需求描述】
__________________________（直接粘贴你的小需求，例：表单新增“联系电话”字段，必填，格式校验为11位手机号；列表新增“联系电话”列显示）

【严格约束（必须100%遵守）】
1.  最小改动原则：只修改与需求直接相关的代码，不改动无关逻辑、不重构、不优化无关代码、不新增多余文件。
2.  规范对齐原则：严格遵循项目全局SKILL，包括但不限于：文件命名、目录结构、组件用法、Axios请求封装、TS类型定义、异常处理、权限控制、日志规范。
3.  复用优先原则：必须复用项目现有组件（Element Plus组件、项目公共组件）、hooks、工具函数，不重复造轮子。
4.  兼容安全原则：必须兼容现有页面所有逻辑，不破坏原有功能，不引入新的bug。
5.  边界处理原则：所有边界场景必须自带完整处理，包括：空数据、加载状态、接口异常（失败重试）、无权限、重复提交、非法入参。
6.  请求规范原则：接口请求必须按项目现有Axios封装规范，包含loading状态、统一错误提示、必要的防抖/节流、取消重复请求。
7.  代码质量原则：禁止硬编码、禁止魔法值、禁止any类型、禁止未处理的异常、禁止冗余代码。

【输出要求（缺一不可）】
1.  第一步：【技术方案设计】
    输出适配本次小需求的简洁技术方案，包含：需修改/新增的文件、核心实现逻辑、接口对接方式、边界场景处理方案、与现有代码的兼容处理，方案需简洁明了、贴合需求及项目规范。
    输出后必须明确通知我：“技术方案设计已完成，请你检查、修改、增减技术方案内容，确认无误后，我将进入代码生成环节”，等待我的确认指令后，再进行下一步。
2.  第二步：【代码生成】
    待我确认技术方案无误后，明确标注每个修改/新增文件的完整路径（必须与项目现有目录结构完全一致），后跟完整可运行代码，无需修改可直接保存。
    代码自带清晰注释（关键逻辑、参数说明），结构、风格与项目现有代码完全统一，符合SKILL规范。
3.  第三步：【自测清单生成与确认】
    代码生成完毕后，输出【自测验收清单】，逐条验证是否满足需求、技术方案及约束，每条必须打勾（✅）或明确说明未满足原因及修正方案。
    输出后必须明确通知我：“自测清单已生成，请你检查、修改、增减自测清单内容，确认无误后，我将完成自测并最终交付”，等待我的确认指令后，再进行最终自测交付。
4.  第四步：【最终交付】
    待我确认自测清单无误后，补充输出【兼容风险说明】，明确是否会影响原有功能、可能的影响点及规避方案，完成最终交付。
5.  禁止输出任何伪代码、示例代码、占位逻辑，所有代码必须真实可运行、无语法错误；未得到我的确认指令，不得擅自进入下一环节。

场景：大项目|新页面|新模块

适用场景：新建完整页面、新建业务模块（列表+表单+详情+导出）、复杂交互流程、多步骤表单/审批/配置、涉及路由/权限/状态管理的开发

你现在基于我当前打开的前端项目（Vue3+Element Plus+TS+Pinia+Axios封装）+ 前端全局SKILL规范，完成一个完整模块/页面开发。
核心目标：代码可直接合并提交，基本无需人工自测、无需返工，结构规范、逻辑闭环、兼容现有项目。

【需求描述】
__________________________（直接粘贴完整需求，例：新建“用户管理”模块，包含用户列表（筛选、分页、删除、编辑）、新增/编辑用户表单、用户详情页面，支持权限控制，对接后端用户相关接口）

【全局架构约束（必须100%遵守）】
1.  目录结构约束：严格按项目现有目录结构创建文件，规范如下（与项目必须保持100%一致）：
    - 页面：src/views/【模块名】/index.vue
    - 类型定义：src/types/【模块名】.ts
    - 接口封装：src/api/【模块名】.ts
    - 钩子函数：src/hooks/use【模块名】.ts
    - 状态管理：src/store/modules/【模块名】.ts（如需）
    - 子组件：src/views/【模块名】/components/【子组件名】.vue（如需）
    - 路由配置：src/router/modules/【模块名】.ts（如需）
2.  组件复用约束：严格复用项目现有基础组件（Element Plus组件、项目公共组件），不重复开发已有的组件、hooks、工具函数。
3.  请求规范约束：严格使用项目统一封装的Axios请求库，包含统一loading、统一错误提示、请求拦截、响应拦截，对齐项目现有请求规范。
4.  TS类型约束：完整的类型定义（接口请求/响应、组件props、状态、变量），禁止any类型，接口返回结构必须与后端完全对齐。
5.  权限控制约束：按钮权限、路由权限、数据权限，与项目现有权限逻辑保持一致，使用项目统一的权限指令/工具。
6.  交互规范约束：完整处理所有交互场景，包括：空数据状态、加载状态、接口失败重试、防抖、防重复提交、分页逻辑、筛选重置。
7.  样式规范约束：样式必须使用项目现有CSS类名、变量、主题，不写冗余内联样式，不引入新的样式文件（除非必要），对齐项目现有样式规范。
8.  兼容安全约束：不引入任何新依赖，不改变现有项目架构，不破坏原有功能，不引入SQL注入、XSS等安全风险。

【输出结构要求（按顺序输出，缺一不可）】
1.  第一步：【技术方案设计】
    输出适配本次大模块/页面开发的完整技术方案，包含：模块文件结构、核心实现逻辑、接口对接方案、状态管理方案（如需）、路由配置方案（如需）、组件拆分逻辑、边界场景处理方案、权限控制方案、与现有项目的兼容方案。
    输出后必须明确通知我：“技术方案设计已完成，请你检查、修改、增减技术方案内容，确认无误后，我将进入代码生成环节”，等待我的确认指令后，再进行下一步。
2.  第二步：【代码生成】
    待我确认技术方案无误后，先输出【模块文件结构树】，明确所有新增/修改的文件路径，让我确认路径无误后，再按以下顺序输出完整可运行代码（每个文件必须完整，无需修改可直接保存）：
    - 第一步：src/types/【模块名】.ts（类型定义）
    - 第二步：src/api/【模块名】.ts（接口封装）
    - 第三步：src/hooks/use【模块名】.ts（钩子函数，如需）
    - 第四步：src/store/modules/【模块名】.ts（状态管理，如需）
    - 第五步：子组件（如需）
    - 第六步：src/views/【模块名】/index.vue（页面主文件）
    - 第七步：src/router/modules/【模块名】.ts（路由配置，如需）
    每个文件代码自带清晰注释（关键逻辑、参数说明、权限控制说明），结构、风格与项目现有代码完全统一。
3.  第三步：【自测清单生成与确认】
    代码生成完毕后，输出【功能自测清单】，覆盖正常场景、异常场景、边界场景、权限场景、空数据场景，逐条打勾（✅）验证，明确是否满足需求及技术方案。
    输出后必须明确通知我：“自测清单已生成，请你检查、修改、增减自测清单内容，确认无误后，我将完成自测并最终交付”，等待我的确认指令后，再进行最终自测交付。
4.  第四步：【最终交付】
    待我确认自测清单无误后，补充输出以下2项内容，完成最终交付：
    - 【与现有项目兼容说明】：明确是否会影响原有功能、可能的影响点及规避方案，确保无兼容风险。
    - 【最终结论】：明确说明代码是否可直接合并提交、是否需要人工修改、是否需要额外配置。
5.  禁止任何伪代码、示例代码、占位逻辑，所有逻辑必须真实可运行、无语法错误、无类型错误，完全符合项目全局SKILL规范；未得到我的确认指令，不得擅自进入下一环节。

通用补充

（所有提示词末尾必加，省自测关键）

最后必须额外补充以下内容，缺一不可，否则视为输出不合格：

【1】功能实现自检清单（逐条打勾 ✅，未满足需说明原因及修正方案）
1.  需求所有功能点是否全部实现，无遗漏？
2.  表单校验（必填、格式、长度）是否完整且符合需求？
3.  加载状态、空数据、接口失败、无权限场景是否全部处理？
4.  防重复提交、防抖/节流是否按需求及技术方案实现？
5.  TS类型是否完整，无any类型、无类型错误？
6.  接口请求是否符合项目Axios封装规范，异常提示是否统一？
7.  权限控制（路由、按钮、数据）是否对齐项目现有规范及技术方案？
8.  样式是否符合项目主题和规范，无冗余、无错乱？
9.  是否复用现有组件/hooks/工具函数，无重复开发？
10. 是否会影响原有功能，兼容性能否达标？

【2】兼容风险说明
1.  本次开发是否会影响项目现有功能？
2.  可能存在的影响点有哪些，如何规避？
3.  若有依赖项（如后端接口、其他模块），依赖项未就绪时如何处理？

【3】最终结论
1.  本次输出的代码是否可直接合并提交，无需人工修改？
2.  是否需要人工补充配置（如路由注册、权限配置）？
3.  是否需要后端接口配合联调，联调注意事项有哪些？

【补充说明】
1.  若本补充段与模板中的自测清单内容冲突，以模板中经我确认后的自测清单为准。
2.  所有环节必须严格遵循“技术方案确认→代码生成→自测清单确认→最终交付”的流程，未得到我的确认，不得擅自推进。