用Python自动化日常工作：从脚本到团队工具的完整实践-代码聚汇网

用Python自动化日常工作：从脚本到团队工具的完整实践

理柴德波浪技术·2026-08-29·阅读 23 GEO检测（免费）

Python自动化脚本

|难度：普通|阅读约 41 分钟

每周五下午三点，我都会坐在工位上做一件极其机械的事情：打开Git提交记录，逐个项目翻阅本周的代码改动，把每个模块的进展复制到邮件里，再根据提交人整理成一份像样的周报。这件事持续时间不长，大概半小时到一小时，但它吞噬的是周五下午最宝贵的连续时间。直到有一天，我把这份周报的模板、数据源和输出格式完整梳理了一遍，用大约120行Python写了一个脚本，从此每周五只需要双击运行，喝杯水回来邮件就躺在已发送里了。

这就是我想在这篇文章里分享的东西：一个自动化脚本是怎么从“我懒得干了”这个念头开始，逐步变成一个稳定、可复用、甚至能交给同事使用的工具。标题叫“自动化你的日常工作”，但我不想只给你一段代码复制粘贴，我想带你走一遍完整的思考过程——哪些工作值得自动化、怎么拆解需求、怎么写第一版能跑的代码、上线后踩了哪些坑、以及怎么让它从“我自己的小脚本”变成“团队里的正经工具”。不管你是刚接触Python，还是已经写了几年但主要在做业务，这篇都值得往下看。

1. 动手写代码之前，先想清楚“哪些活值得被自动化”

很多人对自动化的理解是“能用脚本解决的事绝不手动做”，这个方向没错，但很容易走火入魔。我见过有人花三个小时写脚本，就为了省下每天两分钟的机械操作，结果脚本维护成本远超节省的时间。这不是自动化，这是自嗨。

1.1 判断任务是否适合自动化：频率、耗时与规则强度

我判断一个日常工作值不值得自动化，基本看四个维度：

判断维度	关键问题	我的经验阈值
频率	这件事多久做一次？	每周至少1次，越频繁越值得做
单次耗时	每次做要花多长时间？	单次超过15分钟，自动化收益就很大
规则强度	流程是否清晰、步骤是否固定？	规则越明确，脚本越好写
容错空间	做错了是否会造成严重后果？	低风险任务优先自动，高风险任务要谨慎

如果一个任务满足“每周都做+单次超过20分钟+步骤固定+错误可接受”，那它就是自动化的首选目标。拿我的周报来说，它完全命中：每周一次性，耗时半小时以上，流程就是从几个固定数据源提取信息，按固定模板拼接成邮件，而且就算偶尔数据不准确，也不会有严重的业务影响——顶多改一下再发。

反过来，那些每天只花两分钟、但又特别容易出错的操作，我反而不建议优先自动化。因为这种任务的频率虽然高，但单次耗时太短，脚本的启动和测试成本可能比手动操作还高，性价比不够。

1.2 把“模糊的痛点”翻译成“精确的需求”

确定要自动化的任务之后，下一步是把脑子里“我很烦这件事”的模糊感受，变成一份可以执行的精确需求。这一步做不好，后面写代码就是瞎写。

具体做法是：花15分钟，把这件事的手动流程一步步写下来。注意，是每一步，哪怕“打开浏览器”“点击登录”“输入账号”这种细节也要写。写完之后你会发现，很多你以为“必须人工判断”的环节，其实是完全规则化的；而真正需要动脑子的环节，会清晰地暴露出来，这些就是你需要在脚本里保留人工介入的地方。

我当年写周报脚本时做的需求拆解大致长这样：

读取最近7天的Git提交记录，涉及5个项目仓库
按提交人分组，统计每个人的提交次数和涉及模块
从公司周报系统导出本周的任务列表
把Git数据和任务列表合并，按模板生成Markdown格式的周报
把周报粘贴到邮件正文，按固定收件人列表发送

拆完需求我才发现，整件事里真正需要“我”的智力判断的，只有一步：哪些提交属于“重要变更”需要写进周报，哪些只是日常维护不值得提。其他环节全是机械执行。那我的设计思路就清楚了：脚本处理所有机械环节，把“筛选重要变更”这一步留给我来确认，脚本先把所有变更列出来，我勾选后它再生成最终邮件。

