企业官网建设流程全解析

上周末我干了一件有点“套娃”的事：让 OpenAI 的 Codex 命令行工具，去帮我安装 Anthropic 的 Claude Code。翻译成人话就是——我让一个 AI 编程代理，去装另一个 AI 编程代理。听起来像段子，但整个过程其实暴露出了很多关于 AI 代理工具的真相：不是发布会演示里行云流水的效果，而是它在真实终端里满屏输出、频繁停下来问你要权限、偶尔还会犯低级错误的模样。

这篇就把这次实操完整记录下来，包括环境检查、依赖安装、Claude Code 的登录配置、两个工具联调验证，以及我中途踩过的坑和给 Codex 下达的指令模板。如果你也在 WSL 里折腾这些 CLI 工具，或者单纯对“AI 装 AI”这件新鲜事感兴趣，这篇应该能帮你在正式开始前少走不少弯路。

1. 项目背景：为什么让 AI 来装 AI 工具

1.1 Codex 和 Claude Code 到底是什么

先给可能刚接触这两个名字的朋友捋一下。Codex 是 OpenAI 推出的命令行编程代理，它跑在你本地终端里，能读取你的文件目录、执行 shell 命令、调用各种开发工具。它不是那种聊天框里的 AI，而是直接接管终端的“干活型”智能体。你用自然语言给它下指令，它自己拆分任务、找文件、敲命令、看结果，再决定下一步做什么。

Claude Code 则是 Anthropic 出品的同类工具，名字很像，定位也很像：一个在终端里工作的 AI 编程助手，能理解代码仓库、执行操作、辅助完成开发任务。两个工具本质上都是“跑在终端里的 AI agent”，只是背后的大模型不同，各自的插件生态和配置方式也有差异。

这次我的核心任务很直接：让 Codex 帮我在 WSL 环境里安装 Claude Code，并且完成配置验证，保证两个 CLI 工具能在同一台机器上共存、互不干扰。听起来简单，但里面牵扯到 Node.js 版本、环境变量、权限目录、登录认证方式这些细节，任何一个没处理好都容易白折腾一小时。

1.2 为什么选 WSL 当试验场

很多朋友会问：Windows 上直接装不行吗？为什么非要绕一圈进 WSL？这里我多说一句自己的理解。WSL（Windows Subsystem for Linux）是 Windows 下的 Linux 子系统，等于在 Windows 里跑了一个完整的 Linux 发行版环境。Claude Code 和 Codex 虽然官方都支持 Windows，但要论兼容性、权限模型、路径处理这些细节，原生 Linux 环境明显更省心。

我自己在 Windows 下装过 Claude Code，遇到过 PowerShell 脚本执行策略拦截、路径分隔符不匹配、npm 全局包权限怪异这类问题。而在 WSL 里，所有操作都遵循 Linux 那套成熟的约定，遇到问题能搜到的解决方案也多得多。如果你打算长期用这类 CLI agent 工具搞开发，我建议环境尽量往 WSL 或云主机上放，别和 Windows 的系统权限较劲。

另外，WSL 本身也是很多开发者日常工作的“主场”，Ubuntu 环境里预装了常见的构建工具链，npm 全局安装、node 版本管理、shell 脚本执行都顺畅不少。把 AI 工具装进去，未来做开发任务时也能和本地代码仓库无缝衔接。

1.3 这次实验想验证的三件事

在动手之前，我心里给自己列了三个验证目标，每次做完这种事我都会这么干，避免糊里糊涂装完发现不是自己想要的。

第一，Codex 的自主执行能力到底靠不靠谱。也就是它在没我逐步指导的情况下，能不能自己分析需求、查资料、装依赖、验证结果。现在很多 AI 编程工具宣传得很神，但真实场景里能走完整流程的不多，我想借着这个安装任务实际测一遍。

第二，两个 AI agent 工具能否在同一环境里和平共处。它们都要占用 npm 全局目录，都要写各自的配置文件，还可能抢终端焦点。会不会装完一个把另一个搞坏，这是我想重点观察的。

第三，配置完成后的真实体验。Claude Code 登录后能不能正常响应指令，Codex 又有没有被影响，两个工具能不能在同一目录下处理同一个项目。毕竟工具装好只是开始，真正好用才是目的。

带着这三个目标，我开始动手。结果是：目标基本达成，但过程远没有想象中顺滑，中间有好几次我差点想放弃自己上手装了。

2. 环境准备与前置检查

2.1 WSL 版本确认与系统更新

