企业官网建设流程全解析

1. 为什么最近大家都在问 Codex 怎么装：先从实际场景说起

最近一段时间，我陆续收到好几条几乎一模一样的私信：Codex 到底怎么装？Mac 上有 Homebrew 和 npm 两种装法，Windows 上又有人要用 WSL、有人直接在 PowerShell 里装，装完之后 IDE 还动不动提示找不到可执行文件。我一开始以为是个别环境问题，结果发现这其实是个通用现象，因为 Codex 的安装链路比普通命令行工具多了一截——它既要把 CLI 装好，还要完成登录认证，还得让编辑器能找到它。中间任何一步出了偏差，后面的所有操作都会卡住。

这篇内容就是把我自己反复装过几台机器之后整理的流程写清楚：Mac 和 Windows 各自怎么装，CLI 怎么初始化，IDE 怎么对接，以及我在实际安装和排错过程中遇到的那些“报错信息看着吓人、实际上原因很简单”的问题。适合三类人看：第一次接触 Codex、想快速跑通本地环境的初学者；在 Mac 和 Windows 之间来回切换、需要一份对照清单的开发者；以及已经装完但 IDE 一直提示找不到 CLI、想搞清楚排查思路的人。

先说一个我在开头就要强调的结论：Codex 的安装本身不难，真正难的是搞清楚每个环节之间依赖什么。CLI 是核心，所有其他东西都围绕它转。你如果只装了 IDE 插件而没有装 CLI，插件就是一堆废按钮；你如果只装了 CLI 但没登录，运行时会一直要你认证；你如果用系统自带 node 装了全局包，过几天升级时可能又遇到权限报错。所以这篇文章的结构就是按照“环境准备 → Mac 安装 → Windows 安装 → CLI 初始化 → IDE 集成 → 排错 → 维护”的顺序来组织的，跟着走基本不会翻车。

2. 安装前的环境准备：账号、运行时与包管理器选型

2.1 账号认证是前提，别跳过这一步

Codex 不是装完就能用的离线工具。它的工作方式是：你本地的 CLI 把代码仓库上下文、你的指令发给云端模型，模型返回修改建议或直接改代码，所以你必须有一个可用的 OpenAI 账号，并且让 CLI 完成登录认证。热词里有一堆“登录不了”“failed to start”之类的问题，根源往往就是认证没做。

第一次运行codex时，命令行会提示你登录。有些版本的 CLI 会打印一个 URL，让你在浏览器里打开并授权，授权成功后在终端里粘贴回调后的字符串；有些版本会自动拉起浏览器。整个流程比较顺，但要注意一点：你需要在能正常访问 OpenAI 官网和 API 的环境里操作。这不是网络配置问题，而是账号服务的访问条件问题，别在认证这步卡太久，先确认基础条件再继续。

如果你本来就在用 OpenAI 开发者平台管理 API Key，也可以在配置文件的 auth 部分填写 token。不过说实话，对于绝大多数交互式使用场景，我更推荐用浏览器授权而不是手填 API Key，因为 API Key 在本地文件里存着，万一不小心提交到 Git 仓库就是事故。

2.2 Node.js 运行时：Mac 和 Windows 都绕不开的门槛

Codex CLI 目前最主流的安装方式还是通过 npm 分发，所以 Node.js 是你机器上必须有的运行时。注意我这里说的是“最主流”，因为你也可以选择用 Homebrew 安装，Homebrew 公式内部其实也会处理依赖，但从全平台通用性的角度看，npm 是 Mac 和 Windows 都能对齐的安装通道。

具体版本要求方面，建议安装 Node.js 18 或更高的 LTS 版本。我见过有人在 Node 14 的老环境上硬装，结果 npm install 过程里一堆依赖包语法报错，这就是版本太老导致的。Node 的安装方式我就不啰嗦了，Mac 上可以用 Homebrew 装 node，也可以去官网下载 pkg 安装包；Windows 上推荐下载官方 LTS 安装包，安装时一路默认即可。装完之后在终端里执行node -v和npm -v，能看到版本号就说明环境没问题。

