前言：Vibe Coding 不等于把需求扔给 AI
很多人理解的 Vibe Coding，是把需求描述给 AI，然后等待它生成代码。但真正决定开发质量的，不是 AI 能不能写出代码，而是我们有没有为它定义清晰的边界，并且能不能及时验证结果。
我现在更愿意把 Vibe Coding 理解为一种按风险分配人机控制权的开发模式：功能越核心、越复杂、越难验证、越难回滚，控制权越应该掌握在人手里；功能越简单、越清晰、越容易测试和恢复，就可以把更多执行权交给 AI。
Vibe Coding = 按风险分配控制权的人机协作开发模式判断一个功能适不适合交给 AI 批量开发，关键要问五个问题：
- 人能不能把需求定义正确？
- 边界条件能不能提前列出来？
- 测试能不能覆盖这些规则？
- AI 写错后，错误能不能被及时发现？
- 出错以后，能不能低成本回滚或恢复？
一、守旧派：人主导，AI 执行
守旧派模式要求开发者理解项目的业务、架构和关键逻辑，再让 AI 按照明确的改动边界小步执行。
它适合以下场景：
- 核心业务链路
- 复杂状态机
- 事务、一致性和并发控制
- 权限、安全、金额、库存和订单
- 会影响架构边界、接口或调用链的改动
- 出错后可能造成数据污染，且不容易恢复的功能
守旧派的基本流程是：
人理解业务和架构
-> 人指定改动边界
-> AI 小步实现
-> 人逐轮 review
-> 测试与验收
-> 继续下一小步在已有项目中，AI 不能只追求“先跑起来”。开始编码前，至少要对齐以下内容：
- 依赖和框架能力是否已经存在
- 文件应该放在哪个模块
- 入口、接口、实现和适配器之间如何调用
- 配置、Bean、工厂或装配点在哪里
- 哪些文件可以修改，哪些文件不能修改
- 哪些既有行为必须保持不变
守旧派的价值不在于拒绝 AI，而在于防止 AI 猜业务、绕开已有调用链，或者在项目中创造一套平行实现。
二、维新派：文档主导，AI 批量执行
维新派模式把更多执行权交给 AI，但这并不意味着不需要设计。它要求先把业务意图、架构意图和行为意图写成文档，再拆成清晰的 tickets，让 AI 按照文档批量推进。
它适合以下场景：
- 简单 CRUD
- 后台管理页面
- 表单、列表、分页和筛选
- 导入导出等低风险功能
- 非核心业务模块
- 出错容易发现、容易回滚的功能
基本流程是：
讲清业务逻辑和技术栈
-> 编写 PRD / ADR / BDD
-> 拆分 tickets
-> AI 按 tickets 开发
-> 自动化测试 + 人工验收
-> 定期 review 与架构防腐“CRUD”本身并不自动代表低风险。如果 CRUD 涉及权限、金额、库存、审批、数据隔离或多租户，它依然应该按照守旧派或混合派处理。
三、维新派的五个准入条件
维新派能否安全放权，不取决于功能看起来是否简单，而取决于下面五个条件是否同时成立。
1. 需求可以讲清
功能目标、使用角色、输入、输出和核心规则，应该能用普通语言说明，不依赖大量只存在于开发者脑中的隐性经验。
文档至少要回答：
谁使用？
在什么场景使用？
用户做什么操作？
系统返回什么结果？
哪些字段必填？
哪些状态允许操作？
哪些状态禁止操作？如果一个需求无法被整理成几条明确规则，AI 就只能自行猜测，不能直接进入维新派流程。
2. 边界可以列出
除了正常路径，还要提前列出空值、重复、不存在、无权限、状态不允许、数据被引用和并发提交等情况。
例如“删除分类”至少要定义：
- 分类不存在时返回什么
- 当前用户没有权限时返回什么
- 分类已经被商品引用时是否允许删除
- 分类没有被引用时是否允许删除
边界列不出来，通常说明功能本身还没有想清楚。边界越明确，AI 的自由发挥空间越小，批量开发越安全。
3. 测试可以覆盖
需求和边界必须能转化为自动化测试、BDD 场景，或者明确的验收清单。可以使用下面的格式描述行为：
Given 前置条件
When 用户执行操作
Then 系统产生预期结果例如：
Given 系统中已经存在名为“手机”的分类
When 管理员再次创建名为“手机”的分类
Then 系统拒绝创建，并提示“分类名称已存在”如果只能通过“看起来差不多”来验收，而无法写出可重复的测试，就不适合完全交给 AI。
4. 错误能被发现
AI 写错以后，错误不能悄悄隐藏在数据或业务流程中，而应该能通过测试、接口状态码、页面提示、日志或数据库检查暴露出来。
文档中应明确：
- 成功和失败分别返回什么状态码
- 页面展示什么提示
- 数据库应该发生什么变化
- 失败时如何返回原因
- 哪些异常需要记录日志
如果错误可能悄悄污染金额、权限、库存、订单或生产数据，就不能按纯维新派放权。
5. 回滚成本低
即使测试通过，也要考虑 AI 写错后的恢复代价。要提前确认：
- 是否影响核心数据
- 是否影响线上用户
- 是否可以通过 Git 回滚
- 是否需要数据修复脚本
- 最坏情况下会造成什么影响
一个后台标签页面出错，通常可以回滚代码并清理测试数据；支付状态流转出错，则可能导致真实订单状态异常。这两者不能使用同样的放权程度。
四、混合派：按功能内部的风险拆分
真实项目往往不是整个功能都属于某一种模式。一个看似普通的管理功能，可能有 80% 的 CRUD 外壳和 20% 的权限、状态或事务规则。
更合适的做法是拆开处理：
CRUD 页面、DTO、基础接口 -> 维新派
权限判断、状态流转、事务边界 -> 守旧派因此，模式选择的粒度不应该只到“项目”或“模块”，还应该细化到 ticket 和关键风险点。
可以用下面的风险矩阵快速判断：
| 条件 | 更适合维新派 | 更适合守旧派 |
|---|---|---|
| 业务影响 | 内部工具、辅助页面 | 核心交易、权限、安全 |
| 技术复杂度 | 单表 CRUD | 状态机、并发、事务 |
| 架构影响 | 顺着既有模式扩展 | 修改接口、抽象或调用链 |
| 可验证性 | 测试和验收明确 | 只能依赖人工理解 |
| 回滚成本 | 容易撤销 | 可能造成数据污染 |
五、文档就是维新派的控制边界
维新派不是减少思考，而是把思考提前写进文档。建议在写 tickets 之前完成三层对齐：
- PRD：明确要做什么、服务谁、有哪些业务规则
- ADR：明确采用什么架构方案、复用哪些已有能力、放弃哪些方案
- BDD：明确正常路径、错误路径和边界行为
每个 ticket 至少应该包含：
## 目标
## 输入与输出
## 业务规则
## 边界场景
## 验收条件
## 测试要求
## 允许修改的范围
## 不允许改变的既有行为文档越完整，AI 越像一个高执行力的工程团队；文档越模糊，AI 越像一个会自行补全需求的临时设计师。
六、Review 与架构防腐
无论采用哪种模式，都不能因为 AI 开发速度快就取消 review。
每个 ticket 完成后，可以让 AI 反向回答：
- 本轮改了哪些地方？
- 为什么这样改？
- 和原计划相比有哪些差异？
- 遇到了哪些隐藏边界？
- 哪些地方仍然不确定？
此外，还应该定期进行架构防腐扫描，检查：
- 是否出现重复的 service、util 或 mapper
- 是否有 controller 直接调用 repository
- 是否跳过接口直接依赖实现类
- 是否绕开了项目已有的框架能力
- 是否出现配置散落、命名不一致和边界外泄
Review 是针对当前改动的质量检查，架构防腐则是对系统长期形态的检查，两者不能相互替代。
七、接下来的学习目标
今天我也确定了接下来的学习方向：
- 学习 AI Agent，理解 Agent 的工具调用、任务规划、记忆和工程闭环。
- 学习 AIGC 技巧，掌握如何更有效地使用 AI 进行内容生成、知识整理和创作。
- 继续记录真实学习过程，例如今天对 FastAPI 的学习，沉淀类型提示、Pydantic、异步、路由参数和
APIRouter等基础知识。 - 把学习内容转化为可复用的文档、实践和复盘，而不是只停留在一次性对话中。
这也是 Vibe Coding 方法论的延伸：先把目标和约束讲清楚，再让 AI 协助执行，最后通过实践和复盘验证学习结果。
结语
Vibe Coding 的成熟形态，不是更相信 AI，而是更清楚：
什么时候应该相信 AI？
应该把多少控制权交给 AI？
用什么测试和 review 验证 AI？
出错以后如何低成本恢复？最终可以把三种模式概括为：
守旧派：人掌握业务与架构，AI 做小步执行。
维新派：文档和测试掌握边界，AI 做批量执行。
混合派：低风险部分放权，高风险部分收权。真正高效的 AI 编程，不是让人退出开发，而是让人从“逐行写代码”升级为“定义问题、划定边界、验证结果和维护系统”。