2026 年还在用规则做视觉分类——quasivision 的选择说明了什么

反直觉的开局

2026 年，你随手截一张图扔给 ChatGPT，它就能告诉你上面有什么文字、哪些是按钮、这个界面该怎么操作。VLM 的”视力”已经好到让人忘了它本质上是在猜。

就在所有人都往上走——更大模型、更强推理、更通用的视觉理解——quasivision 往下走了。它的 UI 分类器不是 VLM，而是一组硬编码的几何规则：宽度超过画面一半就是 Block，边界框小于 48 像素且接近方形就是 Icon，高度 20-80 像素配宽高比 0.5-3.0 就是 Button。全是 if-else。

这件事乍看之下像是退步。但如果退一步想：在什么情况下，确定性规则比概率推理更好用？

三条线索

quasivision 的整个设计可以从三条线索理解，这三条线索互相关联，指向同一个结论。

线索一：成本和延迟

用 VLM 做一次截图分析，假设用的是 GPT-4V，一张 1080p 截图大约消耗 800-1500 个 image tokens，加上 prompt 和 response，单次调用成本在 $0.02-0.05 之间。延迟 3-8 秒。

假设一个桌面 Agent 以每 2 秒一帧的速度观察屏幕然后做决策，一小时就是 1800 帧。每帧走一次 VLM？成本 $36-90，延迟累加后 Agent 的反应速度比人还慢。

quasivision 方案：每帧走本地管线，主线程 300ms 内完成 UI 检测，OCR 和物体检测在后台并行。零 API 成本。Agent 仍然需要 LLM 来推理和决策，但 LLM 收到的输入不再是 150KB 的 JPG，而是一段 800 字节的结构化文本：

Root (1280×800)
├── Block: 导航栏
│   ├── Text: "首页"
│   └── Button: "登录"
├── Block: 搜索结果
│   ├── Block: 结果项1
│   │   ├── Text: "quasivision：给 LLM 装上一双廉价的眼睛"
│   │   └── Text: "基于 Rust 的伪视觉理解工具..."
│   └── Block: 结果项2
...

LLM 不需要”看见”屏幕。它读这段文本就够了。视觉感知被从推理链中剥离出来，变成了一个前置步骤——廉价、快速、零信息的确定性提取。

线索二：确定性的价值

VLM 分析同一张截图，两次给出的坐标可能差几个像素，描述方式可能不同，甚至可能遗漏元素。对大多数聊天场景，这完全没问题。但如果你在写一个 UI 自动化脚本——“点这个按钮，坐标 [x,y]“，差一个像素可能就点不到。

quasivision 的连通域分析加几何规则分类，每次运行对同一张输入产生完全相同的输出。这是确定性管线的核心优势：不是”我猜这是按钮”，而是”检测到一个边界框满足 Button 的几何条件，坐标就是这些”。

这种确定性对三类场景尤其重要：

自动化测试：需要断言”页面上有 3 个 Button、1 个 Input”，每次 CI 跑出来的结果必须一致
Agent 工具链：Tool 的返回值必须可靠，LLM 本身已经很能”猜”了，工具层不该再引入不确定性
批量处理：1000 张截图做 OCR，每张结果应该只取决于图片本身，不取决于模型今天的状态

线索三：集成的便利性

一个 Python 视觉工具被集成到系统层，需要 Python 运行时、CUDA 或 Metal、正确处理各种依赖冲突。一个纯 Rust 工具是一个静态链接的二进制文件，拷贝过去就能跑。集成成本为零。

这是 quasivision 选择 Rust 的真正原因——不是为了比 Python 快几毫秒，而是为了作为一块砖被塞进任何项目中。做成 MCP Tool、嵌入桌面 Agent、放进 CI pipeline、打包成 npm 命令行工具——都只需要一个二进制文件。

8 步管线的设计取舍

翻开 main.rs 的核心循环，8 个步骤中埋着几个值得琢磨的设计选择：

