企业官网建设流程全解析

1. 为什么要在局域网里折腾离线 VibeCoding

先把概念说清楚。所谓 VibeCoding，说白了就是让 AI 帮你写代码、改代码、跑命令，你负责提需求和验收。Claude Code 和 Codex 这两套命令行工具是目前最主流的两个选择，一个擅长长上下文理解和复杂重构，一个在代码补全和快速生成上很顺手。问题在于，这两套工具默认都要连外网，把代码片段、文件路径甚至整个项目上下文发到远端服务器。对于个人玩具项目无所谓，但只要涉及公司内部代码、客户数据、还没申请专利的算法，这条路就走不通。

局域网离线方案的核心思路很简单：把模型推理放在局域网内的一台机器上，其他开发机通过内网地址调用它。这样代码不出局域网，延迟还低，带宽也稳定。我实测下来，一台带独显的机器跑量化后的开源模型，配合 LM Studio 或者 Ollama 做推理服务，再让 Claude Code 和 Codex 指向这个内网地址，整个链路是通的，而且体验比想象中好很多。

这套方案适合几类人：一是公司有代码保密要求、不允许代码出内网的开发团队；二是家里有多台机器、想统一管理模型资源的折腾党；三是网络环境不稳定、经常断外网但又想用 AI 辅助编码的独立开发者。不管你是哪种，只要有一台能跑模型的机器和几台开发机，就能搭起来。

需要提前说明的是，本文讲的都是局域网内的正常网络配置和工具使用，所有操作都在你自己的内网环境里完成，不涉及任何跨网络访问的内容。

2. 整体架构设计与方案选型

2.1 三种可选架构的取舍

局域网离线 VibeCoding 的架构，本质上就是"推理服务放哪、怎么被调用"的问题。我试过三种方案，各有适用场景。

第一种是单机自包含：模型和开发工具装在同一台机器上，Claude Code 直接调本地的 LM Studio 或 Ollama。这种最简单，零网络配置，缺点是模型跑起来吃满显存和内存，你写代码的 IDE 会卡。适合只有一台高配机器的人。

第二种是局域网推理服务器：一台机器专门跑模型推理，开放内网端口，其他机器通过内网 IP 调用。这是我最推荐的方案，资源隔离干净，多台开发机可以共享一个模型服务。缺点是首次配置稍麻烦，要处理端口、防火墙、模型加载这些问题。

第三种是混合模式：本地跑小模型做补全，局域网服务器跑大模型做复杂任务。这种最灵活但配置最复杂，适合对延迟极度敏感的场景。

我下面主要讲第二种，因为它平衡了复杂度、性能和可维护性，也是大多数团队能落地的方案。

2.2 为什么选 LM Studio 而不是纯 Ollama

热词里有人问"claude code 调用 lmstudio 的本地模型"，这个方向是对的。LM Studio 和 Ollama 都能提供 OpenAI 兼容的 API，但实际用下来，LM Studio 在几个点上更适合配合 Claude Code 和 Codex。

第一，LM Studio 的 GUI 能直观看到模型加载状态、显存占用、当前并发请求数，排查问题时不用猜。第二，它内置了 OpenAI 兼容的/v1/chat/completions和/v1/responses端点，Codex 需要的/responses接口它能直接提供，省去自己写适配层。第三，模型量化格式支持全，GGUF、MLX 都能加载，显存不够时可以灵活降级。

Ollama 的优势在命令行友好、Docker 部署方便，如果你习惯纯终端操作，它也很好。但 Codex 对/responses端点的要求比较严格，Ollama 需要额外配置才能满足，这点后面会细说。

2.3 网络拓扑与 IP 规划

局域网搭起来之前，先把 IP 规划好，不然后面改配置会疯。我的建议是给推理服务器一个固定 IP，比如192.168.1.100，开发机用 DHCP 或者固定192.168.1.101到192.168.1.120这个段。这样配置文件里写死的地址不会变。

交换机选千兆的就够，模型推理的瓶颈在 GPU 不在网络，除非你要传几十 GB 的模型文件，那万兆会舒服些。普通家用路由器做局域网交换也没问题，只要别让推理流量走外网出口就行。

注意：如果你的局域网里有多个网段，确保推理服务器和开发机在同一网段，或者路由器上配置了正确的静态路由。跨网段访问失败十有八九是路由没配好。

3. 推理服务器端的完整配置

3.1 硬件与系统准备

