2026-07-04

昨晚折腾到两点。

不是因为加班，是在试一个思维方式完全不一样的玩法。GitHub 上有个新项目叫 PxPipe，思路很简单：把代码渲染成图片，然后让 AI 模型去 OCR 识别这些图片来理解代码。

你看到这个第一反应是什么？我的第一反应是：绕这么大一圈，有病吧？

嗯，后来发现有病的是我。

事情是这样的

前两天在重构一个老项目——一个十年前写的 Java 后端，包名还是 com.company.legacy 那种——想着用 Claude Code 的 Fable 模式搞定。Fable 是 Anthropic 的自主编码模式，号称能端到端地处理复杂任务，不用你一步步引导。

然而现实很骨感。

一段 2000 行的核心逻辑类，Fable 打开后开始逐行解析上下文。然后——卡住了。API 调用超时。再试一次，token 飙到 8 万，账单飞涨。说实话，你用它来处理一个中等复杂度的代码库，费用比请一个初级开发还贵。后来甚至不敢拿它做普通的代码 review，等它读完上下文，咖啡都凉了。

简单问答用它属于杀鸡用牛刀，复杂重构用它属于牛刀杀鲸鱼——刀是好刀，就是费刀。

PxPipe 的思路

PxPipe 的作者显然也遇到了同样的问题。但他换了个角度：既然模型对文本 Token 那么敏感，为什么不把代码转成图像，利用模型的视觉能力来处理？

它的做法听起来绕但很直接——先把源文件用 pygments 做语法高亮渲染成高分辨率 PNG，行号、字体、缩进全部保留在图像中。然后把这张图喂给支持多模态的模型——Claude 3.5 Sonnet 或 Claude 4 都行。模型通过视觉编码器"读取"图片里的代码结构，然后进行分析和修改。没有 Token 化，没有序列化，没有注意力衰减。整张图一次性编码，空间关系通过 2D 注意力保持。

结果：Fable 模式下，同样的重构任务，Token 消耗降了 60%，时间缩短了接近一半。

喝了一大口咖啡——凌晨一点四十——重新看了两遍测试数据才敢信。

其实这背后有个更有趣的点。PxPipe 用了一个叫做 Format-Preserving Rendering 的技巧：渲染时不仅保留代码的视觉样式，还把行号和缩进层次用颜色编码嵌入到图片的元数据区域。这样模型不仅能"看到"代码的文本内容，还能通过颜色梯度感知到嵌套深度——这在纯文本模式下需要大量显式的缩进 Token 才能表达。

我试过把这段逻辑用在别的地方——把一个复杂的 JSON 配置文件渲染成图片让 Claude 分析——效果出奇的好。原本需要 5000 Token 的描述，用图片只用了 800 Token。

说实话，这个方向可能被低估了。不是替代文本交互，而是在文本不擅长的场景里——结构密集型、空间关系敏感的代码——用视觉通道作为补充。

为什么会有这种效果

我原本以为这肯定会影响准确性——毕竟 OCR 不是 100% 完美，代码里一个字符的错误可能带来编译错误。但我实际测试下来，发现情况正好反过来。

关键在于模型对"图像"和"文本"的处理方式差异。

文本模式下，Fable 把整个代码库当作连续的 Token 流。每一行代码、每一个注释、每一个空格都被序列化成 Token。2000 行的 Java 类，Token 数轻松破 3 万。模型需要在这个巨大的序列中保持注意力——这是 Transformer 架构最薄弱的环节：长上下文下的注意力衰减。

图像模式下呢？一段 2000 行的代码被渲染成 2-3 张图片。模型的视觉编码器（Vision Transformer 或类似架构）将整个图片一次性编码，空间关系通过 2D 注意力保持。模型"看到"的不再是一串 Token，而是一个完整的代码结构——包括缩进层次、代码块边界、过长行的换行位置。

结果就是：模型对代码结构理解得更准，而不是更差。

我拿了个老项目的 API 层做测试——12 个接口、6 个 Service、3 个 Repository——Fable 文本模式跑了 4 分 20 秒，生成了 2.8 万 Token。PxPipe 模式跑了 2 分 10 秒，只用了 1.1 万 Token。重构后的代码质量从可读性来看，PxPipe 的版本甚至更好——保留了原有的注释格式和空行风格，而文本模式的版本把一些空行合并了。

不是银弹

当然，PxPipe 也不是万能的。

如果代码行特别长（超过 120 字符），渲染成图片后字体缩小，OCR 识别率会下降。我在一个古老的项目里见过 400 字符一行的 SQL 拼接——那种代码 OCR 出来一堆乱码，完全没法用。

另外，PxPipe 对代码文件数量和项目规模的依赖是线性的。如果项目文件超过 50 个，渲染和 OCR 的累计时间也会涨上去。收益递减开始在 80-100 个文件附近出现——这时候图片的总像素量已经很大了，编码开销抵消了 Token 节省。

还有一个坑：PxPipe 当前的实现只映射了语法高亮颜色到对应语言的 Token。如果你用了一个冷门的语言或者自定义的语法高亮方案，它可能不认识。

怎么说呢，这玩意儿不是替代 Fable 的，它是一个在特定场景下能省一大笔钱的技巧。

更大的启示

其实 PxPipe 让我想通了一件事：过去两年我们一直在用文本 Token 和模型交互，但模型的多模态能力可能比我们想象的更有价值。文本是线性的、序列的、一维的。代码是结构的、嵌套的、二维的。

把一个二维结构硬塞进一维的 Token 流，本来就是一种妥协。

喝了口水继续看 PxPipe 的代码——它用了 Pillow 做渲染，用了 pygments 做语法高亮，整体不到 500 行。作者在 README 里说这只是一个"weekend hack"，但效果已经好到让人愿意认真对待。

如果这个方向继续演进——比如专门针对代码优化的视觉编码器、代码结构的 2D 位置编码——说不定未来的代码 AI 根本不用读 Token，直接看图就懂了。

行吧，先把今天的重构跑完。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）