没有证明，就没有付款。

按结果付费的模式，需要双方对结果有共同的定义。举例来说，可以是具体描述的证明：在设定条件下，某项约定的权限边界未被遵守。哪种影响、哪种严重程度、哪种可重现性才算充分，会在启动前就做出决定。已知问题和已被接受的风险，也会一并归类说明。这样一来，双方就能明确：后续出现的某项证明，究竟属于约定目标的一部分，还是仅仅是一项附加观察。

固定费用对应的是这一书面确定的结果，以及约定的测试范围。若在此范围内未能提供所需的证明，则无需支付按结果付费的渗透测试费用。范围之外的发现，并不会自动产生付款请求权。额外的分析、补救或复测，只有另行明确委托后才会开展。这一模式旨在建立清晰的经济基础，而不是让人模糊地以为，任何技术异常都已经构成一次成功。

在开始之前，目标系统、允许的起始点、测试账户和时间窗口都会先行确定。对第三方系统或平台的权限必须事先明确。联系人、报告路径和中止条件也会一并约定。证明结果所带来的激励，不会改变这些规则。任何测试都不得擅自扩展到其他系统，也不得为了达成既定目标而采用未获授权的方法继续进行。

证明材料会被限制在评估所必需的范围之内。凡是可以通过预先准备的测试数据集展示影响的场景，都无需使用其他客户的数据。敏感结果会通过约定的渠道，与获得授权的联系人共享。针对评估中的争议，会事先约定一套共同的核查程序。这样一来，结果的判定可以依据标准和文档来做出，而不必等到最后才去协调双方对某项发现含义的不同理解。

Result as a Service 适用于能够清晰界定并加以验证的目标，例如 SaaS、API、遗留软件或客户自行负责的基础设施中界定明确的问题。对于 AI 应用而言，输出的可变性以及多个相关组件，需要格外精确的证明标准。因此，该模式是否适合您的项目，会在做出承诺之前先行评估。一般性的现状盘点、完整的审计覆盖，以及单一的按结果付费测试目标，属于不同的服务。

未能提供约定证明的测试，并不意味着系统整体不存在漏洞。相关结论仅限于所测试的范围、版本状态和时间窗口。即便是成功的证明，也只是补救工作的起点。技术文档旨在让您的团队理解问题成因与影响，并规划相应的修复方案。随后的复测，可以有针对性地检验该具体漏洞是否已在新版本中修复；其范围会另行确定。