企业官网建设流程全解析

1. 装之前先搞清楚：Codex CLI 到底是个什么东西

很多人第一次听到 Codex CLI，脑子里浮现的是那个写代码的 AI 助手，但具体它跑在哪里、怎么跑、跟浏览器里用的有什么区别，其实并不清楚。我先把这件事讲透，不然后面装到一半遇到报错，你连自己在装什么都不知道，排查起来会很痛苦。

Codex CLI 是一个跑在终端里的命令行工具。你可以把它理解成一个住在你电脑命令行里的编程助手：你在 PowerShell 里敲一句话，它给你返回代码、解释、修改建议，甚至直接帮你改文件。它不是一个带界面的软件，没有窗口、没有按钮，全靠命令和参数驱动。这一点非常关键，因为后面所有的操作——安装、配置、启动、退出——都是在黑底白字的终端里完成的。

那为什么有人愿意用命令行而不是网页版？我自己的体会是三点。第一，它离你的项目更近。你在项目根目录启动它，它能直接读到你的文件结构、代码内容，不用你一段段复制粘贴。第二，它可以被脚本化。命令行工具天然适合嵌进自动化流程，比如批量处理、CI 环节。第三，响应链路更短。没有浏览器渲染、没有页面加载，交互更直接。

但代价也很明显：它对环境有要求。Codex CLI 本身是用 Node.js 生态分发的，也就是说你电脑上必须先有一个能跑的 Node.js 和 npm（Node 的包管理器），它才能被安装进来。这就像你想装一个手机 App，得先确认手机系统版本够不够——Node.js 就是那个"系统版本"。

所以这篇教程的路线图是这样的：先装 Node.js → 再确认 npm 能用 → 然后用 npm 装 Codex CLI → 最后跑通第一次对话。每一步我都会告诉你为什么这么做、容易在哪翻车、翻车了怎么救。零基础没关系，但你得按顺序来，跳步是这类工具安装失败的头号原因。

提示：整篇教程默认你用的是 Windows 10 或 Windows 11，并且有管理员权限（或者至少能自己装软件）。如果你在公司电脑上操作，先确认一下有没有软件安装限制，否则后面会卡在权限上。

2. 第一步：把 Node.js 装对，比装快更重要

2.1 为什么非得是 Node.js，不能直接下个 exe 吗

这是新手问得最多的问题。答案是：Codex CLI 的官方分发渠道就是 npm 仓库，它没有提供一个"双击安装"的独立 exe。npm 是 Node.js 自带的包管理器，所以你想要 npm，就必须先有 Node.js。这俩是捆绑的，装 Node.js 的时候 npm 会一起进来，不用单独装。

那 Node.js 又是什么？简单说，它是一个让 JavaScript 能脱离浏览器、直接在电脑上运行的环境。以前 JavaScript 只能活在网页里，Node.js 把它解放出来，让它能读写文件、开网络服务、跑命令行工具。Codex CLI 就是这样一个用 JavaScript 写的命令行工具，所以它需要 Node.js 来"托底"。

理解了这层关系，你就明白为什么网上那些"Codex CLI 安装失败"的帖子，十有八九根子都在 Node.js 上——要么没装，要么版本太老，要么装了但环境变量没配好，导致终端根本找不到它。

2.2 下载哪个版本：LTS 是唯一正确答案

打开 Node.js 官网，你会看到两个下载按钮，一个写着LTS，一个写着Current。很多人手一抖点了 Current，然后后面各种奇怪的报错就来了。

我的建议非常明确：永远选 LTS。LTS 是 Long Term Support 的缩写，意思是长期支持版，稳定、经过大量验证、生态兼容性最好。Current 是最新版，包含最新特性，但也可能有没被发现的 bug，而且很多 npm 包还没跟上适配。

具体到 Codex CLI 这类工具，它对 Node 版本通常有个最低要求（比如 18 或 20 以上）。LTS 版本一般都能满足，而且不会因为版本太新导致依赖冲突。我见过有人用 Current 版装完，跑起来报一堆模块找不到的错，换成 LTS 立刻就好了——这种坑完全没必要踩。

