截图保存一秒钟，找回十分钟。报错截图想按错误码搜，教程截图想用自然语言描述着找——文件名和日期帮不上忙。本文拆一个用 Python 实现的截图检索工具：视觉模型提取四类字段，文本向量建索引，检索时关键词与向量双路并行。重点讲字段设计里的取舍和几个直接决定成败的工程细节。
架构：两条线走通
入库线：视觉模型读图，产出结构化记录；把记录拼成文本交给嵌入模型生成向量，连同记录一起落库。查询线：用户输入先走关键词匹配，再走向量相似度，两路结果合并展示候选图，点开看原图确认。
技术栈刻意保持克制：Python 标准库承担后端服务和 HTTP 请求，SQLite 存数据，第三方依赖只有 Pillow 做图片解码校验。上传的图先过解码检查再入库，坏图在门口就拦下。
字段设计是整个系统的地基
视觉模型对每张截图提取四类信息，各有分工：
| 字段 | 存什么 | 用在哪 |
|---|---|---|
| title | 简短标题 | 列表展示、关键词匹配 |
| summary | 图片讲了什么 | 语义理解、参与向量检索 |
| tags | 软件名、主题词 | 浏览过滤、精确匹配 |
| visible_text | 图中可辨认的原文 | 报错码、命令、版本号的精确检索 |
摘要和原文必须同时存，这是整个设计里最关键的取舍。 摘要回答"这张图有什么用"，原文回答"那串字符到底是什么"。程序员截图的价值常常就在一串精确字符上：ModuleNotFoundError: No module named 'requests' 少一个下划线，检索就断了。提示词里要明确两条纪律：报错码保留完整原文；看不清的字符不许猜、不许"修正"成常见写法。
还有个信息论层面的硬道理：检索再复杂，也找不回从未存进去的信息。视觉模型把报错概括成"Python 环境问题"，具体错误名就永久丢了。所以提取质量 > 检索算法——这也是为什么第一版宁可用人工标注跑离线模式，先把字段质量的标准立起来。
向量索引的边界要认清
这套方案做的是基于文字内容的检索，不是像素级视觉相似度。想找"构图相近的照片"，得换图像向量方案，两回事。文本嵌入的输入是四个字段拼接——拼接顺序和内容配比直接影响检索效果：报错码原文必须完整进向量输入，不能只进摘要。
几条踩坑后的工程纪律
- 先去重再调模型。同一张截图重复导入，按文件哈希先拦，模型调用费和白花钱的重复索引一起省掉。
- 记录向量是怎么生成的。模型名、版本、拼接模板存进库。将来换嵌入模型，全量重建时靠这个字段圈范围，不用瞎猜哪些向量是旧版本。
- 保留原图入口。视觉模型对小字、旋转文字、缩放图都有识别上限，图传上去不等于每行字都读对了，原图是最后的仲裁者。
- 第一版不生成综合回答。搜索结果直接展示候选图加原文，用户自己确认。多包一层"AI 总结"只会增加一个出错环节，先让检索本身透明可信。
验证与迭代方向
演示范围要诚实：离线模式（关键词检索 + 人工标注六张图）可完整验证；在线模式的识别质量与召回效果，必须用自己的截图和接口实测，别人跑通的数字不代表你的数据分布。下一步迭代优先级也清楚：先扩标注量验证召回率，再考虑接入多轮检索——顺序反了就是在没校准的检索层上叠功能。
评论0