OpenAI将淘汰自定义GPT，非营利组织AI负责人：真正替代方案还没有

致OpenAI的公开信：请勿在无真正替代方案前取消自定义GPT

OpenAI决定淘汰自定义GPT，似乎是基于这样一个假设：Plugins、Skills、Projects、Apps和Workspace Agents加在一起，能够替代它们的全部功能。

对许多中小企业和企业客户来说，事实并非如此。

我在一家全球性非营利组织负责人力资源和负责任AI（Responsible AI），也帮助各类组织学会有效运用AI。我不是软件开发者，和我共事的大多数人也不是。

自定义GPT让业务用户得以创建强大的工具，与同事和外部协作者分享，安全地连接到其他系统，并让工具的行为不依赖于具体的使用者。

除非企业雇用了软件开发者，否则OpenAI正在让这些能力失去合理的替代方案。

真正正在失去的东西

我理解，自定义GPT的许多单体功能可以在别处重建。指令可以变成Skills，文件可以放进Skills或Projects，Projects可以提供持久上下文，Workspace Agents可以提供更多自主性，Apps和MCP可以支持集成。

但这些都无法重建共享GPT在组织使用中特别重要的几项特性：

+ 一个集中治理的助手，为每个用户提供相互独立的私人对话

+ 与每个用户的个人记忆及无关的ChatGPT历史记录之间的行为隔离

+ 由创建者控制、对使用者隐藏的指令

+ 能将同一套配置好的工具分享给其他组织（如顾问或客户）

+ 使用API密钥或OAuth原生认证的Actions，无需组织自行构建和维护软件

这些能力合在一起，为非开发者创造了一个轻量级业务应用平台。这一竞争优势是OpenAI所独有的，一直是许多人推荐采用ChatGPT的依据。

1. 共享的Project不同于共享的GPT

Projects解决不了分享问题。

分享GPT时，每个人得到的是同一个工具，但各自拥有与该工具的独立私人对话。其他用户看不到这些对话，也看不到GPT的指令。

共享的Project运作方式迥然不同。你分享的对象可以看到Project的聊天记录、文件和指令。

对许多业务场景来说，这根本无法成立。员工可能需要与工具讨论保密事项；在同一个项目上合作的顾问可能需要各自的独立对话；用户不应自动看到其他人的提问内容，也通常不应看到构建工具所用的指令。

Projects的设计初衷是让人们在共享空间中协作。GPT则允许许多人使用同一个工具，同时不必把各自的工作内容暴露给彼此。

这是两种根本不同的业务需求。

2. 创建者掌控指令层

共享GPT可以被许多人使用，却无需暴露其治理指令。

这些指令可能包含专有工作流、内部流程、质量控制、安全规则、方法论、其他知识产权或保密边界。例如：“只向高管团队成员披露或确认[信息X]。”

用户获得的是功能，而非底层配置。

这是软件的基本属性：人们可以使用产品，却拿不到产品源代码。

如果取代GPT意味着分发可编辑的Skills、指令文件或其他配置材料，那么即使ChatGPT仍然能执行同样的任务，创建者也已经失去了某些重要的东西。

3. GPT可以跨越组织边界

GPT还可以分享给创建者工作区之外的人。

这使得它在涉及顾问、客户、律师、承包商、合作伙伴组织、供应商及其他外部协作者的项目中格外有用。每个人都能使用同一套配置好的工具，同时各自保有私人对话，创建者也保留着对指令的控制权。

局限于单一组织的Workspace Agent、绑定在工作区内的Project，或需要每个参与者分别安装的Skill，都无法重建这种简单的协作模式。

4. GPT让安全集成不再需要代码

自定义GPT可以使用API密钥或OAuth连接到外部系统，懂行的业务用户完全可以在ChatGPT内部完成这种连接的配置。

不需要MCP服务器，不需要自定义后端，不需要开发者，就能让AI安全地对接现有系统。

