一、什么是 Vibe Coding？
Vibe Coding 是一种以自然语言为主要交互方式的开发模式。开发者通过描述需求，让 AI 协助完成代码编写、功能修改、问题排查和测试验证。
与传统开发相比，Vibe Coding 降低了编写代码的门槛，让开发者能够更专注于需求分析、功能设计和最终结果。但这并不意味着只需要告诉 AI 自己想做什么，就能得到可靠的软件。
如果缺少清晰的需求、合理的项目规划和有效的验证机制，AI 也可能出现理解偏差、重复修改、引入无关代码等问题。项目越复杂，这些问题就越明显。
因此，Vibe Coding 的重点不是让 AI 写出更多代码，而是建立一套能够持续理解项目、执行任务并验证结果的协作方式。
二、从项目规划到分阶段开发
1. 开始写代码之前，先明确需求
面对一个新项目，不建议一开始就要求 AI 直接生成完整系统。
更合适的做法是先明确项目目标、用户角色、核心功能、技术栈和约束条件，再让 AI 协助梳理需求。
例如，准备开发一个简单的商品管理系统，可以先向 AI IDE 提出以下要求：
示例：项目需求讨论提示词
我准备开发一个简单的商品管理系统。
目前先不要编写代码，请协助我完成项目规划。
需要完成：
1. 梳理核心功能与用户操作流程。
2. 分析必要的数据表和字段。
3. 推荐符合项目规模的技术方案。
4. 列出主要开发阶段及每个阶段的验收标准。
5. 指出尚未明确的需求和潜在风险。
约束：
- 优先采用简单、成熟的实现方式。
- 不引入当前需求不需要的复杂架构。
- 不确定的内容先提出问题，不要自行假设。通过这种方式，可以先获得一份可讨论、可修改的项目方案，再决定具体实现方式。
需求尚未明确时，让 AI 先提问，通常比让它直接猜测更有效。
2. 将大任务拆分为可验证的小任务
项目规划完成后，应当将开发过程拆分为多个阶段，例如：
项目初始化与基础配置。
数据库设计与基础数据访问。
核心业务功能开发。
前端页面与交互实现。
异常处理与测试验证。
部署和文档整理。
每个阶段都应当有明确的完成标准，而不是简单地以"代码已经生成"为依据。
例如，开发商品新增功能时，可以要求 AI 完成接口、数据校验和必要测试，并确认接口能够正常运行后，再继续开发商品编辑功能。
这种方式能够限制单次修改的范围。当某个功能出现问题时，也更容易定位原因，避免一次性修改大量代码后难以排查。
3. 技术调研与方案选择
AI 可以帮助开发者了解技术方案、比较框架和查找潜在问题，但不应直接将模型生成的内容当作最终结论。
对于版本、API、依赖配置等容易变化的内容，应优先参考官方文档，并通过实际运行验证。
例如，在使用 Spring AI 接入大模型时，可以先确认模型服务商的 API 兼容性、依赖版本、请求格式和返回结构，再编写调用代码。
如果项目中已经存在成熟的技术方案，也不必为了使用新技术而重新设计整个系统。对小型项目而言，减少不必要的依赖和架构复杂度，往往比追求技术新颖更重要。
三、AI IDE：让 AI 更好地理解项目
AI IDE 将大模型能力融入开发环境，除了代码补全，还可以帮助开发者理解代码库、修改多个文件、执行命令、排查问题和运行测试。
Cursor、Trae 等工具都可以作为 AI 辅助编程的实践入口。不同产品在模型选择、上下文管理、工具调用和交互方式等方面有所区别，但高效使用它们有一个共同前提：让 AI 获得完成当前任务所必需的上下文，并明确本次开发的目标和边界。
1. 为项目建立稳定的规则
如果每次开发都要重新解释项目技术栈、代码风格和实现原则，不仅浪费时间，也容易产生不一致的结果。
可以在项目中建立规则文件，用于记录 AI 开发时需要遵守的核心约束。例如，部分支持相关约定的编程工具可以使用 AGENTS.md。具体文件名、作用范围和加载方式应以所使用工具的实际支持为准。
示例：项目开发规则
# 项目开发规则
## 基本原则
- 优先采用最简单、清晰、可维护的实现方式。
- 修改前先理解现有代码，不要直接重写已有模块。
- 严格控制修改范围，不顺手修改无关代码。
- 不添加当前需求不需要的依赖和抽象层。
## 开发流程
- 需求不明确时，先提出必要的问题。
- 涉及多个模块时，先说明计划和影响范围。
- 完成修改后，运行相关测试或构建检查。
- 无法验证的内容必须明确说明，不得声称已经通过。
## 代码约束
- 优先复用已有工具类和业务逻辑。
- 保持现有项目的命名与代码风格。
- 不擅自修改配置、数据库结构或公开接口。
- 不将密钥写入代码或提交记录。项目规则不需要写得很长。重点是让 AI 始终遵守少量关键约束，而不是将所有开发知识都塞进一个文件。
规则也不是越多越好。如果同一要求在多个文件中重复出现，或者不同规则之间存在冲突，反而会增加维护成本。
2. 将项目背景与当前任务分开管理
除了开发规则，还可以根据项目规模，将项目说明、技术决策和当前进度分别记录。
| 文件 | 主要用途 |
|---|---|
AGENTS.md |
记录稳定的开发规则与约束 |
README.md |
说明项目目标、技术栈和启动方法 |
DECISIONS.md |
记录重要技术决策及其原因 |
NOW.md |
记录当前进度、待办事项和已知问题 |
这些文件只是可选的组织方式，并非所有项目都需要全部创建。小型项目可以从 README.md 和一份简短的开发规则开始，只有在上下文管理确实出现问题时再增加文件。
例如，项目开发到一半需要切换会话，可以在 NOW.md 中记录：
# 当前开发状态
## 已完成
- 完成商品表设计。
- 完成商品查询接口。
- 完成商品新增接口。
## 当前任务
- 修复商品编辑接口的参数校验问题。
## 待办
- 补充商品删除功能。
- 增加相关接口测试。
## 已知问题
- 商品名称不能为空。
- 商品库存必须大于或等于 0。
## 验证情况
- 最近一次构建成功。
- 商品编辑接口的异常场景尚未验证。这样，即使更换 AI 会话，也可以快速恢复项目状态，不必每次重新解释全部背景。
需要注意，项目状态文件应当及时更新。过期的信息可能会误导 AI，因此不能将其当作绝对准确的事实来源。
3. 明确任务边界，减少无效修改
项目规则负责说明长期有效的约束，具体任务则应明确本次要解决的问题、允许修改的范围和验收标准。
例如，修复商品编辑接口时，可以使用以下提示词：
示例：AI IDE 开发任务
请先阅读项目开发规则、README 和相关业务代码，
理解当前项目结构后再开始修改。
当前任务：修复商品编辑接口的参数校验问题。
要求：
1. 先定位接口、DTO 和相关校验逻辑。
2. 说明问题原因及计划修改的文件。
3. 仅修改完成当前任务所必需的代码。
4. 沿用现有项目结构，不引入新的依赖。
5. 修改后运行相关测试；条件允许时执行构建。
6. 最后总结修改内容、验证结果和未解决的问题。
不要重写整个模块，也不要顺手修改无关功能。这类提示词的作用，是明确 AI 的工作边界、执行顺序和验收要求。
对于简单任务，可以直接要求 AI 定位并修复；对于涉及多个模块或存在较高风险的任务，则适合先分析方案，确认后再执行。
4. 建立从修改到验证的闭环
AI 生成代码不代表任务已经完成。开发者还需要确认修改是否真正解决问题，有没有引入新的错误。
一个基本的开发闭环包括：
分析问题： 阅读相关代码，明确问题原因。
实施修改： 只修改当前任务需要的部分。
运行验证： 执行相关测试、构建或接口检查。
检查结果： 确认功能符合预期，并检查潜在副作用。
记录状态： 汇报修改内容、验证结果和遗留问题。
例如，修改数据处理脚本时，不应只检查 AI 是否生成了代码，还需要确认输入文件是否正确读取、异常数据是否得到处理、输出字段是否符合要求，以及实际处理结果是否经过验证。
如果测试失败，应让 AI 根据具体错误信息继续定位，而不是直接接受它生成的修复方案。
这也是 AI IDE 提高开发效率的关键：缩短从理解需求到验证结果的反馈周期，而不是单纯增加代码生成速度。
四、从 AI IDE 到更复杂的自动化开发
当 AI 不再只是辅助编写代码，而是需要围绕一个目标持续读取文件、调用工具、执行命令并根据结果调整方案时，就可以进一步探索更复杂的 AI 编程方式。
在已有的 AI 技术概念中，Agent 关注围绕目标进行推理和行动。具备相应能力的编程系统可以将一个任务拆分为多个步骤，调用工具执行操作，并根据反馈继续推进。
例如，面对一个 Python 数据处理任务，系统可能先分析现有脚本，再修改数据清洗逻辑、运行测试，并根据结果继续排查问题。
但这并不意味着所有开发任务都需要 Agent。对于简单、规则明确的修改，直接使用 AI IDE 往往更简单，也更容易控制。只有当任务需要多个步骤协同执行，或需要反复调用工具时，才有必要考虑更复杂的自动化方式。
Harness：从辅助开发走向可控执行
当 AI 需要持续调用工具、处理执行结果并完成多步骤任务时，除了模型本身，还需要相应的运行与管理机制。这类机制通常可以从 Harness 的角度进行理解。
Harness 可以帮助组织上下文、工具调用、任务执行和结果反馈等环节。它的具体实现方式取决于所使用的产品和技术框架。
不过，Harness 并不是 Vibe Coding 的必备条件。对于一般开发任务，清晰的项目规则、合理的任务拆分和有效的测试验证，已经能够解决许多常见问题。
当项目规模增大、任务执行过程变得复杂，或者需要更精细地管理工具权限、执行步骤和错误恢复时，再深入研究 Harness 会更有价值。
本篇只需要建立这一认识：先掌握 AI IDE 的有效使用方法，再根据实际开发需求逐步引入更复杂的执行机制。Harness 的具体配置、上下文优化与工程化实践，可以留给后续专题展开。
五、优化开发流程，减少 Token 消耗与返工
使用 AI 编程工具时，效率不只取决于模型的生成速度，还取决于任务是否明确、上下文是否必要，以及执行结果能否被有效验证。
1. 避免重复提供相同背景
稳定的项目约束放在规则文件中，项目事实写入说明文档，当前任务只描述本次要解决的问题。
不要在每轮对话中反复粘贴完整项目介绍，也不要将所有历史对话都当作当前任务必需的上下文。
2. 按需读取资料
修改某个接口时，优先读取相关控制器、业务服务、数据对象和测试文件，而不是无差别读取整个代码库。
需要调查全局影响时，再扩大检索范围。这样既可以减少无关信息，也能让 AI 更专注于当前任务。
3. 减少无效的反复修改
对于复杂任务，让 AI 在开始前先定位问题和说明计划。
对于简单、明确的任务，不必强制增加复杂的规划环节；对于涉及数据库迁移、多个模块或关键接口的任务，则应提高分析和确认要求。
4. 明确验收标准
例如，"修复接口"不如"修复接口参数校验，并通过正常输入、缺失参数和非法参数的测试"明确。
验收标准越清晰，AI 越容易判断任务是否真正完成，也越不容易陷入反复试错。
5. 只保留有价值的任务记录
完成任务后，只需要记录实际修改、验证结果、遗留问题和下一步任务。
无需每次都生成冗长的过程复盘。项目文档也应定期清理，避免过期信息干扰后续开发。
Token 优化并不等于一味压缩提示词。过度删减规则可能导致理解偏差和返工，最终反而增加总消耗。更值得优化的是无关上下文、重复操作和低质量的执行循环。
六、建立适合自己的 Vibe Coding 工作方式
综合来看，可以将日常开发整理为以下几个阶段。
1. 规划阶段
明确项目目标、功能范围、技术栈和验收标准。让 AI 协助分析问题，但由开发者决定最终方案。
2. 准备阶段
建立必要的项目规则和说明文档，确认运行环境、依赖和现有代码结构。
3. 开发阶段
使用 AI IDE 按照小任务逐步实现。简单任务直接执行，复杂任务先分析再修改。
4. 验证阶段
通过测试、构建、接口调用或实际操作验证结果。AI 的文字说明不能替代真实验证。
5. 维护阶段
记录关键决策、当前进度和遗留问题。定期更新项目文档，清理不再适用的规则，并根据实际需要完善开发流程。
整个过程不需要一开始就引入复杂的 Agent 架构。对于简单项目，一份清晰的需求说明和少量开发规则就可能足够；当项目逐渐复杂、重复任务增多、上下文管理成为瓶颈时，再逐步引入更完善的自动化机制。
七、结语
Vibe Coding 并不是简单地让 AI 代替开发者编写代码，而是重新组织需求分析、代码实现和结果验证之间的关系。
AI IDE 提供了便捷的开发交互，项目规则与文档帮助 AI 保持上下文一致，任务拆分和测试验证则让开发过程更加可控。
对于个人开发者而言，不必追求一次性搭建最复杂的开发体系。先从明确需求、限制修改范围、及时验证结果开始，再根据实际遇到的问题逐步优化。
真正高效的 Vibe Coding，不是让 AI 做更多事情，而是让 AI 用更少的无效操作，稳定地完成正确的事情。