3 篇博文 含有标签「quality」

1964 年，三十八个人在皇后区的公寓楼外目睹了 Kitty Genovese 遭到袭击。直到为时已晚，才有人报警。Latané 和 Darley 在接下来的十年里一直在解释其中的原因：看到问题的人越多，其中任何一个人采取行动的可能性就越小。他们称之为“责任分散效应”。在他们著名的癫痫实验中，当参与者认为只有自己和受害者在一起时，85% 的人会介入。当他们相信另外四个人也能听到受害者发病时，只有 31% 的人采取了行动。

现在想象一下你最近一次 AI 功能的发布。产品团队编写了 Prompt。工程团队选择了模型并连接了网关。数据团队整理了检索语料库。安全团队加上了输入和输出过滤器。客服团队起草了升级方案。房间里有五个团队。每个团队都按时完成了各自的部分。三个月后，该功能的准确率悄悄从 89% 滑落到 71%，评估套件自发布周以来就没运行过，当你询问谁负责处理这一回归问题时，每个团队都能点出另外三个比自己更有责任负责的团队。

一位资深工程师在四分钟内批准了一个 400 行的 PR。diff 很整洁。命名很合理。测试通过。两周后，值班工程师翻阅一个查询时发现，它返回的行形状是对的，但取错了列 —— 本该用 user.created_at 的地方用了 user.updated_at —— 队列分析仪表板已经对 CFO 撒了九天的谎。审查者很称职。代码结构良好。这个 bug 在 diff 中是不可见的，因为它不是语法异味，而是语义问题。审查者无从着力，因为没有人写下这个变更原本打算做什么。

一旦你代码库中的大部分 diff 都源自模型输出，这种失效模式就会出现。审查者不再问“这正确吗？”，而是开始问“这看起来像代码吗？”。答案几乎总是肯定的。AI 编写的代码在语法上极其流畅，这种流畅性绕过了工程师们花费十年时间在人类编写的烂代码上磨练出来的审查启发式规则。

上桌玩牌要有足够的筹码 —— 招聘足够数量的高水平人才，这些人才要足够重视质量、足够聪明。你要向她们反复强调公司重视质量的文化，形成正式的惯例检验大块工作，该修的修。

战术上，有这样一条最佳实践 —— 降低做正确事情的难度。Stripe 技术团队做出了各种各样的取舍，以便能够保证任何工程师都能够改进系统的任何部分。鼓励责任感（ownership）。

有专门的内部工具检查国际化的水平，很无聊，但是得花时间做。要注意，这又回到了公司的文化问题，当一个做这件事情的 IC 说：“我上周花了一些时间做 i18n ” 的时候，他应该会默认，领导层足够重视这件事情，以至于会回答说：“当然你花了时间做了这件事情，棒棒哒。”

“开个工单给相应的组，会有相应的人来处理” 是个好实践，但是如果你能够推动这个系统更快更好地把这个工单修掉，你就更能够激励人去开工单。

公司会给专门的途径，比如邮件组的别名，来上报产品的质量 bug。有专门的组来 triage 这些任务，或者把任务分配到合适的组来修，有专门的惯例告诉整个公司质量 bug 的修复速率。

在做重大 API 变化之前，既要做内部测试，也要做外部测试。经常问一下“谁有一个真真正正的 Stripe 账号在手头？能不能更新到 beta 版本试一下？” 人们需要专门抽出时间来做这件事情，并且详尽地记录下来形成文档 —— 想象一下，你有一群挑三拣四的客户，虽然你很可能无法像用户那样深入地、广泛地使用自家的产品，但是这样做已经比瞎猜要好很多了。

发现“一块支付代码 5 年没有碰过了，不知道它是怎么工作的，竟然没有测试”，这种情况虽然很少见，但是对于工程团队来说，是宝贵的财富。

以上所有都不是什么高科技，也都不是能够保证质量的充分条件。Stripe 从来都不会满足当下的质量水平，不会被动地说说“我们的标准很高”，而是保持“主动地一直在去做”。