OpenAI Skills 在其目录被弃用后登上 GitHub Trending

尽管 OpenAI 已弃用吸引这波关注的代码库，OpenAI skills 仍在 9 月 7 日的 GitHub Trending 榜单中升至第五位。这种反差比排名本身更值得关注。开发者正在发现一种用于复用代理指令的简单格式，而 OpenAI 则正将其分发策略转向插件。

截至 2026 年 9 月 7 日检查时，该代码库已积累 25,655 个 star 和 1,733 个 fork。GitHub 记录显示，OpenAI 于 2025 年 11 月 25 日创建该代码库，并于 2026 年 7 月 14 日最后一次推送更改。这些日期比未标注日期的 Trending 条目更清楚地说明了事件背景。

该项目并非因 skills 失败而被废弃。其公告将开发者引导至更新的 OpenAI Plugins 代码库和插件构建指南。因此，正在浮现的较量是：可复用、可移植的指令，与包含清单、工具、控制机制和分发元数据的封装扩展之间的较量。

这一差异给任何构建可重复 AI 工作流的人带来了压力。Markdown 操作手册易于审阅和共享。生产级插件则还可提供工具、身份验证、用户界面、策略控制和市场分发。OpenAI 现在似乎希望同时保留这两层能力，但将其纳入更大的软件包之中。

OpenAI Skills 在弃用后仍登上 Trending

眼下的新闻，是热度信号与官方迁移信号的碰撞。

该代码库于 9 月 7 日在所提供的 GitHub Trending 聚合榜单中位列第五。GitHub Trending 排名变化频繁，而该聚合器未提供经过验证的发布时间戳。因此，这一排名应被视为快照，而非永久的排行榜位置。

底层代码库数据则更为可靠。GitHub 的公开 API 将 2025 年 11 月 25 日标为创建日期，并显示最近一次推送日期为 2026 年 7 月 14 日。同一记录将该项目描述为“Codex 的 Skills Catalog”。

截至 9 月 7 日，该项目已获得超过 25,000 个 star。star 数并不等同于活跃安装量、满意用户数或生产环境采用情况。但它确实表明，一个存在不足一年的代码库获得了异常广泛的开发者兴趣。

项目的代码库公告改变了这种关注的含义。OpenAI 将该目录标记为已弃用，并引导读者前往 OpenAI Plugins 代码库获取当前的 Codex 示例。它还引导创作者阅读构建纯 skill 插件的新文档。

这使其不同于普通的 Trending 故事。开发者并不只是在为一个不断扩大的库点 star。他们正抵达两种代理行为分发方式之间的架构交接点。

较旧的代码库将 skills 呈现为包含指令、脚本和辅助资源的文件夹。Codex 可以发现这些文件夹，并在任务匹配时启用它们。系统 skills 会自动提供，而精选和实验性 skills 则采用安装器工作流。

新的目标将 skill 视为插件中的一种可选组件。OpenAI 的 Plugins 代码库支持清单、skills、MCP 服务器定义、应用、命令、钩子、代理元数据和资源。MCP，即 Model Context Protocol，为 AI 系统与外部工具或数据之间提供标准连接层。

迁移并未抹去较小的格式。纯 skill 插件仍可围绕同一指令单元构建。改变的是它外部的包装，包括 OpenAI 希望创作者如何分发和治理这一能力。

GitHub 的数据也需要结合背景理解。尽管其 README 称该代码库已弃用，但它并未被标记为已归档。它仍开放 issue，且仍可公开访问。OpenAI 在将活跃示例移往其他位置的同时，将其保留为参考资料。

这种组合有助于解释为何该项目会在弃用后登上 Trending。现有链接仍然有效，示例依然有用，而且这一概念比完整的插件架构更容易理解。即使不再是首选去处，该代码库正成为一个教育入口。

对开发者而言，实际信息很明确。skill 格式仍然相关，但旧目录不再是当前的分发地图。团队在围绕已弃用代码库构建安装流程前，新项目应先考虑插件层。

为什么 OpenAI Skills 如此迅速地吸引开发者

Skills 将重复提示转化为可版本管理的操作知识，无需新模型或新应用。

一个 skill 以包含元数据和指令的 SKILL.md 文件为起点。它还可包含脚本、参考资料、模板、模式和其他资源。这种结构让团队能够保存的不只是经过润色的提示词。

