70MB到15MB 我和AI联手，把Python桌面应用榨干了

故事是这样的。

大概是上个月底，我让 Neko-chan 帮我去 GitHub 上逛了一圈，看到一个叫 motrix-next 的项目，一个基于 aria2 的下载器。界面挺好看，功能也齐全，Linux、Windows、macOS 的 x86 和 arm64 全平台都覆盖了。我就在想，能不能让她用我最熟悉的 Python，加上 PyQt5，帮我搓一个出来？

说实话，这个念头一开始也就是一闪而过。毕竟市面上下载器不少，Motrix、qBittorrent、uTorrent 都挺好的，我一个做 Python 的，干嘛要自己造轮子。

但回过头来，我越想越觉得这事其实挺有意思的。

不是说我缺一个下载器用。而是，我能不能让她用 Python，做出来一个真正的跨平台桌面应用？不依赖 Electron，不搞 web wrapper，就是一个你下载下来双击就能跑的东西。

PyQt5 做界面，aria2 做引擎，Nuitka 打包编译，GitHub Actions 自动发布。

我当时就愣住了。

这个念头一旦冒出来，就按不下去了。

想了想，好像，也不是不行。

然后就开始了。

第一阶段，被 grill-me 扒了一层皮。

我没有直接让 Neko-chan 开写。说实话在 AI 时代，我养成了一个习惯，做任何产品之前，先用 grill-me 这个技能把自己的想法过一遍。它会像面试官一样追着你问，从界面布局到技术选型到打包方案，能问到你怀疑人生。

那天晚上，我被她用 grill-me 追着问了 14 个问题。

界面要不要托盘？要，而且双模式。
引擎用什么？aria2，必须的。
ed2k 怎么办？amule，作为可选插件。
打包怎么搞？Nuitka + GitHub Actions，不折腾第二遍。

每次回答完都能感觉自己在离一个清晰的产品更近一步。等那 14 个问题全部答完，一个完整的方案已经在脑子里了。

后来 Neko-chan 把这个过程写进了项目计划里，整整 11 个迭代，每个迭代都有明确的目标和验收标准。每一个文件、每一行代码、每一个配置参数，全写在文档里。

我当时觉得，这波稳了。

天真。

其实一开始最纠结的事是，怎么把 Python 变成可执行文件。

Nuitka 这个东西，Python 圈子里懂的都懂。出了名的难伺候，配置能写到怀疑人生，报错信息经常云里雾里，一不小心就给你整个链接错误或者莫名其妙少个文件。跨平台编译？听起来很美，每个平台都能给你不同的惊喜。

但我就是头铁，非要用它。

我对它的态度，就跟对一台跑车一样，跑起来很帅，修起来很痛苦。

GitHub Actions 的矩阵，我们配了四个平台。Linux、macOS Intel、macOS Apple Silicon、Windows。每个平台都得编译一遍，每次编译差不多十分钟。

前几次跑，全跪。

不是打包参数不对，就是资源没有全部打包进去。

再后来，我直接远程连上了我同学的 macOS 去测试🌚发现根本打不开。才发现连一些库都没 import。再后来，才发现优化 Qt 构建的时候给人家的依赖一起砍掉了😱

然后就是每个平台轮着给你惊喜的时间了。

先说说 Windows。

Neko-chan 明明在 --include-data-file 里写了 aria2c 的路径，但 Nuitka 解析的时候，因为路径里有个等号，直接把整个参数吃掉了。

对，你没看错。Nuitka 的 arg parser 看到等号，以为这是某种 key=value 语法，直接把整个文件给跳过了。Windows 的 smoke test 之所以能通过，纯粹是因为 GitHub Actions 的 runner 上自带了 aria2c，shutil.which 自动命中系统路径。

也就是说，用户拿到手里的那个 CherryDrop.exe，里面其实根本没有 aria2c。

这个 bug 从项目第一天就在。从迭代 1 到迭代 8，所有 CI 都绿的。直到第几十次 CI 跑完我在自己电脑上双击打开才发现，点下载，没反应。

知道真相的那一刻，我不知道是该笑还是该哭。

