先判断这是不是低风险任务
Vibe Coding 适合快速探索。它不适合无监督改动长期维护项目。区别不在于工具强不强，而在于失败成本高不高。
低风险任务可以让 Agent 多试几版。高风险任务要收紧边界、跑验证、保留回滚点。把这两个场景混在一起，才是 Vibe Coding 最容易翻车的地方。
原型和脚本可以放开一点
原型、一次性脚本、UI 草稿、低风险内部工具，适合用更松的方式推进。你关心的是先看到一个可运行形状，而不是马上得到可维护系统。
这些任务可以给 Agent 更多空间：
放开不等于不检查。至少要看 diff、运行一次主路径、确认没有写入密钥或改动生产配置。
- 生成一个页面草稿
- 写一个一次性数据清洗脚本
- 做一个内部表单 Demo
- 尝试三版组件排版
- 整理一段临时文档
支付和权限先退出 Vibe 模式
支付、安全、迁移、权限、生产配置、SEO 基础设施，都不适合让 Agent 自由发挥。这里的 tail behavior 比 demo 重要。
这类任务要切回工程约束：
如果 Agent 在这些任务里说“我顺手优化了”，先看 diff。顺手优化通常就是风险。
- 先读代码，不改文件
- 列出修改范围
- 只允许改指定文件
- 跑相关测试或手动验证
- 交付 diff 和失败分支
- 保留回滚点
UI 草稿转正式页面前先收边界
Vibe Coding 写 UI 很快。问题出在从草稿转正式页面时。草稿可以有临时字段、临时样式、临时组件；正式页面要接真实数据、移动端、空状态、SEO 和旧路由。
在合并前，至少让 Agent 检查这些点：
| 真实数据 | 使用现有数据结构，不造临时字段 |
| 移动端 | 375px 宽度下标题和按钮不溢出 |
| 空状态 | 无结果、无文章、链接缺失时仍可读 |
| SEO | title、description、canonical 和 JSON-LD 对应当前页面 |
从 Vibe 切回工程流程
当一个草稿准备进入长期维护项目时，立刻换提示词。不要继续说“再优化一下”。换成范围、验证和交付证据。
把刚才的草稿按正式代码处理。
先列出需要保留的改动和需要删除的临时代码。
只修改确认后的文件。
改完后报告 diff、验证命令和没有验证的项目。让 Agent 说明失败成本
一个简单判断很有用：如果这次改错了，谁会受到影响？如果只影响你本地一个草稿，可以继续 vibe。如果会影响用户数据、支付、权限、上线页面或搜索收录，就收紧流程。
开始前先判断这次任务的失败成本：
1. 会不会影响用户数据
2. 会不会影响权限或支付
3. 会不会影响生产配置
4. 会不会影响已发布页面
5. 如果失败，怎么回滚工具链报错时别继续试运气
如果 Claude Code 或 Codex 自己开始报错，比如 model not found、404、unsupported parameter、service_tier 不支持，先修工具链。Vibe Coding 不能靠试错绕过接入问题。
先回到 Claude Code 配置指南、Codex CLI 实用配置指南或对应错误日志。工具链稳定后，再继续让 Agent 改项目。
开始前按这 5 项分类
交给 Agent 前，先给任务分级：
- 原型、脚本、草稿：可以放宽探索
- 内容、普通 UI、内部工具：限定文件，做最小验证
- 权限、支付、安全、迁移：先读代码，确认计划
- 生产配置、SEO 基础设施：必须保留验证和回滚
- 工具链报错：先修配置，不让 Agent 猜业务代码