现在很多人做 AI 编程，不会只用一个工具。写前端可能开 Cursor，处理长任务可能用 Claude Code，自动化维护项目又会用 Codex。问题也随之出现：同一个项目，规则散在 Cursor Rules、CLAUDE.md、AGENTS.md 里，工具读到的要求不一样，最后就容易出现“这边说要跑测试，那边直接改完就结束”。
这篇文章讲的不是重新写一套项目规范，而是把已有规则迁移成一套可同步、可维护、可验证的项目规则。你可以先看 AI编程工具专题 了解工具选择，再配合 老达AI实践专题 里的工作流文章一起用。
先判断哪些规则值得迁移
不是所有提示词都应该进项目规则。很多人把“你是资深工程师”“请认真检查代码”这类句子写进每个工具配置，结果规则很长，但真正有用的信息很少。
值得迁移的规则通常有四类：
- 项目事实：技术栈、目录结构、启动命令、测试命令、部署方式。
- 行为约束：不要改哪些文件、不要提交密钥、不要跳过验证。
- 协作偏好：改动前先说明计划，改动后给出验证结果和风险。
- 交付标准：什么算完成，哪些检查必须通过，失败时如何汇报。
如果一条规则只是在表达态度，删掉也不会影响工具行为；如果它能改变文件选择、命令执行、风险判断或最终交付，就应该保留下来。
把规则分成通用层和工具层
迁移时最重要的一步，是不要把所有内容复制到三个文件里。否则后面只要改一处，很快就会出现版本不一致。
更稳的结构是：先建立一个通用规则层，再给不同工具保留少量适配层。通用层放项目事实、目录说明、测试命令和安全边界；工具层只写各自读取规则的方式、交互习惯和特殊限制。
例如，一个项目可以这样分：
- 通用规则：README、docs/project-rules.md 或 .rules/overview.md。
- Cursor Rules：强调代码风格、文件匹配、编辑器内补全和局部修改。
- CLAUDE.md：强调任务规划、长会话上下文、测试验收和项目记忆。
- AGENTS.md：强调自动化执行、权限边界、发布流程和最终汇报格式。
如果你还没做过规则分层，可以先读 AI编程项目规则怎么分层。那篇文章讲“放在哪里”，这篇更偏“已有规则怎么迁移和同步”。
从 Cursor Rules 迁移时保留文件范围
Cursor Rules 经常会绑定特定目录或文件类型，比如前端组件、后端接口、测试文件。迁移到 Claude Code 或 Codex 时，不要只复制文字，要保留它原本的适用范围。
比如 Cursor 里有一条规则只作用于 src/components/**，迁移时应该写成“修改前端组件时遵守以下规则”，而不是放到全项目通用规则里。否则工具可能把组件规则错误套用到脚本、配置或后端接口。
旧文 Cursor Rules怎么写 里提到过，规则要尽量贴近真实文件和工作流。迁移时也一样，越能说明范围，越不容易误导工具。
从 CLAUDE.md 迁移时提炼长期记忆
CLAUDE.md 里常见两类内容：一类是长期有效的项目记忆，另一类是某次任务的临时要求。迁移时不要把临时任务也塞进通用规则，否则下次工具可能继续执行已经过期的目标。
建议你逐条标记：
- 长期有效：项目结构、命令、代码风格、测试策略、安全边界。
- 阶段有效：当前重构方向、近期迁移计划、临时兼容要求。
- 已经过期：某次修复、某个实验、已经关闭的需求。
长期有效的内容可以迁入通用规则；阶段有效的内容放到任务说明或当前迭代文档；已经过期的内容直接删掉。关于 CLAUDE.md 的写法，可以回看 Claude Code 项目记忆怎么写。
AGENTS.md 更适合写自动化执行边界
AGENTS.md 经常用于 Codex 这类自动化任务环境。它不只告诉工具“项目是什么”，还要告诉它什么时候可以动手、怎么验证、最终怎么汇报。
如果要把规则迁移到 AGENTS.md，重点应该放在执行边界：
- 哪些命令可以直接运行，哪些命令需要谨慎。
- 修改前是否必须读取某些项目流程或发布规范。
- 生成文件、发布文章、上传图片时有哪些固定检查。
- 最终回复必须包含哪些链接、状态和异常项。
拿内容站维护来说，AGENTS.md 里就应该明确：发布 WordPress 文章时正文不要写 h1，摘要、SEO meta、特色图 alt、站内链接和发布后检查都要完成。规则写得越具体，自动化越不容易只做半截。
同步时用一张对照表
迁移完成后，不要只靠记忆维护三个文件。建议建立一张规则对照表，列出每条关键规则在哪些工具里生效。
| 规则项 | 通用规则 | Cursor Rules | CLAUDE.md | AGENTS.md |
|---|---|---|---|---|
| 测试命令 | 保留 | 引用 | 保留 | 保留 |
| 前端组件规范 | 摘要 | 详细 | 按需引用 | 按需引用 |
| 发布后检查 | 保留 | 不一定需要 | 保留 | 详细 |
| 敏感文件限制 | 保留 | 保留 | 保留 | 保留 |
这张表的作用不是增加文档，而是避免“某个工具记得跑测试，另一个工具不知道”的断层。后面如果测试命令变了，你也知道要改哪些地方。
迁移后一定要做一次行为验证
规则迁移不是复制完就结束。你需要用一个低风险任务验证三件事：工具是否读到了规则，是否按范围修改，是否按要求汇报验证结果。
可以选一个小任务，比如修改一段文案、调整一个组件样式、补一个轻量测试。分别让 Cursor、Claude Code、Codex 执行或分析同一任务，看它们是否都遵守了项目边界。
如果某个工具仍然忽略规则，不要急着加长提示词。先检查规则是不是太抽象、范围是不是不清、命令是不是写错。AI编程的上下文问题，可以参考 AI编程上下文管理怎么做。
一份可直接复用的迁移清单
- 收集现有 Cursor Rules、CLAUDE.md、AGENTS.md 和 README 中的规则。
- 删除过期任务、空泛身份设定和重复表达。
- 把规则分成项目事实、行为约束、协作偏好和交付标准。
- 建立通用规则层，再为每个工具保留适配层。
- 保留文件范围、命令、权限边界和验收标准。
- 用规则对照表记录每条规则在哪些工具里生效。
- 用低风险任务验证工具行为是否一致。
老达点评：AI编程项目规则迁移的目标，不是让每个工具都背同一篇长文，而是让它们在关键行为上保持一致。该共用的规则沉到通用层，该适配的规则留在工具层，再用一次小任务验收效果。这样 Cursor、Claude Code 和 Codex 才能真正像一个团队，而不是三个各说各话的助手。