OCR 和物体检测放在后台线程，不阻塞主流程。 因为 OCR（PaddleOCR ONNX）和 YOLOE-26n 推理是耗时最长的步骤，但它们对 UI 组件检测没有依赖——你在识别的文字最终要合并到 UI 树里，但 UI 树本身的构建不需要等文字识别完成。所以主线程先跑完 CCL → 矩形检测 → 几何分类 → 颜色提取，最后 handle.join() 收结果。

文本过滤的三层逻辑。 长文本（>5 字符，宽度大于 2 倍高度）不受高度限制——因为一个标题可能字号很小但很长，按高度过滤会误杀。空内容删掉。单字符的标点符号删掉，但单字符的数字和中文保留。这个策略处理了 OCR 最常见的”把噪声当文字”问题。

孤儿文本的容器合成。 如果你处理的是一张手写笔记的照片，OCR 识别出了文字段落，但没有 UI 组件包裹它们。synthesize_text 会为这些文本自动生成 Block 容器，让输出始终保持树状结构。

输出：为什么不需要 `--format` 参数

大多数 CLI 工具会给你一堆格式选项：json、yaml、toml、compact、pretty。quasivision 的 CLI 只有一个输出格式——tree。代码里有一句话始终没变过：

输出格式固定为 tree

但同时，lib.rs 暴露了 6 种序列化函数：to_json_string、to_compact_string（-50% tokens）、to_ai_json_string（坐标归一化 0-1000）、to_tree_json_string、to_tree_text_string、to_text_summary。

这意味着格式选择权不在 CLI 用户手里，而在库调用者手里。CLI 是给”一次性使用”的——跑完看结果。库是给”程序化使用”的——Python binding 可以按需调用不同的序列化格式。这种分层设计避开了 CLI 参数膨胀，同时保持了库的灵活性。

附带一个被很多人忽略的输出字段：prominence。它是一个 0.0-1.0 的视觉重要性分数，基于面积、类别类型和颜色对比度计算。对于 Agent 场景，这个分数可以用来做”先关注哪个元素”的排序。比如视觉上最突出的 Button 先考虑。

适用的场景和清晰的边界

最好的工具知道自己的边界在哪里。以下场景 quasivision 占优：

场景	为什么
截图转文字	本地 OCR，批量跑零成本
UI 结构提取	像素级坐标 + 确定性的组件分类
Agent 视觉感知层	把图片 token 换成文本 token，开一轮 Agent 循环
100 张 PDF 批量 OCR	`cargo run -- -i ./docs/ --recursive`
物体列表提取	YOLOE-26n 860 类物体，带父子层级和坐标

以下场景 VLM 占优：

场景	为什么
分析图表趋势	需要数值理解和推理
理解设计风格	需要语义和审美判断
描述照片内容	需要自然语言生成和上下文关联
回答”这个界面有什么问题”	需要综合判断

两层架构：感知与推理分离

从 AI Agent 架构的角度，quasivision 提出了一种分层方案——不再把所有负担堆给 VLM。

传统路线：截图 → VLM（既做感知又做推理）→ 动作。一张图承载了所有信息，VLM 一个人干了所有活。

分层路线：截图 → quasivision 本地解析（感知层）→ 结构化文本 → LLM 推理（决策层）→ 动作。

感知层只做”看见”——把视觉信号转化为精确的结构化数据。决策层只做”思考”——在结构化数据上推理下一步该做什么。

两层分离后，各自可以独立优化。感知层不需要变聪明，只要能更准确地提取信息。决策层不需要变”眼睛”，只需要更善于理解结构化上下文。好的架构不是让一个组件干所有事，而是让每个组件只干自己最擅长的事。

一行命令

git clone https://github.com/WeiChens/quasivision.git && cd quasivision
cargo run -- --input demo/ui.jpg

首次运行自动下载模型（不到 20MB）。国内用户：

set QUASIVISION_MODELS_URL=https://hf-mirror.com/WeiChens/quasivision-models/resolve/main

v0.2.2，MIT 许可，22 次提交。一个在 2026 年选择”往下走”的项目——不是因为技术能力不够，而是因为看懂了那条被所有人忽视的需求：在 Agent 时代，精确的感知比模糊的理解更稀缺。