一个实用的 skill 可以明确其何时启用、需要哪些输入、必须执行哪些步骤，以及输出应呈现何种形式。它还可以定义代理完成任务前必须通过的检查。这些细节将非正式习惯转化为可复用的流程。

OpenAI 的skills 指南将这一格式描述为避免反复解释日常工作的方法。这种表述很容易让人理解其吸引力。许多代理失败的原因并非模型智能不足，而是缺少流程上下文。

以代码审查工作流为例。普通提示可能要求代理检查一个 pull request。一个 skill 则可以要求进行框架识别、安全检查、测试执行、证据收集以及按固定格式报告。

同样的模式也适用于软件开发之外。研究 skill 可以设定来源标准和核验规则。演示文稿 skill 可以打包版式和品牌资源。发布 skill 可以强制执行元数据、图片、翻译和质量检查。

这一模型还支持渐进式披露。代理首先看到 skill 的名称和描述，以帮助其判断该工作流是否适用。只有在启用后，它才加载完整指令。辅助文件可以继续保持未加载状态，直到任务需要它们。

这种方法减少了上下文压力。组织可以保留许多可用的专门工作流，而无需将每条指令塞进每次对话。代理会在相关时获得详细指导。

开放的Agent Skills specification将核心目录布局正式化。它要求一个包含 YAML 元数据和 Markdown 指令的 SKILL.md 文件。脚本、参考资料和资源仍为可选项。

可移植性源于这一简洁的约定。纯文本能够配合版本控制、代码审查和开发者熟悉的工具。团队可以在合并前审查对代理工作流的更改，就像审查应用代码一样。

不过，“一次编写，处处使用”仍是一种愿景，而非保证。兼容客户端可能会以不同方式解释可选字段。工具名称、权限、文件系统路径和执行环境也可能有所不同。

告诉 Codex 调用本地命令的 skill，并不会自动适用于仅支持浏览器的代理。依赖公司私有数据的工作流需要有效的连接器和权限模型。一份精心编写的指令文件无法消除这些环境差异。

即便存在这些限制，这一格式仍提供了有用的分离方式。模型提供通用推理能力，而 skill 提供本地流程。团队无需训练另一个模型或重建一个应用，就能改进流程。

这种分离也改变了所有权。领域专家可以协助以易读的 Markdown 编写工作流。工程师可以在精确行为至关重要时加入确定性脚本。审阅者则可在同一个版本化文件夹中审计两部分内容。

其结果介于提示词与传统软件之间。它比复制的指令块更具结构，又比完整应用更轻量。这一中间层解释了为何该代码库会在技术和非技术使用场景中吸引关注。

知识工作者同样面临重复问题。研究方法、会议分析、文档审阅和报告标准往往散落在各类笔记中。结构化的AI 工作流可以保留这些决策，并让它们更易复用。

OpenAI skills 之所以流行，是因为它们为这一可复用层赋予了清晰的形态。代码库的弃用并未消除底层需求。它表明 OpenAI 希望将这种形态置于更广泛的产品和分发系统之中。

OpenAI Skills 正被纳入更大的插件包

OpenAI 正在保留 skill 作为指令组件，同时改变用户安装和管理员控制的基本单元。

替代代码库让这一新边界清晰可见。每个插件都包含必需的 .codex-plugin/plugin.json 清单。清单用于标识软件包，并提供宿主可在安装和发现过程中使用的元数据。

插件随后可包含 skills、MCP 配置、应用定义、命令、钩子、资源以及面向代理的元数据。并非每个软件包都需要涵盖所有功能面。指令和打包资源已足够时，创作者仍可构建纯 skill 插件。

OpenAI 的插件打包指南指出，清单应位于插件根目录。随后，该目录可将相关能力归入同一个可安装软件包。这比复制到 skills 目录中的松散文件夹形成了更清晰的部署边界。

这正是故事中的核心对立：可移植的指令文件夹，与受治理的扩展软件包。两者并非相互排斥的技术。它们对什么应被视为可分发产品给出了不同答案。

独立 skill 优先考虑可读性和可移植性。其重心是操作手册。开发者可以克隆一个文件夹、检查其中的文件，并为另一种兼容代理调整工作流。

