Vibe Coding 的第一步，是写清边界
用自然语言做出第一个能跑的版本，同时把范围、验收线和变更记录写清。速度来自缩短循环，不是取消复核。
本页解决的问题
先给结论「Vibe Coding 的第一步，是写清边界」要解决的关键问题是什么？
用自然语言做出第一个能跑的版本，同时把范围、验收线和变更记录写清。速度来自缩短循环，不是取消复核。
简报是第一道安全闸门。 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 与设计思考。
从「四类典型事故」把感觉变成判断
「下面四类事故在 AI 协作中反复出现，根源是同一件事：约束没有进入上下文」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「AI 拿到需求就开始写，写了 200 行才发现理解有偏差，回滚重来。更糟的情况是改了 7 个文件之后才发现思路错了，逐个 revert 成本极高」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
- rule-opensource.mdc ：主开发规范，14 个章节覆盖全流程
- writing-style.mdc ：中文写作风格，按需手动引用
- secrets.mdc ：API Key 与凭据模板，占位符形式
漂亮不等于容易用
把「规则的价值不在于多，每条都解决一个真实问题。」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「四类典型事故」走到「理解偏差返工」
「四类典型事故」先把问题落在「下面四类事故在 AI 协作中反复出现，根源是同一件事：约束没有进入上下文」上；到了「理解偏差返工」，讨论继续推进到「AI 拿到需求就开始写，写了 200 行才发现理解有偏差，回滚重来。更糟的情况是改了 7 个文件之后才发现思路错了，逐个 revert 成本极高」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「四类典型事故」：下面四类事故在 AI 协作中反复出现，根源是同一件事：约束没有进入上下文
- 「理解偏差返工」：AI 拿到需求就开始写，写了 200 行才发现理解有偏差，回滚重来。更糟的情况是改了 7 个文件之后才发现思路错了，逐个 revert 成本极高
- 「最后的要点」：secrets.mdc ：API Key 与凭据模板，占位符形式
最后的「最后的要点」把讨论落到「secrets.mdc ：API Key 与凭据模板，占位符形式」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。