需建立可复用、可传递、可回溯的错误文案处理工作流：先通过模型调用日志提取真实error.type与message，再按归因层级分类并构建模板库，最后在sdk层自动渲染返回。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在通义千问中反复调试提示词却总收到“输入不合法”“参数缺失”“格式错误”这类模糊报错时，需要一套可复用、可传递、可回溯的错误信息文案处理工作流，而不是每次手动拼凑检查项。
明确错误信息文案的三类来源
第一步：打开通义千问控制台→进入「模型调用日志」→筛选最近5次失败请求。逐条点开，复制完整响应体（含status_code、error.message、error.type）。这一步不能跳过——很多团队直接看前端弹窗文字就动手改，结果发现后端返回的error.code才是真实判定依据。
第二步：新建Excel表，列名设为「触发场景」「原始报错message」「error.type」「建议文案」「是否已上线」。把刚才复制的三条典型错误分别填入前三列。注意：同一error.type可能对应多个message，比如InvalidParameter下可能有“temperature值超出范围”和“top_p必须为0～1之间小数”两种message，它们需共用同一类用户侧文案逻辑。
第三步：对每条error.type标注归因层级——是用户输入问题（如JSON格式错）、参数配置问题（如选了不支持的model版本）、还是服务异常（如503 Service Unavailable）。【只有标记为“用户输入问题”的错误才允许生成引导性文案；服务异常必须返回通用兜底句，不可承诺修复时间或猜测原因】
设计固定文案模板库
方法一：按错误类型建Markdown模板文件
在项目根目录新建/prompt-workflow/error-templates/文件夹，按error.type命名文件：InvalidParameter.md、BadRequest.md、ModelNotAvailable.md。每个文件首行写变量声明，例如{{param_name}}应为{{expected_type}}，当前值为{{actual_value}}，后续空两行写三条不同语气的备选文案（简洁版/解释版/行动导向版）。
方法二：用JSON Schema约束文案结构
创建error_schema.json，定义必需字段：type（对应error.type）、severity（low/medium/high）、user_action（必填动词开头短句，如“请检查xxx”）、system_hint（仅开发者可见的调试线索）。每次新增错误类型，必须通过jsonschema.validate()校验才能合并进主干分支。
接入调用链自动注入文案
第一步：在SDK封装层拦截所有非2xx响应
第二步：解析response body → 提取error.type → 查找本地模板库中对应文件
第三步：用实际报错中的参数值（如param_name、actual_value）渲染模板 → 返回渲染后文案给上层业务逻辑
第四步：若未命中任何模板，则触发告警并自动创建issue到内部工单系统，标题为“新error.type捕获：{{error.type}}”，附带原始response dump。这一步确保模板库持续演进，避免漏覆盖。
