根本原因是API无状态，每次请求必须手动传全上下文；漏传、错截或后台清空都会导致指代不明、参数消失、目标遗忘。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
通义千问多轮对话中出现“它指代不明”“上一轮说的参数不见了”“突然忘记任务目标”，根本不是模型变笨了，而是你每次发请求时没把上下文一起带过去——API本身不记事，每轮都是全新开始。
根本原因：API无状态，上下文不传就等于没发生
通义千问所有公开API（DashScope / OpenAI兼容接口）默认【不保存任何历史消息】，模型内部没有“记忆体”。你看到的连续对话，全靠你在代码里手动拼接、截断、再提交。漏传一次，上下文链就彻底断裂。
这和手机App里点几下就能连着聊完全不同——App底层已封装好消息队列与本地缓存，而API调用是裸金属级的，每请求都得自己扛上下文。
最常踩的三个断点位置
方法一：历史消息未显式拼接
你只把当前问题发出去，没把之前user+assistant的交互对追加进messages列表。模型收到的是一张白纸，自然不知道“它”是谁、“那个文件”在哪。
方法二：token超限后盲目截断
qwen-plus最大上下文8192 tokens，但messages列表里塞了8轮完整问答，总token达9200。若直接从头部删掉最早1轮，可能刚巧把系统设定或关键实体（如【目标设备】iPhone 16 Pro）给裁掉了——【删错位置比不删更危险】。
方法三：移动端后台进程被系统回收
安卓/iOS频繁杀后台，导致App内维护的messages列表被清空。下一次提问时，列表已重置为空，只剩最新一条user消息。这不是模型问题，是运行环境不可靠。
验证上下文是否真丢失的实操步骤
第一步：在首轮提问末尾硬编码一个唯一锚点，例如：“【校验标识】CTX-7F2A”。
第二步：第二轮提问开头立即复述该锚点：“【校验标识】CTX-7F2A。请接着说明它的散热设计。”
第三步：检查返回内容是否包含对“它”的明确指代（如“iPhone 16 Pro的散热设计”）。若回复变成“请说明什么的散热设计？”，说明锚点未被识别→上下文已丢失。
第四步：抓包或打印实际发送的messages字段，确认【校验标识】是否真实存在于请求体中。
