夜雨聆风你有没有这样的经历？
打开 Cursor，输入一段 prompt：「帮我写一个用户注册模块」，AI 噼里啪啦生成了一堆代码。跑起来一看，数据库字段跟你的表对不上，密码居然存明文，路由命名风格跟项目已有代码完全两套。
这就是 Vibe Coding 的典型困境——你和 AI 各有各的「感觉」，没人说得清标准是什么。
Vibe Coding 好用，但不够用
从无序到有序的转变
Vibe Coding 是 Andrej Karpathy 在 2025 年提出的说法，意思是「凭感觉让 AI 写代码」——你描述需求，AI 生成，不行就再聊，反复迭代。
这种方式在探索阶段很爽：写个原型、试个想法、验证个方案，几分钟搞定。但一旦项目复杂度上来，你会发现几个致命问题：
代码风格不一致。AI 每次生成的变量命名、文件组织方式都在变，一个项目看起来像五个人写的。
重复犯同样的错。你刚纠正了「不要用 default export」，下次它照犯。聊天记录里的约束，不会自动带到下一次对话。
协作困难。你和 AI 的对话是私有的，队友接手项目时只能看源码猜意图。
什么是 Spec Coding
一份规则，多工具共享
Spec Coding（规格驱动开发）的核心思想很简单：在让 AI 写代码之前，先给它一份「规则说明书」。
这份说明书不是需求文档，也不是 README，而是一份告诉 AI 「在这个项目里怎么写代码」的规则文件。它是常驻的、版本化的、所有 AI 交互共享的项目上下文。
目前主流 AI 编程工具都支持这类文件：
- Cursor
： .cursorrules或.cursor/rules/目录 - Claude Code
： CLAUDE.md（支持多层级：用户目录 → 项目根 → 子目录） - GitHub Copilot
： AGENTS.md和.github/copilot-instructions.md - Windsurf
： .windsurfrules
叫法不同，做的事情一样——给 AI 一个「项目大脑」，让它带着你的约束和偏好来写代码。
一份好的 Spec 文档长什么样
Spec 文档结构大纲
实践下来，一份高效的 Spec 文档通常包含以下模块：
1. 项目概览（2-3 句话）
告诉 AI 这是什么项目、用什么技术栈。不用写公司历史，只要事实。
## Project Next.js 15 (App Router) + TypeScript 5.7 + Tailwind CSS v4 数据库用 PostgreSQL，ORM 是 Drizzle，部署在 Vercel。2. 代码风格规则
这是 Spec 的核心。每条规则必须具体、可验证——如果你没法看着一行代码说「它符合/违反了这条规则」，说明写得太模糊了。
## Code Style - 使用 named export，禁止 default export - interface 优于 type（定义对象形状时） - 组件默认用 Server Component，只在需要交互时加 'use client' - 变量命名用 camelCase，组件用 PascalCase - 异步函数统一用 async/await，不用 .then() 链反面教材：「写干净的代码」——这等于什么都没说。
3. 目录与文件约定
AI 最容易犯的错之一是把文件放错位置。明确告诉它：
## File Structure - API 路由放 src/app/api/ - 数据库 schema 放 src/db/schema/ - 公共 UI 组件放 src/components/ui/ - 工具函数放 src/lib/utils/ - 每个功能模块独立目录，包含 components/、hooks/、types/ 子目录4. 禁止清单（最有效的部分）
AI 对「不要做什么」的指令遵从度特别高。把你踩过的坑都列上来：
## Never Do - 禁止使用 TypeScript enum，用 as const 对象替代 - 禁止 console.log 留在提交代码中 - 禁止超过一层的相对路径引用，用 @/ 别名 - 禁止在 Server Component 中使用 useState/useEffect - 禁止不经确认就删除文件或大规模重构5. 测试要求
## Testing - 每个新工具函数必须有测试，放在同级 __tests__/ 目录 - 使用 Vitest，外部服务用 msw mock - 提交前运行 pnpm test 确认通过6. Git 规范
## Git - commit message 用祈使句，不超过 72 字符 - 禁止 force push 到 main - 每个 PR 对应一个功能，保持原子性7. 遇到不确定的情况怎么办
## When Unsure - 先查项目中已有的同类实现，跟着现有模式走 - 不确定时先问，不要自己发挥 - 大的架构改动先写 plan，确认后再动手实际工作流：怎么用起来
四步实操流程
第一步：从五条规则开始
不要试图一次写完整本规则。先回忆一下：过去一周你手动修正 AI 代码最多的问题是什么？把这前五个问题变成规则，放进 Spec 文件。
第二步：在 AI 犯错时即时更新
每次你发现 AI 又犯了同一个错，就加一条规则。Cursor 官方的建议是：只在发现 AI 重复犯同样错误时才加规则。规则不是越多越好，100-300 行是多数项目的合理范围。
第三步：配合 Plan Mode 使用
在 Cursor 中按 Shift+Tab 进入 Plan Mode，让 AI 先根据 Spec 做一份实现计划，确认后再写代码。如果结果不满意，回退并优化计划，而不是在烂代码上反复修补——这通常更快。
第四步：团队共享，版本管理
Spec 文件应该跟代码一起 commit 到 Git。这样每个队友的 AI 助手都遵守相同规则，新人上手时也能快速理解项目约定。当项目引入新模式时，在同一个 PR 里更新 Spec。
进阶技巧
分层规则管理
分层管理：Claude Code 支持从用户目录到子目录的多层 CLAUDE.md。你可以在根目录放全局约定，在 src/api/ 下放 API 层专属规则，在 src/components/ 下放 UI 规则。Cursor 的 .cursor/rules/ 也支持按文件模式匹配作用域。
引用而非复制：Spec 里写「样式规范见 src/styles/README.md」，而不是把整个规范贴进来。复制的内容会过时，引用能保持同步。
跨工具统一：如果团队同时有人用 Cursor、Claude Code 和 Copilot，维护一份 rules.base.md 作为主源，用简单脚本分发到各工具各自的规则文件。核心内容 90% 是通用的。
优先级排序：AI 对文件顶部的规则注意力更高。把最关键的约束放在最前面。如果某条规则总被忽略，试试把它移到更靠前的位置，或者改写成禁止句式。
从 Vibe 到 Spec，不是对立而是进化
Vibe Coding 不是错的——它依然是启动一个想法、快速验证原型的最佳方式。但当你准备把代码做成可维护、可协作的真实项目时，需要 Spec 文档来兜底。
这两种方式的关系是「先 Vibe，后 Spec」：用 Vibe Coding 的速度起步，用 Spec Coding 的规则收束。就像爵士乐手即兴演奏也需要和弦谱一样——自由发挥的前提是有共识的框架。
今天就打开你的项目，新建一个 .cursorrules 或 CLAUDE.md，写上五条你最希望 AI 遵守的规则。你会发现，从此 AI 写的代码，终于像是「你的项目的一部分」了。