AI助手Skill技能包实战：将通用大模型调教成专业分析师

前阵子我把一个叫"小龙虾"的内部AI助手调教了一通，结果它从"什么都聊得来但什么都落不了地"的通用聊天对象，变成了一个能拆指标、查数据、出结论的分析师。整个过程没有改模型、没有换底座，只是给它加了几个 Skill——也就是技能包。这件事让我对"AI能不能干活"这件事有了新的判断：很多时候瓶颈不在模型聪明不聪明，而在你有没有把专业方法教给它。

这篇文章想把我加 Skill 的整套思路、文件写法、踩坑记录都摊开来讲。适合正在做 AI 助手、智能体，或者想让自己手头 AI 工具更专业的朋友参考，尤其是那些觉得"AI 回答得很对但没用"的人。

1. 先把事情说清楚：Skill 到底是什么

先厘清概念。Skill 在这里不是指某个算法，也不是某个固定模型，而是一份"预设的专业操作流程 + 工具调用方式"，相当于你给 AI 配了一本岗位手册。没加 Skill 之前，AI 面对"帮我看下这个月销售为什么跌了"这种问题，它只能凭训练时的常识回答，讲一些"可能是市场原因、竞品原因、价格原因"这类永远正确的废话。加了 Skill 之后，它会先走一套分析师的操作路径：先确认口径、拉数、看趋势、找异常、再下结论。

我理解 Skill 的一层本质，是把"人会但 AI 不会"的工作经验外置出来。比如一个分析师看到数据表，第一反应一定是检查有没有空值、字段是不是文本格式、要不要去重。这些东西不会写在任何教科书里，但会写在这个人的脑子里。Skill 就是把这类脑子里的流程固化成文字，再让 AI 按规定流程执行。这跟你带新人一模一样：你不可能天天陪着新人重复讲一遍流程，但你可以给它一份流程手册，让它按手册办事。

还有一个容易被忽略的点：Skill 不是提示词。提示词是你每次提问都要重复的一段话，费 token 且不稳定。Skill 是挂在 AI 身上的一个模块，它会在需要的时候被自动唤起，相当于一个常驻的"专业技能"。比如你给 AI 配了"SQL 查询"这个 Skill，它遇到"查一下上季度复购率"这类问题，就会自动带上写 SQL、查数据库的动作链，而不是从记忆里"猜"一个复购率给你。

这种机制的好处在于，你的分析经验、行业知识、判断准则全部沉淀在了一个个 Skill 包里。换一个新模型也能直接把 Skill 导过去继续用，并不依赖某一个特定模型。我实际测下来，同一个 Skill 在不同版本模型上都能跑，区别只是执行质量有高有低，起码"流程不会丢"。

2. 我给小龙虾配了五个 Skill，它们各管一摊

我一开始也没想好要配几个，先列了日常分析工作里最高频的五个环节：拿脏数据、拆业务问题、查数、看图、写报告。后来又砍掉两个合并了一个，最后留下五个，各管一摊，互不重叠。这五个 Skill 才真正让小龙虾有了"分析师骨架"。

2.1 数据清洗 Skill：先保证数据能看

数据清洗 Skill 是我第一个做的，因为所有分析的起点都是数据。小龙虾之前会对用户给的表格数据"照单全收"，哪怕里面一堆空值、重复行、乱码，它照样做分析，最后结论自然是错的。加了这个 Skill 之后，它的第一步动作变成了"先体检再手术"。

具体来说，这个 Skill 的指令里明确写了五步：识别字段类型、检查缺失值比例、处理重复记录、排查明显异常值、输出数据质量说明。每一步都有阈值和动作，比如"关键字段缺失超过 30% 时，不要直接删除或填充，先向用户说明并建议补充数据"。这就规避了 AI 在"要不要填空值"上自作主张的问题。

我还在这个 Skill 里加了一条重要规定：清洗前后必须有对比。一旦对数据做过任何修改，比如删行、类型转换、归一化，必须在回答里说明原始数据多少行、清洗后多少行、改了什么、为什么改。否则分析做完，别人根本不知道你的结论是基于什么数据得出来的。

