Merge branch 'dev' into debug

Author: BppleMan

.github/git-commit-instructions.md

@@ -1,88 +1,178 @@
-# Git 提交信息生成指南
+# Git 提交信息（AI 生成）规范
 
-## 基本要求
+> 本说明用于约束 **AI 自动生成 Git 提交信息** 的格式和内容。 注意：**输出只能是提交信息本身，不要解释，不要包裹代码块。**
 
-- 使用简洁明了的中文生成 commit message
-- 每行不超过 50 个字符，保证在各种 Git 工具中良好显示
-- 使用动词开头，描述本次提交**做了什么**而不是**做什么**
+---
 
-## 提交类型分类
+## 1. 总体要求
 
-按照以下类型对提交内容进行分类，使用标准格式：`<类型>: <描述>`
+1. 使用 **简洁明了的中文** 描述提交内容。
+2. 使用 **动词开头**，描述本次提交「做了什么」。
+3. 每一行不超过 **50 个汉字/字符**，尽量控制在 20–30 字内。
+4. 关注业务价值和用户影响，而不是具体实现细节。
+5. 输入可能是 diff、变更列表或自然语言描述，输出始终是 **规范化的提交信息行**。
 
-**重要**：类型标签必须用尖括号包围，例如 `<feat>:`、`<fix>:`、`<update>:` 等。
+---
 
-### 优先级排序（高到低）
+## 2. 输出格式（必须遵守）
 
-1. **fix**: 修复 bug 或问题
-2. **feat**: 新增功能或特性
-3. **refactor**: 重构代码（不改变功能）
-4. **update**: 更新依赖、配置或现有功能
-5. **docs**: 文档相关修改
-6. **style**: 代码格式、样式调整
-7. **test**: 测试相关修改
-8. **chore**: 构建工具、辅助工具等修改
+### 2.1 统一格式
 
-## 格式规范
+无论是「单一类型」还是「多类型」提交，**输出格式完全一致**：
 
-### 单一类型提交
+- 每一行代表一种类型的总结
+- 每一行的格式必须为：
 
+```text
+<类型>: 简要描述
 ```
