在空项目里让 AI 从零写个待办应用，人人都会觉得惊艳。真正的考验是另一件事：把 AI 编程工具接进一个已经有几万行代码、五年历史、无数隐性约定和历史包袱的真实项目，让它改对、不改坏。这一步做不好，AI 要么给出「教科书正确但和你项目格格不入」的代码，要么在它看不见的地方踩塌一片。
这篇文章不讲某个工具的按钮怎么点，而讲接入现有项目这件事本身该怎么准备：怎么把项目上下文喂给 AI、怎么划权限边界、三款主流工具各适合什么场景。
接入现有项目的成败，八成取决于你给 AI 提供了多好的项目上下文。
接入前：先让 AI「读懂」你的项目
现有项目和玩具项目的根本区别，是存在大量不在代码里明说的约定：这个项目用哪套状态管理、错误怎么处理、命名什么风格、哪些目录碰不得、构建和测试怎么跑。人类新同事靠几周熟悉，AI 每次会话都是「新来的」——所以你必须把这些约定显式写下来。
第一件事：写一份项目说明文件。 主流工具都支持一个放在仓库根目录的上下文文件，会自动加载进每次会话：
- Claude Code：
CLAUDE.md - Cursor：
.cursor/rules/*.mdc（旧版.cursorrules） - Codex 等：
AGENTS.md（逐渐成为跨工具的通用约定）
这份文件该写什么——不是把 README 复制一遍，而是AI 最容易搞错、而项目里没明说的东西：
## 技术栈与约定
- 前端 Next.js，状态用 X，不要引入 Redux
- 所有 API 错误走 handleError()，不要自己 try/catch 直接吞
## 目录规则
- 只在 src/features 下加新功能；src/legacy 是待废弃代码，不要动
- 数据生成脚本产物放 data/，不要写进 src/
## 构建与验证
- 改完跑 `npm run check`（类型+lint+测试）
- dev server 端口 3000，不要改端口配置
## 红线
- 不要改数据库 migration 历史文件
- 不要动 auth/ 目录，涉及安全需人工审写这份文件的投入产出比极高：它直接决定 AI 是「懂行的协作者」还是「乱撞的实习生」。本项目自己的 .claude/CLAUDE.md 就是一个可参考的范例。
第二件事：确认 AI 能自己验证。 告诉它构建、测试、lint 怎么跑，让它改完能自查。一个能跑 npm run check 自我验证的 AI，比一个只会写代码不会验证的 AI 靠谱一个数量级。
接入时：从只读到可写，权限逐步放开
别一上来就给 AI 全仓库读写加自动执行权限。合理的放权节奏：
- 只读探索：先让它读代码、回答「这个功能在哪实现」「这段逻辑为什么这么写」。这一步零风险，还能验证它是否真的读懂了项目；
- 小范围可写 + 人工确认每步：让它改一个明确的小任务，每个文件改动、每条命令都要你点确认。观察它是否守规矩、是否越界；
- 建立信任后放宽：确认它靠谱后，对低风险操作（读文件、跑测试、改指定目录）开自动放行，高风险操作（删文件、改配置、装依赖、Git 操作）始终保留确认。
三款工具都提供权限/自动批准的配置，善用它。同时强烈建议配合 Git Worktree 隔离：让 AI 在独立工作目录里改，改坏了删掉即可，主工作区永远安全。这是接入现有项目最重要的一道安全网。
放权节奏：只读 → 小范围可写加确认 → 建立信任后对低风险操作放行，高风险始终确认。
三款工具怎么选
它们能力在快速趋同，但形态和长处不同：
| 工具 | 形态 | 长处 | 适合 |
|---|---|---|---|
| Cursor | AI 原生的 IDE（VS Code 底子） | 编辑器内体验顺滑，边写边补，改动可视 | 习惯 IDE、要频繁人机交替编码 |
| Claude Code | 终端 CLI（也有 IDE 插件） | 擅长跨文件的大范围任务、Agent 式自主推进、复杂项目改造 | 大型项目重构、多步骤任务、脚本化 |
| Codex | CLI / 云端 Agent | 可派发任务后台跑、云端并行 | 批量任务、异步委派 |
务实的选法：要「AI 辅助我写」选 Cursor；要「派任务给 AI 自主完成」选 Claude Code 或 Codex。 很多团队同时用——IDE 里用 Cursor 做日常编码，需要大改造时切 Claude Code。三者对现有项目的接入准备（上下文文件、权限、验证）是共通的，工具只是执行层。更细的组合用法见《AI 编程工具组合工作流》。
第一个任务选什么
接入现有项目后，别拿核心模块练手。好的「第一个任务」应该是：范围清晰、风险低、有明确验收标准、你自己也会做。比如补一个缺失的单元测试、修一个已知的小 bug、给某个函数加类型标注。
这样的任务能帮你校准三件事：AI 是否读懂了项目约定、它的改动质量如何、你的权限和验证流程顺不顺。跑通两三个这样的任务、建立起对它的判断后，再逐步交给它更重的活。跳过这个校准阶段直接让 AI 改核心逻辑，是新手最常见的翻车方式。
第一个任务是校准而非产出：确认 AI 懂项目、改动可信、流程顺畅，再加码。
常见坑
- 不写上下文文件，指望 AI「自己看」：它会看，但会漏掉所有不在代码里明说的约定，然后用「通用最佳实践」覆盖你的项目惯例；
- 一次给太大的任务：「帮我重构整个订单模块」这种任务 AI 容易迷路且难 review。拆成小步，每步可验证可回滚；
- 不验证就合并：AI 说「已完成并测试通过」，你要自己确认真的跑过。见《AI 生成代码如何做 Code Review》；
- 让 AI 碰它不该碰的：migration、密钥配置、CI 流水线、auth 逻辑，这些在上下文文件里就该划为红线，人工把关；
- 忽略上下文预算：项目大时别让 AI 一次读几十个文件，它会被淹没。引导它按需读相关文件，或用工具的代码检索能力。
适用人群与替代方案
适合想把 AI 编程工具真正用进日常工作、而非停留在 Demo 的开发者。如果你的「项目」其实是从零起步的新项目，接入准备可以简化——没有历史包袱，AI 反而如鱼得水，v0、Bolt.new、Lovable 这类从零生成的工具可能更快。但只要是有存量代码的真实项目，本文的准备工作一步都不能省：上下文喂得好不好，直接决定 AI 是助力还是负担。
常见问题
Q：项目太大，AI 上下文放不下怎么办？ A：别指望它一次装下整个项目。现代工具都有代码检索/索引能力，会按需读取相关文件。你要做的是引导它「先定位再动手」，并在上下文文件里给出项目地图（各目录职责），帮它快速找到该看的地方。
Q：多人团队怎么共享 AI 配置？ A：把 CLAUDE.md / .cursor/rules / AGENTS.md 提交进仓库，全团队共享同一套约定。这样每个人的 AI 都遵守相同规则，也避免了「每人各调各的」的混乱。
Q：接入后代码质量下降了怎么办？ A：多半是上下文和 review 环节的问题，不是工具问题。补全上下文文件里的约定、收紧红线、加强 review 和 CI 检查。工具是放大器——项目工程规范好，AI 放大你的效率；规范差，它放大你的混乱。
小结
把 AI 接进现有项目，成败不在工具选型，而在三件准备：写好项目上下文文件让 AI 懂规矩、权限逐步放开 + Worktree 隔离守住安全底线、从低风险小任务开始校准建立信任。做好这三步，Claude Code、Cursor、Codex 都能成为真正的项目协作者；跳过它们，再强的工具也只是个会写整洁代码的麻烦制造机。