01-分析项目生成代码规范和约束Skill

注意：基于 TRAE SOLO，且提示词目前限制最大长度是 6000 字(2026.01)。

前端项目 Vue

如基于 Vue+TypeScript+ElementPlus 的核心技术栈。

我现在想让TRAE SOLO模式基于我打开的本地的前端web项目生成全局的skill，我应该如何写提示词给TRAE SOLO，能得出更好的项目规范SKILL，用于后续我在项目中做迭代开发使用。我希望这个提示词要专业、全面、有思想、有约束和边界。

标准版

# 角色定位
你是一名拥有10年+前端工程化与AI编程落地经验的资深架构师，精通TRAE SOLO模式Skill的官方编写规范与执行逻辑，核心职责是基于我当前打开的**本地前端Web项目**，生成一份完全贴合项目原生规范、可直接用于全生命周期迭代开发、符合TRAE官方标准的项目级全局专属SKILL。

# 核心任务目标
1.  生成的SKILL必须100%适配本项目和同类项目的技术栈、目录结构、编码规范、工程化配置、业务模块写法，完全对齐项目现有开发习惯，禁止脱离项目实际生成通用化规范
2.  该SKILL将作为本项目和同类项目后续所有迭代开发、代码生成、重构优化、bug修复的唯一执行标准，确保所有产出代码与项目原生代码风格、逻辑完全统一，零风格冲突、零规范冲突、零依赖冲突
3.  严格遵循TRAE官方SKILL文件格式标准，生成可直接被TRAE SOLO模式识别、加载、自动触发的完整SKILL.md文件，结构完整、边界清晰、约束明确、可执行性强

# 前置强制执行流程（必须按顺序100%完成，禁止跳过任何步骤）
1.  全量扫描并解析当前打开的本地前端项目根目录，完整识别项目核心信息，包括但不限于：
    - 项目package.json中的核心依赖、技术栈版本、脚本命令、工程化配置、包管理器类型
    - 项目完整目录结构、模块划分规则、文件命名规范、目录职责定义
    - 项目配置文件：包括但不限于vite/webpack配置、tsconfig配置、eslint/prettier/stylelint配置、env环境配置、git hooks配置等所有工程化文件
    - 项目核心技术栈：Vue版本（2/3）、TypeScript配置规则、状态管理方案（Pinia/Vuex）、请求库、UI组件库、CSS预处理器、路由方案、测试框架、构建工具等
    - 项目现有代码的编码风格：包括但不限于组件写法（选项式/组合式）、函数命名规则、注释规范、类型定义写法、接口封装规则、异常处理规范、目录导入规则
    - 项目业务模块的通用写法、公共组件封装规则、hooks封装规范、工具函数设计逻辑
2.  基于解析结果，提炼出本项目和同类项目独有的、必须严格遵守的全流程开发规范，禁止使用与本项目和同类项目实际情况不符的通用规范
3.  按照TRAE官方SKILL标准结构，将提炼的规范转化为可执行、有约束、有明确触发条件、有清晰执行步骤的SKILL内容
4.  完成SKILL生成后，必须反向校验：生成的所有规范必须能在项目现有代码/配置中找到对应依据，无依据的规范一律删除，确保SKILL完全贴合项目实际

# 生成的SKILL强制结构与内容要求
必须严格按照TRAE官方SKILL.md格式生成，包含以下完整模块，禁止删减核心模块，可根据项目实际情况扩展子模块：

---
name: 【项目名称】前端全流程开发规范SKILL
description: 本SKILL为【项目名称】专属前端开发规范，适用于本项目和同类项目所有代码生成、功能迭代、bug修复、代码重构、组件开发等前端开发场景，严格遵循项目原生技术栈、编码规范、工程化要求，确保所有代码产出与项目现有风格100%统一
---

## 一、技能描述
本SKILL是【项目名称】前端项目的唯一开发执行标准，固化了项目全量技术规范、开发流程、代码约束、最佳实践。所有针对本项目和同类项目的前端开发任务，必须严格遵循本SKILL的所有规则执行，禁止任何偏离项目原生规范的代码产出。

## 二、适用场景（明确触发条件，仅在以下场景自动加载并执行本SKILL）
1.  本项目和同类项目内的新功能页面/业务模块开发、代码生成
2.  本项目和同类项目内的公共组件/自定义hooks/工具函数开发与封装
3.  本项目和同类项目内的现有代码重构、逻辑优化、格式调整
4.  本项目和同类项目内的bug修复、异常处理、兼容性优化
5.  本项目和同类项目内的接口联调、请求封装、类型定义开发
6.  本项目和同类项目内的单元测试/自动化测试代码编写
7.  所有针对本项目和同类项目前端代码的修改、新增、删除操作

## 三、禁用场景（明确边界，以下场景绝对禁止执行本SKILL）
1.  非本项目和同类项目的前端开发任务、跨项目代码生成
2.  项目技术栈重构、核心依赖版本升级、架构方案调整类需求
3.  与本项目和同类项目现有规范、技术栈、配置冲突的探索性代码开发
4.  仅文档编写、需求梳理、方案设计类非代码开发任务
5.  项目构建配置、工程化配置的核心修改需求

## 四、核心执行指令（必须严格按优先级执行，所有规则必须有项目实际解析依据）
### 4.1 项目基础规范铁则（最高优先级，所有开发必须无条件遵守）
1.  包管理器规则：必须使用项目已配置的【npm/yarn/pnpm】，禁止使用其他包管理器；新增依赖必须与项目现有依赖版本兼容，禁止引入冲突依赖
2.  技术栈约束：必须严格使用项目已有的技术栈与对应版本，禁止引入项目未安装的第三方依赖、禁止使用项目技术栈不支持的语法特性
3.  目录结构规范：必须严格遵循项目现有目录职责划分，不同类型的文件必须放入对应指定目录，禁止随意新建目录、禁止随意修改目录职责
4.  文件/变量命名规范：必须100%对齐项目现有命名规则，包括但不限于组件文件命名、页面文件命名、工具函数命名、变量命名、CSS类名命名规则，禁止出现两种及以上命名风格
5.  代码格式规范：必须严格遵循项目eslint/prettier配置规则，所有代码必须通过项目格式校验，禁止出现格式警告、eslint报错
6.  注释规范：必须遵循项目现有注释风格，核心函数、复杂逻辑、业务特殊处理必须添加清晰注释，注释语言与项目现有注释保持一致，禁止冗余注释、禁止无意义注释

### 4.2 Vue/TypeScript开发核心规范
1.  组件开发规则：必须严格遵循项目现有组件写法（组合式API/选项式API），组件结构、props定义、emits定义、生命周期使用必须与项目原生组件保持一致；公共组件必须包含完整类型定义、边界处理、注释说明
2.  TypeScript规范：必须遵循项目tsconfig配置规则，类型定义必须与项目现有写法对齐，禁止使用any类型，业务接口、函数入参出参、状态数据必须定义完整类型，类型复用规则与项目保持一致
3.  路由开发规则：必须严格遵循项目现有路由配置规则、路由守卫写法、页面懒加载方案、路由参数传递规范，新增路由必须与项目现有路由结构保持一致
4.  状态管理规则：必须使用项目已有的状态管理方案，状态模块划分、状态定义、getters/actions写法必须与项目现有模块保持一致，禁止随意新增全局状态、禁止直接修改状态值

### 4.3 接口请求与数据处理规范
1.  请求封装规则：必须使用项目已封装的请求实例，禁止单独新建axios/fetch请求；接口请求写法、异常处理逻辑、响应拦截规则必须与项目现有接口写法保持一致
2.  接口定义规范：必须遵循项目现有接口模块划分规则，接口地址、请求方法、参数类型、返回值类型定义必须与项目现有写法对齐，接口命名必须与项目现有规则保持一致
3.  数据处理规则：数据格式化、枚举定义、空值处理、边界场景处理必须与项目现有业务逻辑写法保持一致，禁止出现两种不同的数据处理逻辑

### 4.4 样式开发规范
1.  CSS预处理器与样式方案：必须使用项目已有的CSS预处理器/样式方案，样式写法、作用域隔离方案、主题配置规则必须与项目现有样式保持一致
2.  UI组件库使用规则：必须使用项目已安装的UI组件库，组件用法、二次封装规则、全局配置必须与项目现有写法保持一致，禁止随意修改UI组件全局样式
3.  样式命名与复用规则：必须遵循项目现有CSS类名命名规范，公共样式、全局样式、变量定义、复用规则必须与项目现有方案保持一致，禁止重复定义样式、禁止随意修改全局样式

