企业官网建设流程全解析

正想聊聊 VibeCoding 这波趋势，身边越来越多同事开始在终端里用 Claude Code、Codex 这类命令行的 AI 开发工具。工具确实好用，但一提“局域网离线”四个字，很多人第一反应就是“那还能用吗”。答案是能，而且值得认真配置好。我这段时间在完全没外网出口的企业内网里，把 Claude Code 和 Codex 都跑起来了，代码全程不出内网，请求全部落在局域网模型服务上。这篇就是我的完整落地记录，从离线安装讲到报错排查，适合内网开发者、有数据保密要求的项目组，以及想把 VibeCoding 带到隔离网络里的工程师。

1. 先搞明白 VibeCoding 是什么，以及为什么非要在局域网里跑

1.1 VibeCoding 的底层逻辑：从“写代码”到“聊代码”

VibeCoding 这个说法，核心不是某个具体工具，而是一种全新的编码姿势：你用自然语言描述需求、报错、重构意图，AI 在你授权范围内直接改代码、执行命令、跑测试，然后你把结果 review 一遍合入版本库。Claude Code 和 Codex 就是这种模式的代表性 CLI 工具，它们跑在终端里，比 IDE 插件更主动，能自主完成“读代码—定位问题—改文件—运行验证”的闭环。

我自己的感受是，它把很大一部分“搬砖”工作外包给了模型：重构一个模块、补齐单元测试、排查一个晦涩的报错，你只需要把上下文和约束说清楚，剩下的交给模型迭代。传统补全工具是“你说一句，它补一行”，VibeCoding 是“你说目标，它交出差量”。

这类工具的共同点是需要一个高质量的模型服务。默认配置下，Claude Code 会连 Anthropic 的云端接口，Codex 会连 OpenAI 的云端接口。在办公网络环境里，这套默认链路通常走不通，而且就算走得通，公司的代码片段被发送到外部服务这件事本身就有合规风险。于是“局域网离线”就不是一个可选项，而是硬约束。

1.2 离线和内网环境里到底缺什么、要补什么

先盘点一下真实痛点。第一，很多企业的研发网段根本没有外网出口，npm、GitHub、云 API 全都不可达，连装个包都得想办法；第二，代码资产是核心机密，研发过程中的临时文件、会话记录、diff 内容都不允许离开内网；第三，团队需要一个统一的模型入口，不能每个人各自连外面的服务，既不好管控也没法记账审计。

这就有点像在家里点外卖和自家开灶的区别。外卖方便，但你的口味偏好、地址、甚至菜品照片都经过了外部平台；自家开灶，只要备好食材（模型权重）、锅铲（推理服务）和菜谱（提示词工程），就能在自家厨房里做出一桌菜。局域网离线方案的本质，就是把“厨房”搬进内网。

要补的东西有四个：模型推理服务本身、一个兼容 Claude/OpenAI 接口的请求转发层、离线可用的安装源，以及一套令牌和日志管理机制。下面我把每一步怎么落地都拆开来讲清楚。

2. 离线环境先把工具装好：Node.js、Claude Code、Codex

2.1 解决 Node.js 和 npm 的离线安装与内网镜像

Claude Code 和 Codex 都是基于 Node.js 的 CLI 工具，所以第一步是准备一个干净的 Node.js 运行时。这里不建议用系统包管理器装，因为离线环境下 apt 或 yum 的源未必可用；我推荐直接下载官方 tar.xz 源码包，进内网后解压即用。

先在有网络的机器上下载 Node.js 20 LTS 的 linux-x64 tar.xz（比如 node-v20.12.2-linux-x64.tar.xz），拷进内网后执行：

sudo mkdir -p /opt/node sudo tar -xJf node-v20.12.2-linux-x64.tar.xz -C /opt/node --strip-components=1

然后把路径写进 /etc/profile.d/node.sh，让所有用户都能直接用：

export PATH=/opt/node/bin:$PATH

验证一下：

node -v npm -v

正常情况下会输出 v20.12.2 和对应的 npm 版本。如果内网有自建的 npm 镜像（比如 Verdaccio、Nexus），记得把 registry 指过去，后面装全局包会顺畅很多：

npm config set registry http://你的镜像地址/repository/npm-public/

如果没有内网镜像也别慌，可以在外网机器上用npm pack把需要安装的包打成 tgz，再拷进内网npm install -g。这个方法对任何 npm 包都通用，唯一的坑是依赖树大的包要记得把依赖也一并打全。我通常的做法是，在外面干净的目录里先完整装一次，再用npm shrinkwrap锁定依赖，之后打包带走。

2.2 安装 Claude Code 和 Codex，并确认版本可用

