乐于分享
好东西不私藏

你用的AI工具,为什么每次都要重新"教"它规则?

你用的AI工具,为什么每次都要重新"教"它规则?
你用的 AI 工具,为什么每次都要重新「教」它规则?

同一套判断逻辑,复制粘贴了 23 次,出了 18 个不同版本,每次标准都在微调——这不是 AI 的问题,是你的使用方式出了问题。理解 Skill,是从「用AI」到「驾驭AI」的最后一公里。


😤 一个让团队崩溃的重复劳动

Sally 的团队每个月都要做「经营分析」,其中一个必须环节是红绿灯分析——每次拿到数据,都要算达成率、判断阈值、给数据打上红黄绿标签。

公司有两套经营分析体系,每套都各自实现了一遍红绿灯逻辑。一旦判定标准微调,就要去无数个地方同步修改——极高的错误率和维护成本

大多数人的第一反应:每次从上一次文档里复制逻辑,再做调整。这是最常见但风险最高的做法——每次复制都可能带来漂移。

更好的答案:把核心判断逻辑单独封装出来,各个 PA 统一调用。这就是 Skill 的起点。

🧠 一、Skill 是什么?

Skill 是什么?不是工具,不是文档

🔌

不是插件

不依赖特定AI平台 本质是知识封装

📋

不是模板

不只是复制粘贴 而是可调用的逻辑

🧠

Skill 是

组织知识的封装 让经验变成团队资产

沉淀核心逻辑 → 无数个 PA 和对话中精准、稳定地复用


🔀 二、你应该做 PA 还是 Skill?

在动手之前,先问自己一个核心问题:你要构建的,是一个完整的端到端业务流程,还是一个产出单一数据对象的独立活动

你应该做 PA 还是 Skill?决策树

拿到需求:想让 AI 来做 XX

问题 1

这是不是一个完整的业务流程多步骤、前后流转、多人协作?

否 → 产出单一数据对象?

→ 大概率是 AA(活动能体),考虑封装为 Skill

是 → 是否跨多个业务域?

否 → PA;是 → IPA

Skill

单一活动节点 逻辑固定,多端可调用

🔄

PA

完整业务流程 单业务域,多步骤协作

🌐

IPA

跨多业务域 端到端大流程


📁 三、Skill 长什么样?

Skill 长什么样?一个标准化的文件夹

SKILL.md 是唯一必需的文件,附属文件按需加载、不占用上下文

文件结构

# 简单 Skill(只需一个文件)

red-green-light/

  SKILL.md  ← 主文件,skill 定义和核心逻辑

# 复杂 Skill(可带附属文件)

adas/

  SKILL.md      ← 主文件

  reference/    ← 参考资料(按需加载)

  examples/     ← 示例(按需加载)

SKILL.md 的核心结构(三部分)

NAME

技能名字

简洁明了,让AI知道它是做什么的

DESCRIPTION

触发描述

放在AI「菜单」上展示的内容,决定Skill能否被自然对话触发。至关重要!

正文

核心指令与规则

角色定义、边界、工作流程、反模式等,是Skill真正的「大脑」


⚡ 四、Skill 如何运行:渐进式披露

这么多 Skill,AI 是怎么同时「记住」它们,又不被撑爆的?答案就藏在 Skill 的核心机制里——渐进式披露

Skill 如何运行:渐进式披露

Skill 再多,也不会拖慢 AI 的对话

📋

平时:只看菜单

模型上下文里只有每个 Skill 的 name + description4个 Skill 只占几行,不会撑爆上下文

👨‍🍳

触发:加载完整菜谱

用户需求匹配到 description 时完整 SKILL.md 才加载进上下文,AI 100% 按你写的规则执行

一次触发过程(ADAS Skill 示例)

用户说:「帮我看看其他硬件品牌是怎么做竞品策略的」

  ↓ 匹配

  DESCRIPTION → adas:「跨案例结构化比较分析」✓ 命中!

  ↓ 加载

  完整 SKILL.MD 加载进上下文,AI 完全按你写的规则执行

决定一个 Skill 能否被成功触发,最关键的是 description 是否准确描述了触发场景。菜单上写不清楚,AI 根本不知道你有这道菜。

🏆 五、一个好的 Skill,有七个特征

一个好的 Skill,有七个特征

低质量的 Skill 要么没人触发,要么触发了也没用,要么越用越偏

1触发质量

用户自然描述任务就能自动触发,不用刻意喊「用XX Skill」

ADAS 示例:用户说「帮我看看其他行业是怎么解决这个问题的」→ ADAS 自动触发,无需特意说「请用ADAS」

2角色定义

技能开头明确模型的角色是引导者、执行者还是协作者,避免行为跑偏

ADAS 示例:写「你是用户的洞察引导者,不是分析报告生成者」→ AI 一步步引导思考,而不是直接出报告

3边界设计

明确写清「适用、不适用、模糊场景」三种情况的处理方式

ADAS 示例:适合:竞品选择、竞争对标;不适合:纯数据分析;模糊:先确认是否需要跨案例比较,再决定是否启动

4指令质量

关键规则不仅说「做什么」,还要解释「为什么这么做」

ADAS 示例:不写「禁止跳步」,而写「每步产出是下步输入,跳了后面图全在空中搭楼梯」→ 遇到用户催促也知道不该跳

5反模式

通过测试列出 AI 容易犯的错误(至少2-3条),并给出纠正方式

ADAS 示例:专门列出:「用户一说分析就直接给完整报告」「只选行业案例不选跨界案例」,让 AI 主动避免

6内容质量

内容精简、结构化,正文500行以内,提供可直接参考的示例/模板

ADAS 示例:与其写「引导用户思考」,不如给具体问题示例:「你心里有没有觉得和这个问题类似的案例?」

7泛化能力

提炼的是通用方法,换个类似场景也能使用

ADAS 示例:「分析定价策略」开发的 ADAS Skill,换成「分析组织架构」也能正常引导 → 证明用的是通用方法


✍️ 写在最后

核心方法总结

Skill 的本质

封装核心逻辑,让一个人的经验变成团队永久可调用的资产

PA vs Skill 判断

单一活动节点→Skill;完整业务流程→PA;跨业务域→IPA

渐进式披露

平时看菜单(name+description),触发后看菜谱(SKILL.md)

七维质量标准

触发质量、角色定义、边界设计、指令质量、反模式、内容质量、泛化能力

这不只是工具知识——它代表着你开始用构建者的视角来看待 AI 协作

带走一个问题:你手头有哪个重复性工作,可以被沉淀成一个 Skill?它的 Name、Description 和核心规则会是什么?

- END -

本文基于 AI 协作实践内容编写,文中方法和框架仅供参考