企业官网建设流程全解析

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

先说清楚一件事：VibeCoding 这个词这两年火起来，本质上是把"写代码"从"逐行敲"变成了"跟模型对话、让它生成、你来审"。Claude Code 和 Codex 这类工具就是典型代表——你在终端里描述需求，它读你的项目文件、改代码、跑命令。爽是真爽，但问题也来了：默认情况下它们都要连公网 API，你的代码、你的业务逻辑、你的数据库结构，全都得往外面发。

对于个人玩具项目无所谓，但只要涉及公司内部系统、客户数据、还没申请专利的算法，把源码往公网模型接口上送就是给自己埋雷。所以"局域网离线 VibeCoding"这个需求就冒出来了：把模型跑在内网的一台机器上，其他开发机通过局域网访问，全程不出内网。既保留了 AI 辅助编码的效率，又把数据边界卡死在局域网里。

这套方案适合谁？三类人最需要：一是中小团队的技术负责人，想给团队统一搭一套 AI 编码环境又不想买一堆云服务；二是做企业私有化部署的工程师，客户明确要求数据不出内网；三是对数据敏感的个人开发者，比如你在做金融、医疗、政企相关的项目。哪怕你只是想省点 API 费用，本地跑模型也是个划算的选择。

我前后搭过三套这样的环境，踩过的坑能写满一页纸。下面把整套思路、选型、实操、排错都摊开讲，你照着抄基本能落地。

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

2.1 三种典型拓扑，先想清楚你要哪种

局域网离线 VibeCoding 不是只有一种搭法，核心区别在于"模型跑在哪"和"谁访问谁"。我把它归成三类：

单机自给最简单，模型和 Claude Code 装同一台机器，走 localhost，连局域网都不用配。缺点是吃硬件，一台笔记本跑 7B 模型还行，跑 30B 以上就吃力。

一拖多是团队最常用的。找一台带显卡的机器当"模型服务器"，跑推理服务，其他开发机通过局域网 IP 访问。这里的关键是推理服务要暴露成 OpenAI 兼容接口，因为 Claude Code 和 Codex 都支持自定义 base URL。

混合分流是我个人最推荐的。日常补全、简单重构用本地小模型（快、省资源），遇到复杂架构设计再切到内网大模型。Claude Code 支持通过环境变量切换端点，配合 cc switch 这类工具可以一键换模型。

2.2 为什么选 OpenAI 兼容接口作为统一标准

这是整套方案的地基。Claude Code 原生是连 Anthropic 的，Codex 原生是连 OpenAI 的，但你完全可以把它们指向任何"长得像 OpenAI"的接口。原因很简单：OpenAI 的/v1/chat/completions和/v1/responses格式已经成了事实标准，几乎所有本地推理框架都实现了它。

本地推理框架的选择上，我实测下来这几个最稳：

• LM Studio：图形界面友好，一键加载模型并开启本地服务器，适合新手。它默认监听1234端口，接口路径是/v1。
• Ollama：命令行党最爱，ollama serve之后默认监听11434，同样提供 OpenAI 兼容层。
• vLLM：生产级选择，吞吐量高，适合多人并发，但配置稍复杂，需要 Python 环境。
• llama.cpp 的 server：最轻量，CPU 也能跑，适合没有独显的场景。

选哪个取决于你的硬件和并发量。一个人用 LM Studio 或 Ollama 足够；五个人以上同时用，vLLM 的批处理优势就体现出来了。

2.3 局域网访问的核心：绑定地址与防火墙

很多人卡在"本机能用，别人连不上"。九成原因是推理服务默认只绑127.0.0.1，也就是只允许本机访问。你要把它改成绑0.0.0.0，意思是"监听所有网卡"，局域网里其他机器才能通过你的内网 IP 连过来。

以 Ollama 为例，需要设置环境变量OLLAMA_HOST=0.0.0.0:11434再启动。LM Studio 在设置里有个"Serve on Local Network"开关，打开即可。vLLM 启动时加--host 0.0.0.0。

