VibeCoding 最近的声量越来越大说白了就是你用自然语言把需求砸给 Claude Code、Codex 这类终端编程代理剩下的事情交给它写代码、跑测试、改 bug。可一旦场景变成局域网离线环境事情就没那么简单了模型默认要连外网而你的代码仓库和设计文档全在内网防火墙后面。想要在内网安全地接着“Vibe”就得从工具链上做一套取舍。这篇就算是我自己在离线环境里折腾 Claude Code 和 Codex 的完整记录从架构思路到具体配置再到各种报错排查一次说透。适合三种人看一是要给研发团队搭内部 AI 编程平台的同学二是想在完全离线环境下尝鲜 VibeCoding 的个人开发者三是被各种网关、代理、模型映射问题折磨过的人。1. 局域网离线 VibeCoding 的整体设计思路1.1 为什么要专门搞“局域网离线”这件事很多人的第一反应是VibeCoding 直接连官方 API 不就行了但在实际落地时碰壁的情况远比想象中多。最常见的是三类场景第一类是数据安全要求高的企业项目。代码本身就是核心资产业务逻辑、密钥配置、内部工具链信息全都会作为上下文被塞给模型。如果模型请求直接飞到外部 API这些内容就等于被动离开了企业边界。对很多公司来说这不是技术问题是合规问题。第二类是物理隔离的网络环境。军工、电力、制造车间的研发网甚至某些金融机构的测试网从网络策略上就不允许终端直连公网。机器之间可以互通但对外访问被卡得死死的。这时候别说官方 API连一条普通的外网链路都拉不通。第三类是稳定性和成本问题。外部 API 依赖公网链路一旦出口抖动、限流开发节奏就全断了。内网网关加本地模型则可以把延迟、配额、可用率完全掌握在自己手里出了问题还能翻日志。所以“局域网离线 VibeCoding”从来不是走形式它解决的是安全合规、网络边界、服务可控三个层面的实际问题。工具还是那套工具关键是路由和模型后端的重构。1.2 核心架构CLI 工具 本地 API 网关 模型服务要想让 Claude Code 和 Codex 适应离线环境得先明白一个事实这两个工具本质上都是“客户端外壳”。它们负责接收你的指令、读取文件上下文、组织请求、把模型返回的流式结果展示在终端里真正干推理重活的是背后的模型 API。所以方案的核心思路很简单把请求地址从官方地址改成我们自己可控的地址。我推荐的三段式架构是终端内的 CLI 工具Claude Code 或 Codex负责交互和本地操作。内网 API 网关负责协议转换、鉴权、路由、日志和限流。这一层是整个链路的关键。模型服务可以是内网 GPU 服务器上部署的开源模型也可以是公司统一采购、通过内部接口开放的托管模型。为什么要单独加一层网关而不是让 CLI 直连模型服务因为 Claude Code 默认走 Anthropic 的 Messages 协议Codex 则默认走 OpenAI 的 Responses/Chat Completions 协议而本地部署的大多数开源模型只暴露 OpenAI 兼容接口。协议不一致必须有个“翻译官”。网关还能顺手做掉鉴权和审计谁在什么时间用了哪个模型、传了什么请求全部留下记录。这些是离线环境下“安全”两个字的具体落地。1.3 三种落地形态怎么选根据网络约束和业务要求不同我见过三种比较典型的落地形态形态适用场景优点缺点完全离线保密项目、无外网车间数据零外泄链路短模型能力受限于本地硬件内网网关 受控外部 API可有限出网但需要审计模型效果接近官方请求可追溯需要网络边界审批出口仍有关联风险混合模式团队内需求差异大敏感项目走本地普通项目走外部网关配置复杂需要做路由规则完全离线形态下推荐用本地部署的开源代码模型比如常见的 Qwen2.5-Coder、DeepSeek-Coder 等配合 Ollama 或 vLLM 提供服务。内网网关加受控外部 API 的形态则是“既想要效果又想要管理”把网关架在内网由它统一转发到经过审批的外部模型服务所有请求都走审计。混合模式适合大型研发组织我自己的经验是不要一上来就上混合先把完全离线那条链路跑稳再逐步扩展。2. 环境准备与工具选型2.1 工具清单动手之前先把工具认全。这套链路里我实际用到的工具有这么几类工具作用Claude CodeAnthropic 出品的终端编程代理擅长长上下文和复杂代码库操作Codex CLIOpenAI 出品的终端编程代理命令交互设计干净适合自动化脚本场景CC Switch桌面端配置切换工具能快速把 Claude Code/Codex 指向不同模型供应商one-api / LiteLLM服务端 API 网关适合团队共用支持多模型路由、令牌管理Ollama / vLLM模型推理服务前者轻量简单后者适合高并发生产私有化代码模型Qwen2.5-Coder、DeepSeek-Coder 等开源模型权重完全可控这些工具不是都要装。个人离线环境用 Ollama Claude Code/Codex 就够了团队环境再上 one-api 和 vLLM。CC Switch 解决的是“频繁切换供应商”的痛点但在纯离线场景下它的存在更多是为了方便。2.2 离线安装 Claude Code 与 Codex离线环境没有 npm registry装 CLI 是一道坎。我的办法很简单在有一台能上网的机器上把安装包准备好拷进内网再装。Claude Code 是 npm 包可以这样准备npm pack anthropic-ai/claude-code这会下载一个 tgz 文件把它通过内网文件服务器或者移动硬盘拷贝到目标机器然后执行npm install -g ./anthropic-ai-claude-code-*.tgzCodex CLI 的安装方式类似。它同样发布了 npm 包也可以用预编译二进制。npm 方式npm pack openai/codex然后在离线机器上npm install -g ./openai-codex-*.tgz如果是二进制方式直接从 GitHub Releases 下载对应平台linux-x64 或 darwin-arm64的压缩包解压到/usr/local/bin即可。企业环境建议在内部搭一个 Verdaccio 或 Nexus npm 私服把需要的包同步进去。这样不仅装 CLI 方便后续安装各种 Node 依赖也能统一走内网不用每次人工拷贝。2.3 网关工具怎么选网关是离线 VibeCoding 的“路由器”。选型标准在我看就三条协议兼容性、团队管理能力、排查问题的便利性。CC Switch 适合个人桌面端。它是个带界面的工具图形化配置 provider修改后会自动改写 Claude Code 和 Codex 的配置让请求先走本地代理端口。好处是零命令行门槛调试某个新模型时特别快。但它定位是桌面工具不适合直接部署成服务器给整个团队共享。one-api 或 new-api 适合团队。它们本质上是服务端网关自带用户系统、令牌管理、渠道管理、模型映射还支持把同一套 API 出口按规则分发到不同模型后端。团队里几十个人共用一条链路必须用它这种带审计和配额的工具。LiteLLM 适合走脚本化路线的人。它是 Python 生态里的标准网关配置用 YAML支持上百种模型供应商而且和 Prometheus、Grafana 这类监控系统能很好对接。如果你的团队已经有运维监控体系LiteLLM 会更容易嵌入。个人建议先装 CC Switch 跑通第一遍确认模型链路没有问题后再根据团队规模决定是否迁移到 one-api 或 LiteLLM。2.4 本地模型服务的选型与硬件预估离线 VibeCoding 的体验上限基本由模型服务决定。开源代码模型现在做得很不错常见的有 Qwen2.5-Coder、DeepSeek-Coder、CodeLlama 等。硬件上模型参数量和显存是强相关关系模型规模推荐显存量化后适合场景7B 级别8GB - 16GB单机个人用轻量补全14B 级别24GB - 32GB小团队能处理复杂任务32B 及以上48GB 以上团队级高并发生产链路推理服务方面Ollama 适合快速验证一条命令启动自动管理模型权重对新手极其友好。vLLM 则适合需要吞吐量和并发控制的场景多卡并行、连续批处理都是它的强项。我个人的经验是如果只有一块消费级显卡老老实实用 7B 或 14B 的量化模型体验足够应付大部分日常编码任务等确认需求真的上去了再考虑上 32B 模型和 vLLM而不要一开始就追求大参数。3. 实操把 Claude Code 和 Codex 指向局域网服务3.1 先搭好本地模型服务无论用哪个客户端模型服务必须能先跑起来。以 Ollama 为例在离线机器上准备好模型文件后ollama serve ollama run qwen2.5-coder:14b默认情况下Ollama 会监听11434端口对外提供 OpenAI 兼容接口。测试一下curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen2.5-coder:14b,messages:[{role:user,content:ping}]}能收到正常 completion 返回说明模型服务没问题。如果走 vLLM命令类似注意监听地址要换成内网 IPvllm serve Qwen/Qwen2.5-Coder-14B-Instruct \ --host 0.0.0.0 \ --port 8000这里要特别提醒host别盲目用0.0.0.0。如果机器有多个网卡你只想让内网某个网段访问应该绑定对应网卡的 IP而不是全部暴露。安全边界要从服务监听这一层就开始收。3.2 配置 Claude Code 使用内网 APIClaude Code 原生支持通过环境变量覆盖 API 地址。最直接的配置方式是export ANTHROPIC_BASE_URLhttp://localhost:8080 export ANTHROPIC_AUTH_TOKENyour-internal-token claude这里的http://localhost:8080应该是网关的地址。如果网关本身实现了 Anthropic 的 Messages 协议转换那 Claude Code 不需要关心后端是什么模型。在网关不提供协议转换的情况下也可以用 Claude Code 的参数直接指定模型claude --model qwen2.5-coder:14b建议把环境变量写进 shell 的 profile 文件否则每次开终端都要重新导出。团队统一使用的话可以让网关分配一个公共 token并把 BASE_URL 写成内网域名例如http://ai-gateway.internal:8080。配置完一定要验证在 Claude Code 里随便问一句“用一句话解释这个项目的目录结构”如果返回正常链路就已经通了。如果卡在请求阶段优先看网关日志而不是反复改客户端配置。3.3 配置 Codex CLI 使用内网 APICodex CLI 的配置在~/.codex/config.toml。以我当前的版本为例自定义 provider 的写法大概是这样model qwen2.5-coder:14b model_provider internal [model_providers.internal] name Internal Model base_url http://10.0.0.8:8000/v1 wire_api chat_completions env_key INTERNAL_API_KEY然后设置环境变量export INTERNAL_API_KEYyour-internal-token codex如果你也遇到 Codex 默认走 Responses API 导致网关不兼容的情况把wire_api改成chat_completions通常能解决。不同版本对这个字段的命名有细微差异要以你安装的版本官方文档为准。Codex 的好处是配置文件直观改起来不费劲。不过它加载配置的优先级是“命令行参数 环境变量 配置文件”所以如果命令行里带了别的 provider 参数配置文件会被盖掉。排查时记得先确认这一点。3.4 用 CC Switch 做本地代理和多供应商切换如果不想手动改环境变量和配置文件CC Switch 会省很多事。它的工作方式是你选择某个 provider它会自动把 Claude Code 或 Codex 的请求导向本地一个代理端口再由代理转发到你指定的模型服务。以局域网离线场景为例配置流程大概是安装 CC Switch打开后新增一个 provider。provider 的 API 地址填本地模型服务的地址比如http://localhost:11434。保存并切换CC Switch 会自动修改 Claude Code 配置让请求先走它的本地代理。回到终端启动claude或codex正常对话。需要提醒的是CC Switch 是桌面工具它的“本地代理”通常监听127.0.0.1只服务当前登录用户的会话。如果你想给团队共用老老实实上 one-api 或 LiteLLM不要试图把 CC Switch 跑在服务器上当共享网关用。3.5 离线模型权重与依赖的搬运细节模型服务最大的坑不是启动而是“模型文件怎么进去”。完全离线的机器没有任何外网下载能力所有权重都得提前准备好。我的标准操作是在一台能上网的机器上用ollama pull qwen2.5-coder:14b下载模型。然后把 Ollama 的模型目录Linux 下通常是~/.ollama/models整个打包拷到离线机器上解压到相同路径。重启 Ollamaollama list能看到对应模型就说明导入成功。如果想用 HF 上下载的 safetensors 权重跑 vLLM下载后同样拷贝整个模型目录到内网。注意模型文件名和路径不要改动否则加载时会因为缺文件报错。还有一个容易忽略的点vLLM 和 Transformers 这类 Python 库有很多依赖包离线环境要用pip download提前把整个依赖树拉下来然后在离线机器上安装。这一步建议用pip download -r requirements.txt -d ./wheels批量处理不要一个个手工找。4. 常见问题与排查实录4.1 处理 “cc switch local proxy failed while handling codex endpoint /responses”这个报错在把 Codex 接到 CC Switch 时特别常见。原话大概是cc switch local proxy failed while handling codex endpoint /responses。我第一次看到也愣了一下后来发现它其实把原因说得很清楚CC Switch 的本地代理在处理 Codex 的请求时崩了而崩掉的接口路径正是/responses。Codex 的新版本默认走 OpenAI 的 Responses API路径是/responses而很多网关或代理服务实现的是传统的/chat/completions接口。代理收到/responses请求后不知道该怎么转发自然就失败了。排查步骤按优先级来在 Codex 的config.toml中把wire_api显式改成chat_completions重启 Codex。确认 CC Switch 的本地代理进程确实在运行。任务管理器或ps aux里能找到相关进程如果没起来就重新启动。检查端口占用。CC Switch 默认端口被别的程序占了也会报这个错在设置里换一个端口再试。打开 CC Switch 的日志目录看请求是否到达、被谁拒绝。日志能告诉你是协议问题还是鉴权问题。实测下来大多数情况是协议不匹配改成chat_completions就好了。如果改完还不行再看日志定位。4.2 解决 “codex auth token is unavailable”Codex 启动时如果报这个错说明它没有拿到身份凭证。默认情况下 Codex 会去找 OpenAI 的登录态但如果你接的是内网自定义 provider它自然找不到。解决办法是在 provider 配置里指定读取哪个环境变量。以我的配置为例[model_providers.internal] env_key INTERNAL_API_KEY然后在 shell 里export INTERNAL_API_KEYyour-internal-token codex也可以直接用INTERNAL_API_KEYyour-internal-token codex临时指定。不要试图把 token 硬编码在 config.toml 里一是容易泄露二是 Codex 的配置解析对敏感字段有自己的处理逻辑写错格式反而会坑自己。4.3 模型名映射问题model not supported有时候请求已经到网关却报类似the model gpt-5.6-sol is not supported when using codex的错误。这个问题的本质是Codex 内置的模型列表里没有你要用的模型名或者网关侧的模型 ID 和 Codex 配置里的名字对不上。解决思路是建立“别名映射”。在 one-api 或 LiteLLM 这类网关里可以把请求里的模型名从一个值映射到另一个值。例如Codex 配置里写model gpt-5.6-sol网关里配置一个映射规则把这个名字重定向到qwen2.5-coder:14b。这样客户端不用改网关自动处理。如果不想动网关就直接把 Codex 配置里的模型名改成网关真实存在的模型 ID通常是一了百了。4.4 局域网并发与超时问题团队同时使用的时候经常出现“第一个请求很快就回了后面所有人都在转圈”。这不是工具坏了而是模型推理服务的并发额度被打满了。Ollama 默认并发不高可以把环境变量设大一点export OLLAMA_NUM_PARALLEL4vLLM 侧则可以控制--max-num-seqs。网关侧也要设置合理的请求超时时间别让一个慢请求拖死后续所有任务。我在实践中会把网关超时设在 120 秒左右模型推理超时设在 300 秒给大上下文留出余量同时不让无响应的任务无限占资源。4.5 问题速查表现象可能原因快速处理local proxy failed代理不支持 Responses API把 Codex wire_api 改成 chat_completionsauth token unavailable未配置环境变量设置 provider 的 env_key 并导出对应变量model not supported模型名不一致在网关配置模型别名映射请求超时/排队并发额度打满调大 OLLAMA_NUM_PARALLEL 或 vLLM 并发参数端口被占用代理进程残留查看端口占用杀掉残留进程后重启5. 落地经验与效率提升5.1 VibeCoding 不是不要上下文反而更依赖上下文内网私有化部署的模型综合能力大概率不如云端旗舰模型这是硬件和模型规模的物理限制。所以用局域网离线 VibeCoding 时提升效果的关键不是换更强的模型而是把上下文喂得更准。我强烈建议在项目根目录放一个CLAUDE.mdClaude Code 约定或AGENTS.mdCodex 约定里面写清楚项目结构、构建命令、测试命令、代码风格、常见坑。这样每次对话模型都会自动加载这部分内容回答质量会提升一大截。下面是一个可以直接套用的模板# 项目说明 - 技术栈Python 3.11 / FastAPI / PostgreSQL - 启动命令uvicorn app.main:app --reload - 测试命令pytest tests/ -v - 代码规范类型标注必须完整禁止使用全局变量 - 常见坑数据库迁移必须使用 alembic不能手改表结构我试过在同一个模型下有这份文档和没这份文档生成代码的可直接使用率差距非常明显。5.2 安全红线内网服务不要裸奔离线不等于安全。模型服务、网关一旦在内网跑起来所有能访问到这个网段的设备都能请求它。如果没有任何鉴权那等于把一个能读写代码的 AI 助手暴露给了整个内网。这是我在实际部署时非常在意的事网关必须配置 token 鉴权每个成员用独立 token不要共用管理员 token。模型服务不要监听0.0.0.0只绑定需要访问的内网网段。日志要脱敏prompt 和代码片段里可能带密钥落盘前做过滤。有条件的团队在内网入口加一层自签名 TLS避免明文请求被局域网内其他设备嗅探。这些都是老生常谈但在“VibeCoding 图省事”的心态下最容易忽略。5.3 控制成本模型不是越大越好局域网离线的算力资源是有限的。很多团队上来就想部署 32B、70B 大模型结果两张卡跑起来慢如蜗牛体验反而不如一个调教好的 14B 模型。我个人的建议是先跑小模型把流程走通再评估瓶颈在哪里。如果只是补全、解释代码、写单测7B 模型完全够如果要做跨文件重构、复杂需求拆解再考虑 14B 或 32B。另外可以开启量化部署比如 GGUF 的 Q4/Q5 量化能在损失极小精度的情况下大幅降低显存占用。用 Ollama 的模型大多自带量化选合适的 tag 就行。我在内网环境里把整套链路跑通后最大的体会是VibeCoding 的价值不在于替代工程师而是把重复劳动甩给机器让人更专注在架构和取舍上。局域网离线不是退而求其次它只是换了一种更可控的方式把 AI 编程能力握在自己手里。最后提醒一句任何工具链先在小范围灰度跑再推广到团队别一上来就在生产分支上让它放手刷代码。