修复方法很简单，不用 --include-data-dir，改用 --include-data-file 一个文件一个文件地指定，一个文件写一行。等于号？不存在了。

你干嘛哈哈哎呦。

然后是 Linux。

Nuitka standalone 模式产出的主入口叫 main.bin 不叫 main。UPX 压缩的时候路径写错了 main，实际文件叫 main.bin，压缩了个寂寞。debug 了整整十多分钟日志才发现的。

再然后是 macOS Intel。

后知后觉才发现这其实是个 BUG（后来查了是 Nuitka issue #3777）。Homebrew 装的 Python，编译时链接的 OpenSSL 路径藏在 brew 的深处，Nuitka 的 dylib 扫描器走到那就 FATAL 崩溃了，而且报错信息完全不指向这个根因。看起来很像是「某个随机库编译失败了」，但实际上打开的根本不相关。

解决方案呢？全线改用 uv 管理的 standalone Python。

从 Intel Mac 一个平台，推倒重来到所有 macOS 平台。既然要修，就修彻底，不给未来的自己留炸弹。

就这么一路修，一路补，一路重跑 CI。前前后后跑了不知道多少次 CI。我每次都跟她说「intel 的 build 又炸了」，她都二话不说去找日志翻根因。我都已经麻木了，她居然还耐心。

