给 WorkBuddy 自定义模型搭建"本地 OCR 传图代理"的完整踩坑记录

作者：一个被"纯文本模型传不了图"折磨了一下午的 WorkBuddy 用户

标签：#WorkBuddy #自定义模型 #OCR #多模态 #踩坑记录

我用的 WorkBuddy 是自定义模型接入（在 ~/.workbuddy/models.json 里手动配置了 DeepSeek API 的 deepseek-v4-flash）。平时打字完全正常，但一传图片就报错：

当前模型暂不支持图片，请切换模型后重试

而用 WorkBuddy 积分模式的同一个 flash 模型却能传图。这让我非常困惑：同样的模型，为什么积分模式能传、API 自定义模式不能传？

于是我开始了一场"让 API 模式 flash 传图"的折腾之旅，中间踩了无数坑。这篇记录既是经验分享，也是给同样想折腾的朋友的避坑指南。

一、先搞清楚 WorkBuddy 是怎么判断"能否传图"的

WorkBuddy 主程序打包在 resources/app.asar（279MB 的 Electron 应用）。我把 asar 解包后，找到了图片拦截的核心代码（前端 main-content-core-*.js 约 11328 行）：

const hasImages = hasImage(contentBlocks);const modelInfoForSend = getModelSelectionForSend().modelInfo;if (hasImages && modelInfoForSend && !modelInfoForSend.supportsImages) {    toast.error(t("chat.imageNotSupported"));  // "当前模型暂不支持图片"    return false;   // 直接拦截发送}

结论：图片能不能发，只看模型对象上的 supportsImages 这一个布尔值。它来自模型配置（自定义模型读 models.json，积分模型由后端下发）。

坑 1：我以为改 models.json 里 supportsImages: false → true 就完事了。改完前端确实不拦图片了，但打字也开始报 400！

二、为什么改 supportsImages=true 后"打字也报错"

继续深挖代码，发现 supportsImages 是个复合开关，同时控制两件事：

1. 前端放行图片（上面的拦截判断）

2. 发送侧的消息格式（CLI 的 codebuddy.js 里）

if (model.tags?.includes("custom") && !model.supportsImages && Array.isArray(messages)) {    // 把 content 数组压平成纯文本字符串发给 API    message.content = textParts.join("\n");}

· supportsImages = false（默认）→ WorkBuddy 把消息压平成纯文本字符串 → DeepSeek 纯文本模型能正常处理 → 打字 OK，但前端拦图片

· supportsImages = true → WorkBuddy 认为这是多模态视觉模型 → 消息保留多模态数组格式 [{type:"text"...}] → DeepSeek 纯文本 API 不认这个格式 → 400 报错（连打字都挂）

坑 2：这两个功能绑死在同一个开关上，全库搜索不到独立的 supportsVision / capabilities 字段可以拆分。我在 279MB 的 app.asar 里翻了个底朝天，确认没有别的开关。

三、我的"本地 OCR 代理"方案（以及它为什么最终放弃）

既然 DeepSeek flash 是纯文本模型，那思路就变成：不让 flash 直接吃图片，而是中间加一层——本地 OCR 识别图片 → 转成文字 → 再喂给 flash。

我用 Python 写了一个本地代理服务（http://127.0.0.1:9123），逻辑：

# 收到 WorkBuddy 的多模态数组# 1. 遇到 image_url 就用本地 winocr 识别成文字# 2. 把所有内容压平成纯文本# 3. 转发给 DeepSeek API

然后改 models.json 把 url 指向本地代理：

{  "id": "deepseek-v4-flash",  "url": "http://127.0.0.1:9123/v1/chat/completions",  "supportsImages": true}

实测结果：单测全通（打字、传图都能 200），但一接入 WorkBuddy 就翻车——间歇性 400 / 502 / 空回复。

坑 3（最大的坑）：WorkBuddy 对自定义模型不做上下文压缩！它每次请求都会带上全部对话历史——实测单次请求 700+ 条消息、4MB+ 的 payload。这个规模远超 DeepSeek V4-Flash 能稳定处理的极限，所以时好时坏。

这个结构性瓶颈，任何代理方案都绕不过去——除非改 WorkBuddy 主程序（279MB asar 重打包 + 签名校验，基本不可行）。

1. 纯文本模型（DeepSeek V4-Flash）就是不能传图，这是模型能力边界，不是 WorkBuddy 设置问题

2. 想让自定义模型传图，靠改 supportsImages 没用——它会让打字也挂

3. 本地 OCR 代理思路可行，但被"WorkBuddy 自定义模型不压缩上下文"这个结构性瓶颈卡死

4. 正确用法：传图就切 WorkBuddy 内置的多模态模型（如 GLM-5v-Turbo），打字/分析用 flash，各用所长

五、给同样想折腾的朋友的 3 条避坑建议

1. 先抓包再看代码：想给自定义模型做代理，先看 WorkBuddy 实际发的请求体有多大——我要是先抓包看到 4MB payload，就不会浪费时间写代理了

2. supportsImages 是复合开关：不要指望它能单独放行图片，它是"多模态模型专属"的标记

3. 文件操作用 Python：Windows 上 PowerShell 管道删文件、Bash 的 cp 都可能被安全策略拦，Python 最稳

如果你也在 WorkBuddy 自定义模型上传图这件事上踩过坑，欢迎评论区交流。如果这篇文章帮到了你，点个赞让更多人看到～

开发工具

人工智能

后端

WorkBuddy自定义模型传图踩坑记录：揭秘supportsImages复合开关机制，分析本地OCR代理方案失败原因。解决自定义模型无法传图问题，提供3条实用避坑建议，帮助用户正确使用多模态模型与纯文本模型搭配方案。

WorkBuddy 

DeepSeek

Windows

Python

文字识别限时特惠，新用户0.5折起


WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

给 WorkBuddy 自定义模型搭建"本地 OCR 传图代理"的完整踩坑记录

给 WorkBuddy 自定义模型搭建"本地 OCR 传图代理"的完整踩坑记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