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

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

/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设计为多层体系：

┌─────────────────────────────────────┐

│ 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实现创建表、增加字段、删除字段，提供通用的查询方法，拓展查询参数。

定义如下：

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

license: MIT

Spring Boot JPA DAO 层代码生成规范

适用场景

当用户需要以下操作时使用此 Skill：

根据业务描述生成新的数据库表和对应的 JPA 实体
生成通用的 Repository 查询方法
为已有表增加或删除字段
为实体类生成批量保存、分页查询等通用方法

核心设计原则

1. 架构分层

domain/ # 实体类（Entity）

├── BaseAuditEntity.java # 基础审计实体（已存在）

└── [EntityName].java # 业务实体

repository/ # 数据访问层

└── [EntityName]Repository.java

param/ # 查询参数 DTO

└── [EntityName]QueryParam.java

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`）

查询类型判断规则

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

|---|---|---|---|

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. 索引建议优先级

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

遵循的项目规范

本 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。

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 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 timeline = employeeService.queryEmployeeChangesTimeline(employeeId, start, end);

3. 查询员工基础列表

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

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

**返回内容**:

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

**适用场景**:

下拉列表/选择器中的员工选项
快速列表展示
性能敏感的批量查询

**示例**:

QueryParam param = new QueryParam();

param.setEmployeeStatus(EmployeeStatus.ON_BOARD);

List employees = employeeService.listEmployees(param);

方法选择指南

| 场景 | 推荐方法 | 原因 |

|------|---------|------|

| 需要完整员工档案 | queryEmployeeRoster | 包含所有关联属性 |

| 查看员工晋升调岗记录 | queryEmployeeChangesTimeline | 时间轴形式展示变动 |

| 下拉选择器/快速列表 | listEmployees | 轻量级，性能好 |

| 生成详细报表 | queryEmployeeRoster | 数据最全面 |

| 批量查询员工基本信息 | listEmployees | 避免冗余数据 |

使用示例

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

// 查询技术部所有在职员工的详细信息

QueryParam param = new QueryParam();

param.setEmployeeStatus(EmployeeStatus.ON_BOARD);

param.setOrgId(techDepartmentId);

List employees = employeeService.queryEmployeeRoster(param);

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

// 查询张三在 2025 年的岗位变动情况

Long zhangSanId = 10086L;

LocalDate yearStart = LocalDate.of(2025, 1, 1);

LocalDate yearEnd = LocalDate.of(2025, 12, 31);

List changes = employeeService.queryEmployeeChangesTimeline(zhangSanId, yearStart, yearEnd);

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

// 获取所有在职员工的基础信息用于下拉选择

QueryParam param = new QueryParam();

param.setEmployeeStatus(EmployeeStatus.ON_BOARD);

List employees = employeeService.listEmployees(param);

注意事项

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

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

git workflow工作流

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

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

Git Workflow - 完整工作流管理

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

核心功能

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

?? 安全约束 - 禁止执行的 Git 操作

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

?? 绝对禁止的操作

1. 删除分支

禁止删除本地分支

git branch -d

git branch -D

禁止删除远程分支

git push origin --delete

git push origin :

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

禁止删除远程仓库

git remote remove origin

7. 危险的分支操作

禁止强制签出（丢弃本地修改）

git checkout -f

禁止重命名当前分支

git branch -m # 需谨慎

禁止切换到游离 HEAD 状态

git checkout # 除非用户明确要求

? 允许的安全操作

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

查看类命令（只读）

git status

git log

git diff

git show

git branch

git remote -v

安全的添加和提交

git add

git commit -m "message"

git commit # 打开编辑器

安全的推送（非强制）

git push

git push origin

安全的拉取

git pull

git fetch

安全的分支操作

git checkout # 切换到已存在的分支

git checkout -b # 创建新分支

git merge # 普通合并

软重置（不丢失修改）

git reset --soft HEAD~1

git reset HEAD # 取消暂存

??? 安全原则

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

?? 危险操作检查清单

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

$\] 这个命令是否会删除任何数据？$
$\] 这个命令是否会影响其他人的工作？$
$\] 用户是否完全理解这个命令的后果？$

工作流 1: 生成 Commit Message

快速流程

当用户请求生成 commit message 时：

**分析变更**

`git diff --staged`

**生成 Conventional Commits 格式的 message**

():

**确认并提交**

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 |

生成步骤

**读取 git diff**

git diff --staged

**分析变更内容**

识别变更的文件和模块
理解代码逻辑变化
确定变更类型（新增/修复/重构等）

**生成 commit message**

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

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

示例输出格式

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)

$\] 逻辑正确，符合需求$
$\] 错误处理完整$
$\] 参数验证完整（参考 \`java-request-validation.mdc\`）$
$\] 无 SQL 注入风险$
$\] 敏感信息已脱敏$
$\] 密码/密钥未硬编码$
$\] 避免 N+1 查询$
$\] 大数据量处理有分页/限制$
$\] 缓存使用合理$
$\] 命名清晰、符合规范$
$\] 实体注释完整（参考 \`java-entity-comments.mdc\`）$
$\] 代码结构清晰，职责单一$

? 5. Java 规范 (Standards)

$\] 符合项目编码规范$
$\] 数据库表注释完整（参考 \`database-table-comments.mdc\`）$

提供反馈格式

使用优先级标记：

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

审查流程

**读取变更**

git diff main...HEAD

**按检查清单逐项审查**
**生成审查报告**

Code Review Summary

?? Critical Issues

$文件:行号\] 问题描述$
$文件:行号\] 问题描述$
$文件:行号\] 建议内容$
值得肯定的代码实践

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

工作流 3: Pull Request 管理

创建 PR 流程

**生成 PR 标题**

基于 commit message 格式
示例：`feat(employee): add employee roster query API`

**生成 PR 描述**

?? Summary

简要描述本次 PR 的目的和内容

?? Changes

变更点 1
变更点 2

?? Test Plan

$\] 单元测试已通过$
$\] 手动测试场景 2$

Closes #123

?? Breaking Changes (if any)

不兼容的变更说明

**使用 gh CLI 创建 PR**

gh pr create --title "标题" --body "描述"

PR 审查清单（作为 Reviewer）

当用户作为 Reviewer 审查 PR 时：

**阅读 PR 描述**，理解变更目的
**运行代码审查工作流**（参考"工作流 2"）
**检查测试**

$\] 是否有对应的单元测试$
$\] CI 是否通过$

**决定是否批准**

无 ?? Critical 问题 → Approve
有 ?? Critical 问题 → Request Changes

使用示例

示例 1: 生成 Commit Message

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

**Assistant 流程**:

执行 `git diff --staged`
分析变更（假设添加了员工查询 API）
生成：

feat(employee): add employee roster query API

Implement EmployeeService.queryEmployeeRoster() with:

Multi-dimension filtering support
Data permission control
Complete employee details

示例 2: 代码审查

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

**Assistant 流程**:

执行 `git diff main...HEAD` 或读取 PR diff
按检查清单逐项审查
生成审查报告：

Code Review Summary

?? Important Issues

$EmployeeService.java:45\] 建议添加分页参数避免一次查询过多数据$

?? Suggestions

$EmployeeService.java:67\] 方法命名建议从 getList 改为 queryEmployeeList$
参数验证完整
异常处理规范

示例 3: 创建 PR

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

**Assistant 流程**:

分析 commit 历史和变更
生成 PR 标题和描述
执行：

`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)