Node.js 就绪后，安装就简单了。Claude Code 的 npm 包名是@anthropic-ai/claude-code，Codex 的包名是@openai/codex。如果有内网镜像，直接全局安装：

npm install -g @anthropic-ai/claude-code npm install -g @openai/codex

装完验证版本：

claude --version codex --version

这里要提醒三个离线安装常见的坑。第一个是 Node 版本太低，两个工具都对 Node 版本有最低要求，至少 18，建议直接上 20。第二个是权限问题，如果在全局目录没有写权限会报 EACCES，要么用 sudo 装，要么把 npm 的全局 prefix 指到用户目录。第三个是“装完了但命令找不到”，Linux 下多半是 PATH 没包含全局 bin 目录，检查一下/opt/node/bin或者~/.npm-global/bin是否在 PATH 里。

如果内网连 npm 镜像都没有，就走离线包路线。我的操作流程是：在外网机器上npm pack @anthropic-ai/claude-code，得到 tgz 文件；如果工具依赖原生二进制（有些新版会在 postinstall 阶段下载二进制），需要格外小心，因为离线时 postinstall 会失败。这时候优先找已经编译好的 release 包，或者在有网络的同架构机器上装好之后把整个 node 全局目录打包拷进去。实测下来，同发行版同架构之间拷贝/opt/node下的 lib/node_modules 基本能跑，但偶尔会遇到 glibc 版本不一致的问题，最保险的还是目标机器上重新安装一遍。

3. 把模型请求从云端切到局域网：核心配置拆解

3.1 Claude Code 的请求地址与令牌配置绕不开环境变量

Claude Code 默认会把请求发到 Anthropic 官方 API，但它的设计比较周到，提供了两个关键环境变量来覆盖请求地址和身份验证信息：ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN。只要设置了这两个变量，所有请求都会走你指定的端点，令牌也由你说了算。

我推荐的配置方式不是写在 shell 配置文件里，而是单独写一个环境文件，比如/etc/cc-env.sh，内容是：

export ANTHROPIC_BASE_URL=http://你的局域网模型服务IP:8000/anthropic export ANTHROPIC_AUTH_TOKEN=你的内网令牌 export ANTHROPIC_MODEL=qwen2.5-coder:32b export ANTHROPIC_SYSTEM_PROMPT=你自己定制的系统提示词 export ANTHROPIC_LOG=/data/cc-logs/claude.log

然后在启动 Claude Code 之前source /etc/cc-env.sh再执行claude。之所以不写死在~/.bashrc里，是因为同一台机器有时候也要跑公共云场景，环境隔离更干净。

除了环境变量，Claude Code 也支持在~/.claude/settings.json里配置模型选项。比如我想让每次会话默认使用指定模型，就在这里写：

{ "model": "qwen2.5-coder:32b", "env": { "ANTHROPIC_AUTH_TOKEN": "你的内网令牌" } }

注意一点：如果环境变量和配置文件里的值冲突，环境变量的优先级更高。我会把不敏感的设置放在 settings.json 里方便团队统一，敏感令牌则通过环境变量注入，避免放进版本库。

3.2 Codex 的供应商与模型配置

Codex 的思路类似，但配置结构更偏向“多供应商”模式。它支持 OpenAI 兼容协议，而OPENAI_BASE_URL和OPENAI_API_KEY就是最基础的切流开关：

export OPENAI_BASE_URL=http://你的局域网模型服务IP:8000/v1 export OPENAI_API_KEY=你的内网令牌 export OPENAI_MODEL=deepseek-chat

需要注意 Codex 有两种接口形态。一种走/v1/chat/completions，兼容大多数 OpenAI 代理程序；另一种走较新的/v1/responses接口，部分局域网服务端不一定实现。如果请求时遇到“endpoint 不支持”一类的问题，优先检查是不是OPENAI_BASE_URL指到的服务端实现了对应的端点。多数情况下我会把服务端实现成同时暴露/v1/chat/completions和/v1/responses两个路径，保证两个工具都能用。

Codex 还支持在配置文件~/.codex/config.toml里声明model_providers，通过自定义供应商来绑定多个模型地址：

[model_providers.internal] name = "internal" base_url = "http://你的局域网模型服务IP:8000/v1" api_key_env_var = "OPENAI_API_KEY" wire_api = "chat"

然后在[model]段里指定供应商对应的模型：

model = "internal/deepseek-chat"

这种写法的好处是团队可以维护一份标准 config，每个人只改自己的 api_key，模型切换通过版本库更新配置即可。

3.3 一个能跑的局域网模型服务示例：Ollama + Qwen 系列

前面讲的是客户端怎么切，下面说说局域网里的模型服务端。最常见的快速方案是 Ollama，它在离线环境下的部署成本极低：单二进制、自带模型管理、默认支持 OpenAI 兼容接口。

