企业官网建设流程全解析

这次的事从标题看就很直接：OpenAI 的 Codex 把 Claude Code 用户的本地配置、自定义技能、AGENTS.md、命令模板这些“家当”一键整理进了 Codex，但 Claude 模型本身没法跟着走。对每天用 CLI 写代码、调模型的开发者来说，这个变化值得认真看一遍：哪些东西能迁，哪些要手动补，迁移之后 Codex 到底怎么跑，以及最关键的，模型接口怎么接。

这篇文章就围绕这条主线展开。先给能力规格，再走一遍环境准备、安装、迁移、验证、接口调用和排错流程。内容会保持实操向，不写空泛的行业分析。如果你最近正打算从 Claude Code 切到 Codex，或者想同时维护两套 CLI 配置，可以直接按下面的步骤过一遍。

1. 核心能力速览

先看这张表，确认 Codex 和这次迁移相关的核心能力在什么位置。

从表格可以看到，Codex 的核心定位仍然是“终端里的 AI 编程助手”，不属于本地模型部署项目，所以不用纠结显存和显卡型号。真正需要关注的是本地配置的完整程度，以及模型端点的可用性。

2. 事件背景：“搬空”背后的配置迁移逻辑

“搬空”这个说法听起来像灰色操作，实际指的不是盗号，也不是绕过付费，而是把 Claude Code 在本地积累的个性化配置资产，迁移到 Codex 的配置体系里。

Claude Code 在长期使用后会沉淀出下面这些“家当”：

• ~/.claude全局配置，包括 settings.json、CLAUDE.md、skills 目录等。
• 项目根目录的.claude配置，包括项目级 skills、自定义 slash commands、hooks。
• AGENTS.md 文件，用来给 AI 提供项目背景和编码规范。
• 环境变量和本地代理配置，比如模型端点、API 地址、组织 ID。
• MCP server 配置，用来连接外部工具和数据源。

这些配置本身是文本文件，有明确的格式和目录结构，所以具备可迁移性。Codex 同样有类似的目录逻辑，比如全局配置目录~/.codex，项目级目录.codex，以及 AGENTS.md 支持。这就为“一键搬运”提供了技术基础。

但“唯独带不走 Claude”的原因也很明显：Claude Code 的运行核心是 Anthropic 的 Claude 模型，模型推理依赖账号权限和 API key。迁移工具能把本地配置导出来，却不能把 Anthropic 账号里的模型权限一并导出。到了 Codex 环境里，模型端点需要重新配置，要么使用 OpenAI 模型，要么通过兼容端点接入第三方模型服务。

所以这次迁移的本质是：配置外壳可以搬，模型运行时不能搬。理解这一点，后面所有操作都不会跑偏。

3. 环境准备与前置条件

在开始迁移之前，先把环境检查一遍。Codex 和 Claude Code 都是 CLI 工具，依赖 Node.js 环境，部分功能还需要 Git 支持。

3.1 操作系统与终端

• Windows：建议使用 PowerShell 7+ 或 Windows Terminal，避免使用旧版 cmd。
• macOS：使用自带 Terminal 或 iTerm2，安装 Homebrew 后可简化安装流程。
• Linux：常见发行版均可，建议使用 bash 或 zsh。

3.2 Node.js 与 npm

CLI 工具通常通过 npm 全局安装，需要先确认 Node.js 版本。

node -v npm -v

如果版本过低，建议安装 Node.js 18 或更高版本。升级 Node.js 时注意 npm 全局路径，避免之后出现命令找不到的问题。

3.3 API Key 与服务账号

迁移配置后，最终还是要能调用模型，所以需要准备至少一个可用模型端点：

• 如果使用 OpenAI 官方模型，准备 OpenAI API Key。
• 如果使用第三方兼容端点，准备该服务提供的 API Base URL 和 Key。

这里需要特别提醒：不要把 API key 硬编码进准备迁移的配置文件中。迁移前先检查~/.claude/settings.json和.env文件，把敏感信息单独用环境变量管理。

3.4 磁盘与网络

