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.  所有环节必须严格遵循“技术方案确认→代码生成→自测清单确认→最终交付”的流程，未得到我的确认，不得擅自推进。