万事开头先看环境，这步省不得。我先在 Windows 终端里执行了wsl --version确认 WSL 版本。这里有个小知识点：如果你用的是旧版 WSL 1，很多现代工具会出现莫名其妙的文件系统性能问题，建议直接上 WSL 2。我这边是 WSL 2，Ubuntu 22.04 LTS，算是比较稳的搭配。

进入 WSL 环境后，我的习惯是先做一轮系统更新。虽然和安装 Claude Code 没有直接关系，但 apt 源里的基础库版本会影响后续编译和依赖解析，系统太老容易在 npm 安装阶段撞上奇奇怪怪的兼容报错。

sudo apt update && sudo apt upgrade -y

这一跑就是十来分钟，Ubuntu 更新包比较多的时候很正常。更新过程中 Codex 已经通过 WSL 终端在待命了——注意到没有，Codex 本身就装在 WSL 里，所以它看到的文件系统、权限模型和我完全一致，这是它能帮我干活的先决条件。

提示：如果你还没装 WSL，先在 Windows 上执行wsl --install，装完后默认的 Ubuntu 会用 WSL 2 模式。装好后记得重启一次终端，让环境变量生效。

2.2 Node.js 和 npm 版本踩线

这一步是整个安装任务里最关键的前置条件。Codex 和 Claude Code 都是基于 Node.js 的 npm 全局包，必须确认 Node 版本满足要求。Codex 当时要求 Node.js 18 以上，Claude Code 同样要求 18 以上，但我实测下来建议直接上 Node 20 或更高，因为 18 虽然能跑，某些新版依赖会对 18 发出警告，看着心慌。

我先看了一下系统里已有的版本：

node -v npm -v

第一次检查发现 WSL 里自带的是 Node 12——太老了，直接排除。这里我建议别用 apt 默认源装 Node，版本太旧，后续你会到处碰壁。正确姿势是走 NodeSource 官方源，安装 Node 20 LTS：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs

装完再验证一次node -v，确认变成 v20.x。npm 会随着 Node 一起装好，不用单独配置。这里我额外提一句：如果你平时还跑其他 Node 项目，直接覆盖系统 Node 版本可能影响旧项目，更稳妥的做法是用 nvm 管理多版本。但我这台 WSL 是相对干净的开发环境，所以直接上系统级安装，省事。

2.3 给 Codex 的下一个指令

环境准备好之后，就是本次实验的重头戏。我在 Codex 的交互界面里输入了这样一段指令：

请在当前 WSL 环境中完成以下任务： 1. 检查 claude 命令是否已安装； 2. 如果未安装，使用 npm 全局安装 @anthropic-ai/claude-code； 3. 安装完成后验证 claude --version 能否正常输出； 4. 把安装过程中遇到的任何错误都输出给我，不要尝试绕过任何权限限制。

注意我在指令里加了两个关键约束：一是“不要尝试绕过任何权限限制”，防止它在拿不到权限时自作主张去改系统文件权限或者禁用安全机制，这是我对 AI agent 的基本安全要求；二是要求它“把错误输出给我”，这样即使失败我也能拿到完整日志去排查，而不是它自己在脑子里脑补一个“成功”。

Codex 收到指令后做了一件让我意外的事：它没有立刻动手，而是先把环境检查了一遍，输出了一句话，大意是“检测到 Node v20.12.2，npm 10.x，满足安装条件，我将开始执行”。然后才真正进入安装流程。

这个细节让我对 Codex 的成熟度有了新的认识：它知道自己需要确认环境，而不是盲目执行命令。这比很多直接开跑的 AI agent 要靠谱。

3. Codex 的执行全程实录

3.1 Codex 先自己列了一份安装计划

Codex 在动手前其实还给了一份它自己的执行计划，我这边简化一下记录：

1. 确认 npm 全局安装路径可写； 2. 执行 npm install -g @anthropic-ai/claude-code； 3. 等待安装完成，检查退出码； 4. 运行 claude --version 验证安装结果； 5. 输出最终报告。

这份计划本身没毛病，但问题藏在第一步。它检查完 npm 全局路径后发现，全局目录位于/usr/lib/node_modules，这个目录的写权限属于 root，普通用户没法直接往里写。Codex 默认要用当前用户身份执行命令，所以它在这一步停住了，问我是否允许使用 sudo 权限来执行安装命令。

这里我必须坦诚，我当时有过一瞬间的犹豫：让 AI 拿着 sudo 去装包，等于给它了系统的“钥匙”。但我很快意识到，npm 全局安装本身就必须要有写系统目录的权限，这是工具设计决定的，不是 Codex 在乱搞。而且它在动手前主动征询我的同意，而不是偷偷用 sudo，这个行为模式是符合安全预期的。于是我给了确认。

3.2 它实际敲了哪些命令

