先拔高一句真正的自动化不是从“我要写个 Python 脚本”那一刻开始的而是从某一天你实在不想再打开第五个网页、复制粘贴三张表、然后手工填一张日报开始的。我手里这个脚本就是这么诞生的——它不是什么高深系统就一个每天替我跑数据、发日报的 Python 脚本但围绕它的整个思考过程、踩坑过程、迭代过程我想完整记下来给所有想把重复工作外包给代码的读者一条能直接照走的路径。这篇博文主要讲三件事怎么判断一件事值不值得自动化、脚本第一版长什么样、以及从“能跑”到“好用”中间到底要过几道坎。适合那种已经会用 Python 写点小工具、但还没正经做过一个长期自动化任务的开发者也适合天天在做报表、盯数据、发通知的运营同学——你不需要懂太多抄思路就行。1. 先别急着写代码挑一个真正值得自动化的任务我想先说一个经常被忽略的事实大部分人的第一版自动化脚本都死在了“选错题目”上。有人想自动化订会议室折腾半天发现公司系统接口权限不够有人想自动生成竞品报告结果每天规则都在变脚本修的时间比手点还长。所以真正动手之前得先弄清楚一个任务合不合适。1.1 我选中的那个任务每天上午的“抄数”工作当时我手上有个特别让心烦的日常活每天早上十点前要把前一天的运营情况整理成一张日报发到群里。具体拆开是四步——先从内部数据后台导出一份昨天新增订单的 CSV再从外部推广平台打开活动数据页面把那几个数摘下来最后在 Excel 里把两拨数据按渠道合并、算个汇总截图加文字说明发出去。整套动作熟练的话要十二到十五分钟不熟练的时候能拖到二十分钟。听起来不多但它是每天固定发生的事而且极无聊。最开始我还在心里算过账每天十五分钟一个月就是五个多小时一年六十多个小时——足够读完好几本技术书了。这个任务当时符合我判断自动化的全部标准我后来把它总结成四条。重复频率高、周期稳定。每天都要做不是那种一个月碰一次的杂事。规则清晰且固定。“哪些列合并”“按哪个字段分组”“最终输出什么格式”每一环都有明确答案几乎不需要人为判断。出错代价低、试错空间大。日报晚发十分钟、发错一个数内部消化一下就行不会引发事故。这意味着脚本就算一开始写得烂也不会造成灾难。验收标准极其客观。好不好用就看一件事上午十点前日报发出去了没有数据对不对。这四条缺一不可。反过来看那些“想做自动化但迟迟没动手”的朋友多半是卡在了第二条或第四条上——规则天天变或者事情本身没有硬性交付物那确实不适合一开始就拿代码硬啃。1.2 一个半量化的判断方法两个月回收开发成本除了这四条我还会做一个简单的成本估算帮自己判断“值不值得写”。假设一件事我每天花 T 分钟一个月按22个工作日算就是 22T 分钟。如果我用 H 个小时开发脚本那么只要满足下面这个式子这件事就值得自动化H × 60 22T × 回收月份数 × 2为什么乘以 2因为脚本运行本身也要维护而且写出来的代码至少要留出等量的时间去调试、改 bug。我的习惯是期望回收周期不超过两个月。如果写一个脚本要花 5 小时它必须每天至少帮我省 12 分钟才划算如果它每天只能省 5 分钟那我顶多给它两小时的预算。当时我给自己定的目标是4 小时以内写一个能用的第一版。实际写下来差不太多加上后续迭代其实超了一些但因为有这个预算在先我不会陷入“试试看能不能顺手做个大系统”的泥潭——这是很多人写自动化脚本最大的坑目的本来是省时间结果代码写成了全功能平台。1.3 没选的任务为什么我不碰“看起来更值钱”的方向顺带说一下我没选什么。团队里当时还有个更“高级”的想法自动做数据周报的 PPT把图表、结论、建议全生成出来。听着很酷但仔细一想周报的模板每季度都在换领导偶尔还会临时换分析角度这种依赖人审美判断的任务自动化程度越高维护成本越离谱。还有一个想法是自动巡检服务器日志那确实有价值但权限体系和告警通路都比较复杂短期内交付不了。这两个例子给我的经验是自动化初期要挑“又小又硬”的任务别挑“又大又软”的任务。小是指范围小、流程短硬是指规则硬、边界硬。等一个脚本跑稳了再逐步扩大也来得及。2. 第一版只干四件事用最省的代码跑通全流程选好任务之后我没有立刻铺开写代码而是先在纸上把那条日报的生产流水线画了一遍。最终确定的处理流程只有四个环节拉取数据、解析数据、合并生成报表、推送通知。画完之后我自己都笑了——这不就是个普通的 ETL 加一个消息钩子么。第一版我给自己立了个规矩绝不做“顺手”之外的多余功能比如自动画图表、自动生成分析文字第一版都不碰。目的只有一个——先让“十点前发出日报”这件事拜托人工。2.1 技术选型为什么是 requests、pandas 和 openpyxl依赖库我选了三个都不是冷门后续接手运维也方便。requests用来下载 CSV、调用平台 API、最后推送到群机器人 webhook。这是 Python 生态里最通用的 HTTP 客户端没有悬念。pandas用来读 CSV、读 JSON、按渠道分组汇总。我知道有人会说“就几行数据自己写列表推导不就行了”但 pandas 真正的价值不在于大数处理而在于它对不规整输入的容忍度。数据源有可能多了空行、少了表头、出现整列的缺失值pandas 处理这些情况的兜底方式比手工要稳得多。openpyxl最终要输出一个格式干净的 Excel 文件给团队看。虽然直接用 pandas 的to_excel也能写但 openpyxl 能让我控制列宽、加粗、冻结首行这些细节哪怕第一版没时间做后续加也方便。选型逻辑就一句话用最顺手、团队里别人接手也不慌的库不要为了炫技引入冷门框架。2.2 核心代码骨架我第一版就写了这么点东西第一版脚本我控制在了 150 行左右去掉注释和空行真正干事的代码不超过 100 行。核心逻辑拆开看很简单先看主流程from pathlib import Path import json import time import requests import pandas as pd BASE_DIR Path(__file__).parent DATA_DIR BASE_DIR / data OUTPUT_DIR BASE_DIR / output DATA_DIR.mkdir(exist_okTrue) OUTPUT_DIR.mkdir(exist_okTrue) def download_orders_csv(url: str) - str: 从内部后台下载订单明细 CSV返回本地文件路径 resp requests.get(url, timeout15) resp.raise_for_status() file_path DATA_DIR / forders_{time.strftime(%Y%m%d)}.csv file_path.write_bytes(resp.content) return str(file_path) def load_promotion_json(url: str) - dict: 从推广平台拉取当日活动数据 resp requests.get(url, timeout15) resp.raise_for_status() return resp.json() def build_report(csv_path: str, promotion_data: dict) - Path: 合并两个数据源生成日报 Excel orders pd.read_csv(csv_path) promo pd.DataFrame(promotion_data[channels]) # 按渠道统计订单量、销售额 order_stats ( orders.groupby(channel, as_indexFalse) .agg(order_cnt(order_id, count), order_amount(amount, sum)) ) merged pd.merge(order_stats, promo, left_onchannel, right_onname, howouter).fillna(0) total_orders merged[order_cnt].sum() total_amount merged[order_amount].sum() merged.loc[合计] [, , total_orders, total_amount, , ] output_path OUTPUT_DIR / fdaily_report_{time.strftime(%Y%m%d)}.xlsx with pd.ExcelWriter(output_path, engineopenpyxl) as writer: merged.to_excel(writer, indexFalse, sheet_name日报) return output_path def push_to_group(webhook_url: str, content: str): 推送到群机器人 payload {msgtype: text, text: {content: content}} resp requests.post(webhook_url, jsonpayload, timeout15) resp.raise_for_status() def main(): orders_csv download_orders_csv(https://example.com/api/orders.csv) promo_data load_promotion_json(https://example.com/api/promo.json) report_path build_report(orders_csv, promo_data) push_to_group( https://example.com/robot/webhook, f日报已生成文件{report_path.name}请查收。 ) if __name__ __main__: main()注意这里面example.com是我随手写的占位符你实际替换成自己的数据源地址就行。第一版没有复杂的东西没有异常处理、没有重试机制、没有日志异常全看控制台输出。我甚至没有把它做成定时的前三天都是上午手动跑一下python daily_report.py确认输出文件没问题再发群。这其实是我刻意保留的“人肉保险”。一个脚本第一次上手就跑所谓“全自动”很容易在无人值守时悄悄出错然后等你发现时已经连着错了三天。让脚本先“半自动”地跑一阵子每跑一次你都能亲眼看到输出对培养信任感非常重要。2.3 为什么很多人的第一版卡在“想太多”写到这我想多说一句。我发现很多想学自动化的同事第一版代码总是失败在“试图一次到位”。明明只需要下载一个 CSV非要去研究 API 鉴权体系明明合并两张小表非要起一个数据库。结果半天过去连第一个数据都还没打印出来。第一版脚本的最高原则是先让链路通起来哪怕丑一点。下载就直接写requests.get合并就直接pd.merge推送就直接调 webhook别在这之前引入任何基础设施。你追求的不是架构之美而是“今天上午十点前我不用亲自点那五下鼠标了”。3. “能跑”到“好跑”的三道坎编码、表头变动和定时任务环境第一版跑通之后我对着那个命令行里滚动的日志开心了两天接着就开始迎接一个又一个现场事故。这些事故才是这篇博文最值钱的部分因为代码骨架谁都能看坑只有踩过才知道。3.1 第一道坎CSV 里的中文全是乱码脚本直接崩溃脚本上线的第二天早上我打开output文件夹一看文件没生成控制台报了一大段 UnicodeDecodeError。定眼一看是 CSV 那一步挂的——我们内部后台导出的文件是 GBK 编码的而 pandas 默认用 UTF-8 去读遇到中文和特殊符号直接解码失败。排查思路其实很简单先用记事本打开 CSV 看一眼右下角编码或者用file命令看编码类型更直接的办法是写个循环尝试几种常见编码。我的修复方案是加一个“编码探测 回退”的逻辑def read_csv_smart(path): for encoding in (utf-8, gbk, gb18030): try: return pd.read_csv(path, encodingencoding) except UnicodeDecodeError: continue raise ValueError(f无法识别文件编码: {path})gb18030是gbk的超集能兼容更多生僻字符。这套方案一劳永逸地解决了“今天能读明天不能读”的怪问题。踩完这次我意识到做数据自动化第一件事永远先搞清楚文件编码而不是业务逻辑。3.2 第二道坎推广平台改了字段名Markdown 没提醒我有一阵子脚本连续几天跑得好好的直到某天同事问我“今天渠道 K 的数据怎么是 0” 我当场愣住脚本没报错、文件也生成了数就是个错的。查了半天发现是推广平台把接口返回里的name字段改成了channel_name而我的代码里还在按name取值。pandas 的merge找不到对应列就把那一列整个变成了空值再一fillna(0)数据就神不知鬼不觉地被写成了 0。这种问题比崩溃更阴险——它不说“我错了”而是用一个 0 去填充缺失值让你根本察觉不到。从那以后我做了两个改动把外键字段名做成一个列名映射表放在脚本开头统一管理平台改一个字段我改一行就行。在merge之前加一个字段存在性检查发现关键列不在时就立刻 raise 报错而不是带着缺列继续跑。REQUIRED_ORDER_COLUMNS [order_id, channel, amount] REQUIRED_PROMO_COLUMNS [channel_name, cost, click_cnt] def validate_columns(df, required, source_name): missing [col for col in required if col not in df.columns] if missing: raise ValueError(f{source_name} 缺少字段: {missing}) # 调用处 validate_columns(orders, REQUIRED_ORDER_COLUMNS, 订单CSV) promo promo.rename(columns{channel_name: name}) validate_columns(promo, REQUIRED_PROMO_COLUMNS, 推广平台)我后来总结宁可让脚本崩在明处也不要让错数淹没在静悄悄的空值里。这是所有数据处理脚本都应该刻在心里的原则。3.3 第三道坎定时任务里为什么“找不到 pandas”脚本跑了快两周天天手动执行也嫌烦我准备把它挂到系统自带的计划任务程序里实现真正的无人值守。结果折腾到半夜直接在命令行执行没问题一到定时任务里就报ModuleNotFoundError: No module named pandas。这个问题的根子是环境差异。命令行里用的 Python 是我手动装过依赖的那个解释器而计划任务默认配置可能指向了系统自带的另一个 Python或者启动目录不对导致脚本里的文件路径全都紊乱。我的排查分了三步在计划任务里加一行“记录当前 Python 路径”的日志确认它跑的到底是哪个解释器。改用虚拟环境里 Python 的绝对路径来执行任务比如C:\venv\daily-report\Scripts\python.exe。脚本内部所有路径全部改成基于Path(__file__).parent的绝对路径不依赖任务的工作目录。这里尤其要记住第三条千万不要在脚本里写相对路径。定时任务从哪个目录启动完全是随机的你今天在项目目录里测得好好的明天计划任务把它放在系统目录里启动文件就写到别处去了。这个问题非常典型。为了彻底避免“中午跑一次、下午又跑一次”造成数据重复我还在脚本里加了一个“当日是否已生成”的时间戳判断如果当天的输出文件已经存在就直接跳过数据处理阶段只发一条“今日日报已生成”的提醒。三次踩坑过后我的脚本才算真正进入稳定期。下面这张表是我事后整理的复制给团队里其他人看也一目了然故障现象根因排查手段最终方案中文乱码脚本崩溃CSV 编码不匹配记事本查编码、尝试多编码读取按 utf-8/gbk/gb18030 逐级回退数据全部变 0平台字段改名merge 后空值被填充对比接口文档、打印列名字段映射表 关键字段存在性校验定时任务找不到 pandas计划任务用了错误的 Python 环境日志输出 Python 可执行文件路径设置虚拟环境绝对路径路径全部基于脚本所在目录3.4 webhook 推送也会失败给脚本加一道重试推送那条也不例外。有一次群里迟迟没收到日报最后发现是外部 webhook 服务临时抖动返回了 502。这种事不是每天发生但一旦发生整个无人值守链路就断在最后一步。我给推送函数加了一个简单的重试机制最多重试 3 次间隔按 1 秒、3 秒、9 秒递增。def push_with_retry(webhook_url: str, content: str, retries: int 3): for attempt in range(1, retries 1): try: resp requests.post(webhook_url, json{ msgtype: text, text: {content: content} }, timeout15) resp.raise_for_status() return True except Exception: if attempt retries: # 最后一次也失败本地写一个失败标记人工介入 (BASE_DIR / push_failed.flag).write_text( time.strftime(%Y-%m-%d %H:%M:%S), encodingutf-8 ) raise time.sleep(3 ** attempt)重试不是越多越好3 次足够覆盖绝大多数瞬时故障如果 3 次都不行那我宁可让它停下来报警也不要让它无限重试把消息发重。另外最后那次失败我额外写了个push_failed.flag标记文件——这是我给自己留的“一眼就能看到今天出事了”的信号比翻日志快多了。4. 让脚本活过三个月日志、配置和失败也能自己爬起来的机制一个脚本从“能跑”到“长期稳定跑”差别不在于业务逻辑多复杂而在于它面对异常时的表现。这就像雇了个实习生活儿干得好是基本要求更重要的是出了问题它得让你知道而不是默不作声地搞砸。4.1 日志不是写给电脑看的是写给三周后的自己看的第一版脚本里我用的全是print输出还带着中文Windows 控制台默认编码对中文支持时好时坏。改用标准库logging之后一切清爽了。我的做法是同时输出到控制台和文件文件按天轮转保留最近 7 天避免 logs 目录无限膨胀。import logging from logging.handlers import TimedRotatingFileHandler log_dir BASE_DIR / logs log_dir.mkdir(exist_okTrue) logger logging.getLogger(daily_report) logger.setLevel(logging.INFO) fmt logging.Formatter(%(asctime)s %(levelname)s %(message)s) file_handler TimedRotatingFileHandler( log_dir / run.log, whenmidnight, backupCount7 ) file_handler.setFormatter(fmt) console_handler logging.StreamHandler() console_handler.setFormatter(fmt) logger.addHandler(file_handler) logger.addHandler(console_handler)为什么要写日志因为脚本出问题时第一件事永远是回去查“它当时做了什么”。没有日志一切排查都得从头猜。尤其是定时任务里的问题错过了现场再去看一片空白那真的是抓瞎。4.2 配置外置别让 URL 和密钥硬编码在代码里脚本跑稳定后我把它交给了负责日报的同事维护。结果他拿到代码的第一句话就是“这些网址和 Webhook 地址我总不能改你的代码再跑吧”他说得对。于是我把所有环境相关的内容抽到了一个叫config.py的独立文件里统一管理# config.py DATA_CSV_URL https://example.com/api/orders.csv PROMO_JSON_URL https://example.com/api/promo.json WEBHOOK_URL https://example.com/robot/webhook OUTPUT_DIR_NAME output DATA_DIR_NAME data REPORT_OWNER 运营日报项目组脚本本体里只引用config.xxx坚决不出现任何与实际环境绑定的字面量。这样换电脑、换人交接、迁移到服务器都只需要改一个文件。如果哪天要接密钥管理系统也只需要改这一个文件。4.3 失败报警要“吵”成功通知要“静”我在这个脚本里有一个很个人化的设计成功时不推送多余消息失败时一定推送报警。刚开始设计时我在 webhook 里推了“生成成功”的消息结果群里每天上午 9 点准时刷屏大家一开始还点开看看后来全当噪音。于是我把成功通知改成了“仅推送文件名和摘要信息”并且合并到日报正文里不再单独发一条“成功”。失败就完全不一样了。一旦脚本任何一步抛异常我就会收到一条醒目的报警消息带出日志文件路径。这样哪怕我在地铁上也能秒懂今天数据链路出问题了而不是等同事跑来问我“今天日报呢”。失败报警的代码逻辑很简单就是在main()外面包一层总异常捕获def main(): try: run_daily_report() except Exception: logger.exception(日报生成任务执行失败) push_with_retry(config.WEBHOOK_URL, 今天日报脚本挂了快看日志) raise这里我用logger.exception而不是logger.error会把完整堆栈打到日志里方便我就是躺床上排查问题也能定位到具体行。4.4 交接文档写给三个月后就会失忆的自己最后我想安利一个很多人忽略的东西README。哪怕这个脚本从头到尾就只有你一个人在用也请写一个 50 行的 README记录三件事——脚本是干什么的、怎么跑、遇到常见问题怎么办。我是吃了亏才这么说的。脚本上线两个月后某天它突然不跑了我打开自己写的代码盯着那个pd.merge发呆了半天愣是没想起来当初为什么要rename那一列。后来翻到自己很久之前随手写的注释才缓过来。注释和文档不是写给别人看的是写给三个月后会失忆的自己。5. 脚本写完之后我那套“自动化值不值”的半量化判断现在这个日报脚本已经稳定跑了很久每天的流程是定时任务自动拉数、算数、出 Excel、推送群消息偶尔数据源字段变了它会报警我花五分钟改一下字段映射表继续跑。它带给我的不是“每天省十五分钟”这么简单而是把一种“这件事可以交给代码”的思考方式种在了我脑子里。5.1 自动化的优先级排序先半自动再全自动回看整个过程我最受益的一个策略是“分两阶段推进”第一阶段先做半自动——脚本负责所有计算和文件生成人负责触发并做最后检查第二阶段再上全自动——挂定时任务加失败报警彻底放手。不要一上来就追求无人值守。人还在回路里的时候你对脚本的每个输出都是有感知的“这列数不对”“这个格式不满意”都会立刻反馈进下一版代码里。等你能连续一周对脚本输出无感再切全自动成功率会高很多。5.2 判断任务能不能自动化的清单经过这个项目我把开头那四条判断标准打磨成了一张更实用的清单。之后我评估任何重复性工作时都拿它过一遍这件事是不是每“天/周/月”固定发生完成这件事的步骤是不是有标准答案不需要临场判断做错了后果可控吗最坏情况是什么有没有一条客观标准能说明“做完了/做对了”如果脚本出了问题你能不能快速发现如果五个问题都是肯定回答那这个任务大概率适合自动化。只要有一条是否定回答就得认真掂量一下——尤其是“不需要临场判断”这条它往往是项目烂尾的最主要原因。5.3 从单点自动化到批量复制的边界脚本跑顺之后团队里也有人来问能不能把周报也自动化。我的回答是可以但别急着写代码先把周报的规则、模板、数据来源整理成文档规则不清晰之前不要碰代码。事实上后来我把同一套“下载-解析-合并-推送”模板复制到另一个核对脚本上只花了半小时——因为核心的日志、重试、编码处理都是现成的。但我也很清楚自动化的边界在哪凡是需要审批、需要人签字、需要对外沟通的环节我不会尝试用脚本替代。那种事情的价值恰恰在于“人参与的判断”而不是执行的速度。脚本能做的是把判断材料准备好让人的判断更高效。现在如果有人问我“自动化你的日常工作”从哪开始我通常会说先别急着学框架、搭平台找一个你每天早上最不想干的固定任务把它拆成四步然后用最简单的脚本串起来再花两周让它变稳。等它变成你生活里理所当然的一部分你就再也回不去手点了。 
长河君 · 2026/10/15 5:30:12 · 阅读 1.2k Python日报自动化实践：从任务筛选到稳定运行的全流程指南
先拔高一句真正的自动化不是从“我要写个 Python 脚本”那一刻开始的而是从某一天你实在不想再打开第五个网页、复制粘贴三张表、然后手工填一张日报开始的。我手里这个脚本就是这么诞生的——它不是什么高深系统就一个每天替我跑数据、发日报的 Python 脚本但围绕它的整个思考过程、踩坑过程、迭代过程我想完整记下来给所有想把重复工作外包给代码的读者一条能直接照走的路径。这篇博文主要讲三件事怎么判断一件事值不值得自动化、脚本第一版长什么样、以及从“能跑”到“好用”中间到底要过几道坎。适合那种已经会用 Python 写点小工具、但还没正经做过一个长期自动化任务的开发者也适合天天在做报表、盯数据、发通知的运营同学——你不需要懂太多抄思路就行。1. 先别急着写代码挑一个真正值得自动化的任务我想先说一个经常被忽略的事实大部分人的第一版自动化脚本都死在了“选错题目”上。有人想自动化订会议室折腾半天发现公司系统接口权限不够有人想自动生成竞品报告结果每天规则都在变脚本修的时间比手点还长。所以真正动手之前得先弄清楚一个任务合不合适。1.1 我选中的那个任务每天上午的“抄数”工作当时我手上有个特别让心烦的日常活每天早上十点前要把前一天的运营情况整理成一张日报发到群里。具体拆开是四步——先从内部数据后台导出一份昨天新增订单的 CSV再从外部推广平台打开活动数据页面把那几个数摘下来最后在 Excel 里把两拨数据按渠道合并、算个汇总截图加文字说明发出去。整套动作熟练的话要十二到十五分钟不熟练的时候能拖到二十分钟。听起来不多但它是每天固定发生的事而且极无聊。最开始我还在心里算过账每天十五分钟一个月就是五个多小时一年六十多个小时——足够读完好几本技术书了。这个任务当时符合我判断自动化的全部标准我后来把它总结成四条。重复频率高、周期稳定。每天都要做不是那种一个月碰一次的杂事。规则清晰且固定。“哪些列合并”“按哪个字段分组”“最终输出什么格式”每一环都有明确答案几乎不需要人为判断。出错代价低、试错空间大。日报晚发十分钟、发错一个数内部消化一下就行不会引发事故。这意味着脚本就算一开始写得烂也不会造成灾难。验收标准极其客观。好不好用就看一件事上午十点前日报发出去了没有数据对不对。这四条缺一不可。反过来看那些“想做自动化但迟迟没动手”的朋友多半是卡在了第二条或第四条上——规则天天变或者事情本身没有硬性交付物那确实不适合一开始就拿代码硬啃。1.2 一个半量化的判断方法两个月回收开发成本除了这四条我还会做一个简单的成本估算帮自己判断“值不值得写”。假设一件事我每天花 T 分钟一个月按22个工作日算就是 22T 分钟。如果我用 H 个小时开发脚本那么只要满足下面这个式子这件事就值得自动化H × 60 22T × 回收月份数 × 2为什么乘以 2因为脚本运行本身也要维护而且写出来的代码至少要留出等量的时间去调试、改 bug。我的习惯是期望回收周期不超过两个月。如果写一个脚本要花 5 小时它必须每天至少帮我省 12 分钟才划算如果它每天只能省 5 分钟那我顶多给它两小时的预算。当时我给自己定的目标是4 小时以内写一个能用的第一版。实际写下来差不太多加上后续迭代其实超了一些但因为有这个预算在先我不会陷入“试试看能不能顺手做个大系统”的泥潭——这是很多人写自动化脚本最大的坑目的本来是省时间结果代码写成了全功能平台。1.3 没选的任务为什么我不碰“看起来更值钱”的方向顺带说一下我没选什么。团队里当时还有个更“高级”的想法自动做数据周报的 PPT把图表、结论、建议全生成出来。听着很酷但仔细一想周报的模板每季度都在换领导偶尔还会临时换分析角度这种依赖人审美判断的任务自动化程度越高维护成本越离谱。还有一个想法是自动巡检服务器日志那确实有价值但权限体系和告警通路都比较复杂短期内交付不了。这两个例子给我的经验是自动化初期要挑“又小又硬”的任务别挑“又大又软”的任务。小是指范围小、流程短硬是指规则硬、边界硬。等一个脚本跑稳了再逐步扩大也来得及。2. 第一版只干四件事用最省的代码跑通全流程选好任务之后我没有立刻铺开写代码而是先在纸上把那条日报的生产流水线画了一遍。最终确定的处理流程只有四个环节拉取数据、解析数据、合并生成报表、推送通知。画完之后我自己都笑了——这不就是个普通的 ETL 加一个消息钩子么。第一版我给自己立了个规矩绝不做“顺手”之外的多余功能比如自动画图表、自动生成分析文字第一版都不碰。目的只有一个——先让“十点前发出日报”这件事拜托人工。2.1 技术选型为什么是 requests、pandas 和 openpyxl依赖库我选了三个都不是冷门后续接手运维也方便。requests用来下载 CSV、调用平台 API、最后推送到群机器人 webhook。这是 Python 生态里最通用的 HTTP 客户端没有悬念。pandas用来读 CSV、读 JSON、按渠道分组汇总。我知道有人会说“就几行数据自己写列表推导不就行了”但 pandas 真正的价值不在于大数处理而在于它对不规整输入的容忍度。数据源有可能多了空行、少了表头、出现整列的缺失值pandas 处理这些情况的兜底方式比手工要稳得多。openpyxl最终要输出一个格式干净的 Excel 文件给团队看。虽然直接用 pandas 的to_excel也能写但 openpyxl 能让我控制列宽、加粗、冻结首行这些细节哪怕第一版没时间做后续加也方便。选型逻辑就一句话用最顺手、团队里别人接手也不慌的库不要为了炫技引入冷门框架。2.2 核心代码骨架我第一版就写了这么点东西第一版脚本我控制在了 150 行左右去掉注释和空行真正干事的代码不超过 100 行。核心逻辑拆开看很简单先看主流程from pathlib import Path import json import time import requests import pandas as pd BASE_DIR Path(__file__).parent DATA_DIR BASE_DIR / data OUTPUT_DIR BASE_DIR / output DATA_DIR.mkdir(exist_okTrue) OUTPUT_DIR.mkdir(exist_okTrue) def download_orders_csv(url: str) - str: 从内部后台下载订单明细 CSV返回本地文件路径 resp requests.get(url, timeout15) resp.raise_for_status() file_path DATA_DIR / forders_{time.strftime(%Y%m%d)}.csv file_path.write_bytes(resp.content) return str(file_path) def load_promotion_json(url: str) - dict: 从推广平台拉取当日活动数据 resp requests.get(url, timeout15) resp.raise_for_status() return resp.json() def build_report(csv_path: str, promotion_data: dict) - Path: 合并两个数据源生成日报 Excel orders pd.read_csv(csv_path) promo pd.DataFrame(promotion_data[channels]) # 按渠道统计订单量、销售额 order_stats ( orders.groupby(channel, as_indexFalse) .agg(order_cnt(order_id, count), order_amount(amount, sum)) ) merged pd.merge(order_stats, promo, left_onchannel, right_onname, howouter).fillna(0) total_orders merged[order_cnt].sum() total_amount merged[order_amount].sum() merged.loc[合计] [, , total_orders, total_amount, , ] output_path OUTPUT_DIR / fdaily_report_{time.strftime(%Y%m%d)}.xlsx with pd.ExcelWriter(output_path, engineopenpyxl) as writer: merged.to_excel(writer, indexFalse, sheet_name日报) return output_path def push_to_group(webhook_url: str, content: str): 推送到群机器人 payload {msgtype: text, text: {content: content}} resp requests.post(webhook_url, jsonpayload, timeout15) resp.raise_for_status() def main(): orders_csv download_orders_csv(https://example.com/api/orders.csv) promo_data load_promotion_json(https://example.com/api/promo.json) report_path build_report(orders_csv, promo_data) push_to_group( https://example.com/robot/webhook, f日报已生成文件{report_path.name}请查收。 ) if __name__ __main__: main()注意这里面example.com是我随手写的占位符你实际替换成自己的数据源地址就行。第一版没有复杂的东西没有异常处理、没有重试机制、没有日志异常全看控制台输出。我甚至没有把它做成定时的前三天都是上午手动跑一下python daily_report.py确认输出文件没问题再发群。这其实是我刻意保留的“人肉保险”。一个脚本第一次上手就跑所谓“全自动”很容易在无人值守时悄悄出错然后等你发现时已经连着错了三天。让脚本先“半自动”地跑一阵子每跑一次你都能亲眼看到输出对培养信任感非常重要。2.3 为什么很多人的第一版卡在“想太多”写到这我想多说一句。我发现很多想学自动化的同事第一版代码总是失败在“试图一次到位”。明明只需要下载一个 CSV非要去研究 API 鉴权体系明明合并两张小表非要起一个数据库。结果半天过去连第一个数据都还没打印出来。第一版脚本的最高原则是先让链路通起来哪怕丑一点。下载就直接写requests.get合并就直接pd.merge推送就直接调 webhook别在这之前引入任何基础设施。你追求的不是架构之美而是“今天上午十点前我不用亲自点那五下鼠标了”。3. “能跑”到“好跑”的三道坎编码、表头变动和定时任务环境第一版跑通之后我对着那个命令行里滚动的日志开心了两天接着就开始迎接一个又一个现场事故。这些事故才是这篇博文最值钱的部分因为代码骨架谁都能看坑只有踩过才知道。3.1 第一道坎CSV 里的中文全是乱码脚本直接崩溃脚本上线的第二天早上我打开output文件夹一看文件没生成控制台报了一大段 UnicodeDecodeError。定眼一看是 CSV 那一步挂的——我们内部后台导出的文件是 GBK 编码的而 pandas 默认用 UTF-8 去读遇到中文和特殊符号直接解码失败。排查思路其实很简单先用记事本打开 CSV 看一眼右下角编码或者用file命令看编码类型更直接的办法是写个循环尝试几种常见编码。我的修复方案是加一个“编码探测 回退”的逻辑def read_csv_smart(path): for encoding in (utf-8, gbk, gb18030): try: return pd.read_csv(path, encodingencoding) except UnicodeDecodeError: continue raise ValueError(f无法识别文件编码: {path})gb18030是gbk的超集能兼容更多生僻字符。这套方案一劳永逸地解决了“今天能读明天不能读”的怪问题。踩完这次我意识到做数据自动化第一件事永远先搞清楚文件编码而不是业务逻辑。3.2 第二道坎推广平台改了字段名Markdown 没提醒我有一阵子脚本连续几天跑得好好的直到某天同事问我“今天渠道 K 的数据怎么是 0” 我当场愣住脚本没报错、文件也生成了数就是个错的。查了半天发现是推广平台把接口返回里的name字段改成了channel_name而我的代码里还在按name取值。pandas 的merge找不到对应列就把那一列整个变成了空值再一fillna(0)数据就神不知鬼不觉地被写成了 0。这种问题比崩溃更阴险——它不说“我错了”而是用一个 0 去填充缺失值让你根本察觉不到。从那以后我做了两个改动把外键字段名做成一个列名映射表放在脚本开头统一管理平台改一个字段我改一行就行。在merge之前加一个字段存在性检查发现关键列不在时就立刻 raise 报错而不是带着缺列继续跑。REQUIRED_ORDER_COLUMNS [order_id, channel, amount] REQUIRED_PROMO_COLUMNS [channel_name, cost, click_cnt] def validate_columns(df, required, source_name): missing [col for col in required if col not in df.columns] if missing: raise ValueError(f{source_name} 缺少字段: {missing}) # 调用处 validate_columns(orders, REQUIRED_ORDER_COLUMNS, 订单CSV) promo promo.rename(columns{channel_name: name}) validate_columns(promo, REQUIRED_PROMO_COLUMNS, 推广平台)我后来总结宁可让脚本崩在明处也不要让错数淹没在静悄悄的空值里。这是所有数据处理脚本都应该刻在心里的原则。3.3 第三道坎定时任务里为什么“找不到 pandas”脚本跑了快两周天天手动执行也嫌烦我准备把它挂到系统自带的计划任务程序里实现真正的无人值守。结果折腾到半夜直接在命令行执行没问题一到定时任务里就报ModuleNotFoundError: No module named pandas。这个问题的根子是环境差异。命令行里用的 Python 是我手动装过依赖的那个解释器而计划任务默认配置可能指向了系统自带的另一个 Python或者启动目录不对导致脚本里的文件路径全都紊乱。我的排查分了三步在计划任务里加一行“记录当前 Python 路径”的日志确认它跑的到底是哪个解释器。改用虚拟环境里 Python 的绝对路径来执行任务比如C:\venv\daily-report\Scripts\python.exe。脚本内部所有路径全部改成基于Path(__file__).parent的绝对路径不依赖任务的工作目录。这里尤其要记住第三条千万不要在脚本里写相对路径。定时任务从哪个目录启动完全是随机的你今天在项目目录里测得好好的明天计划任务把它放在系统目录里启动文件就写到别处去了。这个问题非常典型。为了彻底避免“中午跑一次、下午又跑一次”造成数据重复我还在脚本里加了一个“当日是否已生成”的时间戳判断如果当天的输出文件已经存在就直接跳过数据处理阶段只发一条“今日日报已生成”的提醒。三次踩坑过后我的脚本才算真正进入稳定期。下面这张表是我事后整理的复制给团队里其他人看也一目了然故障现象根因排查手段最终方案中文乱码脚本崩溃CSV 编码不匹配记事本查编码、尝试多编码读取按 utf-8/gbk/gb18030 逐级回退数据全部变 0平台字段改名merge 后空值被填充对比接口文档、打印列名字段映射表 关键字段存在性校验定时任务找不到 pandas计划任务用了错误的 Python 环境日志输出 Python 可执行文件路径设置虚拟环境绝对路径路径全部基于脚本所在目录3.4 webhook 推送也会失败给脚本加一道重试推送那条也不例外。有一次群里迟迟没收到日报最后发现是外部 webhook 服务临时抖动返回了 502。这种事不是每天发生但一旦发生整个无人值守链路就断在最后一步。我给推送函数加了一个简单的重试机制最多重试 3 次间隔按 1 秒、3 秒、9 秒递增。def push_with_retry(webhook_url: str, content: str, retries: int 3): for attempt in range(1, retries 1): try: resp requests.post(webhook_url, json{ msgtype: text, text: {content: content} }, timeout15) resp.raise_for_status() return True except Exception: if attempt retries: # 最后一次也失败本地写一个失败标记人工介入 (BASE_DIR / push_failed.flag).write_text( time.strftime(%Y-%m-%d %H:%M:%S), encodingutf-8 ) raise time.sleep(3 ** attempt)重试不是越多越好3 次足够覆盖绝大多数瞬时故障如果 3 次都不行那我宁可让它停下来报警也不要让它无限重试把消息发重。另外最后那次失败我额外写了个push_failed.flag标记文件——这是我给自己留的“一眼就能看到今天出事了”的信号比翻日志快多了。4. 让脚本活过三个月日志、配置和失败也能自己爬起来的机制一个脚本从“能跑”到“长期稳定跑”差别不在于业务逻辑多复杂而在于它面对异常时的表现。这就像雇了个实习生活儿干得好是基本要求更重要的是出了问题它得让你知道而不是默不作声地搞砸。4.1 日志不是写给电脑看的是写给三周后的自己看的第一版脚本里我用的全是print输出还带着中文Windows 控制台默认编码对中文支持时好时坏。改用标准库logging之后一切清爽了。我的做法是同时输出到控制台和文件文件按天轮转保留最近 7 天避免 logs 目录无限膨胀。import logging from logging.handlers import TimedRotatingFileHandler log_dir BASE_DIR / logs log_dir.mkdir(exist_okTrue) logger logging.getLogger(daily_report) logger.setLevel(logging.INFO) fmt logging.Formatter(%(asctime)s %(levelname)s %(message)s) file_handler TimedRotatingFileHandler( log_dir / run.log, whenmidnight, backupCount7 ) file_handler.setFormatter(fmt) console_handler logging.StreamHandler() console_handler.setFormatter(fmt) logger.addHandler(file_handler) logger.addHandler(console_handler)为什么要写日志因为脚本出问题时第一件事永远是回去查“它当时做了什么”。没有日志一切排查都得从头猜。尤其是定时任务里的问题错过了现场再去看一片空白那真的是抓瞎。4.2 配置外置别让 URL 和密钥硬编码在代码里脚本跑稳定后我把它交给了负责日报的同事维护。结果他拿到代码的第一句话就是“这些网址和 Webhook 地址我总不能改你的代码再跑吧”他说得对。于是我把所有环境相关的内容抽到了一个叫config.py的独立文件里统一管理# config.py DATA_CSV_URL https://example.com/api/orders.csv PROMO_JSON_URL https://example.com/api/promo.json WEBHOOK_URL https://example.com/robot/webhook OUTPUT_DIR_NAME output DATA_DIR_NAME data REPORT_OWNER 运营日报项目组脚本本体里只引用config.xxx坚决不出现任何与实际环境绑定的字面量。这样换电脑、换人交接、迁移到服务器都只需要改一个文件。如果哪天要接密钥管理系统也只需要改这一个文件。4.3 失败报警要“吵”成功通知要“静”我在这个脚本里有一个很个人化的设计成功时不推送多余消息失败时一定推送报警。刚开始设计时我在 webhook 里推了“生成成功”的消息结果群里每天上午 9 点准时刷屏大家一开始还点开看看后来全当噪音。于是我把成功通知改成了“仅推送文件名和摘要信息”并且合并到日报正文里不再单独发一条“成功”。失败就完全不一样了。一旦脚本任何一步抛异常我就会收到一条醒目的报警消息带出日志文件路径。这样哪怕我在地铁上也能秒懂今天数据链路出问题了而不是等同事跑来问我“今天日报呢”。失败报警的代码逻辑很简单就是在main()外面包一层总异常捕获def main(): try: run_daily_report() except Exception: logger.exception(日报生成任务执行失败) push_with_retry(config.WEBHOOK_URL, 今天日报脚本挂了快看日志) raise这里我用logger.exception而不是logger.error会把完整堆栈打到日志里方便我就是躺床上排查问题也能定位到具体行。4.4 交接文档写给三个月后就会失忆的自己最后我想安利一个很多人忽略的东西README。哪怕这个脚本从头到尾就只有你一个人在用也请写一个 50 行的 README记录三件事——脚本是干什么的、怎么跑、遇到常见问题怎么办。我是吃了亏才这么说的。脚本上线两个月后某天它突然不跑了我打开自己写的代码盯着那个pd.merge发呆了半天愣是没想起来当初为什么要rename那一列。后来翻到自己很久之前随手写的注释才缓过来。注释和文档不是写给别人看的是写给三个月后会失忆的自己。5. 脚本写完之后我那套“自动化值不值”的半量化判断现在这个日报脚本已经稳定跑了很久每天的流程是定时任务自动拉数、算数、出 Excel、推送群消息偶尔数据源字段变了它会报警我花五分钟改一下字段映射表继续跑。它带给我的不是“每天省十五分钟”这么简单而是把一种“这件事可以交给代码”的思考方式种在了我脑子里。5.1 自动化的优先级排序先半自动再全自动回看整个过程我最受益的一个策略是“分两阶段推进”第一阶段先做半自动——脚本负责所有计算和文件生成人负责触发并做最后检查第二阶段再上全自动——挂定时任务加失败报警彻底放手。不要一上来就追求无人值守。人还在回路里的时候你对脚本的每个输出都是有感知的“这列数不对”“这个格式不满意”都会立刻反馈进下一版代码里。等你能连续一周对脚本输出无感再切全自动成功率会高很多。5.2 判断任务能不能自动化的清单经过这个项目我把开头那四条判断标准打磨成了一张更实用的清单。之后我评估任何重复性工作时都拿它过一遍这件事是不是每“天/周/月”固定发生完成这件事的步骤是不是有标准答案不需要临场判断做错了后果可控吗最坏情况是什么有没有一条客观标准能说明“做完了/做对了”如果脚本出了问题你能不能快速发现如果五个问题都是肯定回答那这个任务大概率适合自动化。只要有一条是否定回答就得认真掂量一下——尤其是“不需要临场判断”这条它往往是项目烂尾的最主要原因。5.3 从单点自动化到批量复制的边界脚本跑顺之后团队里也有人来问能不能把周报也自动化。我的回答是可以但别急着写代码先把周报的规则、模板、数据来源整理成文档规则不清晰之前不要碰代码。事实上后来我把同一套“下载-解析-合并-推送”模板复制到另一个核对脚本上只花了半小时——因为核心的日志、重试、编码处理都是现成的。但我也很清楚自动化的边界在哪凡是需要审批、需要人签字、需要对外沟通的环节我不会尝试用脚本替代。那种事情的价值恰恰在于“人参与的判断”而不是执行的速度。脚本能做的是把判断材料准备好让人的判断更高效。现在如果有人问我“自动化你的日常工作”从哪开始我通常会说先别急着学框架、搭平台找一个你每天早上最不想干的固定任务把它拆成四步然后用最简单的脚本串起来再花两周让它变稳。等它变成你生活里理所当然的一部分你就再也回不去手点了。