Adversarial Review
在产品上线前,团队主动尝试以最恶劣的方式使用自己的产品,借此找出漏洞的内部检查流程。
简单来说
所谓对抗性审查,是指产品正式推出之前,制作者故意抱着不良意图去使用这个产品,借此找出其中的漏洞。
打个比方,就像锁具公司专门请开锁高手来试着撬开自己新造的锁。一般的检查只会问"这个功能是否正常运作",而对抗性审查则会给自己出一道不同的题目:"用这个功能编出最逼真的谎言"、"这个功能被最恶意地使用会造成什么后果"。它把发现问题的顺序颠倒过来,让制作者本人,而不是用户或记者,成为第一个发现问题的人。
尤其是像地图或医疗信息这类服务,用户往往会把屏幕上显示的内容直接当作事实来接受。这种情况下,只是过滤"不该说的话"的常规检查是不够的。"把错误的内容说得像真的一样煞有介事"这种情形,如果不特意去制造,根本不会被发现——这正是为什么需要专门做对抗性审查。
在报道中是这样出现的
文章以地图上的生成式功能上线一天就被撤下的案例为例,指出"在上线前加入对抗性审查"是产品制作方应该吸取的教训。容易被误解的一点是,以为这是防范外部黑客攻击的安全检查,但实际上它更接近内部团队自行设想最坏情境的一种自我验证流程。
亲手试一试
如果你手上有正在开发或审查中的功能,可以把下面这些问题直接抛给团队:
- 利用这个功能能编造出的最逼真的虚假信息是什么?
- 用户把这条虚假信息误当作事实的可能性有多大?
- 如果这个错误答案没有从屏幕上消失,而是残留在缓存或搜索结果中,会发生什么?
如果这些问题很容易就能得到答案,那就应该实际重现这个情境,并在上线前修正它。