企业官网建设流程全解析

1. Mac intel 上 Codex 装完却卡在登录，问题到底出在哪

如果你已经跟着前两篇把 Codex 在 Mac intel 芯片上装好了，命令行敲codex也能弹出界面，但一进去就让你登录 OpenAI 账号，或者提示Missing API key、401 Unauthorized，那这篇就是给你收尾的。我自己在一台 2019 款 Intel MacBook Pro 上折腾这套流程时，最耗时间的不是安装，而是「装完了却用不了」——因为 Codex 默认走的是 OpenAI 官方通道，而我们要做的是把它接到国内的 GLM 模型上，中间需要一个「路由层」来改写请求地址和密钥。

这里先讲清楚三个东西分别是什么，方便你对号入座。Codex 是 OpenAI 出的命令行编码助手，能读代码、改文件、跑命令，本质是个终端里的 Agent。GLM 是智谱的国产大模型，有glm-4.6、glm-4.5这类编码能力不错的型号，通过兼容 OpenAI 的接口对外提供服务。cc-switch 是一个专门给 Codex、Claude Code 这类工具做「配置切换」的小工具，它能在本地起一个转发层，把 Codex 发出的请求改写成你指定的 Base URL 和 API Key，这样你就不用去动 Codex 的源码，也不用登录 OpenAI 账号。

适合谁看：已经装好 Codex、手上有 GLM 的 apikey、想在不登录 OpenAI 的前提下把对话跑通的开发者。如果你还没装 Codex，建议先回去看第二篇 Mac intel 的安装步骤，因为这篇默认你codex --version能正常输出版本号。整篇的核心检索词就是 Codex 接入 GLM、cc-switch 配置 apikey、Mac intel 环境，下面每一步我都会给出可复制的片段，你照着改就能用。

先说结论：最终效果是你在终端敲codex，它不再要求登录，而是直接用 GLM 的 apikey 返回结果。中间的关键动作有三个——拿到可用的 apikey 和 Base URL、在 cc-switch 里新增一条 GLM 配置、打开路由总开关。听起来简单，但每一步都有坑，尤其是 Base URL 写错一个字符就会报local proxy failed，下面逐个拆。

2. 前置准备：apikey、Base URL 和 cc-switch 三件套怎么配齐

在动 cc-switch 之前，你得先有三样东西：一个能用的 apikey、一个正确的 Base URL、以及装好的 cc-switch。这三样缺一个，后面都会卡住。我见过太多人卡在第一步，拿着一个过期的 key 反复试，最后以为是 cc-switch 的问题。

先说 apikey 和 Base URL 从哪来。你可以用 TaoToken 这类聚合入口来统一管理模型访问，它的 API 地址是https://taotoken.net/api，注意这个地址后面不加任何参数，直接作为 Base URL 填进去。apikey 则在你登录后到控制台的 API Keys 页面生成，路径是https://taotoken.net/console/api-keys。生成出来的 key 一般长这样：sk-开头的一长串字符，复制的时候别带空格，也别只复制一半。这里要提醒一句，Base URL 和 apikey 必须配套，用 A 家的 key 配 B 家的地址，结果一定是 401。

然后是 cc-switch。它的作用是给 Codex 做本地路由，所以你得先确认 Codex 本身能跑。在终端执行：

codex --version

如果输出了类似codex-cli 0.x.x的版本号，说明安装没问题。接着确认 cc-switch 是否已安装。cc-switch 通常以命令行工具或菜单栏小应用的形式存在，你可以用下面的命令检查：

which cc-switch

如果没有输出，说明还没装或者不在 PATH 里。装好之后，建议先升级到最新版本，因为旧版本对 Codex 的配置字段支持不全，容易出现「配置写了但不生效」的情况。升级命令根据你的安装方式不同，如果是通过包管理器装的，直接brew upgrade cc-switch之类即可；如果是手动下载的，去项目 release 页面拿最新包覆盖。

这里有个容易被忽略的点：Mac intel 芯片和 Apple Silicon 在二进制兼容上不一样。如果你下载的是 arm64 版本的 cc-switch，在 Intel Mac 上会直接报bad CPU type in executable。所以下载时一定要选x86_64或amd64版本。我当初就是随手点了默认下载，结果跑不起来，排查了半天才发现是架构不对。确认架构可以用：

uname -m

Intel Mac 会输出x86_64，这就是你要匹配的版本。

三件套齐了之后，先别急着开路由。建议先在终端用 curl 直接测一下你的 apikey 和 Base URL 能不能通，这样能把「key 本身有问题」和「cc-switch 配置有问题」分开排查。测试命令如下：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer 你的apikey" \ -H "Content-Type: application/json" \ -d '{ "model": "glm-4.6", "messages": [{"role": "user", "content": "你好"}] }'

