想要让通义千问生成的测试计划真正实现按风险高低自动排序测试场景，关键在于提示词中清晰说明三个核心要素：风险维度的定义、量化依据的设定、排序逻辑的计算方式。否则模型很可能会按照功能模块或执行顺序机械罗列，最终产出的只是一张流水账式的清单，与实际测试优先级毫无关联。
明确定义可量化的风险维度
第一步，在提示词开头直接给出风险判定的三个硬性维度——【故障影响范围（用户数/资金量/系统级联程度）】、【发生概率（历史缺陷率/代码变更密度/第三方依赖稳定性）】、【修复时效压力（SLA等级/上线倒计时/监管合规截止日）】。这三个维度缺一不可，缺少任何一个，模型只会用“高风险”“中等”这类模糊词汇打发你，根本得不到可执行的排序依据。
第二步，为每个维度设置可比较的锚点。例如：“影响范围按用户量分级：>50万用户为L1，10–50万为L2，<10万为L3；发生概率按最近3个版本的缺陷密度：≥8个/千行代码为H，3–7为M，≤2为L”。没有这些锚点，模型在横向比较不同模块的风险值时，就像手里没有尺子，只能凭感觉猜测。
强制锁定输出结构与排序规则
这里有两个实用技巧。第一个是使用模板占位符固定输出格式。在提示词末尾加上一句：“请严格按以下结构输出，不得增删字段：|测试场景|影响范围等级|发生概率等级|时效压力等级|综合风险分（L1+H+SLA1=9分，L3+L+SLA3=3分）|排序序号|”。模型一旦看到带分值计算的表格结构，就会自动走数值化排序的路线，而不是写一堆文字描述敷衍了事。
第二个技巧是添加否定式指令，直接堵住常见的跑偏行为。比如加上：“禁止使用‘建议优先’‘应重点关注’等主观引导词；禁止将登录、支付等常规模块默认置顶；若某场景三项均为最低等级，排序必须放在最后”。这能防止模型偷懒，避免它跳过计算直接凭经验拍脑袋定顺序。
注入真实上下文提升判断准确性
要让模型做出靠谱的判断，还需要给它喂入真实的上下文信息。例如本次上线涉及核心账务模块重构（历史缺陷率12.3个/千行）、对接新支付通道（第三方接口未提供压测报告）、距离金融监管报送截止只剩5个工作日——把这些风险信号都写进提示词里。没有这些具体信息，模型只能泛泛地说“支付功能风险高”，但它根本无法判断在当前版本中，支付风险是否真的高于风控规则引擎的变更风险。
此外，可以附上一份极简的模块关联图。比如用文字描述：“订单中心→调用库存服务→触发支付网关→写入账务流水”。模型看到依赖链上的断点（例如库存服务没有熔断机制），就会自动为上游的订单中心加权，而不是孤立地对每个模块打分。这才是真正的风险联动判断。
