Vibe Coding 实用笔记：让 AI 写代码更可控
Vibe Coding 不是“随便一句话让 AI 写代码”，更像是把 AI 放进正常的软件工程流程里，让它帮我们更快完成分析、编码、测试和 Review。
AI 写代码越快，越要把边界、证据和回滚方式想清楚。否则短时间看起来效率很高，后面很容易变成大量返工。
举个很常见的例子：
不太推荐：帮我做一个订单导出功能。
更推荐：请先阅读订单相关代码，只输出实现方案，不要修改文件。目标：新增订单导出接口，支持按时间范围筛选。限制：不要改数据库表结构，不要影响现有订单查询接口。验收：需要补单元测试，并说明要跑哪些命令验证。前者看起来省事，但 AI 很容易自己猜业务规则；后者多写了几行，却能明显减少跑偏。
1. 开始前先准备 Git
在让 AI 改代码之前，先确认当前工作区状态：
git statusgit diff如果是一个新的需求，最好单独开分支。这样 AI 改坏了，也能通过 diff、commit、revert 把影响范围控制住。
建议养成三个习惯：
- 每次只让 AI 处理一个清晰任务。
- 每完成一个小阶段就看 diff。
- 测试通过后再提交，不要把一堆不确定修改攒到最后。
比如我准备让 AI 改一块登录逻辑，会先这样做：
git statusgit checkout -b feature/login-token-refresh然后告诉 AI：
你可以修改登录刷新 Token 相关代码，但不要改注册、密码重置、用户资料接口。每次修改后先告诉我改了哪些文件，再继续下一步。这样即使中途发现方向不对，也可以很快退回到干净状态。
2. 先写清楚需求边界
Vibe Coding 最怕任务太宽，比如“帮我重构订单模块”“优化整个系统性能”。这种说法对人都不够清楚，对 AI 更容易跑偏。
更稳的方式是先写一份轻量 Spec：
## 目标
实现订单导出接口。
## 范围
- 支持按时间范围导出- 只导出当前登录用户有权限的数据- 不修改已有订单表结构
## 验收
- 新增单元测试- 导出结果字段顺序正确- 无权限用户不能导出他人订单Spec 不一定要长，关键是把“要做什么、不做什么、怎么验收”写清楚。
再比如“修复商品搜索慢”的需求，不要直接说“帮我优化搜索性能”。可以改成：
## 背景
商品列表在关键词搜索时响应较慢，接口平均耗时超过 2s。
## 目标
把 `/api/products/search` 在常见关键词下的响应时间降到 500ms 以内。
## 限制
- 不引入新的搜索中间件- 不改变接口返回字段- 不影响商品分类筛选逻辑
## 验收
- 给出慢查询原因- 补充索引或查询优化说明- 提供优化前后的验证方式这种写法会逼着 AI 先定位问题，而不是上来就大改代码。
3. 把项目规则告诉 AI
很多项目里的坑并不在代码里，而在团队约定里：
- 哪些接口要兼容老客户端。
- 哪些字段不能改名。
- 哪些目录不能随便动。
- 哪些命令可以执行，哪些必须人工确认。
- 提交前必须跑哪些测试。
这些规则不要每次聊天时临时补充，最好写进 AGENTS.md、CLAUDE.md、项目 README 或任务文档里。稳定的项目规则，比一长串临时 Prompt 更可靠。
一个简单的项目规则文件可以这样写：
# AI 开发规则
- 修改前先阅读相关代码，不要直接生成新架构。- 后端接口必须保持统一响应格式：`code`、`message`、`data`。- 不要修改 `.env`、生产配置、数据库迁移脚本。- 涉及登录、权限、支付的修改，完成后必须单独说明风险。- 提交前至少运行相关单元测试。以后每次让 AI 开工时，只要提醒它“先阅读项目规则文件”，就不用反复解释这些约定。
4. 让 AI 分阶段工作
比较稳的节奏是：
- 先让 AI 阅读代码并给出方案。
- 人确认方案和影响范围。
- 再让 AI 按小任务实现。
- 每完成一块就跑测试、看 diff。
- 最后让 AI 做一次 Review，人再看关键修改。
不要一上来就让 AI “直接改完”。方案不清楚时，AI 很可能会自己补设定，甚至把不该改的地方一起改掉。
我更喜欢这样拆任务：
第一步：只分析订单导出需要改哪些文件，不要写代码。第二步：只实现 Service 层逻辑，不要改 Controller。第三步：补 Controller 和 DTO。第四步：补测试并运行验证命令。第五步：总结 diff 和剩余风险。这种拆法看起来慢一点，但每一步都能停下来检查，适合长期维护的项目。
5. 不要只听 AI 说“修好了”
AI 说通过了不等于真的通过了。更可靠的判断来自证据：
- 测试命令是否真的执行过。
- 失败日志是否已经解释清楚。
- diff 是否只包含本次任务相关修改。
- 核心路径是否有测试覆盖。
- 页面或接口是否实际验证过。
一句好用的提示是：
请列出你执行过的验证命令、结果，以及还有哪些风险没有覆盖。也可以让 AI 用固定格式回复：
## 已验证
- `mvn test`：通过- `OrderExportServiceTest`：通过
## 未覆盖
- 没有连接真实数据库验证大数据量导出- 没有验证前端下载文件名展示
## 需要人工确认
- 导出字段顺序是否符合产品要求这样比一句“已经修好了”可靠得多。
6. 控制上下文，不要越聊越乱
上下文越长不一定越好。旧方案、失败尝试、过期日志混在一起，反而会让 AI 判断失真。
长任务里可以维护一份简单的 handoff：
## 已完成
- 修改了哪些文件- 跑过哪些测试- 已确认哪些问题不是 Bug
## 剩余任务
- 还没修的失败用例- 还没确认的边界场景- 下一轮需要先读哪些文件如果一个会话已经反复纠正很多次，不如开新会话，只带当前 Spec、相关文件、失败日志和下一步任务。
比如新会话可以这样开头：
当前任务：继续修复订单导出测试失败。
已完成：- 已实现 OrderExportService- 已新增 OrderExportController- 当前失败用例是 OrderExportServiceTest.shouldRejectOtherUserOrder
请先阅读：- src/main/java/.../OrderExportService.java- src/test/java/.../OrderExportServiceTest.java
要求：- 先解释失败原因- 不要改 Controller- 修复后运行这个单测这比把上一个会话几十轮聊天全部塞进去更清爽。
7. 多 Agent 先串行，再考虑并行
多 Agent 协作很有用，但不建议一开始就让多个 Agent 同时改代码。
更稳的方式是串行分工：
- Plan Agent：只读代码，输出方案。
- Code Agent：按任务实现。
- Test Agent：补测试并运行验证。
- Review Agent：只看 diff，指出风险。
并行开发真正危险的地方，不一定是 Git 冲突，而是两个修改都能合并，但业务语义已经互相破坏。所以并行前必须先明确任务边界、可改文件、验收命令和人工 Review 点。
举个坑：一个 Agent 为了“订单导出”给 OrderDTO 加了字段，另一个 Agent 为了“订单列表性能”删掉了几个字段。代码可能没有冲突，但前端列表和导出文件都可能悄悄变了。
所以并行前要把边界写死：
Agent A：只允许修改导出相关 Service、Controller、测试。Agent B：只允许修改订单列表查询 SQL 和对应测试。公共 DTO、数据库迁移、权限逻辑都不能改。8. 权限要收住
AI Coding 工具不仅会回答问题，还可能读文件、改代码、执行命令。权限控制不能只靠一句“请谨慎”。
建议把高风险操作放到人工确认或禁止列表里：
- 删除文件。
- 读取密钥、证书、生产环境配置。
- 执行数据库迁移。
- 推送远程分支。
- 修改 CI、权限、支付、登录、上传等关键模块。
低风险命令可以适当放开，比如 git diff、格式化、单元测试。高风险操作要靠权限规则、Hook、Sandbox、CI 和人工 Review 一起兜底。
我一般会把命令分成三类：
| 类型 | 例子 | 处理方式 |
|---|---|---|
| 低风险 | git diff、pnpm check、单元测试 | 可以让 AI 直接跑 |
| 中风险 | 安装依赖、修改配置、生成迁移脚本 | 先说明原因，再人工确认 |
| 高风险 | 删除文件、读取密钥、推送远程、执行生产迁移 | 默认禁止 |
权限控制的核心不是“不信任 AI”，而是不给任何工具误操作的机会。
我的常用流程
日常写需求时，可以按这个顺序走：
- 新建分支，确认工作区状态。
- 写轻量 Spec，明确目标、范围和验收标准。
- 让 AI 先出方案，不急着改代码。
- 方案确认后，按小任务实现。
- 每完成一块就跑测试、看 diff。
- 当前 diff 稳定后再提交。
- 让 AI 做 Review，修掉合理问题。
- 合并前人工看关键代码。
完整一点的实战 Prompt 可以这样写：
你现在是这个项目的 AI 编程助手。
任务：实现用户收货地址的默认地址切换功能。
请按下面流程执行：1. 先阅读用户地址相关代码，只输出方案。2. 方案里说明需要修改哪些文件、有哪些风险。3. 等我确认后再写代码。4. 每次只完成一个小步骤。5. 修改后列出 diff 摘要和验证命令。
限制：- 不修改用户表结构- 不改变已有地址列表接口返回格式- 默认地址必须保证同一用户只有一个这类 Prompt 不花哨，但很适合真实项目。
短期原型可以大胆试，先把东西跑起来。但只要代码要长期维护，就要把 Git、测试、Review、Spec 和权限控制加回来。
Vibe Coding 的重点不是让 AI 替我们“盲写代码”，而是让 AI 在清晰规则里放大我们的执行力。
If this article helped you, please share it with others!
Some information may be outdated