ChatGPT Sites 将想法变成可发布的网站，但真正的考验在于发布

OpenAI 推出了公开测试版，ChatGPT Sites 可以将想法转化为可发布的网站，省去了过去将原型与上线产品区分开的部署环节。

7 月 10 日的更新让 ChatGPT 能够根据提示或兼容项目创建、托管、优化并分享网站、Web 应用和游戏。一篇 OpenAI Developers 帖子通过公司团队成员创建的网站展示了这项功能，其中包括一款个人专注应用。

真正重要的变化并不在于 ChatGPT 能够生成网站。多年来，AI 编程产品一直具备这一能力。如今，ChatGPT Sites 将生成、存储、访问控制、分析、版本管理和生产环境托管整合进了一个对话式工作流。

这一组合给 Lovable 和 Replit 等基于提示词的构建工具带来了压力，同时也对 Vercel 这样的托管平台构成挑战。OpenAI 不再只是把代码交给用户，然后让他们去其他地方完成运维工作。

不过，这种整合也把更多责任转移到了 OpenAI 的环境中。每次部署都属于生产环境部署，公开可用性仍然有限，而创建者需要为网站及访客数据承担法律责任。

因此，它提出的主张比“又一个 AI 网站生成器”更加鲜明。OpenAI 希望 ChatGPT 成为这样一个场所：用户在这里描述想法、完成构建、进行审核、发布上线、衡量表现并持续维护。

ChatGPT Sites 让想法在一次对话中变成可发布的网站

ChatGPT Sites 缩小了从生成 Web 项目到让其他人获得可用链接之间的差距。

用户可以先描述网站、目标受众、所需行为和源信息，也可以从一个已经包含代码的兼容本地项目开始。

ChatGPT 会创建预览，接受对话式编辑，并准备可部署版本。用户无需离开当前对话，就可以要求修改文案、样式、布局、表单、链接、计算逻辑或交互行为。

整个流程包含四个实际阶段：描述、审核、优化和分享。根据 Sites 文档，用户可以通过提及网站或明确引用 Sites 来调用这一工作流。

这听起来很简单，但最后一个阶段改变了产品类别。生成的结果不只是显示在临时预览中。ChatGPT 可以保存可部署版本，并通过 OpenAI 管理的托管服务发布它。

每次部署都会获得一个生产环境 URL。随后，用户可以选择受众，发布获批版本，并分发其链接。

OpenAI 的发布材料说明了这一点为何重要。重点展示的个人专注应用是一个小型产品，而不是静态演示。它代表了这样一类想法：往往会卡在交互式模型与公众可用应用之间。

Sites 也支持更传统的网站形式。OpenAI 将落地页、项目仪表盘、发布追踪器、引导页面、计算器、内部工具和游戏列为预期使用场景。

这些都是有明确目标的项目。OpenAI 并未将 Sites 定位为所有软件栈、开发团队或托管平台的通用替代品。

不过，它支持的基础能力已经超越了静态页面。项目可以使用持久化结构化数据、文件存储、访客身份验证，或连接到现有域名。

OpenAI 表示，D1 是用于持久化记录的关系型数据库。R2 则为图片、文档、音频、视频及其他上传文件提供对象存储。

创建者还可以添加 Sign in with ChatGPT。公开网站可以继续向未登录访客展示，同时在用户完成身份验证后提供个性化体验。

这让专注应用的示例更有意义。基础计时器可以是静态的，但要记住会话、保存用户资料和进度，就需要持久化状态与身份信息。

Sites 还可以在无需外部分析库的情况下记录流量。其仪表盘会报告独立访客数、页面浏览量及其随时间的变化，不过在发布时，Enterprise 所有的网站还无法使用这一分析视图。

因此，这一消息的范围比“通过提示词生成代码”更广。OpenAI 将多个独立服务打包成了一条从想法到受监控生产网站的对话式路径。

部署层才是 OpenAI 真正的产品动作

决定性功能并不是更出色的代码生成，而是从用户工作流中移除了部署协调工作。

在 Sites 出现之前，ChatGPT 用户可以要求生成 HTML、React 组件或完整应用。但要让这些成果上线，通常还需要另一个账户、代码仓库、部署配置和托管服务商。

创建者还需要连接环境变量、存储、身份验证、分析工具和域名。每一次交接都增加了配置错误或项目半途而废的可能性。

ChatGPT Sites 压缩了这些交接环节。OpenAI 的产品指南表示，Codex 可以在构建网站的同一工作区中完成创建和部署。

