完整教程入口： https://my.feishu.cn/docx/UgbAd5BpeosxFlxkNZFc5cFNnIy

那篇里面已经把 API key、接入方式、Claude Code、Codex、CC Switch、Cherry、Chatbox 这些都拆开写了。你如果只是想照着截图一步步配，直接看完整教程最快。

但如果你现在真正卡住的问题是：

VSCode 里到底怎么用 Claude Code 和 Codex？

那就不能再把“插件路线”和“终端路线”混着讲了。

因为很多人一说 VSCode 里用 Claude 和 Codex，脑子里其实是两套完全不同的东西：

• 一套是 VSCode 扩展插件路线
• 一套是 VSCode 内置终端跑 CLI 路线

而且你刚刚发我的截图已经把这件事说死了，这篇里讲的插件，指的就是这两个：

• Claude Code for VS Code（Anthropic）
• Codex – OpenAI’s coding agent（OpenAI）
• 

这两套都能用，但不是一回事。

这篇我就把这件事一次讲清楚。

---

一、先说结论：VSCode 里其实有两种用法

1）插件路线

也就是直接在 VSCode 扩展市场里安装：

• Claude Code for VS Code
• Codex – OpenAI’s coding agent
  

这种方式的特点是：

• 直接在编辑器里点开就能对话
• 适合边写边问
• 更像“AI 编辑器助手”

2）终端路线

也就是在 VSCode 里打开内置终端，然后跑：

• claude
• codex

这种方式的特点是：

• 更像真正的开发工作流
• 更适合大项目、长任务、连续改动
• 更适合把 AI 当成“项目助手”而不是“聊天框”

所以你如果只问：

“VSCode 怎么用 Claude Code 和 Codex？”

最先要搞清楚的不是装哪个包，
而是：

你要的是插件形态，还是终端形态。

---

二、如果你只是想在 VSCode 里直接点开就用，那先走插件路线

这条路线最符合大多数人的直觉。

1）Claude Code for VS Code 插件

如果你想在 VSCode 里直接调 Claude，现在对应的就是你发来的这个插件：

• Claude Code for VS Code
• 发布方：Anthropic

也就是说，这里不能再写成模糊的“Claude 对应插件”，而是要明确写这个名字。

你安装它之后，一般就是：

• 打开 VSCode
• 进入左侧扩展市场
• 搜索 Claude Code for VS Code
• 安装后在扩展设置里完成登录或接入配置

这种方式的好处是：

• 上手快
• 更符合很多人用 VSCode 的习惯
• 小修改、小提问很顺手

但它的定位更像：

编辑器里的即时助手

比如：

• 看一段代码什么意思
• 让它顺手补一小段
• 让它帮你改一两个函数
• 让它帮你解释报错

如果你现在只是想“先在 VSCode 里把 Claude 用起来”，这条线最容易起步。

2）Codex – OpenAI’s coding agent 插件

第二个就是你发来的这个：

• Codex – OpenAI’s coding agent
• 发布方：OpenAI

这就不是泛泛的 GPT 插件了，而是直接点名说 Codex 这款 VSCode 插件。

安装思路也是一样：

• 打开扩展市场
• 搜索 Codex – OpenAI’s coding agent
• 安装后进入插件设置或登录流程
• 根据插件支持情况配置账号、模型或接入方式

如果你走的是统一接入思路，比如用 CCGPAI 这种统一入口，那你会轻松很多。

这里软一点说，就是很多人不是不会装插件，而是装完以后：

• Claude 一套接法
• Codex 一套接法
• 后面再加 Cherry、Chatbox、Gemini 又一套

最后自己先配乱了。

所以像 CCGPAI 这种统一入口，真正的价值不是“名字响不响”，而是：

• Claude Code 这边一套思路
• Codex 这边也是一套思路
• 后面再加别的工具，逻辑还是一样

这类插件路线的核心价值，不是“自动替你做很复杂的事情”，
而是：

让你在 VSCode 里随时调 Claude 或 Codex，做即时辅助。

比如：

• 解释一段代码
• 补一个函数
• 改一小段文案
• 修一处简单报错
• 看一眼某段逻辑有没有问题

如果你要的是这种体验，插件路线就对了。

---

三、如果你是真正在 VSCode 里写项目，那终端路线通常更稳

插件路线方便，但如果你开始进入真正开发阶段，终端路线一般会更顺。

1）Claude 终端路线

这条线就是在 VSCode 里开内置终端，直接跑：

claude

