从 Cursor 切到 Codex 一个月，我后悔没早点换我用了 Cursor 快一年，本来以为自己已经离不开它了。直

我用了 Cursor 快一年，本来以为自己已经离不开它了。

直到我把日常开发切到 Codex 一个月，才发现我之前很多时间不是花在写代码上，

而是花在“陪 AI 聊清楚需求”上。

这篇聊聊我为什么换、怎么换、哪里爽、哪里坑。

先说结论：不是 Cursor 不行，是我的工作流变了

我先叠个甲。

Cursor 依然是很强的 AI 编辑器。

如果你的主要诉求是：

边写边补全
在当前文件里快速改代码
问某段代码是什么意思
让 AI 帮你补一个函数
在编辑器里随手问一句

Cursor 仍然很好用。

但我这一个月换到 Codex 后，最大的感受是：

我不再把 AI 当成“更聪明的补全工具”，而是把它当成“能独立跑一段开发流程的代理”。

这两者差别很大。

Cursor 更像一个坐在你旁边的高级副驾驶。
你写，它补。你问，它答。你选中一段，它改。

Codex 更像一个你可以丢任务过去的开发同事。
你说目标，它读仓库、拆任务、改代码、跑测试、给 diff、等你 review。

我以前以为这只是交互方式不同。

用了一个月后我发现，不是。

这会直接改变你每天写代码的节奏。

我为什么想从 Cursor 换出来？

1. 我越来越烦“在编辑器里反复解释”

刚开始用 Cursor 的时候，我每天都很兴奋。

写一半函数，它给我补完。
选中一段代码，它帮我重构。
报错贴进去，它告诉我哪里错。

爽。

但用久了以后，我发现一个问题：

我还是工作流的中心。

比如我要修一个订单保存失败的问题。

我的流程大概是：

1. 打开报错
2. 找相关文件
3. 把报错复制给 Cursor
4. 让它看当前文件
5. 它猜一个原因
6. 我再打开另一个文件
7. 再让它看
8. 它再猜
9. 我跑测试
10. 把新报错贴回去

整个过程里，AI 确实在帮我。

但它更像一个很聪明的问答机。

它不断问我：

相关代码在哪？
报错完整堆栈呢？
这个函数在哪里调用？
测试怎么跑？
你们项目的规范是什么？

我每次都要把这些东西整理好喂给它。

时间久了就很烦。

我不是不想写代码。

我是不想继续当 AI 的项目导游。

2. Cursor 适合“改局部”，但我现在更多是“交付任务”

以前我用 AI 的主要场景是：

帮我写个函数。
帮我优化这段代码。
帮我解释这个类型报错。
帮我补一个单测。

这些 Cursor 很擅长。

但后来我的需求变了。

我更常遇到的是这种任务：

修复订单编辑页保存失败的问题，要求不影响新建订单流程。

或者：

把用户详情页的权限判断逻辑抽出来，补测试，保持原有行为不变。

这种任务不是单文件修改。

它需要：

读多个文件
找调用链
看现有测试
理解项目约定
修改代码
跑测试
看 diff
总结风险

我发现自己在 Cursor 里做这类任务时，经常会陷入一种状态：

AI 一直在帮我，但我一直在调度 AI。

这就是我想换的原因。

3. 我不想再边写边被打断

Cursor 的强项是和编辑器深度绑定。

但这也是我后来的痛点。

它很适合“我正在写代码，你来帮我”。

但有些任务，我其实不想一直盯着它。

比如：

给这个模块补齐单测。
清理几个重复组件。
把旧 API 调用迁到新封装。
修 3 个低优先级 bug。

这些任务我不想一步步陪着 AI 做。

我只想丢过去，然后等它给我一个可 review 的结果。

这就是我切到 Codex 后最明显的变化：

我开始把任务批量丢给 AI，而不是把注意力一直插在 AI 对话里。

我是怎么切的？

我没有一上来就把 Cursor 卸了。

这很重要。

我第一周的策略是：

Cursor 继续做即时补全。
Codex 只处理独立任务。

也就是说：