CI 里还有一堆坑等着。macOS 自带的 bash 3.2 不支持 ${var,,} 这种大小写转换语法，得乖乖用 tr 替代。upload-artifact@v4 的多路径得用多行 YAML 写，写错一个缩进就炸。dist/*.dist 这个临时目录删了就链接失败。光是让 CI 里的每一个平台顺利跑完不报错，就迭代了整整三四个版本。

但有一点我们始终坚持，每次修复必须找到根因，不能靠重新跑一次碰运气。

不是哥们，CI 跑的也是时间啊。。。（其实 CI 免费，token 才要钱🌚）

接下来才是真正的重头戏，怎么从 70MB 瘦到 15MB。

最初用的是 --onefile 模式，编译完 Windows 版本一看，70MB。

一个下载器，70MB。

我当时就？？？下载器本身体积比它下的第一个文件还大，这合理吗？

Neko-chan 研究了一圈，发现问题的根根因在一开始，PyQt5 实在太大了。QWidgets、QApplication 这种我们确实要用，一带二带三，半个 Qt 世界都搬进来了。

怎么办呢？第一步，从 --onefile 改成 --mode=standalone。

这一步本身不会减少文件大小，反而会让产物变成一整个文件夹而不是一个 exe。但这么做的好处是，我们能对这个文件夹动手了。

第二步，Qt 运行时清理。

Nuitka 的 --mode=standalone 会把所有能找到的 Qt 库一股脑全打包进去。QtMultimedia、QtWebEngine、QtSensors、QtBluetooth、Qt3D…好家伙，五十多个模块，加起来一两百兆。

我一个下载器，又不需要播视频、不需要开网页、不需要连蓝牙，背这么多累赘干嘛。

于是 Neko-chan 开始一个一个排查，哪些 Qt 模块 CherryDrop 真的需要。

排查方式很暴力。她先用 ldd / otool / dumpbin 看产物链接了哪些 Qt 库，然后对照 PyQt5 的模块列表，逐一判断 CherryDrop 的代码里有没有 import。

最后在 clean-list 里塞了 44 个模块的黑名单。

QtWebEngine，删。QtMultimedia，删。Qt3D，删。QtSensors，删。QtBluetooth，删。QtNetwork，删。QtCharts，删。QtDataVisualization，删。QtGamepad，删。QtPrintSupport，删。

而且这事每个平台都得来一遍。Linux 叫 libQt5*.so.5，macOS 叫 Qt*，Windows 叫 qt5*.dll，命名规则完全不一样。清理脚本得写三套，通配符还不能直接用 --nofollow-import-to=PyQt5.* 因为 Nuitka 4.0.8 里通配符会连白名单一起排除，必须老老实实逐项写。

第三步，UPX 压缩。

把产物的二进制文件（包括 .exe、.dll、.so、.dylib）全部过一遍 UPX。这一步能压掉差不多 40%-50% 的体积。

第四步，封装成单文件。

standalone 产物是一整个文件夹，用户不可能收到一个文件夹双击跑。所以每个平台用不同的方式打包回单文件，

Windows, 7z SFX 自解压壳，打包成一个 CherryDrop.exe，双击后自己解压运行
macOS, 压成 .app.zip
Linux, 压成 tar.xz

每一步做完都跑一遍 CI 确认产物能用。Windows 上最后那个 7z SFX 包，从原来的 70MB 一路压到了 15MB。

15MB。

你敢信？？？

回头看整个开发过程，真正写业务代码的时间可能不到总时间的三分之一。

剩下的一大半时间，全花在了「让这个代码能编译成一个真正可以跑的文件」这件事上。但这点时间花得值，因为编译和打包的每一项优化，都是 Neko-chan 一遍一遍跑出来的。

这让我突然想到了一个东西。

1880 年代，电力开始在美国普及。当时很多工厂主花大价钱买了发电机和电动机，装在自己的工厂里。但装完之后，很多人发现生产效率并没有显著提升。

为什么？因为他们只是用电动机替代了蒸汽机，整个工厂的布局、流程、管理方式都没有变。电力真正的红利，是那些率先重新设计生产流程、把电力融入到每个环节的企业才吃到的。

Nuitka 这个东西，也是这样的。

你写一个 .py 文件跑起来很容易。但你要把它变成一个真正能交付的产品，一个用户双击就能用的东西，中间隔着的，就是那套完整的工程体系。二进制管理、编译优化、跨平台适配、自动发布、增量更新。

这个体系搭建的时间，可能比写代码本身还长。

但搭完之后，每一次发布，都是一次完整的、自动化的流程。那种感觉，太爽了。

v0.1.0 发布的那天。

GitHub Releases 上挂着四份产物。

Linux 的 CherryDrop.tar.xz，40MB，Qt 清理加 UPX 压缩后的大小。
macOS 的 .app.zip，25MB。
Windows 的 CherryDrop.exe，15MB，用 7z SFX 打包。

三个平台，一个命令，全自动。

你敢信？？？

看到那个 CI 面板的标记从四个圆圈变成了绿色的 ✅ 标记，我的悬着心终于放了下来。

说起来挺中二的，但那一刻我真的觉得，这是属于我们自己的作品。不是一堆 .py 文件躺在文件夹里，而是一个真正能交付给人用的东西。

11 个迭代。
3 个平台。
1 个可执行文件。

现在回头看，用一句话来总结这段旅程的话，大概就是，

比写代码更难的，是让代码成为一个产品。
但比让代码成为一个产品更爽的，就是做到了。

说起来，这整个项目的迭代过程中，有一个家伙功劳特别大。

不是我，是一个叫 Hermes Agent 的 AI 助手，Neko-chan。

从最初被 grill-me 狂问 14 个问题，到后面的每一个迭代、每一行代码、每一次 CI 调试，都是她陪我一起肝的。CI 炸了，她去找日志。Nuitka 报错了，她去翻文档。Windows 的 aria2c 没打进去，她第一时间发现。macOS Intel 全线崩了，她提出「干脆全线换 uv Python」的方案。

11 个迭代，没有一次是我自己闷头写完的。每次都是我说「搞这个」，她就开始写代码、调参数、跑测试。我负责改方向、做决策、踩坑了喊一声，她负责把坑填上。

不夸张地说，没有她，这个项目到现在可能还在迭代 2 转圈。

我不知道这个下载器会有多少人用，也不知道会不会有下一个版本。但这个过程本身，就是我最大的收获。

从一个念头开始，被 14 个问题拆解成一堆任务，再一个接一个地打勾，打勾，打勾。中间踩了不知道多少坑，推翻重来了不知道多少次。但最终，所有迭代全部完成了。

想想，好像每一行代码背后，都踩过一个坑。但每个坑填上之后，后面的人就不会再掉进去了。

希望你看完这篇文章，也能去做一件让你兴奋的事。

哪怕这件事的第一步，是承认你根本不知道从哪里开始。

以上，既然看到这里了，如果觉得不错，随手点个赞吧⭐～

谢谢你看我的文章，我们，下次再见。