几周前，我手工做一个风险摘要工具，对着一个真实的开源项目跑了一下，只问它一个问题。这个项目是unkey，一个提供认证和API密钥管理的开放源代码库，当时有58个活跃的拉取请求。问题很简单：假设我是团队里的资深成员，在合并前最该先看哪五个？

摘要给出的结果，排在最前面的几个很有意思。第一个，一个计费相关的变更，把当月至今的部署推送到Stripe，同时顺带了一个数据库迁移，撞了一下依赖锁文件，还有持续构建失败的红灯。第二个，还是Stripe变更，仅仅265行，但偏偏动了订阅删除那块，那种处理钱的代码，出点小错代价都很大。第三个，一个长达1720行的数据库迁移，然而测试文件一个没碰。注意，这些拉到清单顶部的，靠的不是代码量，第二个就很小。它们之所以靠前，全看落在什么地方，牵扯了哪些东西：资金代码、模式迁移、依赖锁文件、构建失败。关键词是影响范围与正确性，而从来不是行数。这正是我花了多年时间，在拉取请求冒出来的那一刻就下意识扫描的东西。

打开网易新闻 查看精彩图片

这个风险摘要并不完美，坦白说。它也曾把一个暗色主题的CSS变更，标记为触碰了认证、计费和凭据。这个判断是错的，错得有来有去，原因倒是很说明问题：它匹配的是文件路径，看的是那些路由挂载在名为“auth”和“keys”的目录下，而不是去读实际扰动认证逻辑的代码。动了文件名带敏感词的地方，不等于搅了敏感逻辑。这东西我还在做。但即使错了，错的也是能修补的方式，对那几个关键问题，它没跑偏。

我反复琢磨的是这么一回事。一个小团队里，资深者的注意力，永远是最稀缺的资源。而那条审查管道，对每个拉取请求都一视同仁：四行的配置改动，和1720行的迁移补丁，挤在同一个队列里，等同一双眼睛去看。高风险的那些，自己从不嚷嚷。这样一来，真正崩掉的原因，往往不是没人审查，而是稀缺的注意力，平摊到那些风险天差地别的变更上。

我想要的，说起来简单，实际碰到却不容易。就是让这稀缺的注意力，流到风险真正在的地方。眼光一旦这么转过来，就会发现“注意力该投向哪里”这个问题，绝不始于拉取请求，也绝不会止于拉取请求。它打从工单写下那一刻就冒头了，毕竟有些计划中的工作，还没敲出一行代码，光看会碰到哪些东西，就已经把风险写进了骨子里。然后它贯穿整个拉取请求，就是我刚让你看的那部分。接着，它渗进整个团队的运作模式，渗进那些不断激出风险的地带，渗进那些有人正踩在陌生地盘、本该有第二双眼睛照应一下的位置。最后，一路汇拢，涌到一个问题面前，一个每个工程主管本该能答，可几乎没谁真能答出的问题：眼下，我们究竟扛着多大的风险？

这正是我在构建的东西。它叫Merge Lantern，是个面向工程团队的风险情报平台。它给出一个连贯的视图，让你看到风险活在何处，横跨整个软件交付生命周期：从一张工单的落笔，到一个拉取请求的合并。注意力该洒向哪里，终于不用再拿猜的。它铺成一条明线，把那些不吭声的高风险变更，推到最前头，让你把最贵的那点时间精确花在刀刃上。同时，团队的审查流程不再一碗水端平，从工单生成时的风险评估，到代码合入时的风险梳理，都在一个连通的视野里，让主管有了一个真实可控的风险概览。正是这个小实验，从一次随手的手工摘要开始，一路逼出了这个产品。