没有完整开发经验，怎样通过 Vibe Coding 从头到尾完成一个项目？

一、全文速览图

你看着身边的朋友用 AI 做出了属于自己的项目。有人搭了一个网页，有人做了一款 App。你心里多少会冒出一个念头，我是不是也能 Vibe Coding 一个。

轮到自己动手，事情经常卡在另一种状态。AI 写了几轮以后，你开始不知道下一句该让它做什么。好不容易做出几个页面，发现继续加登录、数据库和付款的时候前面的代码又要推翻。对话越拖越长，每轮带进去的上下文越来越多，token 消耗也跟着往上走，成本慢慢也有点兜不住。

这种“卡住”不只出现在完全没有开发经验的人身上。有人只熟悉前端，后端和数据库从来没碰过。还有一些人会做设计、产品或测试，却没有独立走完过整个开发流程。大家欠缺的其实是一样的东西，就是从一个想法出发，怎样一步步把它做成可以打开、可以使用、可以继续维护的完整项目。

这篇文章就是写给遇到类似卡点的这些人的。你不需要先把前端、后端和数据库都学一遍，也不用装成什么都懂。你要做的是在每个阶段把问题问清楚，保留关键决定，再让 AI 完成它擅长的执行工作。

本文会从立项、技术选型、项目结构、长期规则和阶段实施，一直讲到测试、发布和验收。不是只生成几个页面就算完成了，完整项目是需要把这一整段流程都走完的。

在这篇文章里，我把容易混用的技术词都对照官方文档重新核对过。下面出现的词看着可能有点多，每个词我都会在第一次出现时说明用途。你不需要背，知道它会影响哪一步就够了。

二、先弄清楚，为什么你的 AI 会越写越乱

看到这里，你可能会有个疑问。既然 AI 已经能写代码，为什么不能先做起来，遇到问题再慢慢改？

前几轮确实很顺。你让 AI 做一个首页，它很快就能给出结果，接着加登录、预约和后台，每个要求单独看也不复杂。

麻烦在这时候其实就已经埋下了。项目越往后，代码越依赖前面已经做过的决定，用户分几种身份、预约记录怎样保存、取消以后数据怎么处理，都会影响后面的功能。

这些决定如果只留在聊天里，AI 每次工作都要重新翻前面的对话。旧要求和新要求发生冲突时，它还得自己判断该听哪一个。于是，开头提到的几种困扰会慢慢连在一起。代码反复推翻，上下文越来越长，token 消耗跟着增加，最后连“这个功能到底算没算完成”都很难说清。

第一步：把项目和功能边界写清楚

立项先确定几件很朴素的关键点。谁会使用这个项目，他想完成什么任务，第一版需要做到哪里，哪些情况暂时不处理。

我使用做过的一个宠物门店预约工具举例。项目说明可以写成这样“顾客在手机上选择服务、员工和可预约时间，提交预约后支付定金。门店员工可以查看当天安排，也能确认、改期和取消预约。第一版只服务一家门店，会员积分、营销活动和多门店结算留到以后。”

这段话有了，功能清单才有依据。注册和登录、服务项目、员工资料、可预约时段、预约记录、定金订单、取消规则和门店后台，都可以拆成单独功能。每项功能继续补上使用者、触发条件、正常结果和主要异常。接着画出顾客预约和门店处理的页面流程，低保真线框图做到能看清页面、按钮和跳转关系就够了。暂时不做的内容也要留下记录。

这里可以使用“第一版”或 MVP。MVP 指最小可行产品，它仍然要让目标用户完成一项完整任务。只摆出几张能点击的页面，更适合叫原型图。

做到这里，很多人会卡在“我怎么知道功能有没有漏”。最基础的办法，是把项目说明交给 AI，让它分别从普通用户、管理员和异常情况三个角度补功能清单，再由你逐项确认，未经确认的内容先放进待讨论区。

这一关省掉以后，最熟悉的场面就是当时做到一半才问“管理员从哪里改价格”。AI 只能回头补后台，刚写好的接口和数据权限也跟着重来。

