AI驱动的业务开发新范式：将Skills引入工程化实践

引言

仔细审视我们的工作内容不难发现，其中相当一部分其实是高度重复的。这也是为什么不少程序员会自嘲为 CRUD Boy------某种程度上，这是对工作重复性的精准概括。

以我个人的开发流程为例，大致遵循以下步骤：

需求分析：基于业务需求，结合现有系统设计实现方案
方案评估：评估影响范围，需要新增哪些表、修改哪些表
基础代码实现：CRUD、基础 Service、RPC 接口、Web 接口
复杂业务实现：在业务 Service 中编排基础能力，完成业务逻辑
测试阶段：测试、修复 Bug
上线流程：打包、Code Review、提交 MR、合并主干

不同职业的重复形态各不相同。相比需要直面高度不确定现实世界的职业，程序员相对"幸运"的一点在于：我们的工作大多发生在一个极度强调确定性的工程环境中。这也使得我们可以用工程化手段，去系统性地解决重复问题。

从 2023 年开始，我逐步尝试借助 AI 去覆盖这些流程中的重复环节，例如：

基于 CRUD 模板自动生成代码
根据自然语言生成 DLL / 模块模板
在项目中沉淀结构化文档供 AI 使用
通过自定义command、mcp写周报、输出文档

这些实践已经在很大程度上提升了效率，也减少了日常开发中的重复劳动。

但与此同时，我也在持续思考：这件事，是否还能再往前走一步？

如果继续往前思考一个问题：
当 AI 不只是帮我们"写一段代码"，而是能够理解一类工作，并稳定复用这种能力，会发生什么？

过去两年，AI 更多承担的是"增强工具"的角色------帮我们生成代码、补全函数、写文档、写 SQL，本质上仍然是一次性辅助。

但如果换一个视角：

我们是否可以把这些已经验证有效的能力，沉淀为可复用的能力模块？

不是每次重新写 Prompt，而是把经验、流程、规则、上下文，封装成一个可以长期复用的能力单元。

这也正是我开始关注 Skill/能力模块化 的原因。不了解Skill的同学可以移步我之前写过的两篇文章：
Claude Skills是什么？为什么要引入Skills？
从0到1打造Skill：完整实战指南

相比单次 Prompt，Skill 更像是对"经验"的工程化沉淀：

把最佳实践固化下来
把复杂上下文结构化
把一次次试错结果转化为稳定能力

如果说过去我们是在用 AI减少重复劳动 ，那么接下来更值得尝试的是：
让AI帮我们消灭一整类重复劳动。

Let's begin！

在AI辅助开发的语境下，Skill就是一个包含了领域知识、最佳实践、代码模板的知识包。

以"DAO层CRUD生成"为例，一个Skill包含：

markdown 复制代码

/mnt/skills/dao-crud/
├── SKILL.md              # 使用说明
│   ├── 何时使用这个Skill
│   ├── 输入格式（表结构DDL）
│   ├── 输出内容（Mapper、Entity、测试）
│   └── 最佳实践（索引建议、命名规范）
├── templates/            # 代码模板
│   ├── mapper.xml.template
│   ├── entity.java.template
│   └── test.java.template
├── examples/             # 示例
│   ├── user-crud-example/
│   └── order-crud-example/
└── scripts/                # 脚本
    ├── script_1.py
    └── script_2.py

我们将Skills设计为多层体系：

markdown 复制代码

┌─────────────────────────────────────┐
│      Rules 层（规范与约束）          │
│  - 技术栈选型                        │
│  - 代码规范                          │ │
└─────────────────────────────────────┘
↓ 指导
┌─────────────────────────────────────┐
│      Skills 层（能力模块）             │
│   - 工具类、oss Skill                 │
│  - DAO CRUD Skill                    │ 
│  - 消息队列 Skill                     │
│  - 基础Service Skill                 │
│  - 领域服务库（用户、订单、支付...）Skill │
└─────────────────────────────────────┘
↓ 组合
┌─────────────────────────────────────┐
│      Workflow 层（流程自动化）        │
│  - Git代码审查、生成commit Skill      │
│  - CI/CD配置 Skill                  │
│  - 文档生成 Skill│
└─────────────────────────────────────┘

我觉得Rules层也可以做成skill，将其做成skill会有什么好处呢？我还没想清楚，暂时就先按照rules来定义吧。

