近期，基于阿里云百炼平台自主搭建的智能体应用，进行了一次AI自主下单的完整测试——借助蚂蚁集团适配阿里云百炼的支付MCP能力，调用通义千问3.7 PLUS大模型完成订单生成、支付链路调用、支付宝全款支付等全部操作。测试结果出人意料：支付扣款成功，但线下真实订餐订单凭空失效，商家未接单、未出餐、未配送，用户资金直接流失。目前，问题已同步对接阿里云、阿里云百炼、支付宝官方渠道，退款核查与溯源工作正在进行。这篇文章围绕实操过程、调试细节与故障现象，对本次AI支付异常事件做一次全面复盘——不虚构，不夸张，只讲事实。

先交代测试背景。这次测试完全自主搭建、自主调试，没有使用平台的标准工作流模式，核心采用提示词直接调用技能的轻量化开发方式。说白了，就是靠人工优化提示词、反复微调模型指令，驱动大模型调用对应技能完成业务操作。没有固定工作流配置，灵活性更高，但对模型的理解能力、数据检索准确性、逻辑校验能力要求极高。为了实现对自主订餐、智能下单、AI支付的支持，测试过程中持续迭代提示词内容，反复微调模型适配参数，以此匹配通义千问3.7 PLUS的特性，保障下单流程的完整性。

通义千问3.7 PLUS最新版本，官方宣称原生支持生活服务自主下单的核心能力——理论上能完成商家检索、商品匹配、订单生成、支付对接的全流程。但在实际落地测试中，模型暴露出的问题远超预期。全方位的信息识别与判断偏差，让多项核心数据与真实场景严重脱节：用户实时位置定位偏差、合作商家定位错误、用户与商家的实际距离测算失真、商家上架商品信息匹配错误、平台营销活动识别偏差、优惠权益计算错误、商家出餐时效预判失误、配送送餐信息判定异常……最终生成的整体订单信息完全失真，根本不具备真实履约的基础条件。

结合多次重复调试和模型深度思考日志复盘，异常问题的成因可以锁定在三类核心可能性：一是通义千问大模型本身存在能力缺陷，二是调用的AI支付（体验版）MCP组件存在逻辑漏洞，三是大模型与MCP组件协同适配出现双重问题，两类核心模块同时存在故障。反复测试后发现，大模型在深度逻辑推理、场景数据分析、订单信息演算时，所调取和采信的底层数据存在根本性错误。最典型的表现是地址信息匹配错乱——模型频繁错误判定用户所在地与商家门店的地理位置，精准距离测算完全失真。更关键的是，模型不具备主动校验、纠错、风险预判能力：当识别到地址冲突、信息偏差、数据异常时，不会主动核验真实场景数据，也不会暂停流程并提示异常，而是默认错误数据为真实有效信息，继续推进后续下单、调用支付链路等操作，让错误的流程持续闭环。这种处理方式，在金融支付场景中是致命的。

从产品迭代角度看，定位、商品、活动、时效类信息的偏差，大概率是AI生活服务下单能力处于开发测试阶段、尚未完全适配真实线下经营环境导致的常态问题。体验版功能没有完成全量真实场景数据训练，缺乏线下门店实时信息同步机制，场景适配不完善，模型自然无法精准匹配真实消费场景。这些功能性瑕疵属于可优化的阶段性问题。但本次事件中最核心、最危险的致命漏洞，不是基础信息偏差，而是测试态AI能力与真实金融支付链路的不当打通。

在所有场景信息、订单数据、商家履约条件全部错误、订单完全虚假、没有真实对应订餐业务的前提下，智能体依然依托MCP组件模拟生成了完整合规的虚假订单，同时成功调用支付宝官方真实支付能力，生成有效支付链接，引导用户完成了真实资金支付操作。最终形成了极具矛盾性的结果：系统层面生成了完整的虚假订单数据，用户通过支付宝完成了99元真实资金扣款，但线下肯德基商家没有任何对应订餐订单——没有出餐、没有配送、没有履约行为。简言之，测试过程中间出现了“无真实交易场景、无对应服务履约，但产生真实资金扣款”的严重问题。虚假的AI订单凭空诞生，又因为商家端没有数据而彻底失效，用户的真实资金随之流失，核心的“订单真实性校验机制”和“履约风险拦截机制”在整套AI支付体验链路中完全缺失。

复盘下来，症结清晰明确：大模型在场景识别、数据核验、逻辑判断上存在严重短板，无法甄别虚假交易场景；配套的支付MCP体验组件缺乏支付前置风险校验、订单真实性核验、履约能力校验的关键机制；同时，模型与支付组件的协同风控逻辑完全失效，允许未经核验、不真实的测试订单调用真实金融支付接口，最终造成用户资金受损、无服务履约的异常结果。这起事件暴露了一个残酷的现实：当前AI+支付场景的体验版功能，在安全和流程上存在严重的结构性漏洞，远未达到可以放心的阶段。