得到确认后，Codex 执行的安装命令就是标准的 npm 全局安装。我通过它的输出日志，完整把命令摘出来了：

sudo npm install -g @anthropic-ai/claude-code

说实话，看到这行命令我有点啼笑皆非——问题本身不复杂，我自己敲也是这一行。但区别在于，Codex 是在完整理解“为什么装”的基础上敲出这行命令的，而且后面它还会自动做验证。这就是代理工具和普通脚本最大的不同：它会根据结果动态调整下一步。

安装过程输出了一长串 npm 的下载进度，几十秒后提示成功。Codex 紧接着执行了：

claude --version

输出结果是1.x.x版本号，安装本身一次通过，没有任何波澜。但我很清楚，真正的坑往往在验证通过之后——CLI 工具装好不等于能用，登录认证才是真正的鬼门关。

3.3 我唯一一次强制介入

整个过程里我只强制介入了一次，起因是 Codex 在验证完版本号后，擅自决定要继续“帮助”我配置 Claude Code 的 shell 集成，往我的~/.bashrc里追加一行初始化脚本。我立刻打断了它，明确要求它先停下来，把要做的修改给我看，等我确认再执行。

这件事给我的触动很大。Codex 的本意是好的——Claude Code 的官方文档确实推荐把初始化脚本加到 shell 配置里，这样每次打开终端就能用。但问题在于，修改 shell 配置文件属于影响面很大的操作，如果脚本里有兼容性问题，可能导致以后每次打开终端都报错。一个成熟的 agent 应该先展示改动内容、解释影响、获取用户确认，而不是把“推荐操作”当成“可以直接做的操作”。

最终我命令 Codex 回滚了这次修改，改用手动配置的方式。我后来自己看了那份初始化脚本，内容本身没问题，但在不清楚用户 shell 环境细节的情况下，这种修改确实应该更加慎重。这件事让我在后面的所有 AI 代操作里都养成了一个习惯：任何涉及配置文件的变更，都要求 AI 先展示 diff 再执行。

4. Claude Code 配置和认证

4.1 两种认证方式怎么选

安装完成后，运行claude会进入一个认证流程。Claude Code 主要支持两种方式：一种是浏览器登录后粘贴授权码，另一种是在环境变量里配置 API 密钥。

浏览器登录的方式适合个人日常使用，它会生成一个链接，你拿到浏览器里打开、授权、再把授权码粘贴回终端。整个过程类似很多开发工具的 OAuth 登录。API 密钥方式则更适合脚本化或者自动化场景，但密钥本身要小心保管，别直接写进仓库。

我这次选择的是浏览器登录，一个原因是它不需要额外管理系统密钥，另一个原因是认证状态会存在本地的配置目录里，后续使用不用反复登录。这里有个细节值得强调：Claude Code 的配置目录是~/.claude，认证信息就存在这里。如果你未来要迁移环境或者容器化部署，记得要把这个目录一并处理，否则到新环境还要重新认证。

4.2 按自己习惯调整配置文件

认证完成之后，Claude Code 默认配置就能直接用，但我个人习惯看一遍它的配置文件，按自己的偏好微调一下。Claude Code 的配置文件路径在~/.claude/settings.json，也可以在项目根目录放.claude/settings.json做项目级覆盖。

我调整了几个关键项：一是开启自动审批权限，让它在处理一些常见操作（比如读取文件、执行安全的 shell 命令）时不用每步都停下来问；二是设置了输出风格为 verbose，方便我在它执行任务时看到完整过程而不是最终结果；三是把默认模型切换到我更常用的版本。

{ "permissions": { "allow": [ "Read", "Edit", "Bash(npm run *)", "Bash(git *)" ] }, "outputStyle": "verbose" }

这里我最想提醒大家的一个坑是：权限配置里的 allow 列表一定要克制。你允许的 Bash 命令范围越宽，agent 能做的事情越多，出错或产生意外后果的风险也越大。像我在上面只允许了npm run和git开头的命令，覆盖绝大多数日常开发场景，但避免了让它随便执行rm、curl这类高风险命令。

4.3 双 AI 联调：让 Codex 检查 Claude

配置完成后，我做了两轮联调。第一轮是我手动运行claude并在会话里让它读一个测试项目里的 README，解析其中的功能列表并给出开发建议。它响应正常，输出结构清晰，说明安装和认证确实都成功了。

第二轮更有意思：我切回 Codex，让它去检查 Claude Code 的配置文件是否合法，以及两个工具是否在终端环境里互相影响。Codex 乖乖地去查看了~/.claude/settings.json，逐行检查了 JSON 语法，还对比了两个工具各自的环境变量有没有冲突。最后它给了一个结论：两个工具完全独立，配置互不干扰，可以并行使用。

