1. 客服工单长截图 OCR 的第一道坎Key 分发与 Base URL客服工单长截图 OCR 的第一道坎不是模型而是 Key 怎么发。TaoToken 只做 Key 分发先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-intro 拿 Key再把 Base URL 填为 https://taotoken.net/apiGLM 负责文本推理OCR 工具负责把长图转成文本。这个分工听起来简单但真正落到客服工单自动化里效果非常直接。我们团队每天要处理大量用户上传的截图支付失败截图、订单状态异常截图、聊天记录长图、后台报错堆栈截图。这些图片经常是 2000×15000 像素的长图用户直接把手机滚动截图甩进工单前后不写一句话。以前的做法是客服人工看人工摘录订单号、错误码、时间再手动分类。现在我们把流程拆成两段本地 OCR 工具先把长图切成文本GLM 只负责读文本、做分类和摘要。为什么要拆因为纯文本模型看不了图。GLM 的强项是中文文本推理、意图理解、结构化抽取它不是多模态模型不会因为你把 PNG 塞进消息里就自动识别像素。硬要让它看图只会得到一句“我无法处理图片”。但如果你先把图片翻译成文本GLM 就能像处理普通工单文本一样处理它。更关键的是消耗 Token 的是 GLM 的文本推理不是 OCR。OCR 在本地跑不占用模型 Token。这样成本可控链路也清晰。TaoToken 在这条链路里的位置很明确它不碰 OCR不替你决定切图策略也不改你的业务逻辑。它做的是 Key 分发和 API 入口。你从官网拿到 Key把 Base URL 统一填成 https://taotoken.net/api后面无论是 Python 脚本、Claude Code、Codex 还是 CC Switch都走这个入口。模型调用记录、Token 消耗、Key 管理都在同一层完成。对客服工单自动化这种需要长期跑、需要看账单的场景来说这种“只做分发”的定位反而更省心。2. 为什么不让多模态模型直接读图把 OCR 和文本推理拆开很多人第一反应是既然 GLM 看不了图那就换一个多模态模型不就完了在 demo 阶段可以在客服工单自动化里不一定划算。第一多模态模型的调用成本通常高于纯文本模型。客服工单截图里有大量重复信息同一张支付失败截图不同用户反复上传同一段报错日志被截成三四张长图。如果每次都让多模态模型做视觉理解你付的是视觉推理的钱。但如果先用 OCR 提字再让 GLM 做文本分类你付的是文本推理的钱。对于“提取订单号、识别错误码、归类问题类型”这类结构化任务文本推理完全够用。第二私有化部署和成本敏感场景里多模态模型的显存占用、推理延迟、部署复杂度都是硬约束。OCR 可以本地 CPU 跑也可以用轻量模型GLM 文本推理走 API按 Token 计费。两段拆开之后每一段都可以独立优化。OCR 识别率不够就调切图重叠和语言参数GLM 分类不准就改 prompt 和 few-shot 示例。你不需要为了“看图”这一个需求把整个模型选型换掉。第三客服工单自动化需要可审计。多模态模型直接看图输出往往是一段自然语言描述很难追溯它到底看到了什么。而 OCR 先把图片转成文本文本落盘你可以 diff、可以检索、可以人工复核。GLM 再基于这份文本做推理Token 记录也清楚prompt_tokens 里是 OCR 文本completion_tokens 里是分类结果。出了问题你能定位是 OCR 漏字还是 GLM 理解偏了还是 prompt 写错了。这种可解释性在客服场景里比“模型看起来更聪明”更重要。所以我们的结论是把视觉能力放在运行时工具里而不是硬塞进模型里。GLM 还是那个 GLM它不需要长出眼睛OCR 工具替它看它只负责读和想。这个思路不只适用于长截图 OCR也适用于前端 UI 还原、GUI 自动化、图片问答。能力不必长在模型参数里可以长在工具链里。3. 用 TaoToken 拿 Key官网、Base URL 与模型选择真正开始配置之前先把 Key 和 Base URL 固定下来。TaoToken 的入口在官网Key 也在官网控制台创建。你可以先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-key 看一眼模型列表和 Key 管理入口。注册、登录、创建 Key 都在这个站内完成不需要去别的地方找。拿到 Key 之后记住两个东西Base URLhttps://taotoken.net/apiKey 占位符YOUR_API_KEYBase URL 不要加 UTM也不要加多余路径。它就是 https://taotoken.net/api。很多 404 和 401 错误都是因为有人把 Base URL 写成了带斜杠、带/v1、带查询参数的地址。OpenAI 兼容客户端通常会自动拼接/chat/completions你只需要给到根路径。模型名怎么写如果你走 OpenAI 兼容接口模型名填你实际要用的 GLM 文本模型例如glm-4.6。如果你在 Claude Code 里用模型名也填同一个。TaoToken 负责把请求路由到对应模型具体可用模型以控制台和模型对话页为准。你可以先到模型对话页试一条消息确认 Key 能通、模型能回再进代码。一个最小验证命令如下curl -X POST https://taotoken.net/api/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { model: glm-4.6, messages: [ {role: user, content: 只回复TaoToken OK} ], temperature: 0 }如果返回正常说明 Key 和 Base URL 都没问题。接下来再把 OCR 文本接进来。注意这个 curl 只是验证文本推理不涉及图片。图片在本地由 OCR 处理GLM 只收到文本。4. 长截图 OCR 命令从工单长图到 ticket_text.txt长截图 OCR 最容易踩的坑是直接把整张超长图丢给 OCR 引擎结果中间漏字、顺序错乱、表格串行。更稳的做法是先把长图切成带重叠的切片逐片 OCR再按顺序合并。下面是一套可以本地复现的命令Python 和 PaddleOCR 组合适合中文客服工单截图。先准备环境python -m venv venv source venv/bin/activate pip install pillow opencv-python paddlepaddle paddleocr然后切图。假设工单长截图是ticket_long.png我们按 1600 像素高度切片上下重叠 200 像素避免文字被切断mkdir -p tiles ocr_out python - PY from PIL import Image import os img Image.open(ticket_long.png) w, h img.size tile_h 1600 overlap 200 idx 0 for top in range(0, h, tile_h - overlap): box (0, max(0, top), w, min(h, top tile_h)) tile img.crop(box) tile.save(ftiles/tile_{idx:03d}.png) idx 1 print(tiles:, idx) PY逐片 OCRpaddleocr --image_dir tiles/ \ --use_angle_cls true \ --lang ch \ --output ocr_out/合并文本并落盘python - PY import glob texts [] for f in sorted(glob.glob(ocr_out/*.txt)): with open(f, encodingutf-8) as fp: texts.append(fp.read()) result \n.join(texts) with open(ticket_text.txt, w, encodingutf-8) as fp: fp.write(result) print(result[:800]) PY跑完之后你会得到一份类似这样的文本结果[2026-09-07 10:23:11] 客服工单 #A19382 用户付款成功但订单显示未支付 截图内容 - 订单号20260907000123 - 支付流水PAY-8837261910 - 错误码ORDER_STATUS_MISMATCH - 建议操作核对支付回调重新同步订单状态这份ticket_text.txt就是后续给 GLM 的输入。注意到这一步为止你还没有消耗任何模型 Token。OCR 是本地计算切图、识别、合并都在你自己的机器或服务里完成。只有下一步把文本发给 GLM 做推理时才会产生 Token 记录。5. 把 OCR 文本交给 GLM客服工单分类与摘要的文本推理现在把ticket_text.txt送给 GLM。我们用一个 Python 脚本调用 TaoToken 的 OpenAI 兼容接口让 GLM 从 OCR 文本里抽取结构化字段并输出 JSON。这样客服系统可以直接消费不需要再解析自然语言。from openai import OpenAI import json client OpenAI( base_urlhttps://taotoken.net/api, api_keyYOUR_API_KEY, ) with open(ticket_text.txt, encodingutf-8) as f: ticket_text f.read() system_prompt 你是客服工单分类助手。 你只能输出 JSON不要输出多余解释。 字段 - issue_type: 问题类型如支付异常、订单状态、退款、账号、其他 - order_id: 订单号没有则写 null - error_code: 错误码没有则写 null - summary: 一句话摘要 - suggested_action: 建议客服动作 user_prompt f请从下面的 OCR 文本中抽取字段 {ticket_text} resp client.chat.completions.create( modelglm-4.6, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], temperature0.1, response_format{type: json_object}, ) content resp.choices[0].message.content print(content) usage resp.usage.model_dump() print(json.dumps(usage, ensure_asciiFalse, indent2))一次典型输出{ issue_type: 支付异常, order_id: 20260907000123, error_code: ORDER_STATUS_MISMATCH, summary: 用户付款成功但订单未更新支付流水存在, suggested_action: 核对支付回调重新同步订单状态 }Token 记录{ prompt_tokens: 436, completion_tokens: 98, total_tokens: 534 }这段记录非常关键。它告诉你消耗 Token 的是 GLM 的文本推理输入是 OCR 文本输出是分类 JSON。如果发现 prompt_tokens 太高说明 OCR 文本太长可以在 OCR 合并阶段做去重、截断无关行如果 completion_tokens 太高说明模型话太多可以收紧 system prompt强制 JSON 并限制字段长度。你还可以把这段脚本包成函数批量处理工单。每次调用都把 usage 写入日志按天汇总就能知道客服工单自动化的 Token 成本曲线。TaoToken 只做 Key 分发和请求路由Token 记账以模型返回的 usage 为准。6. Claude Code / Codex / CC Switch 配置三套配置不要混除了脚本很多人还会在 Claude Code、Codex 里直接调用 GLM 做文本推理。这里最容易出错的地方是配置混用Claude Code 用ANTHROPIC_*Codex 用config.tomlCC Switch 三件套是 Base URL、API Key、Model。不要把ANTHROPIC_*套到 Codex 上也不要把 Codex 的model_provider写进 Claude Code。先看 Claude Code。编辑~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: glm-4.6 } }这里三个字段分别对应Base URL、Key、模型。Base URL 仍然是 https://taotoken.net/api不加 UTM不加/v1。保存后重启 Claude Code让它读取新的 settings.json。再看 Codex。Codex 用~/.codex/config.toml不要用ANTHROPIC_*。配置如下model_provider taotoken model glm-4.6 [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后在 shell 里设置环境变量export TAOTOKEN_API_KEYYOUR_API_KEY注意Codex 读的是TAOTOKEN_API_KEY不是ANTHROPIC_AUTH_TOKEN。如果你把 Claude Code 的环境变量复制给 Codex通常不会生效还可能报鉴权错误。最后说 CC Switch 三件套。如果你用 CC Switch 在多个客户端之间切换把槽位按下面三件套填Claude Code 槽位 Base URL: https://taotoken.net/api API Key: YOUR_API_KEY Model: glm-4.6 Codex 槽位 Base URL: https://taotoken.net/api API Key: YOUR_API_KEY Model: glm-4.6三件套的本质是请求发到哪里、用什么身份、调哪个模型。客户端不同落地方式不同Claude Code 读ANTHROPIC_*Codex 读config.toml。CC Switch 只是帮你切换不改变底层规则。写完配置后用一个最小文本请求验证不要一上来就跑长 OCR 文本。7. 排障清单401、404、模型名、Base URL 和 Token 记录在客服工单自动化链路里排障要分两层OCR 层和模型层。先确认 OCR 文本是否合理再确认 GLM 调用是否正常。下面是我们踩过的坑和对应检查项。第一401 Unauthorized。通常是 Key 写错、Key 失效、或者把 Key 放错了客户端。检查YOUR_API_KEY是否被替换成真实 KeyClaude Code 看ANTHROPIC_AUTH_TOKENCodex 看TAOTOKEN_API_KEYPython 脚本看api_key参数。Key 只从 TaoToken 官网创建不要混用其他平台的 Key。第二404 Not Found。常见原因是 Base URL 写错。正确写法是 https://taotoken.net/api不要写成https://taotoken.net/api/v1不要带查询参数不要带 UTM。OpenAI 兼容客户端会自动拼/chat/completions。如果你手动拼了/v1/chat/completions有些客户端会变成双路径直接 404。第三模型名不存在。模型名要和 TaoToken 控制台或模型对话页显示的一致例如glm-4.6。不要凭记忆写glm-4、glm-4-plus、chatglm之类。先用最小请求试模型名再跑批量工单。第四Token 记录异常。如果prompt_tokens远大于预期检查 OCR 合并文本是否包含了重复切片。长图切分有重叠合并时要做去重或按行号裁剪。如果completion_tokens很高检查 system prompt 是否太松模型是否在输出解释文字。强制 JSON、限制字段、加temperature0.1都能压低输出 Token。第五OCR 文本乱序。长截图切分后合并顺序必须按文件名排序。如果切片命名是tile_1、tile_2、tile_10字符串排序会变成tile_1、tile_10、tile_2。用tile_001、tile_002这种零填充命名避免顺序错乱。第六不要在 OCR 脚本里直连生产数据库。客服工单自动化可以读截图、调模型、写日志但订单状态核验、退款操作这类动作应该由你本地或你的服务显式执行不要让模型直接操作生产库。GLM 只做文本推理输出建议动作执行权在你手里。8. 边界与选型结构化 OCR 够用审美类任务别硬上这套方案不是万能的。它适合“结构化看图”提取文字、识别错误码、还原字段、定位屏幕元素。长截图 OCR 就是典型的结构化任务。把图片转成文本GLM 做文本推理成本低、可审计、链路清晰。但它不适合“真·视觉理解”。比如判断一个 logo 的配色好不好看、分析海报的情绪氛围、理解复杂图表里的空间关系这些任务需要像素级视觉推理OCR 加文本模型替代不了。硬上只会得到一份文字描述然后让 GLM 猜结果不稳定。所以选型标准很简单如果你的看图需求是“把图里的字和结构变成可处理的文本”OCR 加 GLM 够用如果你的需求是“理解图像本身”那就老老实实用原生多模态模型。客服工单自动化里90% 的截图需求其实是前者用户不是让你欣赏图片而是让你读出订单号、错误码、时间、金额。这些信息 OCR 能提GLM 能判TaoToken 把 Key 和 Base URL 统一起来链路就跑通了。另一个边界是配置成本。Claude Code、Codex、CC Switch 各有一套配置规则第一次配会花点时间。但配好之后所有文本推理请求都走同一个 Base URLKey 管理也集中。对长期跑客服工单的团队来说这是一次性投入。9. 从半自动到全自动客服工单流水线的落地清单如果你准备把这条链路落地可以按下面的清单推进先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-final 创建 Key确认 Base URL 为 https://taotoken.net/api。用 curl 或模型对话页发一条纯文本消息确认 Key 和模型名可用。在本地搭 OCR 环境拿一张真实工单长截图跑切图、OCR、合并检查ticket_text.txt是否完整。写 Python 脚本把 OCR 文本发给 GLM强制 JSON 输出记录prompt_tokens、completion_tokens、total_tokens。在 Claude Code 里配置settings.json在 Codex 里配置config.tomlCC Switch 三件套只填 Base URL、API Key、Model不要混用ANTHROPIC_*。把工单分类结果写回你的客服系统人工抽检一批确认 issue_type、order_id、error_code 的准确率。观察 Token 记录优化 OCR 去重和 prompt 长度控制单工单成本。明确边界结构化截图走 OCR 加 GLM审美和复杂视觉任务走原生多模态。这条流水线的核心变化是以前客服要替模型看图现在工具替模型看图模型只负责读文本、做判断。GLM 还是纯文本模型但它不再被“看不了图”卡住。TaoToken 只做 Key 分发和 API 入口不参与 OCR也不改变你的业务逻辑。你拿到的是一条可复现、可审计、可计费的客服工单自动化链路。如果你想先试模型对话可以从这里进https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-chat 如果准备长期跑客服自动化建议看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-plan 然后创建自己的 Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-key Claude Code 的配置细节可以对照文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentglm-ocr-doc把 Base URL 固定为 https://taotoken.net/api把 Key 换成 YOUR_API_KEY长截图 OCR 加 GLM 文本推理的链路就能跑起来。剩下的就是根据你的工单量去调切图参数和 prompt 了。