VibeCoding 新手入门：开发前做好这 4 件事，AI 才能替你高效完成”软件工程”

AI 确实让”写代码”变得像说话一样简单，但软件工程从来不只是”写代码”。需求模糊、文件混乱、版本失控、角色混淆——这些问题 AI 解决不了，只能靠你自己提前布局。

VibeCoding新手入门：开发前做好这4件事 - 流程步骤图 — VibeCoding新手入门：开发前做好4项工程准备

很多新手拿到 AI 的第一反应是：”帮我写个 App”。结果 AI 生成了几百行代码，你却发现它完全不是你想要的；改了几轮需求后，代码变得一团糟；想回到三天前的版本，却只能手动复制粘贴……
这不是 AI 不行，而是你跳过了开发前的”工程准备”。

本文将用 30 分钟带你完成 4 项核心准备，它们不涉及任何编程技能，却决定了后续 AI 协作的效率。记住：AI 降低了编程门槛，但软件工程的门槛——需求管理、版本控制、流程分工——依然需要你亲手搭建。

准备一：整理项目文件夹 —— 别让所有东西都堆在桌面

新手常见惨状： 同一个项目里，需求.txt、最终版代码.html、参考设计.png、临时测试.js 全挤在一个文件夹，两周后你根本分不清哪个才是最新的。

软件工程第一课：物理隔离 = 逻辑清晰。 至少创建三个顶层目录：

my-project/
├── 01-产品文档/          # 所有需求、设计稿、会议记录
│   ├── 需求描述.md
│   ├── MVP定义.md        # 后文会写的核心文档
│   └── 参考素材/
├── 02-代码项目/          # 唯一存放源代码的地方（AI 只操作这里）
│   ├── src/
│   └── README.md
└── 03-产品设计/          # 可选，UI/UX 设计稿、流程图
    └── 页面原型.fig

为什么要这么分？

AI 生成代码时，你直接指定”所有代码输出到 02-代码项目“，避免它误读其他杂文件。
需求变更时，在 01-产品文档 中更新文档，AI 能精准获取最新版本。
以后想复用设计或查看历史需求，一秒定位。

这不仅仅是编程——这是在为整个项目建立清晰的信息架构，是工程化的起点。

准备二：定义 MVP 并写出”施工图纸” —— 先验证核心，再锦上添花

新手最大误区： 让 AI 一次性实现登录、支付、社交分享、暗黑模式……结果每个功能都半生不熟，连最核心的流程都跑不通。

正确思路： 只定义 MVP（Minimum Viable Product，最小可行产品）——那个如果做不成，整个项目就毫无价值的核心功能。MVP 不追求完美，只追求”可验证”。

两步搞定 MVP

第一步：问自己一个残忍的问题

“如果这个产品只能做一件事，那件事是什么？”

比如一个”待办事项工具”，MVP 就是”能增删改待办项，且数据在页面刷新后不丢失（但可以先做内存版，后续再加持久化）”。先把最简单的那条路径跑通。

第二步：写一份 MVP定义.md（即 spec 文档）
这份文档不是长篇大论，而是给 AI 的”施工图纸”。它必须包含三个部分：

# 项目：待办工具 - MVP 版本

## 核心目标（唯一验证点）
用户能添加、完成、删除待办项，所有操作实时反映在界面上。

## 功能验收清单（可逐条勾选）
- [ ] 输入框 + 添加按钮：输入文本后回车或点击，新增待办项
- [ ] 待办列表：显示所有项，按添加时间倒序
- [ ] 每项带复选框（标记完成/未完成）和删除按钮
- [ ] 底部统计：总条数 + 未完成条数
- [ ] 刷新页面后数据重置（此版不做持久化，明确说明）

## 技术约束（给 AI 的指令）
- 使用纯 HTML + CSS + JavaScript，单文件 `index.html`
- 样式干净简洁（卡片式布局）
- 关键函数必须加中文注释

## 明确不做（防止 AI 发散）
- 不做数据存储（留到后续版本）
- 不做用户登录
- 不做分类、标签、搜索

给 AI 的指令要精准： 首次对话时，直接把这份文档贴给 AI，并说”请严格按照这份 MVP 定义生成代码”。AI 不会自作主张，只会实现你圈定的范围。

这不仅仅是编程——这是需求工程。你在用文档锁住范围，避免”需求蔓延”这个软件工程的头号杀手。

准备三：搭建 Git 仓库 —— 给你的项目装上”时光机”