-<类型> <简洁描述>
-```
 
-### 多类型提交
+- **不要** 输出总标题或概括性第一行
+- **不要** 输出空行
+- **不要** 添加解释性文字、前后说明或代码块
+- **不要** 在类型前后省略尖括号或冒号
+
+### 2.2 单一类型提交
 
-当一次提交包含多种类型的修改时，使用以下格式：
+- 只有一种主要修改类型时，只输出 **一行**：
 
+```text
+<feat>: 添加用户认证功能
 ```
-高度概括的标题
 
-<类型1> <修改描述1>
-<类型2> <修改描述2>
-<类型3> <修改描述3>
+### 2.3 多类型提交
+
+- 同一次提交包含多种类型修改时：
+    - 每种类型一行
+    - 按类型优先级从高到低排序（见下一节）
+    - 所有行都是：`<类型>: 描述`
+    - 不要添加额外标题或空行
+
+示例：
+
+```text
+<fix>: 修复订单支付金额计算错误
+<update>: 调整优惠券校验逻辑
+<docs>: 补充支付流程说明文档
 ```
 
-**格式要求**：
+---
+
+## 3. 类型与优先级
+
+按优先级从高到低排序（用于多类型时的行顺序）：
+
+1. `fix` —— 修复 bug 或问题
+2. `feat` —— 新增功能或特性
+3. `refactor` —— 重构代码但不改变对外行为
+4. `update` —— 更新依赖、配置或现有功能行为
+5. `docs` —— 文档相关修改
+6. `style` —— 代码格式、样式调整（无逻辑变化）
+7. `test` —— 测试相关调整或新增
+8. `chore` —— 构建、脚本、工具链等辅助改动
+
+> **重要：** 类型标签必须用 **尖括号包裹**，并且后面紧跟冒号。
+>
+> 例如：`<fix>:`、`<feat>:`、`<update>:`。
+
+---
+
+## 4. 写作规则
+
+1. **动词开头**：
+
+- ✅ `修复`、`优化`、`添加`、`调整`、`更新`、`补充` 等
+- ❌ 避免名词开头的模糊表达，如 `登录问题`、`代码调整` 等
+
+2. **现在时 + 主动语态**：
+
+- ✅ `修复登录页面响应异常`
+- ❌ `已修复登录页面响应异常`
+- ❌ `将修复登录页面响应异常`
+
+3. **避免技术细节和文件名堆砌**：
 
-- 第一行：简洁的总体标题，概括本次提交的主要目的
-- 空一行
-- 后续行：每行都以尖括号包围的类型标签开头，按优先级从高到低排列
-- 类型标签必须用尖括号包围，例如 `<feat>`、`<fix>`、`<update>` 等
+- 不要罗列具体文件名、类名、函数名
+- 如必须提到技术词汇，保持简短且与业务直接相关
 
-## 注意事项
+4. **关注业务和用户影响**：
 
-- ❌ 不要罗列具体文件名
-- ❌ 不要使用过于技术化的术语
-- ✅ 专注于修改的**业务价值**和**用户影响**
-- ✅ 使用主动语态和现在时态
-- ✅ 多类型提交时，总体标题应该高度概括整次提交的核心目标
-- ✅ 详细描述部分用尖括号标签分类说明具体修改内容
+- ✅ `修复支付失败导致订单状态异常`
+- ✅ `优化列表加载，提升页面响应速度`
+- ❌ `重命名 user_helper.ts 和 order_util.ts`
 
-## 示例
+5. **多类型时的归类原则**：
 
-**好的提交信息：**
+- 优先判断是否存在 bug 修复，若有则必须包含 `<fix>` 行
+- 新增对外可感知功能使用 `<feat>`
+- 不改变行为但整理结构时用 `<refactor>`
+- 修改配置、依赖或已有功能行为偏「调整」用 `<update>`
+- 仅文档改动用 `<docs>`
+- 仅格式、空格、缩进等无逻辑变化用 `<style>`
+- 仅测试相关用 `<test>`
+- 构建脚本、CI、工具等用 `<chore>`
 
-单一类型：
+6. **输出语言**：
 
-- `<feat> 添加用户认证功能`
-- `<fix> 修复登录页面响应异常`
-- `<refactor> 优化数据库查询性能`
+    - 无论输入语言是什么，输出一律使用 **中文**。
 
-多类型：
+---
 
+## 5. 示例
+
+### 5.1 单一类型示例
+
+```text
+<feat>: 添加用户注册邮箱验证
+<fix>: 修复登录态过期后无法自动跳转
+<refactor>: 优化订单聚合服务结构
+<update>: 更新支付网关超时时间配置
+<docs>: 补充部署环境变量说明
+<style>: 统一表单组件代码格式
+<test>: 增加支付流程回归测试用例
+<chore>: 调整打包脚本提升构建速度
+```
+
+### 5.2 多类型示例
+
+示例一：
+
+```text
+<fix>: 修复优惠券折扣计算不正确
+<update>: 调整订单结算税费规则
+<docs>: 更新优惠使用说明文档
+```
+
+示例二：
+
+```text
+<feat>: 添加用户导出报表功能
+<refactor>: 拆分报表生成模块结构
+<test>: 增加报表导出边界用例
 ```
-完善Redis部署和访问配置
 
-<feat> 添加Redis外部访问功能
-<update> 修改Redis服务类型为NodePort
-<docs> 添加Redis连接指南和网络分析文档
+示例三：
+
+```text
+<update>: 升级数据库驱动版本
+<chore>: 调整CI脚本以兼容新驱动
 ```
 
-**不好的提交信息：**
+---
+
+## 6. 生成策略建议（面向 AI）
+
+1. 先从输入内容中识别所有涉及的类型：bug 修复、新功能、重构、配置更新、文档、样式、测试、构建脚本等。
+2. 为每个实际涉及的类型生成一句总结，遵循：
+
+- 动词开头
+- 业务导向
+- 不超过 50 字
+
+3. 将这些类型按优先级排序后输出为多行：
+
+- 排序顺序：`fix > feat > refactor > update > docs > style > test > chore`
+
+4. 若只识别出一种类型，只输出一行。
+5. 严格使用格式：`<类型>: 描述`，不添加任何其他文本、标题、空行或代码块。
 
-- `更新了 auth.js 和 login.vue`
-- `修改`
-- `完成开发任务`
-- `feat: 主要功能` （没有使用尖括号包围类型标签）
-- 缺少总体标题的多类型提交