Rules 层（规范与约束）

在AI编码中，**rules（规则）**是一种重要的机制，用于指导AI如何编写代码。让我解释一下它们的作用和为什么要引用它们：

Rules的主要作用

统一代码规范
Rules定义了编码标准和最佳实践，确保AI生成的代码风格一致、符合项目约定。比如命名规范、缩进风格、文件组织等。
领域知识注入
通过rules可以向AI传达特定框架、库或技术栈的使用方式。例如React的组件编写规范、数据库查询的安全实践等。
避免常见错误
Rules可以明确禁止某些危险或不推荐的做法，比如SQL注入风险、内存泄漏模式、性能反模式等。
项目特定约束
每个项目都有独特需求，rules让你能定义项目特有的架构决策、依赖使用限制、业务逻辑规则等。

在实践中，我们推荐分类定义rules，对于后端来说，可以从以下角度定义：

项目所使用的技术栈
API设计
数据库表结构设计原则、规范
代码架构、代码规范
代码规范
...
其他rules

这种分类方式让整个规则体系模块化、可扩展、易管理，就像代码本身一样遵循"关注点分离"的原则。你可以把它想象成给AI提供了一个"分门别类的工具箱"，需要什么工具就拿什么，而不是让它在一个乱七八糟的大箱子里翻找。并且，分类定义好rules后，我们在后面的Skill中可以根据该Skill涉及的范围明确应该引用哪些rules实现按需加载。

Dao Skill

Dao Skill实现创建表、增加字段、删除字段，提供通用的查询方法，拓展查询参数。

定义如下：

markdown 复制代码

---
name: springboot-jpa-dao
description: "专注于 Spring Boot JPA DAO 层实现的 Skill，支持：(1) 根据自然语言生成数据库表结构 DDL 和索引建议，(2) 生成 Entity、Repository、QueryParam 和通用查询方法，(3) 为已有表增删字段并同步更新相关代码"
license: MIT
---

# Spring Boot JPA DAO 层代码生成规范

## 适用场景

当用户需要以下操作时使用此 Skill：
- 根据业务描述生成新的数据库表和对应的 JPA 实体
- 生成通用的 Repository 查询方法
- 为已有表增加或删除字段
- 为实体类生成批量保存、分页查询等通用方法

## 核心设计原则

### 1. 架构分层

<code>

domain/           # 实体类（Entity）
├── BaseAuditEntity.java  # 基础审计实体（已存在）
└── [EntityName].java     # 业务实体

repository/       # 数据访问层
└── [EntityName]Repository.java

param/            # 查询参数 DTO
└── [EntityName]QueryParam.java

</code>

### 2. 技术栈约定
- **数据库**：MySQL
- **ORM 框架**：Spring Data JPA
- **主键生成**：雪花算法（Snowflake ID）
- **审计字段**：自动填充创建/修改时间和创建/修改人
- **代码简化**：Lombok
- **查询方式**：JPA Specification（动态查询）

### 3. 强制规范
- ✅ 所有实体必须继承 `BaseAuditEntity`
- ✅ 禁止使用数据库外键约束
- ✅ 禁止使用 JPA 关联映射（`@ManyToOne`、`@OneToMany` 等）
- ✅ 关联关系通过冗余 ID 字段表示
- ✅ 所有类、字段必须有完整的 Javadoc 注释
- ✅ DDL 中表和列必须带 COMMENT


## 功能一：生成数据库表结构 DDL

### 输入示例
用户自然语言描述：

"创建一个商品表，包含商品名称、商品编码、商品类型、价格、库存数量、商品状态"


### 输出要求

#### 1. MySQL DDL 语句
`
-- 商品表
CREATE TABLE `product` (
    `id` BIGINT NOT NULL COMMENT '主键ID（雪花算法生成）',
    `name` VARCHAR(255) NOT NULL COMMENT '商品名称',
    `code` VARCHAR(64) NOT NULL COMMENT '商品编码，全局唯一',
    `type` VARCHAR(32) NOT NULL COMMENT '商品类型：NORMAL-普通商品，GIFT-赠品',
    `price` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '商品价格（单位：元）',
    `stock` INT NOT NULL DEFAULT 0 COMMENT '库存数量',
    `status` VARCHAR(32) NOT NULL DEFAULT 'ACTIVE' COMMENT '商品状态：ACTIVE-上架，INACTIVE-下架，DELETED-已删除',
    `created_at` BIGINT NOT NULL COMMENT '创建时间（毫秒时间戳）',
    `updated_at` BIGINT NOT NULL COMMENT '修改时间（毫秒时间戳）',
    `created_by` BIGINT COMMENT '创建人ID',
    `updated_by` BIGINT COMMENT '修改人ID',
    PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表：存储商品基础信息及库存状态';
`

