Imgx

做这个工具的起点很简单：以前在网页上看到一张喜欢的图，我通常先把它下载下来，发给 ChatGPT 或 Gemini，让它帮我整理出一段 Prompt，再复制到另一个生图模型里。中间要来回切页面、上传下载、复制粘贴，还要重新输入和调整，做几次就觉得很繁琐。

Imgx 是我独立做的 Chrome 扩展。把鼠标放到网页里的图片上，就能直接分析它，并给出中英双语的绘图描述、可复制的 Prompt 和负面提示词。不用离开当前页面，也不用手动下载再上传。已上架 Chrome Web Store，可以直接安装体验。

#为了更接近原图

Imgx 先判断眼前的图片属于哪一类，再用该类型真正关心的问题去问模型。分类结果会直接决定后续用哪套方法反推。

一开始只有一套通用模板。很快我发现，人像、UI 截图和建筑图不应该用同一套系统提示词，这会丢失很多细节：人像需要姿态和光线，界面稿需要组件和信息层级，建筑则更在意材质、空间和视角。现在的路由会从图片比例、页面里的 alt、className 和所在网站等线索里累计证据；信号不够，或彼此冲突时，就不替图片做猜测，改由同一次视觉分析从像素里判断。

路由之后是 8 套模板：通用、人像、风景、建筑、产品、UI、插画和海报排版。它们会把注意力放到不同的地方，也会约束模型不要凭空补相机、品牌或 IP。两件事合在一起，目的只有一个：少给一段泛泛的图像描述，多给一段能拿去继续复刻的 Prompt。

#什么叫一段可用的 Prompt

对 Imgx 来说，质量取决于结果能否支持下一次生成。用户不必重新观察原图，也应该能从 Prompt 中找到所需信息。不同类型的关注点会变化，判断标准保持一致。

• 主体明确：人物、产品或空间中的主要对象不能被背景淹没；
• 关系可复现：构图、视角、比例和元素位置需要能指导下一次生成；
• 视觉线索完整：光线、材质、色彩和风格只描述图中能够观察到的内容；
• 约束诚实：看不出的镜头、品牌和 IP 不猜，负面提示词只限制容易跑偏的部分。

#把麻烦留在产品里

真正花时间的是处理网页图源和不稳定的模型返回。图片可能有防盗链，也可能被透明层盖住；模型有时会漏字段、返回不完整的 JSON。Imgx 会尝试找到真实图片、清理返回格式，并在缺少内容时补上必要的信息。用户看到的应该是下一步，而不是一句「生成失败」。

默认模式仍然是本地 BYOK：图片直接发往用户自己配置的模型服务，Key、历史和队列留在浏览器里。现在也可以选择 Cloud 模式，登录后使用 Imgx 提供的免费额度；图片会经由 Imgx Worker 临时转发，原图不在服务端保存，登录、额度和请求状态由 Supabase 管理。这样既保留了自己配置模型的自由，也给不想先申请 Key 的用户留了一条更简单的入口。

Imgx 的技术结构也尽量贴着浏览器本身：Manifest V3 的 content script 负责识别网页图片和放置悬浮入口，Shadow DOM 把结果卡、设置和队列从宿主页样式里隔开；真正耗时的分析交给 background service worker 的队列处理。设置、历史和队列放在 chrome.storage.local，图片副本留在本地 IndexedDB。BYOK 模式下，模型请求直接发往兼容 OpenAI 格式的 Vision endpoint；选择 Cloud 额度时，Worker 负责转发请求，用户不需要配置 Key，Supabase 管理登录与额度状态。

#不确定时，不把猜测写成分析

一张图可能同时具有人像和海报属性，也可能因为缩略图、防盗链或透明遮罩而拿不到足够像素。遇到分类信号冲突时，Imgx 会把判断交给视觉模型；图源不可访问、返回字段不完整或缺少关键观察时，则保留明确的失败状态和重试入口。产品可以帮助用户少走几步，但不能用一段流畅文字掩盖输入本身不可靠。

#还在继续磨

这个项目没有停在第一次上架。最近一轮继续围绕“反推得更准”在改：当一张人物占主画面的海报同时像人像又像平面设计时，不再让本地规则武断地选边，改由同一次图像分析从像素里判断；8 类模板也持续补上各自容易漏掉的复刻线索。

Imgx 已上架 Chrome Web Store，目前支持硅基流动、Gemini、OpenAI 等兼容 Vision 的服务，也可以登录使用 Cloud 免费额度。这个项目从产品想法、Prompt、交互到扩展实现，都是我一个人慢慢做出来的。

你可以访问 Imgx 官网，或从 Chrome Web Store 安装体验。

目前上架和多模型兼容证明了产品可以被安装、配置并完成分析，但还不能证明输出质量已经稳定优于通用视觉描述。下一步需要用固定的人像、UI、建筑、产品和复杂海报样本做对照，记录路由是否正确、必要字段是否缺失，以及生成结果是否真的更接近参考图。