最近在做 AI 多模态应用调研时,发现很多开发者都在关注“免费、低门槛、一步到位”的文本/图像/视频生成方案。相比过去需要同时对接多个模型、处理繁琐的账号和 key,现在通过通义千问这一个入口就能串联文本对话、图像生成和视频创作,工作流被大幅简化。本文就围绕通义千问的免费多模态能力做一次完整实测,分别展开文本生成、图像生成、视频生成的调用方式、参数细节和避坑经验,适合刚接触大模型 API 的开发者,也适合已经在业务中接入 AI 能力、想进一步扩展多模态场景的同学。
先说清楚本文的边界。我不会讲太底层的大模型原理,也不打算把所有功能都贴一遍截图,而是聚焦“怎么快速用起来,用起来之后有哪些坑,如何写出稳定的生成请求”。文中的代码示例基于当前主流的 OpenAI SDK 兼容模式编写,如果你手上的通义千问版本接口有调整,核心思路依然可以复用。
1. 为什么关注免费多模态 AI
1.1 多模态 AI 到底能做什么
多模态 AI 指的是模型能够理解并生成多种类型的数据,比如文字、图片、音频、视频。传统上我们把 AI 能力拆成“对话机器人”“文生图工具”“视频生成工具”三块,各自独立使用。而多模态模型试图把这些能力统一在一个入口里,用户可以用自然语言描述需求,然后直接得到文本答案、配图、甚至短视频片段。
这种统一入口带来的好处很明显:
- 上下文可以跨模态传递。比如先生成一段产品描述文案,再基于这段文案生成宣传配图,整个过程不需要手动切换工具。
- 提示词习惯可以复用。你在文本生成里积累的“角色设定 + 清晰指令 + 输出约束”这套写法,在图像生成、视频生成里同样适用。
- 业务流程更容易集成。一个 API Key、一套鉴权方式,就能在应用里同时提供问答、配图和视频草稿能力。
1.2 通义千问在多模态方向的位置
通义千问是阿里云推出的超大规模语言模型系列,除了对话能力之外,它在图像生成、视频生成等方向也有对应的模型能力。对国内开发者来说,通义千问的吸引力主要体现在三点:
- 中文理解能力强,提示词可以直接用中文写,不需要刻意转成英文。
- 有免费额度支撑个人开发者和学习场景,降低了上手门槛。
- API 兼容 OpenAI 接口格式,切换成本低,很多原本适配 GPT 的代码只需要改 base_url 和模型名就能跑通。
需要说明的是,“通义千问 3.8”这个表述在不同渠道的指代可能不同,有的是指对话模型版本,有的是指整个多模态产品线的版本号。本文统一用“通义千问”称呼,重点讲解能力使用方式,不纠结具体版本号,因为模型迭代很快,接口层保持稳定才是更重要的能力。
1.3 本文实测范围
我会从三个维度做实测:
- 文本生成:调用对话模型完成文案、问答、结构化输出。
- 图像生成:通过提示词生成配图,并对比不同提示词结构对结果的影响。
- 视频生成:梳理当前免费视频生成的流程、限制和组合工作流。
如果你正处于“听说多模态 AI 很火但不知道从哪里下手”的阶段,这篇实测笔记可以帮你建立一条从注册到调用、从提示词到业务集成的完整路径。
2. 环境准备与访问方式
在开始写代码之前,先把环境准备好。这里的步骤不复杂,但容易踩坑,尤其是 API Key 的获取入口和模型名的正确写法。
2.1 官方访问渠道
目前通义千问有网页版、App 和 API 三种使用方式:
| 使用方式 | 适用场景 | 说明 |
|---|---|---|
| 网页版 | 快速体验、日常提问、生成图片 | 打开浏览器直接使用,适合验证提示词效果 |
| App | 移动端对话、语音输入 | 适合碎片化使用 |
| API | 开发集成、自动化流程 | 适合把能力接入自己的应用 |
对于开发者来说,API 是必须掌握的渠道,因为只有通过 API 才能把能力集成到产品里。
2.2 获取 API Key
登录阿里云百炼平台或对应控制台后,在 API Key 管理页面创建一个 Key。注意:
- API Key 是敏感信息,不要提交到 Git 仓库,建议通过环境变量读取。
- 免费额度通常与账号实名认证状态有关,额度用完后可以在控制台查看计费规则。
- 如果开通了多个服务,注意区分不同模型的额度,避免混用。
2.3 本地开发环境
本文示例以 Python 为主,需要安装 OpenAI SDK,因为通义千问的 API 兼容 OpenAI 格式。安装命令如下:
pip install openai如果项目网络环境受限,也可以通过阿里云提供的 DashScope SDK 调用,两种方式都可行,核心参数差别不大。
2.4 版本说明
模型版本迭代速度很快,不同模型的名称、能力边界、最大上下文长度可能有差异。本文的代码示例以兼容模式编写,运行时请在官方文档中确认当前可用的模型列表。如果遇到“model not found”之类的报错,绝大多数情况是模型名写错或当前账号没有开通对应模型权限。
3. 文本生成能力实测
文本生成是通义千问最基础也最稳定的能力,把它调通之后,图像和视频生成的学习成本会低很多,因为请求结构和参数含义是相通的。
3.1 第一次对话请求
先写一个最简单的文本对话请求:
# 文件路径:demo/text_generation.py import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1", ) response = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": "你是一个专业的技术文档编辑助手。"}, {"role": "user", "content": "用三句话介绍什么是多模态AI。"}, ], temperature=0.7, ) print(response.choices[0].message.content)这段代码里需要关注几个点:
base_url指向兼容模式的接口地址,如果使用其他云厂商或其他接入方式,这个值会不同。model是模型名称,不同渠道可用模型不一样,按实际环境填写。messages是对话消息列表,其中system角色用于设定 AI 的身份和行为准则,user角色是用户的输入。temperature控制随机性,数值越大输出越发散,越小越稳定。
运行成功后会输出一段关于多模态 AI 的简要介绍。如果网络正常且 Key 正确,整个过程一般不会超过几秒。
3.2 常用参数详解
文本生成接口里这几个参数会直接影响输出质量:
temperature:取值范围通常是 0 到 2。做代码生成、信息抽取时建议设小一些,比如 0.2;做创意文案时可以设到 0.8 以上。max_tokens:限制生成的最大 token 数。不设置时可能使用模型默认值,但长文本场景建议手动指定,避免生成到一半被截断。top_p:核采样参数,与 temperature 共同控制多样性。一般建议只调其中一个,不要同时大幅调整。messages:多轮对话时要把历史消息都传进来,模型本身不保存跨请求的记忆。
示例:
response = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": "你是一个短视频脚本助手。"}, {"role": "user", "content": "写一段30秒的AI工具推广视频脚本。"}, ], temperature=0.9, max_tokens=1024, top_p=0.8, )3.3 场景化提示词示例
文本生成的质量高度依赖提示词。同样是“写一段短视频脚本”,不同写法的效果差别很大。
弱提示词:
写一个AI工具的短视频脚本强提示词:
你是一个短视频策划专家。请为一个AI写作工具写一段30秒的短视频脚本,目标用户是职场白领,视频节奏要快,开头3秒内提出痛点,中间展示工具操作画面,结尾引导点击链接体验。输出格式为:镜头序号、画面描述、旁白文案、字幕文字。强提示词包含角色、目标、受众、节奏、输出格式五个维度,模型更清楚自己要生成什么。这个技巧在图像和视频提示词中同样成立。
3.4 常见输出问题与调整
如果输出的内容不符合预期,先不要怀疑模型能力,按下面顺序排查:
- 输出太短:检查
max_tokens是否太小。 - 内容重复:适当降低
temperature。 - 内容不符合格式:在
system或user消息里明确要求“只输出 JSON,不要额外解释”。 - 中文英文混杂:在提示词最后加一句“请使用简体中文输出”。
文本生成是后面所有多模态流程的底座,这部分调稳了,后续工作流会顺畅很多。
4. 图像生成能力实测
图像生成是通义千问多模态能力里最直观、最容易出效果的功能。相比传统绘图软件,它的优势在于可以直接用自然语言描述画面,几秒钟内得到多张初稿。
4.1 图像生成的基本方式
图像生成通常有两种使用方式:一种是直接在网页对话窗口里输入提示词,模型返回图片;另一种是通过 API 调用图像生成模型,适合程序化批量生成。对于初学者,建议先通过网页体验找到合适的提示词风格,再迁移到 API 使用。
网页端使用时,提示词可以直接写中文。比如:
生成一张科技感十足的AI机器人插画,背景是蓝色数据流,机器人正面朝向镜头,风格偏向扁平插画,画质清晰。模型会基于这段描述生成一张或多张候选图。需要注意,图像生成受到模型版本和风格偏好的影响,同样的提示词在不同版本下可能产生不同结果,所以要养成记录提示词的习惯。
4.2 提示词结构:主体+风格+构图+画质
我建议把图像提示词拆成四个维度编写:
| 维度 | 说明 | 示例 |
|---|---|---|
| 主体 | 画面里要出现什么 | 一只戴着机械臂的白色猫咪 |
| 风格 | 画面是什么美术风格 | 赛博朋克、扁平插画、水墨风、3D渲染 |
| 构图 | 景别和视角 | 正面特写、全身、俯视、远景 |
| 画质 | 质量修饰词 | 高清、细节丰富、电影感、8K |
举个例子,组合起来就是:
一只戴着机械臂的白色猫咪,赛博朋克风格,正面特写,高清细节丰富,背景是霓虹灯街道,画质类似电影截图。4.3 尺寸与比例设置
生成图片时,尺寸和比例决定图片的最终构图。常见的比例包括 1:1(适合头像)、4:3(适合配图)、16:9(适合封面或视频画面)。如果生成结果出现人物被裁剪、主体不完整的问题,优先检查比例设置是否和用途匹配。
网页端通常只需在下拉框里选择比例,API 调用则通过参数传递。不同模型的参数名可能不同,务必参考对应接口文档。
4.4 图像生成效果评估
拿到生成结果后,可以从几个维度评估效果:
- 主体一致性:主要物体是否完整、是否出现多余肢体。
- 风格符合度:画面是否贴合指定风格。
- 文字准确性:如果图中包含文字,文字是否正确(很多模型在小字号文字上仍会出错)。
- 细节质量:边缘、光影、纹理是否自然。
如果效果不理想,优先调整的是提示词,而不是更换模型。增加细节描述、明确风格参考、限定画面元素,都能提升生成结果的稳定性。
5. 视频生成能力实测
视频生成是当前多模态 AI 中最热的方向,也是迭代最快的方向。相比文本和图像生成,视频生成的限制更多、耗时更长、可控性也更弱。我会把这一章的重点放在“理解限制”和“搭建可用工作流”上。
5.1 视频生成的现状
目前的 AI 视频生成普遍存在几个特点:
- 时长较短,很多模型默认生成的视频只有几秒。
- 动作一致性难以保证,前后帧之间可能出现人物面部、动作衔接不自然的问题。
- 生成耗时较长,通常以分钟为单位计算。
- 免费额度和生成次数都有限制,不适合大规模试错。
一些热词中提到“wan2.2 生成视频只有1秒”“minimax h3 视频生成视频动作不一”等现象,这其实是当前主流视频生成工具的通病,用户反馈集中在时长和动作一致性这两个维度。面对这种情况,与其抱怨工具,不如在设计工作流时主动规避。
5.2 视频生成的基本流程
一个比较常见的视频生成流程是:
- 先确定视频主题和脚本。
- 用文本生成模型产出分镜脚本。
- 把每个分镜的画面描述整理成图像提示词。
- 使用图像生成工具生成关键帧图片。
- 将关键帧图片和动作提示词输入视频生成模型,得到视频片段。
- 在剪辑软件中拼接、配音、配乐。
这样做的好处是每个环节都可以单独调整,避免直接让模型“自由发挥”导致画面失控。
5.3 从脚本到成片的组合工作流
前面提到的步骤可以进一步沉淀为一套可复用的提示词模板。
第一步:让文本模型生成分镜脚本:
你是短视频导演。请帮我把下面这个主题拆成5个分镜,每个分镜包含画面描述和旁白文案。主题:一款免费多模态AI工具的日常使用。第二步:从分镜脚本里提取图像提示词。比如第一个分镜是“主角在电脑前打开AI工具”,图像提示词可以写成:
一位年轻人在办公桌前打开笔记本电脑,屏幕上显示AI对话界面,现代简约办公室风格,自然光,浅色调,电影感构图,高清细节。第三步:把生成的图片作为起始帧,配合动作描述生成短视频片段。
这套组合工作流能有效提升成片的连贯性,也降低了对单一视频生成模型的能力依赖。
5.4 视频生成的注意事项
在实际使用中,有几个高频问题需要注意:
- 模特/人物一致性:如果需要同一个角色在多段视频中反复出现,建议固定人物描述词,甚至使用角色参考图功能。
- 动作幅度不宜过大:动作描述越具体,生成结果越可控。比如“慢慢转头看向镜头”优于“随意地动一下”。
- 字幕和旁白分开处理:视频生成模型对文字渲染仍不稳定,建议在剪辑阶段添加字幕。
- 一定要保留生成参数记录:模型、提示词、种子值这些信息记录下来,后续复现和优化会高效很多。
6. 常见问题与排查清单
多模态 AI 的报错和异常现象比传统接口更花样繁杂,下面整理了一份高频问题排查表,按文本、图像、视频分类梳理。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 接口返回 401/InvalidApiKey | API Key 错误或未开通权限 | 检查 Key 是否复制完整,进入控制台确认模型权限已开通 |
| model not found | 模型名拼写错误或账号没有该模型权限 | 前往官方文档确认当前可用模型列表 |
| 请求超时 | 网络不稳定或生成任务耗时较长 | 增加超时时间,或切换异步任务模式 |
| 文本输出被截断 | max_tokens 设置过小 | 调大 max_tokens 或拆分多轮生成 |
| 图像主体缺胳膊少腿 | 提示词过于简单,模型自由发挥空间大 | 补充主体位置、数量、姿态等描述 |
| 图像文字乱码 | 小字号文字渲染力不足 | 减少图中文字内容,或改用后期添加文字 |
| 视频只有1秒 | 模型本身限制单次生成时长 | 拆成多个短片段拼接,或检查账号是否支持长视频模式 |
| 视频动作不连贯 | 前后帧动作跨度太大 | 让动作描述更平滑,或使用首尾帧引导生成 |
遇到异常时,建议按“请求参数 → 账号权限 → 模型限制 → 网络环境”的顺序排查。先确认代码没有传错参数,再去控制台核对权限和额度,最后再考虑是不是模型本身的限制。这样能少走很多弯路。
7. 最佳实践与工程建议
多模态 AI 能力接入项目并不难,难的是把生成质量、成本、稳定性都控制住。下面几条建议来自实际项目的经验总结,可以帮你少踩坑。
7.1 调用层面的规范
- 使用环境变量保存 API Key,不要硬编码在代码中。
- 在代码外层封装统一的调用函数,避免每个功能模块各自实现一套请求逻辑。
- 设置合理的超时和重试机制,尤其是视频生成这类耗时任务。
- 记录每次调用的模型、参数、返回状态,方便排查问题和统计成本。
示例封装思路:
def call_llm(messages, model="qwen-plus", temperature=0.7): response = client.chat.completions.create( model=model, messages=messages, temperature=temperature, ) return response.choices[0].message.content7.2 提示词工程持续迭代
提示词不要一次写死,要用版本管理的方式持续迭代。每次修改都记录变化和效果,积累属于自己的提示词库。公司内部如果有多人使用,可以沉淀一份提示词规范文档,统一角色设定和输出格式要求,减少重复试错。
7.3 内容生成的安全边界
生成内容并不都是可以直接对外发布的。尤其是涉及人物肖像、商标、医疗建议、金融信息等敏感场景时,需要增加人工审核环节,不能把生成结果直接当作最终交付物。在面向 C 端的应用里,还应该加入内容过滤机制,避免模型生成违规内容。
另外要注意授权边界:不要把未公开的文档、代码直接喂给大模型,防止敏感信息外泄;在测试环境验证新功能时,使用脱敏数据。
7.4 成本控制与免费额度利用
免费额度是学习和原型验证的利器,但正式上线前一定要做好成本评估。建议从以下几点控制成本:
- 文本场景优先用更小的模型,如果简单对话不需要最强推理能力,就没必要用最贵的模型。
- 图像和视频生成按需调用,不要批量生成大量无用素材。
- 对生成结果做缓存,相同提示词和参数在短时间内重复请求时直接返回缓存。
- 长时间没有业务请求时,关闭后台轮询任务,避免额度被无效消耗。
8. 总结与下一步
通过这次实测可以看到,通义千问的免费多模态能力已经足够支撑个人开发者和中小团队的日常使用:文本生成稳定可靠,图像生成上手零门槛,视频生成虽然还有时长和一致性上的限制,但通过“脚本生成 + 分镜拆解 + 关键帧拼接”的组合工作流,已经可以产出可用的短视频素材。
如果想继续深入,建议按这样的顺序学习:
- 吃透提示词工程,熟练编写角色 + 任务 + 格式约束的结构化提示词。
- 掌握一套编程语言调用大模型 API,建议从 Python + OpenAI SDK 开始。
- 尝试把多个 AI 能力串成自动化流程,比如自动生成图文并排版发布。
- 关注模型版本更新和社区实践,多模态能力迭代很快,及时调整技术选型。
最后给一个实用建议:每次调用 AI 生成内容时,把提示词、模型名、参数、结果截图都记录下来,坚持两周,你就会拥有一份非常珍贵的提示词效果库。这份积累比追逐各种模型更新更值得投入。如果本文的实测过程对你有帮助,可以收藏备用,后续遇到调用问题时也方便回来对照排查。