Codex Sites 不是又一个 Lovable - 它让应用自己把自己运营下去

Greg Isenberg 在他的 The Startup Ideas Podcast 里聊了一个我一直在等的东西：Codex Sites。OpenAI 把它悄悄上线了，没怎么宣传，Greg 一开始也以为只是「又一个长得笨笨的 Replit 克隆」。结果他六个 prompt 之后，手里多了一个会自己更新的创业点子看板。

这篇我想顺着 Greg 的思路，聊聊 Codex Sites 到底带来什么不同 - 哪些事真的变了，哪些事其实没变。它不是一个「再做一个网站」的工具，Greg 看到的、也是我读完最有共鸣的一点，是它把「应用」这件事从「你做出来的一个作品」推向了「一个 agent 替你持续运营的东西」。期望对大家有所帮助。

Greg 的起点：网站是「活的」

Greg 以前开过一家做网页设计的公司。他说那时候对客户反复念叨同一句话：网站是个有生命、会呼吸的东西。你上线它，之后每周都得照看。

他拿自己的站举例。15.8 万人订阅他的 newsletter，这个数字爬到 16 万的时候，他得自己打开文件，手动把数字改过来。一个再小不过的维护动作，但它每周都在发生，永远不会自己消失。

In 2026, an agent can carry that for me.

这句是整段的钥匙。不是「agent 帮我把网站做出来」 - 那件事 Replit 和 Lovable 早就能做了 - 而是「agent 替我把网站一直照看下去」。前者是一次性的创造，后者是长期的运营。Greg 真正兴奋的是后者。

真正的不同，不在功能，在你住在哪里

Greg 把 Codex Sites 和 Replit、Lovable 的区别讲得很干脆，我觉得这是整段最值得划线的地方。

Replit 和 Lovable 把所有东西塞进一个盒子里：编辑器、数据库、服务器、托管、连域名都给你配好。你输一句 prompt，转身就能走，特别适合「我只想说一句话然后什么都不管」的场景。

Codex Sites 反过来，它对你的要求更高。它假设你本来就住在 Codex 里，把你的上下文留在那儿。作为交换，它做了一件别的工具不做的事：

It keeps building the app on its own.

它会自己接着把这个应用建下去。这就是分界线。Replit、Lovable 给你的是一个建好就交付的成品；Codex Sites 给你的是一个一直停在 Codex 上下文里、可以被反复指挥的活物。区别不在谁的功能更全，而在你愿不愿意把「常驻在 Codex 里」当成前提 - 你住进去，它才替你运营。

六个 prompt 里藏着的设计

Greg 给自己定的目标是一个真的会用的内部工具：一块有五列的实时看板 - 收件箱、调研中、验证中、在建、已砍 - 每张卡片记一个点子、买家是谁、痛点、证据、下一步、还有一个评分。他用六个 prompt 把它搭了出来。我不想把这六步当教程抄一遍，但里面有几个设计，恰恰解释了上一节那句「自己接着建下去」是怎么落地的。

第一步搭壳的时候，他在 prompt 末尾加了一句会改变一切的话：save for review, do not deploy。 Greg 的原话是，放着不管，Codex 会急着上线；就这一行字，把活儿摁在「产品模式」里，而不是「发布模式」里。这是个很小但很重要的习惯 - agent 默认想交付，你得主动告诉它先别急。

第二步加记忆。 Codex Sites 每次访问都从零开始，所以得让点子在多次访问之间存得下来。Greg 的小技巧是：先让它把数据模型给你看，再写代码。Codex 回来告诉他用 Cloudflare D1 存，一种记录类型叫 ideas，一组干净的动作 - 列出、新增、更新、移动、评分、归档。有了记忆，一个 demo 才变成真软件。

第三步是最容易被忽略、却最关键的一步：safe actions。 一个 safe action 就是一个被批准过的按钮。agent 只能调用 add idea、update idea 这种事先命名好的动作，且只能调这些。它的意义在于：Greg 可以坐在任何一个 Codex 对话里，随口冒一个创业点子，说一句 add idea，这个点子就通过这条唯一被批准的通道，落到那块实时看板上。