绑好之后还有第二道关：系统防火墙。Windows 上默认会拦入站连接，你得给对应端口放行。这一步不做，前面全白搭。

3. 核心环境搭建与实操要点

3.1 模型服务器的准备与推理服务启动

先确定服务器硬件。跑 7B 量化模型（Q4 级别），8GB 显存或 16GB 内存能凑合；跑 14B 建议 12GB 以上显存；32B 级别建议 24GB 显存起步。如果只有 CPU，用 llama.cpp 跑 7B Q4，速度大概每秒几个 token，能用但谈不上流畅。

以 Ollama 为例，完整启动流程：

# Linux/macOS 设置监听所有网卡 export OLLAMA_HOST=0.0.0.0:11434 ollama serve # 另开一个终端拉取模型（以 Qwen 系列为例，中文场景友好） ollama pull qwen2.5-coder:14b

Windows 上设置环境变量用：

setx OLLAMA_HOST "0.0.0.0:11434" # 设置后需要重启终端或重启 Ollama 服务

启动后验证服务是否正常：

curl http://localhost:11434/v1/models

能返回模型列表就说明接口通了。注意 Ollama 的 OpenAI 兼容层路径是/v1，不是根路径，配客户端时别写错。

LM Studio 的话，加载模型后在左侧 "Developer" 标签页点 "Start Server"，然后在设置里勾选 "Serve on Local Network"，它会显示一个局域网地址，形如http://192.168.1.100:1234。

3.2 客户端接入 Claude Code 的关键配置

Claude Code 支持通过环境变量指定自定义端点。核心是这几个变量：

# 指向你的局域网模型服务 export ANTHROPIC_BASE_URL="http://192.168.1.100:11434/v1" export ANTHROPIC_API_KEY="dummy-key" export ANTHROPIC_MODEL="qwen2.5-coder:14b"

这里有个坑要重点说：ANTHROPIC_API_KEY本地服务通常不校验，但 Claude Code 会检查这个变量是否存在，不设会直接报错。随便填个非空字符串就行，比如local。

另一个高频报错是your organization has disabled claude subscription access for claude code。这个错误一般出现在你同时登录了官方账号又配了自定义端点，工具在鉴权逻辑上打架。解决办法是彻底清掉官方登录态，只走环境变量。检查一下~/.claude目录下的配置文件，把残留的 token 清干净。

如果你用的是 cc switch 这类多模型切换工具，注意它切换的是配置文件而不是环境变量，切换后要重启 Claude Code 进程才生效。我见过有人切完没重启，一直连的旧端点，排查半天。

3.3 Codex 接入本地模型的注意事项

Codex 的配置走的是另一套。它读取~/.codex/config.toml（或项目级配置），你需要指定 provider 和 base URL：

[model_providers.local] name = "local" base_url = "http://192.168.1.100:11434/v1" wire_api = "chat" [profiles.local] model = "qwen2.5-coder:14b" model_provider = "local"

Codex 有个容易踩的坑：它默认走responses接口（/v1/responses），而很多本地框架只实现了chat/completions。这时候会报cc switch local proxy failed while handling codex endpoint /responses之类的错。解决办法是把wire_api显式设成chat，强制它走 chat 接口。

还有个报错the 'gpt-5.6-sol' model is not supported when using codex with a...，本质是模型名对不上。Codex 内部有个默认模型名，你必须在 profile 里显式覆盖成你本地实际拉取的模型名，否则它会拿默认名去请求，本地服务找不到就报错。

3.4 局域网连通性排查清单

配完连不上，按这个顺序查，基本能定位：

1. 服务器端服务是否在跑：curl http://localhost:端口/v1/models本机先通。
2. 是否绑了 0.0.0.0：netstat -an | grep 端口（Linux）或netstat -ano | findstr 端口（Windows），看监听地址是不是0.0.0.0而不是127.0.0.1。
3. 防火墙是否放行：Windows 在"高级安全 Windows Defender 防火墙"里加一条入站规则，放行对应 TCP 端口。
4. 客户端能否 ping 通服务器：ping 192.168.1.100，不通就是网络层问题，跟服务无关。
5. 客户端能否 curl 通：在客户端机器上curl http://192.168.1.100:11434/v1/models，这一步能区分是网络问题还是客户端配置问题。
6. IP 是否冲突：用arp -a或路由器后台查一下，确认服务器 IP 没被别人占用。