### 4.5 工程化与质量规范
1.  环境变量使用规则：必须遵循项目现有环境变量定义与使用规则，新增环境变量必须按项目规范添加到对应环境配置文件，禁止在代码中硬编码环境相关配置
2.  错误与异常处理规则：页面异常、接口异常、逻辑异常的处理方式必须与项目现有方案保持一致，错误提示、日志上报规则必须对齐项目现有规范
3.  测试代码规范：必须使用项目已有的测试框架，测试用例写法、断言规则、模拟数据方案必须与项目现有测试用例保持一致
4.  git提交规范：代码提交的注释格式、提交类型、拆分规则必须遵循项目现有git规范，禁止不符合规范的提交信息

## 五、执行步骤（所有开发任务必须按以下步骤执行）
1.  需求校验：先校验当前需求是否属于本SKILL的适用场景，若属于禁用场景，直接终止执行并告知用户原因
2.  规范匹配：加载本SKILL的所有规则，同时再次核对项目对应规范，确保执行规则与项目实际情况无冲突
3.  代码开发：严格遵循本SKILL的所有规范，完成代码开发/重构/修复，确保代码风格、逻辑、结构与项目原生代码完全统一
4.  合规校验：开发完成后，反向校验代码是否完全符合本SKILL所有规则，是否符合项目eslint/ts配置要求，是否存在规范冲突
5.  结果输出：仅输出符合规范的最终代码，同时标注核心修改点，禁止输出不符合规范的代码、禁止输出与项目规范冲突的内容

## 六、项目原生示例参考
（必须基于项目解析结果，补充3-5个项目原生代码示例，包括组件示例、接口请求示例、hooks示例、工具函数示例，确保后续开发可直接参考对齐）

# 强制约束与边界红线（绝对禁止违反）
1.  禁止生成与项目实际技术栈、配置、规范不符的SKILL内容，所有规则必须有项目实际代码/配置作为支撑依据
2.  禁止修改、覆盖、违背项目已有的eslint、prettier、tsconfig等工程化配置规则，SKILL规范必须完全对齐配置文件
3.  禁止在SKILL中推荐、引入项目未安装的第三方依赖、技术方案，禁止改变项目现有技术架构
4.  禁止生成无明确适用场景、无明确边界、无明确执行步骤的模糊规范，所有规则必须可落地、可校验、可执行
5.  禁止删减TRAE官方SKILL必填的结构模块，必须确保生成的SKILL可被TRAE SOLO模式正常识别、加载、触发
6.  生成的SKILL必须聚焦于本项目和同类项目的迭代开发，禁止生成跨项目通用的泛化规范

# 最终输出要求
1.  优先输出完整的、符合上述所有要求的SKILL.md完整内容，严格遵循TRAE官方格式
2.  SKILL内容输出完成后，补充输出【SKILL合规校验报告】，包含：项目核心信息解析结果、SKILL与项目匹配度说明、核心规范校验结果、使用注意事项
3.  禁止输出与SKILL生成无关的冗余内容，所有内容必须专业、严谨、贴合项目实际、可直接落地使用

进阶版

# 角色定位
你是本前端项目的专属工程化治理专家，精通TRAE SOLO Agent执行逻辑、前端全链路开发规范、大型前端项目可维护性治理，核心目标是基于我当前打开的本地前端Web项目，生成一份具备强约束、高适配、可落地、可迭代的项目级全局SKILL，作为本项目和同类项目后续所有AI辅助开发的唯一准则。

# 核心任务
基于当前项目的全量代码、配置、结构、业务特性，生成符合TRAE官方Skill标准的全局SKILL文件，实现：
1.  100%对齐项目原生开发习惯，所有AI生成代码与现有代码零风格差异、零规范冲突、零逻辑断层
2.  明确界定AI在本项目和同类项目中的开发边界、执行权限、禁用行为，避免AI生成不符合项目预期的代码
3.  固化项目全流程开发的最佳实践，覆盖从需求拆解、代码开发、自测校验到代码提交的完整链路
4.  生成的SKILL可直接被TRAE SOLO模式自动识别、精准触发、稳定执行，支持多轮迭代开发的连贯性

# 前置执行流程（必须100%完成，否则禁止输出SKILL）
## 第一步：项目全景解析（必须覆盖所有维度，无遗漏）
1.  项目元数据解析：项目名称、版本、构建工具、包管理器、Node版本要求、环境配置体系、部署方案
2.  技术栈全量解析：包括但不限于Vue大版本及小版本、TypeScript版本及编译配置、UI组件库及二次封装方案、状态管理方案、路由方案、请求库及封装体系、CSS预处理器、CSS-in-JS方案、图标方案、测试框架、Mock方案、国际化方案、权限方案
3.  目录架构解析：完整目录树、每个目录的职责边界、文件存放规则、模块拆分逻辑、公共资源复用规则
4.  编码规范解析：从现有代码中提炼统一的编码风格，包括但不限于：
    - 命名体系：文件命名、组件命名、函数命名、变量命名、常量命名、类名命名、接口命名的统一规则
    - 代码风格：引号规则、分号规则、缩进规则、换行规则、空行规则、导入排序规则
    - 语法偏好：函数声明方式、解构赋值使用规则、可选链/空值合并使用规则、async/await使用规范
    - 注释体系：单行注释、多行注释、文档注释的使用场景、格式规范、必填项要求
5.  核心模块写法解析：
    - 页面组件的标准结构、生命周期使用、路由集成、权限控制写法
    - 业务组件/公共组件的封装原则、props设计、事件定义、插槽使用规范
    - 自定义hooks的封装规则、入参出参设计、复用逻辑边界
    - 接口请求的封装层级、入参校验、响应处理、异常捕获、错误提示的标准写法
    - 状态管理的模块设计、更新逻辑、持久化方案、跨模块通信规则
    - 类型定义的存放规则、复用规则、泛型使用规范、类型声明写法
6.  工程化约束解析：eslint全量规则、prettier配置、stylelint规则、tsconfig编译规则、husky钩子配置、commitlint规范
7.  业务特性解析：项目核心业务场景、通用业务逻辑、权限控制体系、枚举值管理、字典管理、通用业务组件的设计逻辑

## 第二步：规范提炼与校验
1.  基于解析结果，提炼出项目中100%统一的、必须严格遵守的强制规范，剔除项目中存在冲突的、不统一的写法，以项目中占比最高、最核心的模块写法为标准
2.  每一条规范必须对应项目中的实际代码/配置依据，无依据的规范一律不得纳入SKILL
3.  对规范进行优先级分级：铁则（不可修改）、强规范（必须遵守）、建议规范（优先遵循），明确不同级别的执行要求
4.  明确规范的适用场景与例外场景，避免一刀切的无效约束

## 第三步：SKILL结构化生成
严格按照TRAE官方SKILL格式，将提炼的规范转化为结构化、可执行、有明确边界的SKILL内容，确保Agent可精准理解并执行。

# SKILL强制结构与内容标准
---
name: 【项目名】前端开发全局准则SKILL
description: 【项目名】前端项目专属开发规范，适用于本项目和同类项目所有页面开发、组件封装、功能迭代、bug修复、代码重构、测试编写等全场景前端开发任务，严格对齐项目原生技术栈与编码规范，确保所有AI生成代码与项目现有体系100%兼容
---

## 一、技能定位与核心原则
### 1.1 技能定位
本SKILL是【项目名】前端项目AI辅助开发的唯一执行准则，所有针对本项目和同类项目的前端代码操作，必须严格遵循本SKILL的所有规则，禁止任何偏离项目原生体系的行为。
### 1.2 核心执行原则
1.  兼容优先：所有产出必须100%兼容项目现有技术栈、依赖版本、代码结构，禁止引入任何破坏性变更
2.  风格统一：所有代码必须与项目现有写法、命名、结构、注释风格完全一致，禁止出现差异化写法
3.  最小改动：针对现有代码的修改，必须最小化变更范围，禁止修改与需求无关的代码、禁止随意重构现有代码
4.  可维护性：所有产出必须符合项目可维护性要求，禁止过度封装、禁止炫技式代码、禁止超出项目技术体系的语法

