---
author: Peter Pang
date: '2025-12-31'
guest: ''
layout: post.njk
source: https://www.youtube.com/watch?v=rHS3ICfiImo
speaker: Peter Pang
tags:
  - rust
  - nodejs
  - llm
  - code-refactoring
  - legacy-systems
title: 大逆不道！我要用Rust重写我的十年老系统！
summary: 本视频回顾了运行十年的物联网系统技术栈演化，重点介绍了选择Rust重写的原因，展示了AI在重写遗弃JavaScript组件（蓝牙、消息队列）时的强大能力，并指出了当前大模型处理超大规模任务的局限。
insight: ''
draft: true
series: ''
category: ai-application
area: tech-engineering
project: []
people: []
companies_orgs: []
products_models: []
media_books: []
status: evergreen
---
### 系统十年演进：从Java到Rust的迁移之路

我负责开发的最古老项目，即将迎来它的10岁生日。它这十年的技术栈演化，可以说是见证了一个长期运行项目会面临的各种挑战。这个物联网终端系统，其实只需要做一件很简单的事情：把云端发过来的内容显示在屏幕上。但落实到代码上，还是会有很多细节可以考究，很多地方可以被优化的。

追溯其源头，从2016年以Java加Selenium为核心，到后来Docker的引入，Selenium被Puppeteer取代，Java被JavaScript取代，Docker被systemd取代，JavaScript又被bash取代，再到后期用定制的Linux替换掉Ubuntu作为底层OS，这个系统的每一次改动都值得回味。这段跌宕起伏的历史，我后面会用一个单独的视频来回顾。

### Rust的考察期：新技术选型与期望

因为今天的主题不是缅怀过去，而是畅想未来。看过【让编程再次伟大#1】的老粉丝都知道，我会先考察一个技术栈几年，再决定要不要把它用到自己的项目中。而Rust就是那个刚刚通过考察期的技术。虽然这次的目标是用Rust重写终端系统的功能组件，但我们对它的期望其实没有很高，仅仅是希望能够让我们少点遇上【让编程再次伟大#25】里提到的那种要debug几天几夜的抽象故障就可以了。

### JavaScript生态困境与AI的“造轮子”能力

然而，在这个用Rust重写的任务中，最大的挑战并非Rust本身的学习曲线，而是现有Node.js难以替代。JavaScript生态说好听的是更新迭代快，说难听的是弃坑更快，能维护10年的工具库少之又少。而相比较而言，Rust社区则是又小又分散，很多小众功能没有人做，或者是做了也没有人知道。这就引出了一个可能的最坏情况：我们需要用Rust徒手造轮子 😨。

说到造轮子，这就不得不提 **编程大模型**（Programming Large Models: 依赖海量数据和经验，擅长生成代码和解决经验型任务的 AI 模型）。你让它做个新东西，它可能给你胡编乱造，但提到造轮子这种很依赖经验的任务，它就显得游刃有余。对大模型这种靠着吃数据堆积经验而发家的技术路线来说，这简直就是如鱼得水。这也难怪全球AI厂商都在卷编程这个赛道了。

### 蓝牙组件重写：AI定制化解决方案

首先要重写的，就是整个系统里最岌岌可危的蓝牙组件。这个组件原本用的是一个叫 `bleno` 的Node.js工具库，开发者维护了它5年之后弃坑了。后来一个叫做 `AabandonWare` 的专门收留被遗弃软件的组织接手，但是他们接盘了5年后也弃坑了 😂。被一个叫做 `AbandonWare` 的组织 abandon 的软件，可见其处境有多惨。

令人意外的是，我在给AI的命令中，其实并没有明确提到要它去“造轮子”。它却选择了通过d-bus调用bluez接口（全是OS层的原生接口），自己实现了蓝牙外设功能。横向对比原来的 `bleno` 代码就可以看出，它并不是一比一还原了 `bleno`，而是在理解了我们蓝牙组件的应用场景的基础上，专门为我们手搓了一个定制版，将我们应用层代码都融入进去了。

仔细想想，这种做法其实是合理的。毕竟我们不是要造一个像 `bleno` 那样囊括了所有蓝牙功能，可以发布出去让大家都安装使用的通用蓝牙工具库。我们的重写只需要服务我们自己的系统，所以就没有必要造一个完整的轮子，也不需要刻意地把应用逻辑剥离出来。从这点来看，现在的AI已经经过了一定的软件工程层面的思考，已经不像以前的编程AI那样，只是一个无情的码字机器，为了彰显自己的上下文窗口很大（和多点消耗你的token）而写得臃肿不堪。

### 消息队列重写：AI的架构选择与风险控制

在蓝牙组件重写之后，我又尝试了重写所有组件都会共享的消息队列框架。这个框架作为组件中通讯和交流数据的主要渠道，基本上就是在Redis数据库上套一个叫做 `bull` 的Node.js工具库。这个 `bull` 也是被开发组弃坑了，只不过这次是因为他们发现这个东西很有赚头，所以另开新坑，做起了付费版本。对于遵循开源精神的我来说，这是绝对不能接受的，所以换掉它们也是名正言顺的事情。

这个重写的难度更高，因为这个消息队列被几乎所有组件依赖，是牵一发而动全身的关键节点。这次AI很明显也意识到这个问题，所以它在下手之前，给了我三个选择：
A. 用Rust重写 `bull` 和所有用到它的Nodejs组件
B. 用Rust重写 `bull`，所有Nodejs组件通过socket来对接Rust版本的新框架
C. 用Rust封装一个命令行工具，提供类似 `bull` 的消息队列接口，组件可以生成子进程来调用它。

那么问题来了，如果让你来做这个项目的架构师，这里你会选哪个？我选择了B，因为这个做法是改动范围最小的，风险最低的。而从最后的生成结果可以看到，除了重写整个 `bull` 框架，它还很聪明地用JS对照着 `bull` 的API风格，封装了Rust框架的socket接口。这样子所有用到消息队列的组件，都只需改一下导入工具包的那一行，其余代码几乎不需要改动。不要冒风险，尤其是没有必要的风险，是一个程序员成长和成熟的体现。在这个颇有难度的挑战上，AI做出了基本满分的回答，这让我还有点意外呢。

### 超大规模任务的瓶颈：Transformer模型的上下文限制

其实在重写这两个组件之前，我还做了另一个尝试，那就是让AI一次性地把整个项目代码全部用Rust重写。而不出意料的是，效果不太行。反正现在超大规模任务的瓶颈是出在 **Transformer模型**（Transformer Model: 一种基于自注意力机制的深度学习模型架构，常用于自然语言处理任务）的设计上。什么时候全球科学家能解决上下文超过64K，准确率就会断崖式下跌的问题，我们再来考虑一口气重写整个项目的可能性吧。