企业官网建设流程全解析

今天，我给 AI 助手装上了"眼睛"

如果你手里有一个能用但"只长耳朵不长眼"的 AI 助手，迟早会碰到一个尴尬时刻——你拍了一张报错截图发过去，对面回一句"我是文本模型，无法查看图片"。这种对话发生第三次的时候，我就决定动手了。

事情是这样的：我一直维护着一个日常用的 AI 对话机器人，通过 API 接了一个主流大语言模型。它写代码、理思路、改文档都挺利索，但一遇到图片就当场罢工。最开始我觉得忍忍就算了，截图里的报错信息手动敲进对话框也能凑合。直到有一次，我拍了一张手写笔记，想让它帮忙整理成结构化清单，结果只能对着照片里的字一个个手敲。那一刻我意识到，一个只能读文字的助手，在真实生活里的可用性连及格线都不到。

于是我用了一个下午加一个晚上，给这个助手加上了"视觉通道"——以后它可以看截图、看照片、读图表、识别手写内容。整个过程没有多复杂，真正值钱的在于方案的取舍和后面的坑。这篇文章就把完整思路、核心步骤和踩过的坑写清楚，想给 AI 应用加视觉能力的朋友可以直接照着做。

1. 为什么好好的对话助手，非要给它加一双"眼睛"

先聊清楚动机，因为很多人在做这类改造的时候，根本没想明白到底要解决什么问题。

1.1 纯文本助手在日常使用中的三个"盲区"

我给助手加视觉能力之前，整理了它在实际使用中最常遇到的三个场景，每一个都让我有动手改造的冲动：

第一个，截图里的信息提取。比如同事发来一张数据报表截图，或者某个软件弹出一个错误提示框。这些内容本质上都是文字，但它们在图片容器里，纯文本模型只能"隔屏兴叹"。你可以手动敲，但一旦内容长了——像一屏代码报错、一整页表格——手动誊写就完全不现实。

第二个，手写内容与纸质材料的数字化。我平时喜欢在笔记本上草拟思路，也会收到一些手写的反馈意见。这些内容没有电子版本，唯一的存在形式就是"纸"。如果助手能"看"一眼照片里的手写文字、整理成条理清楚的文本，等于把那些散落在纸面上的信息重新拽回了数字工作流，省掉的不只是一段时间，而是整条手动流程。

第三个，图表数据的理解。折线图里的趋势、柱状图里的高低对比、饼图里的占比关系，这些信息在纯文本里很难精确描述。如果助手能直接识别图表结构，并说出"第三季度营收环比下降了 12%"这种结论，而不是等你去翻原始数据表，那这个助手的价值就完全不同了。

1.2 "看得见"和"理解得了"是两回事

这里要先打破一个常见误区。很多人以为"给 AI 助手装上眼睛"就是把摄像头拍到的画面传给模型看，模型就能像人一样理解面前的世界。实际不是这样。

模型并不是用"眼睛"在看，而是把图片转换成视觉特征向量，再和文本特征做了对齐。换句话说，多模态模型读图的本质，是在"视觉特征"和"文本语义"之间建立了一种映射关系。它能输出对某张图的描述，是因为它见过海量图文对，学会了从像素到语义的转换。

这带来的直接结果是：模型能看到图里的信息，但它很可能"看不见"你在意的那部分细节。比如你发一张发票照片，问"这张发票能不能报销"，模型可能只会告诉你"这是一张发票，金额 500 元"，却不知道你所在公司的报销规则是什么。它看得懂图，但不懂你的上下文。

所以在设计"眼睛"的时候，一个关键动作是：把模型的视觉理解能力和我们自己的业务流程、知识上下文绑在一起，而不是裸奔式地把图片丢给模型干等结果。后面讲实现方案的时候，这一点会反复出现。

2. 给助手"装眼睛"的三种方案，我为什么选了中间那条

动手之前，我先弄清楚了市面上给 AI 加视觉能力的主要路径。网上聊这个的很多，但大多数都在讲"某一个方案的用法"，很少把三条路的边界讲清楚。实际操作下来，选错方案的代价远大于学一个新接口的代价，所以这部分值得单独拿出来说。

2.1 三种主流加"眼"路径对比

我把现阶段实现视觉理解的方式归结为三条路线，它们分别适用于不同的场景和资源条件。