#### 2. 索引建议
根据业务场景自动生成索引建议：...省略

#### 3. 索引建议规则
...省略


## 功能二：生成 Entity、Repository 和通用查询

### 2.1 生成 Entity 类
#### 代码模板
...省略

### 2.2 生成 Repository 接口
#### 代码模板
...省略

### 2.3 生成查询参数 DTO
#### 代码模板
...省略

#### 字段命名规则
- **模糊查询字段**（`name`、`title`）：保持单数形式
- **集合查询字段**（`type`、`code`、`status`、`level`）：使用复数形式（如 `types`、`codes`、`statuses`、`levels`）

#### 查询类型判断规则
根据字段名称自动判断查询类型：

| 字段名称关键词 | 查询类型 | 生成参数类型 | 示例 |
|---|---|---|---|
| `type`, `code`, `status`, `level` | IN 查询（集合精确匹配） | `List<String>` | `List<String> types` |
| `name`, `title` | LIKE 查询（模糊匹配） | `String` | `String name` |
| `*Time`, `*At`, `*Date` | BETWEEN 查询（范围） | 两个参数 | `Long startCreatedAt`, `Long endCreatedAt` |

### 2.4 生成通用查询方法


## 功能三：为已有表增加或删除字段
### 3.1 增加字段

#### 输入示例
用户请求："为 Product 表增加字段：供应商ID（supplierId）、商品描述（description）"

#### 输出要求

##### 1. 生成 DDL ALTER 语句
##### 2. 更新 Entity 类
##### 3. 更新 QueryParam 类

### 3.2 删除字段

## 完整示例：从需求到代码
...省略

## 注意事项

### 1. 时间戳统一使用 Long 类型
- 所有时间字段统一使用 `Long` 类型存储毫秒时间戳
- `BaseAuditEntity` 中的 `createdAt`、`updatedAt` 均为 `Long` 类型


### 2. 金额字段使用 BigDecimal
- 所有金额字段必须使用 `BigDecimal` 类型
- 数据库中使用 `DECIMAL(10,2)` 存储
- 避免使用 `Double` 或 `Float` 导致精度丢失

### 3. 枚举值使用 String 存储
- 状态、类型等枚举值使用 `VARCHAR` 存储
- 不使用 `@Enumerated` 注解（避免枚举顺序依赖）
- 在注释中明确枚举的所有可选值

### 4. 外键关联使用 ID 字段
- 禁止使用数据库外键约束
- 关联关系通过 `xxxId` 字段表示
- 在应用层维护数据一致性

### 5. 查询方法复用
- 所有查询条件统一在 `buildSpecification()` 方法中构建
- 严禁为每个查询条件单独创建 Repository 方法
- 通过 QueryParam 动态组合查询条件

### 6. 分页默认值
- 如果未提供 `Pageable` 参数，默认使用 `PageRequest.of(0, 20)`
- 第一页索引为 0，每页 20 条记录
- 前端可通过传递 `Pageable` 自定义分页参数

### 7. 索引建议优先级
1. **唯一约束** → 唯一索引（最高优先级）
2. **高频精确查询** → 普通索引
3. **高频组合查询** → 组合索引
4. **范围查询** → 普通索引（按需）
5. **模糊查询** → 全文索引（可选，仅用于性能优化）

---

## 遵循的项目规范

本 Skill 严格遵循以下项目规范：
- `.cursor/rules/database-table-comments.mdc`：数据库表说明规范
- `.cursor/rules/java-entity-comments.mdc`：Java 领域实体类生成与注释规范

请在生成代码时始终遵循这些规范。

以上内容基本完整定义了 Dao Skill 的使用场景、实现要求以及代码模板结构。文中对部分模板代码和具体场景做了适当省略，以突出整体设计思路。

