前言
大家好，我是 Mark。 如果你已经跟着入门指南，做出了自己的第一个小产品，你大概率会进入一个新的阶段。 刚开始的时候，这种体验很让人兴奋。脑子里冒出一个想法，告诉 AI，它就能帮你生成页面、补功能、调整样式，甚至帮你部署上线。 但越往后，你大概率会发现几个问题：
- 只是想改一个小地方，结果别的功能也坏了
- 聊天轮次越聊越多，AI 开始“变笨”
- 功能越加越多，页面也越来越乱，代码也越来越不好改这其实很正常。 因为在入门阶段，最重要的事情是先把东西做出来。 到了进阶阶段，更关键的问题就在于怎么把东西做得更稳、更可控，更接近真正的开发流程。
本篇文章，我会结合自己在 Vibe Coding 过程中的一些经验和实用技巧，和你聊聊如何从“能做出来”，到“能持续做好”。
一、理解真相
很多同学在初期以为，Vibe Coding 的进阶，就是把 prompt 写得更长、更复杂，其实不然。
真正的分水岭在于：
初级阶段，把 AI 当成代码生成器。
进阶阶段，则需要你在思想上转变，把 AI 当成你的协作对象。
这两种思想看起来只差一点，但实际效果会差很多。
前者是：我想要什么，你直接写出来。
后者是：你先理解问题，再给出方案、说明范围、执行修改并验证结果。也就是说，进阶的关键，在于让 AI 具备清晰的边界、明确的步骤，以及持续的反馈机制。 这也就是为什么越往后做，越不能只靠“想到什么就说什么”。 当项目变的复杂，影响结果的因素，通常会集中在下面这些方面：
- 你有没有把问题说清楚
- 你有没有把范围限制住
- 你有没有给出明确的验收标准
- 你有没有在每一轮之后及时检查和纠偏简单来说，入门是在体验 AI 的速度，进阶则是在建立自己的范式。
二、学会把需求说清楚
回顾你刚开始用 AI 写代码的提问方式，大概率会发现每次提问都很模糊。比如：
- 帮我做一个登录功能
- 帮我优化一下这个页面
- 帮我重构这个页面
- 这个地方不太对，你改一下这种说法在项目刚开始时问题不大，因为项目还没到一定体量，代码功能通常不会很复杂。随着项目越往后，这种表达方式的风险就会被迅速放大。因为 AI 不知道，你真正想解决的问题是什么、功能添加到哪个页面、哪些文件允许改，哪些不能改、这轮任务的完成标准是什么。
本节中，笔者将分享一些把需求讲清楚的技巧。
1. 先说目标，再说范围
正确的表达顺序，应该是：
先说你想达到什么结果，再说这轮允许动哪里，不允许动哪里。
比如，不要只说：
帮我做一个登录功能
而要说：
目标：新增一个登录页面，用户可以使用邮箱和密码登录。
这轮只实现登录页、表单校验、调用登录接口、登录成功后跳转控制台页面。
不要修改其它页面。这样说你大概率会发现，AI 比之前能稳定很多。原因也很简单，你不只是给 AI “方向”，还给它“施工边界”。
2. 每次只推进一个目标
这一点很多同学都喜欢，笔者也不例外(dog)，那就是喜欢把一堆需求一起说完，觉得这样更高效。 比如：
帮我在登录页面加个深色模式，然后把设置页面中的保存按钮改为圆角矩形，还需要检查一下设置页面点击保存按钮无法将数据存到数据库的问题。站在人的角度看，像是在一次性把想法交代完整。但对 AI 来说，这实际上是把多个任务糊在一起。
- 功能新增
- 样式优化
- 逻辑调整结果往往都是每件事都碰了一点，但没有一件事做得特别稳。
那怎么办呢？更好的方式是拆开来：
- 第一轮，只做深色模式
- 第二轮，只做样式优化
- 第三轮，只检查数据无法写入库的逻辑这样看起来是慢了很多，但实际上会更快，因为返工更少。
3. 不要急着让 AI 写，先让它复述理解
笔者强烈建议大家养成这个习惯，正式开工前，可以先让 AI 做一件事：
先不要写代码
请复述你对需求的理解，列出本次要改的内容、不能动的部分、潜在风险和实现步骤。这样做有三个明显的好处：
1. 可以提前发现理解偏差。
2. 可以避免它一上来就写歪。
3. 可以把对话从“聊天”转成“施工前确认”。很多问题并非出在实现阶段，根源往往在一开始的理解就发生了偏差。 所以进阶阶段非常重要的一件事，就是先确认理解，再开始执行。
三、定义“什么叫做完成”
在刚开始接触 Vibe Coding 最常见的判断标准只有一个跑起来了。
这固然重要，但到了正式开发阶段，这个标准就远远不够。因为有很多代码虽然能跑，但并不代表它真的“完成”了。
因为你并不知道 AI 会给你埋一些什么雷。比如：
- 结构混乱，后面很难改
- 没有考虑边界情况
- 只是表面正常，深层逻辑还有 Bug
- 改好了当前问题，却破坏了别的功能
- 没有任何验证手段，只能靠感觉所以本节的进阶关键，就是开始定义到底什么才算“做好了”。
1. 明确成功标准
不要只是简单的说：
修复数据无法写入数据库的问题
而要尽量补全你的标准，比如：
修复数据无法写入数据库的问题，要求：
- 原有功能保持不变
- 如果没有测试用例，补一个最小验证用例
- 不允许通过删除功能规避问题
- 完成后给出建议测试项这样说，AI 的目标会从单纯生成代码，转向生成能够通过验收标准的代码。
2. 明确完成证据
这一步可能大多数同学都没用到过，但却是非常关键的一步。很多同学让 AI 改完一轮代码后，只看“结果能不能跑”， 但在 Vibe Coding 里，相比“它改完了”这个结果，你更需要始终清楚：
- 这一轮到底改了什么
- 为什么这样改
- 影响到了哪些地方
- 还有哪些风险没有验证所以更好的做法是，每完成一轮修改，都要求 AI 同步更新 TASKS.md。
# TASKS.md
## Now
- [ ] [当前任务 1]
- [ ] [当前任务 2]
## Constraints
- 不允许删除功能绕过问题
- 优先最小修改
- 修改后说明影响范围
- 修改后给出建议测试项
## Notes
- [关键背景 / 报错 / 假设]
## Done
- [x] [已完成项]
## Change Log
- [日期] [本轮做了什么，当前还差什么]当然，这里的更新只需要补充关键信息，不需要写成长篇报告。
Now：更新当前还要继续做的事Done：勾掉已经完成的项Change Log：补一条简短的修改说明- 必要时补充
Notes：记录新的报错、假设或背景信息 这样做的好处是，你可以随时从TASKS.md看出每轮 AI 都干了什么，从而对整个任务过程有更强的掌控感。
四、学会控制 AI
很多同学一开始用 AI 写代码，最大的问题不是它不会写，而是它越写越偏。比如：
- 只想改一个按钮，结果它顺手改了整个页面
- 只想修一个 Bug，结果它顺带重构了很多代码
- 本来只做当前需求，结果它擅自补了很多“自认为合理”的优化所以本章节笔者将分享如何主动约束 AI 的行为。 但这里要注意一点，想控制 AI，首先要把它工作的上下文、目标和边界搭清楚，而不是把精力耗在反复提醒上。
1. 先明确目标
在正式开发前，先明确自己到底要做什么。
- 想解决什么问题？
- 做出来的东西是什么样？
- 给谁用？
- 第一版要做到什么程度？就比如你想开发一个番茄时钟应用，那你至少要先想清楚：
- 这是给自己用，还是给别人用
- 是做 APP、小程序，还是网页
- 第一版最核心的功能是什么
- 哪些功能现在必须有，哪些可以以后再加这时就有同学要问了：“为什么要有这一步呢？” 因为如果连你自己都没想清楚，AI 大概率也只能边猜边写，最后越做越偏。
2. 调研类似应用
当目标初步明确之后，可以再去看一看市面上有没有类似的应用。调研类似产品的价值，在于帮助你进一步想清楚自己的方向。
- 它们通常都有哪些功能
- 哪些功能看起来很多，但未必适合你的第一版
- 它们的界面风格大概是什么样
- 有没有哪些交互方式值得参考调研这步你可以自己去查，也可以直接让 AI 帮你做一轮基础调研。比如可以直接问：
有哪些比较好的番茄时钟应用？
它们通常有哪些核心功能？
常见的界面风格和交互方式是什么？
如果我只做第一版，哪些功能最值得优先保留？调研的目的，是帮助你收敛需求、明确重点，从而形成更适合的第一版方案。
3. 把调研结果记录下来
当你有了一些初步想法和调研结论后，最好把这些内容记录下来。可以创建一个简单的文档，比如 RESEARCH.md，这个文档不需要很正式，它的作用只是帮你把前期想法沉淀下来，方便后面让 AI 基于这些信息继续往下整理。
# 番茄应用研究报告
## 目标
开发一款简单的番茄应用，用于帮助用户进行专注计时与任务节奏管理。
## 核心需求
1. 小程序版
2. 支持开始专注
3. 支持暂停
4. 支持继续计时
5. 支持短休息计时
6. 能看到当前剩余时间调研文档不用写得太复杂，只要能把你的想法、方向和初步判断记下来就可以。
4. 整理产品需求文档（PRD.md）
有了研究报告后，你对自己要做的东西就会有一个更清晰的认知。接下来要做的，就是把这些想法继续整理成一份更正式的需求文档，也就是 PRD.md。
很多同学会觉得自己不是产品经理，写不来什么正式 PRD。
但在 Vibe Coding 里，你并不需要一份特别重的传统需求文档。你只需要先把关键内容写清楚，比如：
- 产品概述
- 目标用户
- 核心功能列表
- 功能优先级
- 技术栈建议
- 代码风格和架构模式
- 限制条件和边界场景如果你不想从零开始写，也可以直接把前面的研究报告交给 AI，让它先帮你扩展出一版轻量 PRD。比如可以这样说：
请基于这份研究记录，帮我整理成一份轻量版 PRD。
要求包含：
- 产品概述
- 目标用户
- 核心功能列表
- 功能优先级
- 技术栈建议
- 代码风格和架构模式
- 限制条件和边界场景
尽量写得清晰、结构化，但不要太冗长。
# 番茄应用研究报告
## 目标
开发一款简单的番茄应用，用于帮助用户进行专注计时与任务节奏管理。
## 核心需求
1. 小程序版
2. 支持开始专注
3. 支持暂停
4. 支持继续计时
5. 支持短休息计时
6. 能看到当前剩余时间AI 生成出来之后，你再根据自己的需求做删减和修正就可以。
这步的核心，是借助 AI 把原本模糊的想法整理成更清晰的需求边界。
5. 整理技术设计文档（DESIGN.md）
有了需求文档，我们就知道“要做什么”了，接下来还需要进一步明确：准备怎么做。
这时候就可以创建 DESIGN.md，用来记录技术实现方案。这步的作用，是把需求继续落到实现层，否则 AI 很容易一边写一边想，最后虽然功能能跑，但整体结构会比较乱，后面也不好迭代。
一个简单的 DESIGN.md，可以包含这些内容：
- 技术栈
- 项目结构
- 模块设计
- 接口设计
- 数据模型
- 状态管理
- 关键流程
- 异常处理这步同样可以先让 AI 帮你起草，比如你可以这样说：
基于 PRD 中的需求，给我整理一份技术设计文档。
需要包含：
- 技术栈
- 项目结构
- 模块设计
- 接口设计
- 数据模型
- 状态管理
- 关键流程
- 异常处理
这样整理出来之后，你就会发现项目从“一个想法”，开始真正变成一个可施工的开发任务了。
6. 编写 AI 协作规范（AGENTS.md）
当需求文档和技术设计文档都有了之后，最后还可以再补一份专门给 AI 看的协作规范文档，也就是 AGENTS.md。它本质上可以理解成给 AI 看的 README。
它不是一次性的提示词，也不是某一轮任务里的临时命令，而是一份长期生效的项目协作规则。主要解决的是：AI 在这个项目里应该怎么工作。
通常会包含以下内容：
- 项目说明
- 命令说明
- 编码约束
- 范围边界
- 测试要求
- 交付格式以番茄专注应用为例，结合前面的 PRD 和 DESIGN 文档，可以写成这样：
# AGENTS.md
## 项目说明
这是一个微信小程序番茄专注应用，当前只做 MVP，重点实现专注计时、暂停/继续、短休息和结束提示。
## 命令说明
- 安装依赖：`npm install`
- 启动项目：使用微信开发者工具打开并运行
- 代码检查：按项目现有方式执行
## 编码约束
- 优先最小修改
- 不要重构无关代码
- 命名清晰
- 页面逻辑和计时逻辑分开
- 优先复用现有结构
## 范围边界
本轮只处理番茄钟核心流程。
不要擅自增加登录、数据统计、自定义时长、后端接口等功能。
## 测试要求
修改后至少检查：
- 能否正常开始专注
- 暂停 / 继续是否正常
- 倒计时结束是否有提示
- 是否能进入短休息
## 交付格式
修改完成后请说明：
- 改了哪些文件
- 做了什么修改
- 为什么这样改
- 可能影响哪些地方
- 建议如何测试
## 文档同步
每次完成修改后，必须同步更新 `TASKS.md`，包括：
- Now：下一步待做事项
- Done：本轮已完成内容
- Change Log：本轮修改说明有了这份文档，AI 的工作方式就会更稳定，也更容易持续遵循项目规则。到这里你会发现，真正有效的“控制 AI”，依赖的是清晰的项目信息和长期稳定的规则。这样做，也能减少在聊天框里反复补充提醒的成本。
五、正式进入开发阶段
到了这一步，项目目标、需求边界、技术方案和 AI 协作规则都已经准备好了。接下来，重点将从补充文档转入正式开发阶段。
但这里要注意，正式开发并不意味着一上来就让 AI 把整个项目一次性做完。
更稳的做法，通常是按照“先搭框架、再做核心功能、最后优化细节”的顺序，一步一步推进。
1. 生成基础框架
第一步先把项目的基础框架搭起来，不要急着追求功能完整。 这个阶段的目标很简单，先让项目能启动、能运行、结构基本合理。 你可以直接让 AI 根据前面准备好的文档，先完成初始化工作。比如：
请根据 PRD.md、DESIGN.md 和 AGENTS.md 的要求，先完成项目初始化和基础框架搭建。
先不要直接开始修改，请先说明：
1. 你准备创建哪些目录和文件
2. 为什么这样组织结构
3. 需要安装哪些依赖
4. 如何保证当前阶段项目可启动
确认思路后，再开始执行。
本轮只做：
1. 安装必要依赖
2. 创建基础目录结构
3. 配置开发环境
4. 创建基础页面和路由框架
5. 保证项目能够正常启动
注意：
- 当前阶段只搭基础框架，不实现完整业务功能
- 不要扩展无关模块
- 不要提前加入计时逻辑、设置功能、数据统计等内容
完成后请：
1. 说明创建或修改了哪些文件
2. 展示当前项目目录结构
3. 说明项目如何启动
4. 更新 TASKS.md，记录本轮已完成内容和下一步建议如果你本身有一定编程基础，其实这里也不一定非要让 AI 从零生成。直接使用脚手架、官方模板或者现成项目骨架，会更快也更稳。
2. 逐步实现核心功能
基础框架搭好后，就可以进入功能开发了。这一步更适合先跑通核心业务流程，再逐步补全其他功能。 笔者更推荐把项目拆成多个小功能，一个一个实现。 比如番茄专注应用可以这样拆分：
1. 实现首页基础界面
2. 实现专注计时开始功能
3. 实现暂停与继续功能
4. 实现专注结束提示
5. 实现短休息模式切换
6. 实现短休息计时流程
7. 实现前后台切换后的状态恢复
8. 实现基础设置项（如专注时长、休息时长）
9. 完善异常处理和边界场景
10. 补充基础测试与验证拆完之后，不要一次把这些功能全部丢给 AI，而是每一轮只推进一个功能点。 比如你可以这样说：
我要先实现首页基础界面。
请根据 PRD.md 和 DESIGN.md 中的要求，只完成这个部分。
不要扩展到计时逻辑、设置项或其它无关功能。 每完成一个功能，都建议让 AI 写单元测试。测试功能的正常性以及是否符合预期。 如果有问题，就继续基于当前这一轮对话修正，等当前问题收敛后，再进入下一阶段。
3. 优化实现细节
当核心业务流程已经跑通之后，再优化实现细节。这时候再去处理：
- 界面样式优化
- 交互体验优化
- 性能改进
- 代码结构整理
- 可维护性提升这样顺序会更合理，如果一上来就花很多精力去做视觉和细节优化，前面的核心功能都还没稳定后面一旦逻辑改动，还得重做一遍，成本反而更高。
所以这里有一个很重要的原则：先保证能用，再追求好用，最后再追求好看。
当你把核心功能跑通，并且把细节打磨到基本可交付的程度时，这个项目的 MVP（最小可行产品）就算完成了。
另外，到了这个阶段，强烈建议开始使用 Git 管理代码。
比较稳的做法是初始化项目后提交一次、每完成一个独立功能提交一次、每完成一轮稳定优化再提交一次。这样即使某次修改出了问题，也能快速回退，不至于把前面的成果一起带崩。
六、结束
嗯~不知不觉已经写了近 1 万字，这篇 Vibe Coding 进阶指南也差不多告一段落了。
如果说入门篇更关注的是“怎么快速做出结果”， 那么进阶篇更关注的，其实是另一件事：
怎么让结果变得更稳定、更可控，并且能够持续迭代。
当你开始主动整理需求、明确边界、约束 AI、分步推进开发时，你其实已经不再只是“在用一个会写代码的工具”，而是在逐步建立自己的 AI 协作范式。
这也是 Vibe Coding 真正有价值的地方。
它不只是让开发变快，更重要的是，它开始帮助我们用一种全新的方式去组织需求、推进项目和完成产品。