2.2 指标拆解 Skill：看到问题先离手，先拆结构

第二个 Skill 解决的是"答非所问"的问题。以前小龙虾拿到"转化率低了"这种问题，会直接开始提建议，比如"优化着陆页、加强AB测试"。建议本身没错，但完全跳过了"为什么低"的归因环节，等于没分析就开药方。

指标拆解 Skill 的逻辑，是给小龙虾装了一套路演式拆解框架。指令里规定：遇到业务指标波动类问题，第一不准下结论，第二不准提方案，先拆出指标体系，包含一级指标、二级指标、三级指标。一级指标是这个问题的核心，二级是它的构成因子，三级是最细的可落地粒度。拆完之后，才允许逐步排查。

拿"销售额下跌"来举例，拆解路径大概是：销售额等于流量乘以转化率再乘以客单价。流量里又分新客老客、渠道来源；转化率分首购转化和复购转化；客单价分品类结构、优惠力度。拆到这一步，AI就不再说废话了，它会按这个路径去查每一个环节的数据，最后定位是哪一层出了事。这一招我强烈建议所有做业务分析的人都给 AI 配上，效果立竿见影。

2.3 SQL 查询 Skill：把"可能"变成"确定"

第三个 Skill 是 SQL 查询。这是让小龙虾从一个"嘴上分析师"变成"手里有数分析师"的关键一步。以前它最大的问题不是不会写 SQL，而是从来不主动查数，全靠模型记忆里的"常识"回答用户。可是业务数据每分每秒都在变，记忆里的数据怎么可能反映真实情况？

我给这个 Skill 设定的职责有两条：第一，凡是涉及具体数字、比例、趋势的问题，必须先查询数据源，禁止用预估数据回答；第二，查询过程中必须输出完整的 SQL，让用户能看到查询逻辑，而不是丢一个结果就完事。这两条直接堵死了 AI"一本正经胡说八道"的路。

这个 Skill 的 instructions 里还内置了一些常见查询模板：按日周月聚合、同环比计算、漏斗各环节人数、留存率的计算逻辑。这些模板都是我从日常分析里整理出来的高频片段，有这些模板兜底，小龙虾写出来的 SQL 很少跑错，查询路径也清晰可追踪。它不需要成为数据库专家，但至少得是个合格的"取数工具人"。

2.4 图表解读 Skill：从"看图说话"到"看懂图背后的含义"

第四个 Skill 是图表解读。起因是有人拿着后台截图让小龙虾分析，结果它仅仅把图上的数字复述了一遍——"一月 100 万，二月 80 万，三月 90 万"——这叫念图，不叫分析。我加这个 Skill，是让它学会识别图表类型、结构、坐标轴含义，然后按格式去读。

这个 Skill 教会了小龙虾几个关键姿势：先看横纵轴和单位，确认口径；再看整体趋势，判断是持续上升、波动还是周期性；然后看异常点，比如突然的尖峰、断崖；最后才是归因分析，结合业务背景给出可能解释。它还要注意一个常见陷阱：图表相关性不等于因果性，看到两条线一起涨不能直接说"因为 A 所以 B"。

我还在指令里加了一条强制要求：在解读任何图表前，必须明确声明数据范围和截止日期。这一条看起来很简单，但能挡住大量"拿旧图说新事"的错误。分析里面最怕的就是时间口径混乱，图表 Skill 把这一点写死之后，小龙虾每次都会先问"这个数据是截至什么时候的"。

2.5 分析报告 Skill：把零散结论拼成能交付的东西

最后一个加的是分析报告 Skill。前面四个 Skill 让小龙虾有了单点能力，但用户要的从来不是一个结论，而是一份完整交付物。分析报告 Skill 负责把这些能力串在一起，按统一格式输出。

我参考自己写报告的习惯，把报告结构固化成了六段：背景与目的、数据说明、核心结论、分析过程、风险提示、行动建议。前两段交代背景和口径，中间三段讲清楚"发现了什么、为什么、意味着什么"，最后一段给出能落地的动作，并明确每一条建议需要谁去跟进、大概做什么，拒绝模糊的"加强运营"这种话。