CLI 工具本身的体积很小，但会缓存一些日志、会话记录和模型调用数据。建议保留至少 1GB 可用磁盘空间。网络方面需要能正常访问模型 API 端点，如果本地有代理工具，需要确认代理端口和协议完全一致。

4. 安装 CLI 与启动前的常见报错

在迁移之前，先保证 Codex 和 Claude Code 都能正常启动。这里给出一套通用安装步骤，实际包名以官方文档为准。

4.1 安装 Claude Code

# 安装示例，实际包名以官方文档为准 npm install -g @anthropic-ai/claude-code

安装后检查版本：

claude --version

如果出现下面这类报错：

claude : 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称

说明 npm 全局安装路径没有加入 PATH。在 PowerShell 里可以这样检查：

npm prefix -g

然后把其中的 bin 目录加入系统 PATH，再重开终端。

4.2 安装 Codex CLI

# 安装示例，实际包名以官方文档为准 npm install -g @openai/codex

启动前同样检查：

codex --version

如果遇到：

unable to locate the codex cli binary. set codex cli path or ensure the elec...

大概率是 Codex CLI 没有被正确加入 PATH，或者启动器没有找到codex二进制。排查顺序是先确认安装目录，再检查 PATH，最后检查是否安装了正确的 Node 版本。

4.3 确认双 CLI 可同时存在

Codex 和 Claude Code 使用不同的配置目录，互不覆盖。可以同时安装，迁移过程中也建议保留 Claude Code 原环境，等 Codex 完全验证通过后再清理旧配置。

5. 一键迁移：把 Claude Code 的“家当”搬到 Codex

这里需要说明一下，迁移命令在不同版本中可能有差异，因此不写死某条命令。更稳妥的方式是理解迁移逻辑：读取 Claude Code 的配置目录，解析成 Codex 可识别的格式，再写入 Codex 的配置目录。

5.1 迁移前的配置备份

不管使用官方迁移工具，还是手动迁移，第一步永远是备份。

# 备份 Claude Code 全局配置 cp -r ~/.claude ~/.claude.bak # 备份项目级配置 cp -r .claude .claude.bak # 备份 AGENTS.md cp AGENTS.md AGENTS.md.bak

备份之后，检查配置中是否存在 API key、组织 ID、内部域名等敏感信息。如果存在，先替换为环境变量占位符，再执行迁移。

5.2 核心迁移流程

迁移工具的核心行为是目录映射和格式转换。下面是常见的迁移映射关系：

如果没有官方迁移命令，可以按这个映射关系手动建立目录，再把文本内容复制过去。如果官方迁移工具提供了交互提示，通常会在终端中问你是否覆盖已有配置，这时建议选择“不覆盖”，先做对比。

5.3 迁移完成的判断标准

迁移是否成功，不只看文件是否复制过去，还要看 Codex 是否能正确读取。

一个简单的验证方式是：

# 查看 Codex 配置目录是否生成 ls -la ~/.codex # 查看项目级配置目录 ls -la .codex

如果生成的文件内容和源配置语义一致，迁移第一步就算完成。之后还需要启动 Codex，确认模型调用链路可用。

6. 迁移后配置校验：skills 与自定义命令是否生效

配置复制过去不意味着自动生效，Codex 有自己的加载逻辑。重点验证三块内容。

6.1 全局规范是否加载

Codex 会读取 AGENTS.md 作为全局行为规范。可以在任意目录启动 Codex，输入一段测试指令，观察回复是否遵循 AGENTS.md 中定义的代码风格和约束。

6.2 项目级配置是否加载

进入项目目录，先确认.codex和AGENTS.md存在，再启动 Codex。输入与项目背景相关的问题，如果回复内容包含项目结构信息，说明项目级配置已生效。

6.3 skills 是否被识别

skills 通常对应一个目录和描述文件。迁移后需要在 Codex 中列出可用命令，确认 skill 名称出现在列表里。

# 在 Codex 中列出可用命令 codex --help

如果 skill 没有出现，检查目录名称和描述文件的格式，Codex 可能对 skill 名称规则有限制，需要把驼峰命名改为中划线命名。

7. 带不走的 Claude：模型接入与第三方兼容端点

