今天看小米给opencode fork了个mimocode,我用它试着配合我的浏览器截图插件 利用mimo识图的功能 综合的测试一组提示词 创建我的世界 的 h5小游戏 ， 提示词是 ： 你是一个顶级的资深游戏开发者。请为我使用单 HTML5 和 Canvas（或 Three.js）编写一个《我的世界》克隆版。请包含以下核心功能： 1. 一个基于柏林噪声（Perlin Noise）生成的无限或可滚动的 3D 地形。 2. 第一人称视角，支持使用 WASD 移动和鼠标环视。 3. 支持至少 3 种方块类型（如：泥土、草地、石头等），并支持鼠标左键破坏方块，右键放置方块。材质要尽可能还原。 4. 要有一个内置的、极其丰富的神话幻想中的建筑和地形等，由你自行设计。 结果mimo做得不太行 不过比deepseek v4 flash好 如图 这是mimo v2.5的 这是deepseek v4 flash的 但我莫名其妙发现 mimo视觉似乎有问题 当我朋友用gemini 3.5flash 识别这个图片 都得到正确答案： 66666发现我偷懒是吧 但是给大家看看mimo 当前已经尝试到第四轮了 依然是没有完整的做出来 和claude比还是癞蛤蟆吃天鹅肉了，当然我只是玩玩看。 （我的opencode是自己魔改的，系统提示词是mimo的） 4 个帖子 - 4 位参与者 阅读完整话题
识图也识不了 完全看不懂写的啥 一脸蒙蔽 2 个帖子 - 2 位参与者 阅读完整话题
最近配了个Hermes，想着跑简单的本地模型，显卡是4070laptop，想要个能识图的跑快点的本地模型，求佬们推荐 9 个帖子 - 5 位参与者 阅读完整话题
不知道大佬们在使用cursor都是怎么实现发送图片自动切换到识图模型再自动切回deepseek-v4-pro的 1 个帖子 - 1 位参与者 阅读完整话题
目前我一直是使用deepseek的api接入claudecode中去使用的，但是苦于没有识图功能，正好看到有一个佬友的项目，使用其他模型的api来给deepseek增加识图反馈，链接如下 [开源]Visual-Enhancement-mcp,一个增强cc cx识图能力的mcp 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI 生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出 最近在c… 然后我就去尝试了一下，使用阿里百炼平台的qwen3-vl-plus作为识图模型 首先在ccswitch中配置mcp 类型选择stdio，MCP标题自定，命令选择npx 然后输入如下参数，apikey要自己填写 -y mcp-vision-server –api-base-url https://dashscope.aliyuncs.com –api-path /compatible-mode/v1/chat/completions –api-key sk-114514vivo50kfc –model qwen3-vl-plus 之后点击应用配置就好了，注意启用到应用给claude勾选上 然后deepseek就应该可以识图了，可以输出/mcp检查一下 但是有一个问题，就是在文件夹中测试，将文件的图片名称告诉deepseek，并不能顺利调用mcp ai查询了一下，应该是会默认使用内置 Read 工具去读取图片，可以在ccswitch中加一个提示词 简单写一下工作规则 ## 图片读取规则 当看到 [Image #N ] 占位符时，说明有图片被拖入但模型无法直接读取。按以下顺序查找，找到后立即用 vision_analyze 或 vision_ocr 分析，不要停下来问我路径： * 1. 先检查当前工作目录下最近生成的图片（temp_*.jpg、UUID 格式的 .png） 2. 再检查 C:\Users\lenovo\Pictures\Screenshots\ 下最近修改的图片文件 3. 按文件修改时间倒序排列，取最新的那张就是刚拖入的图片 用户也可以直接发路径，例如：看这张图 C:\Users\lenovo\Desktop\xxx.png 这样再测试就行了，虽然不知道为什么会有红色报错 佬友要是有什么其他方法或者改进方案欢迎来讨论 1 个帖子 - 1 位参与者 阅读完整话题
Snippai 0.3.0 本次更新功能包括： 1 、更智能的 Auto 自动模式，目前 Auto 模式现在会返回多个候选项，并支持候选快速切换预览 2 、支持自定义 prompts （欢迎各位尝试和分享好用的 prompts ） 3 、支持使用系统自带的截图工具进行截图 4 、支持自定义模型服务提供商 （强烈建议各位自定义自己的模型服务提供商已获得最佳体验） 5 、支持禁用快捷键 6 、允许设置默认自动复制识别结果还是截图本身 7 、支持截图历史记录保存（测试，后续可能会有大更改，请不要依赖此功能保存重要信息，可能会在后续版本更新中丢掉历史截图） 8 、新增 日程 识别/导出能力 9 、新增拖拽图片分析：可以直接把图片拖入软件进行识别。 10 、新增本地打开图片文件支持：支持通过系统右键菜单分析图片。 11 、UI 界面整体重构，添加更多动画细节 12 、支持更多的操作系统和处理器架构 下载地址： https://snippai.de/ 0.3.0 版本主题曲： 《 Snippai：灵感不坠悬崖》
本次更新功能包括： 1、更智能的Auto自动模式，目前Auto 模式现在会返回多个候选项，并支持候选快速切换预览 2、支持自定义prompts（欢迎各位佬友尝试和分享好用的prompts） 3、支持使用系统自带的截图工具进行截图 4、支持自定义模型服务提供商**（强烈建议各位佬友自定义自己的模型服务提供商已获得最佳体验）** 5、支持禁用快捷键 6、允许设置默认自动复制识别结果还是截图本身 7、支持截图历史记录保存（测试，后续可能会有大更改，请不要依赖此功能保存重要信息，可能会在后续版本更新中丢掉历史截图） 8、新增 日程 识别/导出能力 9、新增拖拽图片分析：可以直接把图片拖入软件进行识别。 10、新增本地打开图片文件支持：支持通过系统右键菜单分析图片。 11、UI界面整体重构，添加更多动画细节 12、支持更多的操作系统和处理器架构 3 个帖子 - 2 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI 生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出 最近在cc 和cx使用第三方模型的时候会出现一个问题，就是如果有些模型不支持识图的话，还得去别的地方把图像结果识别出来，再粘贴给cc cx或者opencode用，这样可能用的时间比较长，还比较繁琐。 然后我就自己vibing code了一个mcp 安全性：运行在本地，不会泄露重要信息和key 需要准备一个多模态识图能力的小模型，把这个小模型配置上去即可，然后就可以在cc cx中直接调用mcp，进行快速的开发了。 项目地址： GitHub - goehou/Visual-Enhancement-mcp: MCP stdio server for image recognition via an existng vision model · GitHub 欢迎各位佬提出意见，谢谢！ 1 个帖子 - 1 位参与者 阅读完整话题
想将公司项目构建成有Agent开发框架，目前佬提供的思路是用Graphify构建知识图谱 1 个帖子 - 1 位参与者 阅读完整话题
小米多模态模型拉闸了，昨天还能用得好好的，天才识图员陨落 3 个帖子 - 2 位参与者 阅读完整话题
我想做个简单的word文档检查工具，里面有文字也有图片。本来想用ds的，但是ds的识图模型还没出，不能检测图片内容是不是有问题。大家有什么推荐的国模么？ 12 个帖子 - 7 位参与者 阅读完整话题
有没有大佬有好用的自动点击软件，方便游戏做每日 识图点击，带判断的，判断界面是否正确再进行下一步点击这种的 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 纯vibe coding出来的一个全局划词助手工具。之前用cherry studio，很喜欢划词助手功能，但是cs又有点太重了，有时候划词快捷键按半天没反应。所以自己写了个单独轻量的划词助手工具。 以下为更新日志： 更新了截图功能，可以进行ai识图，钉在桌面上，调节大小和透明度，以及标注图片。（当成一个纯截图工具个人感觉也不错） 更新了追问功能，划词或者截图识别后，可以在结果窗口里继续追问ai。 github.com GitHub - zcx960/AIA-selection-assistan: 轻量级系统全局ai划词助手，支持自定义大模型API，多种划词模式 轻量级系统全局ai划词助手，支持自定义大模型API，多种划词模式 截图： 1 个帖子 - 1 位参与者 阅读完整话题
有一个图片，都是内容，需要整理成表格，使用了ds，豆包，Cursor 都不理想，有佬搭把手吗？ 图片地址： https://www.bjhdedu.cn/gongkai/tzgg/202605/t20260507_91726.html 7 个帖子 - 4 位参与者 阅读完整话题
如图，这个项目最近在github上还挺火的，有佬亲身体验过吗 3 个帖子 - 3 位参与者 阅读完整话题
如图我要为笼子做一个罩子， 罩子需要开窗，商家需要位置。 我跟商家说 左右和右边正面各一个窗 ，商家问我： 前面的窗户要开在哪个位置。 这还能有第二个位置吗 down_face:，于是我打算让AI P一下图，把窗户的位置用框选中。 但是发现 AI似乎也无法区分正面，豆包、元宝、千问都不行。 豆包 元宝 千问 最终没办法，我只能通过 二重定位 才解决： 将： 左右和右边正面 各一个窗，改成 左右和左右中间靠右的正面 各一个窗，才解决。 是我的表述有问题吗，我觉得左右和右边正面各一个窗应该只有一种可能啊，怎么会造成这种情况。 2 个帖子 - 2 位参与者 阅读完整话题
周五晚上睡觉窗户没关紧，周四起床坐在电脑旁边，突然脚下长猫了，哄出去后，又钻进来，跑到床底下，哇靠，一窝子，也是被讹上了。。。 对比了deepseek、qwen、和doubao的三个识图，发现豆包还是得力的。 都听说人从deepseek跳到其它大厂，我希望像其它人才也能跳到deepseek。 4 个帖子 - 4 位参与者 阅读完整话题
之前一直开发的是CLI，这两天要搞个带GUI的小工具，现在就倒在了多模态上了。 6 个帖子 - 3 位参与者 阅读完整话题
deepseek多模态咋没消息了，不仅web端没有全面上线，api也还没有，不包括2api出来的。cc里用不能识图感觉好麻烦呀，我已急哭 。 5 个帖子 - 4 位参与者 阅读完整话题
<1> 背景 自动化测试代码维护这行干了挺久，以往基本是在和内部框架打交道，以往工作实属不难，只能说测试以及Debug比较耗时间精力 后来上面也想与时俱进一下，就想着结合AI搞点辅助我们工作的东西，想法是美好的 团队里有一套长期演进的内部工程体系，配置、脚本、规则和经验散在不同地方不同人。 新人要改一个东西，有时要问老同事；老同事也不一定每次都记得准，只能继续翻文件、搜历史、看代码。 于是很自然地想到：那就做一个 AI 知识库吧。 最初的预期很朴素： 把文档、规范、经验整理进去 用户用自然语言提问 系统检索相关知识 大模型组织答案 听起来没毛病，甚至很符合最初大家对 RAG 的想象。 但真正落地后才发现，内部业务知识和互联网公开文档完全不是一回事。 公开文档通常是"解释型"的：这个 API 怎么用、这个参数是什么意思、底层模块解释等。 我们的内部问题更多是"操作型"的：我要改一个现有流程、调整一个规则、关闭一个子项、增加一个步骤、定位一个历史遗留逻辑。 这两类问题看起来都叫问答，但需要的系统能力完全不同。 所以问题不是"能不能用 AI"，而是"怎么让 AI按既定思路来理解"。 本地部署ai以及在vscode基础上做一个自己的业务汇总软件再基于cline改个有基础agent功能的插件，细节不赘述。 <2> 第一阶段：上了 Dify 当时的想法 Dify 嘛： 文档丢进去 切 chunk 做向量 用户问问题，相似度召回 AI 回答 实际效果 各类实际术语听不懂 AI拿到项目不知道从何开始，直接一顿召回一顿搜本地项目文件，实际各种答非所问完全靠大模型自己发挥 Dify 这套方案适合：文档类问答，知识相对固定，用户问法相对规范，需要一直自我调整 我们的问题是：业务实操类，问法千奇百怪，业务理解需要特定思路。 其实换个说法就是：把人对这项目各方面的理解思路等等抽成skills哈哈 但是细调用Dify软件就很不方便了，索性放弃Dify <3> 第二阶段：自建路由 核心思路 先听懂意图，再谈检索 。 这一步其实不是先研究模型，而是先把自己平时遇到的需求拆开。 先把这些常见业务动作分出来，再针对每一类动作设计不同的处理路线。 然后再兼容用户真实问法。中文、英文、缩写、符号、口语表达都要算进去。如果不先统一到同一个意图，后面检索再准也没用。 最开始当然也有关键词规则，后来逐步加上 embedding 和语义分类。简单说，就是不只看用户用了哪个词，还要看这句话整体更像哪类需求。 为了提高稳定性，又加了一层小模型兜底。当前面的规则和语义分类都不够确定时，再让小模型辅助判断一次。它不是负责最终回答，而是负责把问题分到更合理的路线里。 再往后，就是把我们对项目的理解、业务维护经验、常见判断逻辑整理进 RAG。这个过程有点像把人的经验拆成一组组 skills：每类问题都有自己的判断方式、需要看的材料、不能踩的坑。 但它又不完全等同于传统 skills。传统 skills 分散在各处，后面维护起来容易散；RAG 这边有一个相对集中的知识入口，可以单独调路由，也可以单独调知识内容。对这种业务落地场景来说，反而更好维护。 <4> AI不走原定路线 路由做完后，又遇到一个很典型的问题：AI 有时不按你设计好的路线走。 很多需求其实只要进入对应路由，把输入拆好，再查对应知识，就能稳定完成。但模型有时会"觉得自己能行"，上来就直接开始自己读文件、猜结构、自己组织答案。 还有一种情况是多轮对话。用户第二句明明是在补充上一句，打个比方比如"那把它改小一点"，模型却把它当成一个全新的问题处理，完全不管历史上下文里的"它"是谁。 这类问题光靠提示词里说"请优先走 RAG"是不够的。因为模型一旦进入自由发挥状态，就很难保证每次都守规矩。 后来做法变成：先检测当前项目是否属于我们已知的业务项目。如果是，就在底层强制加规则，让它优先走固定 RAG 路线，而不是随便读文件和自由发挥。 这样做以后，系统不一定一下子变得非常聪明，但至少变得可诊断了。答错的时候可以看出来：是项目识别错了，是路由错了，是知识没召回，还是模型最后总结跑偏了。 <5> 人工汇总知识不够用易过期 走到这一步后，AI 已经能处理一些简单、固定流程的业务需求了。但新的问题也很明显：知识库不能只靠人工写。 人工总结的知识短期有用，但长期会遇到三个问题。 第一，维护成本越来越高。后续可能项目在变，文档也要跟着变，靠人手动同步迟早会漏，其实推广到别的项目也容易变。 第二，答案会逐渐不可信。知识写进去的时候是对的，不代表几个月后还对。内部项目最怕的不是"不知道"，而是系统拿着过期知识自信地指导用户。 第三，模型有时会为了补上下文读太多内容。看似更努力，实际会增加 token 消耗和服务压力，而且读得越多，越容易把不相关内容混进来。 所以后面思路又变了：不能只把项目当成一堆文档，而要把它看成一张结构网。 一个业务对象可能关联配置、规则、动作入口、脚本、命令、上下游顺序。靠纯文本相似度去猜这些关系，不稳定，也浪费。 于是开始尝试走LangChain + neo4j路线把项目内条目切离结构抽取，再把这些关系放进图谱。 图谱不是为了替代 RAG，而是给路由结果提供更精准的背景补充：这个对象在哪里、它关联哪些东西、下一步该查哪类材料。 这样原本"靠模型自己理解项目"的问题，就变成了"先由系统把结构上下文准备好，再让模型基于这些上下文回答"。 (小小的吐槽一下：其实到图谱前这个就已经基本实现功能了，最核心最主要是上面觉得要图谱才放心,因为别人好像什么王道路线就是那么走的，没办法胳膊肘拧不过大腿不是吗 手动滑稽 ） <6> 展示层也要自己做 结构抽取图谱建出来以后，本以为可以直接用数据库工具展示。实际又踩了一个坑。 neo4j数据库浏览器适合工程调试，不适合业务展示。比较好的图谱浏览能力都在企业版里， 普通版本虽然能证明"数据确实在里面"，但对普通用户来说，看到的常常只是一堆点和线。 我最开始就只是部署到容器里测试，怎么看怎么别扭以为得下个软件，结果实际还是得付费了属于是 用户不关心数据库里有多少节点，他关心的是：这个对象为什么会关联到这些东西，我要改它应该看哪里。 所以展示层也得自己做。 这个浏览器不追求通用图数据库能力，只服务当前业务： 打开后默认展示一个对象的局部关系 节点按业务类型着色 边显示关系含义 支持搜索、点击查看详情、逐步展开 隐藏原始大段内容，只展示对维护有用的信息 它的目标不是替代数据库，而是把图谱翻译成业务人员能看懂的界面。 后续如果用户能自己搜索对象、展开关系、点节点看详情，再结合 RAG 给出的解释和修改建议，就比较不戳了"。 <7> 过程中最大的几个教训 1. 不要把 RAG 理解成"文档问答" 文档问答只是 RAG 的一种最简单形态。 内部业务场景里，用户往往不是来问"这段文档什么意思"，而是要完成一个动作。动作需要结构、规则、上下文和边界。 如果只做文档问答，很容易一开始看起来能用，深入使用就暴露问题。 2. 意图识别比召回更早出问题 很多人调 RAG 时第一反应是调 chunk、调 embedding、调相似度阈值。 这些当然重要，但在操作型场景里，更早的问题是：系统有没有判断对用户要做什么。 意图错了，召回越准越危险，因为它会在错误方向上给出很完整的答案。 3. 结构化知识比堆文档更重要 文档越堆越多，不等于系统越懂业务。 有些知识应该写成说明，有些知识应该从项目里自动抽取，有些知识应该建成关系，有的知识需要把人的理解抽出来 把所有东西都塞进向量库，只会让问题变得更难诊断。 4. 展示工具会影响认可度 这是后来才意识到的。 同样一套图谱数据，如果只在数据库浏览器里展示，普通用户会觉得乱不知道干啥的；如果用业务视角重新组织，用户才会觉得"这个东西能用"。 所以展示层不是锦上添花，它会影响别人对系统成熟度的判断，也方便用户检查 9 个帖子 - 6 位参与者 阅读完整话题