第四步把这套能力固化成一个 skill - 一个叫 Startup Ideas Admin 的可复用手册，教之后的对话怎么读这块看板、怎么加点子、怎么挪卡、怎么评分。skill 是说明书，safe actions 是它后面真正能开火的那些动作。两者一配，能力就不再绑死在某一次对话里。

第五步设一个存档点：save this as V1 review, do not deploy。 Codex 没有电子游戏里那种自动存档，所以你得自己埋 checkpoint，给自己留一个「已知能跑」的回退点。

第六步验证整个回路。 Greg 开了一个全新的对话，说「用 Startup Ideas Admin 加一个点子」。Codex 起了个新线程，加载 skill，读了看板，只通过那条被批准的通道把卡片加了进去。然后他让它发布 - 它部署上线、加了个注册页，那块看板就活生生地摆在那儿了，五列一列不差，完全照着规格。

把这六步串起来看，它其实在回答一个问题：怎么让一个应用，在你不打开编辑器、甚至不在它面前的时候，依然能被安全地继续改下去。记忆让它有状态，safe actions 给它一条唯一可信的写入路径，skill 让任何一次新对话都能接手。这三样凑齐，「agent 自己接着建」才不是一句空话。

我看到的变化：应用从「作品」变成「被运营的东西」

读完我最大的感受是，Codex Sites 动的不是「怎么把应用做出来」这一步，而是「应用做出来之后，谁来管它」这一步。

过去这一两年，vibe coding 解决的是创造的门槛 - 一句话生成一个应用，人人都能做出来。但做出来之后呢？那个每周改一次订阅数字的活儿，那个上线后每周都要照看的活儿，从来没人替你扛。Replit、Lovable 把「从 0 到 1」压到了几分钟，可「从 1 到一直活着」还是落在你自己肩上。

Codex Sites 想接的正是这后半段。有两个变化我觉得是真的：

一个是交互面变了。你不再打开编辑器去改应用，而是在任何一个对话里，用一句被批准过的指令去操作它。应用的入口从 IDE 挪到了 chat。Greg 那个「坐在任何 Codex 对话里说一句 add idea」的细节，看着小，其实是把「维护应用」这件事从一个需要正襟危坐的任务，变成了一句随口的话。

另一个是应用的身份变了。它不再是一个你交付完就定格的作品，而是一个 agent 持续替你运营的东西。Greg 说大多数人会拿 Codex Sites 做个人主页和小工具，但真正的赢面在再往前一步 - 那些 Codex 替你一直运营下去的产品。Build once, let the agent run it。

但有些事没变，这点我想说清楚，免得读起来像在吹。规格还是你定的，数据模型还是你拍板的，哪些动作可以被批准成 safe action 还是你划的线。Greg 那句「先让它把数据模型给我看，再写代码」，恰恰说明判断力没有被让渡出去 - 被自动化掉的是每周改数字这种重复劳动，不是「这个应用该长什么样」这种判断。agent 接走的是维护的苦力，不是品味。

还差的那部分

Greg 自己也没把话说满，这点我挺欣赏。Codex Sites 是刻意做得很轻的：数据库、认证、支付、邮件、分析、密钥管理，全得你自己带 - 很多人现在拿它配 Convex 用。

而且今天它产出的还是内部应用，分享给团队用的那种。上线地址看着乱糟糟，自定义域名还在路上。想要少折腾的一站式，那还是去 Replit、Lovable；想要一个能自己运营自己的应用，才留在 Codex Sites。

Greg 还埋了一个我觉得被低估的点：打开插件面板，Figma、Canva、HeyGen、Remotion、FAL、Hugging Face 一开始就在那儿。最不起眼的那个叫 Game Studio - 围绕你的产品做一个小而好玩的游戏，攒点热度，再把这些玩家导回你的核心应用。对消费级产品，这招也许比想象中好使。

所以这东西今天还远没到能替代谁的程度。但 Greg 那句收尾我一直记着 - 大多数人只会拿它做个人页面和小应用，真正的奖赏在更靠后一点的地方：build once, let the agent run it。那一步，确实有点 2026 该有的样子。

---

• Greg Isenberg 的播客原帖：The Startup Ideas Podcast on X