一份 PDF，先转成图片，再交给 AI 识别，最后输出 Markdown。员工只是想拿到可编辑文本，后台却可能走完一条昂贵的多模态流水线。

据 404 Media 6 月 24 日报道，一段据称来自埃森哲内部会议的录音显示，公司发现部分 Token 消耗并非主要由工程师产生，而是来自非工程人员的日常操作。被点名的典型场景，正是 PDF 转 Markdown。

PDF 流程为何成了耗量大户

录音中，埃森哲智能体 AI 战略负责人 Justice Kwak 表示，从公司内部数据看，推动 Token 消耗的有不少非工程人员。

随后，客户业务负责人 Stuart Henderson 半开玩笑地问：是不是有人先把 PDF 转成图片，再转成 Markdown？他称这种操作是 Token 消耗大户。Kwak 回应，内部数据确实反映了这一点。

这段信息需要留一层余地。现有材料来自媒体转述和据称泄露的录音，完整会议背景、实际支出、文档数量及各流程占比都没有公开。它能说明埃森哲注意到了这个问题，不能证明普通员工已经成为公司 AI 账单的“罪魁祸首”。

技术机制倒不难理解。

PDF 主要服务于固定版式展示，并不天然适合机器读取。同样是 PDF，后台处理路径可能完全不同：

PDF 类型与处理方式模型实际要做的事成本与限制
原生文本 PDF 直接抽取提取文字，再交给语言模型整理通常最省，但复杂表格和阅读顺序可能出错
扫描 PDF 先做 OCR识别文字，再生成 Markdown成本增加，模糊页面、公式和小字容易识别错
页面转图片后交给视觉模型同时理解文字、版式、表格和图形输入更重，但适合复杂排版和图表
所有页面统一转图片并反复处理每次重新理解整份文档最容易浪费，重复运行还会继续叠加账单

文字模型按输入和输出 Token 计费。图片交给多模态模型后，也会按厂商规则转换成视觉输入或按图像规格收费。文档越长、分辨率越高、重复调用越多，成本越难控制。

输出 Markdown 本身也要消耗 Token。若同一份文件被多人重复上传，系统又没有缓存，企业等于反复购买同一次识别结果。

员工只是沿着工具铺好的路走

把问题概括成“普通员工不会用 AI”，很省事，也很不公平。

大多数员工没有理由知道一份 PDF 是原生文本、扫描件还是复杂版式。他们面对的往往只有一个上传按钮。点击之后走 OCR、视觉模型还是文本解析器，应由产品和平台决定。

工程师通常更了解上下文长度、模型价格和调用次数，也更容易发现异常。财务、法务、咨询和运营人员则长期面对合同、报告、研报、扫描附件。他们使用文档 AI 的频率高，却很难看到每次操作背后的成本。

“工欲善其事，必先利其器。”落回这件事，就是企业不能一边提供没有成本提示的万能入口，一边责怪员工点得太勤。

更合理的产品应当自动分流：

  • 能直接提取文本，就不要先渲染成图片。
  • 扫描件先走 OCR，识别置信度不足时再调用视觉模型。
  • 图表、复杂表格和手写内容，才交给多模态模型兜底。
  • 相同文件和相同结果尽量缓存，避免重复付费。

这里也有现实约束。强行把所有 PDF 都送进廉价文本解析，会丢掉版式、图表关系和表格结构。视觉模型贵一些，却可能减少人工校对。企业要算的是完整任务成本，而非只盯着每次调用价格。

数据安全同样不能漏掉。合同、客户材料和内部报告经过 OCR 或外部模型 API 时，文档被传到哪里、保留多久、生成的中间文件由谁访问，都要进入采购和合规检查。便宜但不可控的处理链路，未必真便宜。

AI 企业化，正在补云计算的旧课

这件事很像早期云计算。

云服务刚进入企业时，开服务器变得容易，账单也迅速变得难看。后来才有资源标签、部门归因、预算告警、自动关停和 FinOps。技术没有退潮，只是从“能不能用”进入“谁在用、为何用、花得值不值”。

生成式 AI 正在重复这段历史。模型价格会下降，缓存和推理效率也会改善，但单位成本下降经常带来更多调用。便宜一点，不等于总账单自然下降。

我更在意企业接下来是否做三件具体的事：能否把费用定位到应用和工作流，而非笼统归到某个员工；能否根据文档类型自动选择模型；能否让业务部门看到预算、质量和数据去向。

如果你负责企业 AI 采购，下一份合同不该只比较模型单价。用量面板、预算告警、缓存策略、文档路由和数据保留条款，都会直接决定真实成本。

如果你是每天处理 PDF 的业务人员，更现实的变化可能是工具入口被统一：公司会限制随意调用高价视觉模型，也可能要求优先使用批准过的文档解析流程。这会多一道规则，却比月底收到一张没人说得清的账单更合理。

埃森哲录音里最有价值的信息，不是“谁吃掉了 Token”。它提醒企业，AI 工具已经从演示台走进办公桌。按钮可以做得很简单，账单和责任不能继续藏在按钮后面。