第一步：选定同一段代码作为比较起点
比较模型编写 Go 单元测试的能力，不要先问哪个模型更强，而要让候选模型解决同一个真实问题。选择项目中的小型函数，例如订单折扣计算：输入金额、会员状态和优惠规则，输出应付金额或错误。它应包含明确的业务分支，又不依赖整套线上环境。
准备实现代码、相关类型和业务约定。特别写清零金额是否合法、优惠能否叠加，以及金额如何取整。预期行为必须来自业务规则，不能由模型根据当前实现自行推断。
第二步：固定输入内容与测试生成要求
把完全相同的上下文交给候选模型甲和候选模型乙，分别开启独立会话。统一要求使用标准测试库、采用表驱动结构、不修改生产代码，并为每个用例写出清晰名称。若项目已有断言库，也要把现有写法一起提供。
可以这样描述任务：“请依据业务约定生成单元测试，覆盖正常输入、边界输入和错误路径；如果需求存在歧义，请明确指出，不要编造预期结果。”同时固定可使用的文件和工具，避免一方获得额外信息。
第三步：先检查测试能否独立运行
将两份结果分别放进隔离分支，使用同一套环境执行测试。先记录包名错误、缺失依赖、类型不匹配和不存在的函数引用，再检查测试是否错误访问私有成员。不要看到代码整齐，就跳过实际运行。
保留模型的首次输出。如果需要修复，把同样格式的报错反馈给模型，并单独记录修复过程。首次可用性与反馈后的修复能力，应分开评价。
第四步：逐项核对断言是否验证业务
按照业务约定建立检查清单，而不是仅比较测试数量。订单折扣场景可以检查普通订单、会员优惠、优惠冲突、零金额和非法金额。对每个用例，追问两个问题：输入为什么有代表性，预期结果依据是什么？
- 正常路径是否核对具体金额，而非只判断没有错误。
- 错误路径是否验证约定的错误类别，而非接受任何错误。
- 边界用例是否覆盖规则切换点，而非重复普通输入。
- 预期值是否独立确定，而非调用被测函数再次计算。
第五步：用故意引入的缺陷验证测试
在临时分支中，每次只引入一个小缺陷，例如颠倒会员判断、遗漏优惠上限，或改变边界比较条件。运行原有测试，观察它们能否因这个缺陷失败。完成后立即恢复实现，不要让实验改动进入正式分支。
覆盖率适合帮助发现未执行的代码，但不能替代断言质量检查。测试经过某条分支，不代表它能识别该分支中的错误。把“执行到了”与“发现了错误”分别记录，比较结果才更可信。
第六步：比较测试的可读性与维护成本
检查测试名称能否直接说明失败场景，失败信息是否包含输入、实际值和预期值。留意模型是否为简单函数搭建复杂替身，是否依赖系统时间、网络或执行顺序，以及是否重复实现整套业务逻辑。
再向两个模型提出相同的规则变更，观察它们能否只调整相关用例，同时保留其他业务约束。对长期维护的项目，能解释、能定位、能修改的测试，比单纯堆积用例更有价值。
第七步：通过统一入口记录结果并选择模型
如果需要反复切换候选模型，可以考虑 SwiftRelay，将其作为统一的模型调用入口，减少分别维护调用配置的工作。它按令牌用量计费；比较时仍需固定模型名称、提示内容和工具权限，因为统一入口并不意味着模型行为相同。注册 SwiftRelay 后，可以用新账户赠送的小额额度开始这轮比较。
最终把首次运行、业务覆盖、缺陷识别、修复过程和维护性整理成同一张记录表，并保存调用用量。不要急着选出所有任务通用的冠军：让实际结果决定哪个模型负责常规用例，哪个适合复杂边界，关键业务预期则始终由开发者审核。