Home

深色模式

三款 AI 工具复用规则 ​

概述 ​

在同一个项目里同时使用 Cursor、Claude Code、Codex，当然可以复用一部分 skill 和 rule，但不能把三家的配置文件当成同一种东西。

先把一句最容易说错的话改正：这三者都支持“长期指导”，但承载方式并不对齐。尤其是 Codex 里的 Rules，主要管的是沙箱外命令审批，不是项目编码规范；Cursor 的公开文档和 2026 年 1 月 22 日发布的 2.4 更新，对 Skills 的表述也不完全在一个重心上。先看清这些差异，再谈复用，后面就不会一边省事一边踩坑。

先看三者差异 ​

Claude Code：CLAUDE.md + rules + skills 分层最清楚 ​

Claude Code 把这几层分得比较明确：

  • CLAUDE.md 负责长期项目说明
  • .claude/rules/ 负责按主题、按路径拆开的规则
  • .claude/skills/ 负责可复用工作流
  • auto memory 负责会话外沉淀的经验

Anthropic 官方文档还专门提到：如果仓库已经在用 AGENTS.md，可以在 CLAUDE.md 里直接 @AGENTS.md，这样就不用重复维护两份项目说明。

这意味着 Claude Code 很适合做两层沉淀：

  • 项目事实放在 CLAUDE.md 或被它导入的共享文档里
  • 步骤型流程放进 SKILL.md

Cursor：Rules 仍是稳定主轴，Skills 已经进入产品面 ​

截至 2026 年 4 月 7 日，Cursor 的公开资料有两个值得注意的信号。

第一，官方文档仍把 Rules 放在最前面，强调：

  • .cursor/rules/ 是项目级规则
  • User Rules 是全局规则
  • AGENTS.md 是更简单的替代方案
  • .cursorrules 还兼容，但已经是 legacy

第二，Cursor 2.4 的官方更新和产品页已经把 Skills 推到台前。2.4 更新明确写到：Cursor 已支持 editor 和 CLI 中的 Agent Skills，SKILL.md 可以承载命令、脚本和任务说明；同时还强调，Skills 更适合动态发现和步骤型 how-to，Rules 更适合 always-on 的声明式约束。

所以对 Cursor，比较稳的理解是：

  • 规则系统：仍然以 .cursor/rules/ 为主
  • 简单兼容入口：AGENTS.md
  • 可复用工作流：新能力已经明显往 Skills 走

如果团队追求稳定、可审阅、容易 onboarding，Cursor 这一侧优先用 .cursor/rules/ 落项目规范，往往更省心。

Codex：AGENTS.md 和 Skills 都有，但 Rules 不是同一个概念 ​

Codex 这边最容易混淆的点，就是 Rules 这个词。

OpenAI 官方文档把三件事拆得很清楚：

  • AGENTS.md：项目长期指令链
  • Skills：可复用工作流，基于 open agent skills standard
  • Rules：控制哪些命令可以在沙箱外执行，当前还是 experimental

也就是说，Codex 的 Rules 更接近“命令放行规则”，不是“代码风格规则”。真正承载项目规范的还是 AGENTS.md；真正承载步骤化套路的，是 .agents/skills/ 下的 skills。

另外，Codex 的 AGENTS.md 支持从全局到项目再到子目录逐层发现与拼接，这一点比 Cursor 当前公开文档里的 AGENTS.md 更强，也更适合在 monorepo 里分层写规则。

先下结论：能复用的是内容，不是壳子 ​

在这三套工具里，真正适合复用的是下面这些东西：

  • 项目背景
  • 目录结构说明
  • 编码约定
  • 提交与发布流程
  • 常见排错步骤
  • 代码评审 checklist
  • 某类任务的 SOP
  • skill 背后的脚本、模板、示例