这里有一个很多人忽略的小细节：npm 的全局安装目录。在 Mac 上，npm 把全局包装到/usr/local/lib/node_modules或$(brew --prefix)/lib/node_modules，对应的可执行文件软链到/usr/local/bin或$(brew --prefix)/bin。在 Windows 上，npm 默认把全局可执行文件放到%AppData%\npm。如果你后面遇到“codex 命令找不到”，大概率就是这些路径没在系统的 PATH 环境变量里。

2.3 包管理器选择：Homebrew、npm 还是两者都要

很多人在第一步就开始纠结，觉得自己是不是只能二选一。我实际用下来的看法是：不用纠结，看你的使用习惯就好。

Mac 用户如果已经在用 Homebrew 管理开发工具，那brew install codex是最省事的路径，升级也统一走brew upgrade。Windows 用户如果没有 WSL 环境，就直接用 npm。如果你是两个平台都要维护，建议 Mac 上走 Homebrew、Windows 上走 npm，各自用对应平台的更新节奏走，反而最不容易乱。

还有一点我想提醒：Machine 上同时有 Homebrew 版和 npm 版时，codex命令到底指向哪个版本，取决于 PATH 里谁排前面。曾经有朋友装完一直报版本不对，排查到最后发现是 Homebrew 装了一个旧版，npm 又装了一个新版，两个路径在 PATH 里互相打架。这种问题很隐蔽，遇到诡异行为时先执行which codex查看当前到底用的是哪个路径下的二进制。

3. Mac 安装 Codex：从 Homebrew 到 npm 的两条路线

3.1 路线一：Homebrew 安装，适合已有 brew 环境的用户

在 Mac 上装 Codex 最直接的方式就是打开终端执行：

brew install codex

这个命令会从 Homebrew 的 formula 仓库拉取 Codex 及其运行时依赖，安装完成后 Codex 的可执行文件会自动放在 Homebrew 的 bin 目录下。Homebrew 在 macOS 上默认是/opt/homebrew/bin（Apple Silicon）或/usr/local/bin（Intel），这两个路径通常在 PATH 里已经存在，所以安装完基本不需要额外配置。

执行完brew install codex之后，我建议先做两个验证：

codex --version which codex

第一个命令确认版本号能打印出来，第二个命令确认路径指向 Homebrew 目录。如果codex命令提示找不到，执行brew doctor检查一下 Homebrew 自身的环境是否有问题。

Homebrew 这条路的优点是和系统其他包管理统一，卸载和升级都清晰：升级用brew upgrade codex，卸载用brew uninstall codex。缺点是依赖了 Homebrew 的更新节奏，如果官方发布新版本，可能需要稍等一会儿 formula 才会同步更新。

3.2 路线二：npm 全局安装，版本更新更及时

如果你更喜欢第一时间拿到新版本，或者你的 Mac 上没有安装 Homebrew，npm 是更好的选择。先确认 Node.js 环境就绪，然后执行：

npm install -g @openai/codex

这里注意包名是@openai/codex，带 scope 的，不是codex，别拼错了。npm 会把可执行文件链接到全局 bin 目录。如果你的 Node.js 是通过 nvm 安装的，全局 bin 目录就在~/.nvm/versions/node/<版本号>/bin，这个路径很可能不在 PATH 里，你需要手动把它加进去。

npm 安装过程中偶尔会遇到权限报错，常见的是EACCES: permission denied。这个问题的根源是 npm 全局目录的写权限不够。我从安全角度不建议直接sudo npm install -g，而是建议排查一下全局目录的归属。如果你是用 Homebrew 安装的 Node，通常全局目录归你当前用户所有，不会出现权限问题；如果是官网 pkg 安装的 Node，全局目录可能是 root 所有，这时候最简单的办法是把 npm 全局目录改到用户目录下：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global'

然后把~/.npm-global/bin加进 PATH。这比 sudo 更干净，后续升级也不会出幺蛾子。

3.3 安装完成后的路径检查与首次启动

无论在 Mac 上走了哪条路，装完以后都要确认命令行能启动。我第一次装完时犯过一个低级错误：终端还是旧会话，PATH 没有刷新，导致怎么敲 codex 都提示不存在。解决办法很简单——关掉终端重新开一个，或者执行source ~/.zshrc（如果你用的 zsh）。

首次启动可以先用codex --help看看帮助信息，再用codex login完成认证。有经验的同行应该能感觉到，Codex 的 CLI 交互设计更接近一个“对话式代理”，而不是那种只接受一遍参数的传统命令行程序。启动后它会进入一个交互界面，你直接输入自然语言描述任务就行。

