把同一份缺陷报告交给三个模型，怎样测得公平又省钱

先选一个能稳定复现的小缺陷

比较三个模型，不必从整个项目开始。选一个边界清楚、能够自动验证的问题，更容易看出差别，也能避免把预算花在反复解释背景上。下面用一个搜索页面的缺陷演示流程；这是测试方案，不代表已经完成的模型实测。

用户先输入“北京”，随后改成“上海”。第二次请求先返回，页面显示上海；第一次请求稍后返回，却把页面覆盖成北京。预期行为是始终展示最新一次搜索的结果。把这个顺序固定下来，后面的比较才有共同依据。

报告应包含复现步骤、预期行为、实际行为、相关实现和运行环境。只提供定位问题所需的内容，并删除密钥、真实用户信息和无关日志。三个模型必须看到完全相同的材料，不能给其中一个额外提示。

在报告末尾统一要求：解释根因，提出最小修复，并说明怎样验证乱序返回、请求失败和输入清空。要求模型区分确定事实与推测；信息不足时先指出缺口，不要擅自补写项目结构。

把候选模型记为甲、乙、丙，避免先被名称影响判断。可以先给这次练习设六元上限，其中一半用于首轮，另一半留给补充验证。这个数字只是预算示例，不是费用预测；实际消耗取决于所选模型、输入长度和输出长度。

在 MyRelay 创建账户后，可以用同一把密钥管理不同模型的调用，并查看每次请求的用量和费用。测试前先核对价格，再设置各工具支持的输出限制。不要把计划额度当成自动生效的硬性扣费上限。

分别开启没有历史上下文的会话，提交同一份报告。不要把甲的答案转给乙，也不要在丙回答前透露自己的判断。如果工具支持相同的生成设置，就尽量保持一致；不支持的差异应记录下来。

保存每次输入、完整回答、实际费用和等待时间。首轮先不追问，也不凭文字长短打分。更长的回答可能只是解释更多，更快的回答也未必能直接修复问题。

把三个方案分别放进独立的实验环境，先运行原有测试，再人为控制请求完成顺序。检查第二次请求先完成时，第一次返回能否覆盖页面；同时验证正常顺序、请求失败和清空输入后的表现。

评分以可观察行为为准，而不是以语气是否自信为准。记录根因是否正确、关键测试是否通过、是否引入新问题，以及改动是否超出必要范围。只说“取消旧请求”的方案，也要检查取消失败或响应已经返回时是否仍然安全。

如果首轮方案失败，就把失败的测试现象反馈给对应模型，并沿用统一要求：只修正已证实的问题，解释改动依据。预先规定每个候选最多追加一轮；预算不足时停止，而不是为了得出排名持续充值。

追问内容可以因实际失败而不同，但都要完整保存。比较时把首轮和追问费用合计，并记录人工修改时间。一个首轮便宜、却需要反复纠错的方案，最终未必更省。

最后先看测试结果，再看改动范围和总成本。没有通过关键测试的方案，不应因为便宜而胜出；都通过时，再考虑哪个更容易审查、维护和解释。对学生项目和个人工具，这往往比答案是否华丽更重要。

把结论限定为“这个缺陷、这份输入、这次运行中的表现”，不要据此宣布某个模型永远更强。如果差距很小且预算允许，可以重跑确认。保留报告、测试和费用记录，下次遇到相似问题，就能从自己的证据出发选择模型。