掌握 Prompt、Rules 和 Agent 的基本用法之后, Vibe Coding 的主要问题就不再是“AI 能不能写代码”, 而是如何让它稳定地产出符合项目实际约束的代码, 同时避免错误被快速放大.
这一篇集中记录使用过程中的注意事项与进阶技巧.
注意事项
AI 无法理解项目中不存在的信息
模型只能根据当前能够读取到的代码、文档和工具输出进行判断. 如果关键业务知识只存在于开发者脑中、外部系统或历史约定里, AI 就无法可靠地理解它.
以一个旧项目为例. 项目最初通过中间件进行数据库操作, 代码中没有维护完整的库表定义. 在这种情况下, AI 很难知道项目有哪些数据库表、业务逻辑使用了哪些字段, 以及关键表之间存在怎样的关系.
将数据库访问逐步收敛到 ORM 后, 业务表、字段类型和关系变成了机器可读的项目上下文. 这不仅改善了代码结构, 也明显降低了 AI 理解业务的成本.
同样的原则也适用于:
- 为接口维护 OpenAPI 或类型定义
- 为复杂业务维护状态机和流程文档
- 在代码中保留明确的领域模型
- 为关键约束补充测试与示例
如果信息对开发者很重要, 就应该尽可能让它也能被工具读取.
最优解不一定是项目中的正确解
AI 倾向于根据通用最佳实践给出它认为的最优方案, 但项目通常存在现实约束.
例如在编写单元测试的 conftest 时, AI 可能优先使用实时 mock 或动态构造依赖. 这种方案在通用场景中可能很灵活, 但如果项目已经约定使用固定 fixture、隔离数据库或特定测试容器, 它反而会增加理解和维护成本.
因此需要明确告诉 AI:
- 优先遵循现有项目模式
- 不要为了通用性引入额外抽象
- 测试必须验证真实业务行为
- 未经允许不要修改测试来适配实现
控制运行权限
Agent 可以执行命令、修改文件并调用外部工具, 因此需要明确允许和禁止的操作范围.
适合默认允许的通常是只读搜索、格式检查和本地测试. 对删除文件、修改生产配置、访问生产数据和执行不可逆命令, 则应保留人工确认.
在配置 Agent 的运行权限时, 应遵循最小权限原则:
- 只开放完成任务所需的命令
- 将开发、测试和生产环境隔离
- 不在 Prompt、规则或日志中暴露 Token
- 为重要修改保留 Git 回退点
- 对外部写入操作保留人工确认
不要跳过 Review 与验证
AI 生成速度越快, 越容易让人忽略审查. “代码能够运行”只能证明它通过了当前路径, 不能证明业务逻辑正确.
需要重点检查:
- 是否遗漏隐含业务规则
- 是否引入 mock、硬编码或临时绕过
- 是否出现过度设计
- 测试是否覆盖异常路径
- 修改范围是否超出任务边界
进阶技巧
主备模型
不同模型在代码能力、上下文窗口、速度和费用上各有优势. 对支持组合模型的 Vibe Coding 工具, 可以通过主备模型降低成本并提升复杂任务的完成质量.
一种常见方式是:
- 使用速度快、成本低的模型处理搜索、简单修改和文档整理
- 使用能力更强的模型负责复杂规划、疑难排查与关键代码 Review
主备模型的价值不是简单地在失败后切换模型, 而是根据任务难度分配合适的能力.
使用独立模型进行 Review
如果方案、实现和测试都由同一个上下文完成, 容易形成逻辑自洽但方向错误的伪闭环.
在高风险任务中, 可以将改动交给另一个模型独立审查, 并要求它:
不要延续实现者的假设.
请根据需求、代码改动和测试结果独立寻找遗漏、错误与过度设计.独立上下文能够提供新的观察角度, 对技术调研和复杂重构尤其有效.
将复杂任务拆成可验证阶段
复杂任务不应只拆成多个“实现步骤”, 还需要为每一步设置可验证的完成标准.
例如:
- 先梳理现有调用链并输出文档.
- 补齐测试, 固化当前行为.
- 修改一个边界清晰的模块.
- 运行测试并进行独立 Review.
- 确认后再进入下一个模块.
这种方式能够降低上下文压力, 也能避免错误跨模块扩散.
将一次经验沉淀为项目能力
一次排查中发现的约束, 应根据适用范围沉淀到合适的位置:
- 始终生效的项目约束写入 Rule
- 特定任务流程整理为 Skill
- 业务事实写入项目文档或代码模型
- 可自动验证的规则写成测试或检查脚本
Vibe Coding 的进阶并不是写出更长的 Prompt, 而是不断减少每次任务都需要重新解释的内容, 让项目本身变得更容易被人和 AI 理解.