1.3 不要一上来就追求“全自动”，半自动往往是更优解

这里我想强调一个我踩过好几次坑之后才想明白的道理：自动化不等于全自动。

全自动当然很酷，脚本跑完所有事情，连确认都省了。但现实世界中，全自动方案往往意味着你要处理大量边界情况、异常分支、权限问题，开发周期可能是半自动方案的三到五倍。而且，一旦全自动脚本的某个环节出了问题，你可能要花比手动操作更多的时间去排查。

我的经验是，第一版脚本做“半自动”就好：脚本把繁琐的提取、拼接、格式化全部做掉，最后生成一份草稿，你快速过目，确认无误后一键发送。这样既节省了90%的时间，又保留了对最终结果的把控权。等脚本稳定运行一个月后，如果你对它的正确性有了足够信心，再考虑把“确认”这个环节也自动化掉也不迟。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 环境准备与第一个脚本骨架：从零到能跑

需求梳理清楚了，接下来才是真正动手写代码。这一节我会从环境准备讲起，但你不用紧张——我不打算搞那种“必装必备、少一个都不行的全家桶”清单，我只讲我实际用的、新项目起步时最快的组合。

2.1 Python环境与编辑器：用最省心的组合起步

如果你电脑上还没装Python，直接去官网下载最新的稳定版即可。安装的时候记得勾选“Add Python to PATH”，这一步能避免后续在命令行里找不到Python的尴尬。安装完成后，打开终端（Windows上是PowerShell或CMD，macOS上是Terminal），输入python --version，能看到版本号说明环境就绪了。

编辑器方面，新手推荐VS Code，装上Python插件之后，代码补全、调试、虚拟环境管理都内置了，基本够用。如果你不喜欢折腾IDE，直接用系统自带的文本编辑器也能写Python，但体验会差很多。我个人日常用的是VS Code作为主力编辑器，偶尔用PyCharm跑大型项目，但如果你只是写自动化脚本，VS Code完全足够。

虚拟环境是我强烈建议从第一天就养成的习惯。python -m venv venv创建虚拟环境，激活后安装的第三方库只属于当前项目，不会污染全局环境。这个习惯早期觉得多余，等你同时维护五六个脚本项目时，就知道多省心了。

2.2 一个最小能跑的脚本长什么样

让我用最直白的方式，给你一个“能跑”的脚本骨架，这也正是我的周报脚本第一版的样子：

python复制# -*- coding: utf-8 -*-
"""工作日报自动生成脚本 - 第一版"""
import datetime

def get_date_range():
    """获取最近一周的日期范围"""
    today = datetime.date.today()
    start = today - datetime.timedelta(days=7)
    return start, today

def main():
    start, end = get_date_range()
    print(f"正在生成本周（{start} 至 {end}）的工作日报……")
    # 后续逻辑都在这里扩展

if __name__ == "__main__":
    main()

这段代码总共不到20行，它什么都没做，但它给你搭好了三个最重要的东西：

入口点：if __name__ == "__main__": 保证了只有直接运行这个文件时才会执行main函数，以后你想把这个脚本当模块导入别的地方，也不会误触发执行。
功能分区：get_date_range()这样的小函数，把“计算日期范围”这个逻辑独立出来，方便测试和复用。
可见反馈：用print输出当前状态，别小看这一行，脚本跑起来的时候能看到进度，Debug时的体验天差地别。

写脚本有个非常重要的原则：先跑通，再优化。你第一版的目标不是写得漂亮，而是能运行、输出正确的结果。哪怕中间逻辑写得不够优雅，能跑就行，后续再重构。

2.3 参数化设计：别把数据硬编码在代码里

我第一个周报脚本最大的败笔，就是把项目路径、收件人邮箱、周报模板全部写死在代码里。结果就是：换一台电脑跑，满地都是报错；同事想用我的脚本，得在代码里翻半天找哪里改路径。

后来我吸取教训，引入了外部配置文件。通常我用一个简单的config.json放这些可变的内容：

json复制{
    "projects": [
        {"name": "订单系统", "path": "D:/work/repos/order-system"},
        {"name": "支付中心", "path": "D:/work/repos/payment-center"}
    ],
    "report": {
        "recipients": ["manager@example.com", "team@example.com"],
        "template": "weekly_report_template.md",
        "output_dir": "D:/work/reports"
    }
}

