
十月江南秋意渐浓。当我把“北京出发绍兴五日图文并茂”的需求同时抛给三位AI助手时并未料到这会是一场横跨数日的思维碰撞——从单打独斗到联合作战从简单指令到工程化协作我们共同完成了一次关于AI能力边界与协作潜力的深度探索。第一幕六次单测看见各自的棱角第一轮无图版策划——三家AI的“素颜”答卷千问硬核的票务管家。它接到指令后没有急于动笔而是调用了一整套工具链先查北京到杭州的航班再搜萧山机场到绍兴的接驳交通接着检索绍兴各区域的酒店最后逐一核实景点开放时间和门票价格。在这个过程中它甚至进行了一次自我纠错——最初搜到的住宿推荐集中在柯桥区但它很快意识到越城区才是古城核心于是重新检索并调整了推荐范围。最终输出的方案令人叹服详细列出了多班次航班及票价给出了地铁换乘的精确站名按性价比/更省/住舒适分档推荐酒店并附上预估价格每天的行程细化到小时还附带了完整的预算表和国庆专属避坑清单。它像一位戴着金丝眼镜的管家递上一沓打印整齐的行程单说“请过目所有数据均已核实。如有疑问我随时可以重新计算。”豆包浪漫的旅游博主。它参考了24篇资料才开始作答。与千问不同的是它似乎更在意“这份攻略读起来是否愉悦”。它的方案结构清晰但真正让人眼前一亮的是排版美食清单被精心整理成表格每日行程之间用分隔线隔开关键信息用加粗和颜色标记。它写道“清晨去书圣故里追光看阳光一寸寸爬上白墙黑瓦傍晚在仓桥直街吃臭豆腐听河水在脚下轻轻拍岸。”它更像一位举着相机的旅伴指着远方的风景说“这里拍照绝美我们慢慢逛不急。”它还特别附上了出行贴士哪些景点需要预约、穿什么鞋子合适、什么时间段拍照光线最好。这些细节让它看起来更像一篇小红书笔记而不是一份行程单。元宝灵活的群聊统筹。它只用了12秒思考是所有AI中最快的。它快速抓取了几个关键约束国庆假期、家庭出行、松弛节奏。然后给出了一个与众不同的方案——它没有锁定单一行程而是提供了A/B两套备选方案A方案紧凑高效适合精力充沛的年轻人B方案悠闲放松适合带老人小孩的家庭。它还专门写了“带老人小孩的注意事项”哪些景点台阶多、哪里可以休息、什么时间段太晒不宜外出。它像家族群里那个最会张罗的人发来一条长消息“大家看看这样行不行A方案玩得多B方案更轻松。不行我再改反正来得及。”这一轮三家AI的“性格”已跃然纸上千问是“数据驱动”豆包是“体验驱动”元宝是“关系驱动”。而这恰好对应了三家公司的产品基因——阿里系的工具生态、字节系的内容生态、腾讯系的社交生态。第二轮带图版策划——当指令升级谁在裸泳第二次测试我增加了“图文并茂”的要求。这一次差距被放大也让我看到了三家AI在面对同一指令时的不同策略选择。千问选择了最理性的路径放弃真图。它在思考过程中权衡了利弊——嵌入图片会增加加载时间、可能偏离核心信息、而且图片版权存在风险。于是它决定用Emoji和摄影建议来代替图片。“鲁迅故里门口拍一张”“沈园之夜建议带长焦镜头”“东湖乌篷船穿洞时用广角”——它用文字描绘画面信息密度依旧惊人但视觉上依然是一篇长文。这很阿里实用至上不为形式牺牲效率。元宝则用文字画起了简图。“萧山机场→地铁1号线→酒店”它用符号勾勒路线在每个景点旁标注“此处可配图鲁迅笔下百草园”“此处可配图沈园钗头凤碑”。它依然保持着“先给框架再补细节”的弹性风格虽然没有真图但阅读者能清晰地知道每个节点应该放什么图片。这种处理方式很适合在微信群里快速传阅——“我先发文字版图片回头补”。豆包是唯一的胜出者。它在思考阶段明确计划“调用图片搜索工具”随后真的检索出了鲁迅故里、沈园、兰亭、柯岩等多张实景图。虽然最终正文中未能自动嵌入这可能受限于当前会话的图文渲染能力但图片参考区里那些高清的绍兴风光——仓桥直街的临河水阁、东湖的陶公洞、安昌的腊味长廊——已经让整份攻略有了温度。它像一本未完成的画册图片散落在扉页等待有人将它们粘贴到对应的章节。这一轮我看到了三家AI对“多模态”的理解差异千问认为“描述图片”就够了元宝认为“指示配图位置”就够了而豆包认为“找到真正的图片”才是答案。这背后是不同的技术路线和产品哲学——千问追求信息的精确传递元宝追求沟通的效率与弹性豆包追求视觉的沉浸与共鸣。第二幕联调实验——当三位AI组成一支团队单测结束一个念头浮现如果让它们合作呢千问的严谨可以弥补元宝的粗心豆包的审美可以为千问的枯燥增色元宝的弹性可以为整个方案保留调整空间。于是我设计了一条流水线元宝写初稿 → 千问校正事实 → 豆包生成图文版。第一站元宝——14秒的初稿元宝接到指令后只用了14秒就输出了一个完整的5天4晚框架。它参考了10篇资料涵盖了天气、交通、住宿、景点等多个维度。方案保持了它一贯的风格松弛有度不赶不累还贴心地为家庭出行准备了雨天预案——如果下雨可以把户外景点换成徐渭艺术馆和绍兴博物馆。但它犯了两处错误沈园之夜的日期写成了10月7日实际上当天停演安昌古镇说成了收费景区实则免费进入。这验证了一个规律速度快的模型容易产生“自信的幻觉”。它不是在撒谎而是在用自己的“常识”推测——大多数古镇都收费所以安昌也应该收费大多数演出每晚都有所以沈园之夜10月7日也应该有。可惜现实总是比常识更复杂。第二站千问——严谨的事实核查员千问接过元宝的初稿像一位挑剔的审校员。它没有直接输出结果而是先调用了一系列工具查航班、搜酒店、核实景点信息。在这个过程中它迅速发现了那两处错误并一一纠正沈园之夜应在10月4日或5日观看10月7日当晚确实停演安昌古镇街区全天免费只有内部景点联票才收费双人游不推荐购买联票。它还补充了大量元宝遗漏的信息鲁迅故里必须通过官方公众号预约每个手机号每天可约1次、最多5人东湖乌篷船16:50停售、17:00停止入园柯岩鉴湖画舫套票线上约118-125元/人比现场单买划算。更难得的是它提出了结构性优化建议全程不换酒店只住越城区1号线沿线行程围着饭点排确保不饿肚子10.7返程预留3.5小时避开国庆返程高峰。它还重新计算了双人预算从住宿到餐饮到交通每一项都有明确的数字区间。千问的“工具调用”能力在这里发挥到极致——它不是凭记忆修改而是联网查询了最新的官方信息。它像一个拿着检查清单的质检员一项一项地核对、修正、补充。第三站豆包——内容的美容师豆包拿到了经过千问校正的文本开始进行最后的包装。它再次展现了自己在多模态检索方面的优势成功检索到了鲁迅故居百草园、沈园钗头凤碑、东湖乌篷船穿陶公洞、鲁镇夜景、安昌古镇沿河廊棚等关键景点的实景图。虽然最终正文中未能自动嵌入这些图片这可能是当前版本的工程限制但那些图片已被我手动下载、整理、嵌入到公众号文章中。当文字与图片终于相遇一份真正“图文并茂”的绍兴攻略诞生了——它有元宝的松弛节奏、千问的硬核数据、豆包的视觉素材以及我作为人类编辑的手工打磨。最终成品公众号“小玮看世界”最终攻略发布在公众号“小玮看世界”上标题为《国庆绍兴5天4晚双人松弛版攻略参考》。文章包含了完整的目录、逐日行程、预算参考、餐饮红榜与避坑指南以及国庆专属的应急预案。读者看到的每一段文字、每一张图片都经过了至少三轮AI处理和一轮人工审核。这篇攻略的质量远超任何一家AI独立生成的极限。它既有元宝的“人情味”——松弛的节奏、备选方案、人群适配又有千问的“专业度”——精确的票价、换乘路线、预约规则还有豆包的“氛围感”——精美的配图、清晰的排版、美食推荐。更重要的是它避免了任何一家AI的短板没有元宝的幻觉没有千问的枯燥没有豆包的数据薄弱。第三幕技术深潜——这场实验揭示了什么1. 多智能体协作111 3这场联调的本质是一个顺序流水线式的多智能体系统。元宝扮演“规划者”快速搭建骨架千问扮演“校验者”用RAG检索增强生成填补事实漏洞豆包扮演“执行者”完成多模态输出。这种分工恰好对应了工业界多Agent系统的经典模式分解-分配-聚合。复杂任务被拆解为多个子任务分配给最适合的模型最后将结果聚合为完整产出。有趣的是这种协作并非预先设计而是自然涌现的——因为三家AI的能力互补性如此鲜明以至于“让它们各司其职”成了一个显而易见的解法。如果要用一个比喻元宝是建筑师画出房子的轮廓千问是结构工程师确保承重墙和地基没有问题豆包是室内设计师挑选家具和配色。而我是业主——提出需求、审核方案、最终拍板。2. RAG与幻觉为什么千问能“治病”元宝的初稿出现幻觉是因为大模型本质上是“概率预测器”而非“真理数据库”。面对国庆期间不断变化的景区排期它只能根据训练数据中的常见模式“猜测”。大多数古镇收费所以它猜安昌也收费大多数演出每晚都有所以它猜沈园之夜10月7日照常上演。而千问之所以能纠正是因为它调用了外部工具——联网搜索、景点数据库——用实时信息锚定了输出。这正是RAG技术的核心价值让模型学会“查资料”而不是“背答案”。RAG的工作原理可以简化为三步检索Retrieve——从外部知识库中找到相关信息增强Augment——将检索到的信息与原始问题合并生成Generate——基于合并后的信息生成回答。千问在联调中的表现正是这一流程的完美演绎它检索了最新的景区公告和票价信息将其与元宝的初稿合并然后生成了修正后的版本。3. 多模态RAG的瓶颈豆包为何“搜得到却嵌不进”豆包成功检索了图片却未能自动嵌入正文。这暴露了当前多模态生成的一个工程瓶颈跨模态的对齐与渲染。检索图片多模态RAG的“R”已经相对成熟——CLIP等模型可以将文本和图像映射到同一语义空间实现图文互搜。但将图片与文本在同一个生成序列中无缝拼接多模态RAG的“G”仍然面临诸多挑战Token消耗过大一张高清图可能需要数百甚至上千Token、排版引擎的限制如何在Markdown或HTML中优雅地插入图片、以及生成稳定性的问题多模态生成比纯文本生成更容易出现异常。这也是为什么最终需要人工介入——人机协同Human-in-the-Loop依然是高精度内容生产的必要环节。AI负责“批量生产”和“初步筛选”人类负责“质量控制”和“精细调整”。在这次实验中我手动将豆包搜到的图片嵌入正文并对每张图片进行了裁剪、压缩和添加替代文字确保它们在公众号上的显示效果达到最佳。4. 产品基因决定AI行为三家AI的表现与其背后的公司战略高度一致千问阿里系重视工具调用与交易闭环。阿里拥有飞猪、高德、支付宝等完整的出行生态千问的策略是成为这些服务的“智能入口”——用户问完攻略可以直接跳转到飞猪订机票、在高德上看路线、用支付宝付款。这种“问完即办”的闭环体验是阿里系AI的核心竞争力。元宝腾讯系强调社交分享与弹性适配。腾讯拥有微信、QQ等庞大的社交网络元宝的策略是成为“群聊里的万能助手”——快速出方案、方便修改、易于分享。它的方案天然适合在家庭群、朋友群里讨论“大家看看这个行程怎么样”“我觉得第二天太赶了能不能改”“没问题我马上调整。”豆包字节系深耕多模态与内容体验。字节拥有抖音、今日头条等内容平台豆包的策略是成为“内容的智能创作者”——它不仅回答问题更注重回答的呈现形式和传播潜力。它的方案天然适合发小红书、做公众号、剪短视频因为它从一开始就考虑了“这个内容发出去会不会有人看、有人赞、有人转”。这场实验某种意义上也是三家互联网巨头在AI赛道上的缩影。它们都在做AI但做AI的方式、目标、路径各不相同。千问想让AI成为“工具”元宝想让AI成为“伙伴”豆包想让AI成为“创作者”。没有对错之分只有适不适合。终章复盘的星光回顾整场实验最让我感慨的不是某一项技术的惊艳而是协作带来的质变。当元宝的速度、千问的严谨、豆包的审美被串联在一起AI不再是一个孤立的“答题机器”而是一个各有所长的“虚拟团队”。而人类则从“执行者”变成了“指挥家”——调配资源、把控质量、注入创意。当然这套流水线仍有局限依赖人工流转目前需要手动将元宝的输出复制给千问再将千问的输出复制给豆包无法自动调度豆包的嵌图能力有待进化它能搜到图但还不能自动嵌入正文需要人工介入千问的工具调用偶有波动有时联网搜索会出现延迟或失败影响校正效率通用性未经验证这套流程目前只针对“绍兴旅行攻略”单一场景换目的地、换任务类型效果未知。但方向已经清晰未来的AI应用不会是“一个模型解决所有问题”而是“多个模型各司其职由人类或编排框架统一协调”。我们已经看到了这种模式的雏形——CrewAI、LangGraph、AutoGen等框架正在让多智能体协作变得更加便捷和自动化。最后回到那篇绍兴攻略。当读者在公众号里看到鲁迅故里的青石板路、沈园的钗头凤碑、安昌古镇的腊味长廊时他们不会知道这背后有三家AI的接力、一个人的手工以及一次关于“如何让AI更好地协作”的深夜实验。但我知道。这或许就是技术探索者的浪漫在代码与文字的交界处用一次次的试错与联调让冷冰冰的算法长出一点点温暖的烟火气。注文中所有关于AI能力的描述均基于本次实验的实际输出。如需了解各产品的最新能力请以官方公告为准。