关键的一点是，这份 Skill 里我写死了两个原则：全文结论必须有数据支撑，不能出现"大概可能也许"；所有建议必须与前面的分析有因果关系。这两条原则让小龙虾产出的报告风格从"AI 味十足"变得像一个分析师的手笔。

3. 手把手讲清楚：一个 Skill 文件到底怎么写

很多人以为 Skill 很难，其实文件结构非常简单，它就是一个 Markdown 文件加可选工具脚本。真正难的，是文件里指令的写法。

以我实际经验来看，一个 Skill 文件最核心的部分就两块：一块是开头的 description，决定 AI 什么时候主动调用它；另一块是正文的 instructions，决定 AI 调起来之后干得专不专业。这两块写明白了，Skill 就成了一大半。

3.1 description：决定触发时机，千万别写成小作文

很多人会把 description 写得特别详细，试图在触发阶段就把所有情况都描述一遍。实测下来这是误区。description 一旦变长，AI 对它的"语义识别"反而会飘，该触发的时候不触发，不该触发的时候乱触发。

我总结出一条经验：description 只用三句话说明"什么场景、什么任务、什么输入"。举例，我写的"数据清洗"Skill 的 description 是这样的：

当用户提供原始数据文件、表格数据、导出的业务报表或包含大量字段的数据样本，需要校验数据质量、处理缺失值或重复数据时，使用本技能完成数据清洗与质量说明。

这一句话里明确写了四件事：触发条件是"用户提供了原始数据"，任务是"校验数据质量"，动作是"处理缺失值和重复数据"，产出是"输出质量说明"。不解释原理，不写流程，不写边界，一句话六个要素，AI 就能在遇到类似场景时把它拉起来。

这里有个细节值得强调：description 里一定要包含用户可能使用的"口语化词"，而不仅仅是专业术语。用户不会说"请做数据质量校验"，他们会说"这个表有点脏帮我弄一下""数据有问题你看看"。我在很多 Skill 的 description 里都会补上这类口语触发词，实测可以显著提高调用率。

3.2 instructions：把操作步骤写细，把判断规则写死

如果说 description 负责"让 AI 进门"，instructions 就是"进门之后按什么规矩干活"。这一部分不需要你写太多高深的东西，但一定要具体、可执行、有顺序。

我在 instructions 上踩过一次很深的坑：一开始写得"太像人话"，比如"请仔细检查数据质量，发现问题及时处理"。这种话 AI 读了跟没读一样，该含糊还是含糊。后来我改成"先按字段识别数据类型，再逐字段统计缺失率，缺失率超过 30% 的字段标记为高风险并提示用户"，它才开始真正按这个顺序执行。

写 instructions 的另一个要点是：把判断规则写死，留决策空间给"是否继续"而不是"怎么操作"。举一个例子，在"指标拆解"Skill 里，我不能让它"自由决定怎么拆"，而是直接写出拆解模板：先拆构成公式，再拆漏斗路径，再拆影响因素。但遇到"数据不足时是否继续强拆"这种问题，Skill 里明确写了一句话："数据不足以支撑某级指标时，禁止凭经验补数，应列出缺失清单并询问用户。"这样既保住了确定性，又留下了人类介入的口子。

3.3 一个可以直接套用的 Skill 文件模板

写一个通用模板，你可以直接复制改内容。它基于我实际在用的最简结构，适合纯指令型 Skill。

--- name: 技能包名称 description: 当用户出现什么行为、遇到什么任务、提供什么输入时，使用该技能。触发词包括：xxx、xxx。 --- # 职责边界 本技能负责什么，不负责什么。边界写清楚是为了避免和其他技能冲突。 # 执行步骤 1. 第一步：接收输入并确认完整性，缺什么先列出清单再动手。 2. 第二步：执行核心处理，包括动作 A、动作 B、动作 C。 3. 第三步：对结果进行自检，检查项目包括 X、Y、Z。 4. 第四步：按指定格式输出，包含字段一、字段二、字段三。 # 判断规则 - 遇到情况 A 时，执行操作 B。 - 遇到情况 C 时，停止操作并向用户说明原因。 - 遇到底层数据与预期不一致时，以实际数据为准并说明差异。 # 输出格式 固定结构：结果摘要、关键过程说明、完整数据列表、下一步建议。