提示：Windows 上如果出现"能上互联网但访问不了局域网"的情况，多半是网络配置文件被识别成了"公用网络"，防火墙策略更严。把网络改成"专用网络"再试。

4. 实操过程与关键环节实现

4.1 从零搭一套一拖多环境（完整流程）

假设你有一台带 RTX 4090 的工作站当服务器，三台开发笔记本当客户端，全部在同一个局域网段192.168.1.0/24。

第一步，服务器装 Ollama 并拉模型。装完后设置OLLAMA_HOST=0.0.0.0:11434，重启服务。拉一个 coder 专用模型，比如qwen2.5-coder:14b或deepseek-coder-v2。中文注释多的项目，Qwen 系列理解更顺。

第二步，服务器放行防火墙。Windows 上执行：

New-NetFirewallRule -DisplayName "Ollama LAN" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow

Linux 上用 ufw 的话：sudo ufw allow 11434/tcp。

第三步，记录服务器内网 IP。ipconfig（Windows）或ip addr（Linux）查出来，假设是192.168.1.100。建议在路由器里给它绑定静态 IP，否则重启后 IP 变了，所有客户端配置都得改。

第四步，客户端配置 Claude Code。每台开发机设好环境变量，指向http://192.168.1.100:11434/v1。Windows 用setx，macOS/Linux 写进~/.zshrc或~/.bashrc。

第五步，验证。在客户端跑一个简单任务，比如让 Claude Code "读一下当前目录的 README 并总结"，看它能否正常调用本地模型返回结果。

4.2 参数调优：让本地模型跑得更像样

本地模型和云端大模型差距最大的地方是"听话程度"。几个关键参数能明显改善体验：

• temperature：编码任务建议 0.1~0.3，太高会瞎编，太低会死板。默认 0.7 对代码来说偏高。
• 上下文长度：Claude Code 会塞很多文件内容进上下文，本地模型如果上下文窗口只有 8K，很容易被截断。尽量选 32K 以上的模型，或在客户端限制读取文件数量。
• top_p：配合 temperature 用，一般 0.9 左右。
• 重复惩罚：本地小模型容易复读，适当加repeat_penalty1.1 左右。

在 Ollama 里可以通过 Modelfile 固化这些参数：

FROM qwen2.5-coder:14b PARAMETER temperature 0.2 PARAMETER top_p 0.9 PARAMETER num_ctx 32768

然后ollama create my-coder -f Modelfile，客户端模型名填my-coder。

4.3 多模型切换的实操技巧

团队里不同任务需要不同模型：写业务逻辑用通用 coder 模型，写 SQL 用专门的，做文档总结用轻量模型。手动改环境变量太麻烦，我一般用两种方式：

一是写几个 shell 脚本，use-qwen.sh、use-deepseek.sh，内容就是 export 不同变量，切换时 source 一下。简单粗暴但有效。

二是用 cc switch 这类工具管理多套配置。它的原理是维护多个配置文件，切换时替换当前生效的那份。注意前面说的，切完要重启 Claude Code。

注意：切换模型后，之前对话的上下文不会自动迁移。Claude Code 的会话是绑定模型的，换模型等于开新会话。做长任务时别中途乱切。

4.4 离线环境下的依赖处理

真正的"离线"意味着服务器和客户端都不能访问公网。这会带来几个麻烦：

• 模型文件得提前下载好，用 U 盘或内网文件共享拷进去。Ollama 的模型存在~/.ollama/models，整个目录拷过去即可。
• Claude Code、Codex 的安装包也得离线装。npm 包可以提前在有网机器上npm pack打包，再离线npm install ./xxx.tgz。
• 如果客户端需要 Node.js 运行时，同样要离线安装包。