下载的时候选Windows Installer (.msi)那个 64 位版本，别去下 zip 压缩包。msi 安装包会自动帮你配好环境变量，zip 包得手动配，对零基础来说纯属给自己找麻烦。

2.3 安装过程中的三个勾选项，别乱动

双击 msi 之后一路 Next 就行，但中间有个界面会出现几个复选框，我逐个说：

• Add to PATH：这个必须勾。它的作用是把 Node.js 和 npm 的路径写进系统环境变量，这样你在任意目录打开 PowerShell 都能直接敲node和npm。不勾的话，你得手动配，新手极易配错。
• npm package manager：默认勾选，保持勾选。这就是 npm 本体。
• Tools for Native Modules：这个可选，会额外装一些编译工具，体积不小。如果你只是用 Codex CLI，可以不勾，省时间。但如果以后要装需要编译的 npm 包，可能会用到，到时候再补也行。

装完之后，一定要重启 PowerShell。注意，是关掉当前窗口重新开一个，不是在里面敲个命令刷新。因为环境变量是在进程启动时读取的，老窗口读的是旧环境，你不重启它永远找不到新装的 node。

2.4 验证安装：两条命令定生死

重开 PowerShell 之后，敲这两条：

node -v npm -v

正常的话，会分别打印出版本号，比如v20.11.0和10.2.4。看到版本号，说明 Node.js 和 npm 都到位了。

如果报错说"无法将 node 识别为 cmdlet、函数、脚本文件或可运行程序的名称"，那就是环境变量没生效。先确认你是不是真的重开了窗口；如果重开了还不行，检查安装时 Add to PATH 有没有勾；再不行就手动去系统环境变量的 Path 里加一条 Node.js 的安装目录（通常是C:\Program Files\nodejs\）。

注意：有些人的电脑上装了多个 Node 版本（比如以前装过又忘了），这时候node -v出来的可能不是你刚装的那个。用where node可以看当前实际调用的是哪个路径下的 node，确认一下是不是你新装的那个。

3. PowerShell 的脚本执行策略：那个让 npm 报错的隐形门槛

3.1 为什么 npm 会突然"无法加载文件"

这是 Windows 上装 Codex CLI 最经典的拦路虎，没有之一。你 Node.js 装好了，node -v也正常，结果一敲npm install就蹦出这么一段：

npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。

第一次看到这个报错，很多人以为是 npm 坏了，跑去重装 Node.js，结果重装完还是这个错。其实 npm 一点问题没有，问题出在PowerShell 的脚本执行策略上。

PowerShell 出于安全考虑，默认不允许运行任何.ps1脚本文件。而 npm 在 Windows 上恰恰是通过一个叫npm.ps1的脚本被调用的。策略禁止运行脚本，npm 自然就起不来。这跟 npm 本身无关，是 PowerShell 的门槛。

3.2 查看当前策略，再决定怎么改

先看看当前是什么策略：

Get-ExecutionPolicy

大概率会返回Restricted，意思就是"禁止一切脚本"。这就是罪魁祸首。

解决方式是把它改成RemoteSigned。这个策略的含义是：本地自己写的脚本可以跑，从网上下载的脚本需要有数字签名才能跑。对日常开发来说，这是安全性和可用性平衡得比较好的一个档位，比直接设成Unrestricted（什么都不管）要稳妥。

改的时候有个关键点：要改当前用户级别的策略，而不是整个系统级别的。命令是：

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

它会问你确认，输入Y回车。这样改只影响你自己的账户，不需要管理员权限，也不会动到系统全局设置，相对安全。

改完再敲一次Get-ExecutionPolicy，应该返回RemoteSigned。这时候再回去跑 npm 命令，那个报错就消失了。

3.3 改策略这件事，到底安不安全

我知道有人会担心：把脚本执行放开，是不是等于给病毒开门？这里说清楚。

