我要投稿

我把树莓派5变成了AI程序员，它写的代码比我还强？

发布日期：2026-04-12 08:25:43 浏览次数： 1526

作者：树莓派开发者

微信搜一搜，关注“树莓派开发者”

我当初购买树莓派 5并怀着一个颇为宏大的想法：把它当作一台小型本地 AI 盒子，专门用来处理编码任务。

一部分动机很实际：我想缓解 Claude API 调用限制带来的压力。另一部分原因更简单：这块价格不低的小板子，宣传称可用于 “AI 实验”，我想给它找个真正能用得上的场景。

理论上，在树莓派上运行本地编码模型，堪称完美。它功耗低、可以常年开机、放在桌面不占地方，随时能帮忙测试、写脚本、处理小型编码任务。在我设想里，它会成为一个小巧的本地编码助手。

然而，现实并非如此。

本文详细记录了我在树莓派 5 上部署 Ollama 与 Aider、进行真实编码测试的全过程，最终得出结论：即使是顶配 16GB 版本的树莓派 5，也无法真正替代一台合格的本地编码主机。

我的目标

我的期望并不算高。我并不指望它能媲美带桌面 GPU 的电脑，或是云端大模型。只希望它能在本地完成一些实用的编码工作：

生成一些单元测试
协助进行小型重构
编写小型Bash/Python工具
或许能通过Telegram上的OpenClaw处理快速交互任务

听起来很合理。如今轻量级编码模型越来越强，Ollama 让本地部署变得简单，配合 Aider 还能在命令行便捷使用。于是我决定动手搭建。

第一部分：在树莓派上安装Ollama

好消息是，设置过程其实相当简单。

我从标准的Ollama安装开始：

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，检查版本：

ollama --version

接着下载几款编码模型，我选择了 Qwen-Coder 系列：

ollama pull qwen2.5-coder:1.5bollama pull qwen2.5-coder:3bollama pull qwen2.5-coder:7b

最后，我通过编辑systemd单元文件——nano /etc/systemd/system/ollama.service——将ollama暴露在树莓派之外，并添加了以下两行：

Environment="OLLAMA_HOST=0.0.0.0:11434"Environment="OLLAMA_CONTEXT_LENGTH=8192"

重启服务后，即可在局域网内访问：

curl http://<pi-ip>:11434/api/tags{"models":[{"name":"qwen2.5-coder:7b","model":"qwen2.5-coder:7b","modified_at":"2026-03-29T15:50:06.938558636+02:00","size":4683087561,"digest":"dae161e27b0e90dd1856c8bb3209201fd6736d8eb66298e75ed87571486f4364","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"7.6B","quantization_level":"Q4_K_M"}},{"name":"qwen2.5-coder:1.5b","model":"qwen2.5-coder:1.5b","modified_at":"2026-03-29T15:30:35.122956073+02:00","size":986062089,"digest":"d7372fd828518a4d38b1eb196c673c31a85f2ed302b3d1e406c4c2d1b64a0668","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"1.5B","quantization_level":"Q4_K_M"}},{"name":"qwen2.5-coder:3b","model":"qwen2.5-coder:3b","modified_at":"2026-03-29T14:51:00.437576892+02:00","size":1929912626,"digest":"f72c60cabf6237b07f6e632b2c48d533cef25eda2efbd34bed21c5e9c01e6225","details":{"parent_model":"","format":"gguf","family":"qwen2","families":["qwen2"],"parameter_size":"3.1B","quantization_level":"Q4_K_M"}}]}

第二部分：添加Aider

接下来安装 Aider（https://aider.chat/）。我不想只在终端里和模型聊天，而是想真正检验：树莓派能否成为实用的编码助手。

安装命令：

curl -LsSf https://aider.chat/install.sh | sh

将 Aider 指向本地 Ollama 服务：

export OLLAMA_HOST=http://<pi-ip>:11434aider --model ollama/qwen2.5-coder:3b

