这篇文章是 Vibe Coding 系列的第四篇。它回答一个非常实际的问题：怎样把一句 Prompt 变成一段可以提交的代码，而不是变成一堆看起来能跑、实际上没人敢维护的改动。
系列导航
- Vibe Coding 系列导读：给计算机学生的 AI 协作开发路线
- Vibe Coding 学习路线：计算机学生如何从 0 到 1 上手 AI 辅助开发
- Cursor、Codex、Claude Code 怎么选：AI 编程工具链入门
- 工程闭环：从 Prompt 到可提交代码：Vibe Coding 的工程闭环
- 上下文工程：AGENTS.md、项目规则和可复用 Skills
- 实战篇：用 Vibe Coding 做课程项目、个人工具和科研复现
为什么要讲工程闭环
很多 Vibe Coding 翻车不是因为 AI 完全不会写代码，而是因为人把开发过程压缩成了一句话：
1
帮我做一个完整的 xxx 系统。
这句话的问题不是不礼貌，而是没有工程边界。AI 不知道你已有项目结构，不知道第一版做什么、不做什么，不知道如何验收，也不知道哪些文件不能碰。它只能根据概率生成一个看似完整的结果。
工程式 Vibe Coding 需要一个闭环：
1
Explore -> Plan -> Implement -> Verify -> Review -> Commit
这六步看起来比直接写 Prompt 麻烦，但它能显著降低失控概率。你不是让 AI 随机发挥，而是在每一步给它明确目标和反馈。
Step 1：Explore，先探索
探索阶段的目标是让 AI 理解现状，而不是立刻动手。无论是课程项目、个人工具还是工作项目，只要不是全新空目录，都应该先让 AI 读代码。
一个好的探索 Prompt：
1
2
3
4
5
6
7
8
9
请先阅读这个项目，不要修改文件。
重点关注：
1. 项目的技术栈和启动方式；
2. 主要目录结构；
3. 和用户登录相关的模块；
4. 现有测试和构建命令。
请输出你的理解，以及如果要新增“重置密码”功能，可能涉及哪些文件。
这一步的价值在于防止 AI 凭空想象。它需要先知道项目是 Vue 还是 React，是 FastAPI 还是 Spring Boot，状态管理在哪里，接口层在哪里，测试怎么跑。
探索阶段你要检查三件事：
- AI 有没有读到真实文件；
- 它对项目结构的理解是否准确；
- 它是否把不相关模块也拉进来了。
如果它理解错了，不要急着实现，先纠正。越早纠正，代价越小。
Step 2：Plan，再计划
计划阶段的目标是把任务拆成可控步骤。一个好计划应该回答：
- 要改哪些模块；
- 每个模块改什么；
- 有哪些风险；
- 如何验证；
- 哪些事情本次不做。
你可以这样要求：
1
2
3
4
5
6
7
8
基于刚才的项目理解，请为“重置密码”功能制定实现计划。
要求：
1. 不要写代码；
2. 按后端、前端、测试、文档拆分；
3. 标出每一步涉及的文件；
4. 标出你认为需要我确认的产品细节；
5. 给出最小可交付版本，不要扩展到短信、邮箱模板和复杂审计。
计划阶段尤其适合发现需求缺口。比如“重置密码”到底是通过邮箱链接，还是管理员手动重置？是否需要验证码？链接多久过期？这些不是 AI 能凭空决定的产品问题。
如果是学生项目，可以把计划简化，但不要省略。哪怕只有三步，也要先写出来。
Step 3：Implement，小步实现
实现阶段的原则是：一次只做一个稳定可验证的改动。
不要让 AI 同时做数据库、后端、前端、样式、测试、文档。更好的顺序是：
- 先改数据模型或接口；
- 跑后端测试；
- 再接前端页面；
- 手动验证流程；
- 最后补文档和边界。
一个实现 Prompt 可以这样写：
1
2
3
4
5
6
7
8
请只实现计划中的第一步：新增后端接口。
限制：
1. 不要修改前端；
2. 不要新增第三方依赖；
3. 沿用现有 Service 和 Controller 风格；
4. 修改后请说明改了哪些文件；
5. 如果有测试命令，请运行或告诉我需要运行什么。
这里的“只实现第一步”非常重要。Vibe Coding 的速度已经足够快，不需要再通过大包大揽来冒险。小步修改让你可以随时停下来审查，也让 Git diff 更容易理解。
Step 4：Verify，必须验证
验证阶段是区分“AI 写了代码”和“代码可以交付”的分界线。
验证可以分很多层：
- 语法层：能否编译或启动；
- 单元层：函数和模块是否符合预期；
- 接口层：请求和响应是否正确；
- 页面层：用户流程是否跑通；
- 回归层：旧功能是否被破坏。
如果项目有测试，优先跑测试。如果没有测试，至少做手动验证，并把验证步骤写下来。
一个验证 Prompt：
1
2
3
4
5
6
7
请根据刚才的改动给出验证清单。
要求：
1. 包含自动测试命令；
2. 包含手动验证步骤；
3. 包含至少 3 个边界场景；
4. 如果项目缺少测试，请说明最小应该补哪类测试。
对学生来说，验证经常被忽略。页面看起来能点，不等于功能正确。比如表单提交成功了，但刷新后数据丢失；接口返回 200，但错误输入也被保存；模型训练跑完了，但数据集路径其实错了。这些都需要验证。
Step 5：Review，审查 diff
AI 修改完代码后，你必须看 diff。不是随便瞄一眼，而是带着问题看：
- 它是否只改了计划中的文件？
- 有没有顺手格式化大量无关代码？
- 有没有新增不必要依赖？
- 有没有把配置、密钥、路径写死？
- 有没有删掉原有逻辑？
- 有没有把错误吞掉？
- 有没有重复造轮子？
一个代码审查 Prompt：
1
2
3
4
5
6
7
8
9
10
请以代码审查的方式检查当前改动。
重点关注：
1. 行为是否符合需求；
2. 是否有安全或数据一致性问题；
3. 是否有无关改动；
4. 是否缺少测试；
5. 是否有更简单的实现方式。
请按严重程度列出问题，不要重写代码。
这一步可以让 AI 自己复查，但最终仍然要你判断。AI 很擅长发现明显问题，也可能漏掉业务语义。因此你要结合需求和项目背景来审查。
Step 6：Commit，形成可回退节点
提交不是最后的形式主义，而是工程闭环的一部分。每次完成一个可验证功能，都应该形成一个清楚的 Git 节点。
好的提交应该满足：
- 一个提交只解决一个明确问题；
- 提交信息能看懂；
- 提交前已经验证；
- diff 中没有无关改动。
提交信息可以简单：
1
2
3
4
feat: add password reset API
fix: handle empty score rows in importer
docs: document local setup workflow
test: cover monthly summary calculation
学生项目也应该这么做。Git 不是团队项目才需要，它是你和 AI 协作时的安全绳。AI 改乱了，Git 能让你知道改了什么，也能回到上一个稳定点。
一个完整任务示例
假设你要给“实验记录系统”增加导出 CSV 功能。
不要这样说：
1
帮我加一个导出功能。
可以这样做：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Explore：
请先阅读项目，找出实验记录列表的数据来源、接口和页面组件，不要修改文件。
Plan：
请设计“导出当前筛选结果为 CSV”的最小实现方案，说明涉及文件和验证方式。
Implement：
请只实现后端导出接口，沿用现有查询条件，不改前端。
Verify：
请给出 curl 验证命令，并说明如何确认 CSV 表头和行数正确。
Review：
请检查当前 diff，重点看是否有无关改动、编码问题和大数据量风险。
Commit：
我确认后再提交。
这就是从一句模糊需求到可提交代码的过程。每一步都可检查，每一步都能停下来。
常见失败模式
第一种失败是“跳过 Explore”。AI 没读项目就开始写，结果目录结构、命名风格、接口约定全都对不上。
第二种失败是“计划太大”。一个计划里包含十几个功能，AI 一次改几十个文件，最后你不知道哪里出了问题。
第三种失败是“没有验证”。代码能生成不代表能运行，能运行不代表正确。
第四种失败是“只看结果不看 diff”。页面看起来好了，但 AI 可能改坏了旧逻辑。
第五种失败是“没有提交节点”。项目一旦乱了，只能靠回忆找问题。
这些失败都可以通过六步闭环缓解。
本篇 Checklist
- 我是否让 AI 先探索项目，而不是直接写代码？
- 我是否要求 AI 先给计划，并列出涉及文件？
- 我是否把实现拆成小步？
- 我是否运行测试或完成手动验证？
- 我是否审查 diff，确认没有无关改动？
- 我是否在稳定状态提交 Git？
参考资料
- Vibe Coding Best Practices - roadmap.sh
- Claude Code: Best practices for agentic coding
- Vibe Coding AI 工作流指南 2026
- 别再说 AI 编程就是 Vibe Coding 了！6 种主流模式一次讲清
修改记录
- 新增 Vibe Coding 工程闭环文章。
