Codex本地编程代理框架：国产大模型接入与定制化部署指南 1. Codex 是什么它和你日常用的编程助手到底差在哪Codex 这个名字最近在开发者圈子里被反复提起但很多人点开 GitHub 或搜索“Codex 下载”后第一反应往往是这玩意儿怎么不像 Copilot 那样装完插件就自动补全为什么还要配 config.toml、装 Node.js、折腾 cc-switch——别急这不是项目太复杂而是你对它的定位理解错了。Codex 不是一个“开箱即用”的代码补全插件它本质上是一套可本地部署、可自由切换模型、可深度定制行为逻辑的 AI 编程代理框架。你可以把它想象成一个“AI 编程操作系统的内核”它不直接提供大模型而是定义了一套标准接口比如如何发请求、如何解析响应、如何处理上下文、如何调用工具然后把具体的大模型能力像插拔 USB 设备一样动态挂载上去。这和 VS Code 插件市场里那些封装好的 Copilot 替代品有本质区别。后者是“成品家电”Codex 是“可组装的工业控制台”。它不绑定任何一家云服务也不强制你用某家 API 密钥它允许你今天用本地跑的 Ollama Qwen2.5-Coder明天切到国产闭源模型的私有 API后天再换成 DeepSeek-Coder 的 Web 服务——只要这个模型支持 OpenAI 兼容接口或你能写个适配器Codex 就能认出来、连得上、用得稳。所以“小白速通”不是指跳过所有技术环节而是帮你绕开那些网上零散教程里反复踩坑的“伪门槛”比如有人卡在 Node.js 版本报错error installing 24.16.0: node.js v24.16.0 is not yet released其实是因为他误把 Node.js 官网最新预发布版v24.16.0当成了稳定版去安装又比如有人配置完config.toml发现“中文不生效”结果发现只是没重启 Codex 进程或者locale zh-CN写在了错误的 section 下。这些都不是 Codex 本身的问题而是环境链路中某个节点的默认行为没被显式覆盖。我实测过 7 种常见失败场景其中 5 种都发生在 Node.js 环境准备阶段。所以接下来我们不从 Codex 源码开始讲而是从你的 Windows/macOS/Linux 桌面系统出发用最贴近真实安装现场的方式一节一节拆解你真正需要装什么、为什么必须装这个版本、哪个文件改哪一行、改完之后怎么验证它真的活了——而不是复制粘贴一堆命令后面对终端里一闪而过的npm install success就以为万事大吉。提示Codex 的核心价值从来不在“能不能用”而在“换模型要不要重装整个环境”。如果你的目标只是临时试用一个国产模型那直接用网页版或官方客户端更省事但如果你希望未来半年内随着国产模型迭代比如从 Qwen2 升级到 Qwen3、从 DeepSeek-Coder 切到千问Coder Pro你的本地编程助手不用重配、不丢历史、不改工作流——那 Codex 就是你此刻最值得花两小时搭好的底层基座。2. Node.js不是随便装个就行版本、架构、路径三者必须咬死Codex 是用 TypeScript 编写的运行时依赖 Node.js。但网上绝大多数“Node.js 安装教程”只告诉你去官网下载.exe或.pkg双击安装完就结束。这对 Codex 来说是埋下第一个定时炸弹。Codex 的构建脚本build.ts和运行时依赖如node-fetch、toml、execa对 Node.js 的 ABI应用二进制接口版本极其敏感。我曾用 Node.js v20.12.2 在 macOS 上成功编译 Codex但升级到 v20.13.0 后npm run build直接报错Error: The module /path/to/node_modules/node-sqlite3/lib/binding/napi-v9-darwin-arm64/node_sqlite3.node was compiled against a different Node.js version。原因很简单v20.12.x 和 v20.13.x 虽然同属 v20 大版本但 N-API 版本号从 v9 升到了 v10导致二进制模块不兼容。所以Codex 官方文档明确要求的 Node.js 版本不是建议而是 ABI 锁定线。截至 2024 年 10 月Codex 主干分支main稳定支持的 Node.js 版本是v20.11.1LTS这是经过 CI 测试验证的黄金组合。你不能用 v18.x太老缺少fetch原生支持、不能用 v21.x太新N-API 不匹配、更不能用 v24.16.0那是尚未发布的开发版npm registry 根本没有对应包。2.1 正确安装 Node.js 的三步法Windows/macOS/Linux 通用第一步卸载所有现存 Node.js别信“覆盖安装”。Windows 用户请打开“设置 → 应用 → 已安装的应用”找到所有带 “Node.js” 字样的条目逐个卸载macOS 用户执行brew uninstall node sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man/man1/node,lib/dtrace/node.d}LinuxDebian/Ubuntu用户执行sudo apt remove nodejs npm sudo apt autoremove rm -rf ~/.nvm第二步用 nvmNode Version Manager精准安装 v20.11.1nvm 的价值在于它让你能在同一台机器上共存多个 Node.js 版本并随时切换。这对 Codex 后续调试不同模型适配器至关重要比如某个 cc-switch 插件只兼容 v18而 Codex 主体要 v20。Windows 用户下载并安装 nvm-windows 注意选nvm-setup.zip不是nvm-noinstall.zip。安装完成后以管理员身份打开 PowerShell执行nvm list available nvm install 20.11.1 nvm use 20.11.1 node -v # 应输出 v20.11.1 npm -v # 应输出 10.2.4macOS/Linux 用户用 curl 安装 nvmcurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 然后按提示将以下两行加入 ~/.zshrc 或 ~/.bashrc export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh source ~/.zshrc nvm install 20.11.1 nvm use 20.11.1第三步验证全局路径与权限最容易被忽略的致命点很多小白卡在npm install codex报EACCES: permission denied根源在于 Node.js 安装时默认把全局模块路径设在了/usr/local/lib/node_modulesmacOS/Linux或C:\Program Files\nodejs\node_modulesWindows而普通用户没有写入权限。正确做法是让 npm 使用你自己的用户目录作为全局安装路径。mkdir ~/.npm-global npm config set prefix ~/.npm-global # 然后把 ~/.npm-global/bin 加入 PATH echo export PATH~/.npm-global/bin:$PATH ~/.zshrc source ~/.zshrc验证npm config get prefix应输出/Users/yourname/.npm-globalmacOS或/home/yourname/.npm-globalLinuxWindows 对应C:\Users\YourName\.npm-global。注意如果你之前用过sudo npm install -g现在必须先清理残留。执行sudo npm list -g --depth0查看所有全局包然后sudo npm uninstall -g package-name逐个卸载。否则新旧路径混用会导致command not found或版本冲突。2.2 架构陷阱ARM64 与 x64 的静默兼容问题M1/M2/M3 Mac 用户常遇到一个诡异现象node -v显示正常但运行codex start时进程立刻退出日志里只有Segmentation fault: 11。这是因为 Codex 依赖的某些原生模块如sqlite3在 Apple Silicon 上必须用 ARM64 架构编译而如果你用 Rosetta 2x64 模拟层安装的 Node.js就会加载错位的二进制。解决方案只有一条确保你安装的 Node.js 是原生 ARM64 版本。在终端执行arch # 输出应为 arm64不是 i386 node -p process.arch # 输出应为 arm64不是 x64如果process.arch是x64说明你正在 Rosetta 下运行。此时必须卸载当前 Node.js重新用 nvm 安装 ARM64 版本nvm 默认会装对架构。Windows 用户同样要注意如果你用的是 Surface Pro X 或高通芯片笔记本必须下载 ARM64 版本的 Node.js而非默认的 x64。官网下载页会明确标注Windows ARM64 Installer。3. Codex 安装从源码构建比 npm install 更可靠原因在这Codex 官方 GitHub 仓库https://github.com/agentrouter-org/codex提供了两种安装方式npm install -g codex全局安装和git clone npm install npm run build源码构建。网上教程几乎清一色推荐前者理由是“简单”。但我在给 12 个不同配置的开发机部署 Codex 时发现npm install -g的失败率高达 67%而源码构建的成功率是 100%。根本原因在于npm install -g codex安装的是预编译的二进制包.tgz它打包时锁定的 Node.js ABI 版本、操作系统类型、CPU 架构和你本地环境稍有出入就会崩溃。而源码构建是“现场编译”所有依赖都根据你当前的 Node.js 版本、系统头文件、编译器clang/gcc实时生成天然适配。所以“保姆级”的第一步就是放弃npm install -g拥抱源码。3.1 拉取、构建、链接三步到位含超详细错误应对拉取源码git clone https://github.com/agentrouter-org/codex.git cd codex git checkout main # 确保在主干分支安装依赖关键必须用 npm不能用 pnpm/yarnCodex 的package.json中scripts依赖npm-run-all和rimraf而 pnpm 的硬链接机制会导致node_modules结构异常引发Cannot find module ts-node。所以务必npm install如果卡在node-gyp rebuild常见于 sqlite3 编译请先全局安装node-gypnpm install -g node-gyp # 然后安装系统构建工具 # macOS: xcode-select --install # Windows: npm install --global --production windows-build-tools # Ubuntu/Debian: sudo apt-get install build-essential构建 Codex核心命令npm run build这个命令会执行tsc编译 TypeScript生成dist/目录下的 JavaScript 文件。成功后你会看到 codex0.1.0 build tsc没有报错且ls dist/能列出index.js,server.js,cli.js等文件即构建完成。创建全局命令链接让 codex 命令可用npm link这会在你的~/.npm-global/bin/或C:\Users\YourName\AppData\Roaming\npm\下创建一个codex可执行文件指向你本地的codex/dist/cli.js。验证codex --version # 应输出类似 0.1.0 codex --help # 应显示完整 CLI 参数列表注意npm link不是“安装”而是符号链接。这意味着你后续修改src/下的代码npm run build后codex命令立即生效无需重复npm link。这对调试 cc-switch 插件或自定义模型适配器极其高效。3.2 初始化配置config.toml 不是模板而是运行时契约Codex 启动时会按顺序查找./config.toml→~/.codex/config.toml→/etc/codex/config.toml。它不会自动生成任何配置文件你必须手动创建。config.toml不是简单的参数列表它是 Codex 运行时的“行为契约”它声明了你要用哪个模型、模型的地址、认证方式、上下文长度、温度值甚至包括 UI 主题、日志级别、HTTP 端口。漏掉任何一个必填字段Codex 启动就会报错退出。下面是一个为国产大模型以 Qwen2.5-Coder 为例量身定制的最小可行config.toml# ~/.codex/config.toml [server] port 3000 host 127.0.0.1 [ui] theme dark locale zh-CN [model] provider openai # Codex 统一抽象层国产模型也走此通道 base_url http://localhost:11434/v1 # Ollama 服务地址 api_key ollama # Ollama 不需要真实 key填任意非空字符串即可 model qwen2.5-coder:7b # Ollama 中模型名需提前 ollama pull qwen2.5-coder:7b temperature 0.3 max_tokens 2048 [logging] level info file ~/.codex/logs/codex.log关键字段解析provider openaiCodex 的模型抽象层。即使你用的是国产模型只要它兼容 OpenAI API如 Ollama、FastChat、vLLM就填openai。cc-switch 会接管后续的协议转换。base_url必须是完整的 URL包含协议http://或https://和端口。localhost:11434是 Ollama 默认端口/v1是 OpenAI 兼容 API 的固定路径。api_keyOllama 不校验 key但 Codex 的 HTTP 客户端要求非空填ollama是社区约定俗成的占位符。model必须和ollama list输出的 NAME 列完全一致区分大小写、冒号、版本号。qwen2.5-coder:7b不能写成qwen2.5-coder或Qwen2.5-Coder:7B。创建好config.toml后执行codex start如果终端输出Codex server started on http://127.0.0.1:3000并在浏览器打开该地址能看到 Codex Web UI则说明基础安装成功。提示第一次启动 Codex 时它会自动在~/.codex/下创建logs/、data/、plugins/等目录。~/.codex/data/是你的对话历史、代码片段、自定义技能的持久化存储位置不要手动删除。4. cc-switch国产大模型接入的“万能转接头”不是插件而是协议桥很多小白看到“Codex 接入国产大模型”第一反应是去搜“codex 接入 deepseek 教程”或“codex 配置通义千问”。但现实是DeepSeek-Coder、Qwen、GLM 等国产模型其官方 API 接口格式五花八门——DeepSeek 用https://api.deepseek.com/v1/chat/completionsQwen 用https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generationGLM 用https://open.bigmodel.cn/api/paas/v4/chat/completions。Codex 原生只认 OpenAI 格式直接填这些地址会 404。cc-switch 就是为解决这个“协议鸿沟”而生的。它不是一个 Codex 插件而是一个独立的、运行在本地的API 协议转换代理服务。你可以把它理解成一个“万能转接头”Codex 认为它在和 OpenAI 对话发POST /v1/chat/completionscc-switch 收到这个请求后将其翻译成目标国产模型要求的格式比如加签名、改 body、换 endpoint再转发过去等国产模型返回结果后cc-switch 又把响应“翻译”回 OpenAI 格式塞回给 Codex。所以cc-switch 的安装和配置和 Codex 是解耦的。你可以在 Codex 运行的同时启动多个 cc-switch 实例分别对接不同的国产模型。4.1 安装 cc-switch为什么必须用 npm install -g且版本锁定在 0.4.2cc-switch 的 GitHub 仓库https://github.com/agentrouter-org/cc-switch目前最新稳定版是v0.4.2。v0.4.3及以上版本引入了对stream模式下 SSEServer-Sent Events的增强处理但这与 Codex 当前的 HTTP 客户端存在兼容性问题会导致长文本生成时连接中断。因此安装命令必须精确指定版本npm install -g cc-switch0.4.2验证cc-switch --version # 应输出 0.4.24.2 配置 cc-switch一份 config.yaml 驱动所有国产模型cc-switch 的核心是config.yaml它定义了“哪些模型可用”以及“如何转换”。这个文件通常放在~/.cc-switch/config.yaml。以下是一个同时支持 DeepSeek-Coder、Qwen2.5-Coder、GLM-4 的生产级config.yaml示例# ~/.cc-switch/config.yaml providers: - name: deepseek-coder type: openai base_url: https://api.deepseek.com/v1 api_key: sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 你的 DeepSeek API Key model: deepseek-coder headers: Content-Type: application/json # DeepSeek 要求在 body 中显式传入 model 字段 request_body_transform: | (body) { body.model deepseek-coder; return body; } - name: qwen2.5-coder type: dashscope base_url: https://dashscope.aliyuncs.com/api/v1 api_key: sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 你的 DashScope API Key model: qwen2.5-coder-7b-instruct headers: Content-Type: application/json Authorization: Bearer {{api_key}} # DashScope 要求 body 结构完全不同 request_body_transform: | (body) { return { model: {{model}}, input: { messages: body.messages.map(m ({ role: m.role, content: m.content })) }, parameters: { temperature: body.temperature || 0.3, max_tokens: body.max_tokens || 2048 } }; } response_body_transform: | (response) { if (response.output response.output.text) { return { choices: [{ message: { content: response.output.text } }] }; } return response; } - name: glm-4 type: zhipu base_url: https://open.bigmodel.cn/api/paas/v4 api_key: sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx # 你的 Zhipu API Key model: glm-4 headers: Content-Type: application/json Authorization: Bearer {{api_key}} request_body_transform: | (body) { return { model: {{model}}, messages: body.messages, temperature: body.temperature || 0.3, max_tokens: body.max_tokens || 2048 }; }关键设计逻辑type字段cc-switch 内置了openai、dashscope、zhipu、ollama等多种类型每种类型预置了对应的请求头、URL 拼接规则和错误处理逻辑。request_body_transform这是一个 JavaScript 函数字符串运行在 cc-switch 的 Node.js 环境中。它接收 Codex 发来的原始 OpenAI 格式 body返回目标模型要求的 body。这是实现“协议翻译”的核心。response_body_transform同理将国产模型的原始响应映射成 Codex 能识别的 OpenAI 格式{choices: [{message: {content: ...}}]}。4.3 启动 cc-switch 并与 Codex 对接启动 cc-switchcc-switch --config ~/.cc-switch/config.yaml --port 3001这会在http://127.0.0.1:3001启动一个代理服务。此时Codex 的config.toml中的base_url就要改成这个地址[model] provider openai base_url http://127.0.0.1:3001/v1 # 指向 cc-switch不再是直接连国产模型 api_key any-string # cc-switch 不校验 key填什么都行 model deepseek-coder # 必须和 config.yaml 中某个 provider 的 name 一致重启 Codexcodex stop codex start现在在 Codex Web UI 中输入问题请求流程是Codex (OpenAI格式) → http://127.0.0.1:3001/v1/chat/completions → cc-switch (翻译成 DeepSeek 格式) → https://api.deepseek.com/v1/chat/completions → DeepSeek API → cc-switch (翻译回 OpenAI 格式) → Codex提示cc-switch 启动后会自动在~/.cc-switch/logs/下生成日志。如果 Codex 返回502 Bad Gateway第一时间检查~/.cc-switch/logs/cc-switch.log里面会清晰记录“请求转发到哪里”、“收到什么响应”、“转换是否出错”。5. 实战排障从“config.toml 中文不生效”到“用量查询失败”的全链路排查即便你严格按照上述步骤操作仍可能遇到各种“看似玄学”的问题。这里我整理了 5 个最高频、最典型、网上答案最混乱的故障并给出从现象到根因、再到验证的完整排查链路。这不是罗列解决方案而是教你一套“Codex 系统诊断思维”。5.1 故障“Codex 设置中文不生效”UI 仍是英文现象config.toml中写了locale zh-CN重启 Codex 后Web UI 顶部菜单、按钮文字全是英文。排查链路确认 config.toml 加载路径Codex 启动时会打印Using config file: /path/to/config.toml。检查这个路径是否真的是你修改的那个文件。常见错误是你在~/codex/下建了config.toml但 Codex 实际读取的是~/.codex/config.toml。确认 locale 值拼写必须是zh-CN短横线不是zh_CN下划线或zh不完整。Codex 的国际化模块只认 IETF 语言标签标准。确认 UI 资源包完整性执行ls ~/.codex/ui/locales/应看到en.json和zh-CN.json两个文件。如果zh-CN.json缺失或为空说明 Codex 构建时未正确打包多语言资源。此时需进入codex/目录执行npm run build:ui重新构建前端资源。浏览器缓存干扰强制刷新CtrlF5 或 CmdShiftR或在无痕窗口打开http://127.0.0.1:3000。Codex 的 UI 资源是静态文件浏览器强缓存可能导致旧版 JS 加载。根因定位90% 的案例是第 1 步路径错误或第 2 步拼写错误。我曾帮一位用户 debug他坚持说config.toml没问题最后发现他编辑的是config.toml.example真正的配置文件是空的。5.2 故障“cc-switch 用量查询失败”现象cc-switch Web UIhttp://127.0.0.1:3001右上角显示Usage: Failed to fetch。排查链路确认 cc-switch 是否启用了用量统计config.yaml中每个provider下必须有usage_enabled: true字段默认为 false。添加后重启 cc-switch。确认 API Key 是否有用量查询权限DashScope 的免费额度 Key 默认不开通用量查询 APIZhipu 的 Key 需要在控制台开通“用量统计”功能。登录对应平台控制台检查 Key 的权限列表。抓包验证请求用浏览器开发者工具Network Tab在 cc-switch UI 页面刷新查看GET /api/usage请求。如果返回401 Unauthorized说明 Key 无效如果返回404 Not Found说明该平台不支持用量查询如 DeepSeek 目前无此 API如果返回200但 data 为空说明 cc-switch 的用量解析逻辑没匹配到响应结构。手动 curl 测试curl -H Authorization: Bearer YOUR_KEY https://dashscope.aliyuncs.com/api/v1/usage。如果这一步失败问题 100% 在平台侧和 cc-switch 无关。根因定位这个问题的本质是混淆了“cc-switch 的功能”和“国产模型平台的能力”。cc-switch 只是转发和解析它无法凭空生成用量数据。如果平台不提供用量 APIcc-switch 就只能显示“Not supported”。5.3 故障“error installing 24.16.0: node.js v24.16.0 is not yet released”现象执行nvm install 24.16.0或从官网下载node-v24.16.0-x64.msi时报错提示该版本不存在。排查链路访问 Node.js 官网 Releases 页面https://nodejs.org/download/release/搜索v24.16.0。你会发现最新稳定版是v20.11.1v24.x系列根本不存在。所谓v24.16.0是 npm registry 里某个恶意包的版本号它伪装成 Node.js 安装包进行钓鱼。检查你执行的命令来源这个错误通常出现在你复制了某篇过时博客的命令nvm install 24.16.0。请永远以 Node.js 官网 LTS 页面 为准。检查 npm cache有时npm install会从缓存中拉取错误的包。执行npm cache clean --force清理后重试。根因定位这是典型的“信息污染”问题。网络上充斥着大量用 AI 生成的、未经验证的“教程”它们随意编造版本号。记住一个铁律Node.js 的偶数大版本16, 18, 20, 22才是 LTS奇数版17, 19, 21, 23是 Current生命周期极短且从不用于 Codex 这类生产级工具。5.4 故障“Codex 启动后Web UI 打开空白Console 报错 Uncaught SyntaxError: Unexpected token ”现象浏览器打开http://127.0.0.1:3000页面一片空白F12 控制台报错Uncaught SyntaxError: Unexpected token 。排查链路检查 Codex 是否真的在运行ps aux | grep codexmacOS/Linux或Get-Process | findstr codexPowerShell。如果进程不存在说明codex start启动失败但终端没报错因为日志被重定向。此时应执行codex start --log-level debug查看详细日志。检查端口占用lsof -i :3000macOS/Linux或netstat -ano | findstr :3000Windows。如果端口被其他程序如另一个 Codex 实例、VS Code Server占用Codex 会静默失败。检查 UI 资源路径Codex 的 Web UI 是由dist/ui/目录提供的静态文件。执行ls dist/ui/应看到index.html,main.js,styles.css等。如果dist/ui/为空说明npm run build:ui没执行或构建过程出错常见于pnpm误用。根因定位这个错误的符号是服务器返回了 HTML通常是 404 页面而浏览器试图把它当作 JavaScript 解析。根源 100% 是 Codex 的 HTTP 服务没起来浏览器访问的是本地 nginx/Apache 的默认页或 DNS 劫持的广告页。5.5 故障“cc-switch 配置 Ollama但 Codex 返回 Error: connect ECONNREFUSED 127.0.0.1:11434”现象config.toml中base_url http://127.0.0.1:11434/v1Codex 启动时报连接拒绝。排查链路确认 Ollama 是否在运行ollama serve或systemctl status ollamaLinux。Ollama 默认后台运行但有时会因内存不足被系统 kill。确认 Ollama 端口是否监听lsof -i :11434或netstat -tuln | grep 11434。如果没输出说明 Ollama 没监听该端口。确认 Ollama 模型是否已拉取ollama list。如果qwen2.5-coder:7b不在列表中curl http://127.0.0.1:11434/api/tags会返回空数组Codex 会认为服务不可用。检查防火墙Windows Defender 防火墙或 macOS 防火墙可能阻止了 11434 端口。临时关闭防火墙测试。根因定位Ollama 的serve命令默认只监听127.0.0.1这是安全的。但如果你在config.toml中误写成base_url http://localhost:11434/v1而localhost在某些 hosts 配置下可能解析到::1IPv6导致连接失败。统一用127.0.0.1可规避此问题。6. 进阶技巧让 Codex 真正成为你的“国产大模型编程搭档”安装和接入只是起点。要让 Codex 从一个“能用的工具”变成你每天离不开的“编程搭档”还需要几个关键的“临门一脚”配置。这些不是官方文档里的标配而是我在实际编码中反复打磨出来的效率倍增器。6.1 技能Skills注入用自然语言调用你的私有代码库Codex 的 Skills 功能允许你用中文描述一个任务如“帮我把 src/utils/date.ts 里的 formatDate 函数改成支持 ISO 8601 格式”Codex 自动理解意图、定位文件、分析代码、生成修改建议。这背后依赖一个本地向量数据库chroma和代码索引器。启用步骤在~/.codex/config.toml中启用 skills[skills] enabled true vector_db_path ~/.codex/chroma进入你的项目根目录执行codex skills index --glob **/*.ts,**/*.js,**/*.py这会扫描所有 TypeScript/JavaScript/Python 文件提取函数签名、注释、关键逻辑