1. 从skills这个模糊词说起它到底指什么第一次看到skills这个标题很多人会懵——这词太泛了。技能技巧还是某个具体产品的功能模块但如果你最近在折腾 Claude Code、Codex 这类 AI 编程助手或者关注过 agents 生态就会知道这里的 skills 有非常明确的指向它是 AI 编程代理agent可以调用的、封装好的能力单元。打个比方。传统的 AI 编程助手像是一个刚入职的聪明实习生你问它什么它都能聊但真要它动手干活——比如按团队规范生成一个组件、跑一套特定的测试流程、调用某个内部工具——它往往抓瞎因为它不知道你们团队的规矩。而 skills 就是给这个实习生配的一本《操作手册》加一套工具箱手册告诉它什么场景该做什么工具箱提供具体能调用的脚本和模板。这个类比不是随便打的。Claude Code 的 skills 机制本质上就是把可复用的工作流、领域知识、脚本封装成 agent 能自动识别和调用的模块。Codex 那边也有类似的概念虽然叫法可能不同但核心逻辑一致让 agent 从什么都能聊进化到什么都能干而且干得符合你的预期。为什么这个方向突然火了因为大家发现单纯堆模型能力已经遇到瓶颈了。你把 GPT-4 换成更强的模型它在写一段快排这种任务上提升有限但在按照我们公司特有的代码规范重构这个模块这种任务上差距巨大——而这个差距靠 skills 来补比靠换模型来补划算得多。所以这篇内容适合谁看三类人一是已经在用 Claude Code 或 Codex但只会基础对话、没碰过 skills 的开发者二是想给自己团队搭建 agent 工作流的技术负责人三是对 agents 生态感兴趣、想搞清楚skills 到底解决什么问题的观察者。不管你属于哪类接下来的内容都会从实际使用角度出发把 skills 的来龙去脉、安装配置、开发方法、踩坑经验讲透。2. skills 在 Claude Code 和 Codex 里的定位差异2.1 Claude Code 的 skills文件系统驱动的能力扩展Claude Code 的 skills 机制有个很鲜明的特点它高度依赖文件系统。你在项目目录下放一个特定结构的文件夹里面包含说明文档和可执行脚本Claude Code 在运行时就能识别并调用它。这个设计的好处是直观——skill 就是一个你能用文件管理器看到的实体不是什么藏在云端的神秘配置。具体来说一个典型的 Claude Code skill 包含这几样东西一个描述文件告诉 agent 这个 skill 是干什么的、什么时候该用可能还有脚本文件实际执行逻辑、模板文件生成内容的骨架、参考文档领域知识。当你在对话中触发了某个场景Claude Code 会扫描可用的 skills匹配到合适的就自动加载。这里有个关键设计哲学skills 是声明式的不是命令式的。你不需要在对话里明确说请使用 XX skill而是通过描述文件里的触发条件让 agent 自己判断。这跟传统的函数调用完全不同——传统方式是你写代码调用函数这里是 agent 根据上下文自主决策。2.2 Codex 的 skills更偏向工具链集成Codex 这边的 skills 概念跟 Claude Code 有重叠但不完全一样。Codex 作为编程代理它的 skills 更强调与现有工具链的集成。比如你有一个内部的代码生成工具、一个特定的测试框架、一套部署脚本Codex 的 skills 机制让你能把这些挂到 agent 上让它在需要时调用。从实际使用体验看Codex 的 skills 配置往往更重一些——需要更明确的接口定义、参数说明、返回值处理。这跟两个产品的定位有关Claude Code 更偏向对话式编程助手skills 是增强对话能力的Codex 更偏向自动化编程代理skills 是扩展自动化能力的。2.3 两者共同的底层逻辑抛开产品差异skills 机制在两者身上共享同一套底层逻辑我把它总结成三个关键词封装。把散落在文档、脚本、人脑里的知识封装成 agent 能理解的结构化模块。没有 skills 之前你想让 agent 按特定规范做事得在每次对话里重复交代有了 skills交代一次以后自动生效。发现。agent 需要知道我有哪些能力可用。skills 的描述文件就是给 agent 看的能力清单它根据当前任务上下文从清单里挑合适的。执行。光知道不够还得能动手。skills 里的脚本、模板、工具调用逻辑就是 agent 的手。理解了这三点你再看任何 skills 相关的配置和开发都不会迷路。3. 安装与配置从零把 skills 跑起来3.1 Claude Code 的安装与 skills 目录结构先说 Claude Code 的安装。不同系统路径略有差异但核心步骤一致。安装完成后skills 的存放位置有几个约定俗成的选择项目级 skills放在项目根目录下的特定文件夹里只对当前项目生效。适合团队协作把 skills 跟代码一起提交新人拉下来就能用。用户级 skills放在用户主目录的配置文件夹里对所有项目生效。适合个人常用的通用能力比如生成符合我代码风格的注释。全局 skills系统级配置一般不建议随便动除非你明确知道自己在做什么。目录结构上一个 skill 通常长这样my-skill/ SKILL.md # 描述文件核心 scripts/ # 可执行脚本 run.sh templates/ # 模板文件 component.tsx references/ # 参考文档 style-guide.mdSKILL.md是最关键的它决定了 agent 能不能正确识别和使用这个 skill。里面通常包含skill 名称、一句话描述、触发条件什么场景该用、使用说明、依赖项。3.2 Codex 的安装与 skills 接入Codex 的安装流程跟 Claude Code 类似但 skills 的接入方式更偏向配置驱动。你需要在配置文件里声明 skills 的来源、调用方式、参数映射。这个过程比 Claude Code 稍微繁琐但换来的是更精确的控制。一个常见的坑是Codex 对 skills 的接口定义要求比较严格。如果你写的描述文件里参数类型不明确或者返回值格式跟预期不符Codex 可能直接忽略这个 skill而且报错信息往往不够直观。我的经验是先在最小可运行例子上跑通再逐步加复杂度。3.3 配置过程中最容易忽略的三个细节第一路径问题。skills 里的脚本如果用相对路径引用其他文件在不同工作目录下执行可能找不到。稳妥做法是用绝对路径或者在脚本开头显式切换到脚本所在目录。第二权限问题。脚本文件需要有可执行权限否则 agent 调用时会失败。这个在 Windows 上不明显在 Linux 和 macOS 上经常踩。第三编码问题。描述文件如果是中文确保用 UTF-8 编码保存。有些编辑器默认用 GBK导致 agent 读取时乱码skill 直接失效。提示配置完 skills 后先用一个简单任务测试 agent 是否能正确识别和调用。不要一上来就搞复杂工作流出问题了很难定位是 skill 本身的问题还是调用逻辑的问题。4. 开发一个自己的 skill从需求到落地4.1 先想清楚什么值得做成 skill不是所有东西都值得封装成 skill。我的判断标准是三条高频。这个操作你每周至少做几次封装一次省下的时间能覆盖开发成本。规范明确。操作有清晰的输入输出、固定的步骤、可验证的结果。如果每次都要临场判断那更适合留在人脑里。容易出错。人工做容易漏步骤、写错参数、忘记某个环节。skill 的价值之一就是把容易忘变成自动做。举个例子。生成一个符合团队规范的 React 组件就很适合做成 skill高频每个新页面都要、规范明确有组件模板和命名规则、容易出错新人经常漏掉 PropTypes 或写错文件结构。4.2 写描述文件的门道描述文件是 skill 的灵魂。写得好agent 在合适的时候自动调用写得差要么从不触发要么乱触发。核心是触发条件的描述。不要写用于生成组件这种模糊表述要写清楚场景特征。比如当用户要求创建新的 UI 组件时当对话中出现新建页面添加组件等意图时当需要按照团队规范生成代码骨架时同时要写清楚不适用的情况避免误触发。比如不适用于修改现有组件不适用于纯样式调整。另一个技巧是在描述里给出示例。给 agent 一两个输入-输出的样例它匹配起来会准得多。这跟给人写文档一个道理例子比抽象描述管用。4.3 脚本编写的实战要点脚本是 skill 的执行部分。几个实战要点输入处理要健壮。agent 传进来的参数可能格式不标准脚本要做基本的校验和清洗。别假设 agent 一定传对。输出要结构化。如果脚本的返回值要给 agent 继续处理用 JSON 之类的结构化格式别返回一大段自然语言让 agent 去猜。错误处理要明确。脚本失败时返回清晰的错误信息最好带上可能的原因。agent 看到明确错误能自己调整看到执行失败四个字只能干瞪眼。日志要留痕。脚本执行过程记日志出问题时能回溯。日志位置固定方便排查。4.4 测试与迭代别指望一次写对skill 开发是个迭代过程。第一版能跑通就行然后在实际使用中观察agent 什么时候调用了它、调用时传了什么参数、结果符不符合预期、有没有该调用却没调用的情况。根据观察结果调整描述文件的触发条件、优化脚本的输入处理、补充边界情况的处理。这个过程通常要来回几轮急不得。5. 踩坑实录那些让我折腾半天的典型问题5.1 skill 死活不触发这是最常见的问题。你明明写好了 skillagent 就是不用。排查思路先确认 skill 被正确加载了。有些工具会提供命令列出当前可用的 skills先看你的 skill 在不在列表里。不在的话检查目录位置、文件权限、描述文件格式。在列表里但不触发那就是触发条件的问题。把描述文件里的触发条件写得更具体加上明确的场景关键词。有时候 agent 对某些表述不敏感换个说法就灵了。还有一种情况是优先级冲突。如果你装了多个功能重叠的 skillagent 可能选了另一个。这时候要么合并 skill要么在描述里明确区分适用场景。5.2 脚本执行报错但看不出原因脚本报错信息不明确是另一个高频坑。我的做法是在脚本里加详细的日志输出把输入参数、执行步骤、中间结果都记下来。然后手动用相同的参数跑一遍脚本看看到底哪一步出问题。常见原因包括路径不对、依赖没装、权限不足、环境变量缺失。这些在手动执行时往往能暴露出来。5.3 中文乱码导致 skill 失效这个坑很隐蔽。描述文件里有中文编辑器保存成了 GBKagent 读取时乱码触发条件匹配不上skill 就废了。解决办法是统一用 UTF-8并且在描述文件开头加编码声明。5.4 跨平台兼容性问题你在 macOS 上写好的 skill同事在 Windows 上用不了。原因可能是脚本用了 Unix 特有的命令、路径分隔符写死了、换行符不一致。如果团队跨平台协作脚本尽量用跨平台的写法或者针对不同平台提供不同版本。5.5 排查链路总结遇到 skill 问题按这个顺序排查skill 是否被加载查列表描述文件格式是否正确编码、语法触发条件是否匹配当前场景看日志脚本是否能独立运行手动执行输入参数是否符合预期打日志输出格式是否被 agent 正确解析这个顺序从外到内能覆盖绝大多数问题。6. skills 生态的现状与个人实践建议6.1 官方市场与社区 skillsClaude Code 有官方的 skills 市场里面有不少官方和社区贡献的 skill。Codex 那边也有类似的资源。这些现成的 skill 值得先逛一圈看看别人怎么写的能省不少自己摸索的时间。但要注意现成 skill 不一定适合你的场景。别人的团队规范跟你的不一样别人的工具链跟你不一样。直接拿来用往往水土不服更好的做法是参考它们的结构改造成适合自己的版本。6.2 团队协作中的 skills 管理如果团队多人使用 skills需要一套管理机制版本控制skills 跟代码一起进 Git改动有记录命名规范skill 名称统一格式避免冲突文档说明每个 skill 有 README说明用途、用法、维护人定期清理过时的 skill 及时删避免 agent 误用6.3 我个人的几条经验用了大半年 skills有几条经验值得分享从最简单的开始。别一上来就搞复杂工作流先做一个生成文件头注释这种小 skill跑通了再扩展。描述文件比脚本重要。脚本写得再好agent 不调用也白搭。花时间打磨触发条件的描述回报很高。保留人工兜底。skill 再智能也可能出错关键操作保留人工确认环节。特别是涉及删除、部署这类不可逆操作。关注 agent 的思考过程。有些工具会输出 agent 的决策日志看看它为什么选这个 skill、为什么传这些参数能帮你优化 skill 设计。别过度封装。不是所有操作都值得做成 skill。有些一次性任务直接对话解决更快。skills 的价值在于复用不复用的东西封装了反而是负担。6.4 这个方向接下来会怎么走从目前趋势看skills 机制会越来越重要。模型能力趋同之后差异化的竞争力就在于谁能把 agent 调教得更懂自己的业务。skills 就是调教的主要手段。另一个趋势是skills 的标准化。现在 Claude Code 和 Codex 的 skills 格式还不完全通用未来可能会出现跨平台的 skill 规范写一次到处能用。这对开发者是好事但也意味着现在投入学习时要关注可迁移性别把宝全押在某个产品的私有格式上。最后说个实际体会skills 这东西看文档觉得简单真动手做才发现细节很多。但一旦跑通第一个后面的就顺了。关键是别怕踩坑每个坑踩过之后都是经验。我现在回头看最开始写的那个 skill触发条件写得一塌糊涂但正是从那个烂版本开始才慢慢摸清了门道。
AI编程代理skills机制详解：从Claude Code到Codex的安装配置与开发实践
1. 从skills这个模糊词说起它到底指什么第一次看到skills这个标题很多人会懵——这词太泛了。技能技巧还是某个具体产品的功能模块但如果你最近在折腾 Claude Code、Codex 这类 AI 编程助手或者关注过 agents 生态就会知道这里的 skills 有非常明确的指向它是 AI 编程代理agent可以调用的、封装好的能力单元。打个比方。传统的 AI 编程助手像是一个刚入职的聪明实习生你问它什么它都能聊但真要它动手干活——比如按团队规范生成一个组件、跑一套特定的测试流程、调用某个内部工具——它往往抓瞎因为它不知道你们团队的规矩。而 skills 就是给这个实习生配的一本《操作手册》加一套工具箱手册告诉它什么场景该做什么工具箱提供具体能调用的脚本和模板。这个类比不是随便打的。Claude Code 的 skills 机制本质上就是把可复用的工作流、领域知识、脚本封装成 agent 能自动识别和调用的模块。Codex 那边也有类似的概念虽然叫法可能不同但核心逻辑一致让 agent 从什么都能聊进化到什么都能干而且干得符合你的预期。为什么这个方向突然火了因为大家发现单纯堆模型能力已经遇到瓶颈了。你把 GPT-4 换成更强的模型它在写一段快排这种任务上提升有限但在按照我们公司特有的代码规范重构这个模块这种任务上差距巨大——而这个差距靠 skills 来补比靠换模型来补划算得多。所以这篇内容适合谁看三类人一是已经在用 Claude Code 或 Codex但只会基础对话、没碰过 skills 的开发者二是想给自己团队搭建 agent 工作流的技术负责人三是对 agents 生态感兴趣、想搞清楚skills 到底解决什么问题的观察者。不管你属于哪类接下来的内容都会从实际使用角度出发把 skills 的来龙去脉、安装配置、开发方法、踩坑经验讲透。2. skills 在 Claude Code 和 Codex 里的定位差异2.1 Claude Code 的 skills文件系统驱动的能力扩展Claude Code 的 skills 机制有个很鲜明的特点它高度依赖文件系统。你在项目目录下放一个特定结构的文件夹里面包含说明文档和可执行脚本Claude Code 在运行时就能识别并调用它。这个设计的好处是直观——skill 就是一个你能用文件管理器看到的实体不是什么藏在云端的神秘配置。具体来说一个典型的 Claude Code skill 包含这几样东西一个描述文件告诉 agent 这个 skill 是干什么的、什么时候该用可能还有脚本文件实际执行逻辑、模板文件生成内容的骨架、参考文档领域知识。当你在对话中触发了某个场景Claude Code 会扫描可用的 skills匹配到合适的就自动加载。这里有个关键设计哲学skills 是声明式的不是命令式的。你不需要在对话里明确说请使用 XX skill而是通过描述文件里的触发条件让 agent 自己判断。这跟传统的函数调用完全不同——传统方式是你写代码调用函数这里是 agent 根据上下文自主决策。2.2 Codex 的 skills更偏向工具链集成Codex 这边的 skills 概念跟 Claude Code 有重叠但不完全一样。Codex 作为编程代理它的 skills 更强调与现有工具链的集成。比如你有一个内部的代码生成工具、一个特定的测试框架、一套部署脚本Codex 的 skills 机制让你能把这些挂到 agent 上让它在需要时调用。从实际使用体验看Codex 的 skills 配置往往更重一些——需要更明确的接口定义、参数说明、返回值处理。这跟两个产品的定位有关Claude Code 更偏向对话式编程助手skills 是增强对话能力的Codex 更偏向自动化编程代理skills 是扩展自动化能力的。2.3 两者共同的底层逻辑抛开产品差异skills 机制在两者身上共享同一套底层逻辑我把它总结成三个关键词封装。把散落在文档、脚本、人脑里的知识封装成 agent 能理解的结构化模块。没有 skills 之前你想让 agent 按特定规范做事得在每次对话里重复交代有了 skills交代一次以后自动生效。发现。agent 需要知道我有哪些能力可用。skills 的描述文件就是给 agent 看的能力清单它根据当前任务上下文从清单里挑合适的。执行。光知道不够还得能动手。skills 里的脚本、模板、工具调用逻辑就是 agent 的手。理解了这三点你再看任何 skills 相关的配置和开发都不会迷路。3. 安装与配置从零把 skills 跑起来3.1 Claude Code 的安装与 skills 目录结构先说 Claude Code 的安装。不同系统路径略有差异但核心步骤一致。安装完成后skills 的存放位置有几个约定俗成的选择项目级 skills放在项目根目录下的特定文件夹里只对当前项目生效。适合团队协作把 skills 跟代码一起提交新人拉下来就能用。用户级 skills放在用户主目录的配置文件夹里对所有项目生效。适合个人常用的通用能力比如生成符合我代码风格的注释。全局 skills系统级配置一般不建议随便动除非你明确知道自己在做什么。目录结构上一个 skill 通常长这样my-skill/ SKILL.md # 描述文件核心 scripts/ # 可执行脚本 run.sh templates/ # 模板文件 component.tsx references/ # 参考文档 style-guide.mdSKILL.md是最关键的它决定了 agent 能不能正确识别和使用这个 skill。里面通常包含skill 名称、一句话描述、触发条件什么场景该用、使用说明、依赖项。3.2 Codex 的安装与 skills 接入Codex 的安装流程跟 Claude Code 类似但 skills 的接入方式更偏向配置驱动。你需要在配置文件里声明 skills 的来源、调用方式、参数映射。这个过程比 Claude Code 稍微繁琐但换来的是更精确的控制。一个常见的坑是Codex 对 skills 的接口定义要求比较严格。如果你写的描述文件里参数类型不明确或者返回值格式跟预期不符Codex 可能直接忽略这个 skill而且报错信息往往不够直观。我的经验是先在最小可运行例子上跑通再逐步加复杂度。3.3 配置过程中最容易忽略的三个细节第一路径问题。skills 里的脚本如果用相对路径引用其他文件在不同工作目录下执行可能找不到。稳妥做法是用绝对路径或者在脚本开头显式切换到脚本所在目录。第二权限问题。脚本文件需要有可执行权限否则 agent 调用时会失败。这个在 Windows 上不明显在 Linux 和 macOS 上经常踩。第三编码问题。描述文件如果是中文确保用 UTF-8 编码保存。有些编辑器默认用 GBK导致 agent 读取时乱码skill 直接失效。提示配置完 skills 后先用一个简单任务测试 agent 是否能正确识别和调用。不要一上来就搞复杂工作流出问题了很难定位是 skill 本身的问题还是调用逻辑的问题。4. 开发一个自己的 skill从需求到落地4.1 先想清楚什么值得做成 skill不是所有东西都值得封装成 skill。我的判断标准是三条高频。这个操作你每周至少做几次封装一次省下的时间能覆盖开发成本。规范明确。操作有清晰的输入输出、固定的步骤、可验证的结果。如果每次都要临场判断那更适合留在人脑里。容易出错。人工做容易漏步骤、写错参数、忘记某个环节。skill 的价值之一就是把容易忘变成自动做。举个例子。生成一个符合团队规范的 React 组件就很适合做成 skill高频每个新页面都要、规范明确有组件模板和命名规则、容易出错新人经常漏掉 PropTypes 或写错文件结构。4.2 写描述文件的门道描述文件是 skill 的灵魂。写得好agent 在合适的时候自动调用写得差要么从不触发要么乱触发。核心是触发条件的描述。不要写用于生成组件这种模糊表述要写清楚场景特征。比如当用户要求创建新的 UI 组件时当对话中出现新建页面添加组件等意图时当需要按照团队规范生成代码骨架时同时要写清楚不适用的情况避免误触发。比如不适用于修改现有组件不适用于纯样式调整。另一个技巧是在描述里给出示例。给 agent 一两个输入-输出的样例它匹配起来会准得多。这跟给人写文档一个道理例子比抽象描述管用。4.3 脚本编写的实战要点脚本是 skill 的执行部分。几个实战要点输入处理要健壮。agent 传进来的参数可能格式不标准脚本要做基本的校验和清洗。别假设 agent 一定传对。输出要结构化。如果脚本的返回值要给 agent 继续处理用 JSON 之类的结构化格式别返回一大段自然语言让 agent 去猜。错误处理要明确。脚本失败时返回清晰的错误信息最好带上可能的原因。agent 看到明确错误能自己调整看到执行失败四个字只能干瞪眼。日志要留痕。脚本执行过程记日志出问题时能回溯。日志位置固定方便排查。4.4 测试与迭代别指望一次写对skill 开发是个迭代过程。第一版能跑通就行然后在实际使用中观察agent 什么时候调用了它、调用时传了什么参数、结果符不符合预期、有没有该调用却没调用的情况。根据观察结果调整描述文件的触发条件、优化脚本的输入处理、补充边界情况的处理。这个过程通常要来回几轮急不得。5. 踩坑实录那些让我折腾半天的典型问题5.1 skill 死活不触发这是最常见的问题。你明明写好了 skillagent 就是不用。排查思路先确认 skill 被正确加载了。有些工具会提供命令列出当前可用的 skills先看你的 skill 在不在列表里。不在的话检查目录位置、文件权限、描述文件格式。在列表里但不触发那就是触发条件的问题。把描述文件里的触发条件写得更具体加上明确的场景关键词。有时候 agent 对某些表述不敏感换个说法就灵了。还有一种情况是优先级冲突。如果你装了多个功能重叠的 skillagent 可能选了另一个。这时候要么合并 skill要么在描述里明确区分适用场景。5.2 脚本执行报错但看不出原因脚本报错信息不明确是另一个高频坑。我的做法是在脚本里加详细的日志输出把输入参数、执行步骤、中间结果都记下来。然后手动用相同的参数跑一遍脚本看看到底哪一步出问题。常见原因包括路径不对、依赖没装、权限不足、环境变量缺失。这些在手动执行时往往能暴露出来。5.3 中文乱码导致 skill 失效这个坑很隐蔽。描述文件里有中文编辑器保存成了 GBKagent 读取时乱码触发条件匹配不上skill 就废了。解决办法是统一用 UTF-8并且在描述文件开头加编码声明。5.4 跨平台兼容性问题你在 macOS 上写好的 skill同事在 Windows 上用不了。原因可能是脚本用了 Unix 特有的命令、路径分隔符写死了、换行符不一致。如果团队跨平台协作脚本尽量用跨平台的写法或者针对不同平台提供不同版本。5.5 排查链路总结遇到 skill 问题按这个顺序排查skill 是否被加载查列表描述文件格式是否正确编码、语法触发条件是否匹配当前场景看日志脚本是否能独立运行手动执行输入参数是否符合预期打日志输出格式是否被 agent 正确解析这个顺序从外到内能覆盖绝大多数问题。6. skills 生态的现状与个人实践建议6.1 官方市场与社区 skillsClaude Code 有官方的 skills 市场里面有不少官方和社区贡献的 skill。Codex 那边也有类似的资源。这些现成的 skill 值得先逛一圈看看别人怎么写的能省不少自己摸索的时间。但要注意现成 skill 不一定适合你的场景。别人的团队规范跟你的不一样别人的工具链跟你不一样。直接拿来用往往水土不服更好的做法是参考它们的结构改造成适合自己的版本。6.2 团队协作中的 skills 管理如果团队多人使用 skills需要一套管理机制版本控制skills 跟代码一起进 Git改动有记录命名规范skill 名称统一格式避免冲突文档说明每个 skill 有 README说明用途、用法、维护人定期清理过时的 skill 及时删避免 agent 误用6.3 我个人的几条经验用了大半年 skills有几条经验值得分享从最简单的开始。别一上来就搞复杂工作流先做一个生成文件头注释这种小 skill跑通了再扩展。描述文件比脚本重要。脚本写得再好agent 不调用也白搭。花时间打磨触发条件的描述回报很高。保留人工兜底。skill 再智能也可能出错关键操作保留人工确认环节。特别是涉及删除、部署这类不可逆操作。关注 agent 的思考过程。有些工具会输出 agent 的决策日志看看它为什么选这个 skill、为什么传这些参数能帮你优化 skill 设计。别过度封装。不是所有操作都值得做成 skill。有些一次性任务直接对话解决更快。skills 的价值在于复用不复用的东西封装了反而是负担。6.4 这个方向接下来会怎么走从目前趋势看skills 机制会越来越重要。模型能力趋同之后差异化的竞争力就在于谁能把 agent 调教得更懂自己的业务。skills 就是调教的主要手段。另一个趋势是skills 的标准化。现在 Claude Code 和 Codex 的 skills 格式还不完全通用未来可能会出现跨平台的 skill 规范写一次到处能用。这对开发者是好事但也意味着现在投入学习时要关注可迁移性别把宝全押在某个产品的私有格式上。最后说个实际体会skills 这东西看文档觉得简单真动手做才发现细节很多。但一旦跑通第一个后面的就顺了。关键是别怕踩坑每个坑踩过之后都是经验。我现在回头看最开始写的那个 skill触发条件写得一塌糊涂但正是从那个烂版本开始才慢慢摸清了门道。