结论先行
开始一个 Vibe Coding 项目，第一步不是输入需求，而是先写规则文件。
这份规则文件就像项目的”宪法”——它告诉 AI：哪些事能做、哪些事不能做、用什么技术栈、遵循什么风格。没有这份宪法，AI 就像一个没有边界感的新员工，可能把项目搞得一团糟。
什么是 LLM 宪法
LLM 宪法，就是你写给 AI 的一组项目级规则，通常存放在项目根目录的 CLAUDE.md 或 AGENTS.md 文件中。
打个比方：如果 Vibe Coding 是让 AI 帮你装修房子，那宪法就是你提前画好的装修图纸加施工规范。你不需要盯着每一锤子，但你得让工人知道——墙不能乱拆、电线要走暗线、卫生间必须防水。
宪法的核心作用有三个：
- 划定边界 —— AI 不会乱装包、乱建目录、乱引入依赖
- 统一风格 —— 整个项目保持一致的代码风格和架构决策
- 持久记忆 —— AI 在整个项目生命周期里都能”记住”这些约定，不会聊着聊着就忘了
为什么需要宪法
LLM（Large Language Model，大语言模型）在执行任务时，本质上是在一个巨大的”解空间”（所有可能的解决方案集合）里探索。没有约束时，它可能：
- 选了一个过于复杂的架构方案
- 引入了你不需要的依赖
- 每次对话风格和决策都不一致
- 把文件结构搞得混乱不堪
宪法的作用，就是缩小解空间。就像在迷宫里预先封住那些死胡同，让 AI 只在合理的路径上探索，大幅提高效率。
更重要的是，AI 对话是有上下文窗口限制的。随着对话越来越长，早期的口头约定很容易被”遗忘”。而规则文件是每次对话开始时都会被加载的，相当于给 AI 植入了”长期记忆”。
宪法应该写什么
一份好的 LLM 宪法通常包含以下内容：
| 维度 | 作用 | 示例 |
|---|---|---|
| 项目目标 | 让 AI 理解”我们在干什么" | "本仓库用于个人知识管理” |
| 技术栈约束 | 避免 AI 乱选技术 | ”脚本用 bun + TypeScript，应用用 Next.js” |
| 目录规范 | 保持结构清晰 | ”工具安装在 ./tools/ 下，数据存放在 ./data/ 下” |
| 风格偏好 | 统一输出质量 | ”代码注释用中文，变量命名用英文” |
| 行为红线 | 防止 AI 越界 | ”不要引入未经确认的第三方服务” |
| 数据策略 | 控制信息质量 | ”只保留高质量内容，避免存储垃圾数据” |
实战示例
下面是一个真实的 Vibe Learning（用 AI 辅助学习和信息管理）项目的宪法示例。我会在项目初始化时把这段话发给 Claude，让它据此生成 CLAUDE.md 和 AGENTS.md：
本仓库是用来做 vibe learning 的，所有的 MCP、Skills 等尽量安装在
本目录下的合适子目录里，控制好结构，避免上下文爆炸。整体设计要尽量
克制，不要复杂，目录要清晰、干净。
你需要把主流媒体平台的 CLI 工具尽量接进来，我是要从这里获取大量
资讯的。我现在推荐了一个 opencli，其他的你可以自己去互联网找一找，
选那些真正有用的工具。抓回来的内容可以考虑存到本地，但一定要克制，
不要把一堆垃圾数据搬进来，尽量只留下高质量的信息。
我本身也在做自媒体，会在微博、即刻和 X 上发内容，所以你需要在这个
仓库里沉淀我的风格、规则、偏好，甚至可以主动去分析我各个平台的内容
表现。所有要发布的内容，也需要在这里有一个沉淀和演化的过程。
有一类资讯是适合做 daily 或 weekly 学习的，这类内容需要重点处理。
你要记录数据源，并设计一个定时拉取策略，把这些高质量内容持续沉淀到
本地。本地存储尽量用 MD 格式，同时把关键附件也管理好。
如果涉及脚本处理，技术栈优先用 bun，可以直接跑 typescript。如果
要做应用，尽量用 Next 或 Nuxt，保持简单。数据库本地用 sqlite，
同时要预留 mysql 的 adapter。能用 CLI 的地方优先用 CLI，不要一
上来就用 MCP。同时要定期 review 我的规则文件，看哪些需要合并、
归档，做好短期记忆和长期记忆的分层，在使用的时候也要有召回机制。
还有一件事，我每次写的 prompt，你要帮我做定期整理，可以按天输出
一份，把里面值得沉淀的表达、模式抽出来，慢慢变成长期资产。整个仓库
用 git 管理，所有内容都是可演进、可回溯的。
将以上内容，拆解后，根据 Claude 官网的最佳实践，初始化写入到本仓库
的 CLAUDE.md 和 AGENTS.md。你会发现，这段话里没有一行代码，但它涵盖了：目标定义、技术栈选型、目录策略、数据质量标准、记忆管理机制。这些就是”宪法条款”。
AI 收到这份宪法后，会据此生成结构化的规则文件，后续所有操作都会受此约束。
常见误区
误区一：宪法写得越长越好
不是。宪法应该精炼、有重点。写太多反而会让 AI “抓不住重点”，因为它需要在有限的上下文窗口里权衡所有规则。
建议：核心规则控制在 20 条以内，按优先级排列。
误区二：写完宪法就万事大吉
宪法不是一成不变的。随着项目演进，你需要定期 review 和更新规则。就像法律也需要修订一样。
建议：每周花 5 分钟看看 AI 的行为有没有偏离预期，及时调整规则。
误区三：把具体实现步骤写进宪法
宪法是”原则”，不是”操作手册”。你应该告诉 AI “用 TypeScript”，而不是告诉它 “第一步创建 tsconfig.json，第二步…”。
建议：宪法定方向，具体实现交给 AI 自己决策。
误区四：不给宪法直接开干
这是最常见的问题。很多人觉得”AI 那么聪明，随便说句话就能搞定”。结果三轮对话下来，项目目录已经面目全非，想回头重来代价更大。
建议：哪怕是一个小项目，花 5 分钟写几条规则，都能省下后面 50 分钟的返工。
总结
Vibe Coding 的核心理念是让 AI 替你写代码，但”替你写”不等于”随便写”。宪法机制的本质是：
- 用最小的前期投入，换取整个项目周期的一致性和可控性
- AI 在有约束的解空间里探索，效率远高于无约束的自由发挥
- 规则文件是 AI 的”长期记忆”，解决了对话上下文容易丢失的问题
一句话总结：先立规矩，再动手。磨刀不误砍柴工。
FAQ
Q: 规则文件应该放在哪里？
对于 Claude Code，放在项目根目录的 CLAUDE.md 文件中。如果项目有多个子模块，可以在子目录下放 AGENTS.md 做局部规则。其他 AI 工具（如 Cursor）有各自的配置文件位置，原理相同。
Q: 宪法和 System Prompt 有什么区别？
System Prompt 是每次对话开始时注入的系统指令，通常由工具平台管理。宪法（规则文件）是你自己维护的、存放在项目目录里的规则，它会被工具自动加载到上下文中。两者互补——System Prompt 管”通用行为”，宪法管”项目特定约束”。
Q: 我用 Cursor / Copilot，也能用这套思路吗？
可以。Cursor 有 .cursorrules 文件，GitHub Copilot 有 .github/copilot-instructions.md，原理完全一样——都是用项目级的规则文件来约束 AI 行为。
Q: 多人协作项目，宪法谁来维护？
建议提交到 Git 仓库，和代码一起版本管理。团队成员都可以提 PR 修改规则，就像修改代码规范文档一样。