代码里用json.load()读取它，这样脚本就完全变成了一个“通用引擎”，换项目、换收件人、换模板，只需要改配置文件，代码一行都不用动。

这个设计思维非常重要：参数和逻辑分离。它让你的脚本从“一次性工具”进化成“可复用工具”的转折点，也是让同事愿意用你的脚本的前提。

3. 三个高频日常工作场景的自动化实战

前面说的都是方法论和骨架，这一节我用三个实际案例演示Python脚本具体能解决什么问题。这三个场景覆盖了我自己工作中最频繁遇到的类型：数据处理、文件批处理、网络请求与定时任务。每个案例都配有真实可运行的参考代码，并且我会解释每一步为什么这么写。

3.1 数据处理：用Python把Excel表格“炖”成一锅粥

日常工作里最让人头大的，无非是一堆Excel表格要合并、清洗、统计。不用pandas这种重型库，光是Python自带的csv模块就能解决很多痛点。

举个我实际处理过的例子：产品部门每周发来五个城市的销售明细CSV，我要把它们合并成总表，按产品线统计销售额，并且过滤掉金额为空的“脏数据”。手工操作大概20分钟，用脚本20秒搞定：

python复制# -*- coding: utf-8 -*-
"""多城市销售数据合并统计脚本"""
import csv
from collections import defaultdict

# 1. 读取所有分城市的销售数据
def read_sales_files(file_list):
    all_rows = []
    for file_path in file_list:
        with open(file_path, 'r', encoding='utf-8') as f:
            reader = csv.DictReader(f)
            for row in reader:
                all_rows.append(row)
    return all_rows

# 2. 按产品线统计销售额，并过滤空值
def aggregate_by_product(rows):
    stats = defaultdict(float)
    for row in rows:
        product = row['product_line']
        try:
            amount = float(row['sales_amount'])
        except (ValueError, KeyError):
            # 金额为空或者不是数字的直接跳过，不作为异常抛出
            continue
        stats[product] += amount
    return stats

# 3. 输出汇总结果到新CSV
def write_summary(stats, output_path):
    with open(output_path, 'w', encoding='utf-8', newline='') as f:
        writer = csv.writer(f)
        writer.writerow(['product_line', 'total_sales'])
        for product, amount in stats.items():
            writer.writerow([product, round(amount, 2)])

def main():
    files = ['beijing.csv', 'shanghai.csv', 'guangzhou.csv', 'shenzhen.csv', 'hangzhou.csv']
    rows = read_sales_files(files)
    stats = aggregate_by_product(rows)
    write_summary(stats, 'total_sales_summary.csv')
    print(f"处理完成：共合并{len(rows)}条记录，输出{len(stats)}个产品线汇总")

if __name__ == "__main__":
    main()

这个脚本的关键点有两个。第一，用csv.DictReader按列名读取数据，比起按列索引读取可读性强太多，也不容易因为列顺序变化而出错。第二，在aggregate_by_product里，我把金额转换失败的情况当成“脏数据”跳过而不是让程序崩溃，这是真实数据处理里非常重要的容错设计——你永远不知道下游同事会在Excel里填什么奇怪的东西。

3.2 文件批处理：让Python帮你整理“乱七八糟”的下载目录

第二个高频场景是文件和目录的批处理。我自己的下载目录曾经乱到无法直视：各种PDF、图片、安装包、压缩文件混在一起，找一份文件要翻半天。写一个按扩展名自动归档的脚本，一劳永逸：

python复制# -*- coding: utf-8 -*-
"""下载目录自动归档整理脚本"""
import pathlib
import shutil

# 定义分类规则：扩展名 -> 目标文件夹名
CATEGORY_RULES = {
    '.pdf': 'PDF文档',
    '.docx': 'Word文档',
    '.xlsx': 'Excel表格',
    '.jpg': '图片',
    '.png': '图片',
    '.gif': '图片',
    '.zip': '压缩包',
    '.rar': '压缩包',
    '.exe': '软件安装包',
    '.dmg': '软件安装包',
}

