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包含：

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

复制代码

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

1. ┌─────────────────────────────────────┐
2. │      Rules 层（规范与约束）          │
3. │  - 技术栈选型                        │
4. │  - 代码规范                          │ │
5. └─────────────────────────────────────┘
6. ↓ 指导
7. ┌─────────────────────────────────────┐
8. │      Skills 层（能力模块）             │
9. │   - 工具类、oss Skill                 │
10. │  - DAO CRUD Skill                    │
11. │  - 消息队列 Skill                     │
12. │  - 基础Service Skill                 │
13. │  - 领域服务库（用户、订单、支付...）Skill │
14. └─────────────────────────────────────┘
15. ↓ 组合
16. ┌─────────────────────────────────────┐
17. │      Workflow 层（流程自动化）        │
18. │  - Git代码审查、生成commit Skill      │
19. │  - CI/CD配置 Skill                  │
20. │  - 文档生成 Skill│
21. └─────────────────────────────────────┘

复制代码

我觉得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实现创建表、增加字段、删除字段，提供通用的查询方法，拓展查询参数。
定义如下：

1. ---
2. name: springboot-jpa-dao
3. description: "专注于 Spring Boot JPA DAO 层实现的 Skill，支持：(1) 根据自然语言生成数据库表结构 DDL 和索引建议，(2) 生成 Entity、Repository、QueryParam 和通用查询方法，(3) 为已有表增删字段并同步更新相关代码"
4. license: MIT
5. ---
7. # Spring Boot JPA DAO 层代码生成规范
9. ## 适用场景
11. 当用户需要以下操作时使用此 Skill：
12. - 根据业务描述生成新的数据库表和对应的 JPA 实体
13. - 生成通用的 Repository 查询方法
14. - 为已有表增加或删除字段
15. - 为实体类生成批量保存、分页查询等通用方法
17. ## 核心设计原则
19. ### 1. 架构分层
23. domain/           # 实体类（Entity）
24. ├── BaseAuditEntity.java  # 基础审计实体（已存在）
25. └── [EntityName].java     # 业务实体
27. repository/       # 数据访问层
28. └── [EntityName]Repository.java
30. param/            # 查询参数 DTO
31. └── [EntityName]QueryParam.java
35. ### 2. 技术栈约定
36. - **数据库**：MySQL
37. - **ORM 框架**：Spring Data JPA
38. - **主键生成**：雪花算法（Snowflake ID）
39. - **审计字段**：自动填充创建/修改时间和创建/修改人
40. - **代码简化**：Lombok
41. - **查询方式**：JPA Specification（动态查询）
43. ### 3. 强制规范
44. - ✅ 所有实体必须继承 `BaseAuditEntity`
45. - ✅ 禁止使用数据库外键约束
46. - ✅ 禁止使用 JPA 关联映射（`@ManyToOne`、`@OneToMany` 等）
47. - ✅ 关联关系通过冗余 ID 字段表示
48. - ✅ 所有类、字段必须有完整的 Javadoc 注释
49. - ✅ DDL 中表和列必须带 COMMENT
52. ## 功能一：生成数据库表结构 DDL
54. ### 输入示例
55. 用户自然语言描述：
57. "创建一个商品表，包含商品名称、商品编码、商品类型、价格、库存数量、商品状态"
60. ### 输出要求
62. #### 1. MySQL DDL 语句
63. `
64. -- 商品表
65. CREATE TABLE `product` (
66.     `id` BIGINT NOT NULL COMMENT '主键ID（雪花算法生成）',
67.     `name` VARCHAR(255) NOT NULL COMMENT '商品名称',
68.     `code` VARCHAR(64) NOT NULL COMMENT '商品编码，全局唯一',
69.     `type` VARCHAR(32) NOT NULL COMMENT '商品类型：NORMAL-普通商品，GIFT-赠品',
70.     `price` DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT '商品价格（单位：元）',
71.     `stock` INT NOT NULL DEFAULT 0 COMMENT '库存数量',
72.     `status` VARCHAR(32) NOT NULL DEFAULT 'ACTIVE' COMMENT '商品状态：ACTIVE-上架，INACTIVE-下架，DELETED-已删除',
73.     `created_at` BIGINT NOT NULL COMMENT '创建时间（毫秒时间戳）',
74.     `updated_at` BIGINT NOT NULL COMMENT '修改时间（毫秒时间戳）',
75.     `created_by` BIGINT COMMENT '创建人ID',
76.     `updated_by` BIGINT COMMENT '修改人ID',
77.     PRIMARY KEY (`id`)
78. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表：存储商品基础信息及库存状态';
79. `
81. #### 2. 索引建议
82. 根据业务场景自动生成索引建议：...省略
84. #### 3. 索引建议规则
85. ...省略
88. ## 功能二：生成 Entity、Repository 和通用查询
90. ### 2.1 生成 Entity 类
91. #### 代码模板
92. ...省略
94. ### 2.2 生成 Repository 接口
95. #### 代码模板
96. ...省略
98. ### 2.3 生成查询参数 DTO
99. #### 代码模板
100. ...省略
102. #### 字段命名规则
103. - **模糊查询字段**（`name`、`title`）：保持单数形式
104. - **集合查询字段**（`type`、`code`、`status`、`level`）：使用复数形式（如 `types`、`codes`、`statuses`、`levels`）
106. #### 查询类型判断规则
107. 根据字段名称自动判断查询类型：
109. | 字段名称关键词 | 查询类型 | 生成参数类型 | 示例 |
110. |---|---|---|---|
111. | `type`, `code`, `status`, `level` | IN 查询（集合精确匹配） | `List<String>` | `List<String> types` |
112. | `name`, `title` | LIKE 查询（模糊匹配） | `String` | `String name` |
113. | `*Time`, `*At`, `*Date` | BETWEEN 查询（范围） | 两个参数 | `Long startCreatedAt`, `Long endCreatedAt` |
115. ### 2.4 生成通用查询方法
118. ## 功能三：为已有表增加或删除字段
119. ### 3.1 增加字段
121. #### 输入示例
122. 用户请求："为 Product 表增加字段：供应商ID（supplierId）、商品描述（description）"
124. #### 输出要求
126. ##### 1. 生成 DDL ALTER 语句
127. ##### 2. 更新 Entity 类
128. ##### 3. 更新 QueryParam 类
130. ### 3.2 删除字段
132. ## 完整示例：从需求到代码
133. ...省略
135. ## 注意事项
137. ### 1. 时间戳统一使用 Long 类型
138. - 所有时间字段统一使用 `Long` 类型存储毫秒时间戳
139. - `BaseAuditEntity` 中的 `createdAt`、`updatedAt` 均为 `Long` 类型
142. ### 2. 金额字段使用 BigDecimal
143. - 所有金额字段必须使用 `BigDecimal` 类型
144. - 数据库中使用 `DECIMAL(10,2)` 存储
145. - 避免使用 `Double` 或 `Float` 导致精度丢失
147. ### 3. 枚举值使用 String 存储
148. - 状态、类型等枚举值使用 `VARCHAR` 存储
149. - 不使用 `@Enumerated` 注解（避免枚举顺序依赖）
150. - 在注释中明确枚举的所有可选值
152. ### 4. 外键关联使用 ID 字段
153. - 禁止使用数据库外键约束
154. - 关联关系通过 `xxxId` 字段表示
155. - 在应用层维护数据一致性
157. ### 5. 查询方法复用
158. - 所有查询条件统一在 `buildSpecification()` 方法中构建
159. - 严禁为每个查询条件单独创建 Repository 方法
160. - 通过 QueryParam 动态组合查询条件
162. ### 6. 分页默认值
163. - 如果未提供 `Pageable` 参数，默认使用 `PageRequest.of(0, 20)`
164. - 第一页索引为 0，每页 20 条记录
165. - 前端可通过传递 `Pageable` 自定义分页参数
167. ### 7. 索引建议优先级
168. 1. **唯一约束** → 唯一索引（最高优先级）
169. 2. **高频精确查询** → 普通索引
170. 3. **高频组合查询** → 组合索引
171. 4. **范围查询** → 普通索引（按需）
172. 5. **模糊查询** → 全文索引（可选，仅用于性能优化）
174. ---
176. ## 遵循的项目规范
178. 本 Skill 严格遵循以下项目规范：
179. - `.cursor/rules/database-table-comments.mdc`：数据库表说明规范
180. - `.cursor/rules/java-entity-comments.mdc`：Java 领域实体类生成与注释规范
182. 请在生成代码时始终遵循这些规范。

