alt 属性这道工序，一直没人愿意做
图片 alt 属性是 SEO 里最没争议的一项：该写，写了有用，屏幕阅读器也靠它。但真正填满的站不多。原因很简单——一张图十几个字，一百张图就是一下午，而且写完看不出效果，属于纯投入。
多模态模型把这道工序的边际成本压下去了。原理不复杂：模型能读懂图片内容，你让它用一句话描述，这句话就几乎是现成的 alt。真正卡住落地的从来不是模型能力，而是怎么把它接进你现有的流程，以及跑在哪儿。
面壁智能在 10 月中旬开源的 MiniCPM-V 4.7 提供了一个新选项。这个系列第一次用上 MoE 架构，提供 35B-A3B 和 1B 两种规格，35B-A3B 版本在 iPhone 17 Pro Max 上只占 3 GB 内存就能跑到 13+ token/s 的解码速度。
图片由 AI 生成
端侧这个选项改变了什么
之前给图片打标，站在"调 API"和"自己部署"之间选。调 API 简单，但你得把图片传出去——未发布的素材、客户的图、带水印的原稿，很多场景不方便外传，量大了还是持续成本。自己部署则要一张卡，一张 7B 的多模态模型常驻显存，为了一天几十张图跑一张卡，账算不过来。
端侧模型把中间这条路打开了：一次性部署，跑在 CPU 或者一张入门卡上，不联网，图片不出本机。13 token/s 听起来慢，但一条 alt 就是二十来个字，两三秒一张，批量跑一晚上能处理几千张。
对素材站和下载站尤其合适。新入库的截图、模板预览图、图标包，本来就要人工写标题和标签，现在可以让模型先出一批草稿，人只做修改和确认。从"每张从零写"变成"每张改一句"，效率差着一个量级。
接进流程的时候，别直接写回数据库
见过最省事的做法是脚本读图、调模型、直接 UPDATE 数据库。能用，但出问题时没法回滚，也不知道哪些是机器写的。
更稳的做法是加一层中间态：
- 单独存一份：生成结果写进独立的表或者 JSON 文件，字段里带上模型名、生成时间、置信度或者原始输出
- 标记来源：正式字段上加一个来源标记，区分人工和自动。以后排查内容质量、或者平台抽查，能一句话筛出来
- 人工抽检后再发布：批量生成的东西，抽检比例别低于 10%。多模态模型在图表、截图、带文字的图上翻车概率明显高于普通照片
第三点不是保守。截图里的 UI 元素、图表里的数字、带水印的素材，模型描述错的代价不小——一条写错的 alt 挂在页面上，可能半年都没人发现。
图片由 AI 生成
提示词决定了输出能不能直接用
默认问"这张图是什么"，模型会给你一段描述性的话，适合做图注，不适合做 alt。alt 要的是短、准、带关键词、不带主观形容。
把要求写死在提示词里差别很大：限定长度（15 到 25 字）、指定输出语言、要求客观描述不出现"精美的""高质量的"这类形容词、要求包含图中可识别的主体名词。再补一条：如果图里主要是文字（截图、海报、表格），就转成文字内容的摘要，而不是描述版面。
还有个容易被忽略的：同一批图用同一条提示词、同一个温度参数。参数飘着走，一百张图会出来三种风格，后期统一反而更费劲。
哪些图不适合交给模型
三类图建议保留人工。一是含敏感信息的截图（后台界面、订单、用户数据），即使本地部署也别自动处理，避免生成结果被写进日志；二是需要精确描述的商品图，尺码、型号、材质这类信息模型猜不出来，猜错比不写更糟；三是纯装饰性图片，这类图的正确 alt 其实是空（alt=""），让屏幕阅读器跳过，模型反而会硬写一堆。
最后一点是成本账：如果你的图库总共两三百张，手写一个下午也写完了，不值得搭这套流程。量级到几千张、且每个月还在新增，才轮到模型上场。