这一区别解释了 OpenAI 为何强调轻量级应用和内部工具。许多此类项目很有价值，但规模太小，不值得启动专门的工程周期。

产品经理可能只需要一个季度使用的发布追踪器。运营团队可能需要一个请求仪表盘。研究人员可能想为某项研究制作一个交互式演示。

这些项目往往停留在电子表格、幻灯片、共享文档或未完成的原型中。它们的问题并不总是软件能力不足，而是要制作并维护一个可用界面所需的额外成本太高。

Sites 将托管变成了编码代理可以直接执行的原生操作。创建者可以要求 ChatGPT 部署获批版本，并返回其 URL。

底层流程仍然区分已保存版本与部署版本。保存会创建一个可供审核的候选版本，而部署则会让该候选版本对配置的受众开放。

这种区分很重要，因为每次部署都会上线。希望进行私下审核的用户必须先保存版本，并避免部署。

版本管理也让 OpenAI 的生产工作流更具可信度。用户可以检查已保存的候选版本，发布选定版本，并在之后返回修改项目。

这不同于接受一段 AI 生成的代码，然后手动决定如何处理它。代理会在创建、修改、配置和托管之间持续保留上下文。

对于兼容的本地项目，系统会将源代码与其托管版本关联起来。它会在托管配置文件中记录这一关系，并将保存的版本与 Git 提交关联。

这条路径为对话式构建与传统源代码管理之间搭建了桥梁。开发者可以继续在本地编辑，同时使用 ChatGPT 管理部署。

不过，目前只有网页版或桌面版 ChatGPT 支持 Sites 的管理操作。Codex 命令行界面和 IDE 扩展可以编辑项目，但没有独立的 Sites 管理视图。

这一限制揭示了 OpenAI 的战略重心。Sites 旨在强化 ChatGPT 工作区，而不仅仅是给开发者终端增加一个部署命令。

同样的策略也体现在 OpenAI 最近对“完成工作”的强调上。ChatGPT 越来越被期待能够产出完成的交付成果，而不只是提供建议、草稿或零散代码。

发布一个可访问的实时网站，是检验这一方向的明确方式。人们可以打开、分享、衡量并评价一个链接，而他们从未参与最初的对话。

提示词构建工具与托管平台面临不同压力

ChatGPT Sites 将 AI 构建工具与部署平台的能力结合到了一款产品中，但并未完全取代其中任何一个类别。

Lovable、Replit 及类似产品的定位，都是将自然语言需求转化为功能性应用。它们帮助非开发者无需组建传统工具链，就能从想法走向可视化产品。

Vercel、Netlify 和 Cloudflare 则从另一个方向切入市场。它们为 Web 项目提供基础设施、部署工作流、域名、分析、存储和生产环境控制能力。

OpenAI 现在与这两类产品产生了重叠。Sites 既能生成体验，也能运行承载这一体验的环境。

这种重叠会立即带来分发压力。ChatGPT 已经是许多编程请求的起点，因此用户在测试想法之前，不再需要先去寻找独立的构建工具。

对于临时项目而言，这种优势尤其明显。创建专注应用、计算器、作品集或小型仪表盘的用户，可能更看重速度，而不是基础设施的灵活性。

ChatGPT 可以保留生成项目的对话。同一上下文可以指导视觉修改、行为更新、部署设置和后续迭代。

专门的 AI 构建工具仍然有差异化空间。它们可以提供专业的可视化编辑器、更深入的设计控制、集成协作功能、更丰富的模板，以及完全围绕应用创建展开的工作流。

对于要求更高的产品，传统托管平台在技术能力上仍然拥有更大优势。成熟团队需要广泛的可观测性、部署自动化、区域控制、框架支持和详细的基础设施配置。

OpenAI 也承认这一边界。其 Academy 指南将 Sites 描述为适合重点明确的页面和轻量级应用，同时建议复杂项目采用更大规模的工程方案。

一些框架、私有网络、数据库、后台服务和托管模式仍不受支持。兼容性取决于 Sites 的运行环境，以及每个账户启用的功能。

Sites 在测试阶段还设置了使用限制。达到限制后，用户可能无法创建新网站、增加存储空间，或让高流量项目继续保持公开。

这些限制使其初期竞争影响并不均衡。在市场中复杂度较低、便利性胜过基础设施选择的领域，Sites 构成的威胁最为明显。

更大的战略风险将在未来出现。如果 OpenAI 扩展运行环境、改进视觉控制并支持更多集成，轻量级项目就可能无需离开 ChatGPT 继续成长。

