为什么要给 AI 立规矩
Vibe Coding 指靠自然语言让 AI 直接产出代码的开发方式。它的问题出在质量：没有规矩的 AI 会返工、漏改、悄悄删代码、留下永久技术债。这一节先看事故长什么样，再看约束怎么注入才最稳。
下面四类事故在 AI 协作中反复出现，根源是同一件事：约束没有进入上下文。
理解偏差返工
AI 拿到需求就开始写，写了 200 行才发现理解有偏差，回滚重来。更糟的情况是改了 7 个文件之后才发现思路错了，逐个 revert 成本极高。
选型漂移
不同对话里 AI 会选不同框架：今天 Express，明天 Fastify。数据库一会儿 MongoDB 一会儿 PostgreSQL。技术栈没有锁定，项目就在漂移中失去一致性。
善意破坏
AI 重构时会清理它认为多余的代码，事后才发现那段代码有用。善意的清理变成了破坏性操作。
永久技术债
要一个完整认证系统，AI 说先做简版登录、后续再加 OAuth。结果后续永远不会来，简版代码成了永久的技术债。
同一句「帮我做个登录」，在无规矩和有规矩两种模式下会走向完全不同的结局。点击「下一步」，两条时间线同步推进。
给 AI 传达约束有三种常见方式。点击切换，看同一条约束（「数据库用 PostgreSQL」）在三个时点是否还生效。
frontmatter 控制生效方式
---
alwaysApply: true # 所有对话自动生效
---
# 开发约束与配置规范
以下是用户重要的约束，请务必严格遵循。true 用于全局编码规范；false 用于写作规范这类按需引用的文件，避免污染编码对话的上下文。
xs_vibe_rules 的三个文件
rule-opensource.mdc：主开发规范，14 个章节覆盖全流程writing-style.mdc：中文写作风格，按需手动引用secrets.mdc：API Key 与凭据模板，占位符形式
使用时放入项目的 .cursor/rules/ 目录即可。
itshen/xs_vibe_rules · 本专题的开源仓库
整套规则原文全部开源（MIT License）。Fork 一份，放进你项目的 .cursor/rules/ 目录，再按自己的技术栈删改，就是你的第一版 AI 协作规范。
规则的价值不在于多，每条都解决一个真实问题。AI 每反复犯一次错，就把它变成一条规则，这是整个专题的底层方法。约束靠不靠得住，看的是注入机制：写十遍「务必」，都比不过一个每轮自动加载的 Rule 文件。
素材来源：本专题基于作者开源仓库 itshen/xs_vibe_rules，内容为多个真实项目沉淀出的 Cursor Rules 与设计思考。