七小时，零网络，四万英尺高空本地人工智能编码

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

七个小时的飞行，没有网络，加上对本地人工智能编码的好奇心，让我不知不觉地在机场候机室下载了13GB的人工智能模型，准备进行一场意外的离线开发实验。

这并非一项研究项目，也不是对现有解决方案的正式比较。我刚结束假期，即将踏上漫长的飞行旅程，只想打发时间。一个萦绕在我心头的疑问：如果能有一个完全本地化的编码助手，或者至少可以在我自己的基础设施上运行，而无需支付代币或订阅费用，那会是什么感觉？而且，这听起来也很有趣。

所以我决定弄清楚我们在这条路上走到哪一步了。

起飞前我匆忙拼凑的东西

我从一个基本的 Next.js 项目开始，并添加了我喜欢的依赖项：TailwindCSS、Zod、ts-pattern 等。我的目标是使用我已经非常熟悉的技术栈，这样在尝试本地 AI 时，我就不必与不熟悉的工具作斗争。

接下来，在寻找本地LLM的过程中，真正的试错开始了。我尝试了Mistral的Devstral 、 Qwen3（搭配Crush）、OpenCode和Ollama-code。经过多次失败后，最终只有gpt-oss成功运行，而且只能搭配OpenCode ^1。我并没有进行大量的研究来比较各种方案——这纯粹是我在有限的时间内能够实现的。

所以我安装了 Ollama，并下载了 gpt-oss 分区表——足足 13GB。我的电脑是 MacBook Pro M4 Pro，配备 24GB 内存，我应该事先说明一下，因为硬件要求确实非常重要。

项目本身，我特意选择了最简单的：一个用来追踪订阅用户（比如 Netflix 或健身房会员）的应用程序。基本的 CRUD 操作，没什么花哨的功能。我决定让应用依赖浏览器的本地存储来持久化数据，并指示助手在其上创建一个抽象层，以便日后可以迁移到更完善的 API 或 Supabase。

在四万英尺高空飞行七小时

在我的实验中，我采用了我在《如何将克劳德·科德变成我的最佳设计伙伴》一文中描述的方法：首先，我请助手规划功能，并根据需要进行修改。当计划完善后，我请他将其整理成 Markdown 文件，并放在“计划”文件夹中。然后，我请他根据计划开始实现，并随着进度更新计划文档，使其成为一份动态文档。

• 令我惊喜的是，规划方案完全可以满足我的基本使用需求。或许对于更复杂的功能来说会更复杂一些，但就目前而言，我几乎第一次就接受了建议的方案！

• 速度带来的现实很快就让人清醒：本地设置比 Claude Code ²慢了大约 4-5 倍，所以你必须要有耐心。好在飞机上有电影可以看，可以打发等待的空档。

• 真正的意外是耗电量。笔记本电脑的热量不仅让我的大腿火辣辣地疼，而且飞机上那糟糕的电源插座根本无法满足本地机型的耗电量。我不得不时不时停下来给笔记本电脑充电。想靠电池供电进行编程？想都别想。

• 最终，代码质量通常能达到 95% 的正确率，但修复剩下的 5% 却十分繁琐。各种各样的问题层出不穷：ESLint 错误、使用了any错误的类型定义，或者某些 UI 元素在迭代过程中被移除，比如按钮突然消失。在专业的项目中，为了提高效率，我会亲自修复这些问题。但在这里，我原本想完全采用 AI 辅助的方式，虽然 AI 完全有能力修复这些问题，但确实耗费了大量的时间和反复迭代。

👆 这是应用中的订阅列表。虽然不是那种我会每天都用的应用，但它确实好用 :)

在7小时的飞行途中，我花了大约3-4个小时开发这个应用（其余时间用来吃饭、小憩和看电影）。我成功搭建了一个基础应用，包含一个用于添加订阅的表单、一个显示当月订阅总额以及已过期和未来订阅的订阅列表、一个编辑按钮和一个删除订阅的功能。用户界面非常简陋，用户体验也不太好，但它能用。

更广泛的现实检验

当我开始将 OpenCode 与 gpt-oss 结合使用时，我惊喜地发现它竟然真的能用。虽然并非完美无缺，但也相当不错了。而且这一切都只在我的机器上运行！无需担心 Claude 配额或 API 密钥的使用情况。这种完全的自主性让我感到无比自由。

本地模型带来的延迟以及能耗问题，使得目前很难想象完全采用本地化方案。硬件要求确实很高——在普通开发者的笔记本电脑上，这种方案运行起来并不流畅。但我们希望随着时间的推移，性能和效率能够得到提升。

最后，我原本期望能找到更多本地AI编码方面的文档资料。我找到了一些博客文章，其中一些已经过时，但OpenCode ³、Crush ⁴以及类似工具的官方文档却非常匮乏。

接下来我想尝试的是使用 OpenAI 的 GPT-OSS 和 OpenCode，但不是在本地：而是通过 OpenAI 的 API，或者通过比我的笔记本电脑性能更强的服务器。

这究竟意味着什么

从这个实验来看，从业者最重要的收获是“如今本地 AI 编码出人意料地可行”和“现在还为时尚早，但正在接近目标”之间的一种混合体。

这实际上关乎本地化的选择权，以及希望有一天模型会更加高效，硬件会更加人工智能化，这样一切都可以在本地流畅运行，而不会消耗太多能源或损坏电池。

目前的状态对于简单的项目来说令人鼓舞，但对于严肃的专业工作而言仍处于早期阶段。权衡取舍是存在的：你需要强大的硬件，电池续航时间会很短，而且速度会比使用云端工具慢。但基础已经打好，而且比我预期的要稳固得多。

回归现实

着陆后，重新打开WiFi，回到克劳德·科德（Claude Code）——速度的差异立刻显现出来。但在离线的七个小时里，一些事情发生了变化。本地AI编码从“也许有一天”变成了“绝对可行，但有一些限制条件”。

这次度假实验意外地揭示了我们在真正实现本地化发展援助的道路上所处的位置。我们尚未抵达终点，但我们已能从这里看到希望。而有时，身处那样的地方反而是最有趣的。

这篇文章最初发表在博客Between the Prompts上。快去看看吧，订阅他们的电子报，就能第一时间阅读新文章啦😉。

1. 我按照这份指南，使用Ollama配置了带有 gpt-oss 的 OpenCode。↩ 

2. 仅代表我个人感受，很难找到一个精确的衡量标准 。↩

3. 请参阅关于使用 Ollama 设置 OpenCode 的简短章节。↩ 

4. Crush 文档的这一部分解释了如何将其与 Ollama 一起使用，但我尝试过的所有模型都出现了与工具调用相关的错误……  ↩