插件优先考虑集成。其重心是交付给用户或组织的完整能力。软件包可以将指令与外部工具、身份验证要求、界面组件和生命周期控制结合起来。

一旦工作流离开个人机器，这一区别便尤为重要。分发代理能力的公司必须回答谁来维护它、它可以访问哪些数据，以及更新如何到达。它还需要一种方法来停用或替换受损版本。

仅靠文件夹约定无法回答所有问题。宿主仍需要安装、策略、来源和权限系统。插件为 OpenAI 提供了一个容器，使这些问题能够得到明确处理。

新模型也反映出 AI agents 角色的不断扩大。早期 skill 示例通常侧重于告诉代理如何完成任务。较新的扩展则越来越需要提供完成该任务所需的操作和界面。

销售工作流说明了这种差异。指令可以解释如何筛选潜在客户并格式化摘要。完成该工作流可能还需要客户数据库连接、授权、写入控制和确认界面。

将这些部分打包在一起可以减少配置阻力，也能让管理员更容易将这一能力作为整体进行评估。代价是，对于只想分享一套可读流程的创作者而言，复杂性会随之增加。

这一转变首先给库维护者和企业团队带来压力。维护者必须决定，是保留通用的 skill 文件夹，还是采用 OpenAI 特定的打包方式。企业则必须决定将审核、批准和部署放在哪一层进行。

Agent 平台的竞争对手也面临压力。开放的 skill 格式降低了在兼容客户端之间迁移操作指导内容的成本。产品专属打包随后可围绕发现、治理、界面和连接工具形成差异化。

OpenAI 并非唯一认识到 skills 价值的公司。Agent Skills 项目表示，该格式最初由 Anthropic 开发，之后作为开放标准发布。其快速入门指南将 Claude Code、OpenAI Codex 和 GitHub Copilot 列为兼容环境。

这样的行业背景使得任何“OpenAI 拥有这一类别”的说法都站不住脚。OpenAI 维护其实现、示例和产品惯例，而底层格式属于一项旨在让 agent 操作流程可移植的更广泛努力。

因此，这一仓库转型看起来不像是对标准的退让，更像是向技术栈上层迈进。OpenAI 可以继续兼容简单的操作指导格式，同时通过围绕它的包、宿主、市场和控制平面展开竞争。

决定性问题在于，这种分层能否保持清晰。开发者应能复用核心指令，而不必携带每一项 OpenAI 专属集成。用户也应获得 plugins 所承诺的更丰富安装与安全体验。

如果这些目标能够兼容，迁移将扩大 skills 的价值。如果产品元数据和专有钩子渗入核心工作流，即便持续支持 SKILL.md，可移植性也会被削弱。

格式的简洁掩盖了安全性与可靠性风险

可读的 skill 仍可能引导 agent 执行不安全命令、访问不受信任的内容，或采取超出用户意图的行动。

不应将仓库的高人气解读为其已具备生产就绪性。GitHub stars 衡量的是兴趣，而不是安全审查；fork 数量反映的是复用或试验，而非成功部署。

Skills 处于敏感位置，因为它们会影响 agent 的行为。用户可能只会阅读标题和描述，而 agent 随后会加载详细指令、脚本或参考资料。这些更深层的资源可能影响工具选择和执行方式。

这带来了供应链风险。恶意或遭入侵的包可能包含试图获取机密、修改文件或联系意外服务的指令。如果宿主允许脚本执行，脚本会带来更直接的风险。

纯文本提高了可检查性，但前提是检查确实发生。团队应审查每一个打包文件，而非只检查 SKILL.md；在接受新版本前，也应审查更新内容。

描述还会带来另一项可靠性风险。它们决定许多 agent 在何时选择激活某项 skill。描述过于宽泛可能触发错误流程，描述模糊则可能使相关能力未被使用。

官方 skill-creator 示例强调详细描述，因为它们承担了发现功能的责任。这是实际的设计约束，而不只是无关紧要的文档偏好。激活错误可能改变 agent 所遵循的整个路径。

指令冲突又增加了一层复杂性。一个仓库可能同时包含系统策略、项目指令、用户请求和已激活的 skills。当这些来源彼此冲突时，宿主需要清晰的优先级模型。

