通义千问写错误信息文案总是只显示失败，提示词哪里没写清楚

说实话，看到“通义千问返回‘失败’”这几个字，我一点都不意外。这其实是个很经典的提示词翻车现场——不是模型不行，而是你没把“错误文案到底要写成什么样”这件事给它讲清楚。它不知道你要的是面向用户的提示语、开发侧的调试日志，还是结构化报错描述，自然只能扔出一个笼统的“失败”来应付你。

简单来说，问题出在三个方面：场景没说清、格式没约束、自由发挥的空间太大。我们一个个拆开看。

明确错误文案的使用场景

第一步其实特别简单，在提示词的开头，用一句话把用途锁死。比如：“以下所有错误文案均用于前端用户界面，需口语化、无技术术语、带安抚语气”。这句话一写进去，模型就明白目标受众是普通用户，不是程序员，输出自然就变了味道。反之，如果你不写这句，它就按通用文本处理，默认给个冷冰冰的“失败”或“错误”。

做完这步之后，紧接着要干一件更重要的事：给一个真实示例。示例的格式必须跟最终要的输出完全一致。比如：“示例：网络开小差了，稍等两秒再试？”模型看到这个示例，就知道你想要的是“有温度的、像人说的话”，而不是干巴巴的报错码。

还有一条硬伤：别用“尽量友好”“大概写清楚”这种模糊要求。模型没法量化“尽量”，结果就是跳过，直接按它最熟悉的套路来。你写“尽量友好”，它可能给你输出“我们感到抱歉”，这根本不是你要的效果。

强制结构化输出格式

这一招是让模型不再自由发挥的关键。你可以用两种方法实现：第一种是用分隔符框定字段。在提示词末尾加一句：“请严格按以下格式输出，不得增减行或改动冒号位置：错误代码：[填入HTTP状态码或自定义码] 用户提示：[面向用户的完整句子] 调试建议：[给开发人员的10字内动作指引]”。这个格式写清楚，模型输出就不会跑偏。

第二种方法是用XML标签包裹。比如：“请将结果封装为：401登录已过期，请重新进入首页清缓存重进”。这种写法对模型来说更自然，解析也更容易。

这两种方法选一种就行，我个人习惯用XML标签，因为结构更直观，后续处理也更方便。

堵住模型自由发挥的漏洞

最后这步最容易忽略，但偏偏是最关键的。在提示词末尾追加一句硬性禁令：“禁止输出任何解释性文字、括号补充、换行符、‘例如’‘比如’等引导词，只输出符合上述格式的纯错误文案内容。”

你可能会想，就这一句话能有多大作用？跟你说，漏掉它，模型极大概率会在你指定的格式后面额外追上一句“以上是根据您的要求生成的……”之类的废话。你不仅要删，还可能打乱后续处理的自动化流程。所以这句话必须写，而且要写在提示词的末尾，像关门一样把它锁死。

这三步操作看起来很简单，但确实能从根本上解决“通义千问只会说失败”的问题。核心思路就一个：把你想让模型输出的样子，清晰地、结构化地、不给它留自由发挥余地地写在提示词里。模型不是不聪明，它是太聪明，聪明到会找捷径——而我们的提示词，就是要把这条捷径堵死。