如果返回里有choices字段和一段回复内容，说明 key 和地址都没问题，可以进入下一步。如果返回401，那就是 key 错了或者没带上；如果返回404，多半是 Base URL 路径写错了，注意/api后面要接/v1/chat/completions。这一步过了，后面 cc-switch 的配置才有意义。

3. 在 cc-switch 里新增 GLM 配置：可复制的 JSON 与路由开关

这一步是整篇的核心，也是最容易出错的地方。cc-switch 的配置本质上是告诉它：当 Codex 发请求时，把请求转发到哪个 Base URL、用哪个 key、默认用哪个模型。配置写对了，Codex 就完全感知不到背后换成了 GLM。

先找到 cc-switch 的配置文件位置。不同版本路径略有差异，常见的是~/.cc-switch/config.json或者~/.config/cc-switch/config.json。你可以用下面的命令定位：

ls -la ~/.cc-switch/ 2>/dev/null || ls -la ~/.config/cc-switch/ 2>/dev/null

找到之后，用编辑器打开。如果你还没有配置文件，可以手动创建一个。下面是一份可以直接参考的 JSON 片段，字段名和结构以你本地 cc-switch 版本为准，但核心就是baseUrl、apiKey、model这三项：

{ "providers": [ { "name": "glm-via-taotoken", "baseUrl": "https://taotoken.net/api", "apiKey": "sk-你的apikey", "model": "glm-4.6", "wireApi": "chat" } ], "current": "glm-via-taotoken", "routeEnabled": true }

这里逐项解释一下。name是你给这条配置起的名字，随便起，但current要跟它一致，表示当前启用哪条。baseUrl填https://taotoken.net/api，注意不要在后面多加/v1，因为 cc-switch 和 Codex 会自己拼接路径，多写反而会变成/api/v1/v1/...导致 404。apiKey就是你从控制台复制的那串。model填你要用的 GLM 型号，编码场景推荐glm-4.6，如果这个型号在你的账户下不可用，换成glm-4.5也行。wireApi表示用哪种接口协议，Codex 走的是 chat 风格，填chat即可。

如果你用的是 TOML 格式的配置（部分版本支持），等价写法是这样：

[[providers]] name = "glm-via-taotoken" base_url = "https://taotoken.net/api" api_key = "sk-你的apikey" model = "glm-4.6" wire_api = "chat" current = "glm-via-taotoken" route_enabled = true

写完保存之后，回到 cc-switch 的界面或命令行，找到「路由总开关」这个选项。在图形界面里它通常在设置页，是一个 toggle；在命令行里可能是cc-switch route enable之类的命令。把它打开，然后点保存。这一步非常关键——很多人配置写对了，但路由开关没开，Codex 还是走默认通道，结果就是一直提示登录。我试过忘记开这个开关，对着配置检查了二十分钟，最后发现是开关的事。

打开路由之后，cc-switch 会在本地起一个监听端口（常见是127.0.0.1:某个端口），Codex 的请求会先到这个本地端口，再由 cc-switch 转发到https://taotoken.net/api。所以你还需要确认 Codex 的配置指向了这个本地端口。Codex 的配置文件一般在~/.codex/config.toml或类似路径，里面要有一行指向 cc-switch 的本地地址，比如：

model_provider = "cc-switch" base_url = "http://127.0.0.1:你的ccswitch端口"

端口号以 cc-switch 实际输出为准，启动时它一般会打印出来。到这里，配置链路就完整了：Codex → cc-switch 本地端口 → TaoToken → GLM。任何一环断了都会失败，所以下面验证的时候要按顺序排查。

4. 验证请求：一次真实对话确认 GLM 正常返回

配置写完，最激动人心的就是验证。别急着在 Codex 里敲复杂任务，先用最简单的一句话确认链路通不通。打开终端，直接运行：

codex "用一句话解释什么是递归"

如果一切正常，你会看到 Codex 不再要求登录，而是直接返回一段中文解释，内容来自 GLM。这时候你可以再试一个稍微复杂点的，比如让它读当前目录的文件：

codex "列出当前目录下所有 .py 文件，并说明每个文件大概是做什么的"

这一步能验证 Codex 的工具调用能力是否也走了 GLM。因为 Codex 不只是聊天，它还会调用读文件、执行命令这类工具，如果模型不支持 function calling，工具调用就会失败。GLM 的glm-4.6对这类场景支持不错，实测下来读文件、改代码都能正常触发。

如果你想更精确地确认请求确实到了 GLM，而不是被缓存或走了别的通道，可以看 cc-switch 的日志。大多数版本会在终端输出每次转发的目标地址和状态码，类似：

[cc-switch] POST https://taotoken.net/api/v1/chat/completions -> 200

看到200就说明转发成功。如果看到401，回去检查 apikey；看到404，检查 Base URL 是不是多写了路径；看到local proxy failed，说明 cc-switch 的本地端口没起来或者 Codex 没指向它。

