Vibe Coding 零基础教程

我用 Vibe Coding 已经一年多了。公司项目里的产品都是通过这种方式完成的，我也构建了满足个人需求的 AI 产品，接下来还有更多新任务要尝试。

Vibe Coding 把编程的入口从语法和 API 前移到了需求与验证。零基础也可以开始，但仍然要判断需求有没有说清楚、结果是否正确、操作是否安全。AI 可以写代码，交付标准不能交给它猜。

这篇教程采用一条固定路线：在 ChatGPT 桌面客户端中使用 Codex，以 TypeScript 开发，先在本地验证，再通过 Git 管理代码，最后按需要部署到 Cloudflare Workers。后续教程也会沿用这条路线，减少工具切换带来的额外学习成本。

Vibe Coding 的基本工作方式

一次完整的 Vibe Coding 任务通常会经过四步：

用自然语言说明要解决的问题、功能边界和预期结果。
让 Codex 阅读当前项目，提出计划并修改代码。
运行程序、测试或构建命令，观察真实结果。
把结果与预期比较，继续修正，直到验证通过。

第三步决定了代码是否能够交付。代码看起来合理、Codex 说已经完成，都不能代替真实运行。页面能否打开、按钮能否点击、数据能否保存、测试能否通过，这些才是完成任务的证据。

为了让后面的步骤更具体，可以先假设要开发一个简单的待办工具。第一版只需要添加任务、显示任务和标记完成，暂时不做账号、联网同步、复杂样式和多端适配。等本地版本稳定后，再增加数据库和部署。

从 ChatGPT 桌面客户端中的 Codex 开始

零基础阶段主要推荐 ChatGPT 桌面客户端中的 Codex。它把对话、项目文件、代码修改、命令执行和结果检查放在同一个工作界面里，初学阶段不必同时学习多个 AI 编程产品。

模型和工具是两件事。模型决定理解、推理和生成代码的能力，Codex 则负责把这些能力用到真实项目中。截至 2026 年 7 月，GPT-5.6、Claude Fable 5 和 Gemini 3.5 Flash 都属于当前能力较强的模型。模型名称会持续更新，这篇教程不依赖某个固定版本，默认直接使用 Codex 提供的推荐模型。

Claude 和 Gemini 仍然可以作为替代工具，用来交叉检查需求、解释概念或对比方案，但没有必要在第一个项目里频繁切换。订阅从能使用 Codex 的入门档开始即可，等任务复杂度和使用频率提高后再考虑升级。

编程语言统一使用 TypeScript。Cloudflare Workers 对 TypeScript 提供一等支持，运行时 API 也有完整类型定义。类型检查可以提前发现一部分字段、参数和返回值错误，也能让 Codex 更准确地理解项目结构。

第一次开始前，只需要准备 ChatGPT 桌面客户端、Node.js 和 Git。GitHub Desktop 可以作为图形化的 Git 工具一起安装，VS Code、Cursor 和其他终端工具可以稍后再加入。

准备第一个项目时，可以按下面的顺序操作：

安装 ChatGPT 桌面客户端并登录账号。
新建一个空目录，例如 todo-app。
在 ChatGPT 中选择工作位置并打开这个目录。
选择 Codex，然后先检查本机开发环境。

第一条消息可以这样写：

这是一个新的空项目，计划使用 TypeScript 开发，并在后续部署到 Cloudflare Workers。我没有编程经验。
请先检查 Node.js、npm 和 Git 是否可用，说明检查结果和缺少的环境。现在不要创建项目或修改文件，等我确认后再继续。

环境检查通过后，再让 Codex 创建项目。把环境准备和功能开发分成两个任务，遇到错误时更容易判断是工具没有安装好，还是代码本身有问题。

先把需求说清楚

复杂产品也能通过 Vibe Coding 开发，但要把它拆成多个可以独立验证的模块。直接告诉 Codex「做一个完整产品」，它需要自行猜测用户、页面、数据、权限和完成标准，最后很容易得到一个看起来完整、实际无法使用的演示版本。

一份适合起步的产品需求文档至少要回答这些问题：

