1. 先把需求看清楚：内网安装的真正链路
内网环境安装 Claude Code 和 Superpowers，不是“下载个安装包双击下一步”能解决的。最近医院信息科的同事给了一台 Windows Server 2016 标准版服务器，要求“把 Claude Code 装好，再把 Superpowers 配上”，机器不联网，但又要用 AI 辅助写内部系统的代码。我复盘了整个安装过程中遇到的所有坑，从 Claude Code 本体、Node 运行时、Docker 镜像到 Superpowers 技能包，整理成这篇文章，给同样被困在隔离网里的开发同行一条能直接落地的路径。
先说一个容易被忽视的事实：所谓“内网安装”，其实是在解决软件供应链问题，不只是执行几条命令。整条链路可以拆成三层，每一层的获取方式完全不同。
- Claude Code 本体：本质上是一个 npm 包，需要通过 Node.js 环境安装，离线场景下可以用 tgz 包直接安装。
- 运行环境：包括 Node.js、Docker（如果计划用容器跑配套服务）。这些体积大、依赖多，是内网安装最容易翻车的一层。
- Superpowers 技能包：看起来最神秘，实际反而最简单。它本质上是一堆 Markdown 格式的技能文件，拷进指定目录就能用，不需要编译，不需要依赖安装。
建议的实施顺序是：先装好 Node.js，再装 Claude Code，然后确认能启动、能加载配置，之后处理 Docker 和镜像问题，最后安装 Superpowers。顺序颠倒会浪费大量排查时间，因为后面每一步都需要前面提供的运行环境。
1.1 所谓“内网安装”，实际要解决的是软件供应链问题
在能上网的电脑上运行npm install -g @anthropic-ai/claude-code，几秒钟就装好了。但内网服务器的困境在于：npm registry 不可达、GitHub 不可达、Anthropic API 也可能不可达。很多人在第一步就卡住，然后跑去折腾网络代理，反而把问题复杂化。
正确的做法是分层准备安装介质。npm 包可以通过npm pack打包成 tgz 文件，拷贝到内网后离线安装。Node.js 运行时则直接下载官方 MSI 安装包。Superpowers 不需要安装介质，而是把仓库整体压缩打包，内网解压即可。
我在实际执行时，习惯于在一台可联网的机器上建立一个“内网交付目录”，里面放好所有需要的文件，然后统一用移动硬盘或内网文件服务器拷贝过去。这个目录一般包含：
- node-v18.20.4-x64.msi（或当前 LTS 版本）
- claude-code-xxxx.tgz（通过 npm pack 生成）
- superpowers.zip（GitHub 仓库压缩包）
- 配套的 Docker 镜像 tar 包（如果服务器需要跑容器服务）
- 一份 README，记录每个文件的版本号和来源地址
这个准备工作一定不能省。到了内网再发现少一个依赖，来回传递文件的时间成本比什么都贵。
1.2 Windows Server 2016 的三个硬约束
如果服务器是 Windows 10/11 专业版，这篇文章一半的篇幅都不需要。但 Windows Server 2016 标准版有其特殊的限制，处理不好每一步都会卡。
第一个硬约束：没有 WSL2。WSL2 要求 Windows 10 版本 2004 及以上，Server 2016 显然不具备。这意味着 Docker Desktop 基于 WSL2 的安装路径走不通，后面会专门讲替代方案。
第二个硬约束：PowerShell 版本停留在 5.1。Server 2016 默认的 PowerShell 是 5.1，虽然可以手动升级到 7.x 版本，但很多内部自动化脚本仍然依赖系统自带的 5.1。Claude Code 安装过程中如果触发了执行策略限制，报错信息不会很友好，需要提前处理好。
第三个硬约束：默认未启用 OpenSSH Server。如果团队习惯用 IDE 的远程开发功能，或者需要通过 SSH 隧道将内网服务暴露给开发机，Server 2016 默认状态是装不了 OpenSSH 的，需要额外添加功能。这一步最好在安装 Claude Code 之前完成，因为后面配置 MCP 服务或本地模型时，远程连接能力会频繁用到。
另外还有一个容易忽略的点：Server 2016 的中文系统和英文系统的区域设置差异，会导致某些脚本里的路径分隔符和编码解析出问题。建议一开始就把项目目录放在英文路径下，比如D:\projects\hospital-system，避免中文目录名带来的权限和解析异常。
2. 离线装好 Claude Code 本体：一台联网电脑加一个 tgz 包就够
Claude Code 本体是 npm 包，官方推荐的安装命令是npm install -g @anthropic-ai/claude-code。在内网环境，这条命令必然失败，但把它拆解成“下载”和“安装”两个阶段后，事情就变得非常简单。
2.1 在能上网的机器上准备安装包
准备步骤分两步。第一步是在联网机器上确认 Node.js 版本。Claude Code 对 Node 版本有要求，推荐使用 Node 18 或 20 的 LTS 版本，太老的 Node 12、14 肯定不行，太新的奇数版本（如 21、23）也可能出现兼容性警告。用node -v确认版本后，进入第二步。
第二步是使用npm pack命令把 Claude Code 打包成离线安装文件：
npm pack @anthropic-ai/claude-code执行完成后，当前目录会生成一个类似anthropic-ai-claude-code-1.0.xx.tgz的文件，这就是内网安装需要的全部介质。注意命令不是npm install，而是npm pack，它只下载不安装，正好适合离线传递。
如果公司有内网 npm 私有仓库（如 Nexus、Verdaccio），也可以先把 tgz 上传到私有仓库中，内网服务器通过配置 registry 安装。但从实际操作来看，对于单个 npm 包，直接传递 tgz 文件比重建一套 npm 仓库成本低得多。
2.2 内网机器上的安装命令与验证
将 Node.js MSI 安装包拷入内网服务器，双击安装。注意默认安装路径会包含空格，比如C:\Program Files\nodejs，这没问题，npm 能处理。安装完成后，务必新开一个 PowerShell 窗口，因为旧窗口的环境变量不会自动刷新。
确认 Node.js 可用后，进入存放 tgz 文件的目录，执行：
npm install -g .\anthropic-ai-claude-code-1.0.xx.tgz如果公司配置了内网 npm 镜像，也可以在命令后追加--registry=http://内网镜像地址，但离线 tgz 安装通常不需要指定 registry。
安装过程会输出一堆依赖信息，看到added x packages in xs就说明成功了。验证方式：
claude --version如果提示“无法识别 claude 命令”，多半是 npm 全局 bin 目录没有加入系统 PATH。可以用npm config get prefix查看全局安装路径，如果在C:\Users\用户名\AppData\Roaming\npm，手动把这个目录加入系统环境变量 PATH，然后重新打开 PowerShell。
还有一种常见情况：安装了最新版 Claude Code，但服务器上的 Node 是 v14 或更老，运行claude --version会直接报语法错误。此时即使命令存在，也建议回去升级 Node，而不是迁就老版本。
2.3 装完先处理三个“小毛病”
第一次在内网机器上启动 Claude Code，通常会遇到三个问题，我在医院服务器上全部踩了一遍。
第一个问题是 PowerShell 执行策略拦截。如果启动claude时提示“无法加载文件，因为在此系统上禁止运行脚本”，需要以管理员身份执行：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser第二个问题是中文乱码。Claude Code 在 PowerShell 下输出中文字符时经常出现乱码，把代码输出和状态提示搅成一团。解决办法是在启动前先执行chcp 65001切换到 UTF-8 代码页，或者直接在 PowerShell 配置文件中写入这一行。如果仍然乱码，把控制台字体从“点阵字体”改为“Consolas”，能明显改善。
第三个问题是初始化登录。Claude Code 首次启动会要求登录 Anthropic 账号或配置 API Key，内网环境不可能直接访问 Anthropic 的认证页面。这是一个需要提前解决的问题：要么在可联网机器上生成 API Key 并配置到内网环境；要么用 CC Switch 之类的工具切换到其他兼容服务；要么接入内网统一的 API 网关。如果完全没外网，又不想申请出网白名单，就直接跳到后面 Ollama 本地模型的部分。
3. 内网服务器上的 Docker：安装策略要调整
很多人在内网部署 Claude Code 相关服务时，默认认为“需要 Docker”。实际上 Claude Code 本身不依赖 Docker，但 Superpowers 里的一些技能在编写和测试代码时会希望有一个干净的容器环境来验证运行结果。如果你的场景确实需要 Docker，那么 Windows Server 2016 上的安装策略必须先调整。
3.1 为什么 Server 2016 其实装不了 Docker Desktop
这是一个关键事实：Docker Desktop 官方支持列表里，明确要求 Windows 10 64 位专业版/企业版或更新版本，以及 Windows Server 2019 及以上。它默认依赖两个后端之一：Hyper-V 或 WSL2。Windows Server 2016 虽然自带 Hyper-V，但 Docker Desktop 的 Windows 容器支持方案在 2016 上兼容性非常差，而且它根本不会识别 WSL2（因为 Server 2016 不提供 WSL2 功能）。
所以在 Server 2016 上执行 Docker Desktop 安装程序，常见结局是：安装向导跑完，启动 Docker 引擎时一直转圈，最后报“Docker Desktop requires a newer Windows version”或“WSL2 installation is incomplete”。
如果必须在 Server 2016 上使用容器，有三条路线：
- 路线 A：安装 Docker EE（Docker Enterprise）for Windows Server。它针对 Windows 容器设计，能跑 Windows 容器镜像，但对 Linux 容器支持有限。
- 路线 B：在 Hyper-V 里创建一台 Linux 虚拟机，在虚拟机内安装 Docker Engine。这是我在内网环境最推荐的做法，兼容性最好，能跑几乎所有 Linux 镜像，后续维护也直观。
- 路线 C：绕过 Docker，直接安装 Python 和 Node.js 运行时，用进程方式启动 Claude Code 需要的辅助服务（如 Ollama、OpenSpec 相关工具）。对于轻量场景，完全够用，还少了一层容器调度复杂度。
考虑到目标是给 Claude Code 和 Superpowers 提供一个干净的开发执行环境，我最终选择了路线 B：建一台 Ubuntu 22.04 虚拟机，装 Docker Engine，需要哪类镜像就在虚拟机里跑。Windows Server 2016 本身只作为宿主机。
3.2 镜像搬运三件套：pull、save、load
内网服务器拉不了 Docker Hub 镜像，所以需要在一台能联网的 Linux/Windows 机器上提前拉好镜像，然后通过 docker save 导出成 tar 文件，拷入内网后用 docker load 导入。
下面是完整的操作过程。假设需要拉取ollama/ollama和python:3.11-slim两个镜像：
联网机器上执行：
docker pull ollama/ollama docker pull python:3.11-slim docker save -o images.tar ollama/ollama python:3.11-slim将images.tar拷贝到内网服务器（或 Linux 虚拟机）后执行：
docker load -i images.tar docker images看到镜像列表里出现这两条记录，就说明导入成功。
有几点经验值得分享：
- 镜像体积比你想象的大。LLM 相关镜像动辄几个 GB，拷入前先确认磁盘空间和传输媒介容量。
- 使用
docker save时尽量用-o指定输出文件，避免输出到 stdout 后又被终端编码破坏。 - 导出、导入的镜像架构要一致。内网如果是 arm64 服务器（有些新采购的机器是 ARM 架构），不要用 x86 机器上拉取的镜像。
- 如果内网机器数量多，更规范的做法是搭一台本地 Harbor 或 Registry，把镜像推到内网仓库，需要时直接从内网仓库拉取。一台服务器临时用
docker load足够，三台以上就值得搭仓库了。
3.3 如果只是给 Claude Code 提供运行环境，可以不用 Docker
这句话可能会颠覆一些人的习惯认知，但在内网环境，少一个组件就少一个故障点。Claude Code 本质上是一个命令行 Node.js 应用，执行环境只需要 Node.js 和 Python（某些技能需要调用 Python 脚本）。Superpowers 技能包同样是纯文本文件。
只有在需要跑隔离的沙箱环境（比如测试代码时不想污染宿主机）、或者跑 Ollama 这类模型服务时，Docker 的价值才体现出来。如果公司安全审计对安装的软件清单很敏感，我更建议：
- 在 Windows Server 2016 上只装 Node.js + Python 3.11 + Claude Code + Superpowers 技能文件。
- 把 Ollama 这类模型服务单独部署在一台 Linux 虚拟机上，通过局域网地址供 Claude Code 访问。
- 需要跑临时代码验证时，用
conda或python -m venv创建虚拟环境，而不是整个容器。
这样服务器上安装的第三方软件更少，安全隐患更少，审计解释起来也轻松得多。
4. Superpowers 到底装的是什么
Superpowers 是最近在 Claude Code 用户圈子里讨论很多的一个项目，很多人把它想象成一个功能复杂的插件，安装前内心充满敬畏。实际上它的机制非常简单，但设计思路非常有效。
4.1 它不是插件，是一套“结构化行动指南”
Superpowers 的核心是一系列 Markdown 文件，每个文件都描述了一个“技能”（Skill）。这些技能文件通过 Claude Code 的技能加载机制，在每次对话开始时注入到模型上下文中，引导模型按照特定流程工作。
用一个生活化的类比：普通模式下让 Claude 写代码，就像把一位厨师直接推到灶台前说“做一桌菜”，他可能直接动手，做着做着发现少了材料，又回头补救。挂上 Superpowers 之后，相当于先让厨师坐下来看一遍完整的菜单，列出食材清单，检查冰箱库存，再决定先做哪道菜、用什么锅具，最后才开火。整个过程显得“慢”了几秒，但翻车概率大大降低。
对新手来说，Superpowers 的另一个价值是它把“如何高质量地使用 Claude”这一经验性问题，从“碰运气式提问”变成了“有章法的流程”。你不需要刻意组织提示词，Claude 会沿着技能文件里的步骤主动追问。
4.2 常见技能一览
不同版本的 Superpowers 技能集略有差异，但常见的技能通常包括以下几类，我整理了一个表格方便对照：
| 技能名称 | 核心作用 | 典型使用场景 |
|---|---|---|
| Brainstorming | 需求澄清与方案头脑风暴，在动手前把模糊想法转化成可执行方案 | 接到一句“帮我做一个排班系统”这种需求时 |
| Planning | 制定多步骤执行计划，明确每步的输入输出和验证标准 | 需要实现一个完整功能模块，而不是单函数 |
| TDD | 引导先写测试、再写实现、最后重构 | 业务逻辑复杂，对正确性要求高的场景 |
| Systematic Debugging | 系统化排查 bug 的流程，先找根因再动手改 | 线上问题定位，或者测试失败后的修复 |
| Code Review | 以评审视角检查代码质量、安全性和可维护性 | 准备提交代码前让 AI 先做一轮检查 |
实际使用中，我会在一开始就告诉 Claude “使用 Superpowers 的 Planning 技能处理这个需求”，或者让它在遇到模糊输入时自行选择 Brainstorming 技能。多试几次就能建立直觉：需求明确但实现复杂，用 Planning；需求本身模糊不清，用 Brainstorming；测试失败但原因不明，用 Systematic Debugging。
4.3 我的使用体验
我在一个内部的管理系统开发任务里做了对比测试。同样一句“给现有用户表增加一个状态字段，并同步修改查询接口”，普通模式下 Claude 直接给出了 SQL 和代码，看起来很快，但遗漏了两个关键点：一是没有检查这个字段在现有索引计划中的适配性，二是没有提醒我需要同步修改数据导出逻辑。切换 Superpowers 引导后，Claude 先列出了受影响范围，包括用户表结构、查询接口、导出功能、测试用例，然后按计划逐步实施。多消耗了一次模型调用，但少了一次返工。
在内网环境下，这个优势被放得更大，因为内网通常不能频繁依赖外网 API，把需求一次做对的成本收益非常明显。
5. 离线安装 Superpowers：放对路径比复制粘贴更重要
Superpowers 的安装过程，本质上干两件事：把技能文件放到 Claude Code 能识别的位置，然后让模型在合适的时机加载它们。麻烦不在于文件复制本身，而在于搞清楚“能识别的位置”到底在哪。
5.1 技能文件的目录结构
Claude Code 的技能加载机制根据安装对象分为两个层级：
- 项目级技能目录：
<项目根目录>/.claude/skills/<技能名>/SKILL.md - 用户级技能目录：
~/.claude/skills/<技能名>/SKILL.md
Claude Desktop 的技能目录则是%APPDATA%\Claude\skills。如果你只用 Claude Code，优先处理.claude/skills即可。
每个技能是一个独立文件夹，文件夹名称就是技能触发时的名称，必须使用英文、小写、连字符分隔，比如systematic-debugging，不能是中文目录名。文件夹内必须有SKILL.md文件，这个文件是技能的入口，里面用 YAML 头部声明技能名称和描述，后面正文是具体的执行步骤和规则。
一个技能文件夹内通常还会附带一些参考文档，比如示例代码、模板、脚本等，这些通过相对路径引用，不影响加载机制。
5.2 离线拷贝操作步骤
在有外网的机器上，将 Superpowers 仓库克隆到本地。可选仓库很多，主流的是workswarm/superpowers或obra/superpowers，两者技能集合略有差异，我个人的做法是都下载下来，挑选自己需要的技能复制到统一目录中：
git clone https://github.com/workswarm/superpowers.git git clone https://github.com/obra/superpowers.git如果外网机器拉取 GitHub 也受限，可以从 Codeberg 镜像、Gitee 镜像或 release 页面下载 zip 包，效果相同。克隆完成后，将整个目录压缩成superpowers.zip，拷入内网服务器。
内网服务器上，先查看当前用户主目录：
echo $HOME如果输出是C:\Users\wangwu，那么全局技能目录就是C:\Users\wangwu\.claude\skills。如果目录不存在，先创建：
New-Item -ItemType Directory -Path "$HOME\.claude\skills" -Force然后将解压后的技能文件夹逐个拷贝到这个目录下面：
Copy-Item -Path D:\temp\superpowers\skills\* -Destination "$HOME\.claude\skills\" -Recurse注意拷贝过来的是技能集合，而不是把整个仓库目录都拷过来。技能目录下应该直接是一层层的技能文件夹。
5.3 让 Claude Code 加载技能的三种方式
文件拷对了，还需要让 Claude Code 在对话时主动看到这些技能。实际使用中有三种方式：
第一种方式（推荐）：把技能放在项目目录下的.claude/skills中，只对当前项目生效，适合团队按项目维度管理 AI 行为，不会造成跨项目的技能冲突。
第二种方式：放在用户目录下的~/.claude/skills，对当前用户的所有项目生效。适合个人全局技能库，比如调试技能、测试技能，任何项目都能用上。
第三种方式：在CLAUDE.md文件中用 markdown 链接形式引用技能文件。CLAUDE.md是 Claude Code 在进入项目时自动读取的指令文件，里面可以写项目的全局规则，也可以引用技能文件的路径。这种方式适合只想偶尔调用某个技能、又不想让它在所有对话中占用上下文的情况。
5.4 验证加载结果
安装完成后，最怕的是文件放了但模型感知不到。最简单粗暴的验证方式是在 Claude Code 对话中直接问：
你当前加载了哪些技能？请列出技能名称和用途概要。如果输出列表里包含了刚才拷贝的技能，说明加载成功。如果没有，按以下顺序排查：
- 技能文件是否放在正确的目录层级（
.claude/skills/技能名/SKILL.md，不能是.claude/skills/SKILL.md） SKILL.md是否包含有效的 YAML 头部（name和description字段不能为空）- 项目是否重新启动过（技能加载通常在会话初始化时完成）
- 文件编码是否为 UTF-8，是否存在 BOM 头
我在内网实践中遇到过一种情况：从 Windows 自带的压缩功能解压后的目录名包含只读属性，导致 Claude Code 遍历目录时跳过。解决方法是对技能目录执行attrib -r /s /d取消只读，再重启项目会话。
5.5 路径字符和编码两个易错点
Windows 环境下最隐蔽的问题是路径长度。Claude Code 技能目录如果嵌套太深，可能触发 Windows 路径长度限制。建议把技能目录放在比较浅的路径下，比如D:\skills，而不是放在一层层嵌套的项目目录里。
编码问题同样值得注意。如果在 Windows 上用记事本编辑SKILL.md并保存为 UTF-8 with BOM，某些解析器会读取失败，技能列表里能看到技能名，但技能内容为空。建议统一用 VS Code 编辑并保存为 “UTF-8”（不带 BOM）。每次拷贝完技能文件，可以用 PowerShell 执行以下命令检查：
Get-Content "$HOME\.claude\skills\specific-skill\SKILL.md" -Encoding UTF8 | Select-Object -First 5看前几行输出是否正常，YAML 头部是否完整。
6. 内网踩坑复盘：按这条路径排查最省时间
整个安装过程中，我前后踩了几类坑。把排查过程写下来，相当于给后来者一份避坑地图。这里按高频程度排列。
6.1 npm 全局安装报错
这个坑出现概率最高，报错形态也最多。常见的现象和原因对照如下：
| 报错现象 | 根本原因 | 解决方法 |
|---|---|---|
npm: 无法识别... | PATH 未包含 npm 全局目录 | 检查npm config get prefix，手动加入 PATH |
EPERM: operation not permitted | PowerShell 没有以管理员身份运行 | 管理员身份重开 PowerShell |
ETARGET或ENOTFOUND | npm 无法访问 registry | 使用本地 tgz 包安装，或配置内网 npm 镜像 |
安装成功但claude命令报语法错误 | Node 版本过老 | 升级到 Node 18 或 20 LTS |
| 安装过程卡住不动 | 杀毒软件拦截 npm 写入临时目录 | 暂时关闭实时防护，或把 npm 缓存目录加到白名单 |
在医院内网服务器上，卡住不动的情况最折磨人。排查后发现是赛门铁克终端安全软件拦截了 npm 在%APPDATA%\npm-cache目录下的写入操作。这种情况在纯内网环境很常见，因为安全软件无法连接云端升级库，往往会启用更激进的本地行为拦截策略。
6.2 连不上 API 或账号无法登录
Claude Code 安装成功后，首次运行必然要求登录。内网环境访问不了 Anthropic 的认证服务，直接执行claude会卡在“等待登录”阶段。这时候需要判断：这台内网机器到底是一点外网都没有，还是通过代理可以访问有限域名。
如果完全没有外网，只有两条路：要么申请网络白名单，允许访问api.anthropic.com和console.anthropic.com等域名；要么放弃 Claude Code 默认的云 API，改用 CC Switch 切换到 Ollama 本地模型。我在医院场景下最终选择了白名单方案，因为医院的信息科更倾向于集中管控，对每一台服务器的出网流量都要留审计记录。
如果只是暂时断了外网、后续会恢复，可以先把常用认证信息缓存在本地。Claude Code 的认证信息存在用户目录下的配置文件里，也可以手动拷贝到内网环境的相同位置，但这种方式在合规要求严格的场景下不建议使用。
6.3 乱码与对话历史
内网 Windows 服务器上 Claude Code 乱码问题的根源是编码不一致。PowerShell 默认代码页可能是 GBK，而 Claude Code 输出 UTF-8 字符时，终端无法正确解码。处理思路是：
chcp 65001 $OutputEncoding = [System.Text.Encoding]::UTF8这两条命令在每次启动时都要执行，强烈建议写入 PowerShell 启动脚本，不然每次开会话都要手工设置一遍。
对话历史的保存是内网用户的另一个痛点。Claude Code 会在本地自动保存会话记录，文件通常位于~/.claude/projects/目录下，按项目名加时间戳命名，格式是 JSONL。内网环境无法在云端查看历史会话，这些本地文件就是唯一的历史记录。建议定期归档备份，或者使用脚本将 JSONL 转为更易读的 Markdown 文件。
6.4 用量额度和成本控制
内网环境如果通过统一出口访问 Anthropic API，多台开发机共用一个出口 IP，很容易触发账号的用量限制提示。热搜词里“your limits are temporarily boosted. your weekly claude code limit is 50%”就是这种情况的典型表现。
对策有几个层面：
- 使用 API Key 而不是订阅额度，按量计费，便于内网财务审计。
- 通过 CC Switch 在多个 API Key 或兼容服务之间轮换，降低单一出口被限制的概率。
- 纯离线开发任务切换到本地 Ollama 模型，只有对代码质量要求高的任务才走云端 API。
我的经验是：对内网环境，不要指望一个方案解决所有问题，混合模式才是常态。
7. 装上之后怎么真正用起来：本地模型、OpenSpec 与一份检查单
安装只是起点。真正要让 Claude Code 和 Superpowers 在内网环境持续产生价值，还需要把运行时、模型接入和项目规范这三件事理顺。
7.1 Ollama 本地模型接入
如果最终没有申请到外网白名单，Ollama 本地模型是唯一能在纯离线环境下跑起 Claude Code 的路子。原理很简单：Claude Code 支持通过配置切换 API 端点，CC Switch 这样的工具能管理多套 Provider 配置，把 default Provider 从 Anthropic 切到 Ollama 即可。
Ollama 本身也是一个离线安装包，在医院内网服务器上部署时，建议单独安装在 Linux 虚拟机上，而不是直接装在 Windows Server 2016 上，因为模型推理对 CPU、内存和 GPU 的调度要求更高。
安装完成后，设置环境变量让 Ollama 监听在局域网地址：
export OLLAMA_HOST=0.0.0.0 ollama serve然后在 Claude Code 对应配置中把 API 地址指向http://内网VM地址:11434，选择qwen2.5-coder:14b这类代码模型。实测下来，本地模型在代码补全和简单脚本生成上够用，但与云端 Claude 相比，在复杂项目拆解和上下文理解上差距明显。所以我的建议是：把 Ollama 作为“离线兜底”，把云端 API 作为“主力输出”，两者通过 CC Switch 随时切换。
7.2 OpenSpec 项目规范
Superpowers 管的是“AI 怎么思考”，OpenSpec 管的是“AI 怎么按规范交付”。两者是互补关系。
OpenSpec 的核心思想是用规格文件（spec）描述项目的模块边界、公共接口和验收标准，Claude Code 在动手改代码前先读取这些规格，避免改 A 模块时破坏 B 模块。在内网多人协作场景，这套机制尤其有用：不同工程师对 AI 说同样的需求时，Claude Code 会去查规格文件，而不是依赖各人提问时的临时描述。
使用步骤很简单：在项目目录下创建openspec/目录，按模块编写规格文件；在CLAUDE.md中声明这些规格文件的路径和优先级；每次给 Claude 派任务时，要求它先引用相关规格再给方案。规格文件的维护本身也是一个版本化过程，Git 里能追踪每一次修改。
7.3 内网部署最小化检查单
最后分享一份我每次内网部署都会过一遍的检查单，照着走基本不会漏项：
- [ ] 确认服务器 Windows 版本和补丁级别，Server 2016 必须确认是否包含最新更新
- [ ] 确认 Node.js 已安装，版本为 18 或 20 LTS
- [ ] 确认 npm 全局 bin 目录已加入 PATH
- [ ] 确认 PowerShell 执行策略为 RemoteSigned
- [ ] 确认 Claude Code 可通过
claude --version正常输出版本号 - [ ] 确认 API 接入方式，云端 API 已申请白名单，或本地 Ollama 已启动
- [ ] 确认技能目录
.claude/skills已创建，Superpowers 技能文件已拷贝 - [ ] 确认
SKILL.md编码为 UTF-8（无 BOM） - [ ] 确认在 Claude Code 对话中能列出技能列表
- [ ] 确认 Docker（如需）已用
docker load导入提前拉好的镜像 - [ ] 确认对话历史目录可写，且定期备份
这份检查单不是摆设，每一条背后都对应一次真实的故障经历。把它保存下来，下次内网装新的开发机或备份恢复服务器时，能省下一个下午的排查时间。
