喜马拉雅山麓的离线开发挑战
作者一年前搬至喜马拉雅山脉的山脚,虽然享受那里的宁静,但也面临着网络与电力不稳定的现实挑战。作为一名在汤森路透担任首席工程师的专业开发者,代码编写与审查是其日常工作的核心。随着AI编程助手成为工作流的重要部分,作者开始思考:在完全断网的环境下,能否继续利用本地化的AI代理完成开发任务? 这不仅是为了应对偏远地区的网络困境,也是对所有希望完全掌控本地代码生成工具的开发者的一次探索。作者明确指出:“Working from the foothills of the Himalayas... it also comes with its own challenges, including network and power outages.” 这种极端环境为测试本地AI代理的实用性提供了天然的实验室。
OpenCode与Qwen模型的离线架构设计
为了实现完全离线的编程辅助,作者选择了OpenCode这一开源编码代理工具。该工具能够读取项目文件、提议代码修改并运行测试套件,且其权限提示机制允许用户在执行命令前进行审查。配合Ollama本地模型运行服务,OpenCode可以将请求发送至同一台笔记本电脑上的本地实例。作者特别指出:“I picked OpenCode because it lets me keep that workflow in the terminal while connecting to a model running on my own laptop.” 这种架构依赖于Qwen3.5 9B等开源模型,其权重可下载至本地运行。在配置上,opencode.json文件被设定为仅启用本地提供者,指向http://127.0.0.1:11434/v1,并禁用了所有网络工具。启动Ollama时,通过设置环境变量禁用云功能并确保上下文长度为65k token,从而构建了一个完全隔离的本地开发环境。模型下载大小方面,Qwen3.5 9B需要约6.6–7.6 GB的存储空间,而运行此类模型建议预留12-16GB内存以应对上下文窗口和其他应用需求。
模型性能基准与离线测试案例
在选型阶段,作者参考了Qwen官方卡片中的公开数据。以下是不同规模模型在LiveCodeBench v6(代码生成)和BFCL-V4(函数调用)上的表现对比:
| Model | LiveCodeBench v6 | BFCL-V4 |
|---|---|---|
| Qwen3.5 4B | 55.8 | 50.3 |
| Qwen3.5 9B (used here) | 65.6 | 66.1 |
| gpt-oss-20b | 74.6 | Not reported |
注:以上数据源自Qwen官方模型卡片,非本机实测。
此外,《The Scaffold Effect in Coding Agents》研究报告对比了OpenCode、Goose和OpenHands-SDK在50个Terminal-Bench Pro任务上的通过率。结果显示,使用Qwen3.6 Plus时,OpenCode的通过率为50% [36–64%],略高于Goose的48%,但作者强调这些差异在统计上并不显著,且OpenCode消耗了约Goose 40倍的Token。在实际离线测试中,作者使用了一个费用计算器示例项目。初始代码存在逻辑错误:运行程序输出为8.00(最后一个费用值),而非正确的25.50。现有单元测试中有三个用例失败,分别涉及十进制算术、退款处理和示例费用计算。作者强调:“Using existing tests gives the agent a concrete target.” 通过让OpenCode读取这些失败的测试用例,旨在验证其在无网络辅助下修复代码逻辑的能力。
离线环境配置与连通性验证
要在无网络环境下使用 OpenCode,首先需在联网状态下完成初始化配置。启动时需通过 --pure 选项禁用外部插件,确保项目配置中的主模型和辅助模型均指向本地运行的 Ollama 服务。断开网络后,只要 localhost 通信正常即可维持运行。在正式断网前,作者使用 Qwen3.5 9B 本地模型进行了一次诊断测试:要求 AI 读取 expense_total.py 并运行测试,解释 bug 而不修改文件。这一过程揭示了 AI 的初始行为:它最初提议使用 pytest,但该项目实际使用的是 Python 内置的 unittest。这提示在后续任务中,应在 Prompt 中包含确切的测试命令(如 python3 -m unittest -v),以减少 AI 的试错成本。
"The permission prompt gave me a chance to inspect the command before allowing it."
为了确认离线状态,作者关闭了 Wi-Fi 并断开了以太网或手机热点。通过终端命令验证:curl --noproxy '*' http://127.0.0.1:11434/api/tags 成功返回了下载的 qwen3.5:9b 模型列表,证明本地服务响应正常。同时,尝试访问外部地址 https://example.com 失败并显示 "Could not resolve host",确认外部查找已失效。这一系列检查确立了离线运行的基础:所有编码任务必须在完全断开外部连接的情况下进行。
断网状态下的 Bug 修复实操
在确认网络断开后,作者重新启动 OpenCode 并输入具体的修复指令:"Fix the bug in expense_total.py so the existing tests pass. Don't change the tests or install anything." AI 迅速分析代码,提出了一行修改建议:将 total = Decimal(amount) 改为 total += Decimal(amount)。这是一个累加逻辑的错误,原代码每次循环都重置了 total 变量。AI 请求编辑权限并成功运行测试,五次测试全部通过。作者随后手动退出 OpenCode,并在终端中独立运行 python3 -m unittest -v 进行复核。
手动检查结果显示,所有五个测试均通过。保存后的源代码包含正确的累加逻辑 total += Decimal(amount),而测试文件保持原样未变。运行示例程序应返回 25.50。这一案例证明了在完全离线状态下,本地 AI 代理能够准确识别逻辑错误、执行代码修改并通过验证。整个过程无需互联网连接,且 AI 的改动微小且易于审查,确保了代码安全。
扩展练习与离线工作流建议
除了成功的 Bug 修复,作者还推荐了两个额外的编程任务供读者尝试:CSV 报告生成器和日志分析器。CSV 报告示例要求按产品分组行、计算数量和收入,包含七个覆盖排序和空输入的测试;日志分析器则存在错误计数和最慢请求选择的 Bug,同样有七个测试覆盖异常输入。这些练习旨在进一步检验本地 AI 在更复杂任务中的表现。
针对离线编程,作者总结了六条关键建议:首先需提前准备好项目和模型依赖;其次在联网时启动一次完整设置以缓存运行时组件。向 Agent 提供确切的测试命令至关重要,以避免不必要的探索;任务应保持聚焦,每次只修复一个小 Bug 或添加小功能。需密切关注内存压力,因为大上下文和其他应用会挤占模型可用资源;最后,应记录包括失败和重试在内的完整尝试过程。"A useful walkthrough should show permission prompts, retries and failures, as well as the final passing output." 这些经验有助于在断网或旅行等无网络场景下高效利用本地 AI 辅助开发。
离线编程的局限性与未来展望
这次实验初步验证了在无互联网连接的情况下,编码代理可以读取本地文件、做出更改并运行检查。作者通过保持原始测试不变,获得了一种验证结果的有效手段。然而,这种小规模的单文件修复并不能完全反映模型在处理大型代码库或不熟悉框架时的能力。作者指出,"This one-line fix doesn't tell me how well the model would handle a large repository or an unfamiliar framework." 因此,下一步的验证将集中在更复杂的 CSV 报告任务上,该任务要求 AI 完成一个函数而非仅修复一行代码,从而提供更具挑战性的评估场景。
"I’d start with small, self-contained tasks when using this setup during an outage or a journey."
作者强调,在使用此设置应对断网或旅行时,应从小型、自包含的任务开始。项目和所需的一切必须在连接消失前预置在笔记本电脑上。虽然目前的成功令人鼓舞,但要全面评估本地 AI 代理的生产力潜力,仍需通过更复杂的工程任务进行压力测试。
结论
本次实验证实,在完全断网环境下,基于OpenCode与Qwen3.5 9B的本地AI代理具备处理小型、自包含代码任务的能力。在费用计算器案例中,模型准确识别累加逻辑错误并成功修复,所有单元测试通过。这得益于预先配置的本地隔离环境及明确的测试指令。
然而,该成果仅限于单文件小范围修复。作者明确指出,此规模无法反映模型处理大型代码库或不熟悉框架时的表现,且OpenCode在类似任务中消耗Token量显著高于竞品。因此,该方案适用于断网或旅行等场景下的轻量级开发辅助,但需提前预置依赖、聚焦微小任务并严格监控内存资源。其生产力潜力仍需通过更复杂的工程压力测试进一步验证,目前尚不足以替代云端AI处理复杂架构。