第一种，换用原生多模态大模型。直接把底层 API 换成具备视觉理解能力的模型，比如市面上主流的 GPT-4o、Claude 3.5 Sonnet 或者国产的智谱 GLM-4V、通义千问 VL 等。这类模型天然支持"图片+文字"混合输入，不需要额外搭任何模块，API 调用方式和纯文本模型几乎一样。这是最省事的路，效果也通常是最好的。

第二种，通过视觉语言模型 API 做"转发"。在原有系统不动的前提下，把带图片的请求转发给一个专门的多模态 API，等它返回描述或分析结果后，再把结果作为"上下文"传回原来的文本模型继续对话。相当于在外面架了一个"翻译/预处理层"。

第三种，本地部署开源视觉模型。比如用 Qwen2-VL、InternVL 这类开源模型自己搭建视觉理解服务。这条路的好处是数据不出本地、按量调用没有成本，但对硬件有要求——显卡显存至少 12GB 以上起步，如果要做高分辨率识别还得更高。要处理环境搭建、模型格式转换、推理加速一堆事，维护成本明显上了一个台阶。

三条路的取舍点用一张表能看得比较清楚：

2.2 我的选择逻辑：以"现有助手"为锚点

我的情况比较特殊：已经有一个跑得好好的基于文本模型的助手，它经过了多轮提示词调优，围绕特定工作流积累了不少上下文逻辑。直接换一个多模态模型，等于把已经调好的系统全部推翻重来——那不是一个"加眼睛"的动作，而是一次重构。

所以我的取舍很直接：保留原来的文本模型作为对话主脑，在前置通道加一个视觉理解层负责"看图说话"。这对应的是上面的第二种方案，也是标题里"装上眼睛"最准确的描述——不是换一个会看图的新大脑，而是给现有大脑加一双可以接收视觉输入的眼睛。

每次用户发送带有图片的消息，请求会先经过一个视觉处理函数：把图片交给多模态 API 得到结构化文本描述，然后把这段描述连同图片的关键信息一起拼装成文本提示词，再交给原来的对话模型做后续推理。这样做的好处是原来的模型不用学新本事，主逻辑不受影响，视觉能力变成了一个可插拔的模块——哪天发现有更好的视觉模型，只需要替换预处理层的实现就行，主模型和业务流程完全不动。

这个思路在很多 AI 应用改造里都值得借鉴：不是什么东西都要推倒重来，增量式地加能力，才是维护一个存量系统最健康的姿势。

3. "眼睛"模块的接入细节：图片压缩、提示词和上下文拼接

方向定了，具体实现就变成了一件纯工程的事。这里把每一个技术环节拆开讲，包括我踩过的坑，以及为什么每一步要这么设计。

3.1 图片接入前的预处理：尺寸、格式与压缩策略

视觉 API 虽然能直接吃图片，但直接"原图直传"在真实场景里会引出几个麻烦：一是大图会造成不必要的 token 消耗；二是有部分 API 对图片尺寸有限制，超了直接返回错误；三是识别质量并不总是和分辨率成正比——某些模型在 512×512 到 2048×2048 这个区间内表现最稳，超高分辨率反而会引入噪声。

所以我在接入通道里加了一层图片预处理，具体做了三件事：

• 格式统一：把 HEIC、WebP、BMP 等非常见格式统一转成 JPEG，避免 API 兼容性问题。
• 尺寸控制：当图片最长边超过 2048 像素时，按比例缩放到 2048 以内，保证细节不丢失的同时满足上游限制。
• 质量压缩：JPEG 质量参数设到 85——这个数值是我试过 70 到 95 几个梯度之后选出来的，低于 80 时识别手写文字明显吃力，高于 90 时文件体积涨得很快但识别精度几乎没提升。

此外还有一个容易忽略的点：带透明通道的 PNG 图在转 JPEG 时会把透明区域变成黑色底，直接影响识别效果。处理办法是先给图片铺一层白底再转码，细节上确实比较琐碎，但不处理的话，遇到深色主题的截图就会输出一堆莫名其妙的内容。

3.2 视觉提示词的写法：让模型"带着任务看图"

视觉模型的输出质量，很大程度上取决于你怎么引导它。如果你只是把图丢过去说"描述一下这张图"，得到的结果通常是一段四平八稳的客观描述，这对下游对话模型来说信息密度不够。

我给视觉模型设计的提示词结构是这样的：