这两轮验证跑完，这次“AI 装 AI”的任务才算真正收尾。我后来实际用这两种工具处理同一个开发任务来对比体验，发现它们各自的优势和短板还挺明显，这个以后有机会再单独写一篇。

5. 我遇到的那些坑

5.1 安装阶段的报错现场

虽然这次安装看来很顺，但为了让大家少走弯路，我把常见的报错和原因整理一下。很多坑我自己在别的环境里也踩过，一并写在这里。

npm 安装时最容易出现的报错是 EACCES 权限不足，这通常是因为 npm 全局目录属于 root，而你在用普通用户安装。解决办法有两个：一是像我这次一样用 sudo 安装，但要注意安全风险；二是更推荐的方式，修改 npm 全局目录到你自己的用户目录下：

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

改完之后记得把~/.npm-global/bin加入 PATH，然后重新打开终端。

另一个常见报错是网络超时，npm 下载包的时候偶尔会卡住。这不是什么玄学问题，大多是网络波动或者 npm 源响应慢。处理方式是换用国内 npm 镜像源，这是合法且常规的加速手段：

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

换完源之后下载速度往往会有立竿见影的提升。如果你在安装过程中看到类似ETIMEDOUT或ECONNRESET的错误，优先检查网络连接和 npm 源配置，别急着重装系统。

5.2 运行时权限和路径问题

安装完了不代表万事大吉。我第一次运行claude的时候，遇到了配置目录不可写的问题，现象是工具启动时报错，说是无法写入配置文件。排查下来发现~/.claude目录的属主变成了 root，原因是我之前用 sudo 执行了某些初始化命令，导致它以 root 身份创建了配置目录。

这个问题的解决办法很简单，把这个目录的属主改回当前用户就行：

sudo chown -R $USER:$USER ~/.claude

还有一个非常典型的问题，就是 PATH 没包含 npm 全局安装目录。你明明装好了 Claude Code 或 Codex，一运行却提示command not found。这种情况看两个地方：全局目录到底在哪，以及有没有加入 PATH。可以用npm prefix -g查全局根目录，然后确认$(npm prefix -g)/bin在 PATH 里。

如果你改过 npm 的全局目录，记得同步更新 shell 配置文件里的 PATH，否则下次打开新终端又会找不到命令。这也是我这个环节里最经常被问到的问题。

5.3 问题速查表

我把这次遇到的和之前积累的相关问题整理成一张速查表，方便你直接对着排查。

排查这类问题有个通用思路：先看是不是环境变量和路径的问题，再看是不是权限问题，最后才是重装。好多朋友一遇到报错就卸载重装，其实前面两步能覆盖八成的 CLI 工具故障。

6. 一次实战之后的几点体会

任务结束后我坐在终端前发了会儿呆。让 AI 帮我装 AI，这件事本身带来的信息量比装好一个工具大得多。

我的第一个体会是，Codex 这类工具已经具备了“完整执行任务”的雏形，但它目前的可靠边界非常清晰：凡是流程标准化、命令明确、验证手段清晰的任务，它都能干得又快又稳；可一旦任务里包含模糊的判断、涉及修改系统级配置、或者需要结合用户个人偏好做决策，它就会露怯，要么停下来反复问，要么自作主张往前冲。我这次强行打断它修改.bashrc，就是因为它触到了判断力的边界。

第二个体会是关于信任边界的。把 sudo 权限或者配置文件的修改权交给 AI agent 时，我心里要有一根清晰的线：哪些操作默许、哪些操作必须经过我确认。这不只是对工具的不信任，也是对自己工程素养的要求。AI 代操作的真正价值，是把我从机械性流程里解放出来，而不是让我把判断责任也甩给它。

第三个体会比较实用：这类工具体验好不好，很大程度上取决于环境干不干净。WSL 里把 Node 版本、npm 全局目录、shell 配置都理清楚之后，装什么都顺。如果你刚接触 WSL 和 AI 工具，我建议先把基础环境打磨利索，再让 AI 进场，体验会完全不一样。

最后再分享一个小技巧。现在我自己在 WSL 里同时装着 Codex 和 Claude Code，日常分工很明确：Codex 比较擅长快速的脚本任务和代码生成，Claude Code 在理解复杂项目和长上下文方面有它的优势。遇到不确定谁更能胜任的任务，我会让两个工具各跑一遍同样的需求，对比它们的方案和代码质量，再择优使用。这不失为一种高效利用 AI 工具的策略——反正它们已经装好了，多一个参考意见总不是坏事。