---
title: Vibe coding - 注意事项与进阶技巧
date: 2026-02-28 23:17:47
updated: 2026-02-28 23:17:47
status: publish
author: harumonia
categories:
  - 源流清泉
tags:
  - AI
  - Cursor
  - Vibe Coding
noThumbInfoStyle: default
outdatedNotice: no
reprint: standard
thumbChoice: default
thumbStyle: default
hidden: false
email: zxjlm233@gmail.com
---

掌握 Prompt、Rules 和 Agent 的基本用法之后, Vibe Coding 的主要问题就不再是“AI 能不能写代码”, 而是如何让它稳定地产出符合项目实际约束的代码, 同时避免错误被快速放大.

这一篇集中记录使用过程中的注意事项与进阶技巧.

<!-- more -->

## 注意事项

### AI 无法理解项目中不存在的信息

模型只能根据当前能够读取到的代码、文档和工具输出进行判断. 如果关键业务知识只存在于开发者脑中、外部系统或历史约定里, AI 就无法可靠地理解它.

以一个旧项目为例. 项目最初通过中间件进行数据库操作, 代码中没有维护完整的库表定义. 在这种情况下, AI 很难知道项目有哪些数据库表、业务逻辑使用了哪些字段, 以及关键表之间存在怎样的关系.

将数据库访问逐步收敛到 ORM 后, 业务表、字段类型和关系变成了机器可读的项目上下文. 这不仅改善了代码结构, 也明显降低了 AI 理解业务的成本.

同样的原则也适用于:

- 为接口维护 OpenAPI 或类型定义
- 为复杂业务维护状态机和流程文档
- 在代码中保留明确的领域模型
- 为关键约束补充测试与示例

如果信息对开发者很重要, 就应该尽可能让它也能被工具读取.

### 最优解不一定是项目中的正确解

AI 倾向于根据通用最佳实践给出它认为的最优方案, 但项目通常存在现实约束.

例如在编写单元测试的 `conftest` 时, AI 可能优先使用实时 mock 或动态构造依赖. 这种方案在通用场景中可能很灵活, 但如果项目已经约定使用固定 fixture、隔离数据库或特定测试容器, 它反而会增加理解和维护成本.

因此需要明确告诉 AI:

- 优先遵循现有项目模式
- 不要为了通用性引入额外抽象
- 测试必须验证真实业务行为
- 未经允许不要修改测试来适配实现

### 控制运行权限

Agent 可以执行命令、修改文件并调用外部工具, 因此需要明确允许和禁止的操作范围.

适合默认允许的通常是只读搜索、格式检查和本地测试. 对删除文件、修改生产配置、访问生产数据和执行不可逆命令, 则应保留人工确认.

在配置 Agent 的运行权限时, 应遵循最小权限原则:

- 只开放完成任务所需的命令
- 将开发、测试和生产环境隔离
- 不在 Prompt、规则或日志中暴露 Token
- 为重要修改保留 Git 回退点
- 对外部写入操作保留人工确认

### 不要跳过 Review 与验证

AI 生成速度越快, 越容易让人忽略审查. “代码能够运行”只能证明它通过了当前路径, 不能证明业务逻辑正确.

需要重点检查:

- 是否遗漏隐含业务规则
- 是否引入 mock、硬编码或临时绕过
- 是否出现过度设计
- 测试是否覆盖异常路径
- 修改范围是否超出任务边界

## 进阶技巧

### 主备模型

不同模型在代码能力、上下文窗口、速度和费用上各有优势. 对支持组合模型的 Vibe Coding 工具, 可以通过主备模型降低成本并提升复杂任务的完成质量.

一种常见方式是:

- 使用速度快、成本低的模型处理搜索、简单修改和文档整理
- 使用能力更强的模型负责复杂规划、疑难排查与关键代码 Review

主备模型的价值不是简单地在失败后切换模型, 而是根据任务难度分配合适的能力.

### 使用独立模型进行 Review

如果方案、实现和测试都由同一个上下文完成, 容易形成逻辑自洽但方向错误的伪闭环.

在高风险任务中, 可以将改动交给另一个模型独立审查, 并要求它:

```text
不要延续实现者的假设.
请根据需求、代码改动和测试结果独立寻找遗漏、错误与过度设计.
```

独立上下文能够提供新的观察角度, 对技术调研和复杂重构尤其有效.

### 将复杂任务拆成可验证阶段

复杂任务不应只拆成多个“实现步骤”, 还需要为每一步设置可验证的完成标准.

例如:

1. 先梳理现有调用链并输出文档.
2. 补齐测试, 固化当前行为.
3. 修改一个边界清晰的模块.
4. 运行测试并进行独立 Review.
5. 确认后再进入下一个模块.

这种方式能够降低上下文压力, 也能避免错误跨模块扩散.

### 将一次经验沉淀为项目能力

一次排查中发现的约束, 应根据适用范围沉淀到合适的位置:

- 始终生效的项目约束写入 Rule
- 特定任务流程整理为 Skill
- 业务事实写入项目文档或代码模型
- 可自动验证的规则写成测试或检查脚本

Vibe Coding 的进阶并不是写出更长的 Prompt, 而是不断减少每次任务都需要重新解释的内容, 让项目本身变得更容易被人和 AI 理解.