正在写代码时，还是用 Cursor
修 bug、补测试、做小重构，丢给 Codex
不确定方案的任务，先让 Codex 读仓库出计划
大任务拆小，再分批给 Codex

到第二周，我开始把 Cursor 使用频率降下来。

到第四周，我基本变成：

日常开发：Codex 为主
临时编辑：编辑器手写
快速问答：ChatGPT / Codex
补全依赖：看场景，不强依赖 Cursor

我不是说所有人都该这么换。

但对我来说，这个切换非常自然。

因为我真正想要的不是“更强补全”。

我想要的是：

更少上下文搬运，更强任务闭环。

我记录了一个月，差别挺明显

下面是我自己一个月的粗略记录。

不严谨，但足够说明体感。

指标	Cursor 为主时	Codex 为主后	我的感受
每天 AI 对话轮次	35～50 轮	15～25 轮	问答少了，任务更完整
单个 bug 平均处理时间	40～60 分钟	20～35 分钟	少了很多找文件和贴报错
每周可交给 AI 的独立任务	3～5 个	8～12 个	Codex 更适合批量丢任务
我手动复制上下文次数	很多	明显减少	这是最大爽点
需要返工的 AI 改动	中等	仍有，但更容易 review	因为 diff 和测试更集中
适合场景	局部编码	任务执行	两者定位不同

我最大的变化不是“代码写得快了 10 倍”。

这种话太虚。

真实变化是：

我每天被 AI 打断的次数少了。

以前我需要一直参与：

看这里
不是这个文件
再看那个文件
报错变了
你改多了
测试挂了
重新来

现在我更多是：

这是任务。
先读代码。
给方案。
我确认。
你执行。
跑测试。
给 diff。

这对注意力的保护很明显。

Codex 最让我爽的 5 个地方

1. 它更适合“丢任务”，而不是“聊代码”

我现在最常用的 prompt 是这种：

帮我修复订单编辑页保存失败的问题。

要求：
1. 先阅读相关代码，定位根因
2. 不要改无关文件
3. 给出最小修复方案
4. 修改后运行相关测试
5. 最后总结改动文件、验证结果和风险点

这类任务给 Cursor 也能做。

但在我的使用习惯里，Cursor 更容易变成来回聊天。

Codex 则更像一个任务容器。

我可以等它完整跑一轮，再看结果。

这种感觉非常不一样。

2. 它会天然把“读代码、改代码、跑验证”放在一起

我以前用 Cursor 时，常常是：

AI 改代码
我跑测试
测试报错
我复制报错
AI 再改
我再跑

Codex 的好处是，我会更自然地要求它把验证也做了。

比如：

改完后运行 pnpm test:unit order，并把失败用例和修复方式一起说明。

这会迫使 AI 不只是“生成代码”，而是交付一个更完整的结果。

当然，它也会失败。

但失败也比以前好处理。

因为它会告诉我：

我改了哪些文件
运行了什么命令
哪个测试失败
失败原因是什么
下一步建议是什么

这比一句“代码应该可以了”强太多。

3. 多文件任务更舒服

我用 Cursor 时，最烦的是跨文件上下文。

比如一个前端 bug，可能涉及：

pages/order/Edit.vue
components/OrderForm.vue
api/order.ts
stores/order.ts
utils/price.ts
tests/order-edit.spec.ts

如果是单文件问题，Cursor 很爽。

但一旦涉及多个文件，我就要不断切、不断问、不断补上下文。

Codex 的体验更接近：

你自己先找相关文件，找完告诉我你的判断。

它不一定每次都找得完美。

但至少我不用从第一秒就当导航员。

4. Review 心智更接近正常开发

我切到 Codex 后，最喜欢的一点是：

我开始像 review 同事代码一样 review AI 代码。

以前在 Cursor 里，我经常是边改边接受，最后自己都忘了哪些是 AI 改的、哪些是我改的。

现在我更习惯让 Codex 最后输出：

1. 修改了哪些文件
2. 每个文件为什么改
3. 有哪些风险
4. 跑了哪些验证
5. 还有哪些没验证

然后我看 diff。

这个流程更稳。

AI 改代码最怕的不是它慢。

下面展开讲。