1. 指定角色：告诉它"你是用户的视觉助手"。
2. 明确任务：判断这张图属于哪种类型（截图、表格、手写笔记、图表、产品照片）。
3. 限定输出结构：按固定 JSON 结构返回，包括图片类型、图文摘要、关键数值、文字内容等字段。
4. 规定信息密度：要求它"尽量保留所有可见文字，不要遗漏关键数字"。

举个例子，如果输入是一张电脑屏幕截图，理想输出应该类似：

{ "image_type": "app_screenshot", "summary": "一个项目管理软件的看板页面，显示 3 个任务列", "text_content": "敏捷迭代 #1224\n待办：登录页样式调整、接口联调、评审准备\n进行中：支付模块回归测试\n已完成：需求文档初稿", "key_values": [], "notes": "页面右下角有一个红色角标，标注数量 99+" }

这里的核心是：不让视觉模型自由发挥，而是给它一个带约束的输出模板。模板化的好处是同一个函数输出的格式永远稳定，下游模型无论何时拿到这段结构化结果，都知道怎么接着往下走。这个设计理念和普通人理解的"AI 聊天"完全不同——它本质上是在设计一个生产流水线，每一步的产出都有既定规格。

3.3 上下文拼接策略：视觉输出如何"喂"给原助手

视觉模型跑完，真正的转折点来了：要把这段视觉描述，变成原来文本模型能够理解和接着推理的输入。

我设计了一个"视觉片段"拼接方案，把视觉输出包装在一段固定格式的伪对话里：

【用户发送了一张图片】 图片类型: app_screenshot 图片内容摘要: [visual_model返回值] 图片中出现的完整文字: [text_content字段原样保留] --- 请基于以上图片信息，结合用户消息回答。 用户消息: 这个页面还有哪些问题需要处理？

把视觉模型返回的文本"翻译"成对文本模型友好的格式，是这一步最重要的设计决策。因为图片本身已经被转成了结构化文字，下游模型在做推理时不会再"跑去看图"（它也没这个能力），它会把那段文本当成用户输入的一部分来理解，自然就能衔接后续对话。

顺带说一句，图片的图片本身也可以通过 Markdown 图片语法直接传给支持视觉的模型，不少主流 API 支持在 messages 里直接携带 image_url。但如果你的主模型是纯文本模型，"描述+拼接"至少能保留 80% 的视觉信息，这是性价比极高的方案。

4. 实测记录：最让我惊艳的一次，和最让我翻车的一次

功能上线之后，我做了几轮真实场景测试。测试结果非常有价值，它不光学到了怎么用，更让我发现了这双"眼睛"的能力边界在哪里。

4.1 惊艳场景一：手写笔记的数字化

我用一张手写的周计划表做了测试。字迹属于中等潦草程度，还夹杂着大量涂改痕迹。视觉模型不仅准确识别出了大部分内容，连"周五下午 3 点（暂定）"这种带括号的时间备注都提取出来了。最关键的是它能理解"手写勾选标记"的含义——那些被画了勾的条目，在输出里被标记为"已完成"。

这种能力如果靠自己手工誊写，至少得花四五分钟，而且大概率会漏掉某个角落里的备注。而整套流程跑下来不到十秒。

4.2 惊艳场景二：数据图表的"语义翻译"

我找了一张第三方数据平台的销售趋势折线图，底部还有图例和刻度。视觉模型不仅描述了折线的大致走向，还用自然语言总结了"3 月到 4 月有一个明显上升段，5 月回落至年初水平"。这种"把图表翻译成结论"的能力，对做汇报材料的人来说相当实用——你不需要再盯着图表自己总结，AI 先把初稿给你写好了。

这也验证了前面说的"模型在图文对上训练出的语义映射"——它并不只是"看见"折线的像素点，而是理解"上升段"在这个图表语境里的商业含义。

4.3 翻车场景：一张对比表格里的数字

有张表做的是"两代产品参数对比"，视觉模型能正确输出参数名称，但在"144Hz"和"90Hz"这两个数字上出现了识别错误，把 144 认成了 114。

排查发现，问题出在图片压缩上。原图里表格线较细，压缩到 2048 像素后抗锯齿处理让数字边缘变模糊了。好在我在预处理层保留了一套降级策略：当视觉模型检测到图片类型是"表格"时，会启动一个高分辨率重试逻辑——用原始图片二次识别，再对比两次结果。最终数字纠正过来了。

