在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 SkillDao Skill实现创建表、增加字段、删除字段提供通用的查询方法拓展查询参数。定义如下---name: springboot-jpa-daodescription: 专注于 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.javaparam/ # 查询参数 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)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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 | List types || name, title | LIKE 查询模糊匹配 | String | String name || *Time, *At, *Date | BETWEEN 查询范围 | 两个参数 | Long startCreatedAt, Long endCreatedAt |### 2.4 生成通用查询方法## 功能三为已有表增加或删除字段### 3.1 增加字段#### 输入示例用户请求为 Product 表增加字段供应商IDsupplierId、商品描述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.mdcJava 领域实体类生成与注释规范请在生成代码时始终遵循这些规范。以上内容基本完整定义了 Dao Skill 的使用场景、实现要求以及代码模板结构。文中对部分模板代码和具体场景做了适当省略以突出整体设计思路。当使用场景较为复杂时建议对功能进行进一步拆分形成独立的子功能文档例如功能1.md、功能2.md。再由 SKILL.md 根据不同条件引入对应的子功能文档。同样地如果示例代码体量较大也建议按照功能或业务场景拆分到不同的 Template 文件中再统一由 SKILL.md 进行引用和组织。基础service Skill对于任何系统而言都可以抽象出一层其核心依赖的基础数据模型。例如在 EHR 系统中最核心的基础数据通常就是员工Employee和组织Org。下游绝大多数业务逻辑都是基于这两类基础数据进行加工、组合与汇总而形成的。同时这类基础能力通常具有相对稳定、变更频率低的特点。因此在系统架构设计中将其沉淀为基础 Service 是一种非常自然且合理的选择。对于 EHR 场景而言EmployeeService 和 OrgService 就非常适合定位为基础 Service。下面我们将以 EmployeeService 为例说明如何定义一个基础 Service 类型的 Skill。---name: employee-querydescription: 员工查询基础服务。提供员工花名册查询、员工时间轴变动查询、员工基础列表查询能力。用于查询员工信息、员工状态、组织变动、岗位变动等场景。---# 员工查询基础服务 (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);---## 注意事项1. **数据权限**: queryEmployeeRoster 支持数据权限控制自动过滤当前用户无权访问的员工2. **性能考虑**: 大批量查询时优先使用 listEmployees避免查询冗余数据3. **时间范围**: 查询时间轴时建议限制合理的时间范围避免返回过多历史数据4. **状态过滤**: 建议明确指定员工状态避免查询到不需要的离职员工从工程实现角度看这类基础 Service 更适合被定义为一份标准化接口能力文档用于明确描述方法能力边界、参数结构以及返回信息语义从而让 AI 能够在合适的场景下正确调用对应能力。git workflow工作流git workflow Skill涵盖代码审查、自动生成commit信息、提交规范、MR管理等完整的工作流。---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 命令严禁执行除非用户明确要求并再次确认**### ?? 绝对禁止的操作#### 1. 删除分支# 禁止删除本地分支git branch -dgit branch -D# 禁止删除远程分支git push origin --deletegit push origin :#### 2. 强制推送# 禁止强制推送到任何分支git push --forcegit push -fgit push --force-with-lease # 除非用户明确要求#### 3. 硬重置导致数据丢失# 禁止硬重置git reset --hardgit reset --hard HEAD~1# 禁止重置到远程分支git reset --hard origin/main#### 4. 修改历史记录# 禁止交互式变基git rebase -i# 禁止修改已推送的 commitgit commit --amend # 如果已推送禁止git rebase # 如果已推送禁止#### 5. 删除未提交的修改# 禁止丢弃所有修改git checkout -- .git restore .# 禁止清理工作目录git clean -fdgit clean -fdx#### 6. 修改远程仓库配置# 禁止修改远程仓库地址git remote set-url origin# 禁止删除远程仓库git remote remove origin#### 7. 危险的分支操作# 禁止强制签出丢弃本地修改git checkout -f# 禁止重命名当前分支git branch -m # 需谨慎# 禁止切换到游离 HEAD 状态git checkout # 除非用户明确要求### ? 允许的安全操作以下操作是安全的可以正常执行# 查看类命令只读git statusgit loggit diffgit showgit branchgit remote -v# 安全的添加和提交git addgit commit -m messagegit commit # 打开编辑器# 安全的推送非强制git pushgit push origin# 安全的拉取git pullgit fetch# 安全的分支操作git checkout # 切换到已存在的分支git checkout -b # 创建新分支git merge # 普通合并# 软重置不丢失修改git reset --soft HEAD~1git reset HEAD # 取消暂存### ??? 安全原则1. **只读优先**优先使用只读命令status, log, diff, show2. **确认机制**对于任何可能修改历史或删除数据的操作必须先向用户说明风险并获得明确确认3. **数据保护**永远不主动执行会导致代码丢失的命令4. **非破坏性**优先使用非破坏性的替代方案如 git reset --soft 代替 git reset --hard5. **用户主导**即使用户要求危险操作也要先说明后果建议安全替代方案### ?? 危险操作检查清单执行任何 git 命令前检查- [ ] 这个命令是否会删除任何数据- [ ] 这个命令是否会修改已推送的历史- [ ] 这个命令是否会影响其他人的工作- [ ] 是否有更安全的替代方案- [ ] 用户是否完全理解这个命令的后果**如果任何一项回答是且用户未明确要求则不执行该命令。**---## 工作流 1: 生成 Commit Message### 快速流程当用户请求生成 commit message 时1. **分析变更**git diff --staged2. **生成 Conventional Commits 格式的 message**3.():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 --staged2. **分析变更内容**- 识别变更的文件和模块- 理解代码逻辑变化- 确定变更类型新增/修复/重构等3. **生成 commit message**- **Type**: 根据变更性质选择正确的 type- **Scope**: 使用模块名、文件名或功能域如 auth、user、order- **Subject**: 简洁描述50 字符动词开头不加句号- **Body** (可选): 详细说明变更原因和实现方式- **Footer** (可选): Breaking changes 或关闭的 issue4. **向用户展示并确认**### 示例输出格式feat(employee): add employee roster query APIImplement EmployeeService.queryEmployeeRoster() to support:- Multi-dimension filtering (status, org, position)- Data permission control- Complete employee details with associationsCloses #123---## 工作流 2: 代码审查### 审查检查清单当用户请求代码审查时按以下维度进行#### ? 1. 正确性 (Correctness)- [ ] 逻辑正确符合需求- [ ] 边界条件处理完善- [ ] 错误处理完整- [ ] 空值/null 处理符合规范参考 java-null-safety.mdc- [ ] 参数验证完整参考 java-request-validation.mdc#### ?? 2. 安全性 (Security)- [ ] 无 SQL 注入风险- [ ] 无 XSS 漏洞- [ ] 敏感信息已脱敏- [ ] 权限校验完整- [ ] 密码/密钥未硬编码#### ? 3. 性能 (Performance)- [ ] 避免 N1 查询- [ ] 数据库查询已优化- [ ] 大数据量处理有分页/限制- [ ] 无不必要的循环嵌套- [ ] 缓存使用合理#### ?? 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...HEAD2. **按检查清单逐项审查**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 API2. **生成 PR 描述**## ?? Summary- 简要描述本次 PR 的目的和内容## ?? Changes- 变更点 1- 变更点 2## ?? Test Plan- [ ] 单元测试已通过- [ ] 手动测试场景 1- [ ] 手动测试场景 2## ?? Related IssuesCloses #123## ?? Breaking Changes (if any)- 不兼容的变更说明3. **使用 gh CLI 创建 PR**gh pr create --title 标题 --body 描述### PR 审查清单作为 Reviewer当用户作为 Reviewer 审查 PR 时1. **阅读 PR 描述**理解变更目的2. **运行代码审查工作流**参考工作流 23. **检查测试**- [ ] 是否有对应的单元测试- [ ] 测试覆盖是否充分- [ ] CI 是否通过4. **提供审查意见**使用优先级标记5. **决定是否批准**- 无 ?? Critical 问题 → Approve- 有 ?? Critical 问题 → Request Changes---## 使用示例### 示例 1: 生成 Commit Message**用户**: 帮我生成一个 commit message**Assistant 流程**:1. 执行 git diff --staged2. 分析变更假设添加了员工查询 API3. 生成feat(employee): add employee roster query APIImplement EmployeeService.queryEmployeeRoster() with:- Multi-dimension filtering support- Data permission control- Complete employee details### 示例 2: 代码审查**用户**: 审查一下这个 PR**Assistant 流程**:1. 执行 git diff main...HEAD 或读取 PR diff2. 按检查清单逐项审查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. 执行bashgh 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 管理**: 描述完整测试充分便于 Review4. **项目规范**: 严格遵循项目现有的编码规范和注释规范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 能力的人。对于这些问题我目前也只有一个还不够清晰的答案。如果用一句朴素但真实的话来说就是问题一定存在但解法也一定存在。只是这些解法不会一次性出现而会在一代代工程实践中逐渐成型。这个话题留到以后结合更多实践再与大家分享。航士诵箍