RemoteSigned的核心逻辑是：本地脚本放行，远程脚本要签名。也就是说，如果有个恶意脚本是从网上下载到你电脑上的，它没有可信签名，照样跑不起来。真正被放开的只是你自己在本地创建或修改的脚本。对于开发者来说，这个策略是业界普遍推荐的最低可用配置。

真正危险的是Unrestricted和Bypass，那两个才是几乎不设防。所以别图省事直接设成 Unrestricted，用 RemoteSigned 就够了。

提示：如果你在公司的域环境里，执行策略可能被组策略锁死，Set-ExecutionPolicy会报"被覆盖"之类的错。这种情况得找 IT 管理员，自己改不动。个人电脑一般不会遇到。

4. 用 npm 把 Codex CLI 装进来

4.1 全局安装还是本地安装

npm 装包分两种：全局（-g）和本地（不带-g）。Codex CLI 这种命令行工具，要的是全局安装，因为你需要它在任何目录下都能被调用，而不是只在某个项目文件夹里能用。

命令是：

npm install -g @openai/codex

这里的@openai/codex是包的完整名称，@openai是作用域（scope），codex是包名。作用域的作用是把同一个组织下的包归类，避免和别人的同名包冲突。

敲下去之后，npm 会去仓库拉取这个包以及它依赖的一堆东西，屏幕上会滚动一堆进度。等它停下来，没有红色ERR字样，基本就是成功了。

4.2 国内网络环境下的加速方案

如果你在国内，直接跑上面那条命令可能会非常慢，甚至卡住不动。原因是 npm 默认的仓库地址在国外，拉包要跨网络，速度不稳定。

解决办法是换成国内镜像源。常用的是淘宝源（现在叫 npmmirror）：

npm config set registry https://registry.npmmirror.com

设完之后，再用npm config get registry确认一下，返回的是你刚设的地址就对了。然后再跑安装命令，速度会有肉眼可见的提升。

这里有个经验：镜像源不是万能的。有些包在镜像上同步不及时，或者某些作用域包镜像没收录，这时候反而会报"找不到包"。如果换了镜像装不上，可以临时切回官方源试试：

npm install -g @openai/codex --registry=https://registry.npmjs.org

这条命令只对当前这一次安装生效，不会改你的全局配置，比较灵活。

4.3 安装完怎么确认真的装上了

装完之后，敲：

codex --version

如果打印出版本号，说明装好了，而且 PATH 也配对了。如果报"无法识别 codex"，那可能是全局包的安装目录没在 PATH 里。

用这条命令看全局包的安装位置：

npm config get prefix

返回的路径（比如C:\Users\你的用户名\AppData\Roaming\npm）就是全局包的可执行文件所在目录。确认这个目录在系统环境变量的 Path 里。如果不在，手动加进去，然后重开 PowerShell。

注意：改完环境变量一定要重开终端窗口，这个规则在整篇教程里反复出现，因为它真的太容易被忽略了。很多人改完 Path 发现还是不行，就是因为没重开窗口。

5. 第一次启动 Codex CLI 与常用命令上手

5.1 在哪个目录启动，决定了它能看见什么

Codex CLI 是上下文敏感的工具，它在哪个目录启动，就默认能访问那个目录下的文件。所以正确的做法是：先 cd 到你的项目根目录，再启动。

cd D:\projects\my-app codex

如果你在C:\Users\你的用户名这种地方启动，它看到的就是一堆系统文件夹，对你写代码没帮助，还可能因为权限问题读不了某些目录。

启动之后，通常会进入一个交互式界面，你可以直接输入自然语言描述你的需求，比如"帮我看看这个函数为什么报错"或者"给这个文件加个单元测试"。它会读取当前目录的上下文来回应你。

5.2 几个你迟早会用到的内置命令

Codex CLI 的交互界面里，除了直接说话，还有一些以斜杠开头的内置命令，用来控制会话本身。这些命令不是给 AI 的指令，而是给工具的操作指令。常见的几个：

