01 | 验证码是个好设计吗？

当你注册或者登录某个应用的时候，经常会用到验证码。它们大部分是由一串歪歪扭扭的字符组成的，看起来并不容易辨别。

验证码的英文名是 CAPTCHA，这不是一个正规的单词，而是个缩写，它的全称是：Completely Automated Public Turing test to tell Computers and Humans Apart，翻译过来是：用来区分人类和电脑的全自动图灵测试。不知道为什么，我就是觉得它听起来像一个不大正经的恶作剧。

据维基百科的描述，验证码出现于十年前，是为了防止机器（程序）假扮成人，去占用原本为用户准备的资源。比如，利用脚本程序不断地模拟尝试登录以便破解账号密码，或者利用恶意代码在 BBS 中发布大量广告或诈骗内容。

可以看到，它的设计初衷是为了区分人和机器，实现方式是在正常流程中增加了一道门槛，人可以翻过去，而机器会被挡住。

从某种意义上说，它可能是个有效设计，但我不认为它是个好设计。因为挡住机器这件事本应该是服务提供方的责任，而服务方却将其成本转嫁给了用户。

这件事引发了我的思考。

第一个思考：不要将责任推卸给用户

不知道你有没有想过，让用户辨别和输入扭曲的验证码，其实是因为服务提供方的能力欠缺，无法静默区分人和机器，而输入验证码本身，这一操作对用户来说其实并无价值。

有一次我接到用户打来电话，抱怨自己搞不定验证码。我向他解释我们正在被攻击，所以临时调高了验证码的级别。电话的最后，我习惯性地向他道歉，用户却很体贴地安慰我说没必要道歉，毕竟被攻击不是我们的错。

当时我心头一热，脸上一红。他说的没错，被攻击确实不是我们的错，但更不是用户的错，让他们付出成本，花费时间，去辨别图片里的那个圆圈究竟是 O 还是 0 还是 6，其实就是让他们承担我们本应该承担的责任。

举一反三，如果再激进一点考虑，我们的软件服务中还有不少推卸责任的设计，比如让用户在成千上万的商品中筛选和比价，比如各种复杂的界面参数设置和兴趣选择。要是想得再发散一点，所有的银行账户密码似乎也没有必要，超市排队也是一样。

如果用户不需要付出筛选和比价的成本，或不需要花费精力记住账户密码，却可以享受到同样高质量的服务，是不是更好呢？

基于这样的思考，我们是不是应该马上去掉这些推卸责任的设计，比如想出更复杂的方案，替代现有的验证码机制呢？这是关于验证码的第二个思考。

第二个思考：方案选择的平衡

有效的设计确实未必是好设计，比如我自己曾经参与设计的产品中也用到验证码，而且在某些特殊阶段（像刚才提到的被定向攻击），我们还会升级验证码机制，让验证码出现的频率更高，而且更加难以辨认，从而在某些关键入口抵抗一些有针对性的攻击。

这一策略是有效的，但对用户的伤害也很大，升级验证码机制后，用户登录过程中耗费的时间会显著增加，通过率也会下降，还有大量的用户抱怨一股脑地涌进来。

然而从服务提供方的角度来看，它却用最低的成本快速地解决了当时面临的问题。这是产品设计方案选择过程中不得不做出的“平衡”，很多时候我们没有办法第一时间实施对用户的完美方案，这就需要在产品利益和用户利益之间，找到微妙的动态平衡点。

所以让一个产品经理讲用户价值其实不难，天花乱坠说完美方案也不难，难的是在实际工程里做出合适的决定。做工程大部分时候都满身污垢，能在其中保持镇定，保持平衡并不容易。

我们当时在扛过了几轮攻击之后，投入了一些技术资源，引入了更多静默监测的策略。比如记录用户密码、记录用户上次登录的位置 / 设备，或通过一些页面动作来做出判断，保证大部分老用户和一部分新用户不会受到验证码的打扰。

我们并没有做到完美，因为资源永远有限，我们需要把它更多投入到我们的竞争优势上，所以还是保留了验证码机制。在某些情况下还是用这种原始、粗暴，但有效的手段来解决问题——这就是我们选择的平衡。

第三个思考：验证码的进化

Google 在两三年前发布了一个叫作 reCAPTCHA 的解决方案，本着“对人类友好，对机器难搞”的原则，用户只需要简单点击一个“我不是机器人”的复选框就可以，不再需要分辨歪歪扭扭的验证码。reCAPTCHA 通过收集用户环境和行为数据，综合分析、智能区分人和机器。

除此之外，阿里也发布了自己的滑动验证码，还有国内一些第三方的验证码服务也在快速迭代进化。毕竟 Google 的服务不太稳定，他们还是获得了自己的生长空间。

这些更高级的验证码服务，大部分都在标榜自己的“人工智能”属性，不管真假，这确实是个非常典型的机器学习应用场景，提供各种行为特征，训练算法去分辨人和机器。

我们把这个思路放大来看，如果可以把过去看似理所应当，其实是由于服务提供方的成本考虑，而把责任推卸给用户的那些功能或流程拿出来重新思考设计，再搭配成熟的机器学习算法，或许就可以带来一系列革命性的用户体验进化。

比如免密支付，让用户不必再耗费精力记录密码，比如无人超市，让用户无需排队付款，无人驾驶，让用户在通勤的过程中不需要费神开车，等等等等。

这个伟大的变革时代提供了新的方法和工具，让我们有机会重新去审视过去由于技术和工具的限制而不得不做出的妥协。

用新方法解决老问题，或许不需要什么翻天覆地的变化，只是撬松一两块被惯性封印的砖，就已经算得上强有力的推动了。这是验证码给我最后，也是最重要的启发。

所以说，一个简单的验证码，背后却并不简单，我们能从中看到设计原则、设计哲学，甚至技术演化改变用户体验的过程。

在你熟悉的产品中，是否也有像验证码这样，虽然用户习以为常，却并不合逻辑，而且暗含机会的产品形态呢？不妨在留言中讲出来，我们一起讨论。