AI工具实战--VibeCoding开发流程：写代码前的9步准备
VibeCoding最近特别火。但很多朋友反映一个问题：通过VibeCoding项目推得特别快，但越往后代码越乱，慢慢变成"屎山"，越改越差，最后牵一发而动全身，整个项目直接崩盘。
问题不在AI强不强，而在于VibeCoding不是"把活丢给AI就完事了"，你还需要构建一套工程流程来驾驭AI。
今天讲一套标准的工作流：开发前的9个步骤 + 开发中的5个关键点。
总览
开发前：9个步骤（三阶段） ├── 第一阶段：定图纸（步骤1-3） ├── 第二阶段：打地基（步骤4-6） └── 第三阶段：立规矩（步骤7-9） 开发中：5个关键点 ├── 关键点1：小步迭代 ├── 关键点2：主动拆分 ├── 关键点3：限制权限 ├── 关键点4：坚守安全底线 └── 关键点5：科学应对报错第一阶段：定图纸（步骤1-3）
步骤1：导需求
先别写代码，先像跟朋友聊天一样，把痛点、目标用户、使用场景、理想中的核心功能全部讲给AI。
这个时候不用追求严谨，追求信息量。
让AI理解你想要什么，比让AI马上动手更重要。
步骤2：整理PRD文档
让AI输出一份结构化的PRD文档，包括：
| 内容 | 说明 |
|---|---|
| 功能列表 | 有哪些功能 |
| 用户流程 | 用户怎么操作 |
| 页面清单 | 有哪些页面 |
重点：每个功能后面补一句"做到什么程度才算完成"。
| 功能 | 验收标准 |
|---|---|
| 用户登录 | 输入账号密码，点击登录，跳转到首页 |
| 登录失败 | 提示"账号或密码错误"，不锁定账户 |
| 登录成功 | 跳转到首页，显示用户名 |
如果你没有验收标准，一定会写得越来越发散。
步骤3：定视觉和页面框架
找2-3个参考网站，或者让AI给出几种风格方案。
你需要决定：
- 导航栏怎么放
- 页面有哪些区块
- 整体想要简约风还是豪华风
这步是为了后面不让AI一边写功能一边把UI推倒重来。
第二阶段：打地基（步骤4-6）
步骤4：明确项目边界和非功能需求
回答三个问题：
| 问题 | 说明 |
|---|---|
| 本地自用还是上线公开？ | 影响安全性和性能要求 |
| 有没有用户数据、支付、隐私合规？ | 影响合规设计 |
| 性能和成本有没有上限？ | 影响技术选型 |
安全、性能、可用性、成本——这四个不写清楚，后面一定会返工。
步骤5：锁定技术栈
原则：不是越主流越好，而是越可验证越好。
主流技术通常更稳，因为资料多、工具链成熟、不容易瞎编。
但更关键的是：你选的技术要有：
- 社区材料
- 官方文档
- 清晰示例
- 能跑测试
- 能监控
一句话总结：不用追求特别潮，追求可控、资料多。
步骤6：出轻量化架构草案
让AI输出：
| 内容 | 说明 |
|---|---|
| 目录架构 | 怎么分层 |
| 核心模块 | 有哪些模块 |
| 数据模型 | 长什么样 |
| 服务端逻辑 | 哪些逻辑必须在服务端 |
注意：这是草案，不是宪法。允许持续迭代，但每次迭代都要记录原因。
第三阶段：立规矩（步骤7-9）
步骤7：固化项目上下文
把架构、当前状态写成项目根目录的三个文本文件：
| 文件 | 内容 |
|---|---|
| PRD.md | 需求文档 |
| ARCH.md | 架构描述 |
| PROJECT.md | 项目阶段、已知问题、下一步要干嘛 |
这三份是AI的全局上下文。每次大改动，这三份必须同步更新，否则AI会按照旧的世界观写新代码。
步骤8：定开发规范和参考资料
让AI有"照着抄"的标准：
| 规范 | 示例 |
|---|---|
| 语言规范 | 必须用TypeScript |
| 命名规则 | 组件命名用PascalCase |
| 文件限制 | 单文件不超过500行 |
另外建一个reference文件夹，放你认可的按钮、表单、弹窗的标准实现。
步骤9：拉起Git和质量闸门
Git是安全带。
某个代码写着写着飞了，你可以通过Git一键回溯到以前最好的代码。
通过多个分支开发，不同特性并行开发，不用担心冲突。
开发中的5个关键点
关键点1：小步迭代（MVP法则）
一次只做一个可验证的小切片。
| 阶段 | 目标 |
|---|---|
| 页面能打开 | 最小可用 |
| 能提交表单 | 核心交互 |
| 服务端保存 | 数据持久化 |
| 权限校验 | 安全性 |
| 列表展示 | 完整流程 |
每完成一个能跑通的切片，就跑测试、Git提交一次。
关键点2：主动拆分
人类必须介入。
不允许所有代码都放在同一个文件里。虽然看着很爽，但后面找某个功能会特别崩溃。
关键点3：限制权限，禁止AI做主
每次任务结尾加一句：
“只改我点名的文件和范围，不要顺手重构，不要改UI风格，不要改无关逻辑。”
你让他修一个按钮，它可能顺便重写整个页面。
用状态摘要管理上下文，防止AI越改越多。
关键点4：坚守安全底线
这四条必须盯住：
| 底线 | 说明 |
|---|---|
| 敏感信息不入前端 | 很容易被人抓出来 |
| 密钥不入仓库 | 用环境变量和服务端调用 |
| 服务端校验和授权校验 | 不能信任前端输入 |
| 不信任任何用户输入 | 防注入攻击 |
写代码往往只求能跑，不会默认安全。你至少要盯住这些底线。
关键点5：科学应对报错
如果两次没有新增证据，就停掉。
正确做法：
| 步骤 | 动作 |
|---|---|
| 1 | 做最小复现，把问题缩到最小输入 |
| 2 | 加日志、加断点，打印关键变量分支 |
| 3 | 写一个小测试，把当前正确行为锁住 |
| 4 | 让AI基于测试来修 |
如果连续两次都没有进展，只是在拆东墙补西墙，借助Git回滚到上一个稳定点，别让它乱改扩大损失。
检查清单
开发前检查
- 需求是否讲清楚？
- PRD是否有验收标准？
- 技术栈是否锁定？
- 架构草案是否输出？
- 三个上下文文件是否创建？
开发中检查
- 是否小步迭代？
- 是否主动拆分模块？
- 是否限制AI的修改范围？
- 是否遵守安全底线？
- 报错时是否科学应对？
常见问题
Q1：开发前花这么多时间值得吗？
值得。9步准备可能花1-2小时，但能避免后面几天的返工。
Q2：AI不听我的怎么办？
用更具体的约束。不要说"优化一下"，要说"只改XX文件的XX函数，不超过20行"。
Q3：项目已经变成"屎山"了怎么办？
如果重构成本高于重写成本，考虑重新开始，这次按流程来。
一句话总结
开发前的9步告诉你做什么、怎么做，开发中的5个关键点决定你的项目能不能真正落地存活。
你负责边界和验收，AI负责体力活。