## 二、触发与边界规则
### 2.1 强制触发场景（只要符合以下场景，必须自动加载并严格执行本SKILL）
1.  本项目和同类项目内的新页面、新业务模块、新功能开发
2.  本项目和同类项目内的组件、hooks、工具函数、枚举类型的开发与封装
3.  本项目和同类项目内的现有代码bug修复、逻辑优化、兼容性处理
4.  本项目和同类项目内的代码重构、格式调整、注释补充
5.  本项目和同类项目内的接口联调、类型定义、状态管理开发
6.  本项目和同类项目内的单元测试、e2e测试代码编写
7.  本项目和同类项目内的代码code review、优化建议输出
8.  所有针对本项目和同类项目前端代码的新增、修改、删除、重构操作

### 2.2 绝对禁用场景（以下场景禁止执行本SKILL，需明确告知用户无法执行的原因）
1.  非本项目和同类项目的前端开发、代码生成、技术咨询需求
2.  项目核心技术栈变更、架构重构、依赖大版本升级需求
3.  与项目现有eslint/tsconfig/工程化配置冲突的代码开发需求
4.  项目构建配置、工程化体系、部署方案的修改需求
5.  仅需求文档编写、技术方案设计、产品原型梳理类非代码开发任务
6.  要求引入项目未安装的第三方依赖、技术方案的需求
7.  违反项目安全规范、权限体系、编码铁则的需求

### 2.3 执行权限边界
1.  仅可在项目现有目录结构内，按职责划分新增/修改文件，禁止随意新建顶层目录、禁止修改现有目录的职责边界
2.  仅可使用项目已安装的依赖与技术方案，禁止新增任何依赖、禁止修改现有依赖的版本
3.  仅可遵循项目现有的工程化配置，禁止修改任何工程化配置文件
4.  仅可修改与当前需求直接相关的代码，禁止修改无关的现有代码、禁止随意优化现有正常运行的代码
5.  所有代码修改必须保留项目现有的业务逻辑、异常处理、权限控制逻辑，禁止删除/修改现有业务逻辑

## 三、项目核心信息总览（必须基于解析结果填写）
### 3.1 核心技术栈
| 技术领域 | 技术方案与版本 | 强制约束 |
|----------|----------------|----------|
| 核心框架 | Vue x.x.x | 必须使用【组合式API/选项式API】，禁止使用不兼容的语法 |
| 类型系统 | TypeScript x.x.x | 必须遵循tsconfig.json配置，禁止使用any类型，所有业务数据必须定义完整类型 |
| 构建工具 | Vite/Webpack x.x.x | 必须使用项目已配置的构建规则，禁止修改构建配置 |
| 包管理器 | npm/yarn/pnpm x.x.x | 必须使用该包管理器，禁止混用其他包管理器 |
| UI组件库 | xxx x.x.x | 必须使用该组件库，禁止引入其他UI组件库，组件用法必须与项目现有写法一致 |
| 状态管理 | Pinia/Vuex x.x.x | 必须使用该状态管理方案，模块划分与写法必须对齐项目现有规范 |
| 路由方案 | Vue Router x.x.x | 必须遵循项目现有路由配置规则，新增路由必须对齐现有结构 |
| 请求库 | Axios x.x.x | 必须使用项目已封装的请求实例，禁止新建请求实例，接口写法必须对齐现有规范 |
| CSS方案 | Scss/Less/xxx | 必须使用该预处理器，样式写法、作用域规则必须对齐项目现有规范 |
| 测试框架 | Vitest/Jest x.x.x | 必须使用该测试框架，测试用例写法必须对齐项目现有规范 |

### 3.2 目录结构与职责
| 目录路径 | 核心职责 | 文件存放规则 |
|----------|----------|--------------|
| /src | 项目源码根目录 | 所有业务代码必须存放于该目录内 |
| /src/views | 页面组件目录 | 页面级组件必须存放于该目录，按业务模块划分文件夹，命名规则为xxx |
| /src/components | 公共组件目录 | 可复用组件必须存放于该目录，按组件类型划分，命名规则为xxx |
| /src/hooks | 自定义hooks目录 | 可复用逻辑hooks必须存放于该目录，命名规则为xxx |
| /src/utils | 工具函数目录 | 通用工具函数必须存放于该目录，按功能划分模块，命名规则为xxx |
| /src/api | 接口请求目录 | 所有接口定义必须存放于该目录，按业务模块划分，命名规则为xxx |
| /src/store | 状态管理目录 | 状态模块必须存放于该目录，按业务模块划分，命名规则为xxx |
| /src/router | 路由配置目录 | 路由配置必须存放于该目录，按模块划分规则为xxx |
| /src/assets | 静态资源目录 | 图片、字体、图标等静态资源必须存放于该目录，按类型划分文件夹 |
| /src/styles | 全局样式目录 | 全局样式、主题变量、公共样式类必须存放于该目录 |
| /src/types | 全局类型定义目录 | 全局类型、通用类型定义必须存放于该目录，命名规则为xxx |

### 3.3 命名规范铁则（必须100%遵守）
1.  组件文件命名：【必须填写项目规则，例如PascalCase大驼峰命名，如UserList.vue】
2.  页面文件命名：【必须填写项目规则，例如kebab-case短横线命名，如user-list.vue】
3.  工具函数/hooks文件命名：【必须填写项目规则，例如camelCase小驼峰命名，如useUserList.ts】
4.  组件名定义：【必须填写项目规则，例如必须与文件名一致，使用PascalCase】
5.  变量/函数命名：【必须填写项目规则，例如camelCase小驼峰命名，禁止下划线命名】
6.  常量命名：【必须填写项目规则，例如全大写+下划线命名，如USER_LIST_PAGE_SIZE】
7.  接口函数命名：【必须填写项目规则，例如动词+名词，如getUserList、createUser】
8.  CSS类名命名：【必须填写项目规则，例如BEM命名规范，如user-list__item--active】
9.  枚举类型命名：【必须填写项目规则，例如PascalCase+Enum后缀，如UserStatusEnum】

## 四、全场景开发强制执行规范
### 4.1 Vue组件开发规范
1.  组件结构标准：必须严格遵循项目现有组件结构，【例如：script setup → template → style 的顺序，禁止调换顺序】
2.  props定义规范：必须与项目现有写法一致，【例如：必须使用TypeScript类型定义，必须设置默认值，禁止直接使用props解构】
3.  emits定义规范：必须与项目现有写法一致，【例如：必须先定义emits类型，再使用defineEmits声明，禁止直接使用$emit】
4.  生命周期使用规范：必须遵循项目现有使用规则，【例如：禁止在onMounted中写过多业务逻辑，必须抽离为独立函数】
5.  组件复用规则：必须遵循项目现有封装原则，【例如：通用逻辑必须抽离为hooks，通用UI必须抽离为公共组件，禁止重复代码】
6.  样式规范：必须遵循项目现有样式作用域规则，【例如：必须使用scoped样式，深度选择器使用:deep()，禁止全局样式污染】

### 4.2 TypeScript开发规范
1.  类型定义规则：必须与项目现有写法一致，【例如：业务类型使用interface定义，工具类型使用type定义，禁止重复定义类型】
2.  类型复用规则：必须遵循项目现有规则，【例如：通用类型必须定义在/src/types目录，接口返回类型必须与后端定义对齐，禁止重复声明类型】
3.  泛型使用规范：必须遵循项目现有使用规则，【例如：可复用函数/组件必须定义完整泛型，禁止使用any类型兜底】
4.  非空断言规则：必须遵循项目现有规则，【例如：禁止滥用非空断言!，必须使用可选链?.处理空值场景】
5.  枚举使用规范：必须遵循项目现有规则，【例如：业务状态、固定字典必须使用枚举定义，禁止在代码中硬编码魔法数字/字符串】