迁移完成后，最关键的环节是模型接入。调用模型时，Claude Code 使用 Anthropic 协议和账号授权，而 Codex 默认使用 OpenAI 协议和 OpenAI 模型。由于 Claude 模型权限无法迁移，必须重新配置模型端点。

7.1 使用 OpenAI 官方模型

最简单的方式是使用 OpenAI 账号对应的模型。在~/.codex/config.toml中指定模型名称。

# ~/.codex/config.toml 示例，模型名请以实际可用模型为准 model = "MODEL_NAME" temperature = 0.2 [api] api_key = "YOUR_API_KEY"

其中MODEL_NAME需要替换成当前可用的模型名称，YOUR_API_KEY建议改成环境变量引用，避免直接写入明文。

7.2 接入第三方兼容端点

如果实际场景需要接入 DeepSeek、通义、GLM 等服务，需要把 API Base URL 指向该服务的兼容端点。不同的服务协议有差异，建议先阅读服务文档确认是否兼容 OpenAI 的/v1/responses或/v1/chat/completions接口。

# ~/.codex/config.toml 示例，接入兼容 OpenAPI 协议的第三方端点 model = "THIRD_PARTY_MODEL_NAME" temperature = 0.2 [api] base_url = "https://api.example.com/v1" api_key = "YOUR_THIRD_PARTY_API_KEY"

这里要特别说明：第三方端点的路径、鉴权方式和参数格式需要按实际服务调整。迁移后的 Claude Code skill 中可能包含针对 Anthropic 特有参数的内容，接入第三方端点时最好先小规模验证，避免批量任务大量报错。

7.3 模型调用的通用 API 示例

无论使用哪个端点，最终验证模型是否可用，可以直接用 curl 测试一个最小的请求。

curl -X POST "https://api.example.com/v1/responses" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "MODEL_NAME", "input": "测试迁移后的 Codex 是否可用" }'

如果使用 Python，可以这样写：

import requests url = "https://api.example.com/v1/responses" headers = { "Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/json" } payload = { "model": "MODEL_NAME", "input": "测试迁移后的 Codex 是否可用" } resp = requests.post(url, json=payload, headers=headers, timeout=120) print(resp.status_code) print(resp.json())

这个示例中的 URL、模型名和认证信息都要替换成实际值。调用成功之后，再进入 Codex 交互模式做端到端测试。

8. 接口 API 与批量任务

Codex 不只是交互式终端工具，也可以作为服务运行，供脚本或本地工具调用。这个能力在批量任务场景中很有用。

8.1 本地 API 服务模式

一些版本支持将 Codex 作为本地服务启动，监听指定端口，从终端工具变成 HTTP 接口。启动方式通常如下：

# 示例命令，实际端口和参数以版本为准 codex serve --host 127.0.0.1 --port 8080

启动成功后，本地就有了一个 HTTP 端点。接着可以用 Python 调用：

import requests endpoint = "http://127.0.0.1:8080/v1/responses" payload = { "model": "MODEL_NAME", "input": "请批量重构当前目录下的 Python 文件" } resp = requests.post(endpoint, json=payload, timeout=300) print(resp.status_code) print(resp.json())

需要注意，本地服务模式如果监听在0.0.0.0，局域网内其他设备可能也能访问，这存在安全隐患。建议只绑定127.0.0.1，并在前面加一层访问控制。

8.2 批量任务的工程化思路

批量任务不适合直接在交互终端里手动操作，更好的方式是把任务拆成独立脚本，循环调用 API。

import os import requests import time file_list = [f for f in os.listdir("./tasks") if f.endswith(".py")] for idx, filename in enumerate(file_list): filepath = os.path.join("./tasks", filename) with open(filepath, "r", encoding="utf-8") as f: content = f.read() payload = { "model": "MODEL_NAME", "input": f"请审查以下代码并输出问题列表：\n{content}", "instructions": "你是代码审查助手，输出必须是条目列表" } try: resp = requests.post(endpoint, json=payload, timeout=300) print(f"[{idx + 1}/{len(file_list)}] {filename}: {resp.status_code}") # 保存结果 with open(f"./results/{filename}.md", "w", encoding="utf-8") as out: out.write(resp.text) except Exception as e: print(f"[{idx + 1}/{len(file_list)}] {filename}: {e}") time.sleep(1)