1. Filesystem：先让它真的看见项目

这个是最基础的。

没有 Filesystem，Claude Code 虽然也能在当前项目里操作，但我更习惯把可访问范围明确写死。

比如只允许它看当前项目，不让它乱扫其他目录。

我的配置习惯是：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/你的项目路径"
      ]
    }
  }
}

装完后，我的 prompt 也变了。

以前：

这是 order.ts，这是 Edit.vue，这是报错，你看看。

现在：

帮我定位订单编辑页保存失败的问题，先读相关文件，不要直接改。

差别非常明显。

以前是我给它喂文件。
现在是它自己找文件。

这一步看起来简单，但体感提升最大。

2. Git：别让 AI 盲改

我很怕 AI 改代码的一个原因是：它有时候改得太“热情”。

你让它修一个 bug，它顺手重构三个函数。
你让它补一个测试，它顺手改了测试框架配置。
你让它改一个按钮，它顺手把样式抽了个组件。

Git MCP 的价值是让它随时知道：

当前分支是什么
最近改了哪些文件
哪些改动是它造成的
哪些文件本来就有变化
这次 diff 是否超出任务范围

我现在每次让 Claude Code 改完，都会补一句：

改完后先看 git diff，总结你改了哪些文件，哪些改动是必要的，哪些可能有风险。

这个习惯救过我很多次。

最典型的一次是，它为了修一个展示 bug，顺手改了一个公共格式化函数。

diff 一看我人麻了。

如果没有 Git MCP，我大概率会到测试炸了才发现。

3. GitHub：让 issue 直接变成任务上下文

这个是我后悔装晚的。

以前产品或测试在 GitHub issue 里写了需求，我会复制标题、描述、评论、截图说明，然后粘给 Claude Code。

现在我直接说：

读取 GitHub issue #128，先总结需求和验收标准，再给实现方案。

它会先读 issue，然后把任务拆成：

1. 影响页面
2. 相关接口
3. 需要改的组件
4. 需要补的测试
5. 潜在风险

这才像正常开发流程。

而且 PR review 也能接上。

比如我会这样用：

读取当前 PR 的 review comments，把需要处理的问题按文件分组，不要立刻修改，先给我确认。

这个动作以前我至少要来回切 5 次页面。

现在一次搞定。

4. Database：只读账号是底线

这个 MCP 我一开始很抗拒。

让 AI 连数据库，听起来就有点吓人。

后来我给它配了一个只读账号，只能连本地开发库和测试库，不能改数据，不能碰生产写权限。

然后它直接解决了我一个长期痛点：

AI 写后端逻辑时终于不再瞎猜字段。

以前我问：

帮我加一个订单筛选条件。

它经常会猜：

order_status
created_time
user_id

但我们真实表字段叫：

status
created_at
buyer_id

字段名一错，后面全错。

接了 Database MCP 后，我会这样问：

先查看 orders 表结构，再实现按订单状态和创建时间筛选。数据库只读，不允许执行写操作。

它会先查 schema，再改代码。

这一步对后端和全栈项目特别香。

但一定要记住：

只读，最小权限，最好本地库。

别为了爽，把生产库写权限交出去。

5. Sentry：别再把线上报错截图发给 AI

以前线上报错，我的流程是：

打开 Sentry。
复制 error message。
复制 stack trace。
复制 release。
复制用户环境。
粘给 Claude Code。

复制到第三段我就已经烦了。

接 Sentry 后，我现在直接问：

查看最近 24 小时订单模块最高频的错误，找出最可能的代码原因，先不要改。

它会把错误按频率、堆栈、影响范围整理出来。

然后我再让它：

根据这个错误定位代码位置，给出最小修复方案。

这里一定要强调“最小修复”。

因为线上 bug 最怕 AI 过度发挥。

我的固定提示是：

只修复导致这个 Sentry 错误的最小代码路径，不做重构，不优化无关逻辑。

加上这句话后，翻车率明显下降。

6. Context7：专治“AI 写过期 API”

这个我装完当天就后悔了。

后悔没早点装。

AI 编程最烦的不是它不会写，而是它会写“看起来很对但已经过时”的代码。

比如：