第二步：选定技术栈和数据库

需求范围确定后，再选择前端框架、UI 组件库、后端运行环境、数据库和部署方式。技术栈是这些技术选择的组合。它不等同于项目结构，也不等同于某一种编程语言。

完全没有开发经验的人，看到 React、Vue、Node.js 和各种数据库名字，很容易在这里停住。你不需要先判断哪一项技术更高级。先告诉 AI 项目准备发布到哪里、谁会使用、有没有付款和账号权限，再让它根据这些条件缩小范围。

选型先看约束。项目要发布到网页、小程序还是手机应用，预计有多少人同时使用，有没有付款和权限，谁来维护，准备部署到哪里。

数据库也要根据数据关系来选。预约工具里有顾客、员工、服务、时段、预约和付款记录，它们之间关系明确，重复预约还涉及并发写入和事务。关系型数据库通常更合适。PostgreSQL 的事务可以把多次更新作为一个完整操作处理，中途失败时一起回滚。

SQLite 适合设备本地、单机工具和写入并发较低的场景。它是嵌入应用的数据库，和 PostgreSQL 这类客户端服务器数据库解决的问题不完全相同。多人在线写入、数据放在独立服务器或写入并发较高时，优先考虑客户端服务器数据库。

选定以后，把版本、选择理由和暂不采用的方案写进技术选型记录。后面出现新需求，可以重新评估。单纯因为看到另一套框架更流行就更换，通常不值得。

最常衍生的问题是“我该选 PostgreSQL、MySQL、SQLite 还是文档数据库”。先把数据对象、对象关系、事务要求、并发写入、部署位置和预计数据量告诉 AI，让它按这些条件做一张比较表，并要求每个结论引用官方文档。

如果你已经知道项目要做什么，技术选型却一直定不下来，可以在评论区留下“技术选型”和项目简介。我可以帮你把候选方案缩到一两套，并把维护成本和以后最可能遇到的问题写清楚。

这一步反复摇摆，后果最容易让人泄气。页面用一套框架写了十几个，后端也已经接上数据库，因为临时换技术栈，前面的代码只能一页页迁过去，项目像是一直在开工，却始终到不了能交付的那天。

第三步：建立最小可运行的项目结构

技术栈定好以后，先用框架官方提供的脚手架或项目创建工具生成基础项目。脚手架指的是官方维护的初始化工具和模板。它负责创建必要的目录、配置和依赖，能减少手工拼装带来的版本问题。

如果你只做过前端，这一步最容易低估后端需要的准备。完全没有开发经验的人又容易走到另一个方向，让 AI 一次创建几十个目录，自己也不知道每个目录有什么用。基础项目的判断标准很简单，能够运行，规则统一，并且每个目录都能用一句普通话解释清楚。

项目结构也常被叫作目录结构，它负责说明代码放在哪里。架构的范围更大，还包括模块之间怎样调用、数据怎样流动、哪些部分可以依赖哪些部分。两者需要一起确定，不能只画一棵好看的文件树。

后端先跑通配置读取、数据库连接和迁移，约定 API 接口的正常响应与错误格式，再接入日志、身份认证入口和健康检查。前端先确定路由、页面模块、公共 UI、请求封装、表单校验和登录状态怎样保存。全局状态管理可以等到跨页面共享数据确实变多以后再引入，没有必要为了目录看起来完整而先装一套全局状态管理方案。

最小项目完成时，业务功能可以很少。前端能够启动，后端能返回结果，数据库迁移可以执行，测试和代码检查也能运行。此时还要初始化 Git 版本管理，准备忽略文件和环境变量示例，密钥只放在本地或部署平台的安全配置中。框架已经规定的目录和文件约定，优先跟官方文档走。例如：Next.js 官方文档就明确列出了路由文件、配置文件和几种项目组织方式，并提醒团队选定一种后保持一致。

这一步经常冒出的问题是“我看过很多目录模板，到底哪一种才对”。先去框架官方文档看文件约定，再让 AI 根据当前功能清单给出一棵最小目录树，并逐个解释每个目录负责什么、哪些依赖关系不允许出现。

