第一次上手 Vibecoding，很容易产生一种错觉：
结果往往很真实——AI 确实写代码飞快，但跑偏也是分分钟的事。它就像一匹烈马，爆发力十足，一天能跑完别人一周的代码量；可要是没给缰绳、不设围栏、不指明方向，它也能连人带代码一起扎进沟里。
结合项目经验来看，关于 Vibecoding，一个很重要的体会是：用好它的关键，不是把想法一股脑扔给 AI，而是学会在这个过程中掌控每一步。
这篇文章就想结合我们在一个作业预警系统项目里的真实经历，聊聊怎么用好 Vibecoding：每个阶段应该给 AI 什么指令、期望它产出什么成果、怎么检查和验收，以及最核心的一点——如何给 Vibecoding 套上规范。
说到底，驯服烈马的关键，从来不是喊得更大声，而是给它套上缰绳、马鞍和赛道。对 Vibecoding 来说，这些东西就是规范。
一、Vibecoding 的核心不是写代码，而是控过程
提到 Vibecoding，不少人第一反应就是：用自然语言生成代码呗。但在真实项目中，最有价值的不是“帮我写一个接口”这种一句话指令，而是让 AI 参与到整个工程过程里来：
- 帮你拆解需求；
- 帮你梳理现有代码；
- 帮你定位问题根源；
- 帮你设计修改方案；
- 帮你生成可以审查的代码；
- 帮你写测试用例；
- 帮你复盘经验并沉淀成规范。
换句话说，Vibecoding 真正的内核不是“代码生成”，而是“工程协作”。
不妨把 AI 当成一个手速惊人但刚入职的程序员，这么一想，提问方式自然而然就变了。
千万别这么问：
帮我实现作业预警系统。
正确的问法应该是这样：这是一个作业预警系统，当前已有班级、作业、学生、提交记录、邮件发送等模块。请先不要写代码，先帮我梳理：1. 这个功能涉及哪些实体；2. 后端需要哪些接口；3. 前端需要哪些页面状态；4. 有哪些边界情况；5. 最后输出一个分阶段实现计划。
这就是“驯马”的第一步：先让它慢下来，别急着狂奔。没有规范的 AI 是烈马，有规范的 AI 才是战马。
二、需求阶段：不要让 AI 猜业务
项目早期，常常只有一个比较粗糙的想法：
这个描述对人类的沟通来说似乎够了，但对 AI 来说远远不够。它会自动“脑补”出很多东西，比如：
- 谁有权限创建班级？
- 谁可以创建作业？
- 管理员和教师权限一样吗？
- 汇总邮件究竟是发给谁？
- 催交邮件是发给学生、家长，还是教师？
- 预警条件按什么算——提交次数、截止时间，还是作业数量？
- 教师能否代学生提交？
- 管理员能否替教师发送汇总邮件？
这些问题如果在需求阶段没说清楚，AI 生成的代码极有可能是“技术上完全正确，业务上一塌糊涂”。
这个阶段应该怎么给指令
需求阶段，最常用的指令不是“帮我写代码”，而是：请你先作为产品经理和后端架构师，帮我澄清这个功能的业务规则。不要写代码。请输出：1. 角色和权限；2. 核心业务流程；3. 涉及的数据实体；4. 关键边界情况；5. 需要我确认的问题。
举个具体的例子，在“发送作业汇总邮件”这个功能里，需要先问清楚：
- 教师点击发送汇总，邮件到底发给谁；
- 管理员帮教师管理班级时，邮件又该发给谁；
- 如果管理员想发给自己，是否需要显式选择；
- 前端传空 email 时，后端应该如何推导出默认收件人；
- 后端能不能直接用
current_user.email作为默认收件人。
这些不是单纯的技术细节，而是业务语义。AI 很擅长实现技术逻辑，但它不会天然理解你的业务语义——你不告诉它，它就会选择最顺手、最容易拿到的数据来凑。
这个阶段应该有什么产出
需求阶段不应该产出任何代码，而应该产出一份业务规则说明。例如：功能名称：发送作业汇总邮件
角色：
- 教师：可发送自己班级的作业汇总；
- 管理员：可代教师触发发送，但默认收件人仍应为班级负责教师；
- 学生：无权限触发。
收件人规则：
- 默认收件人 = 班级负责教师邮箱；
- 如果接口显式传入 email，则发送到指定邮箱；
- 禁止后端默认使用当前登录用户邮箱作为业务收件人。
边界情况：
- 班级没有绑定教师：返回错误；
- 教师没有邮箱：返回错误；
- 作业不存在：返回 404；
- 当前用户无权限访问该班级：返回 403。
这类文档，就是给烈马套上的第一根缰绳。
三、读代码阶段：让 AI 先做“考古”，再做“施工”
很多 Vibecoding 翻车的案例，不是因为 AI 写不出代码，而是它压根没理解已有的项目结构。
在现有项目上直接让 AI 改功能，是一件风险极高的事。它可能会：
- 新建一套重复逻辑；
- 绕过已有的权限体系；
- 忽略现成的 Service；
- 修改一个接口却破坏了另一个页面；
- 为了完成眼前任务，引入更大的不一致性。
所以在动手之前，明智的做法是先让 AI 做一轮“代码考古”。
这个阶段应该怎么给指令
请你先阅读当前项目中和“作业汇总邮件”相关的代码。不要修改代码。请输出：1. 当前调用链路；2. 每一层的职责；3. 当前收件人 email 是如何确定的；4. 可能存在的问题；5. 你建议修改哪些文件，为什么。
在我们项目里，这个阶段就能梳理出类似这样的调用链路：前端页面点击“发送汇总”
↓
POST /api/assignments/{id}/summary
↓
assignments.py 接口处理
↓
EmailService.send_assignment_summary_email()
↓
邮件发送服务
进一步检查就会发现问题所在：当 email 参数为空时，后端使用 current_user.email 作为默认收件人。
这个逻辑乍一看没毛病——谁点的按钮，就发给谁。但放进业务场景里就错了。管理员帮教师创建班级作业后，管理员点击“发送汇总”，系统就会把汇总邮件发给管理员自己，而不是发给班级的负责教师。
这就是典型的 Vibecoding 风险：代码层面看似合理，不代表业务层面正确。
这个阶段应该有什么产出
读代码阶段的产出应该是一份“现状地图”：当前问题：
- 接口默认收件人依赖 current_user；
- current_user 表示操作人，不等于业务收件人；
- 管理员代操作场景下，操作人与班级负责教师不是同一个人；
- 因此前端传空 email 时，后端会发错人。
建议：
- 后端根据 assignment -> class -> teacher 找到班级负责教师；
- 默认 recipient_email 改为 clazz.teacher.email；
- 显式传入 email 时，才使用指定 email；
- 增加测试覆盖管理员代发场景。
注意，这时还不应该让 AI 写代码。先让它说清楚要改什么、为什么改。
四、方案阶段：要求 AI 输出“可审查计划”
AI 最危险的地方在于，它经常一边写代码一边改主意。所以在真正改代码之前，让它先出一份“修复计划”会稳妥得多。
比如面对“汇总邮件收件人错误”这个问题，可以这样要求：请基于刚才的代码分析，写一份修复计划。要求：1. 明确根因；2. 明确不受影响的功能；3. 给出后端修改点；4. 给出前端是否需要修改；5. 给出测试用例；6. 不要写代码。
这么做的最大好处是：你可以在代码生成之前，就发现方向是否正确。
一个好的修复计划应该长这样
根因：
- 当前汇总邮件默认收件人使用 current_user.email；
- current_user 是当前操作人；
- 管理员代教师操作时，current_user 是管理员；
- 业务期望收件人是班级负责教师。
修改方案：
- 在 assignment summary 接口中，通过 assignment.class_id 查询班级；
- 从班级对象获取 teacher；
- 默认 recipient_email = clazz.teacher.email；
- 如果请求显式提供 email，则使用请求中的 email；
- 如果班级没有教师或教师没有邮箱，返回明确错误。
不影响：
- 预警催交邮件逻辑不受影响；
- 因为 warning_task.py 中已经使用 clazz.teacher.email。
测试用例：1. 教师本人发送汇总，收件人为教师邮箱；2. 管理员代发汇总，收件人为班级负责教师邮箱；3. 显式传入 email，收件人为指定邮箱；4. 班级未绑定教师，返回错误；5. 教师无邮箱，返回错误。
这一步非常关键。它相当于先让烈马沿着围栏走一圈，确认没有漏洞，再让它开始加速。
五、规范阶段：给 Vibecoding 套上“项目缰绳”
很多人使用 Vibecoding 的方式，是想到哪里说到哪里：
帮我写个接口。帮我改下 bug。帮我优化一下页面。帮我顺便重构一下。
这种方式短时间看确实很爽，但长期来看隐患巨大。AI 不怕写代码，怕的恰恰是它写得太快、太顺手、太自信。如果没有规范约束，它会不断根据当前上下文“合理发挥”：
- 接口命名可能一会儿用
/summary，一会儿又用/send-summary； - 错误处理可能一会儿返回
400，一会儿返回500； - 权限判断可能一会儿放在 Controller，一会儿放在 Service；
- 邮件收件人可能一会儿取
current_user.email，一会儿取teacher.email； - 前端状态可能一会儿叫
loading，一会儿叫isSubmitting； - 同一个业务概念，可能被它折腾出三套不同的实现。
这就是没有规范的 Vibecoding——它不是因为不努力才出问题，而是因为太努力了；不是不会写，而是每次都按自己的理解重新发明一套。
所以，要真正驯服 Vibecoding，必须给它加上几道硬规范。
1. 业务语义规范
业务语义规范回答的是：这个系统里的核心概念，到底是什么意思？
在这个项目中，就必须明确：current_user 只表示当前登录操作人；
teacher 表示班级负责教师；
admin 可以代操作，但不自动成为业务接收人；
assignment 的归属由 class 决定；
邮件默认收件人应该从业务对象推导，而不是从操作人推导。
如果没有这条规范，AI 就很容易犯我们项目里遇到的那个错误：从技术上看，使用 current_user.email 很自然，因为当前用户确实有邮箱，而且很好拿。但从业务上看，这是错的。
所以应该给 AI 一条明确的规范：在本项目中，current_user 只能用于权限校验、审计日志和个性化展示。凡是涉及业务通知、邮件接收人、任务归属人，必须从业务对象关系中推导，不能默认使用 current_user。
这条规范的价值，远大于“修复这个 bug”。它不只修一个问题，而是防范同类问题反复出现。
2. 代码修改规范
AI 有个“顺手优化”的习惯。你让它修一个收件人 bug，它可能顺手重构接口、改 Service 签名、调整返回结构、移动函数位置。这种行为在小 demo 里无伤大雅，在真实项目里就非常危险了。
所以需要给出明确的代码修改规范：每次修改必须遵守：1. 只修改和当前任务直接相关的文件；2. 不做无关重构；3. 不改变已有接口行为，除非任务明确要求；4. 不引入新的架构层，除非先提交方案并获得确认；5. 修改前先说明计划，修改后解释 diff；6. 对历史行为保持兼容。
在“作业汇总邮件收件人修复”这个案例里，就应该明确告诉 AI：只修复默认收件人逻辑。不要修改邮件模板。不要修改接口路径。不要重构 EmailService。不要改变显式传入 email 时的行为。
这就像告诉烈马：你这次只需要跨过前面那个障碍，别绕场跑三圈。
3. 接口设计规范
接口设计如果没有规范，AI 很容易每次生成不同风格。同样是发送邮件，它可能写出这些接口：POST /api/assignments/{id}/summary
POST /api/assignment/send-summary
POST /api/email/summary
POST /api/assignments/{id}/send-email
每个接口看起来都能用，但系统的混乱程度会与日俱增。所以需要提前定好规矩：接口设计规范：1. REST 接口优先围绕业务资源设计；2. assignment 相关操作统一放在 /api/assignments 下；3. 动作类接口使用清晰动词，如 /summary 或 /send-summary；4. 请求参数必须区分 path、query、body；5. 后端必须对权限和业务归属进行二次校验；6. 前端不能通过隐藏按钮来替代权限控制。
对于当前项目，还可以进一步细化为：作业相关接口统一以 assignment_id 为主线；
班级相关接口统一以 class_id 为主线；
邮件发送接口必须明确 recipient 的来源；
如果 recipient 可选，后端必须定义默认推导规则；
默认推导规则必须写在接口注释或 service 注释中。
这样，AI 后续再写功能时，就不会每次都重新发明一套风格了。
4. 错误处理规范
AI 生成代码时，经常会选择最简单的方式来处理异常：try:
...
except Exception:
return {"message": "发送失败"}
这种方式对用户和开发者都不友好。项目里应该给 Vibecoding 明确的错误处理规范：错误处理规范：1. 资源不存在返回 404；2. 无权限返回 403；3. 参数错误返回 400；4. 业务前置条件不满足返回 422；5. 系统异常返回 500；6. 错误信息必须能指导用户或开发者定位问题；7. 禁止用宽泛 except 吞掉真实异常。
放到“发送汇总邮件”案例里，对应的就是：作业不存在：404 Assignment not found
当前用户无权限访问班级：403 Permission denied
班级没有绑定教师：422 Class has no assigned teacher
教师没有邮箱：422 Teacher email is missing
邮件服务异常：500 Failed to send email
这比一句笼统的“发送失败”要清晰得多。规范越清晰，AI 越不容易瞎兜底。
5. 测试规范
没有测试规范，AI 很容易只照顾到正常情况。比如它可能只生成：教师点击发送汇总，邮件发送成功。
但真正容易出错的反而是那些边界情况：
- 管理员代教师发送时，邮件发给谁？
- 班级没有教师时，怎么办？
- 教师没有邮箱时，怎么办？
- 显式传入 email 时，是否覆盖默认收件人？
- 无权限用户是否能触发邮件？
所以需要给 Vibecoding 立个测试规范：每个功能至少覆盖：1. 正常路径；2. 权限差异；3. 角色差异；4. 空值情况；5. 显式参数覆盖默认逻辑；6. 历史 bug 回归测试。
针对这次出过的问题，测试规范里还应该明确加上一条：凡是修复过的线上 bug，必须补一个回归测试。
也就是说，这次 bug 修复之后，应该有一个专门的测试来验证：当管理员触发作业汇总邮件，且请求未显式指定 email 时，系统应将邮件发送给班级负责教师，而不是管理员。
这就是把事故本身变成护栏。
6. 产出物规范
Vibecoding 不应该只产出代码。每个阶段都应有固定的产出物，可以给 AI 一套项目级的产出规范：每次处理任务时，必须按阶段产出：
需求阶段：
- 业务规则说明
- 角色权限说明
- 边界情况列表
方案阶段：
- 根因分析
- 修改范围
- 不修改范围
- 风险点
- 测试计划
实现阶段：
- 修改文件列表
- 核心 diff 说明
- 兼容性说明
测试阶段：
- 测试矩阵
- 回归测试点
- 手工验证步骤
复盘阶段：
- 问题现象
- 根因
- 修复方式
- 后续规范沉淀
这样，AI 的价值就不只是“帮我写了几行代码”，而是帮整个项目积累了可复用的工程资产。
六、实现阶段：把大任务切成小刀口
很多人让 AI 改代码时，习惯给一个很大的指令：帮我修复这个 bug。
这种指令很容易导致 AI 一次改太多文件，甚至把原本好端端的功能改坏。更好的方式是小步提交。
这个阶段应该怎么给指令
请只修改后端接口中“默认收件人”的逻辑。要求：1. 不改变接口路径；2. 不改变 EmailService 的函数签名，除非必须；3. 不影响显式传入 email 的行为；4. 修改后解释每一处变更；5. 不要顺手重构无关代码。
这里有一个非常关键的原则：AI 很喜欢“顺手优化”，但项目不需要它这么做。你要明确告诉它：不要重构无关代码。不要修改命名风格。不要调整已有接口结构。不要引入新的抽象层。只修复当前问题。
因为 AI 经常像一个热情过头的实习生——你让它修门锁，它顺手就把整扇门都换了。
这个阶段应该有什么产出
实现阶段，AI 应该输出：修改文件：
- backend/api/assignments.py
修改内容：
- 当 email 参数为空时，不再读取 current_user.email；
- 改为通过 assignment 找到对应 class；
- 再从 class.teacher.email 获取默认收件人。
保留行为：
- 如果请求中显式传入 email，仍优先使用该 email。
需要验证：
- 教师本人发送汇总；
- 管理员代教师发送汇总；
- 显式指定 email；
- 班级没有教师；
- 教师没有邮箱。
这才是真正可控的代码生成。
七、测试阶段：不要只问“能不能跑”
测试时，很多人习惯问 AI：帮我检查有没有问题。 这个问题太模糊了，AI 很可能泛泛而谈。更好的方式是让它基于业务规则来生成测试矩阵。
这个阶段应该怎么给指令
请基于这个修复方案，生成测试矩阵。要求覆盖：1. 教师本人操作；2. 管理员代操作；3. 显式传入 email；4. 班级无教师；5. 教师无邮箱；6. 无权限用户访问。请用表格输出：场景、输入、期望收件人、期望结果。
示例产出
| 场景 | 操作人 | 班级负责教师 | 请求 email | 期望收件人 | 期望结果 |
|---|---|---|---|---|---|
| 教师本人发送 | 教师 A | 教师 A | 空 | 教师 A 邮箱 | 成功 |
| 管理员代发 | 管理员 | 教师 A | 空 | 教师 A 邮箱 | 成功 |
| 指定收件人 | 管理员 | 教师 A | test@example.com | test@example.com | 成功 |
| 班级无教师 | 管理员 | 空 | 空 | 无 | 返回错误 |
| 教师无邮箱 | 管理员 | 教师 A | 空 | 无 | 返回错误 |
| 无权限访问 | 其他教师 | 教师 A | 空 | 无 | 403 |
这个矩阵比一句“帮我测一下”管用得多。它把测试的关注点从“代码能不能跑”提升到了“业务逻辑是否正确”。
八、调试阶段：让 AI 解释“为什么错”，而不是让它“再试一次”
调试时最忌讳的指令就是：报错了，帮我改。 如果只是把报错丢给 AI，它可能会头痛医头、脚痛医脚，修好一个错误再引入另一个。更好的方式是先让它做根因分析。
这个阶段应该怎么给指令
这是报错信息和相关代码。请不要直接修改。先输出：1. 报错发生在哪一层；2. 触发条件是什么；3. 最可能的根因；4. 有哪些可能但不推荐的修复方式；5. 最小修改方案是什么。
举个例子，如果发送汇总时报错：AttributeError: 'NoneType' object has no attribute 'email'
AI 如果直接动手，可能会加一个粗暴判断：if clazz.teacher:
email = clazz.teacher.email
else:
email = current_user.email
这看似解决了空指针，实际上又把 bug 原封不动地带了回来。因为当班级没有教师时，正确的行为不是发给当前用户，而是返回明确的业务错误。
所以你要在指令里特别强调：不要用 current_user.email 作为 fallback。如果班级没有教师，应返回业务错误，而不是静默兜底。
这就是调试阶段最重要的经验：不要让 AI 用技术手段去掩盖业务上的错误。
九、前后端联调阶段：明确“数据从哪里来，到哪里去”
前后端联调时，AI 很容易只看一方。比如前端按钮“发送汇总”传了一个空 email，后端拿到空 email 后自己决定收件人。这个设计本身不一定错，但必须把后端的默认规则明确清楚。
这时候可以让 AI 画出一张链路图。
这个阶段应该怎么给指令
请帮我梳理“发送汇总邮件”的前后端联调链路。要求：1. 从用户点击按钮开始；2. 写出前端请求参数；3. 写出后端接收参数；4. 写出后端如何确定 recipient_email；5. 写出最终调用邮件服务的参数；6. 标出当前设计中容易误解的地方。
示例产出
用户点击“发送汇总”
↓
前端调用 POST /api/assignments/{id}/summary
↓
请求体中 email 为空
↓
后端判断 email 是否为空
↓
为空时，根据 assignment 找到 class
↓
根据 class.teacher 获取教师邮箱
↓
调用 EmailService.send_assignment_summary_email
↓
邮件发送给班级负责教师
这个链路图很简单，但价值很高。它能让你一眼看清：每一步是谁负责的，数据是在哪一层被决定的。
十、代码审查阶段：把 AI 当成 reviewer
AI 不只会写代码，用来做代码审查同样很擅长。但你不能只丢一句：帮我 review 一下。 需要给它明确的审查标准。
这个阶段应该怎么给指令
请从以下角度 review 这次修改：1. 是否满足业务规则；2. 是否引入权限漏洞；3. 是否影响已有功能；4. 是否存在空值异常；5. 错误信息是否清晰；6. 是否需要补充测试。请按“严重问题 / 一般问题 / 建议优化”分组输出。
给定了标准，AI 的输出就会更像工程 review，而不是泛泛的建议。
示例产出
严重问题：
- 如果班级无教师时 fallback 到 current_user.email，会再次导致管理员收到邮件，违反业务规则。
一般问题：
- 教师邮箱为空时，需要返回明确错误，否则邮件服务可能失败。
建议优化：
- 日志中记录 assignment_id、class_id、recipient_email，便于排查邮件发送问题。
这类 review 对真实项目非常有帮助，能帮你提前发现那些“看起来没问题，但业务上又错了”的细节。
十一、文档和复盘阶段：让 AI 产出“给未来自己看的说明”
每次修复一个 bug，都建议让 AI 产出一份简短的技术复盘。尤其是像“管理员代操作导致收件人错误”这类问题，非常适合沉淀为项目经验。
这个阶段应该怎么给指令
请基于这次 bug 修复，写一份技术复盘。要求包括：1. 问题现象；2. 根因；3. 修复方案；4. 为什么不能用 current_user.email；5. 测试覆盖；6. 后续类似功能的设计原则。
示例复盘片段
本次问题的根因是混淆了“操作人”和“业务对象负责人”。current_user 表示当前登录用户，只能用于权限校验和审计记录，不能默认作为业务收件人。在管理员代操作场景下，操作人是管理员，但业务收件人应该是班级负责教师。后续凡是涉及邮件、通知、审批、归属关系的功能，都必须优先从业务对象中推导接收人，而不是从当前登录用户中推导。
这段话本身就是一条非常重要的工程原则。一次 bug 修复，如果最后只留下一段代码，那它的价值也就止步于这次修复；但如果留下了复盘和规范，它就会变成后续所有类似功能的护栏。
十二、一个总结：Vibecoding 指令模板
经过这个项目，逐渐形成了一套比较稳定的指令模板。
1. 分析类指令
适合需求、读代码、定位问题。
请先不要写代码。请基于当前上下文分析：1. 当前流程是什么；2. 涉及哪些模块；3. 关键数据从哪里来；4. 可能的问题在哪里；5. 你需要我确认什么。
2. 方案类指令
适合动手之前。
请输出一个可审查的修改方案。要求：1. 明确根因；2. 明确修改范围；3. 明确不修改什么；4. 明确兼容性影响；5. 明确测试用例。不要写代码。
3. 规范类指令
适合在项目开始或重要功能启动前使用。
请基于当前项目，整理一套本功能必须遵守的规范。要求包括：1. 业务语义规范；2. 接口设计规范；3. 错误处理规范；4. 权限校验规范；5. 测试覆盖规范；6. 不允许 AI 自行发挥的边界。
4. 实现类指令
适合真正写代码的阶段。
请按上面的方案实现。限制：1. 只修改必要文件；2. 不做无关重构；3. 不改变已有接口，除非方案中明确说明；4. 保留已有行为；5. 修改完成后解释 diff。
5. 测试类指令
适合验证业务正确性。
请生成测试矩阵。覆盖：1. 正常路径；2. 权限差异；3. 角色差异；4. 空值情况；5. 显式参数覆盖默认逻辑；6. 历史行为兼容。请输出场景、输入、期望结果。
6. Review 类指令
适合在代码提交之前使用。
请作为严格的代码 reviewer 审查这次修改。从业务正确性、权限、安全、空值、兼容性、测试覆盖六个角度检查。按严重问题、一般问题、建议优化输出。
7. 复盘类指令
适合 bug 修复或功能上线后进行沉淀。
请基于这次功能开发/bug 修复，写一份复盘。包括：1. 背景；2. 问题；3. 根因；4. 解决方案；5. 测试覆盖；6. 后续应沉淀成什么规范。
这些模板的核心价值，不是让 prompt 看起来更专业，而是让 AI 每次输出都沿着固定轨道走。指令解决的是单一任务，规范解决的是一类问题。
十三、这个项目给我们最大的教训：不要让 AI 替你决定业务语义
在作业预警系统里，“发送邮件”看似只是一个技术功能。但真正复杂的从来不是 SMTP、不是模板渲染、也不是接口调用。真正复杂的是：这封邮件到底应该发给谁？
这就是业务语义。
AI 非常擅长实现技术逻辑，但它不天然理解业务语义。它会本能地选择最顺手的变量来用，比如 current_user.email。可是 current_user 是“当前操作人”，不等于“业务负责人”。
这类区别在业务系统里其实相当常见：
| 技术变量 | 看起来像 | 实际可能不是 |
|---|---|---|
| current_user | 当前用户 | 业务负责人 |
| creator_id | 创建人 | 当前责任人 |
| class_id | 班级 | 授课教师 |
| email 参数 | 收件人 | 可能只是测试邮箱 |
| admin 用户 | 操作者 | 实际业务归属人 |
所以，Vibecoding 不是把想法扔给 AI 就完事了，而是需要不断提醒它：
- 请区分操作人和业务负责人。
- 请区分权限校验对象和通知接收对象。
- 请区分前端显示状态和后端真实状态。
- 请不要用方便拿到的数据，取代业务上正确的那份数据。
这几句话，几乎可以贴在每个业务系统开发环境的墙上。
十四、如何判断有没有驯服这匹烈马
一个非常简单的判断标准：如果 AI 的产出风格是——我帮你实现好了。 那说明还远远不够。
但如果 AI 的产出风格变成了这样——当前问题是 A。根因是 B。涉及文件是 C。最小修改方案是 D。不应该修改 E。测试用例包括 F。代码变更如下。潜在风险是 G。后续应沉淀的规范是 H。 那说明已经开始驯服它了。
真正好的 Vibecoding，不是 AI 写得多快，而是它的每一步输出都能被审查、验证和回滚。
Vibecoding 的上限，不取决于 AI 模型有多聪明，而取决于你给它的规范有多清楚。
十五、最后：Vibecoding 不是自动驾驶，而是骑马
关于 vibecoding 有个常见的想象：就像自动驾驶，坐上去就等着到达目的地。但 vibecoding 其实更像骑马：你的指令就是缰绳，你的业务规则就是地图，你的工程规范就是马鞍，你的测试用例就是围栏，你的 review 就是刹车。
当你什么都不给，只说一句“帮我做一个系统”，它就会按自己的理解一顿狂奔。当你给它清晰的阶段、明确的边界、完整的规范和严格的验收标准，它就会变成一个非常强大的工程伙伴。
在这个作业预警系统项目中，最大的收获不是“AI 帮我写了多少代码”，而是学会了如何把一个模糊的想法，逐步变成：
- 可讨论的业务规则；
- 可审查的技术方案；
- 可约束的工程规范；
- 可控制的代码变更；
- 可验证的测试矩阵；
- 可复用的项目经验。
驯服 Vibecoding 的关键，不是写出更长的 prompt，而是给它建立规范。需求有需求规范，接口有接口规范，错误有错误规范，测试有测试规范，代码修改有代码修改规范。
没有规范的时候，AI 每次都在重新猜测项目；有了规范之后，AI 才能沿着项目既有的轨道加速。
这就像驯服一匹烈马。目的从来不是削弱它的力量，而是给它缰绳、马鞍和赛道。缰绳是你的业务规则，马鞍是你的工程规范，赛道是你的测试和验收标准。
当这一切都齐备，Vibecoding 就不再是一次次碰运气的代码生成，而会变成一种稳定、可复用、可审查的工程生产方式。驯服了烈马之后，它不是替你跑，而是带你跑得更远。