def organize_directory(target_dir):
    target = pathlib.Path(target_dir)
    # 遍历目录下的所有文件
    for file_path in target.iterdir():
        if file_path.is_file():  # 跳过子目录，只处理文件
            ext = file_path.suffix.lower()
            category = CATEGORY_RULES.get(ext, '其他文件')
            # 目标目录
            dest_dir = target / category
            dest_dir.mkdir(exist_ok=True)  # 目录不存在就创建
            # 移动文件
            shutil.move(str(file_path), str(dest_dir / file_path.name))
            print(f"已将 {file_path.name} 移动到 {category}/")
    print("归档整理完成")

if __name__ == "__main__":
    organize_directory("C:/Users/YourName/Downloads")

pathlib模块是我非常喜欢的一个Python标准库，它用面向对象的方式处理路径，比字符串拼接路径安全得多。这个脚本用target.iterdir()遍历目录，用suffix取文件扩展名，再用shutil.move移动文件——三行核心逻辑就完成了一个以前可能要手动拖拽半小时的活。

实际的下载目录里总是会有意想不到的文件类型，所以我加了一个其他文件的分类兜底，确保脚本任何时候跑都不会因为未知扩展名报错。这类“兜底设计”在自动化脚本里极其重要，你只能保证常见情况，但永远要为意外情况准备一条退路。

3.3 网络请求与定时任务：让脚本每天自动帮你看一眼数据

第三个场景是定时获取数据。很多人可能第一次接触爬虫，觉得网络请求很神秘，但用Python的requests库其实非常简单。举个例子，我有个小项目需要每天定时查询天气数据，并推送提醒到钉钉群。核心代码如下：

python复制# -*- coding: utf-8 -*-
"""每日天气定时提醒脚本"""
import requests
import json

API_KEY = "your_api_key"
CITY = "北京"

def fetch_weather():
    """从天气API获取指定城市天气"""
    url = f"http://api.openweathermap.org/data/2.5/weather?q={CITY}&appid={API_KEY}&units=metric&lang=zh_cn"
    try:
        r = requests.get(url, timeout=10)
        r.raise_for_status()  # 如果状态码不是200，抛出异常
        data = r.json()
        return data
    except requests.exceptions.RequestException as e:
        print(f"请求天气接口失败: {e}")
        return None

def send_dingtalk_alert(message):
    """发送钉钉机器人消息"""
    webhook_url = "https://oapi.dingtalk.com/robot/send?access_token=your_token"
    payload = {"msgtype": "text", "text": {"content": message}}
    headers = {"Content-Type": "application/json"}
    try:
        r = requests.post(webhook_url, data=json.dumps(payload), headers=headers, timeout=10)
        r.raise_for_status()
        print("钉钉消息发送成功")
    except requests.exceptions.RequestException as e:
        print(f"发送钉钉消息失败: {e}")

def main():
    weather = fetch_weather()
    if weather:
        temp = weather['main']['temp']
        weather_desc = weather['weather'][0]['description']
        wind_speed = weather['wind']['speed']
        message = (f"今日天气：{CITY}，{weather_desc}，气温{temp}°C，"
                   f"风速{wind_speed}m/s")
        send_dingtalk_alert(message)
    else:
        send_dingtalk_alert("今日天气获取失败，请检查日志")

if __name__ == "__main__":
    main()

定时执行这一步，Windows上可以用任务计划程序，macOS/Linux上可以用cron。我自己的做法是：先手动跑一遍确认没问题，再加到计划任务里，每天早上9点自动执行。我的经验是，初次配置定时任务后，前两周要多留意运行日志，确认脚本真的在按预期跑，避免“表面自动化、实际没人管”的空转状态。

4. 真实项目里的“坑”：编码、路径、断网和玄学问题

脚本能跑通了，但真正的挑战在于让它稳定地跑下去。这一节我把这几年踩过的自动化脚本的坑集中拿出来聊聊，这些坑没有任何一本书会系统性地教你，全是实战换来的。

4.1 经典乱码问题：UTF-8编码与Windows的“约定冲突”

第一个大坑是编码问题。Linux和macOS上Python默认UTF-8编码，一切岁月静好。到了Windows上，你会发现读取文件时偶尔冒出UnicodeDecodeError，或者输出中文变成乱码。

原因在于，Windows简体中文环境下，很多老软件的文本文件默认用GBK编码保存，而Python期望的是UTF-8。这个冲突在我做文件批处理时几乎是必踩的。解决方法是，在读取所有非UTF-8编码的文件时，显式指定编码：

