导读
如果你只用一个 AI 编程工具，这篇可以跳过。
但现实往往是：终端里跑 Claude Code，编辑器里开着 Cursor，仓库里挂着 Copilot，偶尔还试试 Codex、Windsurf、Cline。每换一个工具，你就得重写一遍同样的项目规则------用什么框架、代码风格怎么定、哪些目录别碰。同一句话，你可能已经在五个不同格式、五个不同位置的文件里各抄了一遍。
有个叫 Ruler 的开源仓库在解决这件事。但比它本身更有用的，是它顺手整理出来的一份对照表：32 个主流 AI 编程工具，各自的配置文件到底叫什么、放在哪。 这份表本身就值得存下来。
先说它是什么
Ruler 的定位是给所有 AI 编程助手的指令做一个中心来源。你把规则写在一个 .ruler/ 目录里，跑一条 ruler apply，它负责按每家工具的格式翻译好、写进对应位置。改一处，全网同步。
bash
npm install -g @intellectronica/ruler
ruler init # 生成 .ruler/ 目录和 ruler.toml
ruler apply # 分发到所有配置好的工具这个思路不新鲜，Terraform 对基础设施、dotfiles 对 shell 配置都是一个套路：把散落各处、格式不一的配置，收敛成一份可以版本管理的源头。 值不值得为它装个工具，取决于你手上工具的异构程度，后面会讲。
更值钱的是这张表
我把 Ruler 支持的 32 个工具的配置映射整理成下面这张表。哪怕你根本不打算用 Ruler，这张表也能帮你在任何一个工具里，一眼找到该去哪写规则、该去哪配 MCP。
| 工具 | 规则文件 | MCP 配置 |
|---|---|---|
| Claude Code | CLAUDE.md |
.mcp.json |
| GitHub Copilot | AGENTS.md |
.mcp.json |
| Cursor | AGENTS.md |
.cursor/mcp.json |
| Windsurf | AGENTS.md |
.windsurf/mcp_config.json |
| OpenAI Codex CLI | AGENTS.md |
.codex/config.toml |
| Gemini CLI | AGENTS.md |
.gemini/settings.json |
| Aider | AGENTS.md / .aider.conf.yml |
.mcp.json |
| Cline | .clinerules |
--- |
| Amazon Q CLI | .amazonq/rules/*.md |
.amazonq/mcp.json |
| Firebase Studio | .idx/airules.md |
.idx/mcp.json |
| Qwen Code | AGENTS.md |
.qwen/settings.json |
| RooCode | AGENTS.md |
.roo/mcp.json |
| Kilo Code | AGENTS.md |
.kilocode/mcp.json |
| OpenCode | AGENTS.md |
opencode.json |
| Zed | AGENTS.md |
.zed/settings.json |
| Warp | WARP.md |
--- |
| Crush | CRUSH.md |
.crush.json |
| Goose | .goosehints |
--- |
| Trae AI | .trae/rules/project_rules.md |
--- |
| Kiro | .kiro/steering/*.md |
.kiro/settings/mcp.json |
| JetBrains AI | .aiassistant/rules/AGENTS.md |
--- |
（完整 32 项含 Jules、Amp、Junie、AugmentCode、Factory Droid 等，见仓库 README。）
盯着这张表看一会儿，会看出一些平时被工具切换掩盖掉的规律。
从这张表能读出的三层分裂
AI 编程工具的配置乍看一团乱麻，其实清清楚楚分了三层，每一层的成熟度完全不同。
第一层：规则文件，正在收敛。 这张表里，一多半工具的规则文件已经统一叫 AGENTS.md------Copilot、Cursor、Codex、Windsurf、Aider、Gemini、Zed、OpenCode 全都认它。这不是巧合，AGENTS.md 正在成为跨工具的事实标准。少数几个还守着自己的名字：Claude 的 CLAUDE.md、Warp 的 WARP.md、Cline 的 .clinerules。规则这一层，行业已经快打通了。 意味着你写一份 AGENTS.md，对大半工具直接生效，Ruler 在这层能帮的其实有限，几个软链接也能凑合。
第二层：MCP 配置，还在各自为政。 往右边一列看，画风突变：.mcp.json、.cursor/mcp.json、.codex/config.toml、.gemini/settings.json、opencode.json......有的是 JSON，有的是 TOML，有的塞进通用 settings 里，路径没有一个对得上。这层是纯粹的混沌，也是 Ruler 最难被替代的地方。 因为软链接只能让两个文件字节相同，做不了 JSON 到 TOML 的格式翻译，更做不了把一份 MCP 定义拆分写进十种结构。
第三层：Skills 和子代理，刚刚冒头。 表里没列全，但仓库已经在试验把技能包和可委派的子代理也分发出去，路径同样五花八门（.claude/skills/、.cursor/skills/、.agents/skills/）。这层还在早期，标准远未形成。
这三层放在一起，就是一个能反复用的判断框架：规则层看标准化程度，MCP 层看格式转换需求，Skills 层看它还在不在实验期。 你面对任何一个新冒出来的 AI 编程工具，套这三层去问，就知道它的配置该怎么接、值不值得纳入统一管理。
那到底要不要用 Ruler
有了三层框架，这个问题就不用拍脑袋了。
只用两三个工具、而且都吃 AGENTS.md 的 ------大概率不用装。写一份 AGENTS.md，需要的地方做几个软链接，比引入一个新依赖清爽。规则层已经帮你收敛好了，Ruler 在这里是过度工程。
同时管一堆异构工具、还重度用 MCP 的------这才是 Ruler 的主场。第二层那片 JSON/TOML 混沌，手动同步迟早出错，它的格式翻译和合并策略是真省事。
团队协作、想把 AI 规则纳入版本管理的 ------它顺带把生成的配置文件自动加进 .gitignore，避免每个人本地生成的文件互相污染，这个细节挺贴心。
Ruler 目前还挂着 Beta 的牌子，作者是 Eleanor Berger，MIT 协议。真要上手前，建议先用 --dry-run 空跑一遍看它打算改哪些文件，别让它直接覆盖你手写的配置。
说到底，一个工具能不能帮你，先看它替你收敛的是哪一层的乱。规则层的乱，行业自己快抹平了；MCP 那层的乱，眼下还得靠 Ruler 这类东西兜着。 而这张对照表最大的用处，是让你不管用不用它，都能随时知道自己该往哪写。