产品解决什么问题，谁会使用；
用户从进入产品到完成目标要经过哪些步骤；
需要接收什么输入，产生什么输出；
第一版必须有哪些功能；
哪些功能明确不做；
每个功能怎样才算验证通过。

可以这样告诉 Codex：

我想开发一个产品，目前只有初步想法。我没有编程经验，请先向我确认缺失的信息，再把需求整理成一份产品需求文档。
文档需要包括目标用户、核心流程、功能清单、数据需求、第一版不做的内容，以及每个功能的验收方法。技术路线优先采用 TypeScript，并考虑后续部署到 Cloudflare Workers。
[逐条列出希望实现的功能和业务逻辑]

文档完成后，可以把它保存为项目里的 requirements.md。后续对话直接引用这份文件，Codex 就能从同一份需求继续工作。需求发生变化时先修改文档，再改代码，避免文档和实现逐渐分离。

还可以让 Codex 评估第一版的复杂度、外部依赖和风险。如果第一版已经需要登录、支付、实时通信、多个外部 API 和复杂权限，可以先保留一条最核心的使用流程，把其他能力放到后续版本。

把第一个任务缩小到 10 分钟

第一个任务应该能快速实现，也能立即看到结果。它不需要有完整数据库、漂亮界面或正式部署，只要证明项目能运行，并且最核心的交互方向是对的。

待办工具的第一个任务可以这样定义：

目标，打开本地页面，输入一条任务后点击添加，任务立即显示在页面中。
边界，不做账号、数据库、网络请求、删除、编辑和样式优化。
验收，运行开发命令后页面可以打开；输入「购买牛奶」并点击添加，列表中出现同样的文字。

然后把需求文档交给 Codex：

请阅读 requirements.md，找出一个可以在 10 分钟内完成的首个任务。先说明会修改哪些文件、如何运行，以及怎样验证。
我确认计划后再修改代码。完成后请实际运行验证命令，并根据结果判断任务是否通过，不要只说明代码理论上可行。

如果第一个任务需要账号、密钥或外部服务，可以继续缩小范围，先用本地数据或模拟结果。联网会增加认证、权限、网络请求、服务状态和费用等变量，不适合作为零基础项目的第一个验证点。

每个任务都要有验收方法

持续获得正向反馈，比一次生成大量代码更容易交付产品。每个任务开始前都要写清楚目标和验收方法，完成后再用同一套标准检查。

常见的验证证据包括：

命令正常结束，没有错误；
页面可以打开，关键操作得到预期结果；
数据写入后可以重新读取；
测试、类型检查和构建通过；
关闭并重新启动程序后，功能仍然正常。

验证失败时，任务仍然处于开发中。不要让 Codex 通过删除测试、隐藏错误、跳过检查或改低验收标准来宣布完成。更可靠的做法是保留失败信息，找出原因，修改后重新执行同一个验证步骤。

完成一个小任务后，再让 Codex 根据 requirements.md 和当前代码推荐下一步。待办工具可以依次增加标记完成、本地持久化、筛选、D1 数据库和部署，每次只引入一类新变量。

把第一个项目完整走一遍

待办工具可以拆成五个连续阶段，每个阶段都留下一个可以观察的结果：

创建 TypeScript 项目，启动开发服务，确认本地页面可以打开。
实现添加和显示任务，输入内容后立即在页面中看到结果。
增加标记完成和本地保存，刷新页面后任务和状态仍然存在。
执行类型检查和构建，查看 diff，验证通过后创建第一个 commit。
部署到 Cloudflare Workers，用线上地址重新检查添加、显示和保存任务。

前一个阶段没有通过验收时，先不要增加下一个功能。比如本地保存还不稳定，就暂时不要接入 D1；本地构建没有通过，也不要开始部署。这样一旦出现问题，需要检查的范围通常只限于刚完成的一个阶段。

这个路线不要求第一天全部完成。第一次只走完前两步，已经得到了一个可以运行和操作的产品原型。后面的本地保存、Git 和部署可以分别作为新的任务继续完成。

用固定格式描述每个任务

需求文档负责记录整个产品，单次任务还需要更具体的说明。可以把下面这份模板保存到项目中，每次只替换方括号里的内容：

