如果你最近在AI应用圈子里泡得足够久，肯定见惯了这种场面：同一条指令丢给同一个大模型，有人拿到的是80分的成品，有人拿到的是40分的大纲。差距不在模型版本，也不在提示词长短，而在于你有没有给AI一套可以反复调用的“固定打法”——这套东西，现在业内统一叫它skills。
skills不是一个功能按钮，也不是某一家平台的专属卖点，它本质上是一种把个人经验、工作流、输出标准一起封装起来的能力模块。你可以把它理解成给AI写的“岗位说明书”：不用每次聊天都重新啰嗦一遍要求，只要触发对应的skill，AI就会自动按照你预先设定好的步骤、格式、质量红线去执行。这篇文章我不谈概念定义，直接讲我怎么从零搭自己的一套skills，踩过哪些坑、调过哪些参数、最后沉淀下来什么，你可以直接照着搬。
1. 先搞清楚：你说的skills到底是指什么
1.1 技能包的来源：从模糊指令到标准动作
我第一次真正意识到skills的价值，是在处理一个特别无聊的重复任务时。当时团队每天要把几十条用户反馈整理成结构化工单，交给产品经理。最开始写法很原始，无非是“把这几条反馈归类一下，写成报告”，AI确实能干活，但每次产出的格式都不一样：今天用表格，明天用列表，后天变成一大段话。改提示词只解决当天的问题，第二天又打回原形。
后来我换了个思路：与其每次对话重新描述需求，不如把“如何整理用户反馈”这件事写成一个固定的sop，连字段定义、分类规则、输出排版全部写死，让AI在收到“整理反馈”这个指令时，自动加载这套sop去执行。这就是skills的雏形。
它的内核一句话就能说清：把隐性经验显性化，把显性经验标准化，把标准化操作封装成可触发的模块。就像新员工入职，你嘴上说“好好干”，和递给他一本《岗位操作手册+质量标准清单+常见错误避坑指南》，带出来的效果完全不同。skills就是那本手册，AI每一次执行都按手册来，不跑偏。
1.2 一个技能包应该长什么样
一个完整的技能包，在我反复迭代后固定为五个组成部分，缺一个都会出问题。
- 触发条件：明确什么时候启用这个技能。比如“当用户提到‘写周报’‘周报’‘weekly report’时，进入周报生成流程”。
- 执行步骤：可编号的完整操作序列。先收集信息，再分析数据，再组织语言，最后自我检查。
- 输入模板：需要用户额外补充的信息框架。比如“本周主要项目名称是什么？本周是否有数据指标变化？”，避免AI在信息不足时自行脑补。
- 输出格式：直接规定成品的排版、长度、语气、是否需要表格，越具体越好。
- 质量红线：必须遵守的底线规则。比如“所有论断必须有数据支撑，没有数据的部分必须标注‘待补充’”，这一条能挡住AI大半的幻觉。
这五部分听起来不复杂，但真正落地时你会发现，每一步都有大量的细节要敲定。下面我会把这套结构拆开，讲清楚每一步的设计逻辑。
2. 设计一套自己的skills：从0到1的关键步骤
2.1 先问自己四个问题
很多人一上来就急着写技能包，结果写出来的东西跟普通提示词没有任何区别——因为本质是“把模糊描述变成稍微不模糊的描述”，没抓住真正的需求。我在动手之前，会先强制自己回答四个问题。
- 哪些事情你几乎每周都在做？注意，这决定了技能包的使用频率。如果一个月用不了一次，不值得我们花半天去封装。
- 哪些事情你能做好，但说不清自己是怎么做好的？这是技能包最难写的一类，因为你在把“直觉”翻译成“步骤”。我建议边做边记录，而不是坐在电脑前硬想。
- 哪些输出需要多人协作统一标准？技能包天然适合团队场景，减少来回扯皮。
- 哪些错误你在同一个领域反复犯？技能包里必须加入“防护性规则”，专门狙击这些问题。
以我自己为例，初期锁定的三个方向分别是：周报生成、代码审查、文章反向标题梳理。这三个都是每周高频出现、有清晰质量标准、且我确实踩过坑的领域。
2.2 搭建技能包的五个核心要素
把前面的五部分翻译成可落地的设计原则：
第一，给技能包起一个明确的名字和职责声明。技能包名称就是触发器的入口。比如“周报生成器”、“PRD检查员”、“竞品分析助手”。职责声明必须一句话讲清“你是什么、你负责什么、你不负责什么”。这个“不负责什么”经常被忽略，但它至关重要——没有边界，AI就会在遇到模糊场景时自作主张。
第二，定义输入参数。这一步决定技能包好不好用。好的输入参数是“即填即用”，不让你觉得是在填表格。我习惯的做法是：把信息分成“必需项”和“可选项”，必需项缺了就先追问，可选项缺失就用默认值。这样既能保证任务可执行，又不会把用户问烦。
第三，设计编号化的执行步骤。千万别写成散文，AI在处理编号步骤时的稳定度远高于处理长段落。我不会追求步骤越多越好，而是让几个关键节点有明确的交付物。比如一个需求拆分技能的步骤是：拆解需求背景、识别用户故事、标注依赖关系、评估工作量、生成验收标准。每步之间保持独立，方便后续定位问题。
第四，规定输出模板。这是最直接提升体感的一步。你给AI一张“填空题的卷子”，它就还你一张“填好的卷子”。如果你只扔给它一个“写一下”，它就还你一篇自由发挥的散文。输出模板里应包含固定标题层级、必要字段、长度区间，甚至指定“哪些位置不需要有内容”。
第五，加入边界与转交规则。当AI遇到“本技能范围之外”的需求，不要让它硬处理，而是让它明确告诉你“这条请求不在我的职责范围内，建议找xxx技能来处理”。这个“知道什么不会做”的特征，恰恰区分了成熟技能包和普通提示词。
2.3 技能包模板示例
下面这个模板我打磨了将近两周，目前已经在多个地方复用，你可以直接保存为文本文件，作为自己创建新技能包的起点。
# 技能包：周报生成器 ## 触发条件 当用户输入包含：“写周报”、“周报”、“weekly report”、“本周小结”等关键词时启用。 当用户输入与周报无关的内容时，不得启用本技能。 ## 职责声明 你是一名资深项目管理助手，负责将用户提供的碎片化工作信息，整理为一份结构清晰、数据可信、重点突出的周报。你只负责周报内容的整理和优化，不负责评估工作绩效。 ## 输入参数 必需项： - 本周核心项目（最多列5个，含项目名称和一句话进度） - 关键数据变化（包括用户数、收入、转化率、bug数等，没有则填“无”） 可选项： - 下周待办事项 - 风险与求助事项 - 团队协作情况 ## 执行步骤 1. 核对必需项是否齐全，缺失时逐项追问。 2. 将用户提供的信息按“完成情况-数据表现-下周计划-风险求助”四段进行归类。 3. 识别信息中的量化字段，没有量化的表述一律标注“待补充”。 4. 按输出模板组织内容，控制在300字以内。 5. 自检：检查是否存在空泛形容词、是否有未标注的数据、格式是否符合模板。 ## 输出模板 ### 本周完成 - 项目A：xxxx（完成度xx%，关键节点说明） - 项目B：xxxx ### 数据表现 - 核心指标1：xxxx（较上周+/-xx%，请基于真实数据） - 核心指标2：无 ### 下周计划 - 事项1：xxxx - 事项2：xxxx ### 风险与求助 - 风险描述：xxxx - 需要的支持：xxxx ## 质量红线 - 不使用“大幅提升”“表现良好”等空泛词汇，如有此类词，必须拆解为具体数字。 - 所有数据必须标注来源或时间周期，无法核实的内容必须说“待补充”。 - 全篇不出现评价性结论，只呈现事实与进度。你可能发现了，这个模板里“输出模板”和“质量红线”占了一半篇幅。这不是浪费，恰恰是技能包稳定输出的保障。写了这层之后，你基本不需要在对话中反复强调“要有数字”“不要空话”，因为每次触发都会自动带上。
3. 实战案例：把周报生成做成一个标准skill
3.1 原始需求与痛点
我们的周报痛点可能跟大多数团队一样：每周五大家花半小时写周报，写出来的东西风格千差万别。有的同学只写一句“本周跟进项目”，有的写了三千字没有重点，更麻烦的是，周报里的数据口径不统一，有的人写“涨了”，有的人写“涨了20%但没说是跟上周比还是跟目标比”。
这个场景非常适合做成skill，因为它足够高频、有明确质量预期、且当前完全依赖个人自觉。我们尝试过给文档模板、做周报培训、在群里强调格式，效果都很有限。最后我决定把这件事交给一个“周报生成器”技能包，让大家把活的流水账丢进去，输出的就是统一格式的周报。
3.2 技能包落地全过程
我把前面那个模板实际用了起来，过程分三步走。
第一步是建立信息采集习惯。技能包再强，也架不住输入信息缺失。所以我要求大家平时记流水账：每周一在共享文档里简单记几点“做了什么事、有什么数据变化、遇到什么问题”。不用整理，用关键词即可，周五把它一股脑丢给周报生成器。
第二步是多次迭代输出模板。第一版模板有了框架，但数据部分的表达不够自由。比如一个同学写“注册转化率从4.1%涨到4.6%”，技能包会原样照搬，虽然真实，但缺少“相对变化幅度”的表达。我后来在输出模板里加了一个“数据表现”字段，要求同时呈现“本期值、上期值、变化幅度、数据周期”，信息一下就完整了。
第三步是让团队直接叫我写好的技能包入口。这一步很多人会忽略：你把技能包写得再完美，如果团队成员不知道怎么触发，那就是废纸。我在团队文档里只留了一个示例指令：“帮我写周报，以下是我的流水账：xxxx。” 复制粘贴，搞定。这样既不会让成员看到一长串提示词产生畏惧，也能保证每次触发都完整加载技能包。
3.3 效果对比与关键参数调整
这个技能包跑了一个季度之后，我觉得最值得拿出来说的是“关键参数”的调整过程。
第一个参数：输出长度。一开始我把长度定为“不限”，结果AI写出来的周报偏长，平均500字，信息密度低。后来改成“300字以内”，模型会主动压缩冗余表达，反而信息量更足。这里的教训是：给AI一个明确极值区间，比一句“简洁点”有效十倍。
第二个参数：数据字段的强制程度。第一版“质量红线”只是说“数据尽量真实”，结果每周都有成员反馈“AI帮我编数据了吗？没有，它写了个‘待补充’，但这句‘待补充’太显眼，显得我没好好干活”。后来我把红线改成“数据缺失时统一输出‘暂未统计’，不在周报中单独标注‘待补充’”，语气中性化之后，大家接受度明显提高。
第三个参数：触发词的边界。起初触发词包含“周报”“weekly”“本周总结”等，结果发现团队成员在聊天时随口说一句“这个不写周报了吧”也会误触发。后来我加了“当用户输入与周报任务无关时不得启用”的负向边界，误触发率直线下降。这个小小的边界设定，让我意识到技能包的触发逻辑必须同时包含“正面清单”和“负面清单”。
运行一个季度后，团队周报格式统一率从原先不到一半提升到接近全覆盖，最明显的变化是产品经理每周的阅读时间少了大半。
4. 常见问题与排查技巧实录
4.1 模型总是“不听话”怎么办
这是被问得最多的一个问题：“我的技能包写得挺详细了，为什么AI还是偶尔不按套路出牌？”
每次听到这个，我都会先反问一句：你的“顺不顺”标准是什么？如果要求的是“100%按模板输出字段顺序都不差”，那大概率会失望。大模型的执行天然带一定波动性，我们的目标是“高质量稳定的输出”，而不是“像素级复刻模板”。所以我处理“不听话”问题的顺序是：
- 第一步，检查输入信息是否充足。80%的“不听话”其实是输入信息不足导致的自由发挥。你把“必需项”写成可选择，模型就只能自己判断，一判断就偏差。
- 第二步，检查输出模板里有没有“自由发挥区”。如果你只规定了第一段标题，后面没写，那模型自然会放飞自我。解决办法是把后文模板补全到四级标题级别。
- 第三步，检查“质量红线”是否可衡量。“语气正式一点”是不可执行的，模型无法量化“正式”到什么程度。换成“不使用第一人称，不出现口语化表达，所有句子主谓宾完整”，执行稳定度立刻上一个台阶。
- 第四步，如果上述都做了还是不稳定，给技能包中同一个输出需求写两个示例——一个正例，一个反例。大模型的模式学习能力很强，你给它一个“不要像这样”的样本，通常能显著降低某类错误。
4.2 技能包之间的冲突与优先级
当你手里的技能包超过五个，就会出现一个很尴尬的问题：同一个用户输入，可能同时命中多个技能的触发词。比如“帮我分析一下这周的用户反馈，并生成一个周报”，既可能触发“用户反馈分析”，也可能触发“周报生成器”。
我刚开始没考虑这个问题，经常出现AI同时加载两个技能包，输出结构四不像。后来我用了一个简单的解法：在技能包开头增加“优先级声明”。比如周报生成器里明确写“当你检测到本技能与其他技能同时触发时，优先执行本技能的信息汇总，再将汇总结果转发给周报模板，不要混用其他技能的输出结构”。这个声明并不复杂，但它成功让AI在冲突场景下有了决策依据。
另外一个实践心得是：技能包之间要有清晰的“服务边界”。我习惯在每个技能包的最后加一句“当需要xxx时，建议使用另一个技能包XXX”。这等于在AI脑子里建立了一棵技能树，让它知道遇到不同场景该调哪个模块。
4.3 从零开始调试的五个排查点
如果你照着上面写了一个技能包，但效果不理想，可以用我常用的“五步排查法”按顺序检查。
- 检查触发路径：命中的关键词是什么、是否在触发条件里、是否被负面条件拦住了。我见过大量“技能包没生效”的案例，本质是触发词没对上，聊了几个来回也没进入技能包。
- 检查输入框架：用户提供的信息够不够支撑执行步骤。不够就让AI主动追问，而不是拿着残料硬写。
- 检查步骤是否可独立验证：你的执行步骤里第2步的产出是否是第3步的输入？如果你的每一步之间没有递进关系，那AI就会把它们当成并列关系处理，流程感自然出不来。
- 检查输出模板是否唯一：模板里是不是出现了两个都可以的选项？如果有，AI就陷入选择困难，表现就是今天用表格、明天用列表。模板必须只有一个明确的样式。
- 检查红线是否能拦截过去犯过的错：把你历史中AI犯过的典型错误逐条列出来，转化成“禁止语句”写进红线。比如你发现它经常在结尾自作主张加“总结建议”，那就加一条“本技能不在结尾输出总结与建议，输出内容止于质量红线之后”。
这套排查法我现在开发任何新技能包都在用，基本能解决九成问题。剩下的问题，通常出在模型本身的能力边界上——那种情况再多调也没用，换更强的模型或者改变任务设计才是正道。
做个技能包这件事，说难真不难，但做得好的人很少，原因在于大部分人把它当成了“更长的提示词”来写，而没当成“一套可复用的工作方法”来设计。我的亲身感受是，真正让skills跑起来的关键，不在于你多会写prompt，而在于你是否真的理解自己手头那件事的完整流程、坑点和质量标准。技能包只是把你脑中的经验外置出来，AI替你当那个随时待命、绝不偷懒的执行者。
从周报技能包开始，我陆续封装了代码审查、需求拆解、竞品分析等十几个常用的skills，每个都是从一个具体痛点出发，先解决自己的问题，再慢慢演变成团队级别的标准动作。我的建议是你别一上来就想建一个庞大的技能包体系，先从下周你就要做的、重复度最高的那件事开始，写出第一个粗糙的skill，用起来，再迭代。等它第二次帮你省下时间时，你自然就明白这玩意真正的分量了。
