一、SKILL是什么？
Skill 是大模型内部封装好的一套标准化能力模块，把特定业务的规则、流程、话术、校验逻辑打包在一起，模型调用 Skill 后，会严格按照预设规范输出，避免自由发挥。
它可以处理会员、隐私、记忆这类有明确官方口径的场景，模型不再随意生成回答，而是读取模块内的权威文档，保证回复统一合规，减少幻觉与错误。简单说，Skill 就是给大模型的专项工作手册，限定它在特定问题下该怎么思考、怎么回复。
二、SKILL结构
Skill 本质上就是一个文件夹，一般长下面这样：
拆开包含三个东西
1. SKILL.md
这是整个 Skill 最核心的文件。
里面包含YAML frontmatter和Markdown指令。
文件最上面的那一段是YAML frontmatter，里面一般会包含这个Skill的名字和描述。
下面的正文部分，就是你要教给 Agent 的方法、原则和执行方式。
2. references 文件夹
这里一般用来放规则、知识库、业务说明、风格指南等资料。
比如不是每次执行都需要加载的文件，就可以放在这里。
3. scripts 文件夹
这里放的是 Agent 可以直接执行的脚本。
比如你有一套固定流程，希望用更传统、更稳定的方式来保证标准化，那就可以把这部分逻辑写成脚本。
这样 Agent 不需要自己临场判断，只要执行脚本就可以了。
这个结构背后，有一个很有意思的机制，叫做渐进式披露。
简单来说，它分成三层。
第一层，Claude 启动时，每个 Skill 只会加载它的 name 和 description。
让模型知道「系统里有这个 Skill 可以用」就够了。
第二层，当对话内容触发某个 Skill 时，才会加载完整的 SKILL.md 文件
第三层，是 references 和 scripts。
只有在真正需要使用skill的时候，Agent 才会加载这些内容
用不到的时候，它们不会占用上下文窗口
三、什么时候需要一个 Skill？
当问题命中有强官方规则、固定流程、不能自由创作、严禁模型瞎编的场景，就必须启用 Skill
例如以下场景：
有严格官方口径，不允许模型自己发挥
会员权益、退款、订阅、发票、隐私政策、用户数据、记忆功能这类，答案是固定的，不能让模型脑补，必须读 Skill 里的标准文档输出。
业务有固定操作流程，需要按步骤执行
比如删除记忆、关闭记忆、投诉反馈路径，操作路径是写死的，模型不能自己创造步骤。
需要规避幻觉，拒绝自由推理
这类场景一旦 AI 自由发挥就容易出错：乱编退款政策、乱讲隐私条款、错误解释记忆逻辑。Skill 强制模型读预设内容，而不是靠模型知识生成。
边界模糊，疑似命中规则场景
拿不准是不是属于规则类问题，优先走 Skill，宁可调用，不要直接自由回答。
开放式问答、写文案、写代码、知识科普、日常聊天、主观建议，没有强制官方标准，直接大模型原生能力回答即可。一般也不用写专门的Skill文档
一个好的Skill文档不断迭代优化
Skill 的真正价值，在于复利。今天做出来，明天用一次、顺手改一次；下周再用，再优化。一个月后，它早已脱胎换骨。真正拉高你效率的，从来不是第一个成品，而是后续永不停歇的迭代。可惜，多数人做完就扔——只要还能跑，便不再理会。
四、如何写一个Skill
一句话流程：
判场景 → 定边界 → 写规则 → 自测 case → 评审合规 → 灰度上线 → 持续迭代
1、需求识别：判断要不要做 Skill
先判定场景属性：是否必须做 Skill，还是不适合做 Skill
2、需求梳理：确定 Skill 边界
写 Skill 前必须对齐 4 件事：
触发场景
红线约束：什么不能说、不能编、不能承诺
3、Skill 内容撰写（标准结构）
严格按照固定模板撰写，保证模型可读、规则无歧义：
功能概述：一句话说明这个 Skill 解决什么问题
排除规则：明确不命中的场景，防止误触发
强制约束（核心）：禁止脑补、禁止扩写、禁止自定义政策
回复逻辑：分支话术、步骤流程、判断条件
兜底逻辑：信息不足、场景异常、无法回答时的统一话术
正反示例：正确回复 + 禁止错误回复
撰写核心原则：只给标准答案，不给模型自由发挥空间，语言必须指令化、无模糊词。
4、自测验证（开发者自查）
写完必须过 4 类 case，不过测不能提审：
正向直白提问：能否精准命中、口径标准
模糊/拐弯提问：能否识别隐藏意图
边界场景：不越权、不瞎答、走兜底
反向场景：不该触发时，绝对不误触发
5、业务+合规评审
Skill 属于合规能力，必须双评审：
业务评审：规则、话术、流程是否和官方一致
合规评审：无风险话术、无过度承诺、无隐私泄露风险
评审重点：有没有留白、有没有可被模型滥用的模糊描述
6、上线灰度 & 全量
小流量灰度上线观察命中情况
监控：误触发率、漏触发率、用户负反馈、幻觉案例
无问题后全量上线
7、迭代优化（长期闭环）
定期复盘问题案例，迭代更新 Skill：
新增用户新型提问句式，补全触发规则
修复边界 case、补全兜底话术
政策更新时，同步更新 Skill 口径
五、示例
一个完整的Skill文档格式：
name: "internal_data_analysis"
description: |
基于公司数据仓库执行标准化数据分析：理解需求、编写安全 SQL、执行查询、清洗数据并生成报告草稿。
适用场景：用户询问业务指标趋势、留存率、渠道对比等需查数任务。
不适用：历史数据回溯超过 1 年、非授权表查询、纯逻辑推演无需查数场景。
metadata:
version: "1.0"
author: "agent-team"
tags: ["data", "sql", "analysis"]
triggers:
- intent: "data_query"
keywords: ["查一下", "多少", "趋势", "占比", "留存", "新增"]
required_slots: ["query_intent"]
- intent: "report_draft"
keywords: ["写报告", "分析结论", "总结"]
optional_slots: ["time_range", "dimensions"]
parameters:
query_intent:
type: string
description: "用户原始自然语言需求"
required: true
time_range:
type: string
description: "时间范围，如'最近 7 天'、'2024-Q1'"
required: false
default: "最近 30 天"
dimensions:
type: list[string]
description: "分组维度，如['渠道', '地区']"
required: false
execution_flow:
steps:
- name: "validate_and_refine"
action: "确认指标口径与表结构，若模糊则反问用户"
rule: "禁止直接猜测指标定义，必须参照 metrics_definitions.md"
- name: "generate_sql"
action: "生成带注释的 SQL，强制添加 WHERE 时间过滤，禁止全表扫描"
constraint: "单条 SQL 逻辑不超过 3 层嵌套"
- name: "execute_query"
action: "调用 run_query.py 脚本执行，捕获超时/权限错误"
- name: "clean_and_aggregate"
action: "调用清洗脚本处理空值/异常值，计算基础统计量"
- name: "format_report"
action: "生成结构化草稿：摘要->方法->关键数据表->洞察->风险局限"
return_schema:
status: "success | error"
data:
raw_result: "CSV 路径或结构化 JSON"
summary_text: "自然语言结论摘要"
sql_used: "实际执行的 SQL 语句"
message: "成功提示或具体错误原因"参数说明：
name：全小写 + 下划线命名（如
query_weather），动词开头，一眼看出功能description：最关键字段。需明确“能干什么”、“何时触发”、“不适用场景”，避免模糊描述导致 LLM 误判
trigger rules：定义精确匹配条件（意图关键词、必填槽位），辅助 LLM 决策
parameter slots：定义输入参数类型、描述、是否必填、提取规则及约束（如范围、枚举值）
execution logic：实际代码逻辑，需包含参数校验、异常处理、外部工具调用及结果格式化
return format：统一返回结构（通常含
status,data,message），区分机器可读数据与人读摘要examples（可选但推荐）：提供输入输出示例，增强 LLM 理解 。
评论区