不寻“常”的基建工程师 | 推倒惯性围墙，点一座灯塔把盲区照亮

PING刚接手效能平台CI/CD流程时，团队里没有人觉得它有问题。每周二和周四，开发同学把自己的需求登记在一个文档里，发车的人再把这个文档里的内容一条条手动录入发布平台。二三十个需求，前端后端加起来二十几号人，全靠一个人统筹。

代码冲突了，要找人。发布校验没过，要找人。流程卡住了，还要找人。有人临时要下线一个需求，代码已经合进去了，不支持单独剔除，只能把整趟车推倒重来。发一次车，搭进去一两天。

他觉得不对，但又说不出哪里不对。 他决定跟一趟完整的车看看，不是坐在旁边问，而是一个环节一个环节地走。

这一走就是一个半月，他跟了四十多位同学的完整操作路径。流程里的别扭，身处其中的人早已习以为常，他却一处处记了下来。

碎片拼在一起，问题终于清晰了：堵车背后的问题不仅是流程繁琐，更是信息割裂。各团队的操作习惯不同，关键节点没有自动化，测试盲区导致线上问题频发。

知道堵在哪，剩下的就是把路重铺一遍。重新编排设计后的“大车发布”机制很简单——登记、校验、发车。需求方在平台自主登记，系统到点自动校验准出标准。测试未通过的剔除，通过的一键发车。

到了2025年底统计的时候，这套流程已经跑了四百多趟车，排了一千五百个发布计划，承载了六千多个需求的上线。

发布窗口还在，但等待不在了。

PING 定期会翻每个月的线上问题复盘文档。他发现一个数字：大约33%的线上缺陷，原因是“漏测”。

开发的代码改了，测试不知道。测试凭经验判断“差不多了”，但那些被改动影响的角落可能根本没走到。开发和测试之间永远有条沟，而这条沟一直在往外漏人。

他不觉得这是谁的错，但他觉得自己能把这沟填上。

2025年11月，他开始构思“灯塔”，一个前端测试可视化平台。将代码的每一处改动翻译成测试同学能看懂的东西，哪些代码被走过了，哪些没走过，全部用红绿色块标出来。未覆盖的代码标红，测试完成的部分标绿，把红的走成绿的，代表测试完成。

次年1月底上线初版，邀请5名测试同学内测。阻力比他预想的要大。改变工作习惯的东西，任何人都会抵触。有人说“你给我添麻烦了”，有人说初版不稳定、多了很多额外操作。他没有争辩，把那五个人反馈的每一个问题记下来，继续修复更新。

二月份，1.0版本正式上线。这一次，测试同学打开面板，能清清楚楚看见自己哪些代码跑过了、哪些没跑过。他把这个平台取名“灯塔”。

灯塔上线后，测试能提前拦截本该上线的缺陷，开发也可以在提测前自检，减少线下bug流转。每一行代码的改动都可以被追踪，测试盲区被照亮。

红一块、绿一块，测试从此有了进度条。

“我觉得不舒服。”——PING 的很多想法，起点都是这句话。

他的团队做前端基建，全公司的前端、后端、算法都是他的用户。他的核心信条很简单：解决用户的问题。但怎么知道用户有什么问题？不靠问卷，不靠会议。

“我会去跟他们聊，问他们日常过程中哪些地方用得爽，哪些不爽。”

他的工作方法其实很朴素：去看，去问，去跟。他不是那种拍脑袋出方案的人，而是一个愿意蹲下来、把每一根线头都摸一遍的人。

现在的流程已经跑顺了，但他觉得还不够。他的想法是：打开钉钉，说一句“周四上午十点发这趟车，需求 A、B、C，测试已过”——系统自动完成登记、校验、调度。

不用切平台，不用点按钮，不用等别人。

这还只是个规划，但他觉得方向没错。AI 花了一年就从辅助变成替代部分日常工作，那发布为什么不能借助它变成一句话的事？

聊、总结、做成工具——这就是他的工作方式。

而他的下一行代码，正在规划中慢慢成型。