当使用场景较为复杂时，建议对功能进行进一步拆分，形成独立的子功能文档，例如：功能1.md、功能2.md。再由 SKILL.md 根据不同条件，引入对应的子功能文档。

同样地，如果示例代码体量较大，也建议按照功能或业务场景拆分到不同的 Template 文件中，再统一由 SKILL.md 进行引用和组织。

基础service Skill

对于任何系统而言，都可以抽象出一层其核心依赖的基础数据模型。例如在 EHR 系统中，最核心的基础数据通常就是员工（Employee）和组织（Org）。下游绝大多数业务逻辑，都是基于这两类基础数据进行加工、组合与汇总而形成的。

同时，这类基础能力通常具有相对稳定、变更频率低的特点。因此，在系统架构设计中，将其沉淀为基础 Service 是一种非常自然且合理的选择。对于 EHR 场景而言，EmployeeService 和 OrgService 就非常适合定位为基础 Service。

下面，我们将以 EmployeeService 为例，说明如何定义一个基础 Service 类型的 Skill。

markdown 复制代码

---
name: employee-query
description: 员工查询基础服务。提供员工花名册查询、员工时间轴变动查询、员工基础列表查询能力。用于查询员工信息、员工状态、组织变动、岗位变动等场景。
---

# 员工查询基础服务 (EmployeeService)

EmployeeService 是 EHR 系统的核心基础服务，提供员工数据的多维度查询能力。

## Service 路径

com.example.ehr.service.EmployeeService

> 注意：请根据实际项目结构调整完整包路径

---

## 核心查询方法

### 1. 查询员工花名册

**方法**: `queryEmployeeRoster(QueryParam param)`

**功能**: 按多维度查询员工详细信息，包含所有关联属性。

**查询维度**:
- 员工状态（在职/离职/试用期等）
- 组织（部门/子部门）
- 岗位/职位
- 入职/离职日期范围
- 数据权限控制

**返回内容**:
- 员工基础信息（工号、姓名、入职日期等）
- 合同公司
- 岗位、职位信息
- 工作经历
- 其他详细属性

**适用场景**:
- 查询某部门所有在职员工详细信息
- 生成员工花名册报表
- 需要完整员工档案的业务场景

**示例**:
QueryParam param = new QueryParam();
param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
param.setOrgId(orgId);
List<EmployeeDetail> employees = employeeService.queryEmployeeRoster(param);

---

### 2. 查询员工变动时间轴

**方法**: `queryEmployeeChangesTimeline(Long employeeId, LocalDate startDate, LocalDate endDate)`

**功能**: 查询员工在指定时间周期内的组织、岗位、职务变动历史。

**返回内容**:
- 时间轴形式的变动记录
- 每次变动的生效时间
- 变动前后的对比信息（组织/岗位/职务）

**适用场景**:
- 查看员工晋升/调岗历史
- 员工职业发展轨迹分析
- 绩效评估时查看岗位变动情况

**示例**:
Long employeeId = 12345L;
LocalDate start = LocalDate.of(2024, 1, 1);
LocalDate end = LocalDate.of(2025, 12, 31);
List<EmployeeChangeEvent> timeline = employeeService.queryEmployeeChangesTimeline(employeeId, start, end);

---

### 3. 查询员工基础列表

**方法**: `listEmployees(QueryParam param)`

**功能**: 快速查询员工列表，仅返回基础信息和工作信息，不包含附加属性。

**返回内容**:
- 员工基础信息（工号、姓名、状态）
- 工作信息（部门、岗位、入职日期）
- 不包含：合同详情、工作经历等附加信息

**适用场景**:
- 下拉列表/选择器中的员工选项
- 快速列表展示
- 性能敏感的批量查询

**示例**:
QueryParam param = new QueryParam();
param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
List<EmployeeBasicInfo> employees = employeeService.listEmployees(param);

---

## 方法选择指南

| 场景 | 推荐方法 | 原因 |
|------|---------|------|
| 需要完整员工档案 | queryEmployeeRoster | 包含所有关联属性 |
| 查看员工晋升调岗记录 | queryEmployeeChangesTimeline | 时间轴形式展示变动 |
| 下拉选择器/快速列表 | listEmployees | 轻量级，性能好 |
| 生成详细报表 | queryEmployeeRoster | 数据最全面 |
| 批量查询员工基本信息 | listEmployees | 避免冗余数据 |