我在 Mac 上遇到过一个问题：配置目录~/.codex不存在，导致登录状态写不进去。其实不用手动创建，CLI 首次运行时会自动生成，但如果你设置了非常严格的 shell 启动脚本，或者目录权限被改过，就会出现异常。遇到这种情况时手动执行mkdir -p ~/.codex把目录建好，再设置当前用户可读写，通常就能解决。

4. Windows 安装 Codex：最容易被卡住的几个环节

4.1 先想清楚：原生环境还是 WSL 环境

Windows 平台上安装 Codex 有一个很现实的分叉点：你是在原生 Windows 终端（PowerShell 或 cmd）里直接跑，还是准备在 WSL 里跑。这两条路我都实际验证过，结论是：

• 如果你日常开发就是 VS Code + Remote WSL，那直接在 WSL 的 Linux 环境里按 Linux 方式装最自然，Node 环境用 apt 或 nvm 都行，整个体验和 Mac 很像。
• 如果你没有 WSL，或者你只是偶尔跑一下 Codex、不想卷进 WSL 的磁盘性能问题，那么原生 Windows 安装同样可行，只是需要注意 PATH 和 npm 路径。

热词里有“codex windows安装未完成”这样的搜索，我基本上能猜到问题场景：要么是安装中介面一直卡住不动，要么是下载过程中断，要么是npm安装到最后权限校验失败。这里有一个通用建议：网络波动时别总是重试同样一条命令，先检查 npm 缓存和安装日志，把错误定位清楚再继续。

4.2 原生 Windows 安装步骤

在 Windows 上，我推荐的安装顺序是这样的：

1. 安装 Node.js LTS 版本。去官网下载 Windows Installer（.msi），一路默认安装。安装完成后打开 PowerShell，执行node -v和npm -v确认可用。
2. 打开 PowerShell（建议以普通用户身份，不需要管理员权限），执行：

npm install -g @openai/codex

3. 安装完成后，打开一个新的 PowerShell 窗口，执行：

codex --version

如果这里提示“codex 不是内部或外部命令”，那几乎可以肯定就是 npm 全局目录不在 PATH 里。npm 在 Windows 上默认把全局包放到C:\Users\<用户名>\AppData\Roaming\npm，你把这个目录加到系统 PATH 或用户 PATH 里就行。操作路径是：系统设置 → 环境变量 → 用户变量 → Path → 新建 → 填入上面的路径。

另外一个 Windows 特有问题：PowerShell 执行策略。有时候codex命令不是找不到，而是被 PowerShell 的执行策略挡了，报错类似“无法加载文件，因为在此系统上禁止运行脚本”。这个不一定非要改全局执行策略，可以只对当前用户放开：

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

这条命令允许本机脚本运行，但远程下载的未签名脚本依然会被限制，安全上比直接改成 Unrestricted 稳妥。

4.3 WSL 环境下的安装方式和差异点

如果你想在 WSL 里装，那就进入了标准的 Linux 环境。假设你用的 WSL 发行版是 Ubuntu，流程是：

sudo apt update sudo apt install -y nodejs npm sudo npm install -g n sudo n stable hash -r npm install -g @openai/codex

这里为什么用n这个 Node 版本管理器？因为 Ubuntu 自带的 Node 版本太老，直接用它跑 Codex 会触发兼容性问题。用n stable把 Node 升到当前稳定版本再装 Codex，能减少大量莫名其妙的报错。

WSL 和原生 Windows 之间还有一处差异：配置文件的存放路径。原生 Windows 上，Codex 的配置在C:\Users\<用户名>\.codex；WSL 里则是/home/<用户名>/.codex。两边不是同一个目录，所以你在原生 Windows 登录了，到 WSL 里依然要重新登录认证。这是很多人没注意到的地方——不是 Codex 有问题，而是两个环境各自维护一套用户状态。

4.4 Windows 安装完成后的首次启动检查

安装完成之后，无论是原生环境还是 WSL，我都建议用三步检查法：

1. which codex或Get-Command codex，确认识别到的路径和你预期一致。
2. codex --version，确认二进制能正常执行。
3. codex login，确认认证流程能走通。

