Claude Code、Cursor、Codex 怎么配合写项目：真实开发工作流

适用人群

这篇教程适合已经有项目代码的开发者、独立产品作者和小团队工程负责人。如果你只是写单个脚本，任意一个工具都够用；如果你维护的是 Next.js、React、Express、Python 服务、浏览器扩展这类多目录项目，就需要更明确的协作流程。

基本分工

推荐分工是：Cursor 负责“写的时候”，Claude Code 或 Codex 负责“做任务的时候”。Cursor 像一个贴在编辑器里的副驾驶，适合补全函数、解释附近代码、改一个组件、快速生成测试。Claude Code / Codex 更像项目级执行者，适合“新增一个页面并同步文档”“修复 CI 失败”“批量改数据结构并跑构建”。

不要让多个工具同时改同一批文件。最常见的混乱就是：Cursor 改了组件，Codex 又根据旧上下文改同一个组件，最后 diff 互相覆盖。一次任务只指定一个主工具，另一个工具只做解释或审查。

第一步：先让 AI 读项目，不急着改

进入项目后，第一条指令不要写“帮我实现某功能”，而是让 AI 读取 README、目录结构、关键配置、已有类似实现。比如：

“先阅读项目结构、相关 README、路由和数据源，告诉我新增文章页需要改哪些文件，暂时不要修改。”

这一步能显著减少 AI 瞎猜框架、误改路径、重复造轮子的概率。成熟项目里，最宝贵的信息通常藏在已有实现和规范文档里。

第二步：把任务切成可验收单元

AI 适合处理明确目标，不适合处理“顺便优化一下”。好的任务描述应该包含：目标、范围、约束、验证命令、不要碰的文件。例如：

“新增一个文章详情页的相关推荐模块，只改 articles 相关组件和样式，沿用现有卡片风格，不改数据结构。完成后运行 npm run build。”

如果任务超过 5 个文件，建议让 AI 先列计划，再开始改。计划不是仪式，它能暴露 AI 是否理解边界。

第三步：Cursor 的高效用法

Cursor 最适合局部快速迭代。选中一段代码，让它解释、重构、补测试，比让它在全项目里自由搜索更稳定。常用动作包括：把重复 JSX 抽成组件、根据 TypeScript 类型补齐参数、给函数补单元测试、解释报错栈。

使用 Cursor 时要多用“约束提示”：保留现有 API、不改变 CSS class、不新增依赖、只修改选中区域。它的速度很快，但也容易“顺手”改风格。每次接受修改前看 diff，不要盲点 accept all。

第四步：Claude Code / Codex 的任务流

项目级工具更适合完整闭环：读取上下文、修改文件、运行命令、根据报错修复、总结变更。让它们处理任务时，要明确验证标准。例如“构建通过”“新增页面能静态生成”“测试覆盖新增分支”。如果命令失败，不要马上接管，先让 AI 读错误并修复一次。

但高风险操作要禁用自动化：删除文件、数据库迁移、批量格式化、升级依赖、重写历史。AI 可以提出方案，真正执行前要人确认。

可以直接复用的任务提示词

把下面这段放进 Claude Code / Codex / Cursor Chat 都能用，重点是限制范围和验收标准。

请先阅读 README、相关路由、数据源和已有类似实现，再修改代码。

任务：新增一个文章详情页的相关推荐模块。
范围：只允许修改 articles 相关组件和样式。
约束：
- 沿用现有 CSS class 命名风格
- 不新增依赖
- 不改变现有数据结构
- 不覆盖用户未提交改动

验收：
- npm run build 通过
- 新模块在空数据时不报错
- 移动端不溢出

推荐项目规则文件

团队可以在仓库根目录放 AGENTS.md 或 .cursor/rules/*.mdc，把工程边界写清楚。示例：

## AI 编程规则

- 先读现有实现，再改代码。
- 不做无关重构。
- 修改公开内容时同步 sitemap / metadata / README。
- 高风险命令必须先说明影响。
- 完成后运行最小验证命令。

第五步：代码审查要看什么

AI 生成代码最容易出问题的地方有四类：边界条件、权限、错误处理、与现有约定不一致。审查时不要只看功能是否跑通，还要看有没有新增重复逻辑、有没有绕过现有 helper、有没有把配置写死、有没有吞掉错误。

建议形成固定清单：是否最小改动、是否沿用项目模式、是否有验证、是否更新文档、是否影响 SEO / sitemap、是否处理空态和错误态。这个清单比“感觉还行”可靠得多。

团队落地规范

团队使用 AI 编程工具，最好提前约定三件事。第一，哪些代码可以交给 AI：样式调整、测试补齐、脚手架、数据迁移脚本可以多用；认证、支付、加密、权限、合规逻辑要更谨慎。第二，AI 生成内容如何标记：不一定要在代码里写“AI 生成”，但 PR 描述里应说明使用了 AI、改动范围和验证命令。第三，失败怎么处理：AI 连续两轮修不好同一个问题时，应该停下来让人重新分析，而不是继续让它试。

还要建立“上下文交接”习惯。每次让工具接手任务前，先写清楚当前分支、相关文件、已有失败命令、不要碰的文件。AI 最怕半截上下文，尤其是在多人协作项目里。清晰交接能减少大量无意义返工。

界面验收图要截三类：Cursor 选中代码局部修改图、Claude Code / Codex 终端执行任务图、PR diff 与构建通过图。AI 编程教程必须让读者看到“提示词 → 代码改动 → 验证结果”这一整条链路，否则就是空泛经验谈。

常见坑

| 现象 | 直接原因 | 修法 | |------|----------|------| | AI 改了一堆无关文件 | 任务没有写范围 | 提示词里写“只允许修改这些路径”，结束后看 git diff --stat | | 代码能跑但风格不一致 | 没让 AI 先读同类实现 | 先让它找 2 个已有组件，再照模式写 | | 覆盖了同事改动 | 没检查工作区状态 | 开始前跑 git status --short，有冲突先停 | | 修 bug 修出新 bug | 没有最小验证命令 | 每个任务写清楚 npm run build、npm test 或页面路径 | | AI 引入不存在的 API | 没查官方文档 | 涉及新库、新模型、新参数时必须联网或看官方 docs |

PR 描述可以固定成这个模板：

## 改了什么
- 

## AI 参与范围
- 使用 AI 生成初稿 / 重构 / 测试

## 验证
- [ ] npm run build
- [ ] 关键页面手动检查
- [ ] 无无关文件 diff

替代方案

如果你只需要补全，GitHub Copilot 已经够用。如果你更偏产品原型，可以用 v0、Bolt、Lovable 这类生成式开发工具。如果你需要严格工程协作，建议保留传统 PR、CI、Code Review 流程，让 AI 成为执行者，而不是绕过流程的捷径。

小结

Claude Code、Cursor、Codex 的最佳组合，不是“三个一起上”，而是按任务层级分工：编辑器内用 Cursor 快速写，项目级任务交给 Claude Code 或 Codex 闭环执行，最后用人类审查把质量兜住。AI 编程越强，工程纪律越重要。