---

## 使用示例

### 示例 1: 查询某部门在职员工

// 查询技术部所有在职员工的详细信息
QueryParam param = new QueryParam();
param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
param.setOrgId(techDepartmentId);
List<EmployeeDetail> employees = employeeService.queryEmployeeRoster(param);

### 示例 2: 查询员工岗位变动历史

// 查询张三在 2025 年的岗位变动情况
Long zhangSanId = 10086L;
LocalDate yearStart = LocalDate.of(2025, 1, 1);
LocalDate yearEnd = LocalDate.of(2025, 12, 31);
List<EmployeeChangeEvent> changes = employeeService.queryEmployeeChangesTimeline(zhangSanId, yearStart, yearEnd);

### 示例 3: 获取在职员工列表（轻量级）

// 获取所有在职员工的基础信息用于下拉选择
QueryParam param = new QueryParam();
param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
List<EmployeeBasicInfo> employees = employeeService.listEmployees(param);

---

## 注意事项

1. **数据权限**: queryEmployeeRoster 支持数据权限控制，自动过滤当前用户无权访问的员工
2. **性能考虑**: 大批量查询时优先使用 listEmployees，避免查询冗余数据
3. **时间范围**: 查询时间轴时建议限制合理的时间范围，避免返回过多历史数据
4. **状态过滤**: 建议明确指定员工状态，避免查询到不需要的离职员工

从工程实现角度看，这类基础 Service 更适合被定义为一份标准化接口能力文档，用于明确描述：方法能力边界、参数结构以及返回信息语义，从而让 AI 能够在合适的场景下正确调用对应能力。

git workflow工作流

git workflow Skill涵盖代码审查、自动生成commit信息、提交规范、MR管理等完整的工作流。

markdown 复制代码

---
name: git-workflow
description: 完整的 Git 工作流管理。支持基于 git diff 自动生成 Conventional Commits 格式的 commit message、代码审查（正确性、安全性、性能、可读性、Java 规范）、Pull Request 管理。在用户提交代码、创建 PR、请求代码审查或需要 commit message 时使用。
---

# Git Workflow - 完整工作流管理

提供从代码提交到 PR 合并的完整 Git 工作流支持。

---

## 核心功能

1. **自动生成 Commit Message** - 基于 git diff 分析变更，生成符合 Conventional Commits 规范的提交信息
2. **代码审查** - 多维度审查代码质量（正确性、安全性、性能、可读性、Java 规范）
3. **Pull Request 管理** - 创建、描述、管理 GitHub Pull Request

---

## ⚠️ 安全约束 - 禁止执行的 Git 操作

**重要：以下 Git 命令严禁执行，除非用户明确要求并再次确认：**

### 🚫 绝对禁止的操作

#### 1. 删除分支
`
# 禁止删除本地分支
git branch -d <branch>
git branch -D <branch>

# 禁止删除远程分支
git push origin --delete <branch>
git push origin :<branch>
`

#### 2. 强制推送
`
# 禁止强制推送到任何分支
git push --force
git push -f
git push --force-with-lease  # 除非用户明确要求
`

#### 3. 硬重置（导致数据丢失）
`
# 禁止硬重置
git reset --hard
git reset --hard HEAD~1

# 禁止重置到远程分支
git reset --hard origin/main
`

#### 4. 修改历史记录
`
# 禁止交互式变基
git rebase -i

# 禁止修改已推送的 commit
git commit --amend  # 如果已推送，禁止
git rebase  # 如果已推送，禁止
`

#### 5. 删除未提交的修改

`
# 禁止丢弃所有修改
git checkout -- .
git restore .

# 禁止清理工作目录
git clean -fd
git clean -fdx
`

#### 6. 修改远程仓库配置
`
# 禁止修改远程仓库地址
git remote set-url origin <url>

# 禁止删除远程仓库
git remote remove origin
`

#### 7. 危险的分支操作
`
# 禁止强制签出（丢弃本地修改）
git checkout -f

# 禁止重命名当前分支
git branch -m <new-name>  # 需谨慎

# 禁止切换到游离 HEAD 状态
git checkout <commit-hash>  # 除非用户明确要求
`

### ✅ 允许的安全操作

以下操作是安全的，可以正常执行：