Skill无法安全地保存这些凭证。如果OpenAI没有提供现成的App或连接器，替代方案就可能需要自定义App、MCP服务器或其他集成工作。

一旦用户不得不处理这些东西，他们就不再只是配置ChatGPT，而是在构建软件了。

许多中小企业既没有软件开发者，也没有其他具备时间和技能来构建并维护此类方案的人。对他们而言，这不是一个更复杂的替代方案，而是这项能力的彻底丧失。

提议的替代方案解决的是不同的问题

Skills、Projects、Plugins、Apps和Workspace Agents都很有用。它们只是无法重建上述各项能力的组合。

Skills提供可复用的行为，但没有同样的私密共享工具模式，也没有安全认证。Projects提供共享工作空间，但参与者能看到共享的聊天记录、文件和指令。Workspace Agents增加自主性与编排能力，当你想要自主性时这很有价值——可有时候你要的并不是自主性。

Plugins还有另一个问题：许多组织出于AI、安全或IT治理方面的考量，禁止或严格限制使用Plugins。如果客户的治理框架不允许部署某个技术方案，那它就不是一个实际可行的替代方案。

而且即便允许使用Plugins，打包Skills和Apps也不能消除构建缺失集成的需求。

有时候，企业只是需要一个工具：遵循既定指令，使用既定知识，或许还要安全地连接到另一个软件，让每个用户拥有私人对话，并且对所有人表现一致。

自定义GPT在这些方面做得极其出色。

为什么这对SMB企业客户重要

SMB企业客户往往没有在编的开发者。即使有，他们大概也没有时间去搭建MCP服务器、Plugins之类的东西来替代GPT。

也不是每个组织都能简单地通过启用更多Apps、Plugins或更自主的Agent来应对。许多企业出于治理和安全要求，刻意限制了这些能力。

生成式AI的一大进步，是让理解问题的那个人能够亲手构建解决方案。自定义GPT正是实现这一点的重要助力。

这也不是为了省几个token或积分的钱。如果一个更好的系统使用成本略高，企业自会判断价值是否抵得上开销。问题在于功能。

为了保住今天已经原生的能力，反而要求企业去做软件开发、放松现有治理控制——这完全是走错了方向。

有一个直截了当的解决方案

OpenAI不需要放弃Skills、Plugins、Apps、MCP、Projects或Workspace Agents。把它们都留着。

但是，请保留一个无代码层，让SMB企业用户继续拥有自定义GPT今天提供的各项能力。

叫它GPT也好，叫它Agent也好，叫别的名字也行。名称并不重要。重要的是，业务用户仍然应该能够创建这样的工具：

+ 由创建者控制、对普通用户隐藏的指令

+ 上传的知识与参考资料

+ 与个人记忆及无关对话相隔离

+ 每个用户拥有独立的私人对话

+ 可在组织内外分享

+ 安全的API密钥与OAuth认证

+ 通过认证的Actions

+ 在组织政策允许时，选用合适的Skills、Apps、连接器和工具

+ 适当的权限与治理控制

在底层，OpenAI可以随意组合Skills、Plugins、Apps、Projects、连接器、MCP服务或其他架构。业务用户不需要关心这些。

不要把业务工具变成软件项目

自定义GPT让非开发者能够构建、控制、分享并安全地连接有用的AI工具。在目前提出的替代方案中，没有一个能为普通业务用户保留这种组合。

在真正的替代方案出现之前，OpenAI不应该淘汰这一能力。保留新架构，也保留无代码层。企业不应该需要开发者，也不应该需要放松治理，才能继续做ChatGPT今天已经让它们做到的事情。

―― 高票评论（帖子共 4 条讨论）――

[+3] u/Flaky-Flamingo-00：发起请愿，要求OpenAI重新考虑：https://c.org/sTfSGH4QjK

[+2] u/AlbertDread：你的自定义GPT指令对用户来说并不安全，真的。

[+1] u/Reclaimer_AI：我们真的只是需要在App和网站上为所有用户提供skills.md。Claude已经有了，为什么OpenAI还在落后？