推理服务器的硬件决定了你能跑多大的模型。我的经验是：7B 到 14B 的量化模型，一张 12GB 显存的卡（比如 3060 12G）就能跑得比较舒服；32B 的模型建议 24GB 显存起步；70B 的模型要么多卡，要么用 CPU 加内存硬扛，速度会明显下降。

系统方面，Linux 和 Windows 都行。Linux 下驱动和 CUDA 配置更干净，Windows 下 LM Studio 的 GUI 更好用。我自己的推理服务器跑的是 Ubuntu，因为远程管理方便，SSH 进去就能操作。

内存建议至少 32GB，因为模型加载时会有额外的内存开销。硬盘用 NVMe SSD，模型文件动辄十几 GB，机械盘加载会等到怀疑人生。

3.2 LM Studio 的安装与模型加载

LM Studio 官网下载对应系统的安装包，Linux 下是 AppImage，Windows 下是 exe。安装完打开，先在设置里把"Enable Local LLM Service"打开，默认端口是1234。

模型加载这一步有几个关键参数要调：

• Context Length：这个决定模型能记住多少上下文。Claude Code 处理大项目时上下文需求很高，建议设到 32768 或更高。但注意，上下文越长显存占用越大，要平衡。
• GPU Offload：把多少层放到 GPU 上跑。显存够就全放，不够就部分放，剩下的用 CPU。LM Studio 会自动估算，但你可以手动调。
• Batch Size：影响推理吞吐，一般设 512 或 1024，显存紧张就降。

加载完成后，LM Studio 会显示一个内网可访问的地址，比如http://192.168.1.100:1234。在浏览器里访问这个地址，能看到 API 文档页面，说明服务起来了。

3.3 开放内网访问与防火墙配置

默认情况下，LM Studio 只监听127.0.0.1，局域网其他机器访问不了。要在设置里把"Serve on Local Network"打开，或者手动改监听地址为0.0.0.0。

Linux 下如果开了 ufw 或 firewalld，要放行端口：

# ufw sudo ufw allow 1234/tcp # firewalld sudo firewall-cmd --permanent --add-port=1234/tcp sudo firewall-cmd --reload

Windows 下第一次启动 LM Studio 时，系统会弹防火墙提示，选"允许专用网络访问"。如果没弹或者选错了，去"Windows Defender 防火墙"里手动加一条入站规则，放行 1234 端口。

提示：配置完后，在另一台机器上用curl http://192.168.1.100:1234/v1/models测试一下，能返回模型列表就说明通了。返回连接拒绝，先查防火墙，再查监听地址。

3.4 验证推理服务是否正常

服务起来后，用一条简单的 curl 命令验证：

curl http://192.168.1.100:1234/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "your-model-name", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50 }'

能返回正常的 JSON 响应，说明推理链路通了。如果返回 404，检查模型名对不对；返回 500，看 LM Studio 的日志，多半是显存不够或者模型加载失败。

4. 开发机端 Claude Code 的接入配置

4.1 Claude Code 的安装

Claude Code 的安装方式取决于系统。macOS 和 Linux 下用 npm 装最方便：

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

Windows 下建议用 WSL2，然后在 WSL 里按 Linux 的方式装。原生 Windows 支持也在完善，但 WSL 的兼容性更稳。

装完后运行claude --version确认安装成功。如果提示命令找不到，检查 npm 的全局 bin 目录有没有加到 PATH 里。

4.2 指向局域网推理服务

Claude Code 默认连 Anthropic 的官方服务，要让它走局域网，需要设置环境变量。核心是两个：

export ANTHROPIC_BASE_URL=http://192.168.1.100:1234 export ANTHROPIC_API_KEY=lm-studio

ANTHROPIC_BASE_URL指向你的推理服务器，ANTHROPIC_API_KEY随便填一个非空值就行，LM Studio 不校验这个。

但这里有个坑：Claude Code 用的是 Anthropic 自己的 API 格式，而 LM Studio 提供的是 OpenAI 兼容格式，两者不完全一样。直接指过去可能会报格式错误。解决办法是用一个转换代理，把 Anthropic 格式的请求转成 OpenAI 格式。社区里有现成的工具，比如claude-code-proxy这类项目，装好后配置一下转发规则就行。

代理的配置大概是这样的：

export ANTHROPIC_BASE_URL=http://127.0.0.1:8082 export ANTHROPIC_API_KEY=any

代理本身再配置成转发到http://192.168.1.100:1234。这样 Claude Code 以为自己在跟 Anthropic 说话，实际上请求被转成了 OpenAI 格式发给局域网模型。

4.3 VSCode 里的集成

