1. 从“skills”这个热词说起：它到底是什么，为什么突然火了
最近几个月，不管是在技术社区、开发者群聊，还是在做AI应用的朋友圈子里，“skills”这个词出现的频率高得离谱。有人叫它 Agent Skills，有人叫它 Claude Agent Skills，还有人直接简称为 skills。热搜词里甚至出现了“今天学会了skills，打开新世界”这种非常情绪化的表达。作为一个在AI应用开发一线摸爬滚打多年的人，我一开始也以为这不过是又一个新瓶装旧酒的营销概念，直到我自己动手把一套 skills 体系从设计、开发到部署完整跑了一遍，才意识到这东西确实值得认真聊一聊。
简单来说，skills 是一种把“能力”模块化、可复用化的组织方式。你可以把它理解成给 AI Agent 准备的“技能包”——每个 skill 封装了一类特定的任务逻辑、工具调用、提示词模板和输出规范。当 Agent 面对一个具体场景时，它不需要从零开始推理该怎么做，而是直接加载对应的 skill，按照预定义的流程执行。这听起来有点像传统的函数库或者微服务，但关键区别在于：skills 是面向自然语言交互设计的，它既要让机器能执行，也要让人能读懂、能修改、能组合。
为什么现在火了？我的判断是三个因素叠加的结果。第一，Agent 应用从 demo 走向生产，大家发现光靠一个通用大模型加一堆工具调用，稳定性根本不够，必须把常见任务固化下来。第二，Google Cloud、GKE、Genkit 这些平台开始原生支持 skills 的编排和部署，基础设施跟上了。第三，社区里出现了大量可复用的 skills 仓库，从写论文到做分镜，从代码审查到自动化测试，覆盖场景越来越广，形成了正向循环。如果你正在做 AI Agent 相关的开发，或者哪怕只是想让日常工作效率更高一点，理解 skills 的设计思路和实操方法，都是当下性价比很高的一件事。
2. 拆解 skills 的核心设计思路：为什么不是简单的提示词模板
2.1 从“一次性提示词”到“可组合能力单元”的思维转变
很多人第一次接触 skills 的时候，会把它等同于“写得更长的提示词”。我一开始也这么想，但实际用下来发现完全不是一回事。普通的提示词模板是静态的、扁平的，你写一段话告诉模型“你是一个资深编辑，请帮我改文章”，模型每次执行都依赖它自己的理解，输出质量波动很大。而一个设计良好的 skill，它是一个结构化的能力单元，包含至少四个组成部分：触发条件、执行逻辑、工具依赖和输出契约。
触发条件决定了这个 skill 什么时候被激活。比如一个“代码审查 skill”，它的触发条件可能是“当用户提交了一段代码并询问潜在问题时”。执行逻辑是核心，它可能是一段精心设计的推理链，也可能是一组按顺序调用的工具函数。工具依赖声明了这个 skill 需要哪些外部能力，比如文件读写、网络请求、数据库查询。输出契约则规定了返回结果的格式，是 Markdown 还是 JSON，包含哪些字段，字段类型是什么。这四个部分合在一起，才构成一个可复用、可测试、可组合的 skill。
我举个实际例子。假设你要做一个“自动生成周报”的 skill。如果只是写提示词，你可能会说“请根据我这周的工作记录生成一份周报”。但做成 skill 之后，触发条件可能是“每周五下午五点或用户主动请求”，执行逻辑包括“读取本周的 Git 提交记录、读取任务管理工具中已完成的任务、按项目分组、生成摘要”，工具依赖包括 Git 命令行接口和任务管理 API，输出契约规定“返回 Markdown 格式，包含本周完成、下周计划、风险项三个二级标题”。这样设计之后，这个 skill 就可以被不同的 Agent 复用，也可以和其他 skill 串联，比如先调用“数据收集 skill”，再调用“周报生成 skill”，最后调用“邮件发送 skill”。
2.2 为什么 skills 比微调更轻，比纯提示词更稳
这里要解释一个关键选择：为什么大家不直接微调模型，或者干脆用更复杂的提示词工程？我的经验是，微调的成本太高，而且一旦业务逻辑变化，微调后的模型很难快速调整。纯提示词又太脆弱，稍微换个模型版本或者换个输入格式，输出就可能崩掉。skills 走的是中间路线：它把确定性逻辑放在代码和工具调用里，把不确定性留给模型推理，同时用结构化的契约来约束输出。
具体来说，一个 skill 里面通常会有“硬编码”的部分和“软推理”的部分。硬编码的部分比如 API 调用、数据格式转换、条件判断，这些用代码实现，稳定可靠。软推理的部分比如理解用户意图、生成自然语言摘要、做主观判断，这些交给模型。两者通过明确的接口衔接。这样做的好处是，当模型升级或者更换时，只要接口不变，skill 的整体行为就不会有太大变化。我实测下来，同一个 skill 在多个主流模型上都能跑出可接受的结果，而纯提示词方案换模型后往往需要重新调优。
还有一个容易被忽略的点：skills 天然支持版本管理和灰度发布。你可以把每个 skill 当成一个独立的软件包，有版本号、有变更日志、有测试用例。当某个 skill 的逻辑需要调整时，你可以只更新那一个 skill，而不影响其他部分。这在生产环境里太重要了。我见过太多项目因为提示词散落在各个角落，改一处崩三处，最后没人敢动。skills 的模块化设计从根上缓解了这个问题。
2.3 与 Google Cloud、GKE、Genkit 的关系：基础设施如何支撑 skills 落地
热搜词里出现了 Google Cloud、GKE、Genkit，这不是偶然。skills 要真正在生产环境跑起来，需要一套完整的基础设施：计算资源、编排引擎、工具注册中心、日志监控。Google Cloud 提供了底层的算力和存储，GKE 提供了容器编排能力，让每个 skill 可以打包成容器独立部署和扩缩容，Genkit 则提供了面向 AI 应用的开发框架，简化了 skill 的定义、测试和集成。
我自己的做法是，把每个 skill 写成一个独立的服务，用 Docker 打包，部署在 GKE 集群上。Genkit 负责定义 skill 的输入输出 schema，以及和模型交互的部分。这样做的好处是，skill 之间通过标准接口通信，可以独立升级，也可以根据负载单独扩容。比如“代码审查 skill”在白天调用频繁，就多开几个实例；“周报生成 skill”只在周五下午用，就保持最小实例数。这种弹性是单体应用很难做到的。
当然，不是每个人都需要这么重的方案。如果你只是个人使用，完全可以在本地用脚本加模型 API 跑起来。但如果你要做团队协作或者对外提供服务，基础设施的考量就绕不开了。我的建议是，先从简单的本地实现开始，验证 skill 的逻辑和效果，等确实有规模化需求了，再迁移到云端。不要一上来就追求架构完美，那样很容易陷入过度设计。
3. 动手开发一个 skill：从零到可运行的完整流程
3.1 环境准备与工具选型：你需要哪些东西
在开始写第一个 skill 之前，先把环境搭好。我假设你用的是 Python 生态，因为目前大部分 AI 应用开发工具对 Python 支持最好。你需要准备以下几样东西：一个模型 API 的访问凭证，一个代码编辑器，一个版本管理工具，以及一个用来测试 skill 的简单界面。模型 API 可以是任何主流提供商的，这里不具体推荐，你根据自己情况选。代码编辑器我用 VS Code，插件装好 Python 和 Docker 就行。版本管理用 Git，这个不用多说。
如果你打算用 Genkit，需要额外安装它的 CLI 工具。Genkit 支持多种语言，我用的是 Python 版本。安装命令很简单，用 pip 就能搞定。安装完之后，你可以用genkit init初始化一个项目骨架，它会自动生成目录结构和配置文件。我建议一开始就用它的项目模板，因为里面已经包含了一些最佳实践的示例，比如如何定义 skill 的输入输出 schema，如何注册工具，如何写测试。自己从零搭也不是不行，但容易漏掉一些细节，后面补起来麻烦。
另外，我强烈建议你准备一个简单的命令行测试工具。不需要多复杂，一个 Python 脚本就行，功能是接收用户输入，调用你的 skill，打印输出结果。这个工具会在开发过程中反复用到，越简单越好。我见过有人一上来就搞 Web 界面，结果大部分时间花在前端调试上，skill 本身的逻辑反而没时间打磨。记住，先让核心逻辑跑通，界面的事情后面再说。
3.2 定义 skill 的输入输出契约：别让模型自由发挥
这是整个开发过程中最关键的一步，也是最容易做错的一步。很多人写 skill 的时候，输入输出定义得非常模糊，比如输入就是“一段文本”，输出就是“一段文本”。这样做的后果是，模型每次返回的格式都不一样，下游处理起来极其痛苦。正确的做法是，用结构化的 schema 来定义输入输出，就像定义 API 接口一样严格。
我拿一个实际例子来说明。假设我要做一个“会议纪要生成 skill”。输入 schema 我会这样定义：包含meeting_title（字符串，必填）、participants（字符串列表，必填）、raw_notes（字符串，必填，原始记录）、output_format（枚举，可选，默认 Markdown）。输出 schema 包含summary（字符串，会议摘要）、action_items（对象列表，每个对象有owner和task两个字段）、decisions（字符串列表，关键决策）。这样定义之后，模型就知道它必须按照这个结构来组织输出，而不是随便写一段话。
在实际编码时，我会用 Pydantic 或者类似的库来定义这些 schema，然后在调用模型时，把 schema 转换成 JSON Schema 传给模型，要求它按照这个格式返回。同时，在代码里做一层校验，如果模型返回的结果不符合 schema，就触发重试或者降级处理。这一步虽然麻烦，但能极大提升 skill 的稳定性。我实测下来，加了 schema 校验之后，输出格式错误率从大概百分之十几降到了百分之一以下。
注意：schema 不要定义得太细，否则会限制模型的推理能力。比如
summary字段，你只需要规定它是字符串，不要规定字数或者具体结构。把确定性的部分交给代码，把灵活性的部分留给模型，这个平衡点需要根据具体场景反复调试。
3.3 编写执行逻辑：硬编码与软推理的边界在哪里
执行逻辑是 skill 的主体。我的经验是，把整个执行过程分成三个阶段：预处理、模型推理、后处理。预处理阶段做确定性的工作，比如读取文件、调用 API 获取数据、清洗输入格式。模型推理阶段把预处理的结果和提示词一起发给模型，让它生成核心内容。后处理阶段对模型的输出做校验、格式化、补充元数据。
还是以会议纪要 skill 为例。预处理阶段，我会检查raw_notes是否为空，如果为空就直接返回错误，不浪费模型调用。然后根据participants列表，生成一个参会人姓名的字符串，方便模型在摘要中引用。模型推理阶段，我会构造一个提示词，包含角色设定、任务描述、输入数据和输出格式要求。提示词里会明确说“请从原始记录中提取关键决策和行动项，行动项必须指定负责人”。后处理阶段，我会校验action_items里的每个对象是否都有owner和task，如果缺失就尝试从原文中推断，推断不出来就标记为“待确认”。
这里的关键判断是：哪些事情让模型做，哪些事情自己做。我的原则是，涉及事实准确性的、涉及格式规范的、涉及安全边界的，尽量自己做。涉及理解语义的、涉及生成自然语言的、涉及主观判断的，交给模型。比如“从原始记录中提取行动项”这件事，模型比规则引擎做得好，就交给模型。但“行动项必须包含负责人字段”这件事，用代码校验比让模型自觉遵守更可靠。
3.4 测试与迭代：怎么判断一个 skill 是否合格
写完第一个版本之后，不要急着集成到生产流程里。先做一轮系统的测试。我的测试方法分三层：单元测试、场景测试、压力测试。单元测试针对 skill 内部的每个函数，确保输入输出符合预期。场景测试用真实的、有代表性的输入数据跑一遍，看整体输出是否合理。压力测试用大量数据或者边界情况来跑，看 skill 会不会崩溃或者输出异常。
场景测试的用例设计很讲究。我会准备至少三组数据：一组是“理想情况”，输入格式规范、内容清晰；一组是“边界情况”，输入很短或者很长，或者包含一些噪声；一组是“异常情况”，输入缺失关键字段或者格式完全不对。每组数据跑完之后，我会人工检查输出，记录哪些地方符合预期，哪些地方需要调整。这个过程通常要重复三到五轮，才能让一个 skill 达到可用的状态。
还有一个我踩过的坑：不要只用一个模型测试。同一个 skill 在不同模型上的表现可能差异很大。我建议至少用两个不同提供商的模型跑一遍，看看输出是否都在可接受范围内。如果某个模型上表现特别差，要么调整提示词，要么在 skill 里做模型适配层。虽然麻烦，但能避免以后换模型时出现意外。
4. 把 skills 用起来：集成、编排与生产部署
4.1 单个 skill 的集成方式：API、SDK 还是命令行
skill 开发完之后，下一步是把它集成到你的应用里。集成方式主要有三种：HTTP API、SDK 调用、命令行工具。选择哪种取决于你的使用场景。如果你要做的是一个 Web 应用或者移动应用，HTTP API 是最自然的选择。把 skill 包装成一个 RESTful 接口，接收 JSON 输入，返回 JSON 输出。这种方式的优点是语言无关，任何能发 HTTP 请求的地方都能用。缺点是需要额外处理网络延迟、错误重试、认证授权这些事情。
如果你是在 Python 或者 Node.js 项目里用，SDK 调用会更方便。你可以把 skill 写成一个库，直接 import 进来调用函数。这样没有网络开销，调试也简单。但缺点是语言绑定，换语言就得重写。命令行工具适合脚本化和自动化场景，比如在 CI/CD 流程里调用，或者在终端里手动执行。我自己的做法是，核心逻辑写成一个独立的 Python 包，然后同时提供 SDK 和 CLI 两种调用方式，需要 HTTP 服务的时候再用 FastAPI 包一层。这样灵活性最高。
不管用哪种方式，都要注意错误处理和超时控制。skill 内部可能调用外部 API，可能调用模型，这些操作都可能失败或者变慢。我通常会给每个 skill 设置一个总超时时间，比如 30 秒，超过就返回降级结果或者错误信息。同时，对于可重试的错误，比如网络抖动，做最多三次的重试，每次间隔递增。这些细节看起来不起眼，但在生产环境里能避免很多半夜被叫起来处理故障的情况。
4.2 多 skill 编排：让 Agent 自己决定调用哪个
单个 skill 只能解决单一问题，真正的威力在于多个 skill 的组合。比如一个“内容创作 Agent”，它可能包含“选题调研 skill”、“大纲生成 skill”、“初稿撰写 skill”、“事实核查 skill”、“润色优化 skill”。当用户提出一个创作需求时，Agent 需要自己判断该调用哪些 skill，以什么顺序调用，以及如何处理 skill 之间的数据传递。
目前主流的编排方式有两种：一种是显式编排，开发者预先定义好流程，比如“先调 A，再调 B，如果 B 的输出满足条件就调 C，否则调 D”。这种方式可控性强，但灵活性差，遇到预设之外的情况就处理不了。另一种是隐式编排，把可用的 skill 列表和描述提供给模型，让模型自己决定调用哪个。这种方式灵活，但稳定性差，模型可能选错 skill 或者陷入循环调用。
我的实践经验是，采用混合策略。对于核心流程，用显式编排保证稳定性。对于辅助决策，用隐式编排增加灵活性。比如内容创作 Agent，我会显式定义“必须先做事实核查再做润色”，但“选题调研”和“大纲生成”之间，让模型根据用户输入自己判断是否需要调研，以及调研的深度。这样既保证了关键环节不出错，又给模型留了发挥空间。
编排的另一个难点是数据传递。skill A 的输出可能是 skill B 的输入，但两者的 schema 不一定完全匹配。我通常会在编排层加一个适配器，负责把上游 skill 的输出转换成下游 skill 能接受的格式。这个适配器用代码实现，逻辑清晰，也方便测试。不要指望模型自己完成格式转换，它可能会漏字段或者改字段名，导致下游 skill 报错。
4.3 部署到 GKE：容器化、扩缩容与监控
如果你要把 skills 部署到生产环境，GKE 是一个值得考虑的选项。我的部署流程是这样的：每个 skill 打包成一个 Docker 镜像，镜像里包含 skill 的代码、依赖和启动脚本。然后写一个 Kubernetes Deployment 描述文件，指定副本数、资源限制、环境变量。再用 Service 暴露一个内部地址，供其他 skill 或者网关调用。最后配置 Horizontal Pod Autoscaler，根据 CPU 使用率或者自定义指标自动扩缩容。
资源限制这块要特别注意。模型调用是 IO 密集型的，CPU 和内存占用不一定高，但响应时间可能很长。我一开始按照常规 Web 服务的标准配置资源，结果发现 skill 经常因为超时被 kill。后来调整了策略，给每个 Pod 设置较大的内存和较宽松的存活探针，同时把超时时间调长。另外，模型 API 的调用凭证通过 Kubernetes Secret 管理，不要硬编码在镜像里。这些安全细节虽然基础，但很容易被忽略。
监控方面，我用了三个层面的指标：基础设施层面看 CPU、内存、网络；应用层面看每个 skill 的调用次数、成功率、平均延迟；业务层面看输出质量，比如用户满意度或者人工抽检通过率。前两个层面用 Prometheus 和 Grafana 就能搞定，第三个层面需要自己埋点。我通常会在 skill 的输出里加一个confidence字段，让模型自己评估这次输出的可信度，然后统计低可信度输出的比例。这个指标虽然不完美，但能提前发现很多问题。
4.4 成本控制：模型调用、计算资源和时间成本
skills 跑起来之后，成本是一个绕不开的话题。主要成本来自三块：模型 API 调用费用、计算资源费用、以及开发和维护的时间成本。模型调用费用通常是大头，尤其是当 skill 被频繁调用或者输入输出很长的时候。我的优化策略是，在预处理阶段尽量过滤掉不需要模型处理的请求，比如输入为空或者明显无效的请求直接返回错误。在模型选择上，不是所有 skill 都需要用最贵的模型，一些简单的格式化或者分类任务，用便宜的小模型就够了。
计算资源费用方面，GKE 的按需实例比较贵，如果负载稳定，可以考虑用预留实例或者抢占式实例。抢占式实例便宜很多，但可能被随时回收，适合那些可以容忍中断的 skill。我通常把核心 skill 放在稳定实例上，把批处理或者非实时 skill 放在抢占式实例上。这样能省下不少钱。时间成本是最容易被低估的，开发和维护 skills 需要持续投入，尤其是当模型升级或者业务需求变化时。我的建议是，把 skill 的代码和提示词都纳入版本管理，每次修改都记录变更原因和测试结果，这样后面维护起来会轻松很多。
5. 常见问题与排查技巧实录
5.1 模型不按 schema 返回怎么办
这是最常见的问题，没有之一。你明明定义了输出 schema，模型就是不好好返回，要么少字段，要么字段类型不对，要么干脆返回一段自然语言。我的排查思路是这样的：首先检查提示词里是否清晰描述了 schema，最好把 JSON Schema 直接贴在提示词里，并明确说“必须严格按照此格式返回”。其次检查模型是否支持结构化输出，有些模型有专门的参数可以强制 JSON 格式，开启之后成功率会高很多。如果还是不行，就在后处理阶段加一层修复逻辑，比如用正则提取 JSON 部分，或者用另一个模型调用做格式转换。
我实测下来，最有效的组合是：提示词里贴 schema + 开启模型的结构化输出参数 + 后处理校验和重试。这三层加起来，格式错误率能降到千分之一以下。另外，schema 本身不要设计得太复杂，嵌套层级不要超过三层，枚举值不要太多，否则模型很容易搞混。
5.2 skill 之间互相调用导致死循环
多 skill 编排的时候，如果让模型自己决定调用顺序，有可能出现 A 调用 B，B 又调用 A 的情况，形成死循环。我遇到过一次，两个 skill 互相认为对方应该先处理，结果来回调用了十几次，把 token 额度都耗光了。解决办法是在编排层加一个调用栈记录，每次调用 skill 之前检查是否已经在栈里，如果在就拒绝调用并返回错误。同时设置一个最大调用深度，比如 5 层，超过就强制终止。
另外，给每个 skill 加一个“幂等性”设计也很重要。也就是说，同一个输入多次调用同一个 skill，应该得到相同的结果，而不是每次都不一样。这样即使出现重复调用，也不会产生副作用。实现幂等性的方法很简单，在 skill 内部对输入做哈希，如果发现相同的哈希已经处理过，就直接返回缓存结果。
5.3 输出质量不稳定，时好时坏
这个问题通常和提示词设计、输入数据质量、模型温度参数有关。我的排查步骤是：先固定输入数据，用同一个 skill 跑十次，看输出差异有多大。如果差异很大，说明提示词不够明确或者温度参数太高。把温度调到 0 或者接近 0，再跑十次，看是否稳定。如果还是不稳定，就要检查提示词里是否有歧义，比如“请生成一份摘要”这种模糊指令，应该改成“请生成一份不超过 200 字的摘要，包含三个要点”。
输入数据质量也很关键。如果输入本身就很乱，模型很难产出高质量输出。我通常会在预处理阶段做数据清洗，比如去除多余空格、统一日期格式、把长文本分段。这些工作看起来琐碎，但对输出质量的提升非常明显。还有一个技巧是，在提示词里加几个“少样本示例”，也就是给模型看几个输入输出的例子，它模仿起来会准确很多。
5.4 排查速查表
| 问题现象 | 可能原因 | 排查方法 | 解决措施 |
|---|---|---|---|
| 输出格式错误 | schema 不清晰或模型不支持 | 检查提示词和模型参数 | 贴 JSON Schema，开启结构化输出 |
| 调用超时 | 模型响应慢或网络问题 | 查看日志中的耗时分布 | 增加超时时间，加缓存，换模型 |
| 输出内容空洞 | 提示词太泛或输入信息不足 | 人工检查输入和提示词 | 细化提示词，补充输入数据 |
| skill 死循环 | 编排逻辑缺陷 | 查看调用栈记录 | 加调用深度限制和幂等设计 |
| 成本突然升高 | 调用量增加或输入变长 | 统计调用次数和 token 消耗 | 加预处理过滤，换便宜模型 |
| 输出不一致 | 温度参数高或提示词有歧义 | 固定输入跑多次对比 | 降低温度，消除提示词歧义 |
提示：这张表是我自己遇到问题时总结的，不一定覆盖所有情况，但能解决八成以上的常见故障。建议你把它打印出来贴在工位上，出问题的时候先对照排查，能省不少时间。
6. 我踩过的坑和总结出的几条硬经验
6.1 不要追求一次做到完美，先跑通再优化
我刚开始做 skills 的时候，总想把每个细节都设计好再动手，结果花了大量时间在架构设计上，真正写代码的时间反而很少。后来我改变了策略，先用最简陋的方式把核心逻辑跑通，哪怕提示词写得很粗糙，schema 定义得很简单，只要能看到输出就行。跑通之后，再根据实际效果逐步优化。这样做的好处是，你能快速得到反馈，知道哪些地方是真正的瓶颈，哪些地方其实没那么重要。
举个例子，我做的第一个 skill 是“自动回复邮件”。第一版只用了最简单的提示词，输出格式也没严格定义。跑了几次之后发现，最大的问题不是格式，而是模型经常误解邮件意图。于是我把精力集中在改进意图识别的提示词上，格式问题反而很容易就解决了。如果一开始就纠结格式，可能会走弯路。
6.2 日志和可观测性不是可选项，是必选项
skill 在生产环境跑起来之后，如果没有完善的日志，出了问题你根本不知道从哪里查。我要求每个 skill 至少记录以下信息：调用时间、输入摘要、输出摘要、耗时、模型名称、token 消耗、是否命中缓存、错误信息。这些信息用结构化格式记录，比如 JSON Lines，方便后续用工具分析。我还会给每个请求分配一个唯一 ID，贯穿整个调用链，这样排查问题时可以追踪一个请求经过了哪些 skill，每个环节花了多少时间。
可观测性还包括指标监控和告警。我设置了几个关键告警：错误率超过 5% 告警，平均延迟超过 10 秒告警，token 消耗超过预算告警。这些告警通过邮件或者即时通讯工具发出来，让我能第一时间知道出了问题。虽然有时候会被误报打扰，但总比出了问题没人知道要好。
6.3 社区资源很好用，但不要直接抄
现在社区里有很多开源的 skills 仓库，从写论文到做分镜，从代码审查到自动化测试，应有尽有。我一开始很兴奋，直接下载了几个来用，结果发现效果并不理想。原因是这些 skill 通常是针对特定场景和特定模型调优的，换一个场景或者换一个模型，效果就会打折扣。而且有些 skill 的提示词写得很复杂，你如果不理解它的设计思路，出了问题根本没法改。
我的建议是，把社区资源当作参考，而不是直接拿来用。看到一个好的 skill，先分析它的结构：触发条件怎么定义的，执行逻辑分几步，工具依赖有哪些，输出契约长什么样。理解之后，根据自己的场景重新实现一遍。这个过程虽然慢，但你能真正掌握 skill 的设计方法，后面遇到新需求也能自己搞定。另外，社区资源里的提示词技巧很值得学习，比如怎么用少样本示例，怎么引导模型分步推理，这些通用技巧可以直接借鉴。
6.4 模型会变，skill 要能跟着变
这是一个容易被忽视的问题。你精心调优的 skill，可能在模型升级之后效果就变了。我遇到过好几次，模型小版本更新后，原本稳定的输出开始出现格式错误。原因是模型的输出风格发生了细微变化，而我的后处理逻辑没有足够的容错能力。从那以后，我在设计 skill 的时候，会刻意让后处理逻辑更健壮，比如用更宽松的正则表达式，对字段缺失做默认值处理，对类型错误做自动转换。
另外，我会定期用回归测试集跑一遍所有 skill，看看输出质量有没有下降。回归测试集是一组固定的输入和期望输出，每次模型更新或者 skill 修改后都跑一遍。如果发现某个 skill 的输出偏离了期望，就及时调整。这个习惯帮我避免了好几次线上事故。虽然维护测试集需要花时间，但比起出了问题再补救，这个投入是值得的。
6.5 关于 skills 的未来，我的个人判断
最后聊一点个人看法。skills 这个概念现在很火，但我认为它不会取代传统的软件开发，而是会成为软件开发的一种补充。它擅长处理那些规则模糊、需要自然语言理解的任务，比如内容生成、意图识别、信息提取。但对于规则明确、要求高确定性的任务，比如金融交易、医疗诊断，传统的代码逻辑仍然是更可靠的选择。
未来我猜测 skills 会朝着两个方向发展：一是标准化，出现通用的 skill 描述格式和交换协议，让不同平台开发的 skill 可以互相调用；二是智能化，skill 能够根据运行时的反馈自动调整自己的提示词和参数，减少人工调优的工作量。这两个方向都还在早期，但已经能看到一些苗头。如果你现在开始积累自己的 skill 库，等生态成熟的时候，这些积累会成为很有价值的资产。
我个人在实际操作中的体会是，skills 最大的价值不在于技术本身，而在于它强迫你把模糊的需求拆解成清晰的能力单元。这个过程本身就是一种思维训练。当你习惯了用 skill 的视角看问题，你会发现很多以前觉得复杂的事情，其实可以分解成几个简单的步骤，每个步骤交给一个专门的 skill 去处理。这种思维方式，比任何具体的工具都更有生命力。