python复制with open(file_path, 'r', encoding='gbk', errors='ignore') as f:
    content = f.read()

errors='ignore'表示遇到无法解码的字符时直接跳过而不是抛异常——这个参数在你的脚本需要处理用户上传的各类文件时，能救命。

写文件时也一样，用with open(output_file, 'w', encoding='utf-8-sig', newline='')。其中utf-8-sig会在文件开头加一个BOM头，这样用Excel打开生成的CSV时，中文不会乱码。这个细节我当年查了好久才搞清楚。

4.2 跟“硬编码路径”说再见：路径不存在的处理

第二个高频坑是硬编码路径和路径不存在。前面配置参数化那一段我已经强调过配置分离。但实际运行中还有个更隐蔽的问题：程序运行时，配置里填的路径或者输出目录突然不存在了（可能被移动或清理了）。

我的习惯是，凡是涉及文件写入的地方，先确保目标目录存在：

python复制import pathlib
from pathlib import Path

def ensure_dir(path_str):
    path = Path(path_str)
    path.mkdir(parents=True, exist_ok=True)
    return path

# 使用示例
output_dir = ensure_dir(config['report']['output_dir'])
output_file = output_dir / f"report_{today}.md"

parents=True表示如果父级目录也不存在，会一并创建。这几乎能杜绝“目录不存在”这类运行时错误最主要的来源。

4.3 网络请求的“玄学”问题：超时、重试和异常捕获

做爬虫或请求类自动化时，最头疼的不是请求失败，而是网络偶尔抽风导致脚本不稳定。一个请求有时快有时慢、有时超时有时正常，脚本挂着不动，还会连带影响后续任务。

我的经验是以尽可能明确的超时参数、重试机制和日志记录来应对一切网络请求：

python复制import requests
from tenacity import retry, stop_after_attempt, wait_fixed

@retry(stop=stop_after_attempt(3), wait=wait_fixed(2))
def fetch_with_retry(url):
    response = requests.get(url, timeout=10)
    response.raise_for_status()
    return response.json()

这段代码用了一个重试装饰器（tenacity库），遇到网络异常时先等2秒再重试，最多试3次。通常第三次就能成功。如果你的环境装不了第三方库，也可以自己写一个循环重试，逻辑相同。

网络请求类脚本有一条铁律：绝对不裸请求。 必须设置超时，必须捕获异常，必须打印日志。否则，你周一早上到工位，发现定时任务在周五就挂了，而你已经对着错误数据开心了一整天——这种经历，一次就够你记住一辈子。

4.4 不要让脚本变成一个“黑盒”：日志记录从第一版就要有

说起日志，这其实是个很多人忽略却极其重要的事。自动化脚本往往没有实时交互界面，跑完之后不会有人盯着控制台看，所以一定要把运行状态记录到日志文件里。这样出了问题，你才能回看日志分析原因。

我自己写脚本的日志规范很简单：

日志输出到项目目录下的logs/文件夹
文件命名带日期，方便回查（比如app_2025-01-15.log）
日志级别区分：INFO记录关键步骤，WARNING记录可恢复的异常，ERROR记录导致中断的严重问题

用Python标准库的logging模块就能实现：

python复制import logging
import datetime

log_file = f"logs/app_{datetime.date.today()}.log"
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s [%(levelname)s] %(message)s',
    handlers=[
        logging.FileHandler(log_file, encoding='utf-8'),
        logging.StreamHandler()
    ]
)

logging.info("脚本开始执行")
logging.warning("发现一条脏数据，已跳过")
logging.error("配置文件缺失，程序退出")

前两版脚本我只用print输出，后来失败了根本无从查起。加上日志之后，定位问题的效率提升了不止一倍。

5. 从“我的脚本”到“团队工具”：打包、调度与交接

脚本自己用没问题，但要让它变成团队里其他人也能用的工具，还有几个坎要过：打包成可执行文件、设置定时调度、以及写好交接文档。这一节是很多人会忽略的“最后一公里”。

5.1 用PyInstaller把脚本打包成exe，终结“环境配置地狱”

如果你的同事不是程序员，让他们装Python、配环境、装依赖再去跑脚本，这几乎是不可能的。正确的做法是，用PyInstaller把脚本打包成Windows可执行文件（exe），让人家双击就能跑。