`
# 查看类命令（只读）
git status
git log
git diff
git show
git branch
git remote -v

# 安全的添加和提交
git add <files>
git commit -m "message"
git commit  # 打开编辑器

# 安全的推送（非强制）
git push
git push origin <branch>

# 安全的拉取
git pull
git fetch

# 安全的分支操作
git checkout <branch>  # 切换到已存在的分支
git checkout -b <new-branch>  # 创建新分支
git merge <branch>  # 普通合并

# 软重置（不丢失修改）
git reset --soft HEAD~1
git reset HEAD <file>  # 取消暂存
`

### 🛡️ 安全原则

1. **只读优先**：优先使用只读命令（status, log, diff, show）
2. **确认机制**：对于任何可能修改历史或删除数据的操作，必须先向用户说明风险并获得明确确认
3. **数据保护**：永远不主动执行会导致代码丢失的命令
4. **非破坏性**：优先使用非破坏性的替代方案（如 `git reset --soft` 代替 `git reset --hard`）
5. **用户主导**：即使用户要求危险操作，也要先说明后果，建议安全替代方案

### 📋 危险操作检查清单

执行任何 git 命令前，检查：

- [ ] 这个命令是否会删除任何数据？
- [ ] 这个命令是否会修改已推送的历史？
- [ ] 这个命令是否会影响其他人的工作？
- [ ] 是否有更安全的替代方案？
- [ ] 用户是否完全理解这个命令的后果？

**如果任何一项回答"是"且用户未明确要求，则不执行该命令。**

---

## 工作流 1: 生成 Commit Message

### 快速流程

当用户请求生成 commit message 时：

1. **分析变更**
   
   `git diff --staged`
  

2. **生成 Conventional Commits 格式的 message**
3. 
   <type>(<scope>): <subject>
   
   <body>
   
   <footer>

3. **确认并提交**

### Commit Type 选择

| Type | 使用场景 | 示例 |
|------|---------|------|
| `feat` | 新功能 | feat(user): add email verification |
| `fix` | Bug 修复 | fix(auth): handle null token edge case |
| `docs` | 文档变更 | docs(readme): update installation steps |
| `style` | 代码格式（不影响逻辑） | style(user): format with prettier |
| `refactor` | 重构（不改变功能） | refactor(service): extract method |
| `perf` | 性能优化 | perf(query): add database index |
| `test` | 测试相关 | test(user): add unit tests |
| `chore` | 构建/工具变更 | chore(deps): upgrade spring boot |

### 生成步骤

1. **读取 git diff**
   `
   git diff --staged
   `

2. **分析变更内容**
    - 识别变更的文件和模块
    - 理解代码逻辑变化
    - 确定变更类型（新增/修复/重构等）

3. **生成 commit message**
    - **Type**: 根据变更性质选择正确的 type
    - **Scope**: 使用模块名、文件名或功能域（如 auth、user、order）
    - **Subject**: 简洁描述（<50 字符，动词开头，不加句号）
    - **Body** (可选): 详细说明变更原因和实现方式
    - **Footer** (可选): Breaking changes 或关闭的 issue

4. **向用户展示并确认**

### 示例输出格式


feat(employee): add employee roster query API

Implement EmployeeService.queryEmployeeRoster() to support:
- Multi-dimension filtering (status, org, position)
- Data permission control
- Complete employee details with associations

Closes #123


---

## 工作流 2: 代码审查

### 审查检查清单

当用户请求代码审查时，按以下维度进行：

#### ✅ 1. 正确性 (Correctness)
- [ ] 逻辑正确，符合需求
- [ ] 边界条件处理完善
- [ ] 错误处理完整
- [ ] 空值/null 处理符合规范（参考 `java-null-safety.mdc`）
- [ ] 参数验证完整（参考 `java-request-validation.mdc`）

#### 🔒 2. 安全性 (Security)
- [ ] 无 SQL 注入风险
- [ ] 无 XSS 漏洞
- [ ] 敏感信息已脱敏
- [ ] 权限校验完整
- [ ] 密码/密钥未硬编码

#### ⚡ 3. 性能 (Performance)
- [ ] 避免 N+1 查询
- [ ] 数据库查询已优化
- [ ] 大数据量处理有分页/限制
- [ ] 无不必要的循环嵌套
- [ ] 缓存使用合理

