封面图AI Skills 到底是什么？
怎么用？
真的能改变工作流吗？
——能。
大部分人还在把 AI 当聊天框用。
打开一个新对话，贴上同样的上下文，讲同样的规矩，纠正同样的错误，要一份同样的输出——然后明天再来一遍。
做实验的时候，这样没问题。
但靠这个跑需要重复的工作，就是灾难。
真正的下一跳，不是更好的提示词库。
是 Skills。
一个 AI Skill，是一份可复用的工作流——任务对得上的时候，Agent 就能自动加载它。
不是一句神奇的提示词。
不是一种人格预设。
不是一文件夹的含糊指令。
一个真正能用的 Skill，要告诉 Agent：
听起来挺小。
但它彻底改变了 AI 工作的形态。
一、提示词 / Skill / Agent，是三层东西
别把这三层混在一起：
提示词 = 用一次
Skill = 稳定地重复用
Agent = 自主挑选并执行工作流
提示词是一次性指令。
"帮我总结这篇文章。"
Skill 是那条指令背后可以重复的方法。
"把一篇长 AI 文章改写成有源可查的 Zaimiri 风格帖子——选好角度、保留原论点、去掉 AI 味、生成一份 review 草稿。"
Agent 是那个能决定加载哪个 Skill、调用哪些工具、读文件、请求接口、写草稿、跑校验、最后把结果交回来的系统。
大部分人，想用一堆提示词文件，去解决 Agent 层面的问题。
所以他们的 AI 方案，永远在重置。
二、一个 Skill 里到底装了什么
一个能用的 Skill，通常就是纯文本。
威力不在格式。
威力在于——这份工作流被写在了 Agent 找得到的地方。
一个简单的 Skill，通常要包含七个部分：
触发条件告诉 Agent，什么时候该把这个 Skill 加载进来。
❌ 不及格的触发条件：
用来写东西。
✅ 及格的触发条件：
当用户要把一条 AI 产品发布，改写成 Zaimiri 风格的引用帖时使用。要核对原始来源、解释机制、挑一个有用的角度、只生成 Typefully 的 review 草稿。
第二种写法，给了 Agent 一条跑道。
它知道任务是什么。
它知道边界在哪里。
它知道输出长什么样。
它知道什么不要做。
这就是"提示词"和"可复用的操作手册"之间的差距。
三、不及格的 Skill vs 合格的 Skill
不及格的 Skill：
写一条更好的推文。
让它病毒式传播。
听起来像人话。
这不叫工作流。
这叫许愿。
合格的 Skill：
使用场景：zaimiri 发来一条 AI 产品发布，要给 @zaimiri 用。
1. 阅读原始来源
2. 找出真正的机制
3. 除非来源支持，否则忽略 hype 宣称
4. 从三种结构里选一个：
- 个人亲历视角
- 功能 → 前后对比
- 机制拆解
5. 用 Hana 的人称口吻写
6. 删掉所有 AI 味重的表达
7. 只在 Typefully 里建一份 review 草稿
8. 校验没有自动排程、也没有发布
到了这一步，Agent 才有"活儿"可干。
它不需要从头猜你的口味。
四、为什么 Skills 会"越用越值钱"
Skills 是你品味能变成资产的地方。
每一次纠错，都能被收进系统里。
Agent 写出了你讨厌的文风？改 Skill。
它忘了引用规矩？改 Skill。
某条命令跑不通了？改 Skill。
某个客户的工作流变了？改 Skill。
大多数人漏掉了这一层。
Skill 不只是"配置文件"。
它是操作记忆的存放地——而且不会把主记忆区变成垃圾堆。
记忆（Memory） 存"稳定的偏好"
Skill 存"稳定的工作流"
举例：
记忆：zaimiri 喜欢简洁的 Telegram 引用帖。
Skill：写 Zaimiri 文章时，统一走 Typefully 草稿模式、跑 AI 味检查、用一个本地的 X Article HTML 工具辅助排版。
第一条是偏好。
第二条是流程。
混在一起，AI 就会越来越乱。
分开存，整个系统才会越用越强。
五、你该先做的第一个 Skill
别一上来就写十个抽象的 Skill。
先挑一个你已经烦透了、又重复过很多次的活儿。
挑一个你已经给 AI 解释过至少三遍的任务。
好的第一个 Skill，往往很无聊：
无聊的好用，是因为输入和输出都很清楚。
判断方法：
如果你同一个提示词已经贴过两遍，
那它基本就该变成一个 Skill。
怎么开始写？
先用下面这个模板：
---
name: research-brief
description: 用来把一个话题 / 链接 / 模糊问题，变成有源可查的研究简报。输出包含建议、源事实、注意点、下一步行动。不要用来写最终对外发布的文案。
---
# Research Brief（研究简报）
## 什么时候用
用来做源信息收集、决策简报、话题研究。
## 输入
- 话题 / 链接 / 问题
- 目标读者
- 必须包含或必须排除的来源
- 期望的输出格式
## 步骤
1. 先复述一遍：这个研究最终要支持什么决策？
2. 优先找一手来源
3. 社媒帖子只能当信号，不能当证据
4. 把"事实"和"推断"分开
5. 输出一份带链接、带注意点的小简报
## 输出
- 建议
- 有源支持的事实
- 注意点
- 下一步行动
## 容易翻车的地方
- 不要编造来源
- 不要把答案埋在一堆链接里
- 除非被要求，否则不写最终对外发布的文案
## 怎么验收
- 重要链接都点开看过
- 所有论断都有来源支撑
- 下一步行动一目了然
够用了，作为第一版。
别一开始就过度设计。
目的是：让 Agent 在一个重复任务上变得更稳。
然后每次它翻车，就修一次这个 Skill。
六、文件夹结构长什么样
一个 Skill 通常是一个小文件夹。
research-brief/
SKILL.md
references/
source-quality.md
output-format.md
scripts/
fetch_sources.py
assets/
brief-template.md
SKILL.md 是主流程文件。
references/ 装判断类材料，Agent 写的时候要随时能调到：
scripts/ 装确定性的、机械的活儿：
该让模型做的，交给模型。
该让脚本做的，交给脚本。
这是让 AI Agent 少翻车最简单的办法之一。
七、Agent 是怎么决定"该不该用"的
这就是 description（描述） 为什么要写得那么讲究。
很多 Agent 在加载完整指令之前，只会先看 Skill 的名字和 description。
如果 description 写得很模糊，Agent 就会直接错过这个 Skill。
❌ 不及格的 description：
description: 帮忙做研究。
✅ 及格的 description：
description: 用来把一个话题 / 链接 / 模糊问题，变成有源可查的研究简报。输出包含建议、源事实、注意点、下一步行动。不要用来写最终对外发布的文案。
这一行字，干了非常多的活。
它一次告诉 Agent：
一个好的 description，就是路由层。
八、怎么测试一个 Skill
一个 Skill，不是写完文件就算完。
Agent 真的能正确调用它，才算完。
跑四组测试。
1. 显式触发
对下面这个主题用 research-brief 这个 Skill：<主题>
看它有没有老老实实按步骤走。
2. 自然触发
你能把这个模糊的问题，变成一份有源可查的决策简报吗？
如果 Agent 错过了这个 Skill，就回去把 description 写紧一点。
3. 过度触发测试
基于这份研究，写一份最终对外发布的文案。
如果 research 这个 Skill 被错误地触发了，就加一条排除说明。
4. 输出检查
核对输出里是否包含该有的章节、注意点、下一步行动。
Skill 变锋利的办法，不是一次性写一本大厚书。
是反复用、盯着翻车点、改流程。
九、Skill 真正"放大价值"的地方
单个 Skill 好用。
一套好的 Skill 库，会变成一个操作层。
| |
|---|
| Skills + 记忆 | Agent 记住稳定的偏好，并按需加载正确的工作流 |
| Skills + 工具 | Agent 跑流程的同时真能把活儿干了：搜资料、读文件、调接口、写草稿、跑校验 |
| Skills + 定时任务 | Agent 每天早上、每周、或者有新源出现时，自动跑同一套流程 |
| Skills + 子 Agent | 一个 Agent 把工作分给多个专员：研究员、写手、审稿、运营 |
| Skills + 配置文件 | 不同的 Agent 可以有各自的 Skill 库、记忆、工具、边界 |
到这一步，AI 就不再像一个大提示词了。
它开始像一个由一个个小操作流程组成的虚拟团队。
十、真正的范式转移
提示词库，是 1.0 时代。
它帮大家把好用的指令存起来。
但提示词还是要靠人记——什么时候用、贴哪儿、配什么上下文、怎么校验。
Skills 把这些负担搬进了系统。
Agent 能自己：
这就是 Skills 重要的原因。
它让 AI 从一个"聪明的自动补全框"，变成一个跑重复工作的"操作系统"。
先从一个 Skill 开始。
一个重复任务。
一个清晰的触发条件。
一种输出格式。
一张验收清单。
然后让它自己"长"起来。
如果你觉得这篇内容对你有启发，欢迎在留言区聊聊你的看法。
关注我，我会持续分享高质量的技术与思考干货。👇
粤ICP备14082021号
免费POC，
零成本试错