这可能减少流向独立构建工具和托管仪表盘的新用户数量。届时，竞争对手需要凭借控制能力、专业化或可移植性取胜，而不再只是提供基础的发布功能。

对于知识工作者而言，这一变化也在重新定义什么算作交付成果。一组结构化的研究或项目信息，可以变成交互式界面，而不再只是另一份静态文档。

使用可搜索的 AI 工作流的团队，可以将经过批准的成果转化为仪表盘或发布追踪器。网站将成为展示层，而不是原始知识来源。

这一点很重要，因为生成的界面是否可靠，取决于其底层信息是否及时更新。当源材料过时，即使仪表盘制作得很精美，也可能误导读者。

轻松发布的表象掩盖着严格限制

ChatGPT Sites 降低了部署摩擦，但并未消除产品所有权、安全审查或数据责任。

第一个限制涉及可用性。Sites 目前处于公开测试阶段，其访问权限取决于套餐、地区、推出状态和工作区设置。

OpenAI 的发布指南称，该功能在推出时不适用于 Free 和 Go 账户。在欧洲经济区、瑞士和英国也无法使用。

Enterprise 客户还面临额外控制。管理员可以决定是否启用 Sites、哪些角色可以创建项目，以及是否允许将内容公开发布。

Enterprise 工作区默认禁用公开发布。推出时，Enterprise 所有的站点也无法使用自定义域名和内置分析视图。

第二个限制涉及运行时范围。OpenAI 描述的是一个支持特定项目形态的托管环境，而不是任意基础设施。

创建者不应假设现有应用无需修改即可部署。ChatGPT 必须先确认项目能够生成兼容的构建产物。

第三个限制涉及实时信息。OpenAI Academy 的文章指出，Sites 目前无法直接连接实时数据源。

团队可以使用独立的自动化流程收集更新，并准备刷新后的版本。但这些更新仍需由人员审核，再重新部署站点。

这一流程可能适用于定期更新的项目仪表板，但不太适合需要持续同步、后台任务或时效性运营数据的应用。

第四个限制是发布风险。对话式工作流可能让部署看起来只是一个无关紧要的最后操作，即使这一操作会暴露文件、表单、链接、生成文本和身份验证行为。

OpenAI 要求创建者在分享站点前，从访客视角进行测试。他们还必须核实受众范围、移除机密信息，并检查任何会收集个人数据的功能。

这种担忧并非理论上的。提示词可能包含对话历史、上传文件、引用材料、生成产物、访问设置、托管 URL 和运营元数据。

如果这些上下文信息被意外带入公开站点，集成式发布的便利就会变成负担。用户必须了解哪些信息从对话转移到了已部署的体验中。

OpenAI 建议选择能够满足项目需求的最小受众范围。新站点最初仅限所有者和工作区管理员访问，直到相关权限发生变化。

可用设置可能包括指定用户、工作区成员或互联网上的任何人。共享权限允许访客查看站点，但不会授予编辑权限。

OpenAI 能够托管站点，也不意味着公司已经审查或认可该站点。创建者仍需对功能、访客内容、身份验证、法律合规和支持承诺负责。

这种易于创建与持续责任之间的落差，正是该产品的核心权衡。Sites 让软件发布变得触手可及，同时保留了运行软件所附带的责任。

一个在线站点仍需要明确的责任人

OpenAI 提供运行环境，但创建者仍需对站点收集、声称和暴露的内容负责。

ChatGPT Sites 条款规定，创建者保留其提交的网站内容所享有的既有所有权，同时授予 OpenAI 托管和运营这些内容所必需的许可。

OpenAI 可以显示该网站由 ChatGPT 提供支持的归属声明。但创建者不得暗示 OpenAI 已认证、支持或认可其特定站点。

条款将访客提交内容的责任交由创建者承担。其中包括通过站点收集的文本、图像、上传材料、登录信息和其他个人数据。

当站点收集个人信息时，其创建者将作为数据控制者。因此，创建者必须履行适用的隐私义务，包括有关透明度和同意的要求。

Sites 不能处理受保护的健康信息，也不能直接处理支付卡数据。不过，在满足特定条件的情况下，创建者可以接入第三方支付服务商。

电子商务会带来更多责任。创建者需要管理履约、退款、客户支持、税务，以及任何外部支付服务的配置。

这些规则划定了生成式原型与真实服务之间的边界。一旦访客能够提交信息或进行交易，该项目就会产生运营和法律层面的后果。

