同一个需求跟 AI 说了 N 遍？30 秒，让它变成一个 Skill

“重复的活儿，说一遍就该被记住！”

程序员和 AI 打交道，最耗时间的往往不是写代码，而是「对齐需求」。同一套代码审查标准说一遍、同一个项目技术栈约束说一遍、同一份回复格式要求再说一遍——说完了，换一个会话，又回到原点。

技能（Skill）就是干这个的：把你反复交代的规则、标准、流程，固化成 AI 一看就懂的指令文件。以后只要一句话，AI 自动按你的规矩办事。而创建它的成本，低到超出你的想象——30 秒。

01 别再把同一句话，说第二遍

仔细想想，「对齐需求」这件事，本质上是把同一套标准反复灌输给 AI。说完了，换一个会话，又回到原点——这不是你的问题，而是缺少沉淀机制。

技能（Skill）就是干这个的：把规则、标准、流程固化成一个指令文件。以后只要一句话，AI 自动按你的规矩办事。

02 三步走：30 秒生成一个技能

STEP 01 发起创建指令
在对话输入框「添加指令」上，选择 /创建技能，然后在描述里输入指令。如果你心里已经有目标，也可以直接描述，比如「创建一个代码审查技能」。

STEP 02 回答引导问题
AI 会像面试官一样，一条一条地问你需求：技能叫什么？用在什么场景？要遵守哪些约束？输出格式是什么？大部分问题都有预设选项，点选即可；没有想要的答案，在最后一项输入自定义内容再选择「自定义」就行。这一问一答，就是 AI 在帮你把模糊的想法翻译成结构化的技能需求，你只管回答，不用懂任何语法。

STEP 03 自动生成 SKILL 文件
问答全部完成后，模型会自动生成完整的技能文件。生成后随时可以打开查看，想调整细节（改措辞、加约束、换示例）直接改，改完继续用。从开始到结束，快的场景真的只要几十秒——以往手写一个像样的技能文档，光想结构和措辞就要半小时起步。

“把重复的规矩交给技能，把创造力留给自己。”

03 技能存在哪里：两个作用域

项目技能
存在当前项目的 .feisuan/skills 目录下，只在当前项目生效。

全局技能
存在用户目录的 .feisuan/skills 文件夹下，所有项目都能用。

两个作用域怎么选？看你的目的：

需求类型	建议作用域	典型内容
个人/团队通用习惯	全局	统一代码风格、命名规范、回复结构
通用工程能力	全局	Git、CI/CD、测试框架工具链用法
项目专属业务规则	项目	业务约束、内部术语、技术栈限制
项目开发协作	项目	测试、Mock、脚手架生成

如果全局技能和项目技能都命中了同一个任务，且名称一致，飞算JavaAI 会优先使用项目技能。

04 创建之后，怎么用

技能创建好，不代表每次都要手动点名，它的触发方式很自然：

自动匹配
你正常提问，AI 扫描技能简介，发现任务和某个技能高度相关，就会自动加载执行——你甚至感觉不到「技能」的存在。

显式点名
想指定用某个技能时，直接使用快捷方式选中这个技能，AI 就会定向加载。

判断技能有没有生效，看输出就行：如果这次回复明显「懂规矩」了——格式是你定的、步骤是你定的、约束都遵守了——那就是技能在起作用。

05 不满意怎么办？直接改文件

技能本质就是文本文件，找到对应 SKILL.md，改措辞、加约束、换示例，改完保存，下次使用立即生效。整个过程不用重启、不用重新创建，迭代成本几乎为零。

这也是技能和「死记硬背的提示词」最大的区别：它是可查看、可编辑、可分享的资产，而不是锁在对话记录里的一段话。

06 SKILL 文件长什么样

结构很清晰，就是一个带 YAML 头部的 Markdown 文件：

---
name: my-skill
description: 用一句话说明这个技能的功能和使用场景
allowed-tools: Bash Read Edit
license: MIT
---

必填的就两个字段：name（技能名称）和 description（功能简介——AI 靠它来匹配要不要加载你）。

allowed-tools 是可选但很实用的字段：空格分隔的预批准工具列表，比如允许技能使用 Bash（运行命令）、Read（读文件）、Edit（改文件）。相当于给技能划定了「活动范围」。

正文部分，一个标准的 SKILL.md 通常包含四块：

1. 描述：这个技能是干什么的
2. 使用场景：什么情况下触发
3. 指令：清晰的分步说明，告诉 AI 具体怎么做
4. 示例（可选）：输入/输出示例，展示预期效果

除了 SKILL.md，技能目录下还可以放配套文件：

skill-name/
├── SKILL.md　# 必须：智能体的核心指令
├── examples/　# 可选：输入/输出示例
├── templates/　# 可选：可复用的模板
└── resources/　# 可选：参考文件、脚本或素材

光说结构有点抽象，看一个真实的「代码审查」技能就懂了。它的 SKILL.md 大致是这么写的：

---
name: code-review
description: 扮演资深代码检查专家，对代码变更进行多维度
（安全、逻辑、性能、风格）的系统化审查，并输出结构化报告。
适用于代码提交前检查、MR/PR 评审等场景。
---

## 指令

1. 理解上下文：先读 MR/PR 描述，明确业务目标
2. 多维度审查，按优先级：
  - 安全性（最高）：注入风险、敏感信息泄露、权限缺失
  - 逻辑正确性：空指针、边界条件、并发安全
  - 性能：N+1 查询、资源泄漏、冗余计算
  - 代码质量：命名、重复、函数复杂度
3. 整合报告，严格按输出规范输出

### 输出规范

- P0 严重问题：必须修复（安全漏洞、严重逻辑错误）
- P1 重要问题：建议修复（性能隐患、代码异味）
- P2 建议：可选优化方向
- 亮点：值得肯定的设计

看到没？把「怎么审查代码」这件事，用结构化的方式固化成了 AI 的肌肉记忆。以后每次提交代码前，一句「帮我 review 一下」，出来的报告永远是同一套格式、同一个标准。

而在飞算 JavaAI 里，你不需要手写这些——问答式创建会自动帮你生成，生成后不满意再微调，比自己从零写省太多事。

07 把技能用起来的三个进阶姿势

创建技能只是开始，真正拉开差距的是怎么用它。

姿势一：把个人偏好固化成全局技能
比如你习惯「先结论、后展开、再给示例」的输出方式；比如你要求所有代码必须带注释、必须符合某套命名规范。把这些固化成全局技能，以后不管开哪个项目，AI 都懂你的规矩，不用每句话都叮嘱一遍。

姿势二：把项目规则注入项目技能
团队有业务边界、有内部术语、有架构约束？写成项目技能放进 .feisuan/skills，AI 在这个项目里就「懂规矩」——技术栈不会用错，业务概念不会混淆，生成的代码天然符合团队约定。

姿势三：去技能市场逛逛
不想从零建？技能市场里有现成的技能可以直接装，装完即用。把团队里优秀的技能沉淀下来、分享出去，还能在更大范围内复用——一个人的经验，变成一群人的能力。

08 别让重复劳动，消耗你的创造力

把标准交给技能，把规范交给技能，把重复交给技能——你只需要专注那些真正需要创造力的部分。

下次遇到「每天都干一遍」的活儿，别犹豫：使用飞算JavaAI，30 秒，生成一个 Skill。