1. 为什么是Skill，为什么是8个岗位
先说结论：Skill方案是目前我个人体验下来，让AI稳定复用能力最靠谱的一条路，没有之一。
市面上的AI工具用了一圈之后，你会发现一个尴尬的事实：大模型本身的推理能力确实很强，但每次开新对话它就像失忆了一样，什么都要重新交代一遍。你让它写代码要重复粘贴项目规范，让它做视频脚本要反复强调风格偏好，让它查资料要重新教它怎么用搜索引擎。折腾一两次还能忍，天天这么干——说实话，不如回去用Excel模板。
后来我把目光转向了Agent Skill。它的核心逻辑很简单：把一套完整的“技能”打包成一个标准文件夹，里面包含提示词模板、脚本代码、参考资料和调用说明，让AI可以即插即用地调用。
我在实际使用中一口气给AI配了30多个Skill，然后把它们按照“生产环境”重新划分成8个岗位：内容创作岗、编程开发岗、数据分析岗、翻译润色岗、科研辅助岗、项目管理岗、媒介运营岗和个人助理岗。一个模型，8个工位，各司其职。
这篇文章不打算讲太多虚头巴脑的概念，我从30多个Skill的配置经验里挑出最核心的设计思路、开发要点和实际踩坑记录，给你一条可以直接复制的路径。适合正在用Claude、Codex等支持Skill机制的AI工具，并且想让AI真正稳定输出、而不是每次“抽奖”的朋友。
2. Skill的本质：不是插件，是“岗位说明书+工具箱”
很多人把Skill理解成AI插件，其实不太准确。插件通常是一段有明确输入输出接口的独立程序，而Skill更像是一份岗位说明书加配套工具箱。
2.1 Skill的目录结构到底长什么样
以Claude生态为例，一个标准Skill组件的目录结构长这样：
my-skill/ ├── SKILL.md # 技能说明，AI读取的核心入口 ├── scripts/ # 可执行脚本，比如Python、JavaScript │ └── generator.py ├── assets/ # 静态资源，模板、示例、图标 │ └── template.md ├── references/ # 参考资料，喂给AI的领域知识 │ └── style-guide.md └── requirements.txt # Python依赖SKILL.md是灵魂。里面写着这个Skill是干什么的、在什么场景下触发、需要哪些前置输入、应该按什么顺序执行哪些步骤、以及最终的输出格式是什么。AI每次加载这个Skill时，会先把SKILL.md读一遍，然后按照里面定义的流程干活。
我倾向于把SKILL.md类比成一个新员工入职时拿到的“岗位手册”——它不会教模型重新理解世界，但会告诉它“在我们这个岗位上，标准作业流程是什么，什么能做，什么不能做，交付物长什么样”。
2.2 Skill和Prompt的根本区别
我知道有人会说：这不就是一套写好的提示词吗？我自己在记事本里存一套不就完了？
表面看确实类似，但实际用下来差距很大。
第一，Skill是可编程的。普通提示词只能要求AI“按我的风格写”，Skill可以在scripts目录里放一个Python脚本，让AI先执行脚本去抓取数据、处理文本，再把结果交给对话模型做进一步生成。等于AI多了一双手，而不是只有一张嘴。
第二，Skill能自动触发。Claude Code检测到用户需求匹配某个技能时，会直接调用这个Skill，不需要手动粘贴任何东西。比如你输入“帮我查一下NVIDIA今天的股价”，它会自动调用内置的网络搜索Skill，先搜索再分析，一步到位。
第三，Skill是模块化可组合的。普通提示词只能整段复制粘贴，Skill之间可以互相调用。比如“数学建模Skill”负责推导公式，“代码生成Skill”负责把公式转化成计算程序，“论文润色Skill”负责把结果写成报告。三个Skill串成一条流水线，这是普通提示词做不到的。
2.3 哪些场景最适合用Skill
30多个Skill装下来，我总结出三类场景特别适合用Skill来增强：
- 标准化高频场景：比如内容翻译、代码审查、SEO文案生成。每次任务流程固定、输出格式要求统一，用Skill能保证每次交付质量都稳定。
- 需要外部工具协作的场景：比如AI需要读取本地文件、调用API、执行Python脚本做数据处理。这些能力模型本身不具备，必须靠Skill里的脚本来补。
- 需要领域专业知识注入的场景：比如专利写作、数学建模、医疗问诊辅助。这类任务对知识的时效性、深度要求高，可以通过Skill的references目录把资料库喂给模型。
不适合的场景也有：纯闲聊、需求极度个性化的一次性任务、需要实时学习用户偏好的场景。这些场景下Skill反而会拖慢响应速度，给人“杀鸡用牛刀”的感觉。
3. 实操：Skill开发与配置全记录
这一部分我直接讲开发流程。按照这个流程走，你不需要完全理解AI底层的运行机制，也可以做出能稳定工作的Skill。
3.1 环境准备与工具选型
我推荐在本地使用Claude Code，也可以选用Codex，两者都原生支持Skill机制。
安装步骤这里不啰嗦，重点说一下目录配置。在项目根目录下创建：
mkdir -p .claude/skills每一个Skill就是一个子目录，命名建议用小写字母加中划线，例如code-reviewer、>--- name: code-reviewer description: 对代码提交进行系统性审查，发现潜在的Bug、安全隐患和性能问题，并输出结构化审查报告。 --- # 代码审查专家 ## 适用场景 - 提交代码前需要做一轮自动化检查 - 希望从安全、性能、可维护性三个维度得到反馈 ## 输入要求 - 代码文件路径 - 审查深度（快速/标准/深度） ## 执行步骤 1. 读取目标代码文件 2. 识别语言和框架类型 3. 按照安全审查清单逐项检查 4. 输出结构化报告（分数+问题清单+修复建议） ## 输出格式 - 报告使用Markdown格式 - 每个问题标注严重级别（Critical/Warning/Info） - 修复建议必须附带代码示例
这段内容看起来不长，但AI会严格按照这个顺序来执行。关键有三点：
- description字段要写清楚“什么场景触发这个Skill”，比如“当用户要求审查代码时”，AI才会在合适的时机自动调用。
- 执行步骤要拆得足够细，越细的步骤越不容易让AI自己发挥跑偏。
- 输出格式必须结构化，AI是概率模型，你不给它明确格式，它每次都给你交一个不同风格的结果，那Skill就没有意义了。
3.3 给Skill配一个真正的“手”和“眼睛”
SKILL.md解决的是“AI知道怎么做”的问题，但很多任务光靠语言模型是完不成的。比如你要让AI分析一个Excel文件，它自己读不了二进制，这时候就需要在Skill里写一个Python脚本，把Excel解析成文本，再交给AI处理。
我在实际配置中给“数据分析岗”的Skill加了一个脚本，负责完成数据预处理：
import pandas as pd import sys def main(): input_file = sys.argv[1] output_file = sys.argv[2] # 读取Excel文件 df = pd.read_excel(input_file) # 基础统计信息 summary = { "列名": list(df.columns), "行数": len(df), "缺失值统计": df.isnull().sum().to_dict(), "数据描述": df.describe().to_dict() } # 输出为文本供AI读取 with open(output_file, "w", encoding="utf-8") as f: for key, value in summary.items(): f.write(f"## {key}\n") f.write(f"{value}\n\n") if __name__ == "__main__": main()这段脚本做的事情很朴素：把Excel的表格结构和基础统计信息输出成文本文件。但它解决了一个大问题——AI不需要直接读二进制数据，只需要读这个文本摘要，就可以做出相对靠谱的数据分析。
这就是Skill的威力所在：语言模型负责思考框架，脚本负责脏活累活。
3.4 Skill的测试与调优流程
Skill写完之后，至少要经历三轮测试：
- 第一轮：功能测试。找一个典型的任务场景跑一遍，看AI是否正确调用了Skill、是否完整执行了步骤、输出格式是否符合预期。
- 第二轮：边界测试。换一个你预计AI可能会犯难的输入，比如超长文本、格式不规范的输入、或者明显超出Skill能力范围的需求，看AI会不会优雅降级。
- 第三轮：兼容性测试。同时加载多个Skill，确认它们之间会不会互相干扰。我在实际操作中就遇到过两个Skill互相打架的情况，一个让AI用Markdown输出，另一个要求JSON格式，结果AI左右为难直接报错。
调优的核心思路是：出现问题，兜底手段永远是改SKILL.md，而不是修改模型。模型是固定的，Skill是自己的，哪里不对改哪里。
4. 8个岗位，30多个Skill：我的岗位配置表
下面是我实际在用的岗位架构。每个岗位我挂了2到6个Skill，总计30多个，但核心运行逻辑是清晰的。
4.1 岗位清单与Skill对照总览
| 岗位 | 挂载Skill示例 | 解决的核心问题 |
|---|---|---|
| 内容创作岗 | 爆款标题生成、结构化写作、SEO关键词布局、内容改写降重 | 解决从零开始写稿难产的问题 |
| 编程开发岗 | 代码审查、Bug定位修复、架构设计、代码注释生成 | 让AI从“能写代码”进化到“写出规范代码” |
| 数据分析岗 | 数据预处理、图表解读、SQL查询生成、统计建模 | 让AI直接对接数据文件，而不是只吃你投喂的文字 |
| 翻译润色岗 | 专业术语库翻译、学术润色、口语化改写 | 解决不同场景下“语气不对”“术语不准”的问题 |
| 科研辅助岗 | 论文结构生成、文献综述整理、数学建模、专利辅助 | 把科研流程中的重复性工作交给AI |
| 项目管理岗 | WBS任务拆解、甘特图生成、风险清单检查、会议纪要 | 解决需求模糊、执行无计划的问题 |
| 媒介运营岗 | 视频脚本分镜生成、自媒体标题优化、热点追踪 | 支撑短视频、图文等多平台内容发布 |
| 个人助理岗 | 日程安排、邮件起草、本地文件检索 | 让AI更深度介入日常工作流 |
4.2 岗1：内容创作岗
内容创作是我最常用的岗位，挂了6个Skill。
其中爆款标题生成Skill我调了几十次参数。核心机制是通过SKILL.md内置一个标题池（我手动收集了1000个高点击标题），让AI分析这些标题的共性模式，然后结合当前文章主题，生成10个备选标题。实际效果比直接对AI说“帮我想几个标题”好非常明显——因为AI有了具体的参照系，而不是凭空发挥。
还有一个值得一提的内容改写降重Skill。它的思路不是单纯替换同义词，那样很容易被检测工具识别出来。我让它采取“结构重构+逻辑重排+案例替换”三层策略：保留原文核心观点，但改变段落组织顺序、替换论证案例、重新组织过渡语句。这个Skill在写公众号文章时非常好用。
4.3 岗2：编程开发岗
编程开发岗是Skill价值最直观的岗位。
代码审查Skill的SKILL.md里，我内置了一份安全审查清单，覆盖了SQL注入、硬编码密钥、不安全的反序列化这些常见问题。AI审查之后会生成一个结构化的审查报告，标注每个问题属于“严重/警告/提示”中的哪个级别，并给出修复代码示例。
还有Bug定位修复Skill，它的工作流程设计得很像真实程序员排查问题的思路：先要求AI复现Bug，再圈定可能的出错模块，生成测试用例验证假设，最后提交修复后的代码。这样做显著降低了AI“凭空猜答案”的概率。
4.4 岗3：数据分析岗
数据分析岗对Skill的依赖最强，因为纯语言模型在数据处理上有天然短板。
我的数据预处理Skill内置了两个Python脚本，一个负责文本清洗，一个负责Excel/CSV解析。AI会先调用脚本，把原始数据转成结构化文本摘要，基于摘要再给出分析结论和SQL查询建议。团队里不太懂SQL的业务同学，现在直接说需求，AI就能自动生成查询语句。
业内关于这个方向的讨论很多，我补充一个判断标准：如果你发现AI经常在数据分析任务上“一本正经地胡说八道”，多半不是模型能力问题，而是缺少一个把真实数据转成文本输入的脚本。加上脚本之后，幻觉概率会明显下降。
4.5 岗4：翻译润色岗
翻译润色岗是门槛最低、但最容易做出差异化的岗位。
基础翻译Skill不用多说，真正体现Skill优势的是专业领域翻译。我建了一个专利翻译Skill，在references目录里放了一份《专利审查指南》要点摘要和常用词汇对照表。AI翻译时先加载这份对照表，再对长句进行结构拆分，最后按专利语言的表达习惯重组句子。
效果最直观的例子：原来把“所述装置包括一个与第二连接件相耦合的第一连接件”这类句子翻成英文，AI经常把耦合关系搞反。加入Skill后，在术语表里定义了耦合（coupled）、连接（connected）、固定（fixed）的不同关系含义，从此这类错误再也没出现过。
4.6 岗6：科研辅助岗
科研辅助岗的Skill设计需要用到专利、论文等专业数据。这里要特别说明：所有Skill内容都基于公开可查的学术规范和写作规则，帮助用户提升文献整理和结构规划效率，不涉及任何未公开数据或不当用途。
数学建模Skill比较典型。它的SKILL.md内置了一套建模方法论：理解问题、设定假设、构建模型、求解验证、敏感性分析、撰写报告。AI接到一个建模题目后，会严格按这个框架推进，而不是上来就写公式。实际参加数学建模竞赛的朋友反馈，这套流程至少省了一天的试错时间。
论文结构生成Skill的思路是把学术论文拆分到段落级别。每个章节需要包含什么要素、每个段落应该承担什么功能、引言该怎么从宽泛背景引入到具体问题，都写进了SKILL.md。AI生成的结构性大纲可以直接作为论文写作的骨架。
4.7 岗7：媒介运营岗
媒介运营岗的Skill主要围绕短视频和自媒体展开。
我用一个短视频脚本分镜Skill同时支撑“短剧制作”和“漫剧制作”两类需求。它把脚本生成拆成了五步：确定主题、设计剧情冲突、拆分镜头、写台词、配拍摄建议。SKILL.md里还内置了几种常见的短剧叙事模板，比如反转、误会、逆袭。AI按模板生成，比自由发挥稳定太多。
还有一个自媒体标题优化Skill，专门用来解决“发布前怎么改标题才能提高打开率”的问题。它的逻辑是：输入初稿标题，AI先抽取出核心卖点词，然后根据情感共鸣、数字冲击、悬念制造、反常识等不同策略，重新排列组合，生成6个优化版本。
4.8 岗8：个人助理岗
个人助理岗挂载的Skill数量不算多，但使用频率极高。
日程安排Skill是我自己写的一个轻量级脚本，核心功能是读取智能设备中已同步的日历文件，解析出未来一周的时间段，再根据AI对任务优先级和耗时的判断，自动生成日程推荐。它注重的不是“帮我把会议记录一下”，而是“通过理解我手头任务的轻重缓急，主动给出时间分配建议”。
本地文件检索Skill则解决了一个日常痛点：AI默认没有访问本地文件的能力。我在Skill里封装了一个基于Python的文件索引脚本，用TF-IDF算法对指定目录下的文档建立关键词索引，AI搜索时先跑脚本，再基于索引结果回答问题。这样问“我上个月写的关于用户增长的方案在哪”这类问题时，AI不再是一脸茫然。
5. 30多个Skill遇到过的坑：常见问题与排查技巧
装了30多个Skill，踩坑是必然的。下面这些问题的通用性很强，大概率你也会遇到。
5.1 问题速查表
| 症状 | 可能原因 | 解决方案 |
|---|---|---|
| AI根本没有调用Skill，直接凭记忆回答 | description写的触发条件不够明确 | 重写description，写明“当用户请求X且上下文包含Y时” |
| Skill被调用了，但输出格式混乱 | SKILL.md里的输出格式描述太模糊 | 补上明确的输出模板和示例 |
| Skill执行到一半卡住、不继续 | 步骤拆得太粗，AI不知道该怎么做 | 细化执行步骤，每个步骤都给出可操作的指令 |
| 脚本执行报错，AI不会排错 | requirements.txt缺少声明或版本冲突 | 锁定依赖版本，并在SKILL.md写入异常处理指引 |
| 多个Skill同时触发，互相打架 | Skill各自为政，没有分组和优先级 | 在SKILL.md里加入“如果检测到X类任务，不要执行本技能”的声明 |
| context窗口太小，Skill文档太长被截断 | references里塞了太多资料 | 精简references，只保留核心摘要，长文放链接或路径 |
5.2 最常见的问题：Skill不生效
几乎所有人第一次用Skill都会遇到“AI不调用它”或者“调用了但像没调用一样”的情况。
有一次我辛辛苦苦写了一个代码审核Skill，在测试环境里跑得好好的，但一放到实际项目里就失灵了。AI明明看到了我的代码，却根本没有调用审核Skill，而是直接用自己内置的代码理解能力给了一堆泛泛的建议。
排查了一圈发现，问题出在description的触发条件写得不够具体。我写的是“审查代码质量”，这个描述太宽泛了，AI对“什么是审查”有它自己的理解。后来我改成“当用户请求对指定代码文件进行逻辑安全、性能、可维护性审查时使用”，触发准确率一下子从50%不到升到了90%以上。
核心经验：description和SKILL.md里的“触发规则”越具体，AI的判断就越准确。
5.3 脚本报错别急着改代码，先看异常类型
Skill脚本报错时，AI的应对方式也会因模型不同而产生差异。有些模型会自己尝试看错误堆栈、调整依赖再重试，有些则只会把错误信息甩给你。
我的建议是：在SKILL.md里写进一条明确的指令——“遇到脚本异常时，先读取完整异常堆栈，判断是依赖缺失、数据格式问题还是逻辑错误；如果是依赖问题，检查requirements.txt；如果是数据格式问题，打印数据schema并尝试字段名映射；如果连续两次修复失败，主动向用户说明并提供临时替代方案”。加了这条指令之后，AI不再遇到报错就“躺平”，而是会像真正的工程师一样按流程排查。
5.4 踩过坑后的独家避坑技巧
这里写几个一般文档里不会说的细节：
Skill目录里不要放太大的资源文件。AI的上下文窗口是有限的，你放一个2MB的参考文档进去，它可能根本读不完，反而挤占了本可以用于任务执行的token。原则是：核心资料压成3000字以内的摘要，详细资料放在项目本地，需要用的时候让脚本去读。
“肾虚式”Skill比“完美主义”Skill好用。一开始我总想把一个Skill做到覆盖所有边界情况，结果SKILL.md越来越长，AI的执行效率越来越差。后来改成“最小可用”原则：只定义最核心的30%场景，保证80%的常见情况都能稳定处理，剩下的靠AI自由发挥兜底。
Skill之间要互相隔离。不同岗位的Skill尽量不要引用同一个临时文件或共用一个脚本环境。AI执行时可能并行触发多个Skill，共享资源会带来不可预知的冲突。我给每个Skill单独设置了工作目录和临时文件前缀，冲突问题从此绝迹。
Skill的版本管理极其重要。我用Git管理所有Skill文件，每次改完SKILL.md都会提交一个commit，并写好改动说明。因为AI的行为对SKILL.md的措辞变化极其敏感，有时候只是把“必须”改成了“建议”，输出结果就完全不同。没有版本管理，你根本不知道是哪一次改动导致了问题。
6. 从造Skill到造团队：我的体会与建议
最后聊点实操之外的东西。
装了30多个Skill之后，我最强烈的感受是：AI的使用方式正在从“对话”走向“组织”。
以前我开一个对话窗口，等于临时雇一个什么都会一点但什么都不精的自由职业者；现在我有了一套固定的岗位架构，每个Skill就是一份岗位职责书，AI像是一个能无缝切换多个职位的超级员工。你给它安排“内容创作岗”的任务，它自动切换到那个岗位的工作流；你给它安排“编程开发岗”的任务，它自动调用代码审查的规范。
这个思路如果推而广之，其实可以复制出很多种岗位组合。比如你是一个独立开发者，可以试着配置“需求分析岗、后端开发岗、前端开发岗、测试岗、部署运维岗”五个岗位；你是一个自媒体创业者，可以配置“选题策划岗、脚本创作岗、剪辑脚本岗、多平台分发岗、数据分析岗”。Skill的力量不在于单个技能的精度，而在于多个技能组合之后形成的“团队协作感”。
我个人在实际操作中的体会是，测算一个AI+Skill体系好不好用，不要看它单次回答的质量，要看它连续完成一整条工作流的能力：今天让它查资料，明天让它写方案，后天让它做表格，最终交付一份可以直接用的成果。只有在这个层级上，Skill的稳定性优势才会真正体现出来。
最后再分享一个小技巧：刚开始别贪多，先挑一个你每天都会重复做的任务，做一个Skill，用一周，迭代到第六版，然后再复制这套方法论去扩展其他岗位。我目前的30多个Skill里，有50%是前两周做出来的，另外50%是在用了三个月之后才补齐的。先跑通一条最小闭环，比盲目堆数量重要得多。