新手常犯错误： 每次让 AI 修改代码后，手动复制一份备份，命名 index_final_v3_真的最终版.html。不出三天，版本彻底失控。

Git 是什么？ 它是一个版本控制系统，可以记录每次代码变更，允许你随时回退到任意历史版本，还能创建独立分支做实验而不影响主线。

对新手的最低要求：让 AI 帮你初始化 Git 仓库。 只需对 AI 说：

“请将 02-代码项目 初始化为 Git 仓库，并完成第一次提交，提交信息为 ‘init’。”

AI 会自动执行 git init、git add .、git commit。此后，每当 AI 完成一个小功能或修复一个 Bug，它会主动询问你是否提交。你只需回复”提交”或”commit”，AI 就会生成一条提交记录。

三个让你离不开 Git 的场景

场景	你的操作（或让 AI 代劳）
AI 改坏了代码，想回到昨天能跑的版本	`git checkout <旧版本哈希>` 或 `git revert`
想尝试新的 UI 框架，但怕影响主代码	`git checkout -b experiment-ui`，不满意就切回主分支删除实验分支
想分享项目给朋友或开源	关联 GitHub/Gitee 仓库，`git push` 一键上传

这不仅仅是编程——这是配置管理，是软件工程中保障代码资产安全的核心实践。

准备四：拆分 AI 对话角色 —— 让”产品经理”和”程序员”各司其职

很多新手在一个对话窗口里既讨论需求又写代码，结果 AI 的上下文里混入了大量需求讨论和代码片段，导致它经常”记错”或”脑补”未确认的功能。

解决方案：建立两个独立的对话窗口，分别扮演不同角色。

具体操作（以 ChatGPT / Claude 为例）

窗口 A —— 产品经理（PM）
开场 prompt：
> “你是一位资深产品经理。我们正在开发 [项目名]。你的职责是帮我梳理需求、定义 MVP、撰写 MVP定义.md 文档。只输出文档内容，不写代码。”
在这个窗口里，你们反复讨论，最终产出清晰的 MVP 定义。将此文档保存到 01-产品文档。
窗口 B —— 研发工程师（Dev）
开场 prompt：
> “你是一位全栈工程师。我会把 MVP定义.md 贴给你，请严格按照文档生成可运行的代码，不做额外功能。如发现需求模糊，请先提问，但不要自行假设。”
将最终版的 MVP 定义直接粘贴进来，让 AI 生成代码。
如果开发过程中发现需求有歧义，不要在这个窗口里讨论——回到窗口 A 修改定义，更新后再把新版本贴给窗口 B。

为什么这种”角色隔离”有效？

混用窗口的问题	拆分角色后的好处
上下文过长，AI 遗忘早期决策	每个窗口内容精炼，重点突出
需求变更时，AI 在旧需求和新需求间摇摆	PM 窗口专门管变更，Dev 窗口只认最新文档
代码中常出现未定义的功能	研发严格按 spec 执行，不会”自由发挥”

这不仅仅是编程——这是流程分工，是软件工程中”职责分离”思想的极简实践。你不需要真正的团队，但你可以用 AI 模拟团队协作。

你的开发前 30 分钟检查清单

在让 AI 写任何业务代码之前，按顺序完成以下动作：

[ ] 创建文件夹：产品文档、代码项目（、产品设计）三个目录。
[ ] 定义 MVP：写出核心目标和验收清单，保存为 MVP定义.md。
[ ] 初始化 Git：让 AI 将代码项目转为 Git 仓库并完成首次提交。
[ ] 拆分角色：分别设置”产品经理”和”研发工程师”两个对话窗口，将 MVP定义.md 提供给研发。

完成这些后，你再对研发窗口说：”开始编码。” 此后，每完成一个可运行的小功能就提交一次代码；每当你想要增加新功能，先回产品窗口更新定义，再贴给研发窗口。
你会发现 AI 的输出稳定、可预期，而且你随时可以回退、对比、迭代。

最后：AI 帮你写代码，但软件工程得靠你

AI 让”从想法到代码”的路程缩短了 90%，但剩下的 10% 恰恰是决定项目成败的关键——需求边界、版本管理、流程规范。这些从来不是代码本身，而是你作为”项目负责人”必须掌控的工程素养。

按本文步骤做好准备工作，你不仅能让 AI 高效产出，更能培养起受益终生的软件工程习惯。现在就去创建你的第一个项目文件夹吧——这 30 分钟，值回你未来上百小时的时间。