前两天刷掘金，看到一篇名为： 2025 Vibe Coding 元年：AI 编程的技术突破全景 的文章，这篇文章不仅详细剖析了近来编程领域可能的发展趋势，还意外地让我接触到了两个新的概念：
Spec（规范）和Skills（技能）。在AI飞速发展的今天，这两个概念的引入显得尤为重要，它们不仅预示着编程规范的进一步标准化，也为技能提升提供了全新的路径。为了进一步理解这两个概念的实际应用，我动手进行了实践操作，下面就是我对这次探索的总结与思考。
或许我们可以实现：赋能 20%的的重要环节，提升整体 80%的效能？？？
一、你在用什么编辑器？
我的
AI编辑器在今年一年内就换了三个，最开始是VScode， 然后是Trae，现在使用的是Kiro，这一个月使用下来，还是蛮顺滑的，推荐 👍。
作为claude模型的金主，亚马逊的 kiro拥有claude 的最新模型:
有资料显示：截至2026年1月，亚马逊已向
Anthropic（开发Claude人工智能模型的公司）累计投资80亿美元（2023年9月首投12.5亿，2024年3月追加27.5亿，2024年11月再投40亿）
下面的示例都是基于这个Kiro 编辑器，当然其他编辑器也有类似的功能，就需要自行探索了，工具本身就是服务于我们的工作，使用什么工具更顺手就用哪个喽！
二、先来了解几个常用的概念
Spec和 Skills 的关系
1. Spec标准性能评估组织，负责解释： 做什么事？
核心理念 ：采用"先计划，后执行"的流程，要求AI在编写代码前，先将任务理解、技术方案和详细拆解形成结构化文档（Doc和Tasks），经人工确认后再生成代码。
主要作用：将传统"黑盒直出"的编码模式变为"白盒化"阶段流程，通过引入"需确认"的缓冲阶段，大幅减少因理解偏差导致的无效工作和返工，提升代码生成的准确性。
适用场景：适用于从0到1的开发、技术方案原型产出、团队内部跨角色（如产品、前后端）沟通协作等场景。
就像项目需求文档、任务清单，大白话讲：就是你给我一个文件，告诉我这个项目怎么做
2. Skills 中文解释"技能"，就是教我"怎么做事"的规则手册。
就像我每次和
AI对话时，总有一些特定的规则前提，不同的规则对应不同的prompt，根据关键词来触发我使用哪个内置的prompt，也可以设置每次对话都引入，比如下图：
3. 两者的关系
类比 1: 做菜 🍳
关系：用烹饪技巧（Skills）来完成菜谱（Spec） 一个技巧可以用在很多菜谱上，一个菜谱需要用到多个技巧
类比 2: 盖房子 🏗️
关系： 按照施工规范（
Skills）来实现建筑图纸（Spec） 规范是通用的，可以盖很多房子 图纸是具体的，只针对这一栋房子
4. 实际的工作流程-理论
假设场景：我们要开发字母拼写游戏
1. 你有一个 Spec（需求文档）📋 "创建字母拼写游戏"
- 需要游戏组件
- 需要游戏接口
- 需要状态管理
2. 我使用 Skills（规则）来实现
创建组件时 → 应用 "React 组件生成 Skill"
✅ 按规范创建文件结构
✅ 按模板生成代码
✅ 遵循命名规范
添加接口时 → 应用 "API 接口生成 Skill"
✅ 检查是否重复
✅ 添加类型定义
✅ 添加完整注释
完成后 → 应用 "代码检查 Skill"
✅ 检查逻辑问题
✅ 检查性能问题
✅ 检查是否有重复代码
3. 完成 Spec✅ 字母拼写游戏开发完成 📊 对比表格
| 维度 | Skills（技能） | Spec（规格） |
|---|---|---|
| 是什么 | 做事的方法 | 要做的事情 |
| 作用 | 教我怎么做 | 告诉我做什么 |
| 范围 | 通用的 | 具体的 |
| 时效 | 长期有效 | 一次性的 |
| 数量 | 少量（3-10个） | 很多（每个功能一个） |
| 位置 | .kiro/steering/ | .kiro/specs/ |
| 例子 | "组件创建规范" | "创建登录页面" |
| 复用 | 可以复用到其他项目 | 只针对当前功能 |
三、下面就让我们用实际的AI编辑器来试试上面能力-实践：
在上面我们讨论了他们之间的关系，并使用示例图的形式展现出来，下面就是具体的实践示例。
首先是-省流最小示例：
bash
.kiro/steering/
├── react-component-generator.md ← "怎么创建组件"
├── api-service-generator.md ← "怎么添加接口"
└── code-review.md ← "怎么检查代码"
Spec 的例子（具体需求）
.kiro/specs/
└── letter-spelling-game/
└── requirements.md ← "做一个字母拼写游戏" 接下来是使用Kiro的具体操作演示步骤：
1. 先来看 Spec
（1）发送指令前，先选择Spec模式：
（2）提出我的需求
prompt: 我想创建一个课堂互动小游戏，根据字母拼单词，帮我实现。
（3）生成具体的需求文档
提交提示词，生成具体的需求文档：
生成完成：
下面的文档我只截取了头部和尾部的部分，大家可以自己动手尝试一下：
shell
# 需求文档
## 简介
课堂拼写游戏是一个教育类互动应用，旨在帮助学生通过游戏化的方式学习和练习英语单词拼写。系统会提供一组打乱顺序的字母，学生需要将这些字母重新排列组成正确的单词。
## 术语表
- **游戏系统（Game_System）**: 管理游戏流程、题目生成和答案验证的核心系统
- **题目（Question）**: 包含目标单词和打乱字母的游戏问题
- **单词库（Word_Bank）**: 存储可用于游戏的单词集合
- **学生（Student）**: 参与游戏的用户
- **回合（Round）**: 一次完整的答题过程，从显示题目到提交答案
- **得分系统（Scoring_System）**: 计算和记录学生表现的系统
## 需求
### 需求 1：题目生成
**用户故事：** 作为教师，我希望系统能够自动生成拼写题目，以便学生进行练习。
#### 验收标准
1. 当游戏开始时，游戏系统应当从单词库中随机选择一个单词
2. 当选择单词后，游戏系统应当将单词的字母打乱顺序
3. 当打乱字母时，游戏系统应当确保打乱后的字母顺序与原单词不同
4. 当生成题目时，游戏系统应当同时保存原始单词作为正确答案
### 需求 2：答案提交与验证
**用户故事：** 作为学生，我希望能够提交我的答案并立即知道是否正确，以便获得即时反馈。
#### 验收标准
1. 当学生输入答案时，游戏系统应当接受字母输入
2. 当学生提交答案时，游戏系统应当验证答案是否与正确单词完全匹配
3. 如果答案正确，那么游戏系统应当显示成功提示并增加得分
4. 如果答案错误，那么游戏系统应当显示错误提示并允许重试
5. 当验证答案时，游戏系统应当忽略大小写差异
..................
..................
..................
### 需求 12：响应式设计
**用户故事：** 作为教师，我想要游戏在不同设备上都能正常显示，以便在各种教学环境中使用。
#### 验收标准
1. 当游戏在大屏幕显示时（1920x1080或更高），游戏系统应当优化布局以充分利用屏幕空间
2. 当游戏在平板设备显示时，游戏系统应当调整字母按钮大小和间距以适应触摸操作
3. 当游戏在小屏幕设备显示时（手机），游戏系统应当采用垂直布局并调整字体大小
4. 当屏幕方向改变时，游戏系统应当在500毫秒内重新布局界面元素
5. 当游戏系统检测到触摸设备时，游戏系统应当增大可点击区域至少44x44像素以符合可访问性标准（4）根据自己的需求进行微调
现在我们已经有了一个完整的需求文档以及具体的生成规则和验收流程，我们需要根据自己的具体需求进行调试，假设你还有其他的需求，也可以再添加到文档中，目的是为后续生成
code提供一个标准和依据。
然后我们就看到有一个这个 "Move to design phase" 意思就是进入设计阶段：
（5）Move to design phase 进入设计阶段
现在它帮我生成了一个项目设计文档：
详细内容如下，当然在此步骤你依然可以对文档进行修改：
php
# 设计文档
## 概述
课堂拼写游戏是一个基于 Web 的互动教育应用，采用客户端-服务器架构。系统的核心功能包括：随机生成拼写题目、验证学生答案、管理单词库、跟踪学习进度。设计强调简洁性、可扩展性和教育效果。
## 架构
系统采用三层架构：
1. **表示层（Presentation Layer）**: 负责用户界面渲染和用户交互
2. **业务逻辑层（Business Logic Layer）**: 处理游戏逻辑、答案验证、得分计算
3. **数据访问层（Data Access Layer）**: 管理单词库和用户数据的持久化
### 架构图
┌─────────────────────────────────────┐
│ 表示层 (UI Components) │
│ - 游戏界面 │
│ - 单词库管理界面 │
│ - 得分显示 │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ 业务逻辑层 (Game Engine) │
│ - QuestionGenerator │
│ - AnswerValidator │
│ - ScoringSystem │
│ - HintProvider │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ 数据访问层 (Data Layer) │
│ - WordBankRepository │
│ - ScoreRepository │
│ - LocalStorage / Database │
└─────────────────────────────────────┘
## 组件和接口
### 1. QuestionGenerator（题目生成器）
负责从单词库中选择单词并生成打乱字母的题目。
**接口：**
```typescript
interface QuestionGenerator {
// 根据难度级别生成新题目
generateQuestion(difficulty: DifficultyLevel): Question
// 验证生成的题目是否有效
validateQuestion(question: Question): boolean
}
**核心方法：**
- `selectWord(difficulty: DifficultyLevel): string` - 根据难度从单词库随机选择单词
- `shuffleLetters(word: string): string` - 打乱单词字母顺序
- `ensureDifferent(original: string, shuffled: string): string` - 确保打乱后与原单词不同
### 2. AnswerValidator（答案验证器）
验证学生提交的答案是否正确。
**接口：**
```typescript
interface AnswerValidator {
// 验证答案是否正确（忽略大小写）
validate(userAnswer: string, correctAnswer: string): boolean
// 验证输入是否只包含字母
validateInput(input: string): boolean
}
**核心方法：**
- `normalize(text: string): string` - 标准化文本（转小写、去空格）
- `isAlphabetic(text: string): boolean` - 检查是否只包含字母
### 3. ScoringSystem（得分系统）
计算和管理学生得分。
**接口：**
```typescript
interface ScoringSystem {
// 计算答题得分
calculateScore(isCorrect: boolean, hintsUsed: number, timeSpent: number): number
// 更新总分
updateTotalScore(score: number): void
// 获取当前统计信息
getStatistics(): GameStatistics
}
**得分规则：**
- 基础分：正确答案 10 分
- 提示惩罚：每使用一次提示减 2 分
- 时间奖励：快速答题（< 10 秒）额外 +3 分
- 最低分：每题最低 1 分
..........（6）生成测试任务列表
现在有两个选项，一个是保持可选任务（更快的MVP），我选择的是： "将所有任务设为必须"
（7）任务完成
此时我们需要的需求文档，设计文档和测试文档都已经全了，里面告诉我们接下来项目具体细节是啥，那么后面我们就可以拿着这些文档喂给我们的项目，让他去设计页面了～
总结：
以上就是Spec的整个流程，以我的使用感受来看，这个Spec比较适用于从头开始的新项目，或者是从头开始一个完整的新需求，如果你是只是修修补补，还是建议使用Vibe模式，更轻便，更简洁。
2. 接下来是Skills
（1）手动创建定制化于自己项目的skill
我让
Kiro帮我生成一个关于接口API接入的编写规范
这就是根据我当前项目全面扫描后，根据以后的规则生成的一个接偶编写规范
如果你有自己的规则，可以添加新的规则到这个文档中：
如下，我需要添加关于重复接口的检查
更新后的结果：
发起思考？？？
除了添加AI接口规范文档，我们想想平常自己哪方面的工作比较耗费时间，并且大部分是有一定规则，我们就可以通过skill的方式，一次性让AI了解我们的复杂的诉求，比如："代码优化"、"创建新组件" "原型还原" 都可以是一套完整的规则，且也可以随着使用来完善你的规则，渐进明细，让他成为一个你靠谱的工作伙伴。
除了可以自己创建，现在市场上也有很多开源的Skills，可以供大家选择：
除了工作需要，例如我们需要一个生成旅游攻略，我的要求如下：
我想生成一个旅游攻略的skill，根据我的输入城市，推荐该城市或者这个城市周边的5个景点，景点可以是： 古建筑、 博物馆、 非物质文化遗产 、遗址 、 著名的4A景点 或者是 老街 、 民俗、演出、大型文艺园区（例如：吴桥杂技大世界）、大型的情景剧演出 以及和人文相关的等 ， 给出景点附近的华住集团的酒店参考，给3个，给出景点和景点之间的距离，单位km， 我默认是从北京自驾出发，如果行程过远（超过600km) ,提醒我是否要更换交通工具，如果筛选出的景点，在当前的时间季节不是最好的季节，或者可能不开放，也请提示我是否更换景点，或者更换城市，生成后，我可以根据自己的想法，再进行修改：
帮我更新这个skill ，如果我提出去 某个城市旅游，请提问我旅游的天数，以及每天推荐一款该城市的著名小吃，或者 这个城市的主打的小吃，我刚刚添加了一些常住的酒店，帮我一起更新下面是我生成的skill的.md文件：
yaml
---
inclusion: manual
---
# 🗺️ 人文旅游攻略生成器
**触发条件：提示词包含"旅游"、"攻略"、"景点"、"出行"、"自驾"等关键词，或直接输入城市名称**
## 基本设定
- 出发地：北京（默认自驾）
- 当前日期：根据实际日期判断季节
- 旅游天数：**需先询问用户**
- 景点数量：根据天数动态调整（每天1-2个景点）
- 酒店品牌：华住集团旗下（全季、汉庭、桔子、水晶、CitiGO、漫心、花间堂、海友、禧玥等）
- 每个景点推荐3个附近华住酒店
- 每日小吃：每天推荐1款当地著名小吃或主打美食
## 景点筛选范围
优先推荐以下类型的人文景点（非自然风光类）：
1. **古建筑**：古城、古镇、寺庙、祠堂、城楼、古塔等
2. **博物馆**：省级/市级博物馆、专题博物馆、纪念馆等
3. **非物质文化遗产**：传统技艺体验地、非遗展示馆等
4. **历史遗址**：古战场、古都遗址、考古遗址公园等
5. **4A/5A景区**：以人文类为主的高等级景区
6. **老街/古街**：历史文化街区、传统商业街等
7. **民俗体验**：民俗村、传统集市、地方特色活动等
8. **演出/剧场**：大型情景剧演出、实景演出（如《又见平遥》《印象系列》）
9. **大型文艺园区**：吴桥杂技大世界、横店影视城等主题文化园区
10. **其他人文景点**：名人故居、革命纪念地、宗教文化场所等
## 输出格式
```markdown
# 🗺️ [城市名] 人文旅游攻略
📍 出发地：北京
🚗 交通方式：自驾（或建议更换的交通方式）
📅 出行日期：[当前日期]
🌤️ 当地季节/天气提示：[季节信息]
---
## ⚠️ 出行提醒（如有）
> [距离超过600km的提醒]
> [季节/开放时间提醒]
---
## 📋 景点总览
| 序号 | 景点名称 | 类型 | 距北京(km) | 景点间距(km) |
|------|---------|------|-----------|-------------|
| 1 | xxx | xxx | xxx | - |
| 2 | xxx | xxx | xxx | 距景点1: xx |
| 3 | xxx | xxx | xxx | 距景点2: xx |
| 4 | xxx | xxx | xxx | 距景点3: xx |
| 5 | xxx | xxx | xxx | 距景点4: xx |
---
## 🏛️ 景点详情
### 1. [景点名称]
- **类型**：古建筑 / 博物馆 / 非遗 / 遗址 / 4A景区 / 老街 / 民俗 / 演出 / 文艺园区
- **地址**：xxx
- **门票**：xxx元（或免费）
- **开放时间**：xx:xx - xx:xx
- **推荐游览时长**：x小时
- **亮点**：一句话描述核心看点
- **季节提示**：⚠️（如当前季节不适宜或可能不开放，给出提示）
**🏨 附近华住酒店推荐：**
| 酒店名称 | 品牌 | 距景点(km) | 参考价格 |
|---------|------|-----------|---------|
| xxx | 全季/汉庭/桔子等 | x.x | ¥xxx/晚 |
| xxx | xxx | x.x | ¥xxx/晚 |
| xxx | xxx | x.x | ¥xxx/晚 |
---
（景点2-5 同上格式）
---
## 🛣️ 推荐行程路线
**Day 1**：北京出发 → 景点1 → 景点2
🏨 住宿：xxx酒店（品牌 | ¥xxx/晚）
🍜 今日小吃：**[小吃名称]** --- [一句话介绍，如"西安回民街必吃，皮薄馅大汤汁鲜"] | 📍 推荐店铺：[店名]
**Day 2**：景点3 → 景点4
🏨 住宿：xxx酒店（品牌 | ¥xxx/晚）
🍜 今日小吃：**[小吃名称]** --- [一句话介绍] | 📍 推荐店铺：[店名]
**Day 3**：景点5 → 返程
🍜 今日小吃：**[小吃名称]** --- [一句话介绍] | 📍 推荐店铺：[店名]
...........现在我们来尝试一下这个旅游的skill:
确实跟我自己搜索的差不多，除了清真寺和纪晓岚文化园我没有计划在内，其他几个还是值得一去的！内容确实包含了我需要的具体的景点信息，酒店信息，美食推荐以及景点和景点的相差公里等方面，还算符合我的要求，后面可以再根据自己的喜好调整即可，基本上是直接可用的状态。
回归主题，接下来我们看一下在工作中怎么配置？
你想让这个skill在什么时候加载？
1. 始终加载（默认，每次对话自动加载，不需要关键词）
yaml
inclusion: always什么时候生效？
- 你在聊天框里问
AI任何问题 - 你让
AI帮你写代码、改代码 - 你让
AI解释某段代码 - Hook 触发后
AI开始工作（因为Hook本质也是一次对话） - 你用
Spec让AI帮你做功能设计和实现
换句话说，任何你和
AI之间的交互，AI都会带着这些规则。它不是一个检查动作，而是AI的"常识大脑🧠"。
2. 匹配文件时加载
vbnet
inclusion: fileMatch
fileMatchPattern: "src/services/**/*.ts"什么时候生效？
只有当对话中涉及到匹配的文件时，AI 才能看到。比如你可以设置只有读取 services/**/*.ts 文件时才注入 xxxxx 规则
3. 手动引用时加载（聊天中用 # 引用）
makefile
inclusion: manual什么时候生效?
你在聊天框里用 # 手动引用时才注入
那么此时又有一个问题：如果我是自己手动修改的bug，并没有使用AI，但我又想让他帮我检查一下，我此时要怎么办？
提示词如下：
css
请帮我code-review 当前代码 或者以下几种都可以：
帮我检查代码 / 帮我审查代码 / 帮我优化代码这样AI会看你当前激活的编辑器文件（就是你正在看的那个 tab），然后结合 steering 规则来审查。它检查的是那一个文件的全部内容，
那么如果你只想让他检查某个方法或者某个部分，
提示词这样说：
css
帮我 code-review 这个文件的 onMounted 部分那么我想让他帮我精确只检查本次改动的部分，也就是git改动的所有文件，且只检查改动的部分的上下文，（虽然问题比较苛刻，但是有真实使用场景的，哈哈哈哈😂 ），那么提示词可以这样说：
css
帮我 code-review，用 git diff 查看本次改动，只检查我修改的部分和上下文，不要动没改的代码，有问题直接修现在这样写提示词好长，每次都要写这么长好麻烦，那么我能点个按钮，就实现这个能力不？
结论是： 当然可以下面引入一个新东西：Hooks
四、 什么是Hooks ?
Kiro的Hooks是一种自动化机制 --- 当IDE里发生特定事件时，自动触发AI执行某个动作。你可以把它理解为"事件监听器"。
1. 工作原理
一个 Hook 由两部分组成：
-
when（触发条件）：什么时候触发？比如你保存了一个文件、创建了新文件、提交了消息等 -
then（执行动作）：触发后做什么？比如让AI帮你检查代码、或者跑一个命令
2. 支持的触发事件
fileEdited--- 你保存文件时触发fileCreated--- 你创建新文件时触发fileDeleted--- 你删除文件时触发promptSubmit--- 你在聊天框发消息时触发agentStop---AI执行完任务后触发userTriggered--- 你手动点击按钮触发
3. hook规则文件的位置：
json
{
"enabled": true,
"name": "hook的名字", // 它的名字
"description": "描述", // 这里是你对于当前hook 的规则描述
"version": "1",
"when": {
"type": "userTriggered" // 触发时机：手动触发
},
"then": {
"type": "askAgent",
"prompt": "你可以自己写你的规则" // 这里是你触发它的规则，比如你让让他按照什么规则做什么
}
}举个例子🌰：
比如你想实现"每次保存
.vue或.ts文件时，AI自动按照你的code-review-checklist检查代码并修复问题"，Hook长这样：
json
{
"name": "代码审查",
"version": "1.0.0",
"description": "保存文件时自动按照审查规范检查代码问题并修复",
"when": {
"type": "fileEdited",
"patterns": ["**/*.vue", "**/*.ts"]
},
"then": {
"type": "askAgent",
"prompt": "检查刚刚编辑的文件，按照 code-review-checklist 中的规范，重点检查：1. 定时器是否在 onUnmounted 中清除 2. 异步请求是否有 try-catch 3. 是否存在内存泄漏风险 4. 是否有防重复提交机制。如果发现问题，直接修复。"
}
}
4. 如何触发：
这个
Hook的效果就是：你每次保存.vue或.ts文件，AI会自动读取你改的文件，按照你项目里已有的审查规范检查，发现问题就帮你修。
再举个例子来callback上面的问题🌰：
我想要真正写完一个功能后，在提交
git仓库前再检查，也就是上面的问题：我们想在完成了一段工作后，进行阶段性的检查，且不要全文检查，只针对修改部分的上下文，且实现只是点点按钮就能检查。
配置规则如下：
swift
{
"enabled": true,
"name": "代码审查与修复",
"description": "手动触发，按照 code-review-checklist 规范检查当前打开的文件，发现问题直接修复",
"version": "1",
"when": {
"type": "userTriggered"
},
"then": {
"type": "askAgent",
"prompt": "执行以下步骤：\n\n1. 运行 `git diff` 获取本次所有未提交的改动\n2. 只关注我修改的代码及其上下文（修改行的前后相关逻辑），不要审查文件中未改动的部分\n3. 对每个改动，按照 code-review-checklist.md 规范检查：\n - 新增的 setInterval/setTimeout 是否有对应的清除\n - 新增的异步请求是否有 try-catch 和 loading 状态管理\n - 新增的 watch 是否有防重复机制\n - 修改部分是否存在空值风险（缺少可选链、数组判空等）\n - 新增的按钮事件是否有防重复提交\n - 修改部分的状态管理是否一致\n4. 只报告和修复改动部分引入的问题，已有代码即使不完美也不要动\n5. 修复后简要说明：改了哪个文件的哪部分、问题是什么、怎么修的"
}
}相比上面的自动规则，这个手动的hook如何触发？：
在
Kiro编辑器的最左侧找到这个方框中的图标，点击后找到你的Hooks列表，在列表里找到你想要执行的hook，点击右侧的执行按钮即可解放双手！
触发后它会变成一个执行中的状态：
执行结束：
小结：
现在是不是有种解放双手的快感？😂 我们用
Skills和Hook联动，实现AI写代码自动检查是否符合我们的规范，在提交代码前检查当前的修改是否会对原逻辑造成伤害，大大减少了bug的产出。
关于AI你有哪些好用的工具也欢迎评论区留言，一起来探索！