用 Codex 从想法做到可运行 Web 应用

哈喽，我是小枫。今天聊一个我最近高频用 Codex 的场景：把一个模糊的产品想法，一步步推成一个真的能打开、能操作、能部署预览的 Web 应用。

Codex 搭页面确实快，几分钟出一个看着像样的界面很正常。但我在实际项目里踩过坑——页面「能打开」离「产品能用」中间还有不少路要走。下面我以一个活动报名工具为例，从问题定义一路走到预览部署，每一阶段都要求有真实的浏览器验证和工程验证。这个流程是我反复用了之后沉淀下来的，希望对你有用。

不会编程也能发起，验收能力才是关键

你不需要亲自写代码，完全可以靠自然语言描述清楚活动报名工具做什么、选哪个页面方向、看预览、测用户流程。Codex 负责把实现扛下来。但有两件事它替不了你：决定业务规则，以及判断什么数据能碰、什么环境能连。

如果你是普通用户（非开发者），先把范围控制在本地或受控预览里，别急着接真实支付、别群发邮件、别导入真实客户数据。碰到终端命令、数据库、域名、部署这些环节，找个技术同事帮忙复核，或者顺带学一点开发者路线的东西。核心原则就一条：「我不会写代码」不能等于跳过安全和测试。

开始之前，建议先翻翻这两篇铺垫：普通人的任务说明法 和 隐私、权限与审批，后面很多判断都建立在它们上面。

第一步：冻结第一个用户结果

我以前犯过的一个毛病：一上来就说「做一个活动平台」。然后 Codex 给我生成了一堆东西，结果发现我连核心流程都没想清楚。

现在我的习惯是，第一版只死磕一个用户结果：

组织者创建一个活动报名页，访客填写姓名和邮箱提交，组织者能看到报名列表并导出 CSV。

支付、社交、推荐、复杂权限、多语言、原生 App——统统放到后面再说。先让这一条路径跑通，后面的功能才有地基。

第二步：写产品和技术边界

别跳过这一步，我吃过亏。有一次没写边界，Codex 自由发挥引入了我项目里根本没打算用的状态库，后面合并得想哭。

我现在的做法是写一个 brief.md，把边界钉死：

- 用户：小型社区活动组织者
- 核心流程：创建活动 → 分享链接 → 报名 → 查看/导出
- 技术：React + TypeScript，沿用当前仓库方案
- 数据：开发期使用本地/测试数据库
- 安全：报名列表只有组织者可见
- 交付：可运行页面、测试、README、预览 URL
- 禁止：不连接生产支付，不发送真实邮件，不公开真实报名数据

这个文件就是你和 Codex 之间的「合同」，后面每次跑偏了都可以用它拉回来。

第三步：先做视觉方向

动手写代码之前，我建议先定视觉方向。可以用 ImageGen 或 Figma 出 2-3 个方向，但核心是先确定信息层级，别一上来就纠结颜色和圆角：

为活动报名页提出 3 个视觉方向，每个包含色彩、字体、布局、交互和适用场景。保持克制，优先表单可读性和移动端。先用低保真结构说明，不实现。

选定方向后写进设计约束。这样做的好处是：后面迭代时 Codex 不会每轮都重新风格化，省掉大量来回调样式的时间。

第四步：研究现有项目

这一步容易被忽略，但其实很值。先让 Codex 只读扫一遍仓库：

只读检查仓库的路由、组件库、样式 token、表单、数据访问、认证、测试和部署方式。找出最接近的已有实现，提出最小文件计划和需要确认的问题。

如果是个空项目，我的建议是选成熟的最小栈，别一口气加多个状态库、UI 库和后端框架。我曾经在一个空项目里同时引入了 Redux、Tailwind、Prisma 和 tRPC，结果光配环境就花了一下午，实际业务代码没写几行。

第五步：按垂直切片实现

这是我体验最好的策略——不做水平分层，做垂直切片。推荐的顺序：

1. 静态报名页和移动端布局；
2. 表单校验和本地提交；
3. 测试数据库写入；
4. 组织者列表与权限；
5. CSV 导出；
6. 错误、空状态和部署。

每个切片都要能单独打开和验证。举个例子，第一个切片的 prompt 可以这样写：