可以看到，整套环境搭建非常简单，Ollama 和 Aider 都极易上手。这也是这个项目最吸引人的地方：从零开始，很快就能拥有一个 “本地编码助手”。

可一旦要求模型真正实用、能节省时间而非浪费时间，问题就来了。

第三部分：在实际任务中进行测试

这才是最关键的部分。我不想做无意义的基准测试，也不问琐碎问题，而是直接用日常开发里的小型真实任务测试。

任务1：生成Go测试

第一个有实际意义的测试：让模型为现有函数生成 Go 单元测试。这正是我期待本地编码模型能胜任的场景：结构化、重复性工作，结果 “够用” 即可。

我在一个不到 300 行的小型 Go 项目上测试，分别用了 1.5B、3B、7B 模型，结果全部失败 ——API 请求 10 分钟后超时，没有任何返回。

显然，等十几分钟才能得到一个编码响应，这不叫辅助，而是耽误工作，更不用说并发请求了。

于是我把任务简化到极致。

任务2：小型Python脚本

我不再让它处理已有 Go 项目，而是用一个极简的 Python 函数做测试：

def to_slug(title: str, max_length: int = 50) -> str:    """    Convert a title into a URL-friendly slug.    Rules:    - lowercase everything    - keep letters, numbers, spaces, hyphens, underscores    - replace spaces/underscores with hyphens    - collapse multiple hyphens    - strip leading/trailing hyphens    - truncate to max_length, then strip trailing hyphens again    Raises:    - TypeError if title is not a string    - ValueError if title is empty/blank or max_length < 1    """    if not isinstance(title, str):        raise TypeError("title must be a string")    if max_length < 1:        raise ValueError("max_length must be at least 1")    title = title.strip().lower()    if not title:        raise ValueError("title cannot be empty")    # Remove unsupported characters, but keep spaces, hyphens, underscores.    title = re.sub(r"[^a-z0-9\s\-_]", "", title)    # Convert spaces/underscores to hyphens.    title = re.sub(r"[\s_]+", "-", title)    # Collapse repeated hyphens.    title = re.sub(r"-+", "-", title)    # Trim edges.    title = title.strip("-")    # Enforce max length.    title = title[:max_length].rstrip("-")    if not title:        raise ValueError("title produced an empty slug")    return title

这看起来是一个宽容度更高的测试。上下文更少、结构更简单、需要生成的代码也更少。如果树莓派无法处理小型代码库中的Go测试，也许它至少能处理一个小型Python练习。

提示如下：

> Write a small pytest test file for string_tools.py. >  > Focus only on the function to_slug. > Cover: > - normal title > - uppercase letters > - multiple spaces > - underscores > - punctuation removal > - repeated hyphens collapsing > - truncation with max_length > - blank input raising ValueError > - non-string input raising TypeError > - max_length < 1 raising ValueError >  > Return only the test file code.

qwen2.5-coder:1.5b

1.5B模型花了大约4分钟生成测试文件。

它确实生成了一些可用的内容：

import pytestfrom string_tool import to_slugdef test_to_slug_normal_title():    assert to_slug("Hello World") == "hello-world"def test_to_slug_uppercase_letters():    assert to_slug("HELLO WORLD") == "hello-world"def test_to_slug_multiple_spaces():    assert to_slug("  Hello   World  ") == "hello-world"def test_to_slug_underscores():    assert to_slug("Hello_World") == "hello-world"def test_to_slug_punctuation_removal():    assert to_slug("Hello, World!") == "helloworld"def test_to_slug_repeated_hyphens_collapsing():    assert to_slug("Hello---World") == "hello-world"def test_to_slug_truncation_with_max_length():    assert to_slug("Hello World", max_length=10) == "hello-worl"def test_to_slug_blank_input_raising_ValueError():    with pytest.raises(ValueError):        to_slug("")def test_to_slug_non_string_input_raising_TypeError():    with pytest.raises(TypeError):        to_slug(123)def test_to_slug_max_length_less_than_1_raising_ValueError():    with pytest.raises(ValueError):        to_slug("Hello World", max_length=0)

