Kimi K3.1 系列原生支持视觉理解（官方模型列表口径，核对时间 2026 年 11 月 3 日），网页端传图和聊天一样简单，但 API 的图片输入有几条硬限制——最容易踩的一条是：不支持公网图片 URL，必须用 base64 或 ms:// 协议。这篇把网页端与 API 两条路分别讲清，坑都标出来。
网页端：和聊天一样传
网页版与 APP 里把图片拖进对话框、或用上传按钮选择即可，多张图可同传，随后用自然语言提问——「这张图里的表格转成 Excel」「对比两张设计稿的差异」。这部分的门槛不在操作，在提问方式：让模型做什么要说成可核对的动作（读数、转格式、找差异），而不是「看看这图怎么样」。图片理解的常用场景与提问写法，豆包侧有同型参考：豆包的图片理解怎么用。
API：三条硬限制先记住
官方 K3.1 Pro Quickstart（platform.kimi.com，核对时间 2026-11-03）对视觉输入的约束有三条，逐条都是真坑：
一是不支持公网图片 URL。把 https:// 开头的图片链接直接塞进请求是不行的——要先用 base64 编码图片内容，或使用 ms:// 协议。二是 content 必须是对象数组——不能像纯文本那样给一个字符串，要按「text 块 + image 块」的数组结构组织，文本与图片交替排列。三是多轮对话中 assistant 消息要原样回传——包含视觉内容的历史轮次也要完整保留，不能只传文本摘要（这条对多轮看图任务的影响最大，图一丢，上下文就断了）。
配套的两个参数边界：max_completion_tokens 默认 131072、最大可设 1048576；temperature、top_p 等采样参数为固定值，官方建议不要显式传入——传了不报错但无效果，调试时容易误判。
提示词起手式（图片读数）：「图片中是一张 [报表/截图/图纸]。请输出：一、图中的关键数字按行列整理成表；二、与文字描述不一致的地方单独列出；三、图中模糊或无法确认的部分标注『无法辨认』。不要推断图里没有的内容。」
视频输入的边界
K3 系列在工具侧可处理视频输入（以视频内容块发送），支持的容器格式包括 MP4、WebM、MOV、AVI、MKV、MPEG；小参数档（k3-256k 一类）不支持视频。视频体量大，客户端通常有编码后体积上限，超限先压缩再发。是否用得上视频，取决于任务——逐帧分析类需求更适合抽帧后按图片处理，可控性更好。
多模态的 token 账
图片不是免费的：图片内容折算成 token 计费，折算比例与图片分辨率相关，机制见什么是多模态 token一篇。实操含义是：发高清大图前先想清楚要不要那么高清——表格截图裁掉无关区域再发，既省 token 又常常更准（噪声少了）。配合缓存：固定的说明性文字放前缀能吃缓存价，但图片本体每轮变化，命中不了缓存，这点和纯文本任务的缓存策略不同。
常见问题
- 思考档位对图片任务有影响吗？K3.1 Pro 始终开启思考且默认 max（官方口径），图片读数这类任务多数用 low 或 high 就够——档位与账单的关系见思考强度三档怎么选与K2 迁移中的默认档位坑。
- 哪些模型支持视觉？官方模型列表口径：K3.1 Pro 与 K3 原生视觉理解，K2.6 支持视觉与文本输入，K2.7 Code 未标注视觉——以模型列表当前版本为准，见模型列表怎么看。
- 图片 URL 真的一点不行吗？官方 Quickstart 的表述是不支持公网图片 URL、用 base64 或 ms://——公网 URL 不在支持清单里，按不支持处理最稳。