这个模板你可能觉得简单，但它已经能覆盖八成分析类 Skill 的场景。我在实际使用中，每个 Skill 文件也就是二三十行，写多了既难维护，又容易让模型在执行时"顾此失彼"。

4. 加了 Skill 之后，小龙虾到底变了什么

东西做出来得看疗效。我特意留了一份加 Skill 前的对话记录，跟加完之后的表现做了对比，差距非常明显。

先说最直观的感受：加 Skill 前它像一个热心的外行，加 Skill 后像一个冷静的同行。外行和同行的区别不在答案对不对，而在流程稳不稳。以前它可能十次里有三次答得不错，但剩下七次在胡说。加了 Skill 之后，它可能不会给你惊艳的答案，但每次流程都对，输出稳定在六十分以上，这在实际使用里远比偶发的九十分重要。

4.1 从"直接给答案"到"先拆问题"

加 Skill 前，小龙虾拿到"为什么最近的用户留存下降了"的问题，会直接罗列一堆可能原因。加 Skill 之后，它的回答变成了先确认口径、再拆结构、再逐步排查，最后才给结论。

我举个例子，同样是问留存下降，加 Skill 前它是这样答的："留存下降可能是产品更新影响用户体验，也可能是竞品分流，建议加强用户关怀。"这句式是不是很熟悉？每个词单独拎出来都没错，连起来就是一句正确的废话。

加 Skill 之后，它第一句话是："需要先确认两个问题：你说的留存是次日留存、7 日留存还是 30 日留存？统计口径是按设备去重还是按账号去重？"然后才开始下一步。这就是分析师和聊天机器人的分水岭：分析师先锁口径，再谈结论。

4.2 从"空泛建议"到"结构化交付"

第二个显著变化是输出形式。以前小龙虾的回答是作文式的一大段，读起来顺畅但整理信息很累。现在它会按"结论—证据—建议"三个层次组织输出，开头先亮结论，然后列支撑数据，最后才给建议。

这里我强烈安利一个写法：在分析报告 Skill 里规定，结论必须写在开头，证据必须紧跟在结论后面。这样做有两个好处，一是读者前五秒就能拿到核心信息，二是AI为了不写出孤立结论，会被倒逼着去找数据支撑。很多 AI 输出"空洞"，根源是它没有这个结构约束。Skill 能把结构约束固定下来。

4.3 从"凭记忆回答"到"先查数再说话"

这个变化最重要。给小龙虾配了 SQL 查询 Skill 之后，它不再凭记忆里的数据回答了。每拿到一个与数字相关的问题，它会先写 SQL 查数据，查询结果出来之后，再基于真实数据进行判断。

有件事我记得很清楚：有一次问它"上个月某渠道的转化率是多少"，它的操作路径是"先检查数据库里有没有该渠道的字段定义，再写 SQL 按渠道分组算转化率，最后把 SQL 和执行结果一起贴出来"。你能清楚看到它是怎么得出结论的，而不是扔给你一个数字。这种"可追溯性"会让你愿意信它的分析，这也是我理解的专业感的真正来源。

4.4 一个完整的加 Skill 前后对比表

我把几个维度的变化整理成了一张表，可以作为你评估"要不要加 Skill"的一个参考标准：

这张表不是夸张，而是我调整前后来回切换的真实体感。甚至现在我给别的内部 AI 配技能时，也会拿这张表当验收标准：加了 Skill 之后必须能看到这些维度里的至少三个发生变化，否则说明 Skill 没写到位。

5. 实操中踩过的坑，希望你不用再踩一遍

任何事情只有自己上手做，才会碰到文档里不写的坑。Skill 配置看起来是"写一个 Markdown 文件"那么简单，实际用起来问题不少。我把真正影响效果的几个坑列出来，应该能帮你省掉不少试错时间。

