开场：Vibe Coding 的问题出在质量
Vibe Coding 指靠自然语言让 AI 直接产出代码的开发方式。它的问题出在质量：**没有规矩的 AI 会返工、漏改、悄悄删代码、留下永久技术债。**这一节先看事故长什么样，再看约束怎么注入才最稳。
一句话速览：Vibe Coding 的四类典型事故，以及 Rule 是最稳上下文注入方式的原理。
一、四类典型事故
下面四类事故在 AI 协作中反复出现，根源是同一件事：约束没有进入上下文。
01 理解偏差返工
AI 拿到需求就开始写，写了 200 行才发现理解有偏差，回滚重来。更糟的情况是改了 7 个文件之后才发现思路错了，逐个 revert 成本极高。
02 选型漂移
不同对话里 AI 会选不同框架：今天 Express，明天 Fastify。数据库一会儿 MongoDB 一会儿 PostgreSQL。技术栈没有锁定，项目就在漂移中失去一致性。
03 善意破坏
AI 重构时会清理它认为多余的代码，事后才发现那段代码有用。善意的清理变成了破坏性操作。
04 永久技术债
要一个完整认证系统，AI 说先做简版登录、后续再加 OAuth。结果后续永远不会来，简版代码成了永久的技术债。
二、三种注入方式，谁活得最久
给 AI 传达约束有三种常见方式，区别在于同一条约束（「数据库用 PostgreSQL」）在不同时点是否还生效。
| 注入方式 | 第 1 轮 | 第 30 轮 | 新开对话 |
|---|---|---|---|
| 对话里临时交代 | ✅ 生效，刚说完还在窗口里 | ❌ 失效，早期消息被挤出窗口，AI 开始建议 SQLite | ❌ 上下文清零，要从头重说 |
| 写在 .env 或文档里 | ⚠️ 让 AI 自己去读，看运气 | ⚠️ 同上 | ⚠️ 同上 |
| 写进 Rule 文件 | ✅ 每轮对话开始前自动加载 | ✅ 仍然生效 | ✅ 仍然生效 |
对话交代的宿命： 约束跟着对话走，对话一长或一换就丢。开头说了「用 PostgreSQL」，聊了 30 轮后 AI 突然建议换库，因为那句话已经不在窗口里了。
三、一个 Rule 文件长什么样
frontmatter 控制生效方式：
---
alwaysApply: true # 所有对话自动生效
---
# 开发约束与配置规范
以下是用户重要的约束，请务必严格遵循。
true 用于全局编码规范；false 用于写作规范这类按需引用的文件，避免污染编码对话的上下文。
xs_vibe_rules 的三个文件
- rule-opensource.mdc： 主开发规范，14 个章节覆盖全流程
- writing-style.mdc： 中文写作风格，按需手动引用
- secrets.mdc： API Key 与凭据模板，占位符形式
使用时放入项目的 .cursor/rules/ 目录即可。整套规则原文全部开源（MIT License，仓库 itshen/xs_vibe_rules），Fork 一份放进项目，再按自己的技术栈删改，就是你的第一版 AI 协作规范。
本节要点
- 规则的价值不在于多，每条都解决一个真实问题。 AI 每反复犯一次错，就把它变成一条规则，这是整个专题的底层方法。
- 约束靠不靠得住，看的是注入机制： 写十遍「务必」，都比不过一个每轮自动加载的 Rule 文件。