其实最近这个圈子风向变得很快前一阵大家还在比谁的Prompt写得更花哨最近又开始批量生产一种叫“Skill”的东西。打开社区满屏的Codex Skill、Claude Skill、Agent Skill一堆人拿着各种“技能包”到处分享仿佛不会写个Skill就落伍了。但说实话我翻了很多所谓“Skill”之后发现大部分人压根没搞清楚这东西到底是什么。有人把一段Prompt换个后缀名就叫Skill有人把整个项目的说明文档塞进去当Skill用还有人把一堆Skill像套娃一样互相嵌套最后跑起来又慢又蠢。这不是在用好Skill这是在滥用Skill。要搞清楚这件事得先把Skill的底裤扒干净。我不太喜欢那种云里雾里的概念解释直接讲本质、讲结构、讲工程实现最后聊聊什么样的情况根本不该用Skill。这篇内容适合正在折腾AI编程工具、想自定义Agent能力的人也适合团队里负责沉淀AI工作流的同学。看完你至少能避免90%的“伪Skill”需求。1. 先搞清楚Skill到底是什么不是什么1.1 从“技能”这个词开始拆Skill翻译成中文是“技能”这个词本身就有误导性。你脑子里想到技能可能是会做饭、会游泳、会写代码——一种内化在个体身上的能力。但AI世界里的Skill本质上不是能力而是能力的说明书加工具箱。我习惯把Skill理解成三样东西的组合一份极其详细的“操作手册”、一组可供调用的“工具/文件/脚本”以及一层触发条件。大模型本身有通用能力但它不知道在特定场景下该按什么顺序、用什么参数、遵守什么约束去做事。Skill就是把这些“特定场景下的做法”封装成一个可复用的单元让模型在遇到对应任务时按照预设好的路径走。举个直观的例子。让一个通用大模型直接分析服务器日志它能给你分析但它不知道你们团队习惯用什么样的格式输出、不知道先做时间聚合还是先做错误码分类、更不知道要自动关联哪些历史故障记录。你把这些东西写成一份文档放在Skill目录里再配上一个提取错误码的小脚本模型在碰到日志分析任务时就会自动加载这套规则产出的结果就非常稳定。所以Skill的本质是什么是把“知道怎么做”从模型脑子里搬到模型面前。它解决的不是模型笨不笨的问题而是模型不知道“在这个场景下具体该怎么做”的问题。1.2 Skill与Prompt、Plugin、Workflow、Agent之间到底差在哪这是社区里被问得最多的问题“Skill和Prompt有什么区别”“Skill和Plugin是不是一回事”“我有了Agent还需要Skill吗”也有大量热搜词反映大家卡在这里。我把这几个概念拉一张表一眼就能看懂区别。概念我理解的核心形态典型使用方式Prompt一次性指令教模型做某件事文本每次对话里粘贴或通过系统提示注入Skill可复用的场景化能力包含文档、脚本、约束目录文件代码按目录存放由Agent按需加载Plugin给程序扩展API能力代码/接口作为工具函数供模型调用Workflow编排固定流程不由大模型自由发挥有向图/步骤链任务按预设步骤执行Agent一个能自主决策的对象可以是以上所有东西的容器系统接收目标、调用工具、自我修正这里的关键区分点在于“是否复用”和“是否存在独立封装”。Prompt是一次性的今天写明天就不一定记得Skill是放在那里随时可以重复调用的。Plugin更偏底层能力扩展比如给模型加一个“读Excel”的能力Skill则是更高一层的编排它可以透过后端调用Plugin但Skill本身更像是一套“教你怎么用这些能力”的方案。至于Agent和Skill的关系可以这么理解Agent是那个干活的人Skill是这个人脑子里的“武功秘籍”。一个人再聪明如果没有针对某类任务的成体系做法效率也不会高反过来秘籍再多没有那个能判断“当前该用哪本秘籍”的Agent秘籍就是废纸。1.3 为什么今年Skill突然爆发了这个时间节点其实很有讲究。最早把Skill概念做火的是Claude Code那一波Agent工具紧接着OpenAI的Codex又把Skill机制标准化形成了SKILL.md那种“目录说明脚本”的结构。说白了是编程Agent的普及把Skill推上了台面。原因很简单当Agent开始真正接手一个完整任务而不只是一问一答时它需要稳定输出。稳定输出靠什么靠约束。Prompt给不了强约束因为它在长上下文里很容易被稀释、被遗忘、被优先级更低的对话内容冲掉。Skill则不同它是以“被加载的模块”形式存在的Agent在决定“要用这个技能”时会把整套内容作为高优先级的上下文引入效果远好于几百行系统提示词。还有一个原因就是复用和分享。Prompt的分享价值很低复制粘贴十次可能有十个变形Skill是按目录封装好的完整单元复制过来就能用甚至可以带上脚本和配置文件。这种形态天然适合社区传播也是热搜里出现“skill推荐”“skill开发”“如何写一个skill”这类词的根本原因。2. 深入解剖Skill的结构一个好用的Skill由哪几层构成如果你打开一个写得比较成熟的Skill会发现它不是简单的一堆文字而是分层的。我自己拆解下来一个可靠的Skill至少包含五个层次指令层、上下文知识层、能力层、校验层、元信息层。缺了哪一层这个Skill都容易在真实使用中翻车。2.1 指令层明确规定执行步骤和边界指令层解决的是“按什么顺序做什么事”。很多人写Skill时最容易犯的错就是把指令写得太虚比如“分析日志并给出报告”。这句话模型看完根本不知道该从哪下手。合格的指令应该精确到动作序列。我做日志类Skill的时候指令层是这么写的先统计日志总行数和时间跨度判断是否存在缺失时间段。按错误等级ERROR/WARN/INFO聚合数量。对ERROR级别的日志提取错误码和堆栈摘要。检查错误码是否出现在已知故障特征库中。输出分析报告按“结论、证据、建议修复方向”三部分组织。这套指令是把经验提炼成了流程。它不允许模型自己“自由发挥”另起炉灶这样产出的多次分析结果才具备一致性和可比性。指令层写不好后续所有输出都飘。2.2 上下文知识层让模型在正确的范围内思考模型训练时学到的知识是通用的但它缺“我们这个具体环境”的知识。比如你们公司的日志格式里“code10086”代表网络抖动这种组织内部约定外部模型不可能知道。上下文知识层就是把这些约定、背景、规范放进来。需要注意一个度的问题。知识层不是越多越好我见过有人往Skill里塞几百页的运维手册结果模型每次调用时都被海量背景信息干扰反而抓不住重点。好的做法是把知识信息拆成两类一类是必须读的约束性信息直接写在SKILL.md正文里另一类是遇事才查的参考信息放到references目录里让模型按需检索。“遇事才查”这个机制能显著降低上下文占用同时保证知识覆盖面。2.3 能力层把模型的短板用代码补上模型的文本理解能力很强但做精确计算、正则匹配、批量文本处理这类事情并不可靠。能力层就是为模型准备的“外挂工具”通常是一组Python脚本或其他可执行程序。我写日志Skill时能力层放了一个脚本专门负责从原始日志中提取时间序列和错误码统计。模型不需要自己数日志行数它只要调用脚本得到结构化结果再基于结果做分析判断。这一下就把大模型的“幻觉空间”压缩了——数字都是脚本算出来的模型只负责解读出错概率大幅下降。能力层的另一个价值是校验。脚本可以预检数据质量比如判断日志格式是否包含时间戳、是否有乱码文件等提前把脏数据拦截在外面避免模型基于错误数据得出荒谬结论。2.4 校验层输出结果自动过一道“质检关”很多Skill写了一版之后就再也不管了这是不对的。一个成熟的Skill应该在输出环节设置校验机制。最简单的校验是“自检清单”比如分析报告必须包含数据来源、统计窗口、样本数量、结论置信度、局限说明。模型在输出前逐项打勾未达标的强制补充。进阶一点的校验是写一段脚本自动去检查模型生成的报告字段是否完整、引用的数字是否与计算结果一致。这种自动校验适合输出结构固定的场景。校验层意义在于它能兜住模型偶尔的思维滑坡保证下游拿到的是可用的产出。2.5 元信息层决定Skill“什么时候被想起”最后这层最容易被忽略但恰恰是最重要的。元信息层就是描述这个Skill是干什么的、在什么场景下使用、和哪些关键词强相关。Agent判断要不要启用某个Skill靠的就是对这部分信息的匹配。写得太模糊Agent会绕开你的Skill写得太窄又可能漏匹配。我的习惯是给Skill起一个直白的名字比如“日志错误分析与故障定位”然后在描述里覆盖多种问法“分析日志”“查报错”“日志异常检测”“log分析”这些都写上。这样不同的提问习惯都能命中同一个Skill。3. 手把手实现一个日志分析Skill从零开始能跑通理论说了一堆现在进入工程实现环节。我直接拿我做过的一个“日志错误分析与故障定位”Skill当范例从目录设计、内容编写到集成测试全程走一遍。这套流程适配主流的Codex、Claude Code这类支持Skill机制的编程Agent也适用于通用Agent平台。3.1 先确定这个Skill要解决什么具体问题我在做这个Skill前正好被一堆线上日志折腾得头疼。系统日志分散在多台服务器每次排查问题时都要把日志拷下来肉眼搜索ERROR关键字再人工去对照错误码表。步骤重复、效率低下新来的同事还老是漏掉关键检查项。这个Skill的目标很清晰给定一份日志文件或日志目录自动化完成错误码提取、异常模式识别、根因推荐和报告生成。它服务的人群是后端开发、运维、SRE。我限定输入为文本日志格式常见的有应用日志、Nginx访问日志、系统日志。限定范围很重要一个企图解决所有日志类型的Skill最后往往什么都做不好。3.2 设计目录结构让Agent一眼就懂目录结构直接决定Agent加载这个Skill时的效率。我最终采用的是这种布局log-analysis-skill/ ├── SKILL.md # 主入口所有指令和引导都在这 ├── scripts/ │ ├── parse_log.py # 日志解析与统计脚本 │ └── error_classifier.py # 错误码特征匹配脚本 ├── references/ │ ├── known_errors.md # 已知故障特征库按需检索 │ └── log_format.md # 当前系统的日志格式说明按需检索 └── assets/ └── report_template.md # 输出报告模板为什么把references单独拆出来因为Agent加载Skill时SKILL.md是必读的而references下的内容是可以按需查阅的。如果所有背景知识全塞进SKILL.md一次任务还没开始干光引言就几百行既浪费token又干扰决策。这个“主文档精简参考文档按需读”的模式是我试过很多版之后最稳的组合。3.3 SKILL.md怎么写给一份可以直接抄的模板SKILL.md是灵魂。你会发现写得好的SKILL.md和写得烂的差别之大就像操作手册和论文摘要。直接看模板# 日志错误分析与故障定位 ## 功能概述 对应用日志文件进行错误码提取、异常统计、故障根因定位并输出结构化分析报告。适用于后端服务日志、Nginx访问日志、系统日志的快速排查。 ## 触发条件 当用户要求分析日志、定位故障、查看报错、统计错误码、排查线上问题时应优先使用本Skill。 ## 输入要求 - 用户提供日志文件路径或日志文本内容 - 日志格式应包含时间戳和日志级别ERROR/WARN/INFO - 支持单文件或多文件目录 ## 执行流程 1. 调用 scripts/parse_log.py 解析日志目录获取总行数、时间范围、各级别日志数量 2. 调用 scripts/error_classifier.py 提取ERROR日志中的错误码和堆栈摘要 3. 在 references/known_errors.md 中检索已知错误码对应的常见故障特征 4. 综合统计结果与特征库信息判断可能的故障根因 5. 按 assets/report_template.md 输出分析报告 ## 输出规范 报告必须包含以下五个部分 1. 分析范围日志时间跨度、文件数量、总行数 2. 核心指标各级别日志数量及占比ERROR变化趋势 3. 错误明细TOP5错误码、首次出现时间、影响范围 4. 根因推断基于特征库的匹配结果按置信度从高到低排列 5. 处理建议至少给出一个可执行的修复方向 ## 注意事项 - 禁止对未出现在日志中的内容做假设性推断 - 如果日志时间跨度超过24小时需分别按小时统计后再聚合 - 错误码匹配失败时在报告中单独列出“未识别错误码”并给出人工排查建议这份模板的关键在于“执行流程”和“输出规范”。前者规定了模型动作顺序后者规定了交付物结构。二者一约束输出基本就稳定了。你把这个结构套用到任何其他领域比如PPT生成、数据分析、代码审查逻辑都是相通的。3.4 能力层脚本宁可简单不要动不动上重型框架能力层的解析脚本我一开始是打算写一个很复杂的解析库后来发现完全没必要。日志分析核心就两个动作划分时间和统计错误码。写成一个两百行的Python脚本就够了。import os, re, sys from collections import Counter from datetime import datetime def parse_log_file(filepath): entries [] pattern re.compile( r(?Pts\d{4}-\d{2}-\d{2}[ T]\d{2}:\d{2}:\d{2}).*? r(?PlevelERROR|WARN|INFO) r(?:.*?code(?Pcode[A-Z0-9_]))? ) with open(filepath, r, encodingutf-8, errorsignore) as f: for line in f: m pattern.search(line) if not m: continue entries.append({ ts: m.group(ts), level: m.group(level), code: m.group(code) }) return entries def summarize(entries): levels Counter(e[level] for e in entries) codes Counter(e[code] for e in entries if e[code]) return levels, codes if __name__ __main__: target sys.argv[1] all_entries [] if os.path.isdir(target): for fname in sorted(os.listdir(target)): if fname.endswith(.log) or fname.endswith(.txt): all_entries.extend(parse_log_file(os.path.join(target, fname))) else: all_entries parse_log_file(target) levels, codes summarize(all_entries) print(fTOTAL_LINES{len(all_entries)}) for level, cnt in levels.most_common(): print(fLEVEL_{level}{cnt}) for code, cnt in codes.most_common(10): print(fCODE_{code}{cnt})这个脚本没什么高深的但它承担了两个模型干不好的事精确计数和正则匹配。模型分析时只需要读脚本输出的结构化摘要再结合特征库做推断。脚本的输出格式我故意设计成KEYVALUE的形式方便模型解析也避免它去猜字段含义。3.5 集成进Agent并完成首轮测试写完之后把整个log-analysis-skill目录放进Agent的skills目录。Codex和Claude Code的Skill目录机制在这点上非常相似都是将Skill名称作为目录名Agent在启动时会扫描目录索引遇到匹配任务自动加载对应SKILL.md。第一轮测试我准备了三个样本一个正常日志文件、一个带有已知错误码的故障日志、一个日志格式不规范的脏文件。测试下来前两个场景表现很好Agent正确调用了脚本并产出了报告第三个场景暴露出问题——日志解析失败时Agent没有主动告知“格式不支持”而是强行基于少量解析结果编了一版报告。这个问题触发了校验层的重要性我在SKILL.md里加了一条硬性规定“如果解析脚本返回的总行数为0必须在报告中明确说明输入格式不符合要求并拒绝继续分析。”3.6 一个迭代教训别让Skill吞掉过大的上下文第一版写完后我在references里塞了三十多个历史故障案例本意是想让模型参考。结果实测时明显感觉模型反应变慢因为是按需检索还好但只要有模糊匹配它就会把相近的故障案例全翻出来输出内容又长又杂。后来我把这些案例压缩成每案三行摘要只保留错误码、故障现象、原因定位、处理动作四个字段。效果立刻提升模型定位根因的速度快了不少。这个经验可以复制到任何Skill上references里的内容要做“摘要化”处理大模型和人类一样信息过载时反而做不出精准判断。4. 为什么你会滥用Skill我见过的四类伪需求与典型解法标题说了“不再滥用Skill”那什么算滥用我观察下来社区里大量所谓“Skill”存在明显问题。它们不是因为Skill机制好用才做而是因为“大家都在做”才做。这种跟风产物既浪费存储又拉低Agent整体效率。4.1 把Prompt模板换个后缀就宣称是Skill这是最泛滥的一类。网上看到很多“Skill分享”点进去就是一个几百字的prompt文件没有目录结构、没有脚本、没有参考资料。其实它就是一段高效的提示词本质上和以前收藏的“XXX提示词模板”没有任何区别。当然一个极简的Skill在某些情况下也能起作用比如你想固定某种写作风格。但既然走上了Skill这条路就应该按工程化思路去设计至少补上目录结构和触发机制。否则你只是在自欺欺人用一个更麻烦的方式管理Prompt。4.2 一次性任务被做成了永久Skill判断一个任务需不需要做成Skill我有个很简单的标准**这活儿你会不会在两周内再做第二遍**一次性的需求比如“帮我把这份PDF里的表格提取出来做成Excel”你做成Skill纯属画蛇添足。下次需求大概率换了一家公司、换了一个格式你的Skill完全用不上。我遇到过有人把一次项目答辩的PPT生成套路做成了“答辩PPT Skill”做的时候花了整整一下午。结果毕业后这个Skill再也没用过缩在那里纯占空间。这种情况的正确做法是先用手工Prompt跑一次如果发现过程可靠且未来会重复再沉淀成Skill。顺序不能反。4.3 Skill套娃一个Skill调用另一个Skill变成俄罗斯套娃有些人追求“复用”把一个Skill里的一部分抽取成子Skill然后在主Skill里引用子Skill。这思路听起来很工程化但它忽略了大模型Agent的实际工作方式。主线任务进行中Agent既要加载主Skill的指令又要跳出去加载子Skill的内容上下文切换频繁反而容易丢失重点。我在设计日志分析Skill时最开始也试图把“错误码分类”拆成独立Skill复用后来发现增加的结构复杂度远大于收益。更合理的做法是关联但独立的能力之间存在逻辑调用关系时用脚本去串联而不是用SKILL.md引用另一个SKILL.md。代码调用比模型跳转加载可靠得多。4.4 给简单任务强行设计复杂流程有些Skill的“执行流程”有十一二步每一步还夹杂着大量判断分支活生生把一件小事搞成了系统工程。我见过一个“写周报Skill”在正式写之前要先调研本周代码提交记录、会议纪要、客户反馈然后还要让模型自评哪项工作优先级高再动态生成三种风格的周报。听起来很强大实际使用时模型在每个分支里都要做大量决策耗时长还容易走偏。Skill的设计原则应该是“能三步走完的绝不写五步”。每一步都会消耗时间和上下文也会引入一步的出错概率。你加到十五步可控性不一定提升反而下降了。4.5 判断要不要用Skill的三个问题综合这些案例我现在决定要不要做Skill之前会先问自己三个问题这个任务是否有稳定的输入输出边界边界越清晰越适合做成Skill。这个任务未来一个月内我预计会遇到几次少于三次不配拥有Skill。现有Prompt方案是否已经支撑不了我要的质量如果现在用Prompt已经挺好就不要折腾。三个问题都过了再开始动手做Skill这样筛下来真正值得做的其实没那么多但每一个都能长期发挥作用。5. 衡量Skill好坏的五个维度以及主流平台的实现差异费劲做了一个Skill怎么判断它是真优秀还是假优秀别凭感觉按五个维度去打分基本能有个客观答案。同时我把Codex、Claude Code这类主流平台的Skill机制差异也过一遍避免你从A平台抄到B平台后“水土不服”。5.1 五个维度自检命中率、稳定件、泛化边界、可维护、可移植第一个维度是触发命中率。一个Skill如果反复出现“用户明明在问相关任务Agent却不调用它”的情况那元信息大概率写得有问题。第二维是输出稳定性同一份输入连续跑五次产出结构应该基本一致差异只应该在具体内容层面。第三维是泛化边界好的Skill能处理正常范围内的输入变体比如日志文件是.txt后缀也能识别而不会只认.log。第四维是可维护性Skill里的指令和参考文档能不能快速修改迭代脚本有没有清晰注释决定了你三个月后还愿不愿意更新它。第五维是可移植性好Skill应该能相对容易地从一个Agent平台迁移到另一个平台而不是深度绑定某个平台的私有格式。我在实战中会让队友给Skill打分每个维度1到5分。低于18分的Skill说明还没成熟不要对外分享误导别人。5.2 Codex Skill、Claude Skill与通用Agent Skill的差异目前使用体验下来平台之间确实有差异。Codex的Skill机制最为结构化它对SKILL.md的格式有比较明确的预期目录组织也规范适合团队内标准化沉淀。Claude Code的Agent能力很强Skill在加载时对语义理解的依赖更高也就是说它不只看关键词还会综合判断当前任务意图这意味着你的描述要写得“语义化”而不是“标签化”。通用Agent平台比如各类自建Agent框架则更灵活Skill可能就是一个可以被前端工具或后端服务调用的能力包与底层的函数调用绑定紧密。通俗来讲Codex更像“填空题”你按格式填好就行Claude Code更像“阅读理解”它要真正看懂你希望它在什么场景下做什么自建Agent则是“搭积木”怎么拼全看你的架构。了解这些差异能避免你拿着一套设计跑到另一个平台上去硬套。5.3 几个我踩过坑后的结论与技巧最后说几个实操细节。Skill目录命名千万不要用中文拼音缩写。我之前建过一个rzfx目录本意是“日志分析”结果Agent根本没法把这个目录名和日志分析任务关联起来白白浪费一次加载。后来老老实实用log-analysis命中率立刻上来了。SKILL.md开头建议写一段“功能概述”然后必须紧跟“何时使用”。这段文字是Agent判断是否加载的关键。我见过有人把触发条件藏在第五段模型根本看不到那么后面Skill形同虚设。还有一个小技巧在SKILL.md内部用“禁止”类句式要比“建议”类更有效。比如“禁止对未识别错误码进行猜测”模型遵守这种指令的概率远高于“建议对未知错误保持谨慎”。这是我在多次测试中得到的一个很有意思的规律。关于维护周期Skill不是写完就完事的。我建议每个Skill配套一个“版本更新记录”每次调整了执行流程或新增了脚本都要记录。三个月前我改了一个分析规则却没有更新文档导致后续好几份报告还按旧规则做排查了半天才发现是Skill过时了。自那以后版本记录就成了我做Skill的标配。说到底Skill是个好机制它让大模型从“什么都会点但什么都不精”变成了“在特定领域内像老手一样干活”。但它终究只是一个工具形态真正决定产出的还是背后那套经验总结和逻辑设计。用心打磨一个真正解决问题的Skill远胜于批量生产一堆没场景、没边界、没质量的三无技能包。