安装打包工具很简单：pip install pyinstaller。打包的命令也很直白：

bash复制pyinstaller -F -w report_builder.py

-F表示打包成单个文件，-w表示运行时不弹黑色控制台窗口（适合给非技术同事用的GUI或无声脚本）。打包完会在dist/目录下生成report_builder.exe，把这个exe发给同事，他直接双击就能运行，跟装了个普通软件一样。

这里有几个经验点：

打包前把外部依赖都打包进去。PyInstaller会自动分析你import的模块，但有些动态导入的库可能检测不到，最好先跑一遍确认。
打包后的exe首次运行可能要等几秒，这是正常的，不用慌。
exe体积通常比较大，哪怕脚本只有50行，打包出来也有几十MB，这是PyInstaller带了个Python解释器的原因，正常现象。

5.2 定时调度：Windows任务计划程序与cron的实操细则

打包成exe之后，你可以把它直接挂到操作系统的计划任务里定时执行。Windows下我用的是“任务计划程序”（Task Scheduler）：新建任务，触发器选“按固定时间间隔”，操作选“启动程序”，然后指向你的exe文件即可。

有几个细节容易踩坑：

“不管用户是否登录都要运行” 这个选项慎用，因为有些脚本需要访问网络资源或用户配置，在无用户登录的环境下可能没有权限。
如果任务执行失败，Windows会记录错误，但你未必会去看。所以最好在脚本末尾加上一个成功标记，比如生成一个哨兵文件，或者在日志里写next run时间，这样才能确认它确实跑过了。
保持“重复任务间隔”设置正确，比如“每天一次”还是“每周五一次”，跟你的实际需求对齐。

如果用的是Linux或macOS服务器，crontab就是标准答案。常见写法：

bash复制# 每天上午9点运行
0 9 * * * /usr/bin/python3 /path/to/your_script.py >> /path/to/logs/cron.log 2>&1

>> /path/to/logs/cron.log 2>&1的意思是，把标准输出和错误输出都追加到日志文件，这样你随时可以检查cron任务有没有正常执行。这个习惯帮我排掉过很多“当时没报错但实际没跑”的伪自动化问题。

5.3 交接像给同事留了一盏灯：文档、配置说明与FAQ

最后，当你决定把脚本交给别人用，一定要附上一份“傻瓜式”说明文档。不需要写代码注释，但要写清楚：

这个脚本是干什么的、会在什么时间自动运行
怎么手动运行它（双击?命令行?菜单入口?）
如果有配置文件，每一项的含义是什么
脚本输出结果在哪个文件夹、怎么确认它运行成功了
常见问题（FAQ）：比如“邮件没收到怎么办”“运行报错怎么截图反馈”

我自己的经验是，写这份文档花费的时间，和写脚本本身差不多。但这完全值得——一个能交付给别人的工具，才真正兑现了“自动化节省时间”的价值。如果只有你自己能维护，那这个脚本未来就是你一个人的“技术债”。

我见过很多半途而废的自动化项目，死因基本都是“脚本写得太随便，过一个月自己都看不懂”。所以，哪怕你最初只是给自己用，也建议按“未来要交给别人”的标准来写日志、做配置、留文档。这个习惯会在某一天，当你全身心投入到新项目、同事突然说“你那个周报脚本我想用一下”的时候，让你感激自己。

我后来把周报脚本从第一版那坨只为自己服务的代码，重构成了一个配置驱动的、带日志、可打包、有文档的小工具。现在它每天自动拉取Git提交记录，按周汇总，每周五早上生成草稿邮件发给我确认。如果周五早上9点我没收到邮件，我会收到一个钉钉告警，然后花五分钟看看日志。

这就是我认为自动化脚本应该有的样子：你写它的初衷是为了省时间，但真正让它长期发挥价值的，是那些不性感的细节——参数配置、容错处理、日志记录、打包分发。每个环节都多花一点心思，你的自动化才不是一锤子买卖，而是一个能陪你很久的东西。

最后分享一个我个人的小习惯：每写完一个脚本，我会专门花15分钟做一件事——模拟“三个月后的自己”来看这段代码，看看哪里会看不懂。看不懂的地方就加注释，或者重构。这15分钟的投入，经常是整段自动化过程中最值的投资。