如果你拿不准项目该分几层，也可以把技术栈和功能清单发给我。我可以帮你先定一版够用的结构，避免一开始把简单项目拆得过重。

没有这一步，开发到第三四个功能时最容易乱。AI 为了赶进度又建一个 utils，又复制一份请求代码。你后来想改登录过期提示，搜索出来七八个文件，每个地方还写得不一样。这也就是常说的代码屎山，其实不仅开发有代码屎山，AI 的上下文屎山、UI 的模板参考屎山，每个地方都会因为前期规划不足而出现单独的屎山。

第四步：创建项目规则文件

项目结构搭起来以后，还要把这套写法固定下来，让 AI 换了会话也能继续遵守。很多人把这份文件叫 Agent 宪法，这个俗称方便理解。各家 AI 编程工具使用的正式名称并不统一，本文统一称为项目规则文件或项目指令文件。

这里也不用死记文件名。你只要知道，这份文件负责把每次开工都要重复交代的规则留在项目里。具体放在哪里，交给当前工具的官方文档来回答。

不同工具读取的位置不同。Claude Code 使用 CLAUDE.md 作为项目指令，也支持放在 .claude/rules/ 下的规则文件。Cursor 当前推荐把项目规则放在 .cursor/rules，旧的 .cursorrules 已经属于兼容格式。使用其他工具时，应当查看它的官方文档，不能把一个文件名直接套到所有产品上。

规则文件适合记录每次开发都要遵守的内容。常用的启动和测试命令、目录与命名约定、API 和数据库规则、增加依赖前要做的检查，还有完成当前阶段后必须停下汇报，都可以写进去。内容要短，要求要能检查。像“保持高质量”这种话很难执行，换成“修改后运行哪些测试”会清楚得多。

规则文件会进入模型上下文，也会占用 token。Claude Code 官方文档就建议让项目指令保持简洁，并明确提醒过长文件会消耗更多上下文。规则还属于给模型的指导，不能当成技术上的强制措施。禁止提交密钥、必须通过测试这类要求，还要配合权限设置、代码检查、自动化测试或持续集成检查，也就是 CI，才更可靠。

走到这里，常见问题会变成“我不知道工具到底会读哪个文件”。最基础的解决办法是查看当前工具的 Rules、Memory 或 Project Instructions 官方页面，再让工具列出本次会话已经加载的规则文件，确认以后再开工。

这一步不做，换一次会话就像换了一个没参加过前面讨论的同事。你刚纠正过“不要在页面里直接访问数据库”，过两天开个新任务，它又把同样的写法放了回来。

第五步：把当前阶段写成单一可信来源

项目规则文件管的是每次开发都要遵守的长期规则。接下来还缺一份任务单，用来说明当前阶段究竟要做什么、做到哪里停。

“实施真元文档”是这套方法里的自定义称呼。更稳妥的写法是阶段实施文档，并把它定为当前阶段的单一可信来源，也就是 SSOT。这个词的重点很简单，开发、修改和验收都以同一份文档为准。

SSOT 这个缩写也不用记。你只需要保证同一阶段只有一份正式任务单。聊天里临时想到的改动，写回这份任务单以后才开始执行。

假设当前阶段写着“完成预约功能”，AI 还要猜很多事。比如：顾客能不能改期，重复提交怎样处理，员工请假以后发现已有预约了怎么办，取消后定金是否自动退回，这些都会影响代码和数据。

阶段实施文档要继续拆成子阶段文档。比如：先建立服务和员工资料，再配置可预约时段。随后完成顾客提交预约和冲突校验，门店确认与改期放在下一段。定金支付、消息通知和会员功能暂时不碰。

每个子阶段写清输入、要做的事、完成条件和验证方法，再标出明确不用做的内容。聊天里出现新想法，先评估影响，再回写文档。数据库核心字段、登录权限和支付流程发生变化时，还要更新技术选型或架构记录，不能只改一句聊天指令。