如果这三步都过了，接下来使用 IDE 集成时才不会出现“找不到二进制”的问题。我见过太多人 IDE 插件装好了、配置里路径却乱填一气，最后错误信息到底是“找不到 CLI”还是“没有权限”都分不清楚。先把 CLI 这一步验证通，后面全是加分项。

5. CLI 初始化与日常使用：认证、模型切换与常用操作

5.1 登录认证的完整流程与常见问题

CLI 装好之后，最优先做的不是马上写代码，而是完成初始化。在终端里执行：

codex login

这个命令会发起认证流程。CLI 会输出一个授权链接，浏览器打开之后会让你确认授权，然后你会拿到一个类似回调码的东西，粘贴回终端即可。认证完成后，你的凭据会存在~/.codex/auth.json里面（如果是在 Windows 原生环境上，就是用户目录下的.codex文件夹里）。

认证环节我在实际中见过几个坑：

• 终端提示“无法启动浏览器”：这通常发生在没有图形界面的 WSL 环境或 SSH 会话里。没浏览器也不用慌，手动复制终端给出的链接到本机浏览器打开，授权后把回调内容粘贴回来就行。
• 认证成功后仍然提示未认证：先检查你的系统时间。时间偏差太大会导致 token 校验失败。Windows 主板电池没电导致时间不准这种极端情况不算常见，但一旦遇到确实会怀疑人生。
• 多账号来回切换：Codex 的配置天然支持多用户配置段，但我个人不建议在一台机器上频繁切换账号。你如果只是日常使用，保持一个主账号登录最省心。

5.2 常用命令与核心参数说明

初始化完成之后，你就可以正常使用了。Codex CLI 的操作逻辑不是传统的“一条命令一个输出”，而是更像一个交互式会话。你启动它，进入提示符界面，然后用自然语言描述需求，它会分析你当前目录的代码结构并给出操作建议。

日常操作中用的比较多的几个命令：

codex exec "把 README.md 里的安装步骤补充完整" codex exec --model gpt-5-codex "帮我写一个 Python 脚本，批量重命名当前目录下的图片文件" codex chat

codex exec是直接执行模式，适合明确的单次任务；codex chat是交互模式，适合多轮对话，你会一直停留在会话里直到主动退出。--model参数用来指定模型，不同模型在代码理解和生成能力上有差异。

还有一个我特别喜欢的参数是--full-auto（或者相应版本的自动执行开关），启用后 Codex 会直接修改文件而不需要你逐步确认。这个模式效率确实高，但我的建议是：第一次使用或代码改动面较大时，不要开全自动。让它先输出修改计划，你确认了再让它动手。

5.3 配置文件的调整：模型、环境与行为偏好

CLI 的全局配置文件在~/.codex/config.toml。这个文件遵循 TOML 格式，我平时会调整几个字段：

model = "gpt-5-codex" model_providers = []

第一个字段指定默认模型，第二个字段可以扩展自定义模型供应商。如果你只是直觉安装、不需要折腾模型路由，默认配置就够用。

我建议每个人都去看一眼这个配置文件，不是因为它复杂，而是因为知道配置在哪、怎么改，后续排错会方便很多。有些问题的答案不在社区里，就在你自己的配置里。比如某个任务在 Codex 里表现不好，你可能想换个模型试试，这时候如果不知道配置位置，就得对着帮助文档一通翻。

6. IDE 集成：把 Codex 塞进你熟悉的编辑器里

6.1 VS Code 扩展安装与路径配置

CLI 用顺了之后，自然想把它整合进 IDE——毕竟直接在编辑器里看 diff、接受改动，比来回切终端舒服得多。目前最主流的方案是 VS Code 扩展。在扩展市场搜索“Codex”，安装 OpenAI 官方提供的扩展。安装完成后，左侧栏会出现一个 Codex 面板，你可以直接在面板里提问，它会自动读取当前打开项目的上下文。

但这里有一个关键接线问题：VS Code 扩展本身不包含 Codex 引擎，它还是要调用你本地安装的 CLI。所以扩展装完之后，你需要检查两个地方：

1. 扩展设置里的 CLI 路径是否指向正确位置。
2. 终端里codex --version是否正常输出版本。

如果你在终端里能跑但扩展报“unable to locate the codex cli binary”之类的错误，基本就是扩展找不到二进制的路径。这个报错在热词里反复出现，等下我在排错章节专门展开。

