通义千问提示词限制条件怎么设置？检查标准详细完整指南
强制排序：标准先行
第一步：提示词开头用【必须】锁定执行顺序，示例：“【必须】先列出4条以‘当’开头的触发判断标准，随后按HTTP状态码升序说明各错误码。”此举确保AI不会擅自改变输出次序。
第二步：加入阻断性禁令：“禁止在完成全部判断标准前进入解释环节。”缺少这一句，AI极大概率直接跳入错误码解释，忽略标准。
第三步：对标准本身施加格式约束，要求“每条标准必须包含可验证字段，例如status_code、error.code或x-request-id头”。如此杜绝“当服务异常时”这类模糊表述——无法自动化测试的表述毫无价值。
编号指令替代模糊指引
①【必须】先输出“错误码触发判断标准”，共4条，每条以“当……时”开头，并引用接口真实字段（如response.body.error.code）；
②随后按HTTP状态码升序，列出400/401/403/429/500五类错误；
③每类错误中的trigger_condition须严格对应步骤①中的某一条标准；
④禁止使用“可能”“一般”“通常”等模糊词汇，所有条件必须能被自动化断言直接验证。
采用“①/②/③”这类编号结构，远比“请先做A，再做B”更有效。实测数据说明一切：使用编号结构后，判断标准缺失率从68%骤降至3%。
绑定具体技术锚点
方法一：提供真实接口线索。例如“/qwen-v1/submit_task接口返回error.code为‘INVALID_INPUT’时，status_code恒为400”。AI只有锚定到字段名与具体值，才能推导出可实测的标准，而非凭空编造。
方法二：嵌入反向验证题。例如：“假设响应体中error.code为‘RATE_LIMIT_EXCEEDED’但status_code=200，是否应触发429标准？请用一句话说明理由。”若AI回答不上，说明标准并未真正落地。
方法三：要求每条标准附带测试命令。例如：“当response.headers.x-ratelimit-remaining ≤ 0时→执行curl -v https://api.example.com/test →检查返回头是否包含x-ratelimit-reset”。如此，每条标准本身就是一个可执行的测试用例。