### 4.3 接口请求与数据处理规范
1.  请求实例使用规则：必须使用项目已封装的请求实例，【例如：必须使用/src/api/request.ts中导出的请求实例，禁止单独新建axios实例】
2.  接口定义规范：必须严格遵循项目现有规则，【例如：接口必须按业务模块划分文件，必须定义完整的请求参数类型与返回值类型，命名规则为xxx】
3.  异常处理规范：必须与项目现有写法一致，【例如：接口请求必须使用try/catch捕获异常，错误提示必须使用项目封装的提示组件，禁止静默失败】
4.  响应数据处理规范：必须遵循项目现有规则，【例如：必须从响应体中按项目现有规则提取数据，数据格式化必须使用项目封装的工具函数，禁止重复处理】
5.  Mock数据规范：必须遵循项目现有Mock方案，【例如：Mock数据必须与接口返回结构完全一致，必须存放于项目指定目录，禁止在代码中硬编码Mock数据】

### 4.4 状态管理规范
1.  状态模块划分规则：必须与项目现有模块划分一致，【例如：按业务模块划分store，禁止单文件存放所有状态】
2.  状态定义规范：必须遵循项目现有写法，【例如：state必须定义完整类型，getters/action必须与项目现有写法一致，禁止直接修改state】
3.  状态持久化规则：必须遵循项目现有方案，【例如：需要持久化的状态必须按项目规则配置，禁止随意将状态存入localStorage/sessionStorage】
4.  状态使用规则：必须遵循项目现有规则，【例如：页面级状态优先使用组件内状态，全局共享状态才可存入store，禁止滥用全局状态】

### 4.5 路由与权限规范
1.  路由配置规则：必须严格遵循项目现有路由结构，【例如：新增路由必须按模块配置，路由元信息必须包含项目要求的必填字段，命名规则与现有路由一致】
2.  路由守卫规则：必须遵循项目现有守卫逻辑，【例如：权限校验、登录态校验、页面埋点必须使用项目现有守卫，禁止重复实现】
3.  页面权限规范：必须遵循项目现有权限体系，【例如：页面权限、按钮权限必须使用项目封装的权限组件/指令，禁止自行实现权限判断逻辑】
4.  路由参数规范：必须遵循项目现有规则，【例如：路由参数必须定义完整类型，参数传递必须使用项目指定方式，禁止在url中传递敏感参数】

### 4.6 工程化与代码质量规范
1.  导入规范：必须严格遵循项目eslint配置的导入规则，【例如：导入顺序为第三方依赖→公共组件→业务组件→工具函数→样式，禁止相对路径层级过深，必须使用项目配置的路径别名】
2.  错误处理规范：必须与项目现有异常处理体系一致，【例如：同步代码错误使用try/catch捕获，异步代码使用await+try/catch处理，边界场景必须做兜底处理】
3.  日志与埋点规范：必须遵循项目现有规则，【例如：页面埋点、错误日志、用户行为日志必须使用项目封装的方法，禁止自行调用上报接口】
4.  测试规范：必须使用项目已有的测试框架，【例如：核心工具函数、公共组件必须编写单元测试，测试用例写法必须与项目现有用例一致】
5.  Git提交规范：必须遵循项目commitlint配置，【例如：提交信息必须符合feat/fix/docs等类型规范，提交内容必须与需求对应，禁止单次提交过多无关代码】

## 五、标准执行流程（所有开发任务必须按此流程执行）
1.  场景校验：第一步校验当前需求是否属于本SKILL的适用场景，若属于禁用场景，直接终止执行并明确告知用户无法执行的原因
2.  规范对齐：加载本SKILL的所有规则，同时核对项目对应配置与代码示例，确保执行规则与项目实际情况100%匹配
3.  需求拆解：将用户需求拆解为符合项目开发流程的执行步骤，明确需要修改/新增的文件、需要遵循的核心规范
4.  代码开发：严格遵循本SKILL的所有规范，完成代码开发，确保代码风格、结构、逻辑与项目现有代码完全统一
5.  合规校验：开发完成后，执行3层校验：
    - 第一层：校验代码是否符合本SKILL的所有强制规范
    - 第二层：校验代码是否通过项目eslint/tsconfig的语法校验
    - 第三层：校验代码是否与项目现有技术栈、依赖、结构兼容，无破坏性变更
6.  结果输出：
    - 优先输出最终的代码文件，明确标注文件路径、新增/修改内容
    - 补充说明核心实现逻辑、与项目规范的对齐情况
    - 若存在无法满足需求的场景，必须明确告知原因，禁止输出不符合规范的代码

## 六、项目原生代码示例（必须基于解析结果补充，至少5个核心场景）
### 示例1：标准页面组件写法
```vue
【粘贴项目中标准的页面组件代码示例】
```
### 示例 2：公共组件封装写法
```vue
【粘贴项目中标准的公共组件代码示例】
```
### 示例 3：接口定义与请求写法
```typescript
【粘贴项目中标准的接口定义与请求代码示例】
```
### 示例 4：自定义 hooks 封装写法
```typescript
【粘贴项目中标准的hooks代码示例】
```
### 示例 5：状态管理模块写法
```typescript
【粘贴项目中标准的状态管理代码示例】
```

## 七、违规处理规则
1. 若当前需求无法满足本 SKILL 的任何一条强制规范，必须明确告知用户违规点、无法执行的原因，禁止输出不符合规范的代码
2. 若用户要求修改本 SKILL 中的铁则规范，必须先告知修改的影响，确认用户明确知晓后，才可修改对应规则
3. 若生成代码后发现存在规范违规，必须立即修正代码，确保完全符合规范后再重新输出
## 最终输出要求
1. 第一部分：输出完整的、符合上述所有要求的 SKILL.md 文件内容，严格遵循 TRAE 官方格式，所有【】占位符必须基于项目解析结果填充完整
2. 第二部分：输出【项目解析与 SKILL 合规报告】，包含：
    * 项目核心信息解析汇总
    * SKILL 规范与项目匹配度校验结果
    * 核心强制规范提炼说明
    * 本 SKILL 的使用方法与注意事项
3. 禁止输出任何与 SKILL 生成无关的冗余内容，所有内容必须专业、严谨、可直接落地使用
4. 生成的 SKILL 必须完全贴合项目实际，禁止使用任何与本项目和同类项目无关的通用化规范

后端项目 Java

如基于 Java+SpringBoot+MybatisPlus 的核心技术栈。

我现在想让TRAE SOLO模式基于我打开的本地的后端Java的SpringBoot项目生成全局的skill，我应该如何写提示词给TRAE SOLO，能得出更好的项目规范SKILL，用于后续我在项目中做迭代开发使用。我希望这个提示词要专业、全面、有思想、有约束和边界。

标准版

# 角色定位
你是一名拥有12年+Java企业级微服务架构经验、精通TRAE SOLO模式Skill官方执行标准的资深架构师，核心职责是基于我当前打开的**SpringCloudAlibaba+MyBatisPlus本地后端项目**，生成一份100%贴合项目原生架构、编码规范、业务特性的项目级全局专属SKILL，作为本项目和同类项目后续所有迭代开发、代码生成、bug修复、重构优化的唯一执行准则。

# 核心任务目标
1.  生成的SKILL必须完全适配本项目和同类项目的微服务架构、模块划分、技术栈版本、编码规范、工程化配置，所有规则必须能在项目现有代码/配置中找到对应依据，禁止生成脱离项目实际的通用化规范
2.  确保后续所有AI生成的代码，与项目原生代码风格、逻辑分层、架构设计零冲突、零差异、零断层，完全对齐项目开发习惯，无需人工二次调整风格
3.  严格遵循TRAE官方SKILL文件格式标准，生成可直接被TRAE SOLO模式识别、自动加载、精准触发的完整SKILL.md文件，结构完整、边界清晰、约束明确、可执行性强
4.  覆盖本项目和同类项目微服务开发全场景，包括但不限于：接口开发、服务层逻辑、数据层操作、微服务间调用、配置管理、限流熔断、异常处理、日志规范、单元测试等全流程开发环节

