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 哪些场景最适合用Skill30多个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, encodingutf-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的力量不在于单个技能的精度而在于多个技能组合之后形成的“团队协作感”。我个人在实际操作中的体会是测算一个AISkill体系好不好用不要看它单次回答的质量要看它连续完成一整条工作流的能力今天让它查资料明天让它写方案后天让它做表格最终交付一份可以直接用的成果。只有在这个层级上Skill的稳定性优势才会真正体现出来。最后再分享一个小技巧刚开始别贪多先挑一个你每天都会重复做的任务做一个Skill用一周迭代到第六版然后再复制这套方法论去扩展其他岗位。我目前的30多个Skill里有50%是前两周做出来的另外50%是在用了三个月之后才补齐的。先跑通一条最小闭环比盲目堆数量重要得多。 AI Skill实战指南：从8个岗位配置到30多个技能的系统设计
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 哪些场景最适合用Skill30多个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, encodingutf-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的力量不在于单个技能的精度而在于多个技能组合之后形成的“团队协作感”。我个人在实际操作中的体会是测算一个AISkill体系好不好用不要看它单次回答的质量要看它连续完成一整条工作流的能力今天让它查资料明天让它写方案后天让它做表格最终交付一份可以直接用的成果。只有在这个层级上Skill的稳定性优势才会真正体现出来。最后再分享一个小技巧刚开始别贪多先挑一个你每天都会重复做的任务做一个Skill用一周迭代到第六版然后再复制这套方法论去扩展其他岗位。我目前的30多个Skill里有50%是前两周做出来的另外50%是在用了三个月之后才补齐的。先跑通一条最小闭环比盲目堆数量重要得多。