热词里"vscode配置claude code"问的人很多。Claude Code 本身是命令行工具，但在 VSCode 里可以通过集成终端使用。装好 Claude Code 后，在 VSCode 里打开终端，直接运行claude就能用。

如果想更深度集成，可以装 Claude Code 的 VSCode 扩展，它提供了侧边栏对话界面。扩展的配置里同样要填ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY，指向你的局域网代理。

实测下来，VSCode 集成终端里跑 Claude Code 的体验和独立终端没区别，而且能直接看到当前项目的文件结构，提需求时更方便。

4.4 模型选择与上下文长度匹配

Claude Code 的工作方式决定了它对模型能力有要求。它会把项目文件、命令输出、对话历史都塞进上下文，所以模型至少要能处理 32K 的上下文，否则大一点的项目直接爆。

我试过几个模型：Qwen2.5-Coder 32B 在代码理解和生成上表现最好，但显存要求高；DeepSeek-Coder-V2 16B 是性价比之选，12GB 显存能跑；Llama 3.1 8B 速度快但复杂任务容易出错。

选模型时别只看参数量，要看它在代码任务上的专项表现。有些通用模型参数大但写代码不如专门的代码模型。

注意：Claude Code 有些功能依赖特定的工具调用格式，不是所有开源模型都支持得好。如果发现工具调用老是失败，换个对 function calling 支持更好的模型试试。

5. 开发机端 Codex 的接入配置

5.1 Codex 的安装与版本选择

Codex 现在有 CLI 版和桌面版。CLI 版通过 npm 安装：

npm install -g @openai/codex

桌面版去官网下载安装包。热词里"codex安装包""codex官网下载"问得多，认准官方渠道就行，别从第三方站点下，容易夹带东西。

装完后codex --version验证。Codex 的配置文件和 Claude Code 不在一起，通常在~/.codex/config.json或项目根目录的.codex目录下。

5.2 配置指向局域网模型

Codex 的配置比 Claude Code 稍微复杂一点，因为它对 API 格式的要求更严格。配置文件大概长这样：

{ "model": "your-model-name", "provider": { "type": "openai", "baseURL": "http://192.168.1.100:1234/v1", "apiKey": "lm-studio" } }

关键在baseURL要带上/v1，因为 Codex 走的是 OpenAI 的 API 规范。

热词里有个报错"cc switch local proxy failed while handling codex endpoint /responses"，这个问题的根源是 Codex 新版会调用/responses端点，而很多本地推理服务只实现了/chat/completions。LM Studio 较新版本已经支持/responses，如果你的版本不支持，要么升级 LM Studio，要么在代理层做转换，把/responses的请求映射到/chat/completions。

5.3 处理 /responses 端点兼容问题

这个问题值得单独说，因为踩坑的人太多了。Codex 的/responses端点是 OpenAI 新推的接口，和传统的/chat/completions在请求和响应格式上有差异。

如果你的推理服务不支持/responses，有三个解决路径：

第一，升级推理服务到支持该端点的版本。LM Studio 在较新版本里加了这个支持，Ollama 需要配合特定的适配层。

第二，用一个中间代理做格式转换。写一个简单的服务，接收/responses请求，转成/chat/completions发给后端，再把响应转回来。这个代理用 Python 的 FastAPI 几十行就能写出来。

第三，降级 Codex 到不调用/responses的版本。这不是长久之计，但能快速恢复可用。

我自己的做法是第一种加第二种结合：主力用支持/responses的 LM Studio，同时备一个转换代理应对其他推理后端。

5.4 Codex 接入 DeepSeek 等模型的注意事项

热词里"codex接入deepseek"也是个高频需求。DeepSeek 的模型可以通过本地部署或者兼容 API 的方式接入。本地部署的话，用 vLLM 或 LM Studio 加载 DeepSeek 的量化版本，然后按上面的方式配置 Codex 指向它。

需要注意的是，DeepSeek 系列模型的对话模板和工具调用格式有自己的特点，配置时要在推理服务端正确设置 chat template，否则模型输出会带一堆特殊标记，Codex 解析不了。

6. 常见问题排查与避坑实录

6.1 连接类问题速查

局域网方案最容易卡在连接上。我整理了一个速查表，按现象对原因：

热词里"linux用交换机组建局域网为什么显示拒绝连接"和"win10系统可以上互联网但不能访问局域网"这两个问题，前者多半是服务监听地址不对或者防火墙没放行，后者通常是 Windows 的网络配置文件被设成了"公用网络"，改成"专用网络"就能解决。