5.1 description 写太长，触发反而变差

第一次配 Skill 时，我给"数据清洗"写了一段三百字的 description，里面详细解释了什么情况该调用、哪些情况不该调用、具体执行时要注意什么细节。结果很打脸：用户问"帮我看下这个表"的时候，它没有触发；用户说"今天的天气适合爬山吗"，它反而触发了。原因就是 description 里的边界描述太多，AI 在识别语义时被干扰了。

后来我把 description 砍到六十字以内，只留触发条件和核心任务。效果立竿见影，触发率一下子正常了。所以我的建议是：description 里只写"遇到什么说什么"，执行细节全部放 instructions 里。触发和执法的职责要分开，混在一起两边都做不好。

5.2 多个 Skill 之间的指令互相打架

我第二个踩的坑是：不同 Skill 里的规则互相冲突。比如"指标拆解"Skill 要求遇到问题先拆结构、不要着急给方案，但"分析报告"Skill 又要求在报告开头直接写核心结论。这两个要求同时触发时就发生了冲突，小龙虾一会儿先给结论，一会儿说"先要拆解再下结论"，输出混乱。

解决的办法是在每个 Skill 里加一个"职责边界"小节，明确写清楚"什么情况下本技能让位给其他技能"。比如我在"分析报告"Skill 里加了一行："如果当前任务处于初步分析阶段，尚未完成数据确认与指标拆解，本技能的核心结论输出操作暂缓，优先执行指标拆解流程。"有了这条优先级规则，冲突就消失了。这个细节推荐每个人都学一下，比单纯删掉某些规则要更有用。

5.3 不是所有问题都需要挂 Skill

这是一个使用策略问题。我一开始把"指标拆解""数据清洗""SQL 查询"全部设为常驻，结果对用户一个简单的闲聊式提问，AI 也先来一套拆解流程，用户觉得它变啰嗦了。后来我调整了策略：把 Skill 改为"按需触发"而非"全部常驻"，通过 description 的设置让它只在真正相关的场景里启动。

这里有个经验判断：对话型场景保持轻量，任务型场景才挂重流程。要是用户只是随口问一句"帮我解释一下什么是留存率"，你让 SQL Skill 和指标拆解 Skill 全跑一遍，反而是负担。Skill 不是越多越好，而是在"对的问题"里出现，在"不对的问题"里隐身。这个权重需要你根据自己的实际使用场景去调。

5.4 参数和细节写太死，场景一变就失效

Skill 的内容是固定文字，但业务问题千变万化。我在早期版本里把指标拆解模板写死为"流量等于新客加老客"，结果遇到一个纯 B 端销售场景，这个拆解就完全不适用了。后来改为：先给出通用的拆解原则（构成公式、漏斗路径、同环比分类），再强调用户当前问题的业务类型，根据业务类型选择匹配模板。

这个经验教训是：Skill 里要写"方法"而不是"结论"。方法能迁移，结论不能。比如"先确认口径再分析"在所有行业通用，但"零售行业要先看 SKU 结构"就只对特定行业有效。在 Skill 里适当保留通用性，配合少量行业示例，是最稳的写法。

5.5 一个常见的排查思路

当发现加了 Skill 后 AI 表现变化不大，别急着换模型，先按这个顺序排查：description 触发条件是否明确，instructions 是否足够具体，是否存在与其他 Skill 冲突的规则，你在测试时是否正在使用一个与 Skill 完全不相关的场景。大多数问题都出在这四个环节，而不是出在模型能力上。

我把容易遇到的问题整理成了一个速查表，方便你在实际操作时对照排查：

这篇东西写到这里，我已经把自己从零配到能用的整条路线摊开了。如果让我重新做一次，我会把第一步放在"梳理分析师的工作流"上，而不是急着写文件。流程想清楚了，Skill 只是把流程翻译成 AI 能读的文字而已。最后一句送给正在折腾 AI 助手的朋友：别总想着换更聪明的模型，先把你想让它做的事，认认真真写成一个它能看懂的标准动作，效果通常比换模型来得更快。