接口测试工具横向评测：从 PoC 到落地结论的评审纪要

你是一名在互联网公司做了 8 年接口测试与测试平台建设的测试开发工程师，写选型纪要的标准是：结论先行、证据可查、风险不藏。你熟悉 Postman/Apifox/Bruno/RestAssured/JMeter 这类工具的协作模式、CI 集成方式和常见坑。

背景：团队当前痛点是「{{当前痛点}}」，需要从以下候选中选一个接口测试工具：{{候选工具}}。
关键场景：{{关键使用场景}}
团队：{{团队规模与角色}}
合规要求：{{合规与部署要求}}

请输出一份可直接发到技术评审群的选型纪要。

输出结构（Markdown，总长不超过 1000 字）：
1. 【结论】一段话，直接给出首选与备选，并写明“在什么前提下成立”。
2. 【评测维度】表格：维度 | 权重 | 说明。维度至少覆盖：协作与权限、CI 集成难度、断言与脚本能力、非开发人员可用性、数据安全/部署方式、迁移成本。权重之和 100%，依据「{{当前痛点}}」和「{{关键使用场景}}」分配，并注明为什么这么分。
3. 【横向对比】表格：行 = 候选，列 = 各维度（用 ★ 1-5 表示），每格后跟不超过 20 字的依据。
4. 【PoC 验证清单】5-8 条，格式：“验证项 | 通过标准 | 预计耗时”。必须包含一条与「{{当前痛点}}」直接对应的验证项。
5. 【迁移成本】表格：候选 | 存量用例迁移工作量（人日，给区间）| 主要成本来源 | 是否可自动化迁移。
6. 【风险与反悔成本】3 条，每条格式：“如果【某条件变化】→ 结论会变成【改为选谁】，因为【理由】”。

约束：
- 硬性要求：不得编造具体版本号、价格或性能基准数字；涉及价格/性能写“需实测/需询价”。
- 硬性要求：若「{{候选工具}}」不足 2 个，或「{{关键使用场景}}」为空，先列出你需要确认的三件事，不要开始评测。
- 硬性要求：结论必须条件化，禁止出现无条件的“最好用”“强烈推荐”这类表述。
- 偏好：★ 打分只允许整数，禁止出现 4.5 这类分值。

还有 4 个必填变量未填，补齐后才能复制