#### 📖 4. 可读性 (Readability)
- [ ] 命名清晰、符合规范
- [ ] 方法注释完整（参考 `java-method-comments.mdc`）
- [ ] 实体注释完整（参考 `java-entity-comments.mdc`）
- [ ] API 文档完整（参考 `java-api-documentation.mdc`）
- [ ] 代码结构清晰，职责单一
- [ ] 避免过长方法/类

#### ☕ 5. Java 规范 (Standards)
- [ ] 符合项目编码规范
- [ ] 错误码使用正确（参考 `java-error-codes-and-enums.mdc`）
- [ ] 数据库表注释完整（参考 `database-table-comments.mdc`）
- [ ] 业务领域术语正确（参考 `business-domain-catering.mdc`）

### 提供反馈格式

使用优先级标记：

- 🔴 **Critical (必须修复)**: 阻塞合并的问题（安全漏洞、严重 bug）
- 🟡 **Important (建议修复)**: 重要但不阻塞的问题（性能问题、规范不符）
- 🟢 **Suggestion (可选改进)**: 优化建议（命名、注释、代码风格）

### 审查流程

1. **读取变更**
   `
   git diff main...HEAD
   `

2. **按检查清单逐项审查**

3. **生成审查报告**
   `
   ## Code Review Summary
   
   ### 🔴 Critical Issues
   - [文件:行号] 问题描述
   
   ### 🟡 Important Issues
   - [文件:行号] 问题描述
   
   ### 🟢 Suggestions
   - [文件:行号] 建议内容
   
   ### ✅ Good Practices
   - 值得肯定的代码实践
   `

4. **提供具体的修改建议**

---

## 工作流 3: Pull Request 管理

### 创建 PR 流程

1. **生成 PR 标题**
    - 基于 commit message 格式
    - 示例：`feat(employee): add employee roster query API`

2. **生成 PR 描述**
   `
   ## 📝 Summary
   - 简要描述本次 PR 的目的和内容
   
   ## 🔄 Changes
   - 变更点 1
   - 变更点 2
   
   ## 🧪 Test Plan
   - [ ] 单元测试已通过
   - [ ] 手动测试场景 1
   - [ ] 手动测试场景 2
   
   ## 📚 Related Issues
   Closes #123
   
   ## ⚠️ Breaking Changes (if any)
   - 不兼容的变更说明
   `

3. **使用 gh CLI 创建 PR**
   `
   gh pr create --title "标题" --body "描述"
   `

### PR 审查清单（作为 Reviewer）

当用户作为 Reviewer 审查 PR 时：

1. **阅读 PR 描述**，理解变更目的
2. **运行代码审查工作流**（参考"工作流 2"）
3. **检查测试**
    - [ ] 是否有对应的单元测试
    - [ ] 测试覆盖是否充分
    - [ ] CI 是否通过
4. **提供审查意见**（使用优先级标记）
5. **决定是否批准**
    - 无 🔴 Critical 问题 → Approve
    - 有 🔴 Critical 问题 → Request Changes

---

## 使用示例

### 示例 1: 生成 Commit Message

**用户**: "帮我生成一个 commit message"

**Assistant 流程**:
1. 执行 `git diff --staged`
2. 分析变更（假设添加了员工查询 API）
3. 生成：
   `
   feat(employee): add employee roster query API
   
   Implement EmployeeService.queryEmployeeRoster() with:
   - Multi-dimension filtering support
   - Data permission control
   - Complete employee details
   `

### 示例 2: 代码审查

**用户**: "审查一下这个 PR"

**Assistant 流程**:
1. 执行 `git diff main...HEAD` 或读取 PR diff
2. 按检查清单逐项审查
3. 生成审查报告：
   `
   ## Code Review Summary
   
   ### 🟡 Important Issues
   - [EmployeeService.java:45] 建议添加分页参数避免一次查询过多数据
   - [EmployeeController.java:23] API 文档缺少参数说明
   
   ### 🟢 Suggestions
   - [EmployeeService.java:67] 方法命名建议从 getList 改为 queryEmployeeList
   
   ### ✅ Good Practices
   - 参数验证完整
   - 异常处理规范
   `

### 示例 3: 创建 PR

**用户**: "帮我创建一个 PR"