某个库新版 API 改了
某个配置项废弃了
某个框架升级后推荐写法变了
某个方法在旧版本能用，新版本不行

以前我会手动打开文档，再贴链接给它。

现在我直接说：

用 Context7 查一下当前版本的 Next.js 路由写法，再改代码，不要凭记忆写。

或者：

先查最新的 TanStack Query 文档，再帮我封装这个 hook。

这个 MCP 的价值不是“让 AI 更聪明”。

而是让 AI 少一本正经地胡说。

对前端尤其有用。

因为前端生态更新太快了，AI 记忆里的写法经常是上个版本的。

7. Playwright：让它自己点一遍页面

这是最有“爽感”的一个。

以前 Claude Code 改完页面，我还要自己启动项目，打开浏览器，点按钮，看弹窗，测表单。

现在我会直接说：

修改完成后，用 Playwright 打开订单编辑页，完成一次保存流程验证。记录你点击了什么、看到了什么、是否通过。

它能自己：

打开页面
找输入框
点击按钮
观察页面状态
生成测试
发现明显交互问题

有一次它修完一个弹窗 bug，自己用 Playwright 点了一遍，然后告诉我：

保存按钮点击后接口成功，但弹窗没有关闭，原因是 onSuccess 里没有 reset visible 状态。

这就是我想要的 AI 编程。

不是“帮我写代码”。

而是“帮我把这件事闭环”。

不过 Playwright MCP 也别乱用。

我一般只让它跑本地环境，不让它操作真实线上后台。

8. Sequential Thinking：让它先想清楚再动手

这个 MCP 听起来有点玄学，但我实际用下来很实用。

尤其适合这种任务：

把订单详情页重构成可复用组件，同时保持现有功能不变。

裸用时，Claude Code 很容易直接开改。

一旦任务大，它就会边改边想，改到一半上下文越来越乱。

现在我会先说：

这是一个复杂任务。先用 Sequential Thinking 拆解，不要写代码。输出阶段计划、风险点、回滚方案。

它会先拆成几步：

1. 梳理现有页面功能
2. 找出可抽离组件
3. 定义 props 和事件
4. 保持原页面行为不变
5. 补测试
6. 分阶段提交

看完计划后，我再让它执行第一步。

我的经验是：

小任务直接干，大任务先拆。

这能显著减少 AI “越改越远”的概率。

Skills：MCP 是手脚，Skills 是规矩

只装 MCP 还不够。

MCP 解决的是“它能不能拿到信息、调用工具”。

Skills 解决的是“它拿到信息后，按什么方式做事”。

我现在项目里会放几个固定 Skills。

比如：

code-review-skill
test-first-skill
bugfix-skill
refactor-skill
commit-message-skill

举个例子，我的 bugfix skill 大概是这样：

# Bugfix Skill

当任务是修复 bug 时，必须按以下步骤执行：

1. 先复现或定位问题，不要直接改代码
2. 找到最小影响范围
3. 优先修复根因，而不是屏蔽错误
4. 修改后运行相关测试
5. 最后输出：
   - 根因
   - 修改文件
   - 验证方式
   - 风险点

禁止：
- 顺手重构无关代码
- 修改公共 API 而不说明影响
- 未验证就宣称修复完成

这个东西看起来很普通，但效果非常明显。

因为你不用每次都提醒它：

不要乱改。
先定位。
补测试。
说清楚风险。

这些都变成默认规则。

我现在的理解是：

CLAUDE.md 写项目常识，Skills 写工作流，MCP 接外部能力。

三者配起来，Claude Code 才不像临时工。

我的最小配置模板

下面是我自己的简化版配置。

注意：不同 MCP 的安装方式会变，实际使用时以对应项目文档为准。这里重点看思路。

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/project"
      ]
    },
    "git": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-git",
        "--repository",
        "/path/to/your/project"
      ]
    },
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GITHUB_TOKEN}"
      }
    },
    "database": {
      "command": "npx",
      "args": [
        "-y",
        "@bytebase/dbhub",
        "--dsn",
        "postgresql://readonly:password@localhost:5432/app"
      ]
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    },
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}"
      }
    },
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@latest"
      ]
    },
    "sequential-thinking": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sequential-thinking"
      ]
    }
  }
}