这个翻车案例给我一个很重要的教训："眼睛"不是万能的，识别精度受限于图片质量和压缩设置，做一个降级链路很有必要。我后来把"首轮低分辨率 + 二次高分辨率兜底"作为表格和手写场景的默认策略，误识别率明显下降。这种线上系统里的小细节，比换一个更大更强的模型更能立竿见影地提升用户体验。

5. "眼睛"装上之后，哪些边界必须要守住

给 AI 助手装完视觉能力，爽是真的爽，但有些边界问题我建议你在动手之前就考虑清楚，不然后面补起来很被动。

5.1 隐私边界：图片数据流向必须可控

多模态 API 意味着图片会离开本地，发到第三方服务器做推理。这在涉及个人隐私、内部资料或客户数据时是绝对的硬伤。我的处理方式是：

• 在接入层加一个可见即可传开关，默认关闭，需要用户在网页端手动确认之后才允许发送图片。
• 在系统层面增加了图片自动过期清理机制，请求结束后可以在服务端临时存储 24 小时，完成任务后自动删除，避免长期留存带来的泄露风险。
• 如果后续遇到对数据安全要求更高的场景，本地部署开源视觉模型就是必经之路。虽然成本高，但换来的是数据不出内网的确定性。

5.2 能力边界：模型"看得见"不等于"信得过"

这里必须泼一盆冷水。视觉模型依然会产生幻觉，尤其是在细节模糊或者图中有大量相似元素时，它可能一本正经地编造图里根本没有的内容。

我在测试里遇到过一张老照片的扫描件，模型一本正经地描述了"画面左侧站着三个人"，但实际上那个位置一个人都没有——像素太模糊，模型根据上下文脑补了场景。所以在设计流程时，我给视觉输出加了一个置信度自评字段，让模型在不确定的内容上标注"猜测"或"不确定"。下游对话模型只要看到这个标记，就会在回答里加一句"这部分信息不太确定，建议核对原图"，从机制上避免误导。

这个设计思路，本质上就是给 AI 的"自信"装一个刹车。对于任何要面向真实用户的 AI 应用来说，知道自己什么时候不知道，比什么都知道更像一个靠谱的助手。

5.3 token 成本边界：图片输入并不便宜

视觉能力是有真金白银成本的。一张 1024×1024 的图片，按主流 API 的计费方式，相当于消耗几千个 token。如果是长图或高分辨率图，单张成本可能抵得上好几轮文本对话。

我的应对策略是按图片类型差异化处理：产品截图、UI 界面这类信息重复度高的图，先把压缩率拉高，用较低质量跑；而合同拍照、手写笔记这类需要高保真的图，才投入更高的识别成本。用一个简单的判断函数处理图片，可以在"质量"和"成本"之间取得一个不错的平衡点。

我在测试阶段就发生过一次"惊喜"——某天连续传了一批大图，单日调用成本直接翻了四倍。从那以后我就在请求通道里加了体积和分辨率上限，超过阈值的图直接拒绝处理并提示用户先压缩。合理的成本约束，也是系统健壮性的一部分。

6. 后续还能怎么玩："眼睛"只是第一步

装上"眼睛"之后，我明显感觉到这个助手在真实生活里的可用性上了一个台阶。但"能看图"远不是终点，它至多算是一双"会描述的眼睛"——真正的想象力在于把视觉理解能力与行动能力串联起来。

一个比较顺理成章的进阶方向是拍照即归档。让助手识别你随手拍下的名片、收据、便利贴，然后把文字信息自动写入对应的工作流——名片进通讯录、收据进报销清单、便利贴进待办事项。这时候 AI 扮演的角色就从一个"解释者"变成了"执行者"，价值的增量是几何级数的。

另外可以尝试的是屏幕共享实时问答。在会议场景中，把屏幕上的内容作为图片流持续传给视觉模型，让 AI 充当"实时看板解说员"，在别人演示时边看边同步说出核心信息。这对远程办公场景的辅助价值非常大。

如果你也想动手改造自己的助手，我的建议是：先从一个简单的"图片转文字"通道做起，跑通之后再逐步增加边界判断、成本控制和隐私开关。一个能力再强的功能，如果没有配套的管控机制，在真实场景里就是一个定时炸弹。先让"眼睛"睁开，再慢慢教会"大脑"分辨什么该看、什么不该看、什么时候该提醒自己看错了——这才是把 AI 助手从"玩具"变成"工具"的关键一步。