ChatGPT Sites 冲上 HN 热榜:提示词建站,到底是玩具还是生产力?
10 月 3 日,Sites in ChatGPT 以约 209 点赞、218 评论冲上 HN 前页。这不是发布,而是一场清算:提示词直达 URL,到底是玩具、原型托管,还是生产力?四个争论焦点、文档实锤的技术事实(D1/R2、登录、自定义域名),以及给 vibe coder 的三个判断。

2026 年 10 月 3 日,Hacker News 把"Sites in ChatGPT"顶到了前页高位——约 209 点赞、218 条评论。这不是一次新品发布:ChatGPT Sites 已经公测了好几个月。HN 真正做的,是逼问产品页面永远不回答的问题:这到底是个玩具、原型托管,还是生产力工具?
对 vibe coder 来说,这个问题比"新功能"重要得多。因为 Sites 代表了一种正在成型的交付形态:提示词直达可分享的 URL。理解它的边界,就是理解你下一批 vibe 作品的发布选项。
Sites 是什么:先对齐产品事实
按 OpenAI 开发者文档的定义,Sites 让 ChatGPT 可以创建、托管、迭代、分享网站、Web 应用和游戏,而不需要一套独立的部署流程。你在提示词里提到 website 或 @Sites,或者从一个兼容的本地项目开始,看预览、迭代、设受众、分享链接。入口在 ChatGPT 网页版的 More → Sites,或 chatgpt.com/sites。
发布分两个阶段,文档写得很坚持:先 Save a version(保存一个可部署版本),再 Deploy a version(发布它)。关键细节是:每个部署出去的 URL 都是生产部署——产品不给你单独的 staging 域名。想要先审后发,纪律在 save 这一步。这是 HN 上一半困惑的官方答案。
存储有两条线:D1(关系型,单站点上限 10 GB)存记录、分数、进度;R2(对象存储,无固定上限)存上传的图片音频文档。本地项目用 .openai/hosting.json 记录关联。公开站点可选"Sign in with ChatGPT",登录后通过请求头把用户邮箱传给你的后端——但 OpenAI 把话说得很直白:鉴权决策必须写在服务端代码里,合规责任是你的,平台不替你背。
争论一:小时级原型是甜点区
最高赞的评论们出奇一致:Sites 被低估的场景是"当天可玩"的小时级应用——演唱会后即兴做的 3D 迷宫游戏、官方站太烂自己做的音乐节日程表、给活动做的校园美食指南。这些东西的共同点不是"做得好",而是"从想法到可分享链接的摩擦,降到了比不做还低"。
这正是 vibe coding 今年的主线胜利:赢的从来不是"替代外包公司",而是让分享链接的成本低于沉默的成本。Sites 只是把这条曲线又往前推了一截。
争论二:原型 vs 生产,真正的分叉
评论区吵得最凶的是"Sites 能不能上生产"。两边其实都对,因为吵的是两个不同的问题。URL 语义上,deployed 就是 live;但 fit(适配度)是另一回事:不支持的框架、没有 raw TCP、beta 用量限额(超了可能建不了新站、公开高流量站可能被限)、没有数据 residency——这些都在说:当宕机的 blast radius 或数据合规要求不可接受时,别用 Sites。
一个实用的心智模型:
- 用 Sites:今天就要一个可分享的 URL;协作者在 ChatGPT/Codex 里一起迭代;D1/R2 + 登录能覆盖需求;受众是受邀用户、工作区或低风险公开访问。
- 别用 Sites:需要数据 residency 或受监管数据;需要不被支持的运行时或 raw TCP;处理支付或 PHI(医疗健康信息);接受不了
.chatgpt.site域名或 OpenAI 托管风险。
争论三:导出和自定义域名,是两个不同的出口
有评论盯着 *.chatgpt.site 问:这些站会不会哪天就没了?能不能导出到自己的域名?评论区给出了两个都对的答案:自定义域名(文档支持:把你自己的域名 DNS 指过去,访客不再看到 chatgpt.site 后缀,但运行时还是 OpenAI 的)和导出自托管(用户实测:有人把项目下载下来交给别的 Agent 或自己托管——但这不等于自定义域名,OpenAI 也没把"一键可移植导出"当作正式产品承诺)。
教训很实在:在积累用户之前先规划出口。要品牌,用自定义域名(注意 Enterprise 工作区首发不支持);要长期主义,把 Sites 当 mockup 阶段,代码成熟了就搬走。别假设"DNS 指过去了=源码可带走"。
争论四:官方展示品被 roast——"hosted polish 不是自动的"
HN 没放过 OpenAI 自己的 showcase。展示站 Tidal House 被批图片上的文字不可读,Below the Surface 被一眼认作"AI slop"。连 OpenAI 员工写的提示词,做出来的东西也需要人工过一遍对比度、文案和字体。
但这恰恰是最有用的结论:托管的精致感不是自动的。反例是 explainx.ai 之前报道过的那个音乐专辑站——一个具体真实的需求加反复迭代,效果远超" cinematic 落地页"式的大词提示词。vibe coder 早就懂这个道理:提示词决定下限,人工迭代决定上限。
Sites vs Claude Artifacts:一句话分清
评论区反复问"Sites 是不是带 URL 的 Artifacts"。按产品形态分:Sites 是持久化的托管输出——站点列表、save/deploy、数据分析、D1/R2、登录、自定义域名,目标是"明天同事点开链接还能用的应用";Artifacts 是对话内的临时画布——强在解释和迭代,弱在"给一个带存储和受众控制的可分享应用"。
交付物是"明天还有人打开的链接",选 Sites;交付物是"对话里的一次性交互解释",Artifacts 摩擦更小。两者都替代不了你需要 CI、多区域、自己掌控合规的完整生产前端。
给 vibe coder 的判断:Sites 是"发布按钮",不是"新品类"
把 Sites 放进更大的图景:它和 Codex 工作流是同一套东西——本地仓库、review 面板、save 再 deploy,Sites 是这个循环的"发布按钮",不是另一个产品品类。理解了这点,选型就清楚了。
我的三个判断:第一,把 Sites 当作 vibe 作品的"第一发布位"。想法验证期,摩擦最低的发布就是最好的发布;等用户和数据来了,再谈搬迁。第二,第一天就绑自定义域名(如果你有的话)。chatgpt.site 的链接适合一次性分享,不适合印在任何地方。第三,别在上面放你输不起的东西:支付、医疗健康、13 岁以下用户数据——OpenAI 的帮助中心有明确的禁用清单,出事时"不知道"不是借口。
HN 这 218 条评论,本质上是第一批认真用户在替所有人交学费:一个提示词就能发布的时代,稀缺的不再是"做出来",而是"分清什么该放上去、什么不该"。Sites 把发布的摩擦降到了零——而判断力,恰好是摩擦消失后唯一剩下的护城河。
实操:四条直接能抄的提示词模式
光讲道理不够,HN 帖子里沉淀了几条和文档对得上的实操模式,直接能用:
- 内部工具 + 身份:"给我的运营团队做一个项目需求看板,可以提交需求、指派负责人、更新状态、筛选列表。要求工作区登录,数据在访问之间保持。用 @Sites。"
- 公开站点 + 可选登录:"给这个公开站点加上 Sign in with ChatGPT。未登录也能用。登录后显示 Sign in / Sign out,登录后用姓名或邮箱打招呼。鉴权决策放在服务端。"
- 存储:"加上玩家分数和头像上传。分数存 D1,头像存 R2,访问之间持久化。"
- 发布纪律:"保存一个版本但不要部署。把版本详情给我看,等我批准再发布。"——这条对应"没有 staging"的官方解法:把纪律放在 save 这一步。
注意第二条里的分寸感:公开站保持"未登录可用",登录只是增值(存进度、个性化)。一上来就强制登录的 vibe 站,死得最快。
诚实局限清单(别在生产环境里学到)
- Beta 限额:撞到 plan 上限可能建不了新站、加不了存储、公开高流量站可能被限流;编辑已有站点通常不受影响。
- 运行时形状:HTTP/HTTPS/WebSocket 可以,raw TCP 不行;很多框架和后台常驻模式不支持。动手前先查文档的运行时说明。
- 没有 residency:站点代码、D1/R2 数据、artifacts、日志——数据驻留和推理驻留首发都不支持。这是硬红线,不是"以后会加"。
- 版本与协作:save/deploy 两阶段、URL 改名、co-editing、插件能力都在快速加东西——这是"没被砍的实验",不是"签了终身合同"。重要项目按"随时能搬走"来设计。
把这份清单和前面的心智模型放在一起,Sites 的定位就完整了:它是 vibe 作品从"能跑"到"有人用"之间最短的那座桥。桥的承重有限——别开卡车上去;但在验证想法这个阶段,它是全场最快的路。
最后:发布正在变成提示词的一部分
Sites 真正值得关注的不是功能列表,而是一个趋势:发布正在变成提示词的一部分。以前的工作流是"写代码→构建→部署→分享",四个阶段四种工具;Sites 把它压成"一句话→链接"。Vercel 把部署变成 git push,Sites 想把部署变成一句话。
这对 vibe 生态意味着:作品的生命周期会越来越短、数量越来越多,"做出来"不再是门槛。门槛会移到两件事上:一是判断力——什么值得做、什么该放上去;二是运营——有人用之后,你怎么迭代、怎么留住。Sites 解决了第一公里,剩下的九十九公里,还得你自己走。
所以回到 HN 那个问题:玩具还是生产力?答案是——它是玩具的生产力,也是生产力的玩具。拿它验证想法的,是生产力;拿它承载身家的,是玩具。分清这两者的人,在 2026 年 10 月的 HN 评论区里已经交了学费,你直接抄作业就行。
原始来源
相关文章

10 月 3 日,工程师 Kevin Liao 发表檄文冲上 HN 前页:记忆插件是一场 RAG 片段抽奖,Agent 需要的是文档工作区。本文拆解他的诊断、开源的 Operator Memory 插件、两个最强的反方质疑,以及今晚就能开始的最小实践。

Gergely Orosz 走访 OpenAI、Anthropic、Cursor、Ramp 后写下的 2026 行业现状:近 100% 代码由 AI 生成、Agent PR 八个月涨近 10 倍、code review 沦为表演、IDE 被判为遗产产品。本文提炼报告要点,并给出 vibe coder 的三个判断与四件本周可做的事。

2026 年 10 月 7 日,Google Developers 发布 Developer Knowledge API 生态:Google Cloud、Firebase、Android 等官方文档变成程序化事实来源,配 gcloud CLI 入口、官方 Agent Skill(一行安装)、MCP server 和多语言客户端库。为什么「文档 API 化」能连根拔掉 vibe coding「模型记错 API」的经典翻车。