Codex Sites做站入口新榜单：2025年新手建站必看

OpenAI 这次发布的 Sites，表面上看只是个建站工具，但背后隐藏的意图比想象中要大得多——它在把建站、部署内部工具、跑原型验证这套动作，整体搬进 Codex 任务流里。换句话说，以后你写代码、做原型、发布站点，可能不需要离开同一个对话窗口了。

01｜先看它到底发了什么

Sites 是 Codex 的一个 plugin，不是独立产品。装上之后，你可以在 Codex 里 create、sa ve、deploy、inspect 网站、Web 应用和游戏，OpenAI 负责托管和生成 URL。

用法很直接：给 prompt，出来一个 hosted site，有生产 URL，能访问，能分享给 workspace 成员。也支持把现有项目扔进来，让 @Sites 检查兼容性、做必要改动、给出部署地址。

当前是 preview 阶段，仅限 ChatGPT Business 和 Enterprise workspace。Business 默认开启；Enterprise 需要管理员手动在 RBAC 里授权。如果 Codex 里找不到 Sites，去 Plugins 手动添加，装完新开一个 thread 就能用。

官方文档建议写 prompt 时带三件事：audience（给谁用）、core UX（核心交互是什么）、required data or persistence needs（需要存什么数据）。这三个是把需求说清楚的最低门槛。特别提一句：有持久化数据或文件上传需求，要显式说明，Codex 不会擅自猜。

文档里给了几个典型 prompt 示范：给运营团队做项目请求看板，支持提交请求、查看负责人、更新状态、按条件过滤，并要求用 workspace 账号登录；把现有项目交给 @Sites 检查兼容性并给出部署 URL；游戏应用里需要持久化存储玩家分数和头像上传。这三类覆盖了从轻量内容展示到带状态应用的主要场景，代表了 Sites 当前能承接的典型需求。

02｜真正关键的，是 sa ve / deploy / permission

Sites 的机制里有一个细节值得单独说：每一次部署的 URL 都是生产部署（production deployment）。

注意，这里没有测试环境。想先 review 再上线，要明确让 Codex "sa ve a version"（不 deploy），看完再决定要不要发布。发布分两步：sa ve version 先把 build 做好并关联 Git commit；deploy version 才是真正上线。这个设计强迫你在部署前想清楚——这种改动到底该不该发出去。

官方文档还把站点区分成几种类型，对应不同的存储方案：纯内容或落地页不需要持久化状态；需要保存记录、用户进度或游戏分数的，用 D1 关系型数据库；图片、视频、文档等文件用 R2 对象存储；需要可搜索元数据的文件上传场景，D1 和 R2 同时用。D1 和 R2 都来自 Cloudflare 生态。这说明 Sites 的后端存储能力接在 Cloudflare Workers 体系上，而不是只停留在前端页面生成。对开发者来说，这个信号很关键：它已经开始处理数据持久化、文件存储和部署边界。

.openai/hosting.json 这个文件存放项目的 linkage 和 storage binding names。这个细节说明 Sites 在管理项目、版本、存储绑定之间的关系——它有版本管理逻辑，不是临时生成一个页面就完事的工具。

权限层面：Business 和 Enterprise 的分层，说明 OpenAI 在往企业内部工具场景上想。团队协作、审查流程、访问控制，这些在里面都有位置。

这些机制放在一起，比"用 AI 生成了一个网页"要重得多。它在管的是：谁能发、发什么版本、绑了什么数据。

03｜它为什么会让 Lovable/Replit 难受

Lovable 和 Replit 的逻辑是：你主动去它们的平台做东西。

Codex Sites 的逻辑是：你在 Codex 里做任务，顺手把结果部署出来。

入口位置不同，整个工作流的重心就不同。一旦"做站"变成任务流里的一个步骤，用户就不用切换工具——选题、写内容、做原型、发布，都在同一个 agent 任务里完成。

OpenAI 官方公告（2026-06-02）里提到，Codex 每周用户超过 500 万，非开发者占比约 20%，这部分用户的增速是开发者的 3 倍以上。Codex 从编程工具起步，正在向非编程工作流渗透。Sites 是这个方向上的一步——让非程序员也能在 Codex 里产出可以访问的、可以演示的东西。

第三方评测的观察值得看一眼。Masset 有一篇评测，标题直接写的是：

? 做出来没问题，23 分钟。但当前分享和公开访问有限制，官方也没给出完整的对外发布路径。

这个限制短期是障碍，长期看可能是保护期。Business/Enterprise 范围内跑通，再扩开放，Codex 已有的 5M 周活用户基数就是正面优势。Lovable/Replit 面对的是入口层面的压力——用户用 Codex 做东西，自然就用 Codex Sites 发东西，平台切换的动力就消失了。

04｜我会怎么用它

从官方文档来看，一个直观的判断是：特定场景现在就能上手。

适合的场景：

• 内部工具（团队内访问，不依赖公网开放）
• 活动页、临时运营页
• 数据看板、指标展示
• 产品原型，给团队或投资人演示用
• 可丢弃的小应用，验证完就撤

现在不适合的场景：

• 需要掌控域名的工具站
• 要接支付、登录体系、SEO、边缘部署的正式产品
• 长期维护、有成本结构要求的项目
• 需要公开访问、SEO 导流的出海内容站

做工具站，或者任何靠搜索流量的产品，Sites 现阶段解决不了。你仍然需要 PRD、选词、设计、研发、QA、真实域名、分析埋点、数据复盘这整套闭环。Sites 更像是把最早 20% 的"原型验证成本"压下来——把"从想法到能演示的东西"这段路缩短。

但这个 20% 本来就是卡人最多的地方。很多项目死在"还没做出来就放弃"这一步，如果 Sites 能把这段路从两天缩到两小时，这个价值是实的。

往后程序员真正的分水岭，可能是能不能把任务范围、上下文边界、验证标准、部署条件说清楚。说清楚了，Codex + Sites 做的事情就精准；说不清楚，出来的东西再快也是废的。

来源：互联网