项目背景：[产品解决什么问题，当前使用什么技术]
当前状态：[已经完成什么，哪些验证已经通过]
本次目标：[这一次只实现什么]
明确不做：[本次不修改的功能和文件范围]
验收标准：[用户执行什么操作后，应该看到什么结果]
验证要求：[需要运行哪些命令，检查哪些页面或数据]
操作边界：[哪些操作需要先获得确认]
请先阅读相关文件并复述任务理解。如果信息不足，先提出问题；信息足够时，说明修改计划和验证方法，等我确认后再修改代码。完成后请实际执行验证，并报告真实结果。

这份模板不需要每次都写得很长。目标、边界和验收标准各用一两句话说清楚，通常已经足够。出现 Bug 时，再补上完整报错、复现步骤和最近改动。

管理长对话和项目上下文

同一个对话窗口不适合无限追加任务。对话变长后，旧需求、失败尝试和已经过期的代码信息会占用上下文，Codex 更容易遗漏早期约束。

一个阶段完成后，可以让 Codex 生成交接说明，至少记录：

当前目标和需求文档位置；
已完成的功能；
关键文件和项目结构；
开发、测试和构建命令；
已知问题与未完成任务；
下一步建议和对应验收方法。

把交接说明保存到项目中，再开一个新对话，让 Codex 先阅读 requirements.md、交接说明和当前代码。这样保留的是已经确认的项目状态，而不是整段混杂了尝试过程的聊天记录。

修复 Bug 时提供完整证据

开发过程中难免遇到 Bug，比如程序报错、结果与预期不同，或者之前正常的功能突然失效。Codex 能协助排查，但需要看到足够完整的现场信息。

一次有效的问题描述应包括预期结果、实际结果、完整报错、复现步骤、运行环境，以及出错前做过的修改。界面问题可以补截图，终端报错要尽量保留可复制的原始文本。

可以使用下面这个模板：

预期结果：[应该发生什么]
实际结果：[现在发生了什么]
复现步骤：[从启动程序到出现问题的完整步骤]
完整报错：[粘贴错误信息]
最近改动：[问题出现前修改了什么]
请先分析根因，再提出最小修改方案。修复后重新执行原来的验证步骤，不要通过删除测试或跳过检查绕过问题。

排查时一次只改变一个主要因素。连续修改多个文件、升级依赖和更换框架，会让问题暂时消失也无法确定原因。经过几轮仍没有进展时，可以带着最新代码、复现步骤和失败记录开启新对话。

出现这些信号时先停下来

继续生成更多代码并不一定能让任务接近完成。出现下面这些情况时，先暂停修改并重新整理现场：

同一个报错经过几轮修改仍然存在，或者修复一个问题后不断出现新的无关问题；
Codex 开始修改任务范围之外的文件，或者同时更换框架、升级依赖和重写已有模块；
新增了很多依赖，却无法说明每个依赖解决什么问题；
没有可执行的验收方法，只能根据代码看起来是否合理来判断；
需要提供生产环境密钥、修改线上数据、产生费用，或者执行删除与重置操作。

先保留完整报错并查看 git diff，让 Codex 只分析最近改动与问题之间的关系，不要立即继续修改。需要回退时，先确认哪些内容会被丢弃；不要在不了解影响时执行 reset --hard、删除文件或清空数据。

如果当前对话已经混杂了多轮失败尝试，可以按前面的交接清单记录当前状态，再开启新对话。新任务应缩小到一个可以单独验证的目标，并沿用原来的验收标准，而不是降低标准来让结果通过。

按当前任务补软件工程基础

任务复杂度增加后，需要逐渐补充软件工程基础，否则很多问题会越来越难排查。这和搭家具很像：拼一张简单桌子，依靠直觉和说明书就能完成；组装更复杂的橱柜，就要了解工具怎么用，也要看懂基础结构。

不必先学完整套课程再开始项目。更适合 Vibe Coding 的顺序是：

先理解文件、目录、终端和命令执行。
再理解项目结构、package.json、依赖和 npm scripts。
开始修改功能时，学习 TypeScript 的变量、函数、数组、对象、类型和异步操作。
接入网络和数据时，再学习 HTTP、JSON、API 和数据库。
项目开始迭代后，补上测试、日志、Git、部署和基础安全知识。