**Assistant 流程**:
1. 分析 commit 历史和变更
2. 生成 PR 标题和描述
3. 执行：
   `bash
   gh pr create --title "feat(employee): add employee roster query API" --body "..."
   `

---

## 引用的项目规范

代码审查时，请参考以下项目规范文件：
... 各类mdc文件
这些文件位于：`.cursor/rules/`

审查时如需查看具体规范，读取对应的规范文件。

---

## 详细资源

- 完整的审查标准和细则：[STANDARDS.md](STANDARDS.md)
- Commit 和 PR 示例：[examples.md](examples.md)

---

## 关键原则

1. **Commit Message**: 遵循 Conventional Commits，清晰描述变更内容和原因
2. **代码审查**: 全面、具体、建设性，使用优先级标记
3. **PR 管理**: 描述完整，测试充分，便于 Review
4. **项目规范**: 严格遵循项目现有的编码规范和注释规范
5. **安全第一**: 严禁执行任何可能导致数据丢失或历史修改的危险 Git 操作，除非用户明确要求并理解后果

与前面提到的 Dao Skill 和基础 Service Skill 不同，Git Workflow Skill 在设计时需要重点考虑安全性问题 。由于 Git 本身具备较强的破坏性操作能力，如果由 AI 自动触发执行，可能存在较高风险。

因此，在该 Skill 的定义中，应将安全性作为核心关注点：

明确列出严禁执行的高风险命令
在 rules 中定义完整的 Git 操作安全规范
在 Command Allowlist 中仅允许执行经过审核的安全命令

需要注意的是，一些危险操作与安全操作的差异往往仅体现在参数层面，因此很难通过简单的命令级限制完全规避风险。

基于这一点，相比将其定义为由 AI 自动触发的 Skill，将其设计为需要人工手动触发的 Command，往往是更加稳妥的方案。

现实的困境

在上一小节中，我们仅基于业务开发实现了三个 Skill。一方面是受篇幅限制，另一方面也是因为实际项目中的复杂度远高于示例场景。

在真实需求开发中，往往会同时涉及多个数据表的变更，包括新增、删除、更新等多种操作类型。因此，需要根据实际项目情况，构建更丰富的 Skill 体系。

这些 Skill 并不是孤立存在的，而是可以通过组合，形成更高层级、更强能力的复合 Skill。例如，可以在 Dao Skill 的基础上，进一步构建 control-service-dao 全链路 Skill；也可以扩展出消息队列相关 Skill 等。

真正的现实困境，并不在于如何构建 Skill，而在于我们是否真正理解问题本身。

Skill 可以不断完善，工程体系可以不断进化，但有两个问题始终绕不开：

我们是否真的理解需求？
我们是否具备把复杂问题拆解成可执行任务的能力？

当下很多讨论集中在：如何让 AI 写代码更好、调用工具更准确、生成结果更稳定。

但一个更本质的问题是：
如果问题本身就没有被正确定义，再强的 AI 也只能稳定地做错事。

我们当然可以构建越来越完善的 Skill 体系，

但 AI 是否一定能够按照我们的期望执行？需求复杂度是否可以被量化评估？任务拆解是否可以被标准化建模？

也许答案是：可以，但不会是绝对精确的。

软件工程从来都不是纯数学问题，它更像是一门"半工程、半经验"的学科。

未来的开发者，可能不再只是写代码的人，而是：
定义问题的人、拆解复杂度的人、组织 AI 能力的人。

对于这些问题，我目前也只有一个还不够清晰的答案。

如果用一句朴素但真实的话来说就是：

问题一定存在，但解法也一定存在。

只是这些解法，不会一次性出现，而会在一代代工程实践中逐渐成型。

这个话题，留到以后结合更多实践，再与大家分享。

结语

我们正站在一个重要的技术转折点上。AI 的出现，并不是为了替代开发者，而是为了让开发者能够做得更好、走得更远。但前提是：我们需要学会如何与 AI 协作。 Skill 的工程化，正是连接人与 AI 协作关系的一座桥梁。它让 AI 从"一个会写代码的工具"，逐步进化为"一个理解业务、遵守规范、能够继承经验的智能助手"。未来，属于那些能够驾驭 AI 的团队。而驾驭 AI 的钥匙，正握在每一位开发者手中。

从现在开始，构建属于你的第一个 Skill。