第一次在热搜词里看到“skill女生向百度云”“skill原版无删减版”的时候我愣了一下心想这是什么新出的影视资源后来才反应过来搜索引擎里正在发生一场语义分裂一个群体在找某种跟剧集相关的“skill”另一群人在找的却是完全不同的东西——codex skill、claude code skill、skill开发、如何写一个skill、skill和agent的区别。后者是2025年AI Agent开发者圈子里最热衷的话题之一。如果你最近关注Claude、Codex或者各类AI编程工具大概率已经撞见过这个概念Agent突然多了一项“会做PPT”“能分析日志”“会画架构图”的能力背后站着的就是Skill。这篇文章打算把这个概念彻底讲透Skill从哪里来、和Agent到底什么关系、运行原理是什么以及怎么写一个真正能用的Skill。适合刚接触AI Agent开发的人也适合那些已经在用Codex、Claude Code但对Skill边界还很模糊的开发者。1. 一个英文单词如何变成AI领域的新范式1.1 同一关键词下的两个平行世界去看“skill”的热搜词列表是一件很有喜感的事。“skill女生向百度云”“skill原版无删减版百度”这类搜索明显是冲着某个资源去的大概率跟影视、同人或二次元相关内容有关技术人员看到容易一头雾水。翻过这一页往下拉画风突变——“codex skill”“openclaw skill”“ai agent skill”“skill脚本”“skill creator”。同一个词在两类人的搜索框里指向的是完全不同的宇宙。技术圈里Skill是过去一年里AI Agent领域最重要的范式之一。它的出现背景并不复杂大模型很聪明但它在面对具体领域的专业任务时表现像是一个“很有天赋但没受过岗位培训”的实习生。它知道日志应该分析但不知道你们公司的日志格式长什么样它知道PPT应该有逻辑但不熟悉你的汇报模板和风格要求。Skill就是为解决这件事而生的——把某类具体任务的know-how、操作流程、工具脚本打包成一份“岗位培训材料”让Agent在遇到对应场景时能直接“上岗”。1.2 2025年Skill集中爆发的三个推手2025年Skill这个概念集中爆发背后有几个标志性事件。第一个是OpenAI Codex把Skill作为定制化能力的分发格式。Codex本身是编程Agent能够接管代码仓库、执行命令、操作文件。但用户的需求远不止通用编程有人希望它懂公司内部的编码规范有人希望它能自动处理某种数据格式于是Skill成了把这些“个性化操作说明脚本”打包挂载给AI的标准方式。第二个推手是Anthropic在Claude生态里主推的Agent Skills。Claude的Skill体系更强调“声明式”的组织方式——用Markdown文档描述能力配合脚本实现具体动作发布后可以被其他Agent加载复用。这个“文件即能力”的设计直接影响了后来很多社区Skill项目的组织方式比如有人做的drawio skill画图、ppt skill生成演示文稿基本都是沿着这条路径。第三个推手是国内IDE和开源社区的快跟进。Trae、Cursor这类AI原生IDE以及OpenClaw这类开源Agent项目都在很短时间内接入了Skill概念甚至开始出现“Skill市场”。与此同时各种垂直场景的Skill如雨后春笋日志分析、科研辅助、AI漫剧制作、漏洞挖掘、代码审计、文案去AI味……几乎每个细分领域都有人在尝试把经验固化成Skill。所以你现在去搜索引擎里问“skill是什么”不同时期、不同背景的人会给你完全不同的答案。在AI开发者这里它已经从一个英语名词变成了一个有着清晰技术内涵的范式。2. Skill与Agent、Plugin、Prompt的区别——先分清概念2.1 Skill是Agent的“职业技能”不是Agent本身很多人第一次接触Skill时最容易混淆的一点Skill和Agent的区别到底是什么包一层Agent不就能干活吗为什么要搞Skill我用一个比喻来回答。Agent可以理解成一个“数字员工”它有大模型当大脑有工具当手脚能感知环境、做决策、采取行动。但一个员工光有脑子和手脚不够他需要有“岗位技能”——比如客户投诉处理流程、财务报表核对规范、项目周报的格式要求。这些技能被沉淀成文档和工具包员工上岗前接受培训上岗后按标准执行。Skill就是Agent的“岗位培训包”。Agent是执行主体Skill是主体掌握的能力包。一个Agent可以挂载多个Skill今天是代码审查员挂上代码审查Skill明天变成数据分析师切换到日志分析Skill。Agent本身不会因为挂载Skill而变成一个“新的Agent”它的模型、记忆、目标设定机制没变变的是处理任务时能够调用的上下文知识、操作规则和专用脚本。2.2 它和Prompt、Plugin、Workflow的边界把Skill和另外几个近亲概念放在一起对比特征会更清楚概念核心形态运行方式解决的核心问题Prompt一段自然语言指令每次对话时随请求发送给模型告诉AI“这一次”做什么Skill结构化说明文档脚本/资源包Agent在对话中自动识别并按需加载告诉AI“这类任务”按什么标准反复做Plugin预编译的软件模块或API封装挂载到运行时由AI决定何时调用给AI提供它本身不具备的“手脚”Workflow编排好的固定任务序列按预设流程依次执行各节点把“只能这么走”的流程固化下来它们之间不是替代关系而是合作关层Plugin可以成为Skill里的一个工具Workflow可以被Skill引用为操作步骤而Skill的说明书本身本质上也是Prompt的升级版。区别在于Prompt是“一次性”的——你这次问了下次还得重新写Skill是“可复用”的——一次封装随处加载你只需要写一次说明书之后同类型的任务AI都会按这套标准执行。举一个具体的例子。你想让AI帮你读取CSV文件并生成统计报告。用Prompt的方式你需要每次把CSV格式说明、统计口径、报告结构全部交代一遍AI还经常记不全。但如果写一个“CSV分析Skill”说明书里写清楚列名规则、统计指标、输出格式再配一个Python脚本做数据解析下次只要说“帮我分析这份CSV”Agent会自动加载Skill按标准流程执行。2.3 什么时候该用Skill而不是直接写Prompt判断要不要把一个任务封装成Skill我一般看三个信号第一个信号是“重复”。同一个任务一周之内你发现自己反复给AI描述同样的背景、同样的要求、同样的格式偏好这就是强烈的Skill需求信号。大多数人的第一反应是“把这段Prompt存起来”但存Prompt是备忘录思维Skill是生产力思维——后者在反复执行中会不断被校准越用越准。第二个信号是“有确定性逻辑”。如果任务里包含固定的规则、公式、脚本处理比如日志聚合、数据清洗、格式转换这种情况尤其适合Skill。确定性逻辑沉淀成脚本不确定性判断交给AI两者结合准确率比纯Prompt高一个量级。第三个信号是“需要专用资源”。当任务要依赖特定词典、模板、历史案例库时Prompt写不进去Skill包可以带着这些资源一起加载。反过来如果任务是一次性的、高度即兴的、完全依赖对话上下文的强行封装成Skill反而画蛇添足。Skill不是万能药它是给“反复发生的同类问题”准备的标准化答案。3. Skill的运行时原理AI如何“学会”一个新技能3.1 SKILL.md一份带结构的说明书市面上的Skill实现五花八门但绝大多数Skill的骨架是一个叫SKILL.md有的叫SKILL.md有的叫skill.md不同平台命名稍有差异的Markdown文件。这个文件的核心作用是把“如何执行某类任务”的隐性问题变成一份显式的、结构化的、机器可读的操作说明书。一份典型的SKILL.md长这样--- name: log-analyzer description: 用于分析应用日志聚合错误、提取关键堆栈、生成问题定位报告。 当用户提供日志文件、日志文本或希望排查线上错误时使用。 --- # 日志分析流程 ## 1. 输入解析 - 接收用户提供的日志文件路径或日志文本内容 - 确认日志来源类型后端服务/前端/数据库 ## 2. 分析步骤 1. 先统计日志中的 ERROR / WARN 级别占比 2. 按时间窗口聚合错误识别连续时间段内的高频异常 3. 对每条 ERROR提取异常类型、业务模块、堆栈摘要 4. 关联相同错误指纹指纹异常类名首帧方法名 ## 3. 输出格式 - 必须按以下结构输出 - 概况总览日志量、错误级别分布 - 高频错误TOP5附错误指纹和发生次数 - 每个错误的可能根因分析 - 修复建议排序 ## 4. 注意事项 - 不要编造日志中不存在的内容 - 堆栈过长时只保留前15行 - 判断根因时优先参考日志中直接出现的关键字不要过度假设这份说明书的价值在于它把“一个资深后端工程师拿到日志后会怎么做”的过程完整复刻成了AI可以照做的SOP。注意看第4条“注意事项”这是很多人会忽略但极其重要的部分——它规定了AI的边界有效阻止了AI出现幻觉、过度解读、输出格式漂移这些常见问题。3.2 调用流程拆解检索、加载、执行、反馈Skill在真实环境中是怎么被调用的我拆成四步来看。第一步是“检索”。Agent的调度器会周期性评估当前对话上下文判断有没有已挂载的Skill“描述”与当前任务匹配。这个匹配通常是语义匹配所以SKILL.md里的description字段极其关键——它决定了Skill会不会被“想起”。第二步是“加载”。一旦匹配成功Agent会把对应的SKILL.md连同配套脚本、资源文件注入当前会话上下文。这个注入不是把整个文件丢给模型就行而是经过解析的结构化注入说明、步骤、约束条件会成为系统提示词的一部分让模型在后续推理中有据可依。第三步是“执行”。模型按照说明书中的步骤逐项推进对于确定性操作读文件、跑脚本、统计数字它调用Skill包内的工具脚本完成对于需要判断的部分根因分析、修复建议排序它自己推理完成。第四步是“反馈”。执行结束后Skill还可以定义“自我检查”逻辑比如“输出是否符合第3节的格式要求”“有没有引用日志中不存在的错误”检查不通过就重新生成。这一步是Skill质量稳定器很多专业Skill都会内置一层校验反馈。3.3 为什么“描述质量”比“代码质量”更影响效果我在测试Skill时发现一个反直觉的现象决定Skill好用不好用的往往不是脚本的代码质量而是SKILL.md里描述的质量。原因是Skill的触发、执行路径、输出约束全部依赖这份自然语言描述代码只是其中执行环节的一环。举个我踩过坑的真实例子。早期我写过一个“会议纪要整理Skill”description写得特别简短“整理会议纪要生成待办事项”。结果Agent在用户随便聊到会议内容时就被触发频繁误调用而且因为说明书里没写输出格式同一个Skill连续调用三次三次的输出结构都不一致——一会儿是列表一会儿是表格一会儿是纯文字段落下游处理脚本根本没法对接。后来我把description改精确了明确“仅当用户提供完整的会议文本或转写记录时使用”并且在说明书中规定输出必须包含“会议主题、关键决策、行动项负责人截止时间、风险项”四段结构行动项强制用表格输出。修改之后触发准确率和输出稳定性立刻就好起来了。这段经验告诉我写SKILL.md本质上是在给一个“很聪明但容易飘”的实习生写操作手册——边界写得越清楚效果越稳定。4. 从零写一个实战Skill日志分析Skill完整过程4.1 选一个高频痛点为什么选日志分析热搜词里正好有“日志分析skill”说明这个方向的需求量确实大。我自己早期做后端的时候线上日志排查是每天绕不过去的日常先grep错误再按时间排序再到日志平台里翻上下文遇到相似错误还得一个个对特征。这些动作重复、机械但又是判断线上问题的关键。把这件事交给Skill做人类只负责审结论和做决策是最典型的人机协作场景。4.2 完整的SKILL.md示例先看最终形态。我以日志分析为例写一个你能直接抄走的Skill骨架--- name: log-troubleshooter description: 分析应用日志并定位线上问题。当用户提供日志文件、日志文本、 或描述线上报错需要排查时使用。适用于后端服务、前端异常、数据库慢日志等场景。 不适用于非日志类的文本分析。 --- # 目标 快速从日志中识别异常模式定位根因输出可执行的修复建议。 # 输入要求 - 用户可提供日志文件路径、日志文本片段、或日志平台检索结果 - 若用户只给了错误关键字先引导用户提供至少包含异常发生时间段的上下文日志 # 流程 1. 确认日志范围和来源类型 2. 统计日志总量、ERROR级别占比、WARN级别占比 3. 按分钟/小时聚合错误定位异常峰值窗口 4. 提取每条关键错误的关键信息时间、服务名、异常类、方法栈首帧 5. 按错误指纹聚类指纹 异常类 栈首帧方法名 业务模块ID 6. 对TOP5错误分别做根因推演给出证据链 # 输出格式 必须按以下Markdown结构输出 ## 概况总览 ## 高频错误TOP5表格错误指纹、发生次数、影响接口 ## 根因分析每条错误给出证据、推断链路、置信度 ## 修复建议按优先级排列 # 质量检查 - 确认所有结论都在日志中有对应证据不编造 - 确认输出中包含错误指纹聚类步骤不要直接罗列原始日志 - 确认TOP5有排序不是随意列举 # 规范与禁忌 - 堆栈输出超过15行必须截断不要全文粘贴 - 不要给出“建议重启”这类无效建议至少要定位到具体模块或代码路径 - 当日志量小于100行时不要套用聚合流程直接逐条分析你可以直接把这段存成本地目录的SKILL.md再按照具体平台要求放进Skill目录很多Agent就能识别。4.3 让AI做判断、让代码做执行光有SKILL.md还不够稳妥因为AI直接读取一个几万行的大日志文件既慢又不准。这里的关键设计是“AI做判断、代码做执行”——日志的读取、解析、统计、聚类这类确定性操作应该写成Python脚本AI只负责调用脚本并根据输出做分析、给结论、写建议。配套脚本的关键函数可以这样设计import re from collections import Counter, defaultdict def parse_log_file(file_path): 读取日志文件返回结构化事件列表 events [] pattern re.compile( r(?Ptime\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}).*? r(?PlevelERROR|WARN|INFO|DEBUG).*? r(?Pmodule\S).*?(?Pmessage.*) ) with open(file_path, r, encodingutf-8, errorsignore) as f: for line in f: m pattern.search(line.strip()) if m: events.append(m.groupdict()) return events def fingerprint(error_text): 生成错误指纹异常类名 栈首帧方法名 exc_match re.search(r([A-Za-z_][\w\.]Exception), error_text) frame_match re.search(rat\s([\w\.]\(.*?\)), error_text) return f{exc_match.group(1) if exc_match else Unknown}:{frame_match.group(1) if frame_match else NoFrame} def cluster_errors(events): 按错误指纹聚类返回高频TOP N clusters defaultdict(list) for e in events: if e[level] ERROR: key fingerprint(e[message]) clusters[key].append(e) ranked sorted(clusters.items(), keylambda x: len(x[1]), reverseTrue) return ranked[:5]脚本输出的结果是压缩后的结构化摘要高频错误指纹、各错误出现次数、对应时间窗口。AI再基于这些精确数字进行分析和根因判断形成结论。这个“脚本出数据、AI出判断”的分工是让日志分析Skill真正可用的核心。4.4 本地测试与迭代方法Skill写完不能直接上线测试迭代是重头戏。我的测试流程分三步。第一步准备样本。找三组日志一组是正常日志没有明显错误一组包含两三个常见异常一组包含一个难定位的慢接口问题。把这三组分别喂给Agent观察是否触发Skill、是否按说明书步骤执行。第二步做“飘移测试”。用不同的问法反复触发同一个Skill“帮我看下这个日志”“为什么线上报错”“这是今天的error日志你分析一下”“帮我查一下这个日志文件里的问题”。前两个问法比较模糊后两个比较明确。理想状态下明确问法应当100%触发模糊问法不应该误触发。如果模糊问法也触发了说明description描述范围过宽要收紧。第三步做输出校验。对照说明书里的“质量检查”逐项核查输出是否合规。如果发现AI在某一步频繁跳步比如直接罗列原始日志而不是先聚类就说明说明书对应步骤写得不够强需要改成“必须”句式甚至加一个输出反例。迭代三到五轮之后Skill基本能稳定工作。这个过程比较枯燥但Skill的价值恰恰就是这么打磨出来的——每一轮校准都是在沉淀一次经验。4.5 发布与复用建议测试稳定后把Skill放进自己常用Agent的Skills目录即可。我还习惯给每个Skill配一个version字段方便回滚和对比。如果是在团队里推广建议把SKILL.md和脚本放在一个独立仓库里并写一个团队的Skill索引文档——新成员拉下来直接用比口头传经验高效得多。这也是“技能沉淀”真正的意义所在经验不会被某个人带走而是留在了团队资产里。5. 主流平台的Skill实现差异Codex、Claude Code、Trae、LangGraph5.1 OpenAI Codex的Skill载体与分发方式OpenAI Codex里提到的Skill更多是作为一种“可分发能力包”的格式存在。它的核心思路是你可以把一个Skill的代码、说明、prompt模板打包成标准目录挂载到Codex的配置中让编程Agent在处理仓库任务时自动加载对应技能。这个机制很适合团队内部把“代码规范检查”“依赖升级”“自动化测试生成”这类工程实践固化下来。Codex的Skill高度依赖代码仓储结构所以如果你主要用它做代码仓库治理Skill里嵌入脚本逻辑的比例通常要高于Claude生态。5.2 Claude Code与Agent Skills的组织形式Claude这边的Agent Skills体系更接近我前面展示的SKILL.md模式Markdown文档负责说明脚本负责执行目录结构清晰一个目录就是一个Skill。社区里流传的drawio skill、ppt skill基本都是这套结构。Claude的Agent对环境感知能力强同一个Skill在它手里能表现出更强的“临场发挥”能力所以就更需要说明书把规范写细写死否则输出会非常天马行空。我的经验是用在Claude生态的Skill一定不要省略“禁忌”和“输出格式”这两节——它对这两节的遵循度直接决定最后结果的可用度。5.3 Trae与国产IDE的Skill生态国内开发者对Trae的Skill更熟悉它在AI原生IDE里做了很贴近编辑场景的Skill落地。Trae的Skill往往偏“编辑器内任务”根据代码自动生成注释、按项目风格重构代码、一键生成单元测试、分析代码复杂度等。这类Skill的一个特点是它们和IDE的上下文贴得很紧——说明书里经常引用《当前打开文件》《选中代码块》这类实时变量让AI能更快理解领域上下文。国产IDE生态的Skill还有一个特点分享文化强很多人会在社区直接发布已经调试好的Skill文件几乎就是“复制-粘贴-用”的节奏。但社区Skill质量参差不齐使用前建议先做一次样本测试再放进生产环境。5.4 LangGraph中如何“组装”Skill逻辑热搜词里“langgraph 怎么增加skill”问的人不少。LangGraph本身没有内置“Skill”这个概念它的核心抽象是图Graph和节点Node。如果你想把“Skill”逻辑融入LangGraph标准做法是把一个Skill拆成“该不该用”的判断节点和“负责执行”的执行节点。判断节点接入LLM让模型根据用户请求做路由执行节点里加载对应脚本或调用工具函数并把结果传给下游节点。本质上你在LangGraph里是用“节点路由”实现了Skill的效果灵活性更高但也意味着你需要自己处理状态管理和失败重试不像前两个平台开箱即用。平台Skill组织方式适合场景上手难度OpenAI Codex目录打包偏好脚本嵌入代码仓库自动化中Claude Code / Agent SkillsSKILL.md 资源目录通用任务、内容类、分析类低Trae 等国产IDE编辑器上下文Skill编程辅助、代码重构低LangGraph用节点和路由模拟自定义Agent流程高如果你只是想快速在已有Agent里加一个技能Claude和Trae的体验最顺如果你在搭建自己的Agent应用LangGraph的组装方式给你最大的控制权但也意味着更多的设计工作。6. 我在Skill开发中踩过的坑以及“好Skill”的评判标准6.1 我写过的“失败”Skill错在哪我最早写Skill时犯过三个典型错误列出来当反面教材。第一个错误description写得太“虚”。当时写了一个通用写作Skill描述写“帮助用户完善文本提升表达质量”。听起来没错但这是个“永远匹配”的描述——每天都会被触发AI在用户聊任何话题时都想往写作上引最终变成了一个多余的干扰器。这个教训后来很管用description里一定要写清楚“什么时候用”更要写清楚“什么时候不用”。第二个错误把全部逻辑压在AI身上。早期写的Skill里没有脚本所有步骤都要求AI自己“做”。比如让AI直接分析一个20MB的日志文件结果就是AI很难处理输出靠猜完全不可用。后来我才学会把重活交给代码给AI“计算器”而不是让它心算。第三个错误没有定义可校验的输出。Skill生成的报告AI每次都换格式下游没法自动化处理。直到我在SKILL.md里明确规定输出字段和格式并把质量检查列成显式清单后这个问题才根治。6.2 好Skill的四个判据经历了几轮失败和重构我对“好Skill”有了自己的标准现在写新Skill都会拿这四条卡一遍。第一“该用的时候必被触发不该用的时候绝对安静”。这是衡量description质量的核心标尺。调一次触发调两次不触发AI就像手里揣着锤子看什么都像钉子那是灾难。第二“确定性逻辑由代码负责”。凡是能脱离模型独立完成的操作全部进脚本。脚本的聚合同理心来做AI只做真正的判断和表达。一个人力工做苦力、AI做资深的组合才是Skill的理想形态。第三“输出边界清晰格式稳定”。Skill的产出物不管谁来调用、调用几次结构应当一致。这样下游能做自动化处理也能跟其他Skill串联组装。第四“可测试可迭代”。好Skill一定留了质量检查清单和迭代记录维护的余地。如果一份SKILL.md写得太笼统迭代时无从下手最终会慢慢腐烂变成没人用的僵尸资产。6.3 从抄到写Skill开发的成长路径Skill开发入门我的建议是“先抄、再拆、后写”。先用别人验证过的Skill比如各种社区里流传的PPT Skill、日志分析Skill、写作润色Skill跑通一遍去看它的SKILL.md怎么组织、脚本边界在哪里、输出格式怎么定。然后把你手头高频重复的任务拆成小模块——凡是超过两次重复的就有封装的价值。最后再按照“描述-流程-输出-禁忌”四段结构写自己的Skill。整个过程不需要太多前置知识几个月就能形成自己的方法论。6.4 顺便回应热搜里的几个幺蛾子写到最后还是想回应一下前面提到的热搜词乱象。“skill女生向百度云”“skill原版无删减版”这类搜索大概率与AI技术无关搜出来的东西也不是这篇博文想讨论的。倒是“去ai味的skill”“humanizer skill”这类词确实对应着AI应用层一个真实需求让AI写出来的东西更像是人写的。这类Skill的说明书里通常会内置“避免AI框架词”“减少并列排比”“加入口语化连接”等规则本质上也是把写作经验固化成SOP——这件事本身就很值得玩味我们在用SOP让AI产出“不像SOP的内容”这大概是Skill范式里最有趣的一个缩影了。至于“前任skill”“clown skill”“matt skill”这些词有的指向个人博客、有的指向娱乐内容严格说它们蹭了“skill”这个词的热度但和Agent技能开发基本不搭界。真正的Skill不是为了造一个可以炫耀的“技能收藏夹”而是为了每次遇到同类问题时都能少踩一个重复的坑。我的经验是开始写Skill之后你会在两个地方产生质变——一是你对自己工作流的抽象能力明显提升了二是你对“重复劳动”的容忍度断崖式下降了。后者尤其致命它会让你的下一个工作日变得非常想写新Skill。