复制代码

以上内容基本完整定义了 Dao Skill 的使用场景、实现要求以及代码模板结构。文中对部分模板代码和具体场景做了适当省略，以突出整体设计思路。
当使用场景较为复杂时，建议对功能进行进一步拆分，形成独立的子功能文档，例如：功能1.md、功能2.md。再由 SKILL.md 根据不同条件，引入对应的子功能文档。
同样地，如果示例代码体量较大，也建议按照功能或业务场景拆分到不同的 Template 文件中，再统一由 SKILL.md 进行引用和组织。
基础service Skill

对于任何系统而言，都可以抽象出一层其核心依赖的基础数据模型。例如在 EHR 系统中，最核心的基础数据通常就是员工（Employee）和组织（Org）。下游绝大多数业务逻辑，都是基于这两类基础数据进行加工、组合与汇总而形成的。
同时，这类基础能力通常具有相对稳定、变更频率低的特点。因此，在系统架构设计中，将其沉淀为基础 Service 是一种非常自然且合理的选择。对于 EHR 场景而言，EmployeeService 和 OrgService 就非常适合定位为基础 Service。
下面，我们将以 EmployeeService 为例，说明如何定义一个基础 Service 类型的 Skill。

1. ---
2. name: employee-query
3. description: 员工查询基础服务。提供员工花名册查询、员工时间轴变动查询、员工基础列表查询能力。用于查询员工信息、员工状态、组织变动、岗位变动等场景。
4. ---
6. # 员工查询基础服务 (EmployeeService)
8. EmployeeService 是 EHR 系统的核心基础服务，提供员工数据的多维度查询能力。
10. ## Service 路径
12. com.example.ehr.service.EmployeeService
14. > 注意：请根据实际项目结构调整完整包路径
16. ---
18. ## 核心查询方法
20. ### 1. 查询员工花名册
22. **方法**: `queryEmployeeRoster(QueryParam param)`
24. **功能**: 按多维度查询员工详细信息，包含所有关联属性。
26. **查询维度**:
27. - 员工状态（在职/离职/试用期等）
28. - 组织（部门/子部门）
29. - 岗位/职位
30. - 入职/离职日期范围
31. - 数据权限控制
33. **返回内容**:
34. - 员工基础信息（工号、姓名、入职日期等）
35. - 合同公司
36. - 岗位、职位信息
37. - 工作经历
38. - 其他详细属性
40. **适用场景**:
41. - 查询某部门所有在职员工详细信息
42. - 生成员工花名册报表
43. - 需要完整员工档案的业务场景
45. **示例**:
46. QueryParam param = new QueryParam();
47. param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
48. param.setOrgId(orgId);
49. List<EmployeeDetail> employees = employeeService.queryEmployeeRoster(param);
51. ---
53. ### 2. 查询员工变动时间轴
55. **方法**: `queryEmployeeChangesTimeline(Long employeeId, LocalDate startDate, LocalDate endDate)`
57. **功能**: 查询员工在指定时间周期内的组织、岗位、职务变动历史。
59. **返回内容**:
60. - 时间轴形式的变动记录
61. - 每次变动的生效时间
62. - 变动前后的对比信息（组织/岗位/职务）
64. **适用场景**:
65. - 查看员工晋升/调岗历史
66. - 员工职业发展轨迹分析
67. - 绩效评估时查看岗位变动情况
69. **示例**:
70. Long employeeId = 12345L;
71. LocalDate start = LocalDate.of(2024, 1, 1);
72. LocalDate end = LocalDate.of(2025, 12, 31);
73. List<EmployeeChangeEvent> timeline = employeeService.queryEmployeeChangesTimeline(employeeId, start, end);
75. ---
77. ### 3. 查询员工基础列表
79. **方法**: `listEmployees(QueryParam param)`
81. **功能**: 快速查询员工列表，仅返回基础信息和工作信息，不包含附加属性。
83. **返回内容**:
84. - 员工基础信息（工号、姓名、状态）
85. - 工作信息（部门、岗位、入职日期）
86. - 不包含：合同详情、工作经历等附加信息
88. **适用场景**:
89. - 下拉列表/选择器中的员工选项
90. - 快速列表展示
91. - 性能敏感的批量查询
93. **示例**:
94. QueryParam param = new QueryParam();
95. param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
96. List<EmployeeBasicInfo> employees = employeeService.listEmployees(param);
98. ---
100. ## 方法选择指南
102. | 场景 | 推荐方法 | 原因 |
103. |------|---------|------|
104. | 需要完整员工档案 | queryEmployeeRoster | 包含所有关联属性 |
105. | 查看员工晋升调岗记录 | queryEmployeeChangesTimeline | 时间轴形式展示变动 |
106. | 下拉选择器/快速列表 | listEmployees | 轻量级，性能好 |
107. | 生成详细报表 | queryEmployeeRoster | 数据最全面 |
108. | 批量查询员工基本信息 | listEmployees | 避免冗余数据 |
110. ---
112. ## 使用示例
114. ### 示例 1: 查询某部门在职员工
116. // 查询技术部所有在职员工的详细信息
117. QueryParam param = new QueryParam();
118. param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
119. param.setOrgId(techDepartmentId);
120. List<EmployeeDetail> employees = employeeService.queryEmployeeRoster(param);
122. ### 示例 2: 查询员工岗位变动历史
124. // 查询张三在 2025 年的岗位变动情况
125. Long zhangSanId = 10086L;
126. LocalDate yearStart = LocalDate.of(2025, 1, 1);
127. LocalDate yearEnd = LocalDate.of(2025, 12, 31);
128. List<EmployeeChangeEvent> changes = employeeService.queryEmployeeChangesTimeline(zhangSanId, yearStart, yearEnd);
130. ### 示例 3: 获取在职员工列表（轻量级）
132. // 获取所有在职员工的基础信息用于下拉选择
133. QueryParam param = new QueryParam();
134. param.setEmployeeStatus(EmployeeStatus.ON_BOARD);
135. List<EmployeeBasicInfo> employees = employeeService.listEmployees(param);
137. ---
139. ## 注意事项
141. 1. **数据权限**: queryEmployeeRoster 支持数据权限控制，自动过滤当前用户无权访问的员工
142. 2. **性能考虑**: 大批量查询时优先使用 listEmployees，避免查询冗余数据
143. 3. **时间范围**: 查询时间轴时建议限制合理的时间范围，避免返回过多历史数据
144. 4. **状态过滤**: 建议明确指定员工状态，避免查询到不需要的离职员工

复制代码

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

git workflow Skill涵盖代码审查、自动生成commit信息、提交规范、MR管理等完整的工作流。
[code]---name: git-workflowdescription: 完整的 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 命令严禁执行，除非用户明确要求并再次确认：**###
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

谢谢分享，试用一下

新版吗？好像是停更了吧。