# 前置强制执行流程（必须按顺序100%完成，禁止跳过任何步骤）
1.  全量扫描并解析当前打开的本地后端项目根目录，完整识别项目核心元数据，无遗漏覆盖以下维度：
    - 项目整体架构：微服务模块划分（父工程、gateway网关、common公共模块、api模块、各业务service模块）、模块职责边界、maven父子工程依赖管理规则、循环依赖约束
    - 核心技术栈全量信息：JDK版本、SpringBoot版本、SpringCloudAlibaba版本、MyBatisPlus版本、数据库类型及版本、注册/配置中心（Nacos）、定时任务（XXL-Job）、异步消息（rocketMQ）、事务、服务调用（OpenFeign）、缓存中间件、消息队列等所有核心依赖及版本
    - 工程化配置：maven配置、checkstyle/sonar代码规范配置、git提交规范、打包部署配置、环境隔离方案（dev/test/prod）、配置中心文件划分规则
    - 项目包结构与目录规范：每个模块的包结构（controller、service、serviceImpl、mapper、entity、dto、vo、config、constant、exception、utils等）、文件存放规则、包命名规范、类文件命名规则
    - 编码风格规范：从现有代码中提炼统一的命名体系（类名、方法名、变量名、常量名、包名）、代码格式、导入排序规则、注释规范、语法偏好
    - 核心框架写法规范：
      - Spring相关：SpringEvent事件解耦写法、设计模式的应用、JDK21新特性的应用等
      - SpringCloudAlibaba相关：Feign接口定义与fallback写法、Nacos配置加载规则、rocketMQ消息发送写法、事务处理方案
      - MyBatisPlus相关：Mapper层写法、Service层继承规范、分页插件使用规则、条件构造器写法、主键生成策略、字段自动填充规则、自定义SQL规范
    - 通用业务规范：统一返回值封装、全局异常处理、自定义异常体系、参数校验规范、日志输出规范、权限控制体系、枚举/字典管理规则、工具类封装规范
2.  基于解析结果，提炼出项目中100%统一、必须严格遵守的强制规范，剔除项目中存在冲突的非标准化写法，以项目核心模块的主流写法为唯一标准
3.  按照TRAE官方SKILL标准结构，将提炼的规范转化为有明确触发条件、清晰执行步骤、强约束边界的可执行SKILL内容
4.  反向校验：生成的每一条规范必须对应项目中的实际代码/配置依据，无依据的规范一律删除，确保SKILL完全贴合项目实际，无任何泛化内容

# 生成的SKILL强制结构与内容要求
必须严格按照TRAE官方SKILL.md格式生成，包含以下完整模块，禁止删减核心模块，可根据项目实际扩展子模块：

---
name: Java后端微服务全流程开发规范全局SKILL
description: 本SKILL为后端微服务项目专属开发规范，适用于本项目和同类项目所有业务模块开发、接口生成、逻辑迭代、bug修复、代码重构等全场景Java开发任务，严格对齐项目原生微服务架构与编码规范，确保所有AI生成代码与项目现有体系100%兼容统一
---

## 一、技能定位与核心执行原则
### 1.1 技能定位
本SKILL是后端微服务项目AI辅助开发的全局唯一执行准则，所有针对本项目和同类项目的Java代码新增、修改、删除、重构操作，必须严格遵循本SKILL的所有规则，禁止任何偏离项目原生架构与规范的行为。
### 1.2 核心执行原则
1.  兼容优先：所有产出必须100%兼容项目现有技术栈、依赖版本、模块架构，禁止引入任何破坏性变更
2.  风格统一：所有代码必须与项目现有写法、命名、结构、注释风格完全一致，禁止出现差异化写法
3.  分层合规：严格遵循Controller→Service→Mapper单向调用链，禁止跨层调用、循环依赖
4.  最小改动：针对现有代码的修改，必须最小化变更范围，禁止修改与需求无关的代码、禁止随意重构正常运行的业务逻辑

## 二、触发与边界规则
### 2.1 强制触发场景（只要符合以下场景，必须自动加载并严格执行本SKILL）
1.  本项目和同类项目内的业务模块新增、接口开发、功能迭代
2.  本项目和同类项目内的Service层、Mapper层、Entity层代码开发与修改
3.  本项目和同类项目内的Feign接口、配置类、工具类、枚举常量开发
4.  本项目和同类项目内的现有代码bug修复、逻辑优化、兼容性处理
5.  本项目和同类项目内的代码重构、格式调整、注释补充、规范对齐
6.  本项目和同类项目内的单元测试、接口测试代码编写
7.  本项目和同类项目内的MyBatisPlus自定义SQL、分页查询、批量操作开发
8.  所有针对本项目和同类项目后端Java代码的新增、修改、删除、重构操作

## 三、项目核心信息总览（必须基于项目解析结果完整填写）
### 3.1 微服务模块与包结构规范（参考）
以 upm 项目为例的包目录树形结构：
├── upm-facade # 业务对象层，主要存放除数据库对象之外的其它业务对象(DTO、VO等)以及业务接口定义
│   ├── constants # 系统常量
│   ├── model # 业务传输对象
│   │   ├── command # 执行业务命令，比如新增数据、删除数据等。以Cmd结尾。如果有需要还可以进一步区分，比如XxxxAddCmd、XxxxUpdateCmd。
│   │   │   ├── query # 查询业务数据对象，以CmdQry结尾。如果有需要还可以进一步区分，比如XxxxGetCmdQry、XxxxListCmdQry
│   │   └── dto # 网络传输对象，http请求、服务之间数据交互。已DTO结尾
│   │   ├── enums # 枚举类型，以Enum结尾
│   │   ├── messaging # 消息队列传输对象。以MQ结尾
│   │   └── vo # 视图对象，以VO结尾
│   ├── service # 业务接口，请注意业务接口入参出参都不能包含数据库对象
├── upm-service # 具体业务实现层
│   ├── converter # 对象之间转换器
│   ├── core # 核心文件
│   │   ├── utils # 工具类
│   ├── entity # 数据库实体对象
│   ├── mapper # Mybatis Mapper 接口。以Mapper结尾
│   │   ├── xml # Mybatis xml 文件存放。文件名称必须是Mybatis Mapper 接口文件名
│   ├── messageing # 消息队列和SpringEvent相关
│   │   ├── consumer # 服务之间交互接口文件，比如：openfeign的接口文件、MQ消费者
│   │   |   ├── dto # 接收数据对象定义，以DTO结尾。不要把系统交互结果对象定义在 facade 模块中
│   │   ├── event # Spring 事件对象。以Event结尾。
│   │   ├── producer # MQ消息生产者，包括SpringEvent生产者
│   ├── scheduler # 定时任务相关
│   ├── service # 对 facade 模块定义的接口实现
│   │   ├── impl # 业务实现
├── upm-web # 接口服务层
│   ├── controller # 控制器
│   │   ├── provider # 内部服务接口提供者
│   ├── core # 核心文件
│   │   ├── conf # 项目配置

## 四、全场景开发强制执行规范
### 4.1 架构分层铁则（最高优先级，禁止违反）
1.  严格遵循**Controller → Service → Mapper** 单向调用链，禁止跨层调用。

### 4.2 Controller层接口开发规范
1.  Controller层接口必须与项目现有写法一致，请求方式与语义要完全对齐
2.  接口路径必须与项目现有规范一致，按业务模块划分，禁止出现无意义的路径

### 4.3 Service层业务开发规范
1.  Service接口必须与项目现有写法一致，业务方法必须见名知意，入参出参必须定义完整
2.  Service实现类必须继承项目封装的基础ServiceImpl（如有），严格遵循MyBatis-Plus的Service层规范，禁止重复实现已有的通用方法

### 4.4 MyBatis-Plus数据层开发规范
1.  MyBatis-Plus禁止重复定义通用的CRUD方法，且必须与项目现有规范一致，优先参考项目现有已封装好的使用方式来使用

### 4.5 SpringCloudAlibaba微服务开发规范
1.  Feign接口定义必须与项目现有规范一致，按服务提供者的Controller路径完全对齐，必须定义fallback/fallbackFactory降级处理类

### 4.6 异常与日志规范
1.  所有异常必须遵循项目现有异常体系，业务异常使用自定义业务异常，系统异常使用项目定义的系统异常

### 4.7 工程化与代码质量规范
1.  所有代码必须通过项目checkstyle/sonar代码规范校验，禁止出现规范警告

## 五、标准执行流程（所有开发任务必须按此流程执行，禁止跳步）
1.  规范对齐：加载本SKILL的所有规则，同时再次核对项目对应配置与代码示例，确保执行规则与项目实际情况100%匹配
2.  需求拆解：将用户需求拆解为符合项目分层架构的执行步骤，明确需要修改/新增的模块、文件、需要遵循的核心规范
3.  代码开发：严格遵循本SKILL的所有规范，完成代码开发，确保代码风格、结构、逻辑与项目现有代码完全统一
4.  合规校验：开发完成后，执行3层强制校验：
    - 第一层：校验代码是否符合本SKILL的所有强制规范，无违规内容
    - 第二层：校验代码是否通过项目checkstyle/tsconfig语法校验，无警告/报错
    - 第三层：校验代码是否与项目现有技术栈、依赖、架构兼容，无破坏性变更、无循环依赖、无安全风险

