本地模型接入 Claude Code，新增跨平台支持

Claude Code Local 原先把本地推理绑在 Apple Silicon 和 MLX 上，如今通过拆开 API 转换层与推理引擎，在 v0.5.0 加入 Linux、Windows 支持，随后又在 v0.6.0 把语音、浏览器、远程访问等工具接进安装器。

它值得看的地方，是作者如何把一组分散项目拼成本地 AI 编程环境。不过，能安装、能调用工具，与实际编程体验够不够好，仍然是两件需要分别验证的事。

换掉中间层，为什么就能跨平台

作者在 8 月收到 issue #53：一位用户的 HP 笔记本有 32 GB RAM，却被安装器拦住。问题不在内存，而在整个服务端依赖 MLX，无法在 Windows 上运行。作者当时表示有人移植到 llama.cpp 就会推荐，9 天后仍以仅支持 Mac 关闭了问题。

到 10 月 29 日，变化发生在架构上。原来负责兼容 Anthropic API、转换工具调用的服务端与 MLX 绑定；现在这层转换不再依赖具体引擎，MLX 和 llama.cpp 共用一条代码路径。

跨平台的关键，是把协议适配与模型推理解耦。

Mac 继续使用 MLX；其他平台由安装器识别 NVIDIA、AMD 或 Vulkan GPU，也支持纯 CPU，然后下载固定版本的 llama.cpp 构建。这让作者能保留上层工具调用逻辑，只在底层选择不同推理后端。

项目当时已有超过 3,390 个 GitHub stars，但关注度只能说明有人感兴趣，不能代替兼容性验证。

模型能自动选，但速度还得自己测

安装器会按内存容量，尽量选择装得下、精度更高的视觉模型：

• 24 GB NVIDIA 显卡选择 Qwen 3.5 9B，使用完整 BF16 精度。
• 12 GB 显卡选择 Qwen 3.5 4B，同样使用完整 BF16 精度。
• 没有 GPU 时，按 RAM 容量适配 4B 或 9B 视觉模型，原文没有列出具体容量门槛。

所有候选模型都能读取图片，因此可以把截图粘进 Claude Code。这对前端排查页面问题有直接用途：模型至少能够接收界面截图，再结合代码处理任务。

但原文没有给出截图理解准确率、工具调用成功率或生成速度。支持图片输入，不足以证明它能达到云端模型的处理效果；纯 CPU 能装下模型，也不足以说明交互延迟适合连续编程。

Windows 的操作是运行一行 PowerShell，然后双击桌面的 Claude Local；Linux 则运行安装命令后，用 claude-local 启动。原文没有提供那条 PowerShell 命令，不能自行补全。

v0.6.0 把哪些工具接到了一起

v0.5.0 发布不到一小时，作者又推出 v0.6.0，把此前分散在多个仓库的工具加入安装器。

这条命令用于安装并选择全部组件：

curl -fsSL https://raw.githubusercontent.com/nicedreamzapp/claude-code-local/main/install.sh | bash -s -- --with all

注意末尾的 --with all：不传 --with，模型设置完成后会显示菜单。Windows 则是在安装命令前设置 $env:CCL_WITH = "all"，跳过菜单并安装全部组件。

菜单覆盖七项能力：NarrateClaude 提供语音输入和播报；Moonstone 把各台机器的会话放进一个窗口；browser-agent broker 让代理操作真实浏览器，每个代理使用独立标签页；claude-screen-to-phone 支持从 iPhone 操作 Claude Code；FiaOS 提供浏览器里的屏幕访问与真实终端；claude-failover 在额度耗尽时切到本地模型；Trinidad Head 是作者用 Rust 编写的终端，各窗口有独立辉光颜色。

这些工具仍由各自仓库的安装器安装，也能独立使用。组件之间开始复用资源：手机控制工具复用浏览器 broker，故障切换工具发现本地服务已启动时，会直接复用，避免再加载一个模型。各仓库也有卸载器，默认保留数据，添加 purge 标志才清理；具体标志写法没有给出。

语音部分的改动更深。NarrateClaude 从依赖 Apple 语音识别，改成用 whisper.cpp 运行完整 f16 精度的 Whisper large-v3-turbo，再用本地 Piper 语音回答。它通过自己管理的伪终端（pty）运行 claude，Windows 使用 ConPTY，因此不再依赖 Apple Terminal。作者称整个语音循环开源、离线运行，Apple 引擎仍可通过一个未注明名称的标志启用。

我的判断

我认可协议层解耦，以及组件间复用模型和浏览器资源的方向。前者降低跨平台改造成本，后者减少重复加载与重复维护，这些设计理由成立。

但这篇更接近发布说明。作者提供了版本、安装方式和组件关系，没有提供编程任务对照测试。与云端模型相比，本地方案的代码质量、长任务稳定性和工具调用可靠性都没有结论，不能替它背书。

本地推理与整套工具的访问边界，需要分别检查。

作者称代码和提示词留在机器上，也明确称语音循环离线；但套件同时包含远程终端、手机控制和真实浏览器访问。原文没有交代这些组件的鉴权与网络部署细节，不能把整套安装直接理解为所有能力都只在本机范围内运行。

能拿来做什么

• 如果你在 Linux 或 Windows 上评估本地 AI 编程，可以先只安装模型服务，用真实仓库检查代码修改、工具调用与响应速度，再决定是否增加其他组件。
• 如果主要做前端，可以用一张页面截图配合对应组件代码测试视觉能力，检查模型能否定位具体问题，而不只是在复述画面。
• 如果经常遇到额度限制，可以评估 claude-failover，并确认它复用了已运行的本地服务；切换后的任务质量仍需单独验证。
• 如果正在开发自己的 AI 工具，可以借鉴协议适配层独立于推理后端的结构，让上层工具调用逻辑更容易支持不同引擎。