AI 编程工具越来越强，很多人开始用 Cursor、Claude Code、Codex、Trae 等工具做所谓的 Vibe Coding。

有些人用得很顺：需求拆得快，代码落得快，测试也能补上。

但也有不少人用得很痛苦：AI 改着改着把项目搞乱了，功能看似完成，实际一跑全是问题，最后还得自己一点点排雷。

问题不一定出在模型不够强，也不完全是 Prompt 写得不好。

更大的差距在于：你有没有把 AI 拉回正常的软件工程流程里。

Vibe Coding 不是闭眼让 AI 狂写代码。短期做原型可以大胆一点，先把东西跑起来；但只要代码要长期维护，Git、测试、Review、需求边界这些基本功就不能丢。

1. Git 是底线，不是可选项

用 AI 写代码，第一件事不是开写，而是确认 Git 状态。

AI 改代码很快，也意味着它改坏代码同样很快。如果没有版本控制，出了问题很难回到干净状态。

建议做到：

  - 每个功能单独开分支

  - 小步提交

  - 一个提交只解决一个明确问题

  - 不要让 AI 直接在主分支上大改

  - 改动前先看 git status

AI 适合快速试错，但 Git 是兜底机制。没有 Git 的 Vibe Coding，本质上是在裸奔。

2. 动手前，先检查工作区

让 AI 开始写代码之前，先让它看当前工作区状态。

尤其要确认：

  - 是否有未提交改动

  - 当前在哪个分支

  - 这些改动是不是用户手写的

  - 是否需要先新建分支

  - 是否存在生成文件、临时文件、未跟踪文件

很多翻车不是因为 AI 不会写代码，而是它在一个已经很乱的工作区里继续改，最后你分不清哪些是原来的问题，哪些是 AI 新引入的问题。

一个好的习惯是：每次让 AI 接手前，先让它执行一次工作区检查，并说明它准备改哪些文件。

3. 需求不要只写一句话

不要只对 AI 说：

  > 帮我实现一个订单导出功能。

这类需求太模糊，AI 只能靠猜。它可能猜错字段、权限、分页、异常处理、导出格式、数量限制，甚至猜错业务含义。

更好的方式是先写清楚：

  - 目标是什么

  - 输入是什么

  - 输出是什么

  - 权限怎么控制

  - 数据量限制是多少

  - 失败时怎么处理

  - 是否需要兼容历史逻辑

  - 验收标准是什么

  - 哪些地方不能改

如果自己一时写不清，可以先让强模型帮你把需求整理成 Spec，再让编码模型实现。

需求越清楚，AI 越不容易自由发挥。

4. 让 AI 参考项目里的好代码

  不要只说：

  > 代码写优雅一点。

  > 按项目规范来。

  > 注意架构设计。

这些话对 AI 来说都太抽象。

更有效的方式是直接告诉它：

  - 参考哪个 Controller

  - 参考哪个 Service

  - 参考哪个测试类

  - 参考哪个异常处理方式

  - 参考哪个 DTO / VO 命名风格

  - 参考哪个前端页面结构

比如：

  > 新增接口时，参考 UserController 的参数校验和返回格式。

  > Service 层参考 OrderServiceImpl 的事务处理方式。

  > 测试参考 PaymentServiceTest 的写法。

AI 最擅长模仿上下文。给它看项目里的好代码，比空泛地要求“写得好一点”有效得多。

5. 把项目坑点写进规则文件

很多项目都有自己的坑：

  - 某些目录不能改

  - 某些接口不能破坏兼容

  - DTO 不能直接复用 Entity

  - 数据库迁移必须单独确认

  - 日志不能打印敏感信息

  - 前端不能引入新的 UI 库

  - 测试必须走固定命令

这些内容不要每次靠聊天提醒，可以写进规则文件里。

例如：

  - CLAUDE.md

  - AGENTS.md

  - Cursor Rules

  - Codex instructions

  - 项目内的开发规范文档

规则文件不要写成大而全的团队手册。重点放 AI 容易犯错、但团队又必须遵守的规则。

规则越具体，越有用。

6. 重复流程沉淀成 Skill

有些工作流程会反复出现：

  - TDD

  - 代码审查

  - 前端视觉检查

  - 性能分析

  - 网页资料调研

  - GitHub PR 评论处理

  - CI 失败排查

如果每次都靠聊天重新提醒，效率很低，也容易漏步骤。