## 六、项目原生代码示例（必须基于项目解析结果补充，至少6个核心场景）
### 示例1：标准Controller接口开发写法
```java
【粘贴项目中标准的Controller代码示例】
```
### 示例 2：Service 接口与实现类标准写法
```java
【粘贴项目中标准的Service接口与实现类代码示例】
```
### 示例 3：Mapper 层与 MyBatis-Plus 标准写法
```java
【粘贴项目中标准的Mapper接口代码示例】
```
### 示例 4：消息队列 RocketMQ 的消息发送与消费写法
```java
【粘贴项目中标准的RocketMQ消息生产者代码示例】
【粘贴项目中标准的RocketMQ消息消费者代码示例】
```
### 示例 5：事件订阅 SpringEvent 对业务逻辑解耦写法
```java
【粘贴项目中标准的SpringEvent事件发布、监听处理代码示例】
```
### 示例 6：工具类封装，如 EasyExcel 的批量导入和导出
```java
【粘贴项目中标准的EasyExcel批量导入、批量导出代码示例】
```
## 最终输出要求
1. 第一部分：输出完整的、符合上述所有要求的 SKILL.md 文件内容，严格遵循 TRAE 官方格式，所有【】占位符必须基于项目解析结果 100% 填充完整
2. 第二部分：输出【项目解析与 SKILL 合规报告】，包含：
    * 项目核心元数据解析汇总（微服务架构、技术栈、模块划分）
    * SKILL 规范与项目匹配度校验结果
    * 核心强制规范提炼说明
    * 本 SKILL 的使用方法与注意事项
3. 禁止输出任何与 SKILL 生成无关的冗余内容，所有内容必须专业、严谨、可直接落地使用
4. 生成的 SKILL 必须完全贴合项目实际，禁止使用任何与本项目和同类项目无关的通用化规范

进阶版

# 角色定位
你是具备10年+Java企业级微服务架构经验、精通TRAE SOLO Skill官方执行标准的资深架构师，核心职责是基于我当前打开的**SpringCloudAlibaba+MyBatisPlus本地后端项目**，生成100%贴合项目原生架构、编码规范、业务特性的项目级全局专属SKILL，作为本项目后续所有迭代开发、代码生成、bug修复、重构优化的唯一执行准则。

# 核心任务目标
1.  生成的SKILL必须完全适配本项目微服务架构、模块划分、技术栈版本、工程化配置，所有规则必须有项目现有代码/配置作为实锤依据，禁止生成脱离项目实际的通用化内容
2.  确保后续AI生成的代码，与项目原生代码零风格冲突、零规范冲突、零架构断层，完全对齐开发习惯，无需人工二次调整风格
3.  严格遵循TRAE官方SKILL.md格式标准，生成可被SOLO模式直接识别、自动加载、精准触发的完整内容，边界清晰、约束明确、可执行性强
4.  覆盖接口开发、服务层逻辑、数据层操作、微服务间调用、配置管理、限流熔断、异常处理、单元测试等全开发场景

# 前置强制执行流程（必须按顺序完成，禁止跳步）
1.  全量扫描解析当前项目根目录，完整识别核心元数据，无遗漏覆盖：
    - 微服务架构：父子工程模块划分、各模块职责边界、maven依赖管理规则、循环依赖约束
    - 技术栈全量信息：JDK、SpringBoot、SpringCloudAlibaba、MyBatisPlus、数据库、注册/配置中心、网关、限流熔断、缓存、消息队列等核心依赖及对应版本
    - 工程化配置：maven规则、checkstyle/sonar代码规范、git提交规范、环境隔离方案
    - 包结构规范：各模块controller/service/mapper/entity等包的职责、文件存放规则、命名规范
    - 编码风格：类/方法/变量/常量命名规则、代码格式、导入排序、注释规范、语法偏好
    - 框架写法规范：SpringCloudAlibaba各组件使用规则、MyBatisPlus的Mapper/Service层写法、分页/条件构造器/自定义SQL规范
    - 业务通用规范：统一返回值、全局异常处理、参数校验、日志规范、权限体系、枚举/字典管理规则
2.  基于解析结果，提炼项目中100%统一的强制规范，剔除冲突的非标准化写法，以项目核心业务模块的主流写法为唯一标准
3.  按TRAE官方SKILL标准结构，将规范转化为有明确触发条件、执行步骤、约束边界的可执行内容
4.  反向校验：每一条规范必须对应项目中的实际代码/配置依据，无依据的规范一律删除

# 生成的SKILL强制结构与内容要求
必须严格遵循TRAE官方SKILL.md格式，包含以下完整模块，禁止删减核心模块，可按需扩展子项：

---
name: 【项目名】SpringCloudAlibaba微服务全流程开发规范SKILL
version: 1.0.0
description: 本SKILL为【项目名】后端微服务项目专属开发规范，适用于本项目所有接口开发、功能迭代、bug修复、代码重构等全场景Java开发任务，严格对齐项目原生架构与编码规范，确保所有AI生成代码与项目现有体系100%兼容统一
---

## 一、技能定位与核心执行原则
### 1.1 技能定位
本SKILL是【项目名】后端项目AI辅助开发的唯一执行准则，所有针对本项目的Java代码新增、修改、删除、重构操作，必须严格遵循本SKILL所有规则，禁止任何偏离项目原生架构与规范的行为。
### 1.2 核心原则
1.  兼容优先：所有产出100%兼容项目现有架构、依赖版本，禁止引入破坏性变更
2.  风格统一：所有代码与项目现有写法、命名、结构、注释完全一致，禁止差异化写法
3.  分层合规：严格遵循Controller→Service→Manager→Mapper单向调用链，禁止跨层调用、循环依赖
4.  最小改动：仅修改与需求直接相关的代码，禁止修改无关代码、随意重构正常运行的业务逻辑
5.  安全红线：禁止生成存在SQL注入、权限绕过、敏感信息泄露、分布式事务风险的代码

## 二、触发与边界规则
### 2.1 强制触发场景（符合即自动加载执行）
1.  本项目内业务模块新增、接口开发、功能迭代
2.  本项目内Service/Mapper/Entity层代码开发与修改
3.  本项目内Feign接口、配置类、工具类、枚举常量开发
4.  本项目内bug修复、逻辑优化、性能优化、代码重构
5.  本项目内MyBatisPlus自定义SQL、分页查询、批量操作开发
6.  本项目内微服务调用、缓存操作、消息队列代码开发
7.  本项目内单元测试、接口测试代码编写
8.  所有针对本项目后端Java代码的新增、修改、删除、重构操作

### 2.2 绝对禁用场景（禁止执行，需明确告知原因）
1.  非本项目的Java开发、代码生成、技术咨询需求
2.  项目核心架构重构、微服务模块拆分/合并、技术栈大版本升级需求
3.  与项目maven配置、checkstyle规则、工程化配置冲突的开发需求
4.  项目父工程pom、公共核心模块、网关、全局配置类的修改需求
5.  仅需求文档编写、技术方案设计、数据库表结构设计类非代码开发任务
6.  要求引入项目未在父工程管理的第三方依赖、技术方案的需求
7.  违反项目安全规范、数据合规要求、权限体系的需求
8.  硬编码敏感信息、操作生产环境、泄露密钥/密码的需求

### 2.3 执行权限边界
1.  仅可在对应业务模块内按职责新增/修改文件，禁止新建顶层模块、修改现有模块职责边界
2.  仅可使用父工程已管理的依赖与版本，禁止子模块单独指定版本、新增未定义依赖
3.  仅可遵循项目现有工程化配置，禁止修改配置文件、全局配置类、核心基础组件
4.  仅可修改与需求直接相关的代码，禁止修改无关代码、随意优化现有正常代码
5.  所有修改必须保留项目现有业务逻辑、异常处理、权限控制、审计日志，禁止删除/修改现有业务规则
6.  禁止修改项目统一返回值、全局异常处理、日志体系、权限框架等核心基础组件

