99.3%压缩率：一个程序员如何用算法"骗过"15个大模型

一位开发者测试了15个主流大语言模型后，发现了一个反直觉的结论：让AI直接处理原始网页，是最贵的错误。

他的解决方案不是换更好的模型，而是把输入数据砍掉99.3%。最终架构比纯AI方案快10倍以上，成本降到可忽略。

第一堵墙：15个模型集体翻车

故事开始于一个典型场景。开发者想做一个网页数据提取工具，第一反应很"标准"——把页面扔给大模型，让它自己找数据。

然后现实给了他一巴掌。

一个普通商品列表页，原始DOM体积500-700KB。这意味着什么？按token计费的话，单页就要烧掉约15万token。等15-30秒才能拿到结果。遇到复杂页面直接撞上下文长度上限。

他在第一页就撞墙了。

测试名单很长：GPT-4、GPT-4o、Gemini 1.5 Pro、Gemini Ultra、Claude 3 Opus、Claude 3.5 Sonnet、Mistral Large、Llama 3 70B、Cohere Command R+，外加一批微调小模型。

结果出奇一致：没有模型能解决延迟问题。不是因为模型不够强，是因为他让模型解决了错误的问题。

核心发现：输入尺寸才是元凶

真正的问题不在模型能力，而在输入尺寸。

开发者做了一个DOM预处理器。效果：580KB → 4.2KB。压缩率99.3%。

输入变成4KB之后，每个模型都变快了。但更有趣的事情发生了——在这个尺寸下，重复模式变得肉眼可见。同样的结构重复20次、50次、100次：商品卡片、目录行、搜索结果。

他意识到一个关键问题：如果结构本身已经足够明显，为什么要花钱让模型去"发现"它？

于是写了一个启发式检测器。规则很简单：找重复的标签结构、识别列表容器、定位数据行。

AI的角色被重新定位——不是在600KB垃圾里找 needle，而是在已经定位好的4KB片段里做标注和格式化。这是200 token的工作量，不是15万。

速度对比很直观：纯LLM方案25-35秒，启发式+AI混合架构2-3秒。10倍以上的差距。

产品化：Clura的架构逻辑

这套方法变成了Clura，一个浏览器扩展形态的网页抓取工具。

工作流程被拆成两层：启发式引擎负责检测，AI负责标注。打开任意页面，Clura自动用启发式规则找出所有列表结构。用户选一个列表，选要的字段，秒级提取全部记录。

没有"描述你想要什么"的提示词工程。没有机器人训练环节。没有30秒等待。

关键洞察被总结成一句话：大语言模型（LLM）极其擅长理解"某物是什么意思"，但极其不擅长在600KB HTML里扫描"某物在哪里"。

后者是结构模式问题——而结构模式问题，正是算法擅长的领域。

可复用的方法论

开发者提炼出一个通用架构原则：不是"用最好的模型"，而是"用启发式方法把问题压缩到模型真正擅长的尺度"。

他特别指出，DOM预处理这一步 alone 就值得任何做LLM应用的团队借鉴。无论底层任务是什么，它能让每个模型更快、更便宜、更准确。

Clura的运行方式也做了针对性设计：检测完全在浏览器本地完成，没有服务器往返。这解释了为什么能做到"秒级"——网络延迟被剔除了。

产品形态是Chrome扩展，免费试用。模板功能支持快速回复FAQ或存储可复用片段。

为什么这件事值得关注

这个案例提供了一个清晰的成本锚点。15万token vs 200 token，差距是750倍。即使按最便宜的模型定价，这也是从"不可商用"到"忽略不计"的跨越。

更深层的信号是：AI应用层的竞争，正在从"模型能力"转向"问题拆解能力"。同样的GPT-4，喂600KB和喂4KB，产出质量和响应速度完全不同。

开发者社区里有个隐形成本很少被讨论——token浪费。很多团队把原始数据直接塞给模型，因为"这样最简单"。Clura的案例证明，前置做一层轻量处理，ROI可能高得惊人。

另一个值得注意的点是浏览器端计算。Clura把检测环节完全本地化，这不仅省了服务器成本，也省了网络延迟。对于需要实时交互的场景，这种架构选择可能是必选项而非可选项。

最后回到那个核心判断：LLM的理解能力+算法的扫描能力，这种分层架构可能是" messy real-world inputs "（混乱真实世界输入）的标准解法。不是用AI取代算法，而是用算法给AI减负。

99.3%的压缩率，750倍的token效率提升，10倍以上的速度差距——这三个数字定义了当前AI应用层的一个关键优化空间。