遇到陌生代码时，可以让 Codex 只解释当前任务涉及的部分，并说明修改它会影响什么。数据结构与算法仍然重要，但零基础阶段先理解项目中真实出现的问题，比脱离项目背完整概念更容易形成记忆。

用 Git 保存每个可验证版本

Git 负责记录本地代码历史，GitHub 负责远程托管和协作，两者不是同一个工具。频繁修改代码后，版本历史可以回答「刚才改了什么」和「从哪个版本开始出错」。

对初学者来说，GitHub Desktop 是比较直观的图形化工具。一个简单的工作节奏是：

项目创建后立即初始化 Git。
每次修改后先查看 diff，确认没有无关文件、密钥或大体积生成文件。
验证通过后创建一次内容清晰的 commit。
功能稳定后再 push 到 GitHub，作为远程备份或协作版本。

一次 commit 只记录一件完整的小事，比如「新增待办任务」或「修复刷新后数据丢失」。如果一个 commit 同时包含几个无关功能，后面很难单独检查或恢复。

VS Code、Cursor 和终端都可以查看、编辑代码。我个人更喜欢终端，但零基础阶段可以先从 ChatGPT 桌面客户端中的 Codex 和 GitHub Desktop 开始，等需要更精细地阅读代码时再加入编辑器。

把安全边界写进规则

Vibe Coding 降低了修改代码和执行命令的门槛，操作边界也要更明确。

公司项目使用 AI 前，应先确认公司的代码、数据和模型使用规范，不把受限代码、客户数据或内部文档发送到未经批准的服务。
API key、密码、Cookie 和访问令牌应放在本地环境变量或密钥服务中，不写进代码，不提交到 Git。
删除文件、清空数据、重置 Git、修改生产环境、付费和部署等操作，应在执行前单独确认。
安装新依赖前先说明它解决什么问题，并检查来源、维护状态和需要的权限。
第一次部署使用测试数据和独立环境，同时设置费用提醒，避免实验任务直接影响生产数据。

可以把这些规则写进项目的 AGENTS.md，让 Codex 每次进入仓库时都能读取。规则越具体，越不需要在每次对话里重复提醒。

从本地运行到 Cloudflare Workers

大多数现代产品需要联网获取数据，或者持续运行接口、定时任务和数据存储。零基础项目仍然应该从本地开始，先证明核心功能有效，再增加云端环境。

我更推荐使用 Cloudflare Workers。它适合承载 Web 应用、HTTP API 和定时任务，并能通过 D1、KV、R2 等服务处理关系数据、键值数据和文件存储。我自己的产品基本都用 Workers 构建，它省掉了不少服务器环境配置，让开发过程更专注于业务逻辑。

这也是教程选择 TypeScript 的原因。项目可以用同一种语言完成页面交互、服务端逻辑和 Workers 部署，遇到问题时不需要切换语言和运行环境。

如果项目依赖完整 Linux 环境、特殊系统软件或现有服务器程序，再评估 AWS、DigitalOcean 等云服务器。服务器提供的控制范围更大，也需要自行处理系统更新、网络、安全、进程和日志。

部署不是把代码上传后就结束。至少要确认线上地址可以访问、关键操作正常、环境变量已配置、错误日志可查看，并重新执行本地使用过的核心验收步骤。具体价格和免费额度会调整，开始项目前应以 Cloudflare 官网的最新说明为准。

积累自己的 Vibe Coding 方法

我相信，用 Vibe Coding 构建产品会越来越常见，门槛也会继续降低。持续积累一套稳定的开发方法更有价值，某一段生成代码很快就会过时。

每次完成任务后，可以记录需求、Codex 的关键提示、修改过的文件、验证命令、遇到的错误和最终解决方式。做过几个项目后，会逐渐形成自己的需求模板、验收清单、Debug 模板和项目规则。

模型和工具还会继续变化，但需求拆解、逐步验证、版本管理和安全边界不会很快过时。把这些基础动作练熟，后面增加数据库、登录、支付、AI Agent 或更复杂的产品功能时，仍然可以沿用同一套方法。