更好的做法是把固定流程沉淀成 Skill、脚本、模板或检查清单。

比如代码审查可以固定要求：

  - 先看 diff

  - 按严重程度列问题

  - 关注 bug、回归风险、测试缺口

  - 不做无关重构建议

前端检查可以固定要求：

  - 启动本地服务

  - 打开页面

  - 截图验证

  - 检查移动端

  - 确认无文字重叠和布局错位

把流程固化下来，AI 的输出会稳定很多。

7. 贵模型不要拿来搬砖

不同模型适合做不同的事。

强模型更适合：

  - 梳理需求

  - 拆任务

  - 做架构判断

  - 发现风险

  - Review diff

  - 分析复杂 bug

便宜模型或普通模型更适合：

  - 按明确任务写代码

  - 补测试

  - 改样式

  - 做机械性重构

  - 根据已有模式补文件

不要所有事情都用最贵模型硬跑，也不要让弱模型做高层设计判断。

比较实用的方式是：

  > 强模型定方向，普通模型干活，最后再让强模型 Review。

这样成本和质量会更平衡。

8. AI 说修好了，不代表真的修好了

AI 很容易说：

  > 已修复。

  > 已完成。

  > 现在可以正常工作。

但工程上不能只看它怎么说，要看证据。

至少要看：

  - 测试是否跑过

  - 命令输出是什么

  - diff 改了哪些文件

  - 是否覆盖了异常场景

  - 是否引入了新的依赖

  - 是否改到了无关代码

如果是性能优化，还要看：

  - 优化前后耗时

  - SQL EXPLAIN

  - 压测数据

  - 缓存命中率

  - CPU / 内存变化

如果涉及敏感操作，更不能让 AI 自动决定：

  - 删除文件

  - 数据库迁移

  - 推送代码

  - 修改密钥

  - 生产配置

  - 批量替换

  - 重置 Git 历史

AI 可以建议，但关键操作必须人工确认。

9. 一个会话不要塞太多任务

AI 上下文再长，也不适合无限塞任务。

一个会话里同时做需求分析、写后端、改前端、补测试、调 CI、写文档，很容易失控。上下文越长，AI 越容易遗漏约束，甚至混淆前后任务。

建议按阶段拆开：

  - 一个会话只做一个明确目标

  - 长任务写 NOTES.md 或任务记录

  - 每完成一个阶段就提交一次

  - 新会话接手时先读记录和 Git diff

  - 不要让 AI 靠记忆续命

可维护的 AI 编码流程，应该允许随时换会话、换模型、换人接手。

10. 多 Agent 先串行，再并行

多 Agent 很诱人。

一个写后端，一个写前端，一个补测试，一个做 Review，看起来效率很高。

但前提是你的单 Agent 流程已经稳定。

如果单 Agent 都经常翻车，直接上多 Agent，只会把问题放大。多个 Agent 同时改代码，很容易出现冲突、重复实现、风格不一致、互相覆盖。

更合理的顺序是：

  1. 先把单 Agent 流程跑顺。

  2. 再把任务拆成清晰边界。

  3. 先串行执行，确认交接稳定。

  4. 最后再考虑 worktree 并行、多 Agent 并发、专项 subagent。

subagent 很适合做独立任务，比如：

  - 只做代码审查

  - 只分析测试失败

  - 只查资料

  - 只检查前端页面

  - 只做性能瓶颈分析

不要一开始就追求复杂编排。流程稳定，比 Agent 数量更重要。

总结

同样是 Vibe Coding，有人又快又稳，有人频繁翻车，差距不只是 Prompt，也不只是模型。

真正的差距在工程流程。

AI 写代码越快，越需要这些东西兜底：

  - Git

  - 测试

  - Review

  - Spec

  - 小步提交

  - 清晰边界

  - 可验证结果

  - 可回滚机制

以前这些流程主要是用来约束人。

现在，它们也顺手约束一下 AI。

短期做原型，可以让 AI 更自由一点，快速试错、快速验证。但只要代码要长期维护，就不能把 AI 当成一个随便发挥的代码生成器。

更好的方式是把 AI 当成一个执行力很强、但需要明确边界和验收标准的工程协作者。

让它写代码之前，先把上下文给清楚。

让它写完之后，再用测试、diff 和 Review 验证结果。

这样 Vibe Coding 才不只是“感觉来了就写”，而是能真正进入生产级开发流程。