6.2 其他 IDE 的接入情况

VS Code 之外，JetBrains 系 IDE 也有相应的 Codex 插件支持。安装方式和 VS Code 类似：在插件市场搜索 Codex，安装后重启 IDE，然后在设置里确认认证状态。JetBrains 的新版本 IDE 对这类 AI 插件的支持已经比较成熟，但旧版本可能有兼容性问题。如果你用的 IDE 版本比较老，升级一下会有奇效。

还有一类情况是 IDE 本身内置了 AI 功能，但登录一直不成功。比如热词里的“antigravity ide登录不了”就属于这一类。这种集成型 IDE 的登录问题，我的排查思路一般是：先看它是否依赖本机 CLI，如果依赖，那 CLI 的安装和认证状态就是首要检查项；如果它是独立登录体系，那就检查账号授权状态。很多所谓“登录不了”其实是认证会话过期，重新登录一次就恢复。

6.3 IDE 集成时必须注意的版本对齐问题

IDE 扩展和 CLI 的版本需要匹配。扩展的更新频率通常低于 CLI 的发布频率，新版本 CLI 改了某个内部接口，老版本扩展可能就对接不上。我见过一个情况：CLI 升级到新版本后，VS Code 扩展一直提示“连接失败”，后来把扩展也升级到最新版才恢复。

版本对齐的检查方法很简单：打开扩展设置，看 CLI 路径那里能不能自动检测到版本号。有些扩展会直接显示检测到的 CLI 版本；如果没有显示，就在终端里运行codex --version和扩展的最新版本信息做对比。

另外，IDEA 是小事，平时的习惯才是大事。在 IDE 里用 Codex 时，注意让它针对当前项目的文件生效，别让它去读你根本没有 open 的其他目录，否则上下文会非常混乱。这个不是安装问题，但是很多人装上之后抱怨“结果不准确”，80% 都是因为项目打开方式不对。

7. 安装排错实战：我踩过的坑和完整排查链路

7.1 “无法定位 Codex CLI 二进制文件”：先检查这条路

这个报错应该是我见过频率最高的安装问题，热词里那句“chatgpt failed to start. unable to locate the codex cli binary or required r...”基本成了 Codex 新手村的标志性路障。我先说结论：这个错误几乎都是 IDE 扩展找不到 CLI 可执行文件造成的，跟你的模型配置、网络环境都没有关系。

完整排查链路是这样的，照着顺序走：

1. 先在终端里敲which codex（Windows PowerShell 里用Get-Command codex），把返回的路径记下来。
2. 确认路径真实存在。有时候 which 返回的路径指向的是一个已被卸载的 Node 版本，或者一个软链接已经断裂。
3. 打开 IDE 扩展的设置界面，找到类似 “Codex CLI Path” 的配置项，把它显式填成第 1 步得到的完整路径。
4. 重启 IDE，再次触发操作。

我之前踩过的坑是第 3 步没做。扩展默认用的是它自己推断的路径，但因为我用 nvm 管理 Node 版本，默认推断路径找不到可执行文件。手动指定路径之后，问题立刻消失。所以如果你用了任何版本管理器（nvm、n、fnm），大概率需要手动指定路径。

7.2 npm 权限报错和安装中断：分清楚是谁的锅

热词里的“codex windows安装未完成”和 Mac 上常见的EACCES: permission denied经常让人误以为是同一类问题。其实 Windows 安装未完成更多是网络中断或安装包下载不完整，而 Mac 上的权限问题是 npm 全局目录归属导致的。

Windows 安装未完成时，我的处理顺序是：

1. 查看 npm 日志。npm 会把错误日志写到当前目录下的npm-debug.log或缓存目录里，日志末尾会有具体失败原因。
2. 清理 npm 缓存npm cache verify，避免用了损坏的缓存包。
3. 重新执行安装。如果第二次还在同一位置中断，换用镜像源或检查磁盘空间。

Mac 上遇到 EACCES 时，我不建议无脑 sudo，而是先检查你当前用户对 npm 全局目录的权限：

ls -ld $(npm prefix -g) npm prefix -g

如果这个目录属于 root，说明安装 Node 的方式导致了目录权限问题。按第 3 节的方法把全局目录改到用户目录，或者修复目录所有权，比 sudo 安装更干净。