/compact这个特别值得说。AI 对话有个"上下文窗口"的概念，就是它能同时记住的内容有上限。聊得越久，累积的内容越多，一旦超过窗口，早期的内容就会被挤掉，表现为它开始"忘记"你前面说过的话。/compact的作用就是把之前的对话压缩成摘要，腾出空间，同时保留关键信息。感觉对话变迟钝了，敲一下它，往往能救回来。

/resume则是解决"手滑关了窗口"的痛点。它会列出你之前的会话，让你选一个继续，不用从头再来。

5.3 退出与卸载

退出交互界面一般是敲/exit或者按Ctrl+C两次。具体看版本，界面上通常会有提示。

如果哪天你不想用了，卸载命令是：

npm uninstall -g @openai/codex

这条命令会把全局安装的 Codex CLI 移除。注意它不会动你的 Node.js，Node.js 要单独卸（去控制面板的程序列表里找）。

6. 装完跑不起来？按这个顺序排查

6.1 排查要讲顺序，别东一榔头西一棒子

新手遇到报错最容易犯的错，就是看到什么错就搜什么，改一堆东西，最后把环境搞得更乱。正确的做法是从底层往上查：Node.js → npm → 执行策略 → 包安装 → PATH。因为上层依赖下层，下层不通，上层怎么改都没用。

我整理了一个排查顺序表，照着走基本能定位到问题：

6.2 两个我踩过的真实坑

第一个坑是多版本 Node 打架。我电脑上以前装过一个老版本 Node，后来装新版的时候没卸干净，结果node -v显示的是老版本，npm 装包各种报错。用where node一看，居然有两个路径。解决办法是把老版本卸掉，或者调整 Path 里的顺序，让新版本排在前面。

第二个坑是镜像源设了但没生效。我明明设了淘宝源，装包还是慢。后来发现是项目目录下有个.npmrc文件，里面的 registry 配置覆盖了全局设置。npm 的配置是有优先级的：项目级 > 用户级 > 全局级。所以如果你在某个项目里设过源，它会盖过你全局设的。检查项目根目录有没有.npmrc，有的话看看里面写了什么。

6.3 关于 PowerShell 乱码和闪退

有人的 PowerShell 中文显示成乱码，这通常是编码问题。可以临时用chcp 65001把当前窗口切到 UTF-8 编码。想永久解决，得改系统区域设置或者 PowerShell 配置，稍微麻烦点，但日常用临时切换基本够。

至于"脚本命令闪退"，多半是因为脚本执行完就自动关窗口了。解决办法是在脚本末尾加一句pause，或者从已经打开的 PowerShell 窗口里手动执行脚本，而不是双击运行。

7. 把它用顺手的几个个人习惯

装好只是起点，真正让它产生价值的是使用习惯。我自己用下来，有几个做法明显提升了效率。

第一，项目根目录放一个说明文件。Codex CLI 读取上下文时，如果根目录有个清晰的 README 或者项目结构说明，它给出的建议会准确很多。相当于你先给它交代了背景，它就不用瞎猜。

第二，描述需求时带上具体文件路径。与其说"帮我改一下登录逻辑"，不如说"看一下src/auth/login.js里的登录逻辑，把错误处理补全"。路径越具体，它定位越准，来回拉扯的次数越少。

第三，长会话记得用/compact。我一开始不知道这个命令，一个会话聊到后面它开始答非所问，我还以为是模型不行。后来学会定期压缩上下文，体验完全不一样。

第四，换模型用/model按需切换。简单任务用快模型，复杂重构用强模型，不必一直用最贵的那个。这个习惯能省不少等待时间。

最后说一句关于版本更新的。Node.js 和 Codex CLI 都在持续迭代，偶尔会遇到新版本引入的兼容问题。我的做法是：生产环境用的版本不轻易升，等社区反馈稳定了再动。如果升级后出问题，回退到上一个 LTS 版本通常能立刻恢复。工具是拿来干活的，稳定比尝鲜重要。