在局域网服务器上装好 Ollama，启动前设置监听地址，让它不要只绑定回环地址：

export OLLAMA_HOST=0.0.0.0:11434 ollama serve

然后在同网段的机器上验证服务是否可达：

curl http://局域网服务器IP:11434/api/tags

能返回模型列表 JSON，说明服务通了。接下来拉取代码模型。Ollama 官方的代码模型里我常用qwen2.5-coder系列，有 7B、14B、32B 等多种规格。完全离线的网络可以通过在有外网的机器上ollama pull qwen2.5-coder:14b，然后导出模型文件，拷进内网后ollama create导入。

但 Claude Code 默认发的是 Anthropic 风格请求，Ollama 原生只提供 OpenAI 兼容接口，中间还差一个“翻译”环节。我的做法是在内网服务器上部署一个请求流转网关，比如 claude-code-router，把 Anthropic 的/v1/messages请求翻译成 OpenAI/本地模型能理解的/v1/chat/completions。配置大概长这样：

{ "provider": "ollama", "ollama": { "base_url": "http://127.0.0.1:11434", "model": "qwen2.5-coder:14b" } }

网关启动后监听 8000 端口，对外暴露/anthropic路径，Claude Code 的ANTHROPIC_BASE_URL指向它即可。Codex 更省事，直接指到 Ollama 或者网关的/v1路径就能跑。

如果内网允许访问特定的模型供应商 API（比如通过合规审批的 DeepSeek 开放接口），也可以直接把ANTHROPIC_BASE_URL指到供应商的 Anthropic 兼容端点。需要注意，供应商提供的模型名必须和客户端填写的一致，否则后面会出现“model is not supported”的报错，这一点往下看。

4. 高频报错与排查实录

4.1 “auth token is unavailable” 这类认证问题怎么破

在离线内网环境里，Codex 很容易在启动时直接报出codex auth token is unavailable。这通常意味着 CLI 找不到可用的身份令牌。默认情况下，Codex 会尝试交互式登录，登录流程需要浏览器，而内网机器既没有外网、也没有配置好的浏览器环境，自然拿不到令牌。

我的解决思路是绕开交互式登录，直接用环境变量注入令牌。启动前明确设置OPENAI_API_KEY，并确认~/.codex/auth.json不存在或至少不是过期的空文件。因为 Codex 的优先级逻辑里，本地 auth 文件往往优先于环境变量，一旦 auth.json 存在且无效，会直接遮挡环境变量配置。

实际操作时我习惯这么处理：

unset OPENAI_API_KEY # 先清理可能冲突的历史变量 export OPENAI_API_KEY='你的内网令牌' codex --version

如果还是不行，就删除本机残留的~/.codex/auth.json再试。团队里我建议统一把令牌放在环境配置文件里，通过部署脚本下发，避免每个人手动管理。另一个容易被忽略的问题是：令牌里如果带有特殊字符，记得用单引号括起来，否则 shell 会做变量展开，导致最终请求头里的令牌和预期不一致。

4.2 “model is not supported” 与“模型名对不上”的坑

我在配置 Codex 接入局域网模型时遇到过一条很典型的报错：

the 'gpt-5.6-sol' model is not supported when using codex with ...

这行报错看起来像是服务端拒绝模型，但真正原因往往是客户端用了默认的模型名，而默认模型名只在官方的模型列表里存在。你服务端跑的是 DeepSeek 或 Qwen，客户端填的却是 GPT 系列，那自然不匹配。

排查分三步。第一步，用 curl 直接请求模型服务，确认服务端支持的模型名列表。第二步，在配置里把model改成列表里的准确名称。第三步，检查有没有写透传模型名的格式，比如 Codex 的vendor/model格式，或者网关里的模型映射表。

Claude Code 这边的相似问题是claude启动时默认找claude-*模型，如果没有在 settings.json 或环境变量里覆盖ANTHROPIC_MODEL，就会请求一个局域网服务根本不认识的模型名。这个问题在我接 Ollama 时反复出现，最后统一在网关层做了模型名映射：无论客户端传什么名字，网关都把它替换成后端实际存在的模型。这样做的好处是团队成员的客户端配置可以完全统一，服务端升级模型时只需改网关映射。

4.3 本地转发服务连接异常的问题

很多人在配置局域网环境时遇到过类似cc switch local proxy failed while handling codex endpoint这样的报错。我先说明一下，这行错误信息是提示“本地转发服务在处理 Codex 请求时连接失败”，而不是说你不能这么用。它的本质是：客户端把请求交给了本机或局域网内的某个转发进程，但那个进程没有正常响应。