但其中一个测试完全错误：

======================================================================================= FAILURES =======================================================================================___________________________________________________________________________ test_to_slug_punctuation_removal ___________________________________________________________________________    def test_to_slug_punctuation_removal():>       assert to_slug("Hello, World!") == "helloworld"E       AssertionError: assert 'hello-world' == 'helloworld'E         - helloworldE         + hello-worldE         ?      +test_string_tool.py:17: AssertionError=============================================================================== short test summary info ================================================================================FAILED test_string_tool.py::test_to_slug_punctuation_removal - AssertionError: assert 'hello-world' == 'helloworld'============================================================================= 1 failed, 9 passed in 0.09s ==============================================================================

从绝对意义上讲，这个结果并不糟糕。模型基本上理解了任务。但是，花费4分钟生成一个小型pytest文件，且其中包含一个错误的断言，这在实际工作流程中远远达不到我的期望。

qwen2.5-coder:3b

3B模型花了大约4分半钟。这次，它生成了一个更好的测试文件：

import pytestfrom string_tool import to_slugdef test_to_slug_normal_title():    assert to_slug("Hello World") == "hello-world"def test_to_slug_uppercase_letters():    assert to_slug("HELLO WORLD") == "hello-world"def test_to_slug_multiple_spaces():    assert to_slug("  Hello   World  ") == "hello-world"def test_to_slug_underscores():    assert to_slug("Hello_World") == "hello-world"def test_to_slug_punctuation_removal():    assert to_slug("Hello, World!") == "hello-world"def test_to_slug_repeated_hyphens_collapsing():    assert to_slug("Hello---World") == "hello-world"def test_to_slug_truncation_with_max_length():    assert to_slug("Hello World", max_length=10) == "hello-worl"def test_to_slug_blank_input_raises_value_error():    with pytest.raises(ValueError):        to_slug("")def test_to_slug_non_string_input_raises_type_error():    with pytest.raises(TypeError):        to_slug(123)def test_to_slug_max_length_less_than_one_raises_value_error():    with pytest.raises(ValueError):        to_slug("Hello World", max_length=0)

所有10个测试用例未经修改全部通过：

10 passed in 0.02s

输出结果不错，但对于如此简单的任务来说，延迟仍然高得离谱。我可能自己编写测试的速度比等待模型完成思考还要快。

生成的输出仍有改进空间。例如，我可能会为全空白输入添加一个额外的测试。

with pytest.raises(ValueError):    to_slug("   ")

qwen2.5-coder:7b

7B模型花了超过10分钟。与较小的两个模型不同，它实际上将测试放在了test/test_string_tool.py下，乍一看似乎是一个更聪明的结果：

import pytestfrom string_tool import to_slugdef test_normal_title():    assert to_slug("Hello World") == "hello-world"def test_uppercase_letters():    assert to_slug("HELLO WORLD") == "hello-world"def test_multiple_spaces():    assert to_slug("  Hello   World  ") == "hello-world"def test_underscores():    assert to_slug("Hello_World") == "hello-world"def test_punctuation_removal():    assert to_slug("Hello, World!") == "hello-world"def test_repeated_hyphens_collapsing():    assert to_slug("Hello--World") == "hello-world"def test_truncation_with_max_length():    assert to_slug("This is a very long title that should be truncated", max_length=10) == "this-is-a-very"def test_blank_input_raising_ValueError():    with pytest.raises(ValueError):        to_slug("")def test_non_string_input_raising_TypeError():    with pytest.raises(TypeError):        to_slug(123)def test_max_length_less_than_1_rasing_ValueError():    with pytest.raises(ValueError):        to_slug("Hello World", max_length=0)

