做网优的人大概都有过这种时刻：一份核查清单摊在桌上，左边是4G的设备板卡，右边是5G的设备板卡，中间要找的是"哪些射频单元既服务4G又服务5G"。这种活儿不复杂，但量一大就磨人——几千几万块板卡，手动比对能把眼睛看花，还保不准漏。

于是我想，干脆写个工具替我干。这次做的是"4&5G共设备功率配置核查"，核心就一件事：把共设备的射频单元抓出来，把两侧的小区对上，按频点归好类，输出一张能直接拿去核对功率配置的表。

工具是和AI协作搭起来的。过程中我最大的体会是：AI写代码很快，但有些坑它替你踩不了，必须你自己下场较真。下面把这次踩的坑一条条摆出来，既是复盘，也算给同行提个醒。

一、先定口径：共设备到底按什么判

这是整个工具的根。如果根没扎稳，后面全白搭。

我的数据源是两个系统的设备板卡清单（一张4G、一张5G），每行登记一块射频单元，关键字段是"资产序列号"——说白了就是一块射频单元的身份证号。我们要判断"共设备"，唯一干净的判据就是：**同一块射频单元的序列号，同时出现在4G清单和5G清单里**。

为什么必须用序列号，而不是"同一个站址"或者"同一个小区名"？因为现实中，一个基站站址里4G和5G往往是分开放在不同射频单元上的。站址相同，不等于它们共用同一块单元。只有序列号对上，才是真共设备。

这一点我跟AI反复确认过，最后拍板：严格按序列号。宁可贵一点，也不放宽到"同站址就算"，因为放宽了就会把"共站但不共单元"的小区误配进来，结果反而脏。

二、关联链路怎么搭

口径定下后，链路就顺了：

1.只提取两种射频单元类型（MRRU、EPRRU），其他板卡不掺和；

2.用序列号给两侧板卡建索引；

3.取两边序列号的交集，这就是"共设备"的单元集合；

4.对交集里的每块单元，去两个系统的静态参数表里追它下面挂的小区名、频段、频点、带宽；

5.按频点归类：频点300的进A列，频点1550的进B列，其他频点进C列；

6.输出两张表——一张全量（保留关联过程，方便校验），一张只放共设备结果（整行去重）。

链路看着清楚，真正要命的都在第4步"追小区"和第3步"判共设备"的细节里。

三、踩坑实录

坑1：一块板卡挂多个小区，不是一对一

最开始我提醒过自己：一个"单元名+射频单元信息"关联出来的本地小区，可能不只是一个，而是1到3个，对应不同频点。如果不展开，就会漏掉同单元下别的频点小区。

解决办法是：索引不要建成"一对一"的字典，而要建成"一对多"的列表，追踪时把每个小区都展开成独立一行。实测下来，4G侧有近三成单元是多小区的，最多的挂了6个。不展开真会漏一大片。

坑2：同站址 ≠ 共设备

这是最容易被"直觉"带偏的。我用一份手工核查的结果去比程序输出，发现程序"少"了二十多行。一查，那些行里4G和5G确实在同一个站址，但落在不同序列号的射频单元上。

按"序列号相同才是共设备"的口径，这些行本来就不该输出。程序没错，是我手里的对照表口径更宽了。差异的根子，就在"按串码"还是"按站址"这个定义上。所以动手前，先跟自己把定义咬死，比写完再返工省事得多。

坑3：小区名写着写着就变样了

两个系统给小区起的名字，口径不完全一样。比如有的在前缀加了站型标记，有的把同一段前缀放在了不同位置。结果就是：程序输出了"XXF33"，我手里的表写的是"JJXXF33"——其实是同一个小区，名字写法差了一截。

这种不是漏，是同名不同写法。核对时别被前缀晃了眼，按"网元名+小区名+频点"对齐，比死磕字符串靠谱。

坑4：5G空白的行，不是"非共设备"

结果表里有一批行，5G小区名是空的。我第一反应也是"这咋没配上"。后来才分清：

•全量表里大量5G空白行，是"纯4G小区"，压根不共设备，空白是正常的；

•但共设备结果表里的那三十几行5G空白，是另一回事——它们序列号已经判明共设备了，只是从5G静态参数表里没追到对应小区名（可能是5G侧没配小区，也可能是网元名/机框号口径对不上）。

这俩完全不同。前者是"没配上"，后者是"硬件上共设备、但5G小区信息缺失"。看表的时候先分清在哪张表，别一股脑当成bug。

坑5：用小区名反查序列号，会查到另一块板

有个同事拿一个4G小区名去基础数据库反查"资产序列号"，再去5G清单里找，死活找不到，跑来问我程序是不是漏了。

问题出在：一个4G小区常挂多块射频单元、多个序列号。程序判定共设备用的是"那个5G侧也有的序列号"；而拿小区名反查，查到的是它挂的"另一块只在4G的单元"的序列号。拿Only-4G的串码去5G清单找，当然找不到。要核对共设备行的串码，看结果表里"资产序列号"那一列（那是配对用的串码），别绕道用小区名反查。

坑6：对照表自己也会写错网元名

有一批行对不上，追到源头发现是对照表自身的问题：同一个"五福大厦"，对照表写的是某个网元名加一组小区，而真实数据库里这些小区挂在另一个网元名下，连小区编号都对不上。这不是程序漏跑，也不是纯源数据缺失，是人工整理对照表时网元名抄岔了。所以"对不上"先别急着怪工具，回头看看对照表本身干不干净。

坑7：占位序列号是脏数据

基础数据库里存在一种占位序列号，被多个不同物理站址的单元共用。这种数据如果在关联链路上被当成真序列号，就会把跨站址的单元误判成共设备。好在共设备判定用的是板卡清单里的序列号（那批是干净的），脏数据主要影响的是小区追踪和命名环节。但这类坑提醒我们：源数据不是天然可信的，关键关联键最好先验一下唯一性。

四、留一道保险：待人工复核

即便口径定得再死，也架不住极个别"同一序列号真跨了不同网元"的异常情况（比如同一块单元在两个基带单元下重复登记）。这种量很小，但错了就是错。

我在程序里加了一列"人工复核"：凡是同一序列号在某一侧跨了多个网元的，自动标"待人工复核"。跑完结果瞄一眼这一列，把少数可疑行挑出来人工确认，比全量盲信稳。

五、写在最后

工具跑通那天，我回头想了想这次协作。AI帮我把规则翻译成代码、把关联链路搭起来、把一对多展开、把表做出来，速度是自己手写的好几倍。但有几件事它替不了：

一是**口径的拍板**——共设备按串码还是按站址，这种定义只能人定，定了AI才写得对；

二是**坑的识别**——结果"对不上"的时候，是人判断这到底是bug、还是口径差、还是源数据脏；

三是**最后的较真**——工具是放大器，它放大的是你的判断。判断准，结果就准；判断糊，它只会更快地给你一份看起来规整、其实跑偏的表。