关键原则

**Commit Message**: 遵循 Conventional Commits，清晰描述变更内容和原因
**代码审查**: 全面、具体、建设性，使用优先级标记
**PR 管理**: 描述完整，测试充分，便于 Review
**项目规范**: 严格遵循项目现有的编码规范和注释规范
**安全第一**: 严禁执行任何可能导致数据丢失或历史修改的危险 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 能力的人。

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

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

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

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

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

.Acwing基础课第题-简单-区间和

Spring Boot JPA DAO 层代码生成规范

适用场景

核心设计原则

1. 架构分层

2. 技术栈约定

3. 强制规范

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

输入示例

输出要求

1. MySQL DDL 语句

2. 索引建议

3. 索引建议规则

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

2.1 生成 Entity 类

代码模板

2.2 生成 Repository 接口

代码模板

2.3 生成查询参数 DTO

代码模板

字段命名规则

查询类型判断规则

2.4 生成通用查询方法

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

3.1 增加字段

输入示例

输出要求

1. 生成 DDL ALTER 语句

2. 更新 Entity 类

3. 更新 QueryParam 类

3.2 删除字段

完整示例：从需求到代码

注意事项

1. 时间戳统一使用 Long 类型

2. 金额字段使用 BigDecimal

3. 枚举值使用 String 存储

4. 外键关联使用 ID 字段

5. 查询方法复用

6. 分页默认值

7. 索引建议优先级

遵循的项目规范

员工查询基础服务 (EmployeeService)

Service 路径

核心查询方法

1. 查询员工花名册

2. 查询员工变动时间轴

3. 查询员工基础列表

方法选择指南

使用示例

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

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

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

注意事项

Git Workflow - 完整工作流管理

核心功能

?? 安全约束 - 禁止执行的 Git 操作

?? 绝对禁止的操作

1. 删除分支

禁止删除本地分支

禁止删除远程分支

2. 强制推送

禁止强制推送到任何分支

3. 硬重置（导致数据丢失）

禁止硬重置

禁止重置到远程分支

4. 修改历史记录

禁止交互式变基

禁止修改已推送的 commit

5. 删除未提交的修改

禁止丢弃所有修改

禁止清理工作目录

6. 修改远程仓库配置

禁止修改远程仓库地址

禁止删除远程仓库

7. 危险的分支操作

禁止强制签出（丢弃本地修改）

禁止重命名当前分支

禁止切换到游离 HEAD 状态

? 允许的安全操作

查看类命令（只读）