很多人会问“任务到底拆到多细才合适”。一个实用尺度就是让每个子阶段能在一次专注任务里完成，并且可以单独验证。拿不准时，让 AI 把任务改写成带有前置条件、交付结果、验收标准和排除项的步骤文档，任何一项你认为仍然含糊就继续拆。

如果省掉这一步，你会经常收到一种很难评价的汇报。AI 说“预约模块已完成”，你打开以后只有页面和按钮，刷新页面数据就没了。你说的完成和它理解的完成，从开工时就已经不是同一件事情了。

第六步：分阶段实施、验收和管理上下文

正式开发以后，每次只交给 AI 一个子阶段。开工前把项目规则文件和阶段实施文档路径发给它，再说明这次允许修改的范围。做完以后停下来，先汇报和验收，不能自动进入下一阶段。

到了这一步，前端开发者可以用自己熟悉的页面检查结果，完全不懂代码的人也有办法验收。页面是否能操作，数据刷新后还在不在，重复提交会发生什么，这些都是肉眼能看到的结果。自动化测试和代码检查可以让 AI 运行，再让它把结果换成普通话汇报。

这段开工指令可以直接使用。

请读取并严格遵守项目规则文件和阶段实施文档。只实施当前子阶段，不增加范围外功能。完成后停止修改，对照验收标准汇报结果，不要自动进入下一阶段。

验收时让 AI 回答三件事。它完成了哪些条目，还有哪些没有完成。这次改了哪些文件，是否出现文档外的改动。它运行了哪些自动化测试，手动验证又得到什么结果。

项目条件允许时，每个子阶段保留一次 Git 提交或独立分支。Git 提交是一个可回看的代码版本点，独立分支则把当前改动和稳定版本分开。验收失败时，你可以明确知道这一段改了什么，也更容易撤销或比较。这里的撤销仍然要先确认范围，不能让 AI 随手清掉尚未保存的工作。

准备发布时，再单独安排一个发布子阶段。让 AI 检查生产环境变量、数据库迁移、数据备份、域名与 HTTPS、日志和错误监控，并写好失败后的回退办法。部署完成后还要在正式环境走一遍最关键的用户流程，确认注册、预约和后台处理都能工作，项目才算完成这一版。

上下文也要在这一步管理。一个子阶段结束后，把完成结果、未解决问题和下一步回写阶段文档。进入新的大阶段时，可以开启新会话，只提供项目规则、阶段文档和必要文件，避免把几十轮聊天一起带过去。OpenAI 的模型指导里也建议精简重复指令，并在长时间运行的 Agent 工作里有意识地去整理常用状态。

最后常见的一个问题是“我不懂代码，怎么写验收”。把阶段文档交给 AI，让它把每条完成条件改成可观察的测试，分别给出自动化测试命令、手动操作步骤和预期结果，你只按结果逐项检查。

如果你跳过验收，最容易发生的事是 AI 每次都说完成，你每次都回复继续。等到付款、权限和预约状态一起出现问题，已经很难说清是哪一个阶段带进来的。前面每一次没有检查的“继续”，都会变成最后那次没人敢动的大改。

三、“把聊天变短，把项目记忆留在项目里”

用 Vibe Coding 做完整项目，最省时间的状态往往显得有点慢。开工前先写清需求，选定技术栈，建立项目结构，再把长期规则和当前任务分别放进文档。开发时一次做一小段，验收以后才继续。

这样做以后，即使当前对话太长，你也可以重新开一个会话。让 AI 先读取需求文档、项目规则和阶段实施文档，它就能知道项目要做什么、已经做到哪里，不需要你重新讲一遍前面几十轮的内容。

开发经验当然有用，它能帮助你更快发现风险。没有完整开发经验，也不妨碍你先把第一版做出来。流程会告诉你当前该决定什么，官方文档负责说明技术本身，AI 则帮你补上眼前缺少的知识。

如果你已经有一个项目想法，却卡在技术栈、数据库或项目结构，可以在评论区留言“帮我选型”，也可以把项目简介直接发给我。只要先写清使用者、核心功能和准备发布的平台，我就能帮你整理出一份可以交给 AI 继续往下做的基础方案。