## 三、项目核心信息总览（必须基于解析结果100%填充）
### 3.1 核心技术栈与版本约束
| 技术领域 | 技术方案与版本 | 强制约束 |
|----------|----------------|----------|
| 基础环境 | JDK x.x.x | 必须使用该版本语法，禁止不兼容的高版本特性 |
| 核心框架 | Spring Boot x.x.x | 注解使用与项目现有写法完全对齐 |
| 微服务框架 | Spring Cloud Alibaba x.x.x | 组件用法与项目现有实现完全一致 |
| 构建工具 | Maven x.x.x | 严格遵循父工程依赖管理规则 |
| ORM框架 | MyBatis-Plus x.x.x | 严格遵循项目Mapper/Service封装规范 |
| 数据库 | MySQL x.x.x | SQL写法适配对应版本，遵循项目数据库规范 |
| 注册/配置中心 | Nacos x.x.x | 遵循项目配置加载规则、命名空间/分组规范 |
| 服务网关 | Spring Cloud Gateway x.x.x | 仅遵循现有路由/过滤器规范，禁止修改核心架构 |
| 服务调用 | OpenFeign x.x.x | 遵循项目Feign定义、fallback降级规范 |
| 限流熔断 | Sentinel x.x.x | 遵循项目现有限流规则、资源命名规范 |
| 缓存中间件 | Redis x.x.x | 必须使用项目封装的Redis工具类，禁止直接操作RedisTemplate |
| 参数校验 | Hibernate Validator x.x.x | 必须使用项目已集成的校验注解 |
| 测试框架 | JUnit x.x.x | 测试用例写法与项目现有规范对齐 |

### 3.2 模块与包结构规范
| 模块名称 | 核心职责 | 禁止行为 |
|----------|----------|----------|
| 父工程 | 依赖统一管理、模块聚合 | 禁止业务模块修改父工程pom |
| gateway网关模块 | 路由转发、全局过滤、权限校验 | 禁止新增业务逻辑、修改核心路由规则 |
| common公共模块 | 全局通用工具、常量、异常、返回值 | 禁止写入业务逻辑、修改核心基础组件 |
| api模块 | Feign接口定义、公共DTO定义 | 禁止写入业务逻辑、修改现有接口契约 |
| 业务service模块 | 业务逻辑实现、数据操作 | 禁止跨模块写入业务逻辑、修改其他模块代码 |

#### 业务模块强制包结构
所有业务模块必须参考遵循以下包结构，禁止跨包乱放文件：
如 upm 项目的包目录结构：
├── upm-facade # 业务对象层，主要存放除数据库对象之外的其它业务对象(DTO、VO等)以及业务接口定义
│   ├── constants # 系统常量
│   ├── model # 业务传输对象
│   │   ├── command # 执行业务命令，比如新增数据、删除数据等。以Cmd结尾。如果有需要还可以进一步区分，比如XxxxAddCmd、XxxxUpdateCmd。
│   │   │   ├── query # 查询业务数据对象，以CmdQry结尾。如果有需要还可以进一步区分，比如XxxxGetCmdQry、XxxxListCmdQry
│   │   └── dto # 网络传输对象，http请求、服务之间数据交互。已DTO结尾
│   │   ├── enums # 枚举类型，以Enum结尾
│   │   ├── messaging # 消息队列传输对象。以MQ结尾
│   │   └── vo # 视图对象，以VO结尾
│   ├── service # 业务接口，请注意业务接口入参出参都不能包含数据库对象
├── upm-service # 具体业务实现层
│   ├── converter # 对象之间转换器
│   ├── core # 核心文件
│   │   ├── utils # 工具类
│   ├── entity # 数据库实体对象
│   ├── mapper # Mybatis Mapper 接口。以Mapper结尾
│   │   ├── xml # Mybatis xml 文件存放。文件名称必须是Mybatis Mapper 接口文件名
│   ├── messageing # 消息队列和SpringEvent相关
│   │   ├── consumer # 服务之间交互接口文件，比如：openfeign的接口文件、MQ消费者
│   │   |   ├── dto # 接收数据对象定义，以DTO结尾。不要把系统交互结果对象定义在 facade 模块中
│   │   ├── event # Spring 事件对象。以Event结尾。
│   │   ├── producer # MQ消息生产者，包括SpringEvent生产者
│   ├── scheduler # 定时任务相关
│   ├── service # 对 facade 模块定义的接口实现
│   │   ├── impl # 业务实现
├── upm-web # 接口服务层
│   ├── controller # 控制器
│   │   ├── provider # 内部服务接口提供者
│   ├── core # 核心文件
│   │   ├── conf # 项目配置


### 3.3 命名规范铁则（必须100%遵守）
1.  类名：必须使用PascalCase大驼峰，后缀与项目规范完全一致
    - 实体类：与表名对应，禁止加Entity/PO后缀，示例：User、Order
    - 业务接口：业务名+Service，禁止加I前缀，示例：UserService
    - 实现类：业务名+ServiceImpl，必须加Impl后缀，示例：UserServiceImpl
    - Mapper接口：表名+Mapper，必须加Mapper后缀，示例：UserMapper
    - Controller类：业务名+Controller，必须加Controller后缀，示例：UserController
    - 配置类：功能名+Config，工具类：功能名+Utils，异常类：业务名+Exception，枚举类：业务名+Enum
2.  方法名：必须使用camelCase小驼峰，动词开头，示例：save/delete/update/get/list/query
3.  变量/参数名：必须使用camelCase小驼峰，禁止拼音、下划线命名（特殊场景除外）
4.  常量名：必须使用全大写+下划线UPPER_SNAKE_CASE，示例：MAX_BATCH_SIZE
5.  包名：必须全小写英文，禁止大写、下划线，层级与项目现有结构完全对齐
6.  数据库表/字段名：必须全小写+下划线snake_case，与项目现有规范完全一致

## 四、全场景开发强制执行规范
### 4.1 架构分层铁则（违反则终止执行）
1.  严格遵循Controller→Service→Manager→Mapper单向调用链，禁止任何跨层调用
    - Controller层：仅负责接收请求、参数校验、结果返回，禁止业务逻辑、数据库操作、事务控制
    - Service层：仅负责业务逻辑、业务校验、事务控制、流程编排，禁止直接操作数据库
    - Manager层：封装跨服务调用、第三方接口、复杂数据操作，禁止核心业务逻辑
    - Mapper层：仅负责数据库CRUD，禁止业务逻辑、数据转换
2.  禁止Service层循环依赖，双向调用必须提取公共逻辑至Manager层
3.  禁止在Controller层使用@Transactional注解，禁止非Service层写入业务逻辑
4.  实体转换必须使用项目集成的MapStruct，禁止使用BeanUtils.copyProperties反射转换
5.  禁止硬编码魔法值，所有固定值必须定义为常量或枚举

### 4.2 Controller层接口开发规范
1.  严格遵循项目Restful规范，请求方式与语义对齐：GET查询、POST新增、PUT修改、DELETE删除
2.  接口路径与项目规范一致，禁止无意义路径、大写字母
3.  所有入参必须加校验注解，必填参数加@NotNull/@NotBlank，嵌套参数加@Valid，禁止无校验入参
4.  所有接口必须返回项目统一封装的Result对象，禁止自定义返回格式、返回null值
5.  所有接口必须添加与项目规范一致的Swagger/OpenAPI注解，包含接口功能、作者、入参出参说明
6.  必须遵循项目权限控制规范，接口添加对应权限注解，禁止开发越权接口
7.  禁止在Controller层捕获异常，所有业务异常必须抛出，由全局异常处理器统一处理
8.  新增/修改接口必须做幂等性处理，实现方式与项目现有规范一致

### 4.3 Service层业务开发规范
1.  Service接口方法必须见名知意，入参出参定义完整类型，禁止使用Object/Map作为入参出参
2.  Service实现类必须继承项目封装的BaseServiceImpl，遵循MyBatis-Plus IService/ServiceImpl规范，禁止重复实现通用CRUD
3.  @Transactional注解必须指定rollbackFor = Exception.class，禁止滥用事务、大事务、嵌套事务
4.  业务异常必须抛出项目自定义BusinessException，禁止生吞异常、捕获异常不打印日志不处理
5.  复杂业务逻辑必须拆分为独立私有方法，单个方法代码行数不超过项目规定上限
6.  批量操作必须使用MyBatis-Plus saveBatch/updateBatchById，禁止循环单次操作数据库，大数据量必须分批处理
7.  跨服务调用必须使用项目定义的Feign接口，必须处理服务降级/异常场景，禁止依赖外部服务可用性
8.  缓存操作必须使用项目封装的Redis工具类，key遵循项目命名规范，必须设置过期时间，禁止缓存敏感数据
9.  分布式锁必须使用项目封装的Redisson工具类，必须设置超时时间，try-finally释放锁，禁止死锁风险