批量任务要注意几个问题：

• 每批任务之间加延时，避免请求过快被限流。
• 为每次请求增加日志，方便事后定位失败原因。
• 任务中断后要能从断点继续，不要每次都全量重跑。
• 结果文件分目录保存，避免原文件和结果文件混在一起。

9. 资源占用与性能观察

Codex 属于云端推理的 CLI 工具，不涉及本地 GPU 推理，所以不需要关注显存，但要关注进程的 CPU、内存和网络占用。

9.1 本地资源占用观察

在 Windows 上打开任务管理器，macOS 上打开活动监视器，Linux 上使用top或htop，可以观察node或codex进程的 CPU 和内存占用。通常对话和代码生成时，本地只负责流式收发包和渲染，CPU 占用不会很高。如果出现持续高 CPU，可能是终端渲染插件或本地代理出了问题。

9.2 网络延迟的影响

模型响应速度主要取决于网络到 API 端点的延迟。可以用下面的命令测试端点连通性：

curl -o /dev/null -s -w "HTTP %{http_code} 耗时 %{time_total}s\n" "https://api.example.com/v1/models"

如果耗时过高，考虑切换网络或调整代理。如果本地配置了 local proxy 做协议转换，比如把 Anthropic 格式转成 OpenAI 格式，整个链路会多一个中转进程，此时内存占用和端口占用都要单独观察。

9.3 降低资源占用的方法

• 减少同时开启的 Codex 会话数量。
• 关闭不必要的本地代理进程。
• 清理~/.codex下过期的日志和会话缓存。
• 在 config.toml 中调整temperature和max_tokens，避免生成超长无用内容。

10. 常见问题与排查方法

下面这张表整理了迁移和启动过程中最高频的问题，基本覆盖从安装到 API 调用的失败场景。

排查顺序建议：先确认网络连通性，再确认 API key 是否正确，接着检查模型名称是否可用，最后看配置格式是否有版本差异。

11. 最佳实践与合规提醒

迁移配置这事本身不复杂，但涉及本地文件、API key 和模型调用链，需要一些工程化的约束。

11.1 迁移前做配置备份

无论使用官方迁移工具还是手动迁移，先备份全部配置。这个步骤不能省。

11.2 敏感信息脱敏

检查settings.json、.env、config.toml中是否有明文 API key、内部域名、组织 ID。有就替换成环境变量引用。

# 示例：在终端中设置环境变量 export CODEX_API_KEY="your-api-key"

11.3 全局配置与项目配置分开管理

全局配置放通用规则，项目配置放项目相关内容。不要把单个项目的技术栈信息写到全局配置里，否则换项目后 AI 行为会混乱。

11.4 涉及代码数据与版权素材必须合规

如果在代码审查、批量重构、文档生成中使用 Claude Code 或 Codex，需要确认输入数据是否有版权限制。涉及安全测试、漏洞分析、敏感文件读取时，必须严格遵守授权边界，不能对未授权系统执行命令，不能把内部敏感数据直接发送到外部模型端点。

11.5 发布或商用前做效果复核

AI 生成的代码和文档只能作为草稿，不能直接进入生产环境。批量任务尤其要注意输出质量，建议在合并到主分支前做一次完整审查。

12. 总结与下一步

这次迁移最值得尝试的点是：用 Codex 继续保留你在 Claude Code 里积累的 skills 和自定义命令，节省重新配置的时间。最先应该验证的不是 skill 是否全部迁移成功，而是模型端点是否能正常调用，因为模型调用是整个链路的入口。最容易踩的坑有三个：PATH 环境变量导致 CLI 无法启动、API key 明文泄露、第三方端点协议不兼容。

后续可以扩展的方向包括：把 Codex 接入 CI/CD 流程，让批量代码审查自动化；把 config.toml 纳入团队配置模板，统一全组 AI 行为规范；如果第三方模型端点稳定，还可以在 Codex 中切换不同模型做效果对比。

建议先在一个小项目里完成迁移测试，跑通全链路后再考虑清理旧的 Claude Code 配置。这样即使出问题，也能随时回滚。