我的建议是别一口气全装。

按这个顺序来：

Filesystem → Git → Context7 → Playwright → GitHub → Database → Sentry → Sequential Thinking

先把本地开发闭环跑顺，再接外部系统。

否则你会遇到另一个问题：

工具太多，Claude Code 不知道该先用哪个。

我现在的常用 prompt

修 bug

帮我修复这个问题。

要求：
1. 先定位根因，不要直接改
2. 优先读取相关代码、git diff 和错误信息
3. 如果涉及第三方库，先查最新文档
4. 给出最小修复方案
5. 修改后运行相关测试
6. 最后总结根因、改动文件、验证方式和风险点

做需求

读取 issue 内容，整理需求和验收标准。

然后：
1. 找到相关代码
2. 给出实现方案
3. 标出可能影响的模块
4. 不要直接修改，等我确认后再动手

改前端页面

完成这个页面改动。

要求：
1. 先读取页面组件和相关接口
2. 如涉及库 API，先查最新文档
3. 修改后用 Playwright 在本地页面验证一次
4. 记录验证步
::contentReference[oaicite:1]{index=1}
和结果

代码审查

查看当前 git diff，做一次 code review。

重点看：
1. 是否有无关改动
2. 是否破坏现有类型
3. 是否有潜在边界条件
4. 是否需要补测试
5. 是否符合项目约定

只输出 review，不要修改代码。

裸用 vs 接 MCP 后，差距到底在哪？

我自己最明显的感受有 4 个。

1. 复制粘贴少了

以前我每天都在复制：

报错
文件
接口
文档
日志
表结构
issue

现在大部分让它自己去拿。

这不是省几十秒的问题，而是工作流顺了。

2. 它更少瞎猜

尤其是字段名、库 API、项目规范。

AI 最可怕的不是不会，而是自信地写错。

MCP + Skills 能显著降低这种情况。

3. 任务更容易闭环

以前 Claude Code 改完代码就结束了。

现在我会让它：

改代码 → 跑测试 → 看 diff → 浏览器验证 → 总结风险

这才是完整开发流程。

4. 我更敢让它动大一点的代码

裸用时，我只敢让它改小 bug。

现在有 Git、测试、Playwright、Skills 兜底后，我开始敢让它做一些中等规模重构。

当然，大重构我还是会分阶段。

AI 可以开车，但方向盘不能完全松。

但我不建议你无脑全开

最后说点冷水。

MCP 很强，但也有风险。

我现在有几条硬规则：

第一，数据库只读

能不给写权限就不给。

尤其别让 AI 直接操作生产库。

第二，敏感系统分环境

本地、测试、生产要分开。

AI 能访问什么，要明确。

第三，改代码前先计划

复杂任务一定先让它出方案。

不要上来一句“帮我重构一下”。

第四，外部 MCP 要确认可信

MCP 本质上是给 AI 接工具。

工具越强，风险越大。

不要看到别人推荐就直接装，尤其是需要 token、文件权限、浏览器权限的。

第五，永远看 diff

这条最重要。

Claude Code 改完，不管它说得多自信，我都一定看 diff。

AI 写代码的第一原则：

信它的效率，不信它的结论。

最后

我现在回头看，裸用 Claude Code 的那两周真的挺蠢的。

不是工具不行，是我用法太像 2023 年的聊天机器人时代。

以前我问 AI：

这段代码怎么改？

现在我会说：

这是目标，你去读 issue、查代码、看文档、跑测试、验证页面，最后告诉我改了什么。

这两个用法，差的不是 prompt 技巧。

差的是工作流。

Claude Code 真正好用的地方，不是它能不能一次写出完美代码。

而是你把 MCP、Skills、项目规范、测试验证都接起来后，它能从“代码生成器”变成“开发流程执行器”。

所以我的建议很简单：

别急着研究 100 个神奇 prompt。

先把这 8 个 MCP 装起来。

你会发现，之前让你痛苦的很多问题，不是 AI 不聪明。

是你一直让它闭着眼睛干活。