一项 skill 不应仅因被激活就获得额外权限。Agent 仍需遵守用户范围、平台政策、沙箱限制和审批要求。单靠打包无法保证这种行为。

工具可移植性同样尚未完善。开放规范定义了 skill 的组织方式，却无法确保每个被引用的工具都可用。在一个 Codex 环境中成功的工作流，可能会因权限或连接器不同而在其他环境中失败。

本地路径和依赖项也存在同样的问题。一个打包的 Python 脚本可能假定存在特定软件包、操作系统或命令行工具。创作者需要提供明确的兼容性说明和有用的失败提示。

维护也是一项问题。当 API 变更、产品设置迁移或合规要求演进时，skill 可能会悄然过时。版本控制会记录变更历史，却无法验证其是否仍然正确。

确定性检查可以降低这一风险。创作者可以包含验证脚本、模式测试、示例输入和验收标准。团队可以在审查期间及依赖项更新后运行这些检查。

评估还应覆盖行为，而不仅是文件结构。一个有效的文件夹仍可能产生不可靠的结果。团队需要具有代表性的任务，用于测试激活、执行、错误处理和拒绝边界。

一个高星标目录的弃用说明了相关的生命周期问题。即使首选安装路径已经变化，资源仍可能长期保持可见。搜索结果和共享链接仍会将新用户引向过时指引。

OpenAI 通过醒目的通知和直接迁移链接来应对这一问题。这很有帮助，但宿主和安装器最终应在安装前显示弃用状态。对某些工作流而言，藏在 README 中的警告来得太晚。

企业很可能会要求签名包、发布者身份、版本约束、权限声明和审计轨迹。这些需求有利于 plugin 模式，但也扩大了随意的 Markdown 工作流与经批准的组织能力之间的距离。

开发者不应将任一种格式视为天生安全。小型文件夹更易于检查，而受管理的 plugin 可以支持更强的控制。两者都依赖可信分发和严格的宿主行为。

正确的安全问题不是某项 skill 是否包含代码。指令本身也可能引发后果重大的工具调用。审查必须覆盖该包说服 agent 去做什么、加载哪些资源，以及启用哪些操作。

开放标准与产品控制如今位于同一层

市场正趋向于可移植的 skill 指令，同时围绕发现、授权和分发这些指令的系统展开竞争。

Agent Skills 规范提供了一个通用的最低标准。一个目录需要 SKILL.md 文件、必填的名称和描述字段，以及 Markdown 指令。可选目录可包含脚本、参考资料和资源。

这一最低标准使跨客户端复用成为可能，但并不要求每个供应商都提供相同的安装方式或工具。每个平台都可以围绕共享文件夹结构构建自己的运行时行为。

OpenAI 的仓库曾将这种可移植性作为核心信息。其 README 将 skills 描述为可跨 agents 复用，并直接链接至开放标准。新的 plugin 方向增加了一个 OpenAI 专属包，但不一定会改变其中的 skill。

这类似于软件开发中更早出现的分层。源文件可以使用标准语言，而应用程序则通过不同的包管理器和商店发布。在一层实现兼容，并不会消除另一层的竞争。

好处在于专业化。OpenAI 可以改进安装、界面元数据和管理控制，而无需等待通用规范。其他 agent 平台也可以实现自己的打包方式，同时继续理解相同的基础 skill。

风险在于渐进式碎片化。产品专属元数据可能会成为发现功能的必要条件，供应商专属钩子也可能成为实现实用行为的必要条件。名义上可移植的工作流，随后可能在原始宿主之外失去重要能力。

创作者应尽可能将核心流程与宿主集成分离。Skill 可以描述持久的工作流；产品专属文件则可以定义界面展示、连接器、权限和安装行为。

这种分离也有助于团队管理知识。可靠的工作流通常比运行它的模型、界面或工具存续更久。保持持久流程可读，能让迁移和审计更加容易。

这一底层趋势不止涉及 OpenAI。Agent 产品越来越需要结构化方法，将组织知识带入执行过程。当 prompts 存在于个人文档或对话历史中时，很难进行治理。

Skills 让这些知识变得可见，Plugins 让它们可部署，连接工具让它们可执行。业界如今正在决定这三个层次应如何互动。

对于模型提供商而言，机会具有战略意义。丰富的扩展库可以在不要求模型内置每项能力的情况下，让 agent 更有用。它也创造了一条连接开发者、企业和用户的分发渠道。