我排查这类问题固定按三步走。第一，确认转发进程真的在监听端口。用ss -lntp | grep 8000看端口是否 LISTEN，很多时候是服务没启动、或者启动后崩了。第二，用 curl 测端点是否可通，比如curl http://127.0.0.1:8000/v1/models，如果 curl 都超时，说明问题出在服务本身而不是客户端配置。第三，检查证书策略。如果转发服务用了自签发证书，而 CLI 默认强制校验 TLS，就会在握手阶段失败，表现为“连接失败”或“证书错误”。我自己的处理是给转发服务配置内部受信任的证书，或者让客户端明确跳过 TLS 校验。

还有一个内网特有的坑是监听地址写错。很多人把服务绑定在127.0.0.1，然后客户端配置里写的是局域网 IP，流量压根到不了服务。记住：只在本机用就写 127.0.0.1，要让同网段其他机器访问就是0.0.0.0或具体内网 IP。

4.4 一张速查表，把高频报错一次说清

我把这段时间遇到的典型问题整理成了速查表，方便大家对照处理。

这张表没有覆盖所有极端情况，但内网环境里 80% 的问题都集中在认证、模型名、网络路径这三类。我一般建议在做任何复杂配置前，先用 curl 把链路打通，再上 CLI，能少踩很多坑。

5. 局域网离线下我用下来最顺手的几步走法

5.1 我建议的落地顺序，按这个来基本不折腾

第一次搞这套东西，最容易犯的错是先把 CLI 装好、把环境变量配好，然后去连一个还没部署的模型服务，最后面对一堆报错不知道是服务的问题还是客户端的问题。所以我的建议是严格按“服务端 → 验证链路 → 客户端 → 联调”的顺序来做。

第一步，先把局域网里的模型服务跑起来，确认curl能拿到模型列表。第二步，用一条最简单的非流式请求测试模型推理，比如让模型返回一句“你好”，确认输出正常。第三步，把网关或转发层部署好，再 curl 一遍网关的端点，确认翻译后的请求能打到后端模型。第四步，才安装配置 Claude Code 和 Codex。第五步，用最小命令比如claude "print hello"验证，确认通了再放开做真实任务。

这个顺序能保证任何一步出问题，你都能明确知道瓶颈在哪一层。我团队里入职的新同事按这个顺序操作，最慢的也能在半小时内跑通。

5.2 局域网不是绝对安全，令牌和日志同样要管好

很多人觉得“没有外网”就等于“绝对安全”，这是错觉。内网也有横向渗透的风险，而且多人共享一台模型服务时，令牌如果不分权限，任何一个开发者的令牌泄露都会影响整个团队。我的做法是，模型服务用一个专用系统账号运行，不给任何交互式 shell 权限；每个团队成员分配单独的令牌，服务端做最小权限映射，不允许跨令牌访问其他目录。

日志管理同样不能忽略。Claude Code 和 Codex 都会在本地保留会话记录，里面可能包含代码片段。我在企业里会强制设置日志路径到一个统一目录，并开启定期清理任务。同时提醒团队成员不要在 AI 会话里粘贴密钥、密码等敏感信息，这条我会写进团队的约定文档里。最后，内网服务尽量绑定在专门的研发网段，不要直接暴露在办公网或访客网段，必要时用 iptables 做来源 IP 限制。

5.3 从命令行到桌面版、编辑器的扩展

CLI 跑通之后，还可以往周边扩展。VSCode 里可以通过终端面板内嵌运行 Claude Code 或 Codex，体验上接近 IDE 插件，但能力仍然是 CLI 的完整形态。桌面版（Claude Code Desktop）在有外网的环境下用得很火，但在内网环境，我更推荐直接用claude命令配合 tmux 使用，少一层壳就少一份配置复杂度。

另外，如果你们团队平时用飞书或者企业微信做协作，还可以接上 cc-connect 这类通知插件，把 AI 的长任务运行结果推送到群组里。这在跑批量代码迁移或长时重构时非常方便，任务在后台跑，结束推一条消息，不占终端。对于嵌入式场景，比如 STM32 这类项目的助手配置，也完全可以复用文中的链路，只要把代码上下文和编译工具链挂到提示词里就能用。

我个人这一圈实践下来，最大的感受是：Claude Code 和 Codex 在局域网离线环境下并非“能用不能用的区别”，而是“配置得好不好”的区别。只要模型服务有足够的能力，网关层的翻译和模型映射做得干净，体验和直连公共 API 相比并不会差太多，反而因为数据不出内网，用起来更踏实。最后补一个小技巧：给团队下发配置时，把环境变量、config 文件、首次验证命令整合成一段脚本，成员拷过去跑一次就能进入正常工作流，比一份几十页的文档高效得多。