让 GLM 读长截图，TaoToken 只做 Key 分发

1. 客服工单长截图 OCR 的第一道坎：Key 分发与 Base URL

客服工单长截图 OCR 的第一道坎不是模型，而是 Key 怎么发。TaoToken 只做 Key 分发：先到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-intro 拿 Key，再把 Base URL 填为 https://taotoken.net/api；GLM 负责文本推理，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_source=taotoken_aicg_blog_end&utm_content=glm-ocr-key 看一眼模型列表和 Key 管理入口。注册、登录、创建 Key 都在这个站内完成，不需要去别的地方找。

拿到 Key 之后，记住两个东西：

• Base URL：https://taotoken.net/api
• Key 占位符：YOUR_API_KEY

Base 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(f"tiles/tile_{idx:03d}.png") idx += 1 print("tiles:", idx) PY

逐片 OCR：

paddleocr --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, encoding="utf-8") as fp: texts.append(fp.read()) result = "\n".join(texts) with open("ticket_text.txt", "w", encoding="utf-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_url="https://taotoken.net/api", api_key="YOUR_API_KEY", ) with open("ticket_text.txt", encoding="utf-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( model="glm-4.6", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt}, ], temperature=0.1, response_format={"type": "json_object"}, ) content = resp.choices[0].message.content print(content) usage = resp.usage.model_dump() print(json.dumps(usage, ensure_ascii=False, indent=2))

一次典型输出：

{ "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.toml，CC 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_KEY="YOUR_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是否被替换成真实 Key；Claude Code 看ANTHROPIC_AUTH_TOKEN，Codex 看TAOTOKEN_API_KEY；Python 脚本看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、限制字段、加temperature=0.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 URL，Key 管理也集中。对长期跑客服工单的团队来说，这是一次性投入。

9. 从半自动到全自动：客服工单流水线的落地清单

如果你准备把这条链路落地，可以按下面的清单推进：

1. 先到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-final 创建 Key，确认 Base URL 为 https://taotoken.net/api。
2. 用 curl 或模型对话页发一条纯文本消息，确认 Key 和模型名可用。
3. 在本地搭 OCR 环境，拿一张真实工单长截图跑切图、OCR、合并，检查ticket_text.txt是否完整。
4. 写 Python 脚本把 OCR 文本发给 GLM，强制 JSON 输出，记录prompt_tokens、completion_tokens、total_tokens。
5. 在 Claude Code 里配置settings.json，在 Codex 里配置config.toml，CC Switch 三件套只填 Base URL、API Key、Model，不要混用ANTHROPIC_*。
6. 把工单分类结果写回你的客服系统，人工抽检一批，确认 issue_type、order_id、error_code 的准确率。
7. 观察 Token 记录，优化 OCR 去重和 prompt 长度，控制单工单成本。
8. 明确边界：结构化截图走 OCR 加 GLM，审美和复杂视觉任务走原生多模态。

这条流水线的核心变化是：以前客服要替模型看图，现在工具替模型看图，模型只负责读文本、做判断。GLM 还是纯文本模型，但它不再被“看不了图”卡住。TaoToken 只做 Key 分发和 API 入口，不参与 OCR，也不改变你的业务逻辑。你拿到的是一条可复现、可审计、可计费的客服工单自动化链路。

如果你想先试模型对话，可以从这里进：https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-chat 如果准备长期跑客服自动化，建议看 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-plan 然后创建自己的 Key：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-key Claude Code 的配置细节可以对照文档：https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=glm-ocr-doc

把 Base URL 固定为 https://taotoken.net/api，把 Key 换成 YOUR_API_KEY，长截图 OCR 加 GLM 文本推理的链路就能跑起来。剩下的，就是根据你的工单量去调切图参数和 prompt 了。