Cursor Rules 与 CLAUDE.md 实战：让 AI 按你的规范写代码

同一个模型，在两个项目里的表现可以天差地别，差别常常只在一份配置文件。这篇文章讲怎么写好这类文件，让 Cursor、Claude Code、Copilot 们产出符合你团队规范的代码。

三种文件各管什么

内容公式：事实 + 禁区 + 命令

写得好的规范文件有个共同结构：

• 事实：技术栈版本、目录职责、命名习惯——模型不知道的部分。
• 禁区：不许改的模块、不许引入的依赖、必须保持的兼容行为。
• 命令：构建、测试、格式化的确切命令——模型最常搞错的部分。

反例是写一堆「代码要优雅、测试要充分」式的空话，这些模型本来就会，写了只占上下文。

分层放置，越近越具体

CLAUDE.md 支持放在仓库根目录与子目录，子目录规则只在该目录生效。适合的用法是：根目录放全局约定，某个老模块目录下再放一条「这里不要用新语法」的局部规则。比把所有内容堆在一个大文件里有效得多。

维护比编写更重要

规范文件最常见的死法是过期：项目换了包管理器、目录重构了，文件还留着旧说法，模型照旧说明行事，比没有文件更糟。把「更新规范文件」写进相关改动的检查清单里，是成本最低的保鲜办法。

一个实用习惯：每次 AI 犯了「本可由规范避免」的错误，就把对应条目补进规范文件。文件会随项目一起进化。

不同工具的配置细节有差异，但「短、准、常更新」这三条是通用的。