我一般会准备一个"离线资源包"，里面放好模型文件、安装包、配置模板，新机器接入时直接拷过去，十分钟搞定。

5. 常见问题与排查技巧实录

5.1 高频报错速查表

5.2 几个只有踩过才知道的坑

坑一：模型名大小写敏感。有些框架对模型名大小写敏感，Qwen2.5-Coder和qwen2.5-coder会被当成两个模型。配置时严格照ollama list输出的名字抄。

坑二：上下文超限不报错，直接截断。本地模型上下文满了之后，很多框架是静默截断而不是报错。表现是"模型好像忘了前面说的话"。排查时看服务端日志的 token 计数。

坑三：并发请求把显存打爆。多人同时用一台服务器，如果没限制并发数，显存瞬间吃满导致服务崩溃。vLLM 可以设--max-num-seqs，Ollama 可以设OLLAMA_NUM_PARALLEL。

坑四：局域网 IP 变动。DHCP 分配的 IP 会变，今天配好明天就连不上。务必给服务器绑静态 IP 或在路由器做 MAC 绑定。

坑五：Windows 防火墙的"专用/公用"网络判定。同一个网卡，插不同路由器可能被判定成不同网络类型，防火墙策略跟着变。固定用"专用网络"配置。

5.3 性能与体验的平衡经验

本地模型再强，和云端旗舰模型也有差距。我的经验是：把本地模型定位成"能干活的助手"而不是"全能专家"。简单函数、样板代码、单元测试、注释补全，本地模型完全够用；复杂架构设计、疑难 bug 定位，还是得靠更强的模型。

如果团队预算允许，可以搞"内网大模型 + 本地小模型"双层：内网部署一个 70B 级别的模型处理复杂任务，本地跑 7B 处理日常补全。Claude Code 通过切换端点来分流，兼顾效率和质量。

另外，给模型喂好上下文比换模型更有效。项目里放一个清晰的CLAUDE.md或AGENTS.md，写清楚项目结构、技术栈、编码规范，模型的表现会明显提升。这个文件相当于给模型的项目说明书，本地小模型尤其吃这一套。

6. 安全边界与运维建议

6.1 局域网不等于绝对安全

很多人觉得"在内网就安全了"，其实不然。局域网内任何一台被感染的机器都能扫描到你的模型服务端口。几个基本防护要做：

• 推理服务不要暴露到公网，只绑内网网段。
• 如果内网有访客网络，确保访客网段访问不到模型服务。
• 服务端可以加一层简单的 API Key 校验（vLLM 支持--api-key），虽然本地模型不校验也能跑，但加一层能挡住误连。
• 定期看服务日志，异常的大量请求可能是有人在扫端口。

6.2 模型与数据的隔离

模型文件本身不敏感，但你的项目代码敏感。确保 Claude Code 的工作目录限制在项目内，别让它读到系统敏感文件。Claude Code 有权限确认机制，第一次读文件会问你，别图省事全点允许。

如果做企业私有化部署，建议把模型服务、代码仓库、开发机放在同一个受控网段，和办公网做逻辑隔离。这样即使办公网出问题，开发环境也不受影响。

6.3 日常运维的几个习惯

服务器上的推理服务建议做成开机自启。Linux 用 systemd 写个 service，Windows 用任务计划程序。这样重启机器后不用手动去拉服务。

模型更新要有版本管理。新模型先在小范围试用，确认稳定再全量切换。我见过直接换模型导致整个团队编码风格突变的，回滚都来不及。

日志要留。推理服务的日志能帮你定位"为什么这次响应这么慢""为什么模型输出异常"。Ollama 的日志在~/.ollama/logs，vLLM 直接输出到终端或指定文件。

最后分享一个我自己的小习惯：给每个模型起个好记的别名，比如fast（小模型）、smart（大模型），配置里用别名，切换时只改别名指向。这样团队成员不用记一堆模型全名，沟通成本低很多。这套环境搭好之后，我们团队三个人共用一台 4090 工作站，日常编码辅助完全够用，代码一行都没出过内网。