还有一个验证技巧：故意把 model 改成一个不存在的名字，比如glm-not-exist，然后发请求。如果返回的是「模型不存在」这类错误，说明请求确实打到了 TaoToken 并被正确解析；如果返回的还是正常回复，那说明你的配置根本没生效，Codex 还在走旧通道。这个方法能快速判断配置有没有被读取。

成功之后，你可以把常用任务跑一遍，比如让它帮你重构一个小函数、写单元测试、解释一段报错。我实测下来，GLM 在中文注释和国内常见框架的代码上表现挺自然，尤其是让它解释 Python 报错，比英文模型更贴合中文开发者的表达习惯。到这一步，Mac intel 上 Codex 接 GLM 的完整链路就算跑通了。

5. 常见报错排查：401、local proxy failed、reading choices 逐个击破

即使按步骤来，也难免遇到报错。下面这几个是我和身边人踩过的坑，对照着看能省不少时间。

第一个是401 Unauthorized。这个最直接，就是 key 的问题。可能的原因有三个：key 复制时带了空格或换行、key 已经过期或被删除、key 和 Base URL 不配套。排查方法是用第 2 节里的 curl 命令直接测，如果 curl 也 401，那就是 key 本身的问题，去控制台重新生成一个。如果 curl 通了但 Codex 里 401，那说明 cc-switch 没读到你的 key，检查配置文件里的apiKey字段有没有写对，以及current指向的 provider 名字是否匹配。

第二个是local proxy failed或connection refused。这个报错说明 Codex 想连 cc-switch 的本地端口，但连不上。原因通常是 cc-switch 没启动、路由开关没开、或者端口号对不上。先确认 cc-switch 进程在跑：

ps aux | grep cc-switch

如果没有输出，说明没启动。如果有输出，看它监听的端口，然后检查 Codex 配置里的base_url端口是否一致。还有一种情况是端口被别的程序占用了，换个端口重启 cc-switch 即可。

第三个是reading choices相关的报错，比如error reading choices: unexpected end of JSON input。这个通常出现在响应体为空或者不是合法 JSON 的时候。可能的原因是 Base URL 路径写错，导致返回了一个 HTML 错误页而不是 JSON；也可能是模型名写错，服务端直接返回了错误结构。排查方法是看 cc-switch 日志里转发的完整 URL，确认是https://taotoken.net/api/v1/chat/completions这种正确路径，而不是https://taotoken.net/api/v1/v1/chat/completions。多写/v1是高频错误，我自己就犯过。

第四个是 OAuth 相关的提示，比如OAuth login required或一直跳转登录页。这说明 Codex 还在走 OpenAI 官方通道，cc-switch 的路由没生效。回去检查路由总开关是否打开、Codex 的model_provider是否指向了 cc-switch。有时候改了配置但 Codex 有缓存，重启一下终端或者删掉~/.codex下的缓存文件再试。

第五个是模型返回乱码或截断。这个多半是模型名不对或者该模型在你的账户下没有权限。换成glm-4.6或glm-4.5再试，同时确认账户余额或额度是否充足。如果返回内容里夹杂英文错误信息，把完整报错贴出来对照，一般能定位到具体字段。

排查的核心思路是「分段验证」：先用 curl 验证 key 和地址，再验证 cc-switch 本地端口，最后验证 Codex 到 cc-switch 的连接。哪一段断了就修哪一段，不要一上来就怀疑所有环节。

6. 把链路固定下来：日常使用与后续扩展

跑通之后，建议把配置固定下来，避免每次重启都要重新弄。cc-switch 的配置是持久化的，只要你保存了，下次开机它一般会自动读取。但路由开关有时候不会自动恢复，所以每次重启后可以先确认一下开关状态。如果嫌麻烦，可以把启动 cc-switch 并开启路由的命令写成一个 shell 脚本，放到~/.zshrc里，登录时自动执行。

日常使用上，Codex 接 GLM 之后能干的事不少：读项目代码、生成单元测试、解释报错、重构函数、写提交信息。你可以把它当成一个懂中文的终端助手。如果任务比较重、需要长时间跑 Agent，可以考虑用 Coding Plan 这类方案来管理额度，入口在https://taotoken.net/coding-plan。如果只是想验证某个模型效果，直接到模型对话页面试就行，地址是https://taotoken.net/chat。需要生成或管理 key 的时候，回到https://taotoken.net/console/api-keys。

后续如果你想换模型，比如从glm-4.6换成别的，只需要改 cc-switch 配置里的model字段，保存后重启 Codex 即可，不用重装任何东西。这也是用 cc-switch 做路由的好处——模型和工具解耦，切换成本很低。Mac intel 机器虽然性能不如新芯片，但跑 Codex 这种命令行工具完全够用，关键是把链路配通。到这一步，你的 Codex 应该已经能稳定用 GLM 返回结果了，剩下的就是拿它去解决实际的编码问题。