截图生成测试用例：多模态怎么问才具体

截图能告诉模型「看见了什么」，不能自动证明「背后逻辑是什么」。 用多模态生成测试用例时，要逼它区分：界面可见行为、需确认的业务规则、以及纯猜测。猜测必须标出来，否则 QA 会被带偏。

准备截图

去掉真实用户数据与密钥；多步骤流程按顺序编号多张图；用简短文字说明入口与角色权限。若有设计稿与现网差异，先声明以哪边为准。

根据截图生成测试用例表：编号|前置条件|步骤|预期可见结果|优先级|是否依赖未知后端规则。
规则：只根据可见 UI 写预期；需要猜测的规则单独列入「待产品确认」；不要编造接口名。
【角色权限】<<<>>>
【截图说明】<<<>>>

删掉无法执行的空话步骤；补上权限否定用例与空态。示意用例（虚构）仅作格式。结合代码评审清单思维，阻断级问题优先人工设计。

用例表进测试管理工具时保留「待确认」列，直到产品书面答复。暗色模式、小屏与权限否定路径优先补测。截图更新后重跑生成，旧用例要标废弃以免误测。

执行时请保持单一事实源：输入没有的数字、负责人与截止日期，输出就不要出现。把不确定写清楚，比生成听起来完整却无法核对的句子更有用。若连续两次结果漂移很大，先检查是否混入未脱敏或互相矛盾的材料，再考虑换模型。

也可以把本页提示词改成团队共享片段：只开放「材料区」给同事粘贴，固定规则区由维护人更新。这样能减少每人私改导致的格式分裂，也方便在复盘会上对照同一版本讨论。

把本次用过的提示词与输入输出一并存档，方便对照下次同类任务的差异。凡标注虚构或示意的人名、金额、订单与指标，一律不得进入正式提交或对外承诺。若材料涉及客户或员工个人信息，先按公司数据分级选择允许的工具，再开始粘贴。做完一次闭环，用三句话记录：最有效的约束、仍需人工的步骤、下版提示词要改哪里。