为什么会做这次横评
GWMS 里有一个「拍照退件面单 → 识别退件基本信息」的功能。现在的痛点是：拍照之后，识别这一步的响应速度很慢。
于是我从多个平台各拿了一个 API Key，用相同的提示词、相同的调用方式做一次横向评测。这个任务我同时交给了 DeepSeek Harness 和 Claude Code CLI，让两边各跑一遍、各出一份 HTML 报告。
我给两边的是同一句话：
请使用相同的提示词，相同的调用方式，访问../OCRvsLLM，里面的.env给出了多个大模型的API_KEY，调用它们完成识别，并用HTML输出一份详细报告。我要横向对比，上传速度，识别速度，识别结果是否一致；对了也列出图片的尺寸和上传内容的大小。下面把两份报告原样合并贴出来，先注明各是谁出的。报告部分我没有改动内容和格式。
报告一：DeepSeek Harness 出品
报告二：Claude Code CLI 出品
评价：差距还是很明显的
同样一句话，两份报告完全不在一个量级上。
第一，对「识别」的理解不一样。 DeepSeek Harness 把「识别」理解成「描述图片里有什么」，自己造了一个通用描述提示词（「请识别并描述以下四张图片的内容……」），然后拿 gpt-4o、claude-sonnet-5 这类对话模型跑了一遍。Claude Code CLI 则是先回到 GWMS 生产代码里，找到了线上真正在用的提示词——WmsReturnOrderServiceImpl#recognizeLabelFromImage——用那份「提取结构化 JSON 字段」的生产提示词去逐字段比对。生产要的是 customerCode、recipientRaw、trackingNo 这些字段，不是一段文字描述；这两道根本不是同一道题。
第二，交付的东西不一样。 我要的是「上传速度、识别速度、识别结果是否一致、图片尺寸、上传内容大小」。DeepSeek Harness 交了一张总表：6 家模型、耗时 + token + 一段文字摘要；图片尺寸和上传大小只写了一句「共 3.83 MB」，「识别结果是否一致」干脆没做。Claude Code CLI 交了 8 家模型、108 次调用：逐图逐字段打分（满分 24，按人工核对基准，而不是多数票），列出像素尺寸（608×1080）、原始文件 / Base64 / 实际请求体三档大小，还单独做了「各模型结果是否一致」一节，甚至顺手做了一组「转 JPEG / 缩尺寸」的对照实验。
第三，结论甚至会互相打架。 在 DeepSeek Harness 的报告里，deepseek-v4-flash-vision-exp 看起来一切正常（识别 14.21 秒）；在 Claude Code CLI 的报告里，它在两张倒置图上整图失败、只吐思考过程没有 JSON。原因就是口径不同：描述得头头是道，不代表结构化字段提取得对——而 PDA 现场拍照恰恰经常是倒的。
第四，能不能直接拿去用。 Claude Code CLI 给了一组按「改动小、收益大」排序的生产建议（customerCode 正则复核、运单号校验位、客户端转 JPEG 不缩尺寸、倒置兜底、改结构化输出……）。DeepSeek Harness 的报告只是把结果摊开，没有一句能指导改造的结论。
第五，它甚至把「为什么慢」的根因挖了出来。 横评做完之后，Claude Code CLI 又回头反编译了 gwms-common-ai:1.0.20，发现生产里 ModelType.QWEN_VL_MAX 这个枚举名有误导——实际下发给阿里云的模型串是 qwen3.7-plus，不是 qwen-vl-max。也就是说，之前一直当「生产基线」的模型，线上根本没在跑。线上真正在用的 qwen3.7-plus，推理就要 8.07 秒、端到端 11.78 秒；换成 qwen-vl-max 后推理 2.88 秒（砍 64%），准确率同样是 94%。这才是「识别响应慢」的大头——而这是 DeepSeek Harness 那份报告连边都没摸到的。
差距还是很明显的。同样一句话，一个交上来的是「能看的摘要表」，另一个交上来的是「能直接指导改造的评测报告」，还顺手把生产环境里的坑给找了出来。这不只是模型强不强的问题，而是接到任务之后，有没有先去搞清楚：这个「识别」在生产里到底要输出什么、出错会怎样。