北京
出品 | 网易智能
作者 | 小爪
编辑 | 王凤枝
AI做完一份项目报告后，工作往往还没有结束。
负责人要把任务搬进表格，把风险项贴到群里，再做一张进度看板。市场团队关心发布时间，销售团队只想知道哪些客户会受影响，管理者则不断追问哪一项延期了。几天以后，报告、表格和群消息各自更新了一轮，团队又开始确认：哪一份才是最新版？
生成式AI已经越来越擅长整理信息、写报告、制作表格和演示文稿，但从"内容生成"到"团队继续工作"，中间仍有一轮人工搬运。 OpenAI现在开始尝试缩短这段距离。
7月9日，OpenAI将ChatGPT Sites推向公开测试。用户可以在ChatGPT Work网页版，或ChatGPT桌面应用的Work、Codex模式中描述需求，加入文件、数据和限制条件，让ChatGPT生成一个可以预览、修改并发布的网址。
Sites对准的正是生成之后的交付环节。它没有让人更快地搬运内容，而是直接换了一种交付方式。ChatGPT不再只给出一份需要继续转抄的文件，而是生成一个团队可以打开、操作和更新的页面。
这让Sites看起来像AI建站，落点却更接近办公交付。过去ChatGPT交出答案、表格或演示文稿，现在它开始尝试交出一个团队可以继续使用的工作入口。
让人用得起来的，是生成之后那半程
用AI生成网页并不新鲜，Sites真正补上的，是生成之后那串容易把普通用户挡在门外的动作。
用户先说明页面给谁使用、要完成哪些任务、需要保存什么信息，ChatGPT生成第一个版本。页面出来后，不必直接修改代码，仍然可以用自然语言调整文字、布局、链接、表单和交互方式。
制作完成也不等于立刻公开，Sites把发布拆成保存版本和正式部署两步。先生成一个可检查的版本，确认内容和功能后，再部署到生产网址。以后继续修改，也可以保存新版本，不必每次从头生成。
如果页面需要长期保存请求记录、用户进度或游戏分数，OpenAI的开发文档允许使用平台提供的关系型数据库，也就是开发文档中称为D1的数据库；图片、文档、音频和视频等文件，可以放进专门的文件存储服务R2。内部页面可以调用当前组织的用户身份，公开页面也可以加入登录功能。发布时，创建者还可以把访问范围限制在自己和管理员、指定成员、整个组织，或在管理员允许时开放到互联网。
Sites把页面生成、修改、版本保存、部署和访问权限放进同一条对话式流程，在受支持的运行环境中还可使用数据库、文件存储和组织访问控制。 不会写代码的人可以从一段业务需求开始生成页面；已有项目的开发者，也可以先检查框架和功能是否兼容，再决定是否部署。
不过，D1、R2和身份能力目前只在Sites支持的运行环境内可用。它还不能直接对接企业内网、私有数据库或任意后台服务。OpenAI在公测文档中也列出了部分尚未支持的框架和托管方式。
效果如何？先看一张项目请求看板
拿项目请求看板来说，成员可以提交请求，页面也能按负责人或状态展示和筛选记录。如果将这些记录写入D1，用户下次打开页面时，仍能读取此前保存的信息。
提交、筛选和保存记录本身都不是新功能，Sites带来的变化是用户可以从一段业务需求出发，在同一条对话中生成这些功能，并直接得到一个可以访问的网址。 原本需要先整理需求、搭建页面、配置数据和部署上线的过程，被压缩到了ChatGPT里。
这个页面也可以成为不同角色寻找信息的共同入口。管理者打开后先看延期事项，市场团队筛选临近的发布时间，销售团队查找会影响客户的变化。过去，这些答案可能分别藏在周报、表格和群消息里；现在，创建者可以把表单、筛选条件和状态信息放在同一个页面中，让不同成员按自己的需要查找。
Sites在这里缩短的是交付路径。同一批信息不必再被反复整理成报告、表格和看板，团队也少了一轮寻找最新版的过程。页面仍是同一个，不同角色打开后获取的答案可以不同。
不过，从对话生成一个可操作页面，还不等于建立了一套成熟的多人协作系统。
最先被它接住的，是"小到不值得立项"的工具
Sites最清楚的使用边界，反而来自OpenAI自己列出的例子，比如发布追踪页、每周复盘看板、方案计算器、新人入职页。这些工具通常只服务一个团队、一项项目或一段重复流程。
它们用文档承载时不够好用，交给工程团队开发又显得太重。 一个发布追踪页需要里程碑、负责人、链接和风险；一张入职页面要把制度、联系人和第一周任务放在同一个地方。需求很具体，但未必值得单独排期、搭后台、做权限，再长期维护。
Sites试图占据的正是这块中间地带。用户把已有文件、数据和要求交给ChatGPT，让它先搭出可用版本；需要变化时继续对话修改，检查后重新部署。它比文档多了操作能力，又把正式软件项目里的许多准备动作藏到了对话后面。
这也是Sites与ChatGPT Work同时出现的意义。Work可以交付文档、表格、演示文稿和页面；Sites给这些内容加上按钮、筛选器、表单和状态保存，让AI的工作成果成为下一步操作发生的地方。
公测阶段，Sites还不是成熟的多人协作系统
访问者可以填写表单、筛选信息，或使用页面已有的功能，但分享页面并不会同时授予站点编辑权。页面的结构和功能仍由创建者回到ChatGPT中修改，保存新版本后再重新部署。
Sites已经提供身份识别和访问范围设置，但OpenAI没有承诺它具备飞书多维表格那样的实时协同、细粒度角色视图和复杂自动化。 对团队来说，它更像一个共同使用的页面，还不是所有成员都能同时参与编辑和配置的工作空间。
数据更新也有明显限制，Sites目前不能直接连接实时数据源。项目数据持续变化时，OpenAI建议另建自动任务定期收集信息，再由用户审核并刷新页面。它可以展示更新后的结果，却还不能持续同步业务系统。至于页面中的数据能否方便地导出和迁移，现有官方说明没有给出足够信息。
以上是产品当前的设计边界。公测阶段还有一些可能随版本更新变化的限制。
首先是配额和稳定性，目前同样没有形成固定承诺。不同套餐的创建与存储额度可能调整；达到上限后，用户可能无法继续新建Site、增加存储，或让高使用量页面保持公开运行。7月13日，OpenAI状态页曾记录ChatGPT创建Sites时错误率升高，从调查到恢复持续约80分钟。一次已经解决的故障不能代表长期表现，但关键流程仍需要保留原始数据和备用入口。
其次，OpenAI同时列出了几项明确限制。Sites上线时不支持数据驻留和推理驻留，不能处理医疗健康信息或支付卡数据，也不能用于金融交易。涉及企业内网、长期后台任务、复杂权限和高级基础设施的项目，现阶段仍需要正式工程系统。
这些限制加在一起，划出了Sites目前的位置：小型内部工具、阶段性项目页面、轻量交互交付。 要它接管关键业务系统的数据同步、多人协作和长期运行责任，还太早。
它与Claude Artifacts，不只是存储能力的差异
如果只把ChatGPT Sites理解为"增加了存储和后台能力的Claude Artifacts"，已经很难准确概括两款产品当下的差别。截至7月15日，Anthropic的帮助文档显示，已发布的Artifact同样支持持久存储，也可以通过MCP连接Asana、谷歌日历和Slack等外部服务。不过，它的持久存储目前只接受文本数据，单个Artifact的存储上限为20MB。
Sites更鲜明的特点，是直接嵌入ChatGPT Work的任务流程，用户可以从对话和工作材料出发生成页面，再完成修改、版本保存和部署。 在受支持的运行环境中，还可使用D1、R2和组织访问控制。它与Claude Artifacts、传统无代码工具都在向轻量应用靠近，区别主要落在从哪里开始、哪些能力默认可用，以及产品允许用户走到哪一步。
这些差别最终不能只靠功能清单判断。第一次生成一个漂亮页面已经不算难，Sites是否真的进入团队工作，要看项目第二次、第五次甚至第二十次更新时，成员是否仍愿意回到同一个网址继续操作，而不是重新把信息搬回文档、表格和群聊。
下一次更新项目时，团队会回到哪里
ChatGPT Sites给出的方案，是把AI的交付终点从答案和文件向前推一步。用户提出需求，AI生成页面；页面在受支持的范围内保存数据、识别访问者，再通过网址交给团队使用。
如果下一次项目进度变化时，成员直接回到这个页面查看和提交信息，Sites就进入了日常协作。 如果大家仍然回群聊寻找最新表格，它就只是继文档、表格和演示文稿之后，ChatGPT新增的另一种输出形态。
