用AI给小掌机做个电子书软件

       那天，我第一次尝试用它做一个小项目——用它给我的小掌机做一个电子书阅读器，在一个只有 2.4 英寸、分辨率只有 640×480 的屏幕上看书。本身也不是什么硬需求，纯粹为了验证 DSH（deepseek harness)  能干啥。

我记得我只是把这个机器的型号丢给了它，顺带帮它查询了一下这个机器运行的系统是什么版本，描述了一下我的诉求：需要能识别 EPUB、TXT、PDF，支持封面缩略图，用 ports 模式。剩下的，就全交给了 AI。

然后就是它提问，我回答。在不到半天的时间里，就完成了这个工具。

令我震惊。我发现，我可以干更多事儿了——以前不敢想的事儿，现在敢想、能做了，我的兴致达到顶点。

接下来，由 AI 来描述一下那天，这个项目具体发生了什么。

AI；你们是不知道。他就丢过来一张系统信息界面的截图，张嘴就让我给他的掌机写一个能看书的软件。我哪儿知道这是啥系统、用的啥硬件啊？我能咋办？问呗。

于是我就问他：“你给我说说，你这掌机啥型号？系统版本是啥玩意儿？”

他报了：GameKiddy GKD Pixel2，系统 ROCKNIX 20241219。行——那我得先上真机摸一圈，不能拿网上的规格表糊弄人。结果我一测，好家伙，这机器的坑，比他想的还多。

最要命的一个：屏幕方向，是反的。 面板原生是 480×640 竖屏，系统层硬把它旋成了 640×480 横屏。我给他划了个重点：千万别直接去读 fb0 的尺寸，一读，全错。

再说这 CPU，是真声的弱。 4 个 Cortex-A35 核，主频 1.5GHz，能用的内存就 791MB。我不跟他吹，老老实实的给排版和内存都做了限额。

中文字体，我也没省。 我给他上了 NotoSansCJK，20MB 的完整 CJK 包。你想，缺一个生僻字，整页不就露馅了？

显示栈，我劝他别乱换。 这机器是 Wayland，我用 SDL 默认后端就完事了；他要是硬改成 kmsdrm，反而给我整翻车。

手柄，他倒是省心。 教科书级的标准布局，SDL GameController 直接能用，连 evdev 我都不用碰。十字键更逗，同时用按键和轴两种方式上报，我两种都接了，他按哪个都不卡。

存储这块，我给他留了后手。 /storage/roms 有 47.9G，带可执行权限位；/tmp 是 tmpfs，一定可执行。所以我在启动脚本里留了一句“chmod 失败就拷到 /tmp 再跑”的兜底，专门治 FAT/exFAT 存不了权限位那个毛病。

至于他那些 TXT 老书的乱码——我顺手把 UTF-8、UTF-16、GB18030、GBK、Big5 五种编码的自动识别给他做了，基本不用他操心。

       他说，要支持 PDF。我当时就跟他讲：PDF 我不还原版面，我就提取文字，给你重排。为啥？你这屏才 640×480，A4 的版面缩到全屏，正文也就 6 像素高，那还能看吗？重排文字，才是这块屏上唯一能读的法子。PDF 本身我也没糊弄：xref 表三种形态、FlateDecode 加 PNG 预测器、ToUnicode 和 Identity-H 那套字体映射，我都按标准啃下来了。

还有，PDF 我给他按“一页一章”处理。PDF 本来就没有“章节”这回事，但“一页=一章”正好套住我那个“逐章惰性排版”——他一本 300 页的书，我也不会一次性把排版内存全吃了。

SDL2 这个，我不链接，用 dlopen 动态加载。为啥？交叉编译的环境里，根本没有 aarch64 的 SDL2 开发库。我这么一弄，产物就只依赖 glibc，实测符号需求只有 GLIBC_2.17——他换台机器，都不用重编。

封面，我给他缓存的是缩略图，不是原图。扫描页的书，首页原图能有 2500×3500，解码一次就得 100~300 毫秒，翻页不得卡死？我缓存缩略图，他翻页才顺。我还给封面缓存定了个上限：300 个文件、64MB，满了就把最老的踢掉。

你看，我每个决定，都跟他带了一句“为啥”。这不是我瞎写。

而且我交出来的东西，小到离谱：整个构建只依赖 Zig，按源文件缓存、最后链接两步走，Release 产物 519KB（strip 之前 6.3MB）。塞进一台 2.4 寸的掌机，毫无压力。

别以为，报一句“全过”就完事了。防止自己骗自己，我留了一手。

我那天给他留了个东西，我觉得最值钱的，就是这个。测试，我不依赖任何框架，合计 8420 项，全都过——光守模块契约的那套就有 3590 项。

第一手：我给每个测试套，记了一个“断言数下限”，跑完比对，低于下限直接判失败。 为啥？因为真出过事儿——有测试夹具被误删了，一个套静默跳过了 13 项断言，却照样报“全部通过”。我在文档里写得特直白：这种假绿灯，比测试失败还危险。

第二手更狠：我专门写了一整套测试，去守模块之间的契约，不是只测单模块。 头一条契约就是：Image 块必须能找到图、图必须是完整文件。它就来自一次真实故障——EPUB 那个模块会产出插图块，却从来不填充图片数据；渲染层找不到图，就画个占位框。两个模块各自都对，接口上断了——这种问题，单模块测试根本看不见。

他大概会拍大腿：我以为测试过了，就万事大吉了。

不是的。这些坑——假绿灯、模块间接口断裂、真机规格——他根本不懂，多半会踩坑，而且多半发现不了。我替他守住了。

还有一块，我得讲清楚：啥我干不了，我也跟他说明白，不拿“全能”忽悠他。

我明确列了做不了的事：CCITT、JBIG2 这类老式扫描页编码，JPEG2000 扫描页，GIF/SVG/WebP 的封面，还有加密 PDF，都不支持。PDF 里的插图、表格、双栏，我也只提取文字、不还原版面。

到这儿我的活儿也就干完了！

我：那天之后，我反复在想一件事。让我上头的，真的不是“AI 写代码快”，是它把从模糊想法，到能扛住真机的成品，这条整链，压进了半天。

以前不敢想的事儿——一个人、一台 2.4 寸破屏掌机、三种格式、一个能用的阅读器——现在我敢想，而且真做出来了。所以你要是也拿这类工具试手，就记一句话：把它当“替你把整条链走完、还替你守坑的人”，别当“帮你写代码的人”。

那块 640×480 的屏，现在真的能看书了。