7.3 登录、网络和配置文件异常的排查思路

还有几类不那么显眼的报错，我按出现频率列一个速查表：

最后一类我要多提一句：配置文件被改动后导致的异常往往最隐蔽。某次修 bug 时试过改config.toml里的model_providers，结果格式写错，CLI 启动后一直报“配置文件解析错误”。我当时真的没料到是配置问题，反复重装了好几次，最后才发现就是少写了一个引号。所以排错时，先去检查你自己的配置文件，别急着重装。

8. 装完只是开始：推荐配置、升级习惯与日常维护

8.1 如何平滑升级，避免某天突然全部失效

Codex 的迭代速度不算慢，建议养成定期升级的习惯，但不要在项目进行到一半时突然手动升级。我自己的节奏是：每个周一上班后先检查 CLI 和 IDE 扩展是否有新版本，确认项目没有紧急任务再升级。不要等“某天突然不能用了”再去排查，那时你根本分不清是版本兼容变了还是网络问题。

Mac 上如果你用的 Homebrew：

brew update brew upgrade codex

如果你用的是 npm：

npm update -g @openai/codex

Windows 上同样用 npm update，WSL 里也一样。升级后记得codex --version确认新版本生效。

这里有个细节：Homebrew 和 npm 会各自维护一份 Codex 安装。如果你两个渠道都用过，升级时不要只更新其中一个。检查which codex确认当前生效的版本来自哪里，再决定升级哪个。我遇到过升级完 npm 版，以为是最新版，结果终端里跑的其实是 Homebrew 版的情况。

8.2 卸载与清理：干净离开才能干净重装

如果你需要换电脑、换环境，或者安装出了问题想彻底重装，这里有一个完整的卸载思路。

先卸载全局包：

npm uninstall -g @openai/codex

如果你用 Homebrew 装的：

brew uninstall codex

然后清理用户配置目录。在 Mac 和 Linux 上是~/.codex，在 Windows 原生环境上是C:\Users\<用户名>\.codex。如果你要彻底清空认证信息和历史会话，就把整个目录删掉。注意：这个目录里保存了你登录状态，如果你想留着以后再用，就别删；如果是为了解决认证问题，删掉重来也是最干净的方案。

卸载后偶尔会有残留文件，比如 VS Code 扩展本身的配置还指向 Codex CLI 路径，这时候去扩展管理里卸载扩展就会一并清理。

8.3 多环境共存的实用建议

我实际的工作流是 Mac 上装一份用于日常开发，Windows 台式机上再装一份用于在 Windows 侧跑一些 Windows 专属项目。两个环境并行的体验，我总结了三个实用的经验：

第一，在两个环境的配置文件里使用同一个 OpenAI 账号，认证一次之后两边都能工作，不需要维护两套账号体系。

第二，项目文件的位置会影响效果。Windows 原生环境对本地磁盘的访问速度快，但如果你的项目代码在 WSL 文件系统里，原生 Windows 的 CLI 直接去读会跨文件系统，性能会受影响。这种场景下，在 WSL 里安装一份 CLI 反而更顺。

第三，配置文件务必纳入版本管理。我习惯在 dotfiles 仓库里维护一份config.toml的模板，换新机器时直接复制过去改改路径就行。这个习惯帮我省了很多重复配置的时间。

8.4 最后分享一个实践中的小技巧

装完 Codex 之后，不要急着让它直接上手大项目。先在几个小项目上试几次，让它处理 README 补全、单文件重构、测试用例生成这类任务，摸清楚它的交互习惯。然后逐步把项目上下文放进去，你会发现它能给出的建议质量会明显上升，因为对话中它能记住你之前给出的反馈和偏好。

还有一个小技巧：多留意codex --help的输出。这个 CLI 的版本迭代非常快，几乎每个版本都会增加或调整参数。命令行工具的能力经常藏在这些看似不起眼的帮助文档里，每隔几周翻一次，比到处搜教程有效得多。

以上就是我在 Mac 和 Windows 两个平台上安装、配置、使用 Codex 的完整记录。安装环节本身不复杂，顺着文章里的路线走，绝大多数问题都能当场解决。真正需要耐心的，是之后把 CLI 和 IDE 的协作关系理顺，以及逐步建立起自己的使用习惯。