事情是这样的。上周三下午，隔壁工位的运营妹子突然哀嚎一声，说有个Excel要处理，里面3000多条用户数据，她得手动匹配每个用户最近3个月的订单状态，再打标签。按她手速，一上午能搞200条，算下来得干整整一周。
我瞟了眼她的屏幕——好家伙，数据源分三个表：用户信息表、订单表、退款表。没有唯一ID关联，全靠手机号模糊匹配。这种活我见多了，纯纯的体力劳动，用Python跑一下，半个小时出结果。
当时我手里正闲着，就说要不我帮你写个脚本？她眼睛一亮，当场把文件甩过来。我花40分钟写了段脚本，跑完验证没问题，交给她。结果她拿去给主管一看，主管直接跑过来问：这玩意儿能不能批量处理？我说能。主管说好，下周开始全部门都用这个。然后我就被“点名表扬”了——老板在群里说“技术部小王值得大家学习”。
说回技术。这个场景其实很典型：多表数据匹配，字段不一致，需要做模糊关联。我用的Python 3.10，主要依赖pandas和fuzzywuzzy两个库。
核心逻辑分三步。
第一步，数据清洗。原始Excel里手机号格式乱七八糟：有的带86前缀，有的中间有空格，有的用横线分隔。我先用pandas读进来，然后统一做清洗。具体代码就一行正则替换：
“`
df[‘phone’] = df[‘phone’].str.replace(r'[^\d]’, ”, regex=True)
“`
这步去掉所有非数字字符。然后去掉长度不是11位的异常数据，用`df[df[‘phone’].str.len() == 11]`过滤。
第二步，模糊匹配。因为三个表之间没有严格的一对一关系，同一个手机号在不同表里可能少一位数或者多一个数字。我用了fuzzywuzzy的`fuzz.ratio`做相似度匹配，阈值设到80。匹配逻辑是：遍历用户表的每个手机号，去订单表和退款表里找相似度最高的那条记录，如果相似度大于80就取过来，否则留空。
“`
from fuzzywuzzy import fuzz
def match_phone(target, candidates):
best_score = 0
best_match = None
for c in candidates:
score = fuzz.ratio(target, c)
if score > best_score:
best_score = score
best_match = c
if best_score >= 80:
return best_match
return None
“`
这步跑起来有点慢，3000条数据匹配两个表，大概跑了2分钟。优化空间其实很大，可以用`process.extract`替代手动循环，但当时赶时间没做。
第三步，聚合打标签。匹配到订单和退款数据后，按用户分组，统计每个用户的订单数、退款数、最近下单时间。然后根据规则打标签：比如“高频用户”是月订单大于5笔，“风险用户”是退款率超过50%。这些规则写在一个字典里：
“`
rules = {
‘高频用户’: lambda x: x[‘order_count’] > 5,
‘风险用户’: lambda x: x[‘refund_rate’] > 0.5,
‘沉睡用户’: lambda x: (datetime.now() – x[‘last_order’]).days > 90
}
“`
最后把标签拼成字符串，写回原始Excel的一个新列。
整个脚本不到100行，跑完生成一个新文件。运营妹子拿到后，3天的工作量压缩到30分钟（包含她检查数据的时间）。结果就是她被夸了，我也被夸了。
但真正让我觉得值得分享的，是踩的几个坑。
第一个坑：fuzzywuzzy的匹配效率。一开始我直接用`fuzz.ratio`逐条循环，跑了一分钟才匹配200条。后来改成`process.extract`，用`limit=1`取最佳匹配，速度快了大概5倍。但要注意，`process.extract`返回的是列表，需要取第一个元素。
第二个坑：内存溢出。匹配过程中，pandas会创建大量中间DataFrame，尤其是做`merge`的时候。我一开始没注意，把三个表全量join了一次，内存直接飙到4GB，笔记本风扇狂转。后来改成按批次处理，每500条写一次中间结果，释放内存。
第三个坑：编码问题。原始Excel是GBK编码的，pandas默认用UTF-8读，报了一堆乱码错误。加了`encoding=’gbk’`参数解决。但有些单元格里混了特殊字符，还得用`errors=’ignore’`跳过。
第四个坑：时间格式。订单表里的时间字段是字符串，格式是“2023/04/01 14:23:45”，退款表里却是“2023-04-01 14:23:45”。直接做时间运算会报错。统一用`pd.to_datetime`解析，指定`format`参数，才搞定。
第五个坑：数据校验。脚本跑完后，我随机抽了50条人工核对，发现3条匹配错了。原因是手机号相似度阈值设得太低，有些号码只差一位也被匹配上了。后来把阈值提到85，再跑一次，错误降到0条。但阈值也不能设太高，否则漏掉很多。
总结一下。这种自动化脚本的核心不是代码多炫酷，而是理解业务逻辑。你不知道运营要打什么标签，就写不出有用的脚本。另外，一定要做数据校验。跑完结果不看一眼就发出去，等于在给自己埋雷。我这次抽了50条手动查，花了10分钟，但避免了被老板骂的风险。
最后说个题外话。这个脚本后来被其他部门知道了，有人问我能不能写个通用的工具。我说可以，但需要统一数据格式。然后我就被拉去开了个会，讨论数据规范。再然后我就被老板安排写一份“数据清洗规范文档”。再再然后，我摸鱼的时间就少了。
所以，帮同事写脚本这件事，收益是肉眼可见的，但代价也是。如果你也打算干这种事，建议先评估一下自己有没有时间应付后续的“连带责任”。不然，你可能跟我一样，从一个摸鱼的人，变成一个写文档的人。
📎 延伸阅读
看完这篇，如果你想：
- 直接拿工具 → 回复”13“，我把跨境获客工具包发给你
- 系统学习 → 点击菜单”AI训练营”，从0开始跑通AI变现