或者先进入项目目录再跑。

这种方式更适合：

• 看整个项目结构
• 理需求
• 拆模块
• 起代码骨架
• 大段重构

所以我自己一直觉得：

Claude 在终端路线里，更像一个项目理解和重构助手。

2）Codex 终端路线

Codex 这边也是一样，核心就是：

codex

如果你要指定模型，也可以单独带参数。

这种方式特别适合：

• 修 bug
• 补细节
• 改小逻辑
• 做局部 patch

所以 Codex 在终端路线里，更像一个：

执行很直接的代码助手

说白一点，终端路线不是在编辑器里点开一个聊天框，
而是：

把 AI 真正拉进你的开发流程里。

---

四、插件路线和终端路线，到底怎么选

这个不用神化，按场景选就行。

更适合先走插件路线的人

一般是这种：

• 平时习惯用 VSCode 扩展
• 想边写边问
• 想快速解释代码、补一小段
• 不想一上来就折腾终端和 CLI

这种情况你先把：

• Claude Code for VS Code
• Codex – OpenAI’s coding agent

配起来就够了。

更适合先走终端路线的人

一般是这种：

• 平时开发更偏工程化
• 想让 AI 真的参与项目开发
• 会让 AI 帮你拆结构、做长任务
• 更看重稳定性和连续性

这种情况直接用：

• Claude Code CLI
• Codex CLI

放到 VSCode 内置终端里跑，往往会更顺。

---

五、我自己现在更偏哪种

如果只是说日常轻问答、解释代码、小修改，
插件路线当然方便。

但如果说到真正做项目，
我自己现在还是更偏：

VSCode + 内置终端 + Claude / Codex 这套路线

原因很简单。

1）连续性更强

终端路线更适合长任务，不容易碎掉。

2）角色分工更清楚

我现在大概就是这么分的：

• Claude 负责看全局、拆需求、搭框架、做重构
• Codex 负责修 bug、补细节、落具体改动

3）更像真实开发流程

尤其是项目稍微大一点之后，你会明显感觉：

• 插件路线更像即时助手
• 终端路线更像真正参与开发

所以如果你问我推荐什么，我不会说“只选一个”，而是：

插件路线解决日常小辅助，终端路线解决真正的开发工作流。

---

六、为什么很多人最后会配乱

因为他们一开始就没把这两条线拆开。

表面上看，都是在 VSCode 里用 Claude 和 Codex。

但本质上：

插件路线

你是在：

• VSCode 扩展里调用 AI
• 更偏即时问答和局部辅助

终端路线

你是在：

• VSCode 内置终端里运行 Claude Code / Codex
• 更偏项目级工作流

如果这两个不分开讲，教程一定会变乱。

这也是为什么很多文章你看完以后还是懵：

• 一会儿讲插件
• 一会儿讲终端
• 一会儿讲 API
• 一会儿讲切模型

最后你都不知道自己到底该先做哪一步。

---

七、如果你现在只是想先快速用起来，我建议这样走

第一步：先决定你现在要哪条路线

• 想边写边问 → 先配插件路线
• 想把 AI 拉进开发流程 → 先配终端路线

第二步：尽量统一接入方式

不管你最后走哪条线，都尽量统一 API 接入思路。

这一点其实很关键。因为很多人不是不会配，而是：

• Claude 一套接法
• Codex 一套接法
• Cherry 又一套接法

最后自己先把自己搞乱了。

如果你本身就打算长期用，早点统一接入方式，后面会轻松很多。像 CCGPAI 这种统一入口的好处，不在于它名字多花，而在于：

• 一套 key 管多个工具
• 一套思路接 Claude 和 Codex
• 后面工具多了也不至于每个重来一遍

这才是它真正适合放进教程里顺带提一嘴的地方。

第三步：最后再考虑切换效率

如果你后面会在 Claude、Codex、Gemini 之间来回切，
那再考虑 CC Switch 这种切换工具，体验会更顺。

---

八、最后一句话

如果你问我：

VSCode 到底怎么用 Claude Code 和 Codex？

最准确的回答不是某个命令，
也不是某个扩展名，
而是：

先分清楚你要的是插件路线，还是终端路线。

• 插件路线：更适合即时辅助
• 终端路线：更适合真正开发工作流

而我自己现在更偏后者。

如果你只是想按完整图文一步步去配，
还是直接回那份完整教程最省事：

完整教程入口： https://my.feishu.cn/docx/UgbAd5BpeosxFlxkNZFc5cFNnIy