6.2 模型加载与显存问题

显存不够是最常见的硬件问题。表现是模型加载到一半报 OOM，或者加载成功但一推理就崩。

解决办法有几个层次：降低量化精度，从 Q8 降到 Q4，显存占用能减一半；减少 GPU Offload 层数，把部分层放到 CPU；缩短上下文长度；换更小的模型。

我一般先用 Q4 量化跑起来，确认功能正常后再逐步往上调精度，找到显存和质量的平衡点。

6.3 工具调用失败的处理

Claude Code 和 Codex 都依赖模型能正确输出工具调用格式。开源模型在这方面的支持参差不齐。

如果发现工具调用老是失败，先确认推理服务有没有正确设置模型的 chat template。很多模型需要特定的模板才能输出结构化的工具调用。其次，换一个对 function calling 支持更好的模型，Qwen 系列和 DeepSeek 系列在这方面做得比较好。

还有一个隐蔽的坑：有些推理服务默认不启用工具调用支持，需要在配置里显式打开。LM Studio 里要在模型加载设置里勾选相应的选项。

6.4 性能调优的几个实操心得

延迟高是局域网方案常见的抱怨。除了硬件本身，有几个调优点：

第一，确认推理走的是 GPU 不是 CPU。用nvidia-smi看推理时 GPU 利用率，如果一直是 0，说明模型全在 CPU 上跑。

第二，调整 batch size 和并发数。单用户场景下，小 batch 延迟更低；多用户共享时，适当增大 batch 提高吞吐。

第三，模型文件放在 SSD 上。首次加载慢是正常的，但如果是每次请求都慢，检查是不是模型被反复加载卸载。

第四，网络层面，确保推理流量走的是有线而不是 WiFi。WiFi 的抖动对交互式编码体验影响很大。

提示：如果多台开发机同时用一个大模型，显存会不够。可以考虑部署两个小模型实例做负载分担，或者用支持并发批处理的推理框架。

7. 多机协作与日常维护

7.1 多台开发机共享推理服务

局域网方案最大的好处就是共享。一台推理服务器可以同时服务多台开发机，每台机器上的 Claude Code 和 Codex 都指向同一个内网地址。

但要注意并发问题。LM Studio 默认可能只处理单个请求，多台机器同时发请求会排队。如果团队人多，建议用 vLLM 这类支持连续批处理的推理框架，能显著提升并发吞吐。

配置上，每台开发机只需要设置相同的ANTHROPIC_BASE_URL或 Codex 的baseURL，指向推理服务器的内网 IP。模型切换在服务器端做，开发机不用改配置。

7.2 模型更新与版本管理

模型更新时，先在服务器上加载新模型，用 curl 测试通过后，再通知开发机切换。如果推理服务支持多模型同时加载，可以新旧并存，开发机按需选择。

建议给模型文件做个版本目录，比如models/qwen2.5-coder-32b-q4-v1、models/qwen2.5-coder-32b-q4-v2，出问题能快速回滚。

7.3 日常监控与日志

推理服务器上要关注几个指标：GPU 显存占用、GPU 利用率、请求延迟、错误率。LM Studio 的 GUI 能看到前两个，后两个需要看日志或者自己加监控。

我习惯在服务器上跑一个简单的脚本，定时 curl 一下推理接口，记录响应时间，这样能提前发现性能退化。

日志方面，推理服务的日志要保留，出问题时能追溯。Claude Code 和 Codex 的日志在各自的配置目录下，排查工具调用问题时很有用。

8. 一些实际使用中的体会

搭这套东西的过程中，我最大的感受是：局域网离线 VibeCoding 的瓶颈往往不在模型能力，而在工程配置的细节上。模型选对了、服务起来了，剩下的就是耐心调各种参数和排查连接问题。

另一个体会是，不要追求一步到位。先用最简单的单机方案跑通，确认 Claude Code 和 Codex 能正常工作，再逐步拆分成局域网架构。这样出问题时容易定位是哪一层的问题。

还有一点，开源模型和官方服务的体验差距是客观存在的，尤其是在复杂推理和长上下文任务上。局域网方案的价值在于数据不出内网和可控的成本，而不是完全替代官方服务。想清楚自己的核心需求是什么，再决定投入多少精力去折腾。

最后分享一个小技巧：如果局域网里有闲置的机器，哪怕配置不高，也可以拿来跑小模型做代码补全，把大模型留给复杂任务。这种分层使用的思路，能让有限的硬件资源发挥更大价值。