身份验证同样需要仔细审查。Sign in with ChatGPT 可以让身份感知型功能更容易构建，但它不能替代应用层授权。

Sites 会将经过身份验证的电子邮件和个人资料信息转发至服务器。OpenAI 明确要求创建者将授权决策保留在服务器端代码中。

这意味着，要求加入登录功能的提示词并不是完整的安全设计。创建者必须决定每位访客可以访问哪些记录，并测试这些边界是否确实有效。

机密信息也需要另一套审慎流程。托管环境变量应通过站点设置进行配置，而不应放入提示词、附件、项目内容或托管清单中。

修改环境变量后，创建者必须重新部署已批准的保存版本。否则，生产环境中的部署可能会继续使用早期配置。

出于安全或政策原因，OpenAI 也可以限制或移除站点。创建者可以取消发布自己的作品、限制其受众，或将其永久删除。

删除操作不可逆。如果当前目标只是移除公开访问权限，修改访问设置是破坏性更低的选择。

这些细节让“任何人都能把想法变成成品”的说法变得更加复杂。ChatGPT Sites 可以生成已部署的产物，但负责任的所有者仍必须对其进行管理。

组织需要根据每个站点的风险制定相应的审查标准。一个公开的专注计时器，不需要与包含员工信息的内部仪表板遵循同样的流程。

团队应明确谁负责批准发布、谁负责审查生成的代码、谁负责核查来源权利，以及当访客数据或功能出现问题时由谁响应。

缺乏这种所有权管理，Sites 可能会加剧一种常见的软件蔓延。员工可以快速创建有用工具，而管理员却难以识别哪些工具仍在使用，哪些工具值得信任。

三个信号将显示 ChatGPT Sites 能否走出测试阶段

下一阶段取决于采用情况、运行时扩展，以及组织能否管理不断增长的对话式创建软件清单。

第一个信号是可衡量的演示之外的实际使用。OpenAI 需要证明，人们会持续访问已部署的站点、更新它们，并将其分享给稳定的受众。

内置分析功能为个人创建者提供了一个起点。独立访客数和页面浏览量可以揭示，一个生成式体验在发布帖文失去关注后是否仍能持续存在。

使用情况比创建的站点数量更重要。大量被弃置的落地页只能证明人们有实验需求，而不能证明他们需要持久运行的应用。

重复部署也是一项有价值的指标。如果创建者会保存并发布修订后的版本，就说明 Sites 支持的是持续工作流，而不是一次性的新鲜体验。

第二个信号是支持运行时的扩展。直接连接实时数据、更广泛的框架兼容性、更强的后台处理能力，以及更多基础设施控制，都将扩大其潜在市场。

但每项新增能力也会提高风险和复杂度。OpenAI 必须在扩展功能的同时，避免让对话式产品变成另一个配置繁琐的云控制台。

Enterprise 支持尤其值得关注。自定义域名、分析功能、数据驻留选项和更强的治理能力，将提升 Sites 在企业部署中的可信度。

在推出时，Sites 不支持数据驻留和推理驻留。这一限制适用于已部署代码、存储数据、产物和日志。

无论 Sites 多么便利，这一差距都可能阻止部分受监管组织考虑使用它。支持区域控制将强化 OpenAI 的商业论据。

第三个信号是竞争对手的反应。基于提示词的构建工具可能会强调设计深度、导出选项、协作能力，或摆脱对单一模型提供商的依赖。

托管公司可以让 AI 生成的部署更加便捷，同时保留基础设施的可迁移性。它们还可以提供更成熟的可观测性、安全性和扩展控制。

OpenAI 最强的优势仍然是分发能力。用户已经在使用 ChatGPT 开发想法、编写规格、制作素材和生成代码。

Sites 让对话得以持续，直到这些材料变成一个在线体验。这种连续性很难由一组相互独立的产品复现。

而它的弱点也正是这种集成。用户必须接受 OpenAI 的运行时边界、测试阶段限制、治理模式和托管关系。

ChatGPT Sites 能将想法转化为可发布的网站，但长期竞争的关键在于发布之后会发生什么。可靠运行、负责任的数据处理和持续使用，将决定这些站点能否成长为真正的产品。

目前，创建者应使用一个受众明确、风险较低的聚焦项目来测试 Sites。仔细审查每项生成的行为，在部署前保存一个版本，并以外部访客的身份检查最终结果。

然后问一个比“ChatGPT 能否发布它”更重要的问题：当数据发生变化、受众不断扩大，或第一次安全决策出现失误时，谁来维护这个站点？