但文件甚至无法运行：

E   ModuleNotFoundError: No module named 'string_tool'

手动修正导入问题后，仍有一个测试失败：

======================================================================================= FAILURES =======================================================================================___________________________________________________________________________ test_truncation_with_max_length ____________________________________________________________________________    def test_truncation_with_max_length():>       assert to_slug("This is a very long title that should be truncated", max_length=10) == "this-is-a-very"E       AssertionError: assert 'this-is-a' == 'this-is-a-very'E         - this-is-a-veryE         ?          -----E         + this-is-atest_string_tool.py:23: AssertionError=============================================================================== short test summary info ================================================================================FAILED test_string_tool.py::test_truncation_with_max_length - AssertionError: assert 'this-is-a' == 'this-is-a-very'============================================================================= 1 failed, 9 passed in 0.09s ==============================================================================

更令人失望的是，该工具实际上并不知道如何独立完成整个循环。它能够生成测试代码，但无法运行测试、观察失败情况，并在同一工作流程中迭代修复错误。

这一点很重要，因为本地编码助手的重点不仅仅是输出代码。它的目的是帮助你以最小的阻力获得一个可工作的结果。

到目前为止，这种体验与我日常工作中的实际需求相差甚远。仅延迟一项就使得即使是小任务也显得比实际更繁重。

第四部分：问题出在哪里

回想起来，很明显，即使是性能最强的16GB树莓派也不是为人工智能编码协助而设计的工具。这并不意味着树莓派5的硬件不好。相反，就其设计目的而言，它实际上非常出色。

但是，一旦从玩具演示转向实际使用，大语言模型（LLM）推理（尤其是编码推理）对硬件的要求就非常苛刻。编码模型需要足够的内存、足够的吞吐量以及足够的原始推理速度来保持紧密的交互。这正是树莓派所欠缺的。

即使模型在技术上能够运行，体验也会受到树莓派硬件类型的限制：与真正的台式机相比，CPU性能有限；对于此类工作负载，没有强大的GPU加速；内存带宽根本不适合与编码模型进行快速本地推理。

结论

我最初的想法很简单：使用树莓派5作为本地编码助手，稍微减轻API的使用压力，并最终为这台昂贵的小机器找到一个真正的人工智能工作。

尝试之后，我的结论也很简单：这不是执行该任务的合适机器。

如果你的目标是进行试验、了解本地模型的工作原理或构建小型演示，那么树莓派很有趣。如果你的目标是拥有一款真正有助于日常编码的工具，那么即使是16GB的树莓派5也不够用。

老实说，我认为这值得大声说出来，因为许多业余人工智能内容都聚焦于某样东西能否运行，而不是它是否应该以那种方式使用。

因此，我的树莓派现在可能有着不同的未来。它不再是“本地编码助手”，而是更多地扮演“智能家居盒子”、Home Assistant主机或其他适合其硬件的常开项目的角色。

想要查看原文，请点击文章尾部的【阅读全文】。

1. 树莓派CM0，CM0NANO 开启测评！

如果您是具有一定影响力的树莓派爱好者，创客爱好者，热爱动手，搞项目做测评，拥有自己的树莓派圈子，活跃在各个树莓派的论坛，或者是小有成就媒体博主，都可以添加小编微信：EDATEC_SH，备注测评申请！（名额有限）点击此处了解规则！

2. 加入树莓派爱好者群！

话题：代码、DIY、项目、整活、求教程
成员：学生、社畜、退休工程师、神秘高中生

添加小编拉你进群，微信号：EDATEC_SH

3. 树莓派CM0优惠劵活动！

官方网站：https://edatec.cn/zh/cm0

淘宝店铺：https://edatec.taobao.com/

53AI，企业落地大模型首选服务商

产品：场景落地咨询+大模型应用平台+行业解决方案

承诺：免费POC验证，效果达标后再合作。零风险落地应用大模型，已交付160+中大型企业