直接上手玩了几个月 ChatGPT Skill说实话这东西刚出来的时候我以为是套壳提示词用完之后才发现完全不是一回事。它本质上是把“提示词脚本工具调用自动化流程”打包成一个可复用的技能包相当于给 AI 预装了一套业务逻辑省掉你每次重复输入的上下文。这篇文章不聊概念营销只谈实际怎么用、怎么配、怎么排查报错以及几个我踩过坑后总结出来的经验。适合所有在用 ChatGPT 桌面端、Codex CLI 或者想系统化整理提示词的人尤其是那些频繁用 AI 做同类型任务、又不想每次重新调教对话的人。1. 内容整体设计与思路拆解1.1 Skill 到底是什么和普通提示词有什么本质区别很多人第一次看到 ChatGPT Skill 的概念第一反应是“这不就是自定义指令吗把一段预设提示词发给 AI 不就行了”。我最初也是这么想的但实际用下来发现两者完全是两个维度的东西。普通提示词是“一次性”的。你把一段文字发给 ChatGPT它根据这段文字给出回应。下次新开对话历史记录清空你又得把这段提示词重新粘贴一遍如果提示词很长这个操作会让人非常崩溃。更重要的是提示词只能约束对话层面的行为它无法真正触发某些系统动作比如读取某个文件、遍历目录、调用本地脚本、执行一段外部工具链。ChatGPT Skill 则是“可复用、可执行、可挂载”的。它在 ChatGPT 桌面端和 Codex CLI 中有一个实质性的运行环境。Skill 包里面不只是文字还包含一块 SKILL.md 文件作为指令核心外加一个可选的 scripts 目录存放你要执行的脚本Python、Node.js、Shell 都可以。当你在对话中提到与该技能相关的目标时AI 会自动加载 SKILL.md 中的行为守则并在需要的时候主动运行 scripts 目录下的脚本把结果拿回对话里继续分析。我用一句话概括普通提示词是给 AI 说的话Skill 是给 AI 装的脑子。前者是聊天的规则后者是干活的系统。Skill 把“怎么说”和“怎么做”绑定在一起形成一个完整的执行闭环。1.2 Skill 与 Agent 的区别为什么不能混为一谈我注意到很多人把 Skill 和 Agent 混在一起讨论但这两者在实际使用中的边界其实很清楚。Agent 是具备自主规划、分解任务、调用多种工具并循环执行的一个完整系统它负责“思考下一步做什么”。Skill 本身不具备这种自主性它是被 Agent 或用户需求所触发的一组能力封装负责“做好某一类具体的事”。在 ChatGPT 桌面端里的逻辑是Agent 作为主控大脑Skill 作为被调用的功能模块。比如你让 AI 做一份市场调研报告Agent 会先分析任务发现需要收集数据、清洗数据、生成图表、撰写分析这一系列流程中它可以按需调用数据清洗 Skill、图表生成 Skill每个 Skill 只负责自己那一环。这就好比你开一家餐厅。Agent 是店长负责决定今天做什么菜、怎么安排后厨Skill 是厨师你叫他做川菜他就能做川菜叫他做粤菜他也能做粤菜但他不会自己决定今天餐厅该卖什么。如果把两者混用就会出现一个很尴尬的情况你把 Skill 的职责设计得过于自主结果它反而不知道该在什么时候执行自己的功能。我在早期配置时就把 Skill 写得太像 Agent导致 AI 在完全无关的对话中频繁调用这个技能干扰了正常交流。后来调整思路Skill 只做“窄而深”的事才真正解决了问题。1.3 为什么说 Skill 能“效率翻倍”它到底省了什么“效率翻倍”这种说法听起来像标题党但实际用下来确实不夸张只是它省的不是打字的时间而是重建上下文和调教行为的时间。先说重建上下文的成本。我处理数据分析类任务时以前每个新对话都要重新描述一遍“你是数据分析师你需要遵循以下步骤第一步导入数据第二步清洗缺失值第三步计算描述性统计……”这段描述大概三百字每次粘贴一次。对于一周要开二十多个新对话的我来说这就是日常开销。配置了数据清洗 Skill 后我只需要输入“清洗一下这份数据”AI 自动加载整套规则按照规范流程执行省掉的不仅是我打字的时间还有等 AI 理解我要求的时间。再说调教行为的成本。没有 Skill 的时候AI 在分析中的输出格式每次都有细微出入你得反复跟它说“用表格输出”“百分比保留一位小数”“相关性分析跟着描述性统计走”。有 Skill 后这些行为约定一次性写在 SKILL.md 里所有对话默认遵守。刚开始我花了一个晚上写这个文件之后两个多月里每次任务输出格式都是稳定一致的这点真的省心。对于个人用户来说省的是时间对于团队来说省的是标准化的成本。如果你维护了多个 Skill每个成员在同一个 Skill 约束下的输出都是同一种格式、同一套逻辑交接成本大幅降低。这才是“效率翻倍”背后真正核心的东西不是打字速度变快了而是所有确定性的事情都自动化了。2. 核心细节解析与实操要点2.1 Skill 包的文件结构看懂目录就等于懂了一半我想先明确一点ChatGPT Skill 并不是云端的一个抽象概念它是以真实的文件系统目录形式存在于你本机上的。你在系统里能看到它、访问它、修改它这跟以往写提示词完全是两种体验。一个标准 Skill 包通常长这样my-skill/ ├── SKILL.md ├── scripts/ │ ├── analyze.py │ └── yaml_dump.py ├── assets/ │ └── reference.pdf └── config.tomlSKILL.md 是这个技能包的核心配置文件之一里面用 Markdown 编写所有行为规则。AI 一加载这个 Skill会先读这个文件然后在本次对话的整个过程中把它当作行为纲领。scripts 目录存放的是可以被 AI 调用的脚本文件Python、Node.js、Shell 都行。assets 目录放辅助资料比如参考文档、模板、图片AI 也可以读取。config.toml 则是技能包的元信息配置定义了模型参数、技能元数据等。我在 macOS 上实测ChatGPT 桌面版会默认从~/.chatgpt/skills读取已安装的技能包。也就是说你在这个目录下新建一个文件夹把 SKILL.md 放进去然后在.chatgpt的配置文件中把它勾选为启用状态对话中就能直接调用了。Codex CLI 的读取机制也差不多只是目录位置和配置格式略有不同。那 config.toml 里面是什么内容呢以我自己的一个日志分析 Skill 为例name log-analyzer description 分析应用日志统计错误类型并生成摘要报告 version 1.2.0 model gpt-4.1 [agent] enabled true temperature 0.2 max_tokens 2048name 是这个技能的唯一标识description 则是给 AI 看的触发条件描述。你在对话里提到日志分析相关的内容时AI 会根据 description 判断是否需要加载这个技能包。model 参数可以指定这个技能运行时的模型版本temperature 设得低一点可以保证分析任务的输出更稳定减少自由发挥的空间。2.2 SKILL.md 的写作逻辑把行为守则说清楚而不是把对话稿写完很多第一次写 SKILL.md 的人容易走进一个误区把这个文件当成跟 AI 对话的逐字稿写了一大段“请你帮我做某某任务”之类的话。实际上SKILL.md 不是对话稿是行为守则。它的作用是让 AI 在接收到相关请求后以固定的流程、固定的风格、固定的输出格式来完成任务。我写 SKILL.md 时通常会分成几个固定区块每个区块解决一类问题第一个区块是“目标描述”。明确这个技能包是干什么的解决什么问题在什么场景下适用。给 AI 一个清晰的触发场景判断依据。比如我写过一个专利检索辅助 Skill 的目标描述“当用户需要查找专利信息、分析专利申请文件、或者比对已有专利权利要求时使用此技能。它帮助用户整理检索关键词推荐 IPC 分类号并辅助分析专利文本结构。”第二个区块是“工作流程”。分步骤列出完成任务的顺序。这里要用命令式的语言明确每一步做什么不要给 AI 太多自由发挥空间。比如我的数学建模 Skill 中的工作流是这样的先分析题目类型再确定使用哪种模型然后进行数据预处理接着建模、求解、检验最后生成报告。每一步下面还有更细的子步骤。这样做的好处是AI 的输出结构会非常稳定每个任务都会按这个流程走不会突然跳步或者漏掉关键环节。第三个区块是“输出格式和守则”。定义所有输出的统一格式。比如“所有数值保留两位小数”、“所有表格使用 Markdown 表格呈现”、“相关性分析结果必须附上 p 值”、“不要主动向用户推荐其他未提及的分析方法”。这些规则越具体输出越稳定。我有个心得不要写“请做好数据分析”这种空话要写“当皮尔逊相关系数绝对值大于 0.8 时标记为‘强相关’并在报告中加粗显示”这种可验证的规则。这里有一个非常关键的点SKILL.md 的编写目标不是让 AI 说更多话而是让 AI 说更一致的话。它是在给 AI 的行为做约束和校准而不是在给它写台词。2.3 脚本调用机制Skill 如何真正“动手干活”Skill 跟提示词最大的一个区别在于它可以真正执行本地脚本然后把脚本输出结果作为对话上下文的一部分继续分析。这个机制我理解之后才明白 Skill 的威力到底在哪里。举个例子。我写了一个日志分析 Skill它的 scripts 目录下放着一个 Python 脚本作用是读取输入的日志文件路径然后统计 ERROR、WARNING、INFO 三种级别的数量找出出现次数最多的前十个异常关键字输出成 JSON 格式。在对话中我只需要提供日志文件路径AI 会自动执行这个脚本然后把脚本输出的 JSON 数据读进来再基于这些数据分析问题根因、写总结。这里有个技术细节值得注意AI 执行脚本时是在一个沙箱环境中运行的它不能随意访问你的计算机上的所有文件只能访问你授权给它的目录。比如我在 config.toml 中给日志分析 Skill 添加了一个权限条目[sandbox] allowed_directories [/Users/me/logs, /tmp]这样 AI 执行脚本时只能读取/Users/me/logs和/tmp下的文件其他路径一概拒绝。这个安全机制真的很重要尤其当你使用第三方下载的 Skill 包时没有这个限制的话风险会大很多。脚本不止可以用于数据处理任务。我还见过有人把 Skill 跟浏览器自动化工具结合起来让 AI 先把网址抓取下来再调用本地脚本打开浏览器、定位元素、截图保存。也有人把 Skill 跟图像处理工具结合让 AI 自动对图片做尺寸裁剪和格式转换。这类技能包的本质逻辑是一样的AI 负责理解意图和规划步骤脚本负责执行确定性的操作两边配合各取所长。3. 实操过程与核心环节实现3.1 从零到一创建并安装你的第一个 Skill 包理论说再多不如直接上手做一遍。我在 Windows 11 的 ChatGPT 桌面端上完整走了一遍创建 Skill 的流程这里把每一步都记录下来包括踩过的坑。第一步创建一个技能包目录。我建了一个文件夹叫report-generator专门用来写周报的。在正式操作之前先想清楚这个技能包到底要干什么事边界在哪里我的答案是输入一个周报要点片段输出一份结构完整的周报包含“本周完成”、“问题风险”、“下周计划”三个板块。第二步创建 SKILL.md 文件。我把行为守则写清楚核心内容大概长这样# 周报生成技能 ## 目标 将用户提供的零散工作要点整理为结构清晰的周报确保重点突出、逻辑连贯。 ## 工作流程 1. 识别用户输入中的每个工作项。 2. 将工作项分类归入“本周完成”、“问题风险”、“下周计划”三个板块。 3. 问题风险板块需要明确问题描述、影响范围和建议解决措施。 4. 下周计划板块需要给出优先级排序。 ## 输出守则 - 使用项目符号进行描述。 - 每条描述控制在 20 字以内。 - 在周报末尾标注本周累计完成的工作项数量。这里我没有写太长刻意保持精简。因为之前犯过写太多导致 AI 抓不准重点的毛病现在养成一个习惯能用一条规则表达清楚就绝不用三条。第三步把技能包移动到正确目录。在 Windows 上ChatGPT 桌面版的技能包目录是%USERPROFILE%\.chatgpt\skills。我打开文件资源管理器把report-generator整个文件夹复制了过去。然后在 ChatGPT 的“设置”—“技能”页面里确认这个技能已经出现在列表里并保持启用状态。第四步测试调用。我随便打了一段极其零散的要点“这周完成了登录模块重构解决了用户反馈的连接超时问题下周准备做性能测试和文档更新。”AI 自动识别到这是一个周报生成场景调用了周报生成技能按预置的格式输出了一份完整的周报。三个板块分类准确没有跑偏。第一次跑通的那一刻确实挺有成就感的。3.2 config.toml 的配置细节模型选择与温度参数配合config.toml 的正确配置直接决定了 Skill 的运行表现。在反复测试中我形成了两个原则配置必须精简准确参数必须符合技能场景需求。先看 model 字段。有人可能以为这个字段跟对话中使用的模型是同一个其实不是。每个 Skill 都可以单独指定运行时使用的模型版本。这意味着对于一个需要大量推理的任务你可以给这个 Skill 指定一个更强的模型对于一个简单重复的任务则指定一个响应更快的轻量模型。我在数学建模 Skill 中用了model gpt-4.1因为这类任务需要较强的逻辑推理能力而在周报生成 Skill 中我用了model gpt-4.1-mini这类任务不需要特别复杂的推理速度比精度更重要。再看 temperature 参数。这个参数控制输出的随机性范围是 0 到 1 之间。值越低AI 越倾向于选择概率最高的词输出更稳定、更保守值越高输出越有创造性但更不稳定。对于跟数据分析、代码生成相关的技能我一般设置在 0.1 到 0.3尽量让输出结果可预期。对于创意写作类的技能我会把温度调高到 0.7 左右给 AI 更多自由发挥的空间。config.toml 中还有一个需要认真对待的字段是[sandbox]。这是当前的沙箱权限配置涉及 AI 的脚本执行范围。我强烈建议每一个 Skill 都显式地配置这个字段不要用默认配置。默认情况下有些版本可能会允许脚本访问比较宽泛的目录范围如果你跑的是第三方 Skill这种宽泛权限存在一定风险。我的配置习惯是白名单制只放行需要访问的目录其他的一律拒绝。痛过一次就记住了。我之前测试一个网页抓取类的 Skill它的脚本需要临时文件目录做缓存我把整个用户目录都授权给它了。虽然这个 Skill 是我自己写的但后来复盘的时候后背一凉如果这个 Skill 包里的脚本被别人植入了恶意代码那整个家目录下的私密文件就全暴露了。从那以后每个 Skill 的沙箱权限我都按最小可用原则来配置。3.3 数学建模 Skill 实战一个完整流程复盘如果你想更直观地感受 Skill 的能力边界数学建模是个非常好的场景。数学建模竞赛对处理流程的要求非常固定每年的套路都差不多问题分析、模型选择、数据预处理、模型求解、结果检验、论文写作。把这套固定流程固化成 Skill参赛的时候能省下大量重复劳动。我的数学建模 Skill 目录长这样mathematical-modeling/ ├── SKILL.md ├── scripts/ │ ├── data_clean.py │ ├── regression_analysis.py │ └── sensitivity_analysis.py └── config.tomlSKILL.md 的工作流程部分我写得很细细到每个环节该输出什么都有明确约定。比如在数据处理环节脚本会自动检查数据的缺失值比例超过 20% 的列给出删除建议低于 20% 的列采用均值或中位数填补。在模型选择环节AI 会根据数据特征自动推荐线性回归、随机森林或者时间序列模型。这些规则全部写死在 SKILL.md 中AI 调用时不需要每次重新理解需求直接按流程走。regression_analysis.py 这个脚本做的事情是读入数据、运行多种回归模型普通最小二乘、岭回归、Lasso、输出每种模型的 R 方、调整后的 R 方、AIC/BIC 值以及各特征的回归系数和显著性水平。AI 拿到这个输出后会根据自己的分析框架生成一段模型比较的文字指出哪种模型更适合当前数据。比赛场景下一篇文章从拿到题目到完成初稿原来可能要 12 小时以上。配置了这套 Skill 后数据预处理和初版建模环节能压缩到 2 小时以内多出的时间可以用来优化模型和打磨论文。这里面的核心逻辑就是把高确定性的工作全部自动化把人的精力留给真正需要判断力的环节。3.4 Codex CLI 场景让 Skeeel 在本地命令行里跑起来ChatGPT 桌面端的 Skill 体验是“对话优先”而 Codex CLI 场景下Skill 则更贴近开发者工作流。Codex 是命令行的 AI 编程助手现在也支持 Skill 机制。使用 Codex CLI 的时候Skill 的加载和调用跟桌面端有些不同但核心机制是一样的通过技能包中的 SKILL.md 来指导行为通过 scripts 中的脚本扩展能力边界。在 Codex CLI 中创建 Skill 的流程跟桌面端大同小异。找到 Codex 的配置目录一般也是.codex或类似路径在其中创建skills子目录再把技能包放进去。Codex 会扫描这些技能包在合适的时候自动加载。相比桌面端Codex 场景中 Skill 更偏向代码生成与分析。比如我配了一个专门做代码审查的 Skill它的 SKILL.md 规定了审查的维度代码风格、潜在bug、性能瓶颈、安全性问题、可维护性。审查报告必须按这五个维度逐项输出且每个问题都要给出具体的修复建议和参考代码。Codex CLI 有一个特别方便的地方它可以跟你的 Git 仓库做深入联动。我写过一个生成 commit message 的 Skill它的脚本会先执行git diff把变更内容输出然后分析这些变更生成一个符合 Conventional Commits 规范的 commit message。这个 Skill 的脚本用 Python 写的核心逻辑也不复杂先调git diff --stat查看变更文件列表再调git diff看具体内容接着按照变更类型feat、fix、refactor、docs、test、chore和变更范围生成 commit message。实测下来这个 Skill 生成的 commit message 虽然不能做到每一句都完美但至少能保证格式规范、语气统一省去了每次纠结 description 怎么写的时间。对于每天都在 commit 的人来说这种微小的效率提升累积起来还是很可观的。4. 常见问题与排查技巧实录4.1 经典报错config.toml 无法加载导致对话串不可恢复我注意到近期有大量用户遇到了一个典型报错报错信息说的是 config.toml 无法加载这个对话串无法继续需要修复 config.toml报错中会提到 model 字段和 skill 字段。这个问题我在实际使用中也碰到过这里把根因和排查思路完整说一下。这个报错的意思是ChatGPT 桌面端在读取某个 Skill 包的 config.toml 时失败了解析不出来合法配置导致依赖该配置的对话无法继续。最常见的触发场景有两个一是 config.toml 文件格式写错了比如引号没闭合、中括号写错层级、某个字段的值用了中文引号二是文件中的 model 字段指定了一个当前环境不支持的模型版本AI 无法用这个模型继续后续生成。先说格式问题。TOML 格式对字符串要求双引号包裹对键值对要求键和值在同一行。我见过很多从博客上复制配置的人把 SKILL.md 和 config.toml 的内容混在一起粘贴导致 config.toml 里出现 Markdown 标记当然解析不了。排查方法也很直接用支持 TOML 高亮的编辑器打开文件逐行检查语法。更快的办法是在终端里用 Python 跑一句import tomllib; tomllib.load(open(config.toml, rb))Python 3.11 以上版本自带 TOML 解析库能一秒定位是哪一行出问题。再说模型不支持的问题。报错里明确提到某个模型名字不被当前环境支持。这种情况通常是你配置的模型名在当前 Codex 环境或 ChatGPT 账户下不可用。解决办法有两种一是把 model 字段改成当前环境支持的其他版本比如报错里提到的版本换成更通用的gpt-4.1或gpt-4.1-mini二是如果这个 Skill 不需要特殊模型要求干脆把 model 字段删掉让 AI 沿用对话主模型的参数运行。这背后有一个值得深挖的细节同一个模型在不同账户类型下的可用情况并不相同。有些模型仅对特定订阅用户开放你用普通账户的 Codex 或 ChatGPT 自然加载不了。配置 Skill 时先确认当前账户能访问哪些模型再决定 model 字段写什么。不确定就把这个字段留空最稳妥。4.2 报错速查表一段对话搞不定的问题直接查表定位我在使用 Skill 的过程中踩了不少坑有些问题报错信息明确有些则是行为异常。这里做一份速查表覆盖我遇到过的六类典型问题方便你用的时候快速定位。它近距离地从代码层拷问 ChatGPT Skill 最常见的错误场景。现象根因解决方案对话开头提示 config.toml 无法加载config.toml 语法错误或字段格式非法用 TOML 校验工具检查文件确认 model 字段为当前环境支持的模型提示缺少 Codex CLI 二进制或相关依赖Codex CLI 未安装或 PATH 环境变量未配置重新安装 Codex CLI检查which codex是否输出有效路径提示某个模型当前不支持model 字段指定的模型在当前账户下不可用换成gpt-4.1等通用模型或不指定 model 字段Skeeel 被触发但行为不符合预期SKILL.md 的规则写得过于宽泛AI 有太多自由解释空间把流程拆解成更细的步骤每条规则只能有一种理解方式技能包没有出现在技能列表中目录位置放错了或文件名大小写不匹配确认技能包在正确目录下且 SKILL.md 文件名完全一致AI 执行脚本时报权限错误sandbox 配置未包含脚本需要的目录在 config.toml 的 [sandbox] 中添加对应目录白名单这个表是我面向实际使用的排查索引。有些问题在紧急情况下会掩盖成其他表现比如你发现某个 Skill 完全不生效有可能不是 Skill 本身的问题而是 config.toml 解析失败把整个对话阻塞了。排查时最省时间的原则是先报错、后行为先配置、后脚本先模型、后权限。4.3 我踩过三次的坑SKILL.md 写作中的反面教材就 SKILL.md 写作中的常见问题我愿意分享三个交叉反复踩过的坑想必读完能帮你节省不少时间。第一个坑是“把规则写成散文”。我早期的 SKILL.md 写了一段类似这样的话“数据分析前应当考虑数据质量如果数据质量不佳可以适当进行清洗以保证后续分析的准确性。”这句话听起来没什么问题但 AI 面对这种描述时自由度很高它无法统一执行标准于是时常自主判断“数据质量不佳”的阈值导致不同对话间的清洗力度不一样。后来我改成硬性规定“缺失值比例超过 30% 的列直接删除缺失值比例在 10% 到 30% 的列用中位数填补缺失值比例低于 10% 的列保留原样。”改完之后清洗逻辑就稳定多了。第二个坑是“把 SKILL.md 写成百科全书”。我在一个专利辅助 Skill 中塞入了大量背景知识、历史沿革、名词解释。看起来是丰富配置实际上额外信息越杂AI 越容易在执行时被无关内容干扰反而忽略了最重要的执行步骤。后来我把背景知识删到只剩跟执行直接相关的部分其他内容移到 assets 目录下作为参考材料效果立刻好了很多。第三个坑是“没有定义输出失败时的兜底行为”。比如我的爬虫 Skill在没有指定脚本目录权限时执行失败AI 只是简单反馈一句“权限不足”就结束了没有告诉用户该怎么解决。后来我在 SKILL.md 中加了一个“异常处理”区块规定遇到权限错误时AI 必须明确说明需要用户在 config.toml 的 [sandbox] 中添加哪个目录并给出具体的修改示例。这样用户看到错误信息后能直接操作不用自己研究配置语法。SKILL.md 不只约束正常流程也要约束异常流程。4.4 “skill原版无删减版百度”类搜索背后的真实需求很多人在搜索上输入“skill原版无删减版百度”这样的关键词想找一份“原版 Skill”或者“完整版 Skill”这背后其实暴露了一个真实的痛点网上关于 Skill 的教程太杂要么只说概念要么只讲安装缺少一份可以直接拿来用的高质量技能包参考。就我自己的经验而言官方渠道的示例是最靠谱的起点。ChatGPT 桌面端的帮助文档里有几个官方示例技能包结构非常简单但五脏俱全适合作为参照模板。把这些示例跑通之后你就明白 SKILL.md 各区块应该怎么写、脚本目录怎么组织、config.toml 各字段怎么配然后在这个基础上逐步修改成自己的版本。对于想要参考别人项目的人来说最优质的信息源其实是代码仓库里开源的 Skill 包。GitHub 上已经有不少人组织了自己的 Skill 仓库里面放着日常积累的各种技能包。我每次看到一个感兴趣的 Skill 包都会重点关注几个部分SKILL.md 的规则粒度、scripts 目录下的脚本质量、config.toml 中的参数配置。通过对比不同作者对同一类任务的写法能很快形成自己对最佳实践的理解。这里有一个需要提醒的风险点网上下载的第三方 Skill 包不一定安全。Skill 包含有本地脚本执行权限如果你从不可靠的地方下载了一个包里面的脚本有可能在读取你的个人数据并外传或者对被授权的文件目录执行危险操作。我在安装第三方 Skill 前一定会做三件事第一打开 SKILL.md 看它的行为规则判断是否有恶意倾向第二逐个阅读 scripts 目录下每个脚本的源码确认没有可疑的系统调用第三在 config.toml 中严格收紧 [sandbox] 白名单只给它访问必要的目录。5. Skill 与 Agent 的选型判断什么时候用 Skill什么时候上 Agent5.1 两者的适用场景边界写到这里我认为有必要正面把 Skill 和 Agent 的分工讲透。Skill 和 Agent 是两种不同层级的能力单元适用场景有明确的边界。这不是偏好问题是架构问题。Skill 适合“任务确定、流程固定、输出标准”的场景。比如生成周报、做日志分析、生成 commit message这类任务的输入输出都非常明确不会出现“中间突然要临时改变方向”的情况。Skill 把流程固化到极致好处是输出稳定可靠坏处是灵活性不足一旦任务超越了它的规则范围它可能表现得比较僵硬。Agent 适合“目标明确但路径未知”的场景。比如“调研一下新能源汽车市场的竞争格局”这个任务没有一个固定的流程可以走。Agent 需要自己决定先做什么、再做什么它可能需要搜索资料、阅读报告、做数据对比、生成结论每一步都在动态调整。在这种场景下硬用一个 Skill 反而会成为束缚。实际项目中两者往往是配合关系。Agent 负责宏观的任务规划Skill 负责微观的执行单元。有一次我让 Agent 帮我对一个网站做综合评价它的流程规划里拆出了内容质量分析、页面性能分析、SEO 结构分析三个子任务其中内容质量分析就用到了我之前配的文本摘要 Skill页面性能分析用到了日志分析 Skill。Agent 负责调度Skill 负责干活这个配合模式运行得非常顺。5.2 选择时的判断依据四个自问如果现在你也面临“该配 Skill 还是该上 Agent”的纠结我建议你回答这四个问题第一这个任务的执行流程是否已经固定如果你每次做这件事的方法都一样那就用 Skill如果你每次都需要重新想一遍怎么做那就需要考虑 Agent 或者至少留出更大的动态规划空间。第二任务的输出格式是否要求一致如果下游接收方要求固定格式比如周报模板、审查报告模板Skill 是更好的选择因为它能把格式稳定性锁死。Agent 在规划中的输出会更灵活但灵活性有时候是缺点。第三你是否经常执行同类型任务某个任务如果一个月只做一次配置 Skill 的性价比就不高。如果一周做好几次那花一晚上配置一个 Skill 是非常划算的。我自己配置的量级标准是每周超过两次就值得做成 Skill。第四这个任务是否需要跨步骤决策如果任务从开始到结束只需要埋头执行Skill 就够了。如果中途需要根据中间结果调整策略就需要 Agent 介入。我见过有人试图用 Skill 做项目管理最后效果很差就是因为项目管理的每一步都充满变数Skill 的“规则执行”模式无法应对这种变数。5.3 组合使用的最佳实践一个 Skill 库的成长路径Skill 用的时间长了你会发现手里积累的不只是几个技能包而是一套关于工作流的方法论。我在自己的实践中总结了一条技能库的成长路径分四个阶段。第一阶段是“复制”。把官方示例跑通照葫芦画瓢做一个最简的 Skill 包。这一阶段的目的是理解机制不要追求复杂。我在这个阶段用日志分析练手整个过程不到一小时但对 Skill 的理解比看十篇文章都管用。第二阶段是“改造”。把高频任务逐个梳理找出那些“每次做都很烦但流程很固定”的事情把它们做成新的 Skill。比如周报、代码审查、commit message这些场景是最适合第一批技能化的。这一阶段的核心是选对场景选错了会白费功夫。第三阶段是“联动”。开始让不同 Skill 之间配合让 Agent 调度多个 Skill 完成复杂的组合任务。比如我让 Agent 先调用“数据清洗 Skill”处理原始数据再调用“可视化 Skill”生成图表最后调用“报告写作 Skill”生成最终文档。这个阶段你会真正感受到“效率翻倍”的含金量不是单次快了而是复杂任务也可以拆解成标准化单元流水线化执行。第四阶段是“沉淀”。把验证有效的技能包组织成个人或团队的技能库形成一套标准化的资产。我在这个阶段的习惯是每个 Skill 都维护一份 README记录它解决什么问题、依赖什么环境、有哪些已知限制。后续维护和交接都省力很多。6. 最后聊点经验之谈Skill 这个东西刚上手时容易高估它觉得它什么都能干用一段时间后又容易低估它觉得它不过就是提示词的游戏。真正让我改变看法的是连续使用一个月之后的一个场景一个需要反复处理的标准分析任务以前每次手动整理要一个小时现在输入需求后十分钟内就能拿到结构严谨、格式稳定的结果。那一刻我意识到Skill 最大的价值不是“让 AI 变聪明”而是“让确定的事情不再消耗注意力”。配置 Skill 的核心原则我用一句话总结规则越硬输出越稳边界越清问题越少权限越窄风险越低。每次新建一个技能包之前先问自己想解决什么问题、边界在哪里、什么情况下不要触发想清楚再动手写。这样配出来的 Skill 才不会变成一堆复杂但用不上的配置。根据我个人的实操经验最推荐的起步方式是个性化而非大而全选一个你每周都要做的、流程固定的任务先做出一个最简技能包跑通全流程然后在实际使用中逐步迭代。不要一开始就想着做一个全能助手型 Skill那种项目维护成本极高而且容易在复杂性中迷失方向。从一个小而精的切入点开始把一个技能打磨到真正顺手你才能体会到 Skill 这套机制跟传统提示词之间真正的差距。这大概就是“装上技能包”这件事最朴素的原理。