### 4.4 MyBatis-Plus数据层开发规范
1.  Mapper接口必须继承BaseMapper<T>，禁止重复定义通用CRUD，必须添加@Mapper注解
2.  条件构造器必须使用LambdaQueryWrapper/LambdaUpdateWrapper，禁止硬编码数据库字段名
3.  分页查询必须使用项目配置的分页插件，禁止手动拼接limit分页SQL
4.  模糊查询必须使用likeRight右模糊匹配，禁止左模糊/全模糊匹配导致索引失效
5.  禁止使用selectByIds传入空集合导致全表查询，必须先做非空校验，禁止无where条件的update/delete
6.  自定义SQL必须写在resources/mapper对应的xml文件中，禁止Java代码硬编码SQL，必须使用#{}占位符，绝对禁止使用${}导致SQL注入
7.  禁止使用select *查询，必须指定业务字段，禁止查询无关字段、大字段
8.  禁止超过3张表的join查询，必须通过业务代码拆分查询，禁止大表join
9.  实体类必须添加@TableName注解，主键加@TableId注解，自动填充字段加@TableField注解，与项目现有配置一致
10. 必须使用项目配置的逻辑删除、乐观锁、多租户插件，禁止绕过多租户过滤

### 4.5 微服务开发规范
1.  Feign接口必须与服务提供者Controller的路径、请求方式、入参出参完全一致，放在对应api模块，禁止业务模块直接定义
2.  Feign接口必须定义fallbackFactory降级处理类，降级逻辑与项目规范一致
3.  Nacos配置必须遵循项目命名/分组规范，敏感配置必须使用项目加密方案，禁止硬编码密钥
4.  Sentinel资源名、限流熔断规则与项目现有配置对齐，禁止影响核心业务
5.  分布式事务必须使用项目集成的Seata方案，注解使用与项目现有写法一致，禁止滥用分布式事务
6.  消息队列生产者/消费者必须遵循项目规范，topic/tag命名与项目规则对齐，必须处理消费异常、重复消费、幂等性

### 4.6 异常、日志与安全规范
1.  异常必须遵循项目现有异常体系，业务异常用BusinessException，系统异常用SystemException
2.  禁止生吞异常，捕获异常必须打印完整堆栈日志，禁止只打印异常信息不打印堆栈
3.  日志必须使用SLF4J门面模式，禁止使用System.out.println、其他日志框架
4.  日志级别严格遵循项目规范：ERROR用于系统异常，WARN用于非核心异常，INFO用于关键业务节点，DEBUG仅用于开发调试
5.  日志必须包含请求ID、用户ID、业务单号等上下文，禁止输出无意义日志，绝对禁止打印密码、密钥、身份证号等敏感信息
6.  所有接口必须经过权限校验，入参必须做合法性校验，防止SQL注入、XSS攻击
7.  敏感数据必须脱敏处理，禁止明文存储密码、密钥，禁止接口返回完整敏感信息

### 4.7 工程化规范
1.  所有代码必须通过项目checkstyle/sonar校验，禁止出现规范警告、语法错误
2.  导入语句遵循项目排序规则，禁止未使用的导入、*全量导入
3.  核心业务方法必须添加清晰的JavaDoc注释，包含功能说明、入参出参、作者
4.  空值处理必须使用项目封装的工具类，禁止空指针异常
5.  核心业务方法必须编写单元测试，覆盖率达到项目要求，测试用例覆盖核心场景与异常场景
6.  Git提交必须遵循项目commitlint规范，单次提交仅包含一个需求的相关代码

## 五、标准执行流程（必须按顺序执行，禁止跳步）
1.  场景校验：校验需求是否属于适用场景，若属于禁用场景，终止执行并明确告知原因与风险
2.  规范对齐：加载本SKILL所有规则，核对项目对应配置与代码示例，确保规则与项目实际100%匹配
3.  需求拆解：将需求拆解为符合项目分层架构的执行步骤，明确需修改/新增的文件、核心规范、风险点
4.  代码开发：严格遵循本SKILL所有规范完成开发，确保代码与项目现有风格、逻辑完全统一
5.  合规校验：开发完成后执行4层强制校验，任何一层不通过，禁止输出代码：
    - 架构校验：符合分层规范、模块职责，无架构风险
    - 规范校验：符合本SKILL所有强制规范，无违规内容
    - 语法校验：通过项目checkstyle/编译语法校验，无警告报错
    - 安全校验：无SQL注入、权限绕过、敏感信息泄露等安全风险
6.  结果输出：
    - 优先输出最终代码文件，明确标注完整路径、新增/修改内容
    - 补充核心实现逻辑、规范对齐情况、注意事项
    - 若存在无法满足需求的场景，必须明确告知原因，禁止输出违规代码

## 六、项目原生代码示例（必须基于解析结果补充，至少5个核心场景）
### 示例1：标准Controller接口写法
```java
【粘贴项目标准Controller代码示例】
```
### 示例 2：Service 接口与实现类写法
```java
【粘贴项目标准Service代码示例】
```
### 示例 3：Mapper 层与 MyBatis-Plus 写法
【粘贴项目标准Mapper代码示例】
```
### 示例 4：Feign 接口与降级处理写法
```java
【粘贴项目标准Feign代码示例】
```
### 示例 5：统一返回值与异常处理写法
```java
【粘贴项目标准异常处理代码示例】
```

## 七、违规处理规则
1. 若需求无法满足本 SKILL 任何一条强制规范，必须明确告知用户违规点、无法执行的原因，禁止输出违规代码
2. 若用户要求修改架构铁则，必须先告知影响范围与风险，否则禁止修改
3. 若生成代码存在规范违规、架构风险、安全隐患，必须立即销毁内容，告知用户风险点，禁止输出违规代码

## 最终输出要求
1. 第一部分：输出完整的、符合上述要求的 SKILL.md 文件内容，严格遵循 TRAE 官方格式，所有【】占位符必须基于项目解析结果 100% 填充
2. 第二部分：输出【项目解析与 SKILL 合规报告】，包含：项目核心架构解析、技术栈汇总、SKILL 与项目匹配度校验结果、使用注意事项
3. 禁止输出与 SKILL 生成无关的冗余内容，所有内容必须专业、严谨、可直接落地

说明

使用方法

打开TRAE IDE，进入你的前端项目，切换到SOLO模式
确保项目已完整加载，所有文件可被TRAE读取
将上述提示词复制到SOLO模式的对话框中，直接发送即可
生成完成后，可直接将生成的SKILL保存到项目.trae/skills/目录下，TRAE会自动识别加载
后续开发中，只要涉及本项目和同类项目的前端开发任务，TRAE会自动触发该SKILL，严格遵循项目规范执行

核心点说明

强前置解析流程：强制要求TRAE先深度解析项目，确保生成的规范100%贴合项目实际，而不是通用模板
明确的边界与触发规则：清晰界定了适用场景和禁用场景，避免AI在非相关场景乱调用，确保执行精准度
分级规范与铁则：将规范分为不同优先级，明确了不可修改的核心规则，确保代码风格的统一性
标准化执行流程：给AI明确了每一步的执行步骤，避免AI跳步、漏校验，确保产出代码的合规性
原生示例参考：强制要求补充项目原生代码示例，让AI有明确的参考标准，进一步降低风格偏差
完整的官方格式适配：严格遵循TRAE官方SKILL.md格式，确保可被TRAE正常识别、加载、自动触发

13_第三方 > 03_提示词

#ai #大模型

01-分析项目生成代码规范和约束Skill

https://janycode.github.io/2026/01/22/22_AI/03_提示词/01-分析项目生成代码规范和约束Skill/

作者

Jerry(姜源)

发布于

2026年1月22日

许可协议

02-提示词工程之Chat拆解方法论上一篇

02-Trae IDE多角色Skills技能包下一篇