做 Vibe coding 少不了见到 .cursorrules 和 .github/copilot-instructions.md 这两个文件。前者是 Cursor 专属的，后者是 VS Code / Copilot 专属的。
它们里面存储的，是在当前项目里 AI 生成代码的基本原则。AI 生成代码的时候，就会以这些原则为基础。
没有这两个文件，代码照样能够生成。但是它们可以显著提升代码质量，尤其在多人协作的项目中，它们可以明显提升代码质量，保证代码风格和质量的一致性。
这两个文件被吹得神乎其神，甚至有人把它们称为 Vibe Coding 的“宪法”。但归根结底，它们其实就是一段固定的提示词而已。
Vibe Coding 的时候有一个很大的问题，就是上下文常常会丢失。
AI 并不能完全记得之前的内容。随着对话轮数变多，AI会丢失很多信息。
我自己的项目里就遇到过，AI 不记得如何启动我的项目。即使最初的启动脚本就是它生成的，它依然会尝试找出启动项目的方式，对自己生成的脚本不屑一顾。即使我提醒它，过不了几轮，它就又会把这件事情忘掉。
更不要说给它指定的各种代码规范了。
这时，就需要这种项目标准文件出场了。
所以，在这两个文件里存储的内容，也必须是对全局项目有效的指导原则。所有的个人特色，如果你是在团队中开发，个人偏好相关的内容，最好都不要上传到这个文件里，以免影响其它人的代码生成（有用户级配置可以存放自己的内容）。
虽然作用很大，但本质上，它仍然就是一个提示词。
大模型是没有记忆的。所谓的上下文，实际上都是把内容压缩（截断或者摘要）之后，连着本次的提示词一起给到 AI，生成的结果就好像它还记得之前的事情一样。
在这种情况下，我们每次给它的固定提示词，就必须要尽可能地简短精炼，因为过多会非常浪费 token，也就意味着会多花钱（随着提示词缓存的出现，这一点得到了有效缓解）。而且提示词过长、内容过多，也会造成注意力分散，让 AI 没有办法达到最好的效果。
所以这种项目标准文件也必须精炼简洁。
而且因为它的影响范围很大，所以也不能允许所有人随意修改。
实际上，这种上下文的存储方式，我们在很多 AI 应用里都会遇到。
大多数网页的 AI 聊天界面（比如 ChatGPT 或者 Gemini），它们都会有一个地方让你设置一些内容，有的是设定 AI 的身份，有的是设定自己的资料。这些实际上和这两个项目文件有着相同的作用：固定的提示词内容。
在 OpenClaw 里面，也有一些 MD 文件，比如SOUL.md、AGENTS.md、MEMORY.md 等等。它们的作用各不相同，但是本质上来说，它们最终的使用方式从根本上还是一样的：组合固定的内容发给大模型。
明确了这一点之后，就会发现，其实所有的工程化 AI 开发、Vibe Coding 应用都并没有什么神秘的。
它们都只是一种提示词工程的变化而已。
当然，工程化不仅仅意味着提示词本身。通过这种方式定义的“预设”提示词，会在不同的场景和流程中注入不同的内容，从而达到最优化 AI 产出的效果。
了解它们的作用方式，有利于我们从更高的视角，来优化 Vibe Coding 的质量。
注1: .cursorrules 是集中存储方式，官方已经开始用 .cursor/rules/ 目录取代。
注2: 关于Vibe Coding 实战的更多内容，详见我的置顶。
