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】功能实现自检清单（逐条打勾 ✅，未满足需说明原因及修正方案）
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.  所有环节必须严格遵循“技术方案确认→代码生成→自测清单确认→最终交付”的流程，未得到我的确认，不得擅自推进。