只实现切片 1：活动详情和报名表静态页面。复用项目组件和 token，支持 390px 与桌面。不要接数据库。运行前端测试和构建，并用浏览器检查目标路由。

这样做的好处是一个切片出问题了，你不会被后面还没做的功能干扰，定位快很多。

第六步：真实浏览器循环

页面截图像那么回事 ≠ 真的能用。用 Build Web Apps、Browser/Chrome 或 Playwright 能力：

启动开发服务器，打开目标路由。先检查控制台和网络错误，再按桌面与手机尺寸完成主流程。列出可复现问题，逐个最小修复。每次交互后检查页面状态，不只看截图。

我通常会额外测这些：键盘操作、表单校验边界、重复提交、loading 态、错误恢复、刷新后的状态、空状态和超长文本。这些场景 Codex 默认不太会主动覆盖，需要你刻意去点。

第七步：接入数据

数据接入先写 schema 和权限，顺序别反：

设计最小数据模型：Event、Registration、Organizer。说明主键、唯一约束、时间、删除和租户边界。先生成迁移与回滚计划，在测试数据库验证，不连接生产。

用 Supabase/Postgres 等 Plugin 的时候，权限策略要在服务端/数据库层验证，不能只靠前端隐藏按钮。这块我踩过坑——前端藏了管理入口，但接口没做鉴权，等于白藏。

第八步：处理外部服务

邮件、支付、分析这些外部服务，我的原则是分阶段接入：

• 先使用 sandbox/test mode；
• Key 通过环境变量；
• webhook 验证签名和幂等；
• 失败和重试有状态；
• 不发送真实邮件、不收真实付款；
• 在预览环境检查隐私和 Cookie。

Build Web Apps Plugin 里的 Stripe/Supabase 指导可以帮你跟上当前最佳实践，但业务金额、退款策略和权限逻辑还是要人审查，这个不能省。

第九步：部署预览而非直接生产

每次默认走 preview，别直接打生产：

准备预览部署。先检查环境变量清单、构建命令、静态资源路径和数据库目标。部署到 preview/staging，返回 URL 和验证清单。不要绑定正式域名，不连接生产数据库，不执行正式发布。

用 Vercel、Netlify、Render 或 Cloudflare Plugin 时，明确部署目标账号和项目；预览通过后再由人批准生产。这个习惯帮我挡过至少两次「凌晨上线发现炸了」的情况。

第十步：发布前门槛

预览跑通之后，上线之前，我会对着这个清单过一遍：

• 核心用户流程端到端通过；
• 手机和桌面通过；
• 认证、授权和数据隔离通过；
• 错误、日志和监控可用；
• 秘密扫描通过；
• 性能和可访问性无阻塞问题；
• 数据迁移和回滚演练；
• 隐私、条款和外部服务配置确认；
• 预览 URL 由真实用户试用。

缺任何一项，我都不会点发布。

我踩过的常见坑

一上来就生成完整 SaaS

刚开始用 Codex 的时候，我经常让它「帮我做一个活动管理平台」，结果它给我生成了用户系统、权限角色、Dashboard 图表……看着很爽，但核心报名流程反而没跑通。现在的做法就是前面说的：冻结一个用户结果，垂直切片推进。

页面漂亮但流程断裂

有过一次，报名页做得很好看，但提交按钮点了没反应，因为后端接口根本没接。后面学乖了：用真实浏览器从头走到尾——创建、提交、查看、导出——缺一步都不算完。

假权限

前端藏了按钮就以为安全了。后来养成习惯：在服务端和数据库层专门测越权访问，用另一个账号直接调接口。

自动部署到生产

这个最痛。有一次 preview 跑完顺手就部署了，结果测试数据库的脏数据跑到了线上。现在默认只做 preview，域名、数据库、支付和发布一律等人批。

完成门槛

• [ ] 第一版用户结果明确且范围受控。
• [ ] 复用现有项目模式。
• [ ] 每个切片有浏览器和工程验证。
• [ ] 权限在服务端测试。
• [ ] 外部服务只用测试模式。
• [ ] 预览部署可回退，未自动生产发布。

事实来源

• OpenAI：Get from idea to proof of concept
• OpenAI Prompting：Iterate on UI