对于企业而言，价值在于运营。团队可以标准化重复流程，同时保留可审查的源材料。当工作流需要访问公司系统时，他们可以附加受控工具。

对于个人开发者而言，权衡则更为复杂。独立 skill 仍是编码重复流程的最快方式；当分发、界面或连接服务变得重要时，plugin 才更具价值。

这个热门仓库以不同寻常的方式捕捉到了这种张力。开发者正在为易于理解的对象投票——一个他们可以阅读的文件夹。OpenAI 则在投资受管理的对象——一个产品能够安装和治理的包。

这两种信号并不互相抵消。它们共同表明，成功的 agent 生态系统需要一个小型创作原语和一个更大的交付机制。只有当交付层掩盖或锁定这一原语时，问题才会出现。

OpenAI 面临的下一个挑战，是保留推动原始目录受到关注的清晰度。Plugin 架构可以解决真实的部署问题，但不应让一个简单工作流看起来像应用程序开发。

OpenAI Skills 迁移后，开发者应关注什么

三个信号将显示 OpenAI 能否将仓库热度转化为持久的扩展生态系统。

第一个信号是迁移清晰度。OpenAI 需要提供最新示例，说明创作者何时应使用独立 skill、仅含 skill 的 plugin，或功能更丰富的 plugin。清晰的兼容性指引将强化这样一种观点：新层是在扩展 skills，而不是取代它们。

Plugins 仓库已包含超过 300 次提交，示例涵盖设计、移动开发、部署、演示文稿和连接服务。较旧的 skills 仓库则有 114 次提交。这些总数反映的是仓库活跃度而非质量，但它们揭示了新开发的集中方向。

应关注弃用目录中的热门示例是否获得直接继任者。一份有文档记录的映射将减少现有用户的困惑；如果缺少对应替代项，则意味着旧目录中的部分内容已不再符合 OpenAI 的优先事项。

第二个信号是跨客户端可移植性。开发者应测试相同的核心 SKILL.md 是否能在 Codex、Claude Code、GitHub Copilot 和其他兼容宿主中保持一致表现。成功复用将支持开放标准的承诺。

这些测试应将指令与集成分开。一套工作流可能保持可移植，而其 MCP server、界面或认证层仍保持产品专属。报告这种区别，比直接宣称整个 plugin 可移植或不兼容，能提供更有用的证据。

第三个信号是治理。OpenAI 的插件系统需要就发布者身份、权限、更新、弃用以及组织级控制给出清晰可见的说明。完善的控制机制将使额外的打包工作更具合理性，也有助于企业批准代理能力的使用。

随着插件将指令与外部操作结合，治理将变得尤为重要。用户需要知道插件能够读取哪些数据、可以修改哪些系统。管理员则需要能够按工作区和角色限制这些能力。

旧仓库为生命周期沟通提供了一个警示：README 宣布弃用后，它仍未被归档，且依然很容易被发现。更完善的安装器级提示可以避免用户在未看到警告的情况下采用过时的软件包。

开发者还应关注两个仓库的相对增长情况。若已弃用目录仍持续获得 star，说明对简单示例的需求依然存在。若插件的采用速度更快，则表明这一更广泛的软件包已变得足够易于理解，可供主流用户使用。

一次出现在 GitHub Trending 上不足以证明上述任何一种结果。除 9 月 7 日的快照外，该排名没有经过验证的时间戳，也未提供安装量或留存数据。更有力的证据将来自持续维护的示例、成功的迁移，以及可重复的跨客户端测试。

对于目前正在评估 OpenAI skills 的团队，合理做法是将工作流逻辑保留在符合标准的 SKILL.md 中。新的分发工作应遵循 OpenAI 的插件指导，并将产品特定的集成置于核心流程之外。

这种做法既能保护可复用的知识，也承认 OpenAI 正在前进的方向。安装前应审查脚本和权限，记录来源修订版本，并使用具有代表性的任务测试该工作流。

最后的问题很实际：你的代理需要更好的指令，还是需要一个具备工具与治理能力的完整扩展？先从能够解决重复性任务、且经过审查的最小 skill 开始。当分发、已连接的操作或组织级控制成为需求的一部分时，再升级为插件。