不适合直接原样复用的，是这些东西：

  • .cursor/rules/*.mdc 的元数据格式
  • Claude Code 的 CLAUDE.md / .claude/rules/ 组织方式
  • Codex 的 Rules 文件
  • 三家对 SKILL.md frontmatter 的具体字段和触发机制

一句话说，复用的是“知识和流程”，不是“文件格式和产品名词”。

最稳的复用方式 ​

比较稳的办法，不是只维护一份超大 AGENTS.md，而是做成两层。

共享内容层 ​

先把项目共识写成中立文档，例如：

text
/docs/ai/project-context.md
/docs/ai/coding-style.md
/docs/ai/workflows/code-review.md
/docs/ai/workflows/release.md
/docs/ai/workflows/bugfix.md

这里放的是“人和工具都看得懂”的长期内容：

  • 仓库结构
  • 技术栈边界
  • 命名规范
  • 构建和测试命令
  • 哪些目录不要改
  • 典型任务流程

这层应该是唯一真源。

工具适配层 ​

然后给三家各自留一个很薄的入口。

Claude Code ​

text
CLAUDE.md
.claude/rules/
.claude/skills/

CLAUDE.md 里只放两类内容：

  • 导入共享文档
  • Claude 专属补充

例如：

md
@AGENTS.md
@docs/ai/project-context.md
@docs/ai/coding-style.md

## Claude Code

- 复杂改动优先进入 plan mode

Codex ​

text
AGENTS.md
.agents/skills/

AGENTS.md 作为 Codex 的项目入口，适合放：

  • 共享文档的摘要或索引
  • Codex 专属执行约束

例如：

md
请先阅读：
- docs/ai/project-context.md
- docs/ai/coding-style.md
- docs/ai/workflows/code-review.md

额外要求：
- 修改前先确认工作目录
- 只在明确需要时申请越权命令

Cursor ​

text
.cursor/rules/
AGENTS.md

Cursor 最稳的一层仍然是 .cursor/rules/。这里不要把整份项目手册硬拷进去，最好拆成几条小规则：

  • 00-project.mdc
  • 10-style.mdc
  • 20-review.mdc

每条规则只负责一个主题，并引用共享文档或摘录必要片段。

如果团队还想兼容 Cursor CLI 或希望和其他 agent 共用一个基础说明，可以保留根目录 AGENTS.md，但不要把复杂作用域全压在它身上。Cursor 公开文档当前仍把它当作简单替代方案来看待。

skill 怎么复用 ​

skill 能复用，但要分成两种情况看。

可以直接复用的部分 ​

这部分通常和平台无关：

  • workflow 描述
  • checklist
  • 模板文件
  • 示例输出
  • 辅助脚本
  • 参数说明
  • 触发场景描述

比如“修复 CI 失败”这个 skill，不管在哪家工具里，核心步骤都差不多：

  1. 收集失败日志
  2. 定位失败类型
  3. 在最小范围内修复
  4. 重新验证
  5. 输出变更说明

这些内容应该写成共享材料，而不是直接埋进某一家私有格式里。

不能盲目共用的部分 ​

这部分通常和平台实现绑定：

  • frontmatter 字段名
  • 自动触发规则
  • 工具白名单
  • 子代理执行方式
  • slash command 暴露方式
  • 目录扫描位置

Claude Code 和 Codex 都明确提到技能体系建立在 open agent skills standard 之上，这让二者之间的 skill 迁移更顺手一些。Cursor 现在也已经公开支持 SKILL.md，但它的公开资料更强调产品能力和 marketplace，不能想当然地假设三家的字段、目录和触发行为已经完全一致。

比较稳的做法是：

  • 共享 skill 的正文、模板、脚本、示例
  • 每个工具单独写一层很薄的 SKILL.md
  • 不把工具私有字段混进共享正文

一套能长期维护的目录 ​

下面这类结构，通常比“三套配置各写各的”更耐用。

text
docs/
  ai/
    project-context.md
    coding-style.md
    workflows/
      bugfix.md
      code-review.md
      release.md
    skills/
      fix-ci/
        README.md
        checklist.md
        examples/
        scripts/

AGENTS.md
CLAUDE.md

.cursor/
  rules/
    00-project.mdc
    10-style.mdc
    20-review.mdc

.claude/
  skills/
    fix-ci/
      SKILL.md

.agents/
  skills/
    fix-ci/
      SKILL.md

如果团队已经开始使用 Cursor Skills，也可以再加：

text
.cursor/
  skills/
    fix-ci/
      SKILL.md

但建议把这层看成适配层，而不是唯一真源。

一份内容，三套薄入口 ​

实际落地时，可以按下面这个分工来维护。

内容类型最好放哪Claude CodeCursorCodex
项目背景docs/ai/project-context.mdCLAUDE.md 导入rule 引用或摘录AGENTS.md 引用或摘录
编码规范docs/ai/coding-style.md.claude/rules/ 或导入.cursor/rules/AGENTS.md
复杂任务流程docs/ai/workflows/*.md.claude/skills/Skills 或 Commands.agents/skills/
简单全局说明根目录入口文件CLAUDE.mdAGENTS.md 可兼容AGENTS.md 主入口
命令审批策略工具私有配置settings / permissionseditor / CLI 权限设置Rules

这张表里最重要的一行是最后一行：命令审批策略不要和项目编码规范混在一起。尤其在 Codex 里，Rules 真的是权限规则，不是写作风格指南。

不建议这样做 ​

把三家的规则全写进一个文件 ​

短期省事，长期很容易变成提示词回收站。人不想看，模型也容易吃到互相冲突的约束。

把 Cursor 的 .mdc 当通用格式 ​

.mdc 很适合 Cursor，但 Claude Code 和 Codex 不认识这套元数据。它只能当适配层，不能当共享层。

把 Codex 的 Rules 当“项目规则” ​

这是最常见的误解。Codex 的项目说明应该进 AGENTS.md 或 skills，不应该塞进命令越权规则里。

指望一份 SKILL.md 在三家完全等价 ​

即便都叫 SKILL.md，也别默认字段、触发、工具权限、目录发现完全一致。先共享正文，再做薄包装，才是稳的。

什么时候值得做这套复用 ​

如果团队只是偶尔换工具，手工同步几份规则也还凑合。

但只要出现下面两种情况，这套分层就很值：

  • 同一个项目里长期混用 Cursor、Claude Code、Codex
  • 团队已经开始沉淀自己的 review、release、debug、oncall 流程

因为真正贵的不是写一份文件，而是后面每次规则更新时，三套说明一起漂移。

参考 ​