只用一周的软件,也值得造:OpenAI 团队的 Sites 用法

为了看懂一次出差的安排，你会专门做一个网站，用完就扔吗？

OpenAI 的产品负责人 Kath Korevec 会。在 10 月 5 日发布的《How I AI》中，她告诉主持人 Claire Vo：自己有时只想换一种方式看日历，就为那一周做一个 Site，结束后便不再使用。

这个细节，比“AI 又能生成一个漂亮网页”更值得创业者留意。过去，定制软件要证明长期回报，才值得启动。现在，一段短暂、具体的工作，也可能值得拥有自己的工具。

这场 DevDay 现场对谈，展示了 ChatGPT Sites 从内部工具到个人项目的多种用法。沿着这些例子看下去，一个问题逐渐清晰：当软件越来越容易被做出来，什么才是用户真正需要的？

01 先解决“别再问一遍”的小问题

Kath 展示的第一个例子，是团队的事故信息看板。

作为产品经理，她经常在会议之间切换。团队处理故障时，她想了解进展，又不希望反复追问工程师，打断他们解决问题。

于是，她把 Slack、Notion 和日历等信息接进一个界面，整理事件时间线、参与处理的同事，以及相关操作手册。需要进一步确认时，再回到原始文档。

这里有一个必须保留的前提：她明确说，现场展示的是为演示重建的内容，不能把屏幕上的事故当成 OpenAI 的真实事件。

但这个需求本身很真实。团队已经有消息、文档和日程，缺的是一个符合当前角色的信息入口。产品经理关心进展和影响，处理故障的人关心具体步骤，两者不必使用完全相同的阅读方式。

对创业团队来说，这提供了一个更容易验证的起点：找到一个大家总在问、答案却散落在几个地方的问题，先让一个小工具把它讲清楚。

02 同一个界面，每个人带来自己的权限

对谈中更关键的变化，是 Sites 可以使用访问者自己连接的应用。

按 Kath 的解释，同一个事故看板分享给不同团队后，可以依据各自可访问的数据，呈现不同内容。共享的是工具，访问者仍然使用自己的连接和权限。

Sites 本身还承担部署，并提供数据库、文件存储等能力；官方文档也说明，它可以托管 MCP 服务，将工具提供给 ChatGPT 使用。这些能力让作品有机会继续长成可用的应用，但仍有使用范围、权限和资源限制。

这让“做一个团队工具”的成本结构开始变化。过去，要把几个业务系统接进应用，开发者往往需要处理接口、身份认证和部署。平台如果承担更多通用工作，小团队就能把精力放在信息如何组织、哪些提醒有用、用户怎样完成下一步。

不过，权限不能被“自动接好”四个字带过。按 OpenAI 当前官方说明，Sites 中的应用连接有工作区、管理员设置和访问者授权等条件，主要适用于受支持的 Business、Enterprise 工作区内的私有站点；不能理解为把网站公开，任何人就能读取公司的资料。

一个看板是否值得投入使用，仍要检查：数据从哪里来，谁能看到什么，连接失败时会显示什么，结论能否回到原始记录核对。

03 软件的寿命，可以和任务一样短

最有启发性的例子，反而是那个只用一周的日历界面。

一款通用产品必须照顾很多人的习惯。某次出差、一个活动、一个临时项目，却常常有特殊的信息排列方式。以往，人们会用表格凑合，或者在几个应用之间来回切换。

如果制作和部署成本足够低，就可以直接做一个贴合任务的小界面。任务结束，它的价值也已经兑现，不必强行变成一套长期系统。

Kath 的音乐项目体现了同样的思路。她希望跳出家庭成员影响后的推荐结果，于是让工具参考 Reddit 上的音乐分享，每周整理新的播放列表。

但这个例子也有清楚的运行条件：她说明其中用到了电脑操作，需要笔记本保持打开并运行。它不能被包装成一个天然全天候、完全无人维护的云服务。

这也是判断 AI 产品机会时容易漏掉的一步：演示能完成一次任务，和用户每天都能稳定使用，中间还有运行环境、失败处理与维护成本。

04 把“怎么扩展”也做成产品

对谈里还有一个有意思的游戏实验：Kath 希望大家为同一个地牢游戏制作不同房间。

她把房间尺寸、角色和操作规则写进一个 skill，让别人可以在这些约束内，用自然语言描述想做的场景，再由 Codex 帮助构建。

当时，她谈到的社区分享和拼接房间仍包含后续设想，不能写成已经成熟运行的平台。但这个方向值得借鉴：产品除了提供功能，还可以提供一套让用户安全扩展它的规则。

对垂直领域的创业者而言，价值可能藏在这些规则里：什么输入是合格的，生成结果必须满足哪些约束，哪些修改可以自动完成，哪些需要人确认。

同时也要分清实验与承诺。节目中，将模型推理进一步带进 Sites 的交互仍在探索；Kath 提到的访问分析也比较轻量。愿景可以启发产品设计，不能直接充当今天的能力清单。

05 越容易生成，越要认真验收

对谈接近结尾时，Kath 提出了一条非常个人、也非常实际的边界：她会用 AI 做研究和辅助写作，但不喜欢它擅自以自己的名义给别人发消息。

这提醒我们，功能做出来之后，真正需要设计的还有授权边界。读取资料、整理建议、替人发送消息，是风险不同的动作。

如果想从这场对谈里带走一个可执行的方法，可以从一个低风险的小任务开始：选定明确使用者，接入最少的数据，约定需要节省哪一步，然后连续观察几次真实使用。

用户还要不要回到群里追问？资料过期时能不能发现？工具坏了，谁来处理？这些答案，比首页生成得多快更能说明产品价值。

当一个只用一周的软件也值得被创造，创业者可以重新审视那些过去“小到不值得开发”的需求。把具体的人、具体的工作和清楚的边界放在一起，才更有机会做出真正被留下来的工具。

我是 AI萤火研究苑，带你看最前沿的 AI 信息。

来源

原节目：How I AI｜How OpenAI uses ChatGPT Sites (live at DevDay!)｜Kath Korevec，2026 年 10 月 5 日发布。

YouTube 原视频：https://www.youtube.com/watch?v=kz5Cpomk3HA

节目原页：https://www.lennysnewsletter.com/p/how-openai-uses-chatgpt-sites-live

OpenAI 官方使用说明：https://help.openai.com/en/articles/20001339-creating-and-using-chatgpt-sites

OpenAI 官方工作区管理说明：https://help.openai.com/en/articles/20001338-managing-chatgpt-sites-for-your-workspace

OpenAI 数据与连接文档：https://learn.chatgpt.com/docs/sites/data-and-connections

OpenAI MCP 托管说明：https://help.openai.com/en/articles/20001547-hosting-a-plugin-with-chatgpt-sites

本文依据完整转写与公开来源整理；创业启示为作者分析，不构成对所有账号功能开放或产品效果的保证。