上周跟某互联网公司的后端组蹲了一下午，亲眼看见三个开发围着CI界面骂街。提交的代码过了单元测试，过了静态扫描，临到要发预发环境，被质量门禁拦了。理由是这次合并的代码分支，单元测试覆盖率比上一次构建掉了0.7%。
很多团队的门禁从第一版就装错了位置
那三个开发的反应特别真实。有人拍桌子说上次为了赶大版本上线，临时把门禁的覆盖率阈值从85%调到70%，本来想等版本发完就调回去，结果一忙就忘了。现在每次提交，覆盖率涨一点跌一点的，根本没人算得准到底要凑多少分才能过。
很多团队的质量门禁从搭建之初，就把“拦住代码”当成了核心目标，而不是“拦住会带来线上故障的代码”。我见过最夸张的流水线，光门禁检查项就列了11个：静态扫描、单元测试覆盖率、代码重复率、安全漏洞扫描、接口契约校验、上线文档完备度、甚至连提交的commit message长度都要卡。
提交一次代码，等20分钟跑完所有检查。经常因为某个无关紧要的点被打回——比如commit message少写了个冒号，比如代码注释率差了0.2%。时间长了，开发哪有耐心一条条改？最后大家琢磨出来的招，要么把所有检查项的阈值调到最低，要么直接在流水线脚本里加个跳过的参数。门禁从一开始的“质量守门员”，变成了人人想绕开的路障。
说白了，门禁设得太死，最后只会逼得所有人想办法绕开门禁，而不是把代码写好。
卡在哪一步比卡什么指标更重要
刚才那组后端的问题，说穿了就是把所有检查都堆到了最后一步。开发写完代码推到自己的特性分支，没人检查，没人提醒。等攒了几千行代码要合并到主干的时候，才把所有门禁规则拉出来算总账。这时候就算发现哪里有问题，改起来的成本，比写完代码当时就改高了十倍都不止。
真正好用的质量门禁，是跟着开发的提交动作分层触发的，而不是攒到最后算总账。
推特性分支的第一步，就先卡最容易改的硬问题：有没有硬编码的密钥，有没有静态扫描出的严重语法错误。这几秒钟就能跑完，发现问题立刻就让开发改，根本不用等攒了一堆代码再查。等代码写得差不多，要提合并请求的时候，再卡单元测试覆盖率的变化，卡接口的兼容性，这时候改起来也没什么心理负担。最后临到要发生产环境之前，再卡安全扫描的高危漏洞，卡性能基线的波动，这时候的检查才是真的能拦住线上风险的。
说个我亲眼见过的调整。之前有个团队，门禁一直卡“全仓库总测试覆盖率不能低于80%”。结果老代码本来覆盖率就低，新写的代码就算做到100%覆盖，只要老代码那边掉一点，总覆盖率就不达标。开发每次都要为了凑数，硬给根本不会改的老代码补一堆没用的测试用例，纯粹浪费时间。后来他们把规则改了，不卡总覆盖率，只卡“这次提交的新增代码，测试覆盖率必须达到90%”，一下子就没那么多矛盾了。老代码的覆盖率慢慢提，不赶时间，新写的代码必须保证测试覆盖，这才是门禁该干的事。
门禁的规则从来不是一劳永逸的
太多团队的门禁规则，是两年前刚搭流水线的时候定的。两年过去，业务都从To C的用户端，做到了To B的企业服务，门禁的阈值从来没调过。
To C的业务，接口响应慢个200毫秒，用户可能只是觉得加载慢，还能忍。但To B的业务，接口响应波动个100毫秒，客户那边的SLA就不达标了，这时候门禁里的性能基线阈值，自然就要调得更严。反过来，如果是做内部工具的团队，本来迭代速度就要快，门禁里的安全扫描阈值就不用卡得跟支付系统一样严，不然开发连个内部用的小功能都要等半小时检查，效率全没了。
我之前见过最离谱的门禁规则，是要求所有提交的代码，注释率必须达到30%。结果开发为了过门禁，把每一行代码后面都加个// 这行代码是做什么什么的，甚至连注释都复制粘贴，根本没人看。这种规则除了给大家添堵，半毛钱用都没有。
现在很多人吹什么AI驱动的智能门禁，说能自动识别代码风险，其实根本没那么玄。门禁的核心从来不是用多先进的工具，而是你得真的知道，你要拦的是什么风险。比如你团队之前出过三次线上故障，两次是因为提交的代码没做异常处理，一次是因为接口改了没同步文档，那你的门禁就先把这两个点卡上，比你堆十个听都没听过的检查项有用得多。
那天在工位蹲到下班，那三个开发最后把之前临时调的覆盖率阈值改回了原来的数，又把那个卡commit message长度的规则给删了。他们说之前总觉得质量门禁是运维或者QA给他们设的关卡，现在才反应过来，门禁其实是帮他们挡锅的——毕竟真出了线上故障，最后背锅的还是写代码的人。
哦对，走的时候我看了一眼他们的流水线界面，原来之前拦了他们四十分钟的那个覆盖率下降0.7%，其实是因为删了一段根本没人调用的死代码，算下来总覆盖率自然就掉了。
这种乌龙，要是早把门禁的规则捋顺，根本不会发生。