如果让我说过去十年里最值得投入的一项技能自动化脚本一定排在前三。它不是某一个编程语言的专利而是一种“把重复交给机器、把时间留给自己”的工作方式。这篇文章不聊理论只聊实战自动化测试、运维自动化、Windows脚本、AI辅助办公四个主战场我会把踩过的坑、验证过的做法和可以直接抄作业的脚本样式全部放出来。想入门的测试新手能从这里找到pytest和Appium的落地路径刚接触Linux的运维同学能拿到Shell和Ansible的实用范例被Windows命令行坑到怀疑人生的朋友也能在最后的排查章节里找到答案。内容偏长但每一段都有用。1. 自动化脚本先想清楚再动手1.1 什么场景适合脚本化什么场景不必硬上我见过太多人看见“自动化”三个字就兴奋结果把三天能做完的事搞成一个月最后脚本自己成了维护负担。判断一个场景该不该上脚本我一般看三个条件重复次数够不够多、操作步骤稳不稳定、失败后的影响可不可控。每天执行一次、每次十分钟的报表导出很值得写每个月执行一次、每次半小时的年度盘点我建议你手动点两下算了脚本的学习成本和维护成本远大于那半小时。这条经验来自真实教训。早年我写过一个“几乎包含所有办公自动化的全能脚本”听起来很酷实际上因为需求不断变化脚本里的分支条件越来越多最后连我自己都不太敢改。自动化脚本的设计原则其实很简单需求边界画得越小脚本活得越久。你真正需要的不是一个大而全的工具而是一个能稳定跑半年、出问题三分钟能定位的小工具。1.2 语言与工具选型Shell、Python、PowerShell、Node.js 各自的主场很多人纠结学哪门语言我的建议是别纠结按场景选。这里放一张我常年使用的选型表照着选基本不会错场景首选语言备选理由Linux/Unix 系统管理、文件批处理Bash/ShellPython系统自带、轻量管道和重定向是天然优势跨平台数据处理、网络请求、自动化测试PythonNode.js生态庞大requests/pytest/playwright 齐全Windows 系统管理、注册表/服务操作PowerShellCMD/批处理面向对象直接操作 WMI/CIM 和注册表Web/Node 生态的前置脚本Node.jsPython与 npm 工具链天然契合启动速度快为什么我不建议所有东西都用同一种语言Shell 在文本处理和进程控制上几乎零成本但一旦遇到复杂的 JSON 解析就开始痛苦Python 适合做“重逻辑”的活但部署时需要解释器环境PowerShell 在 Windows 上无敌到了 Linux 上虽然也能运行但生态和习惯还是差点意思。把这些想清楚再动手比学一堆语法重要得多。选型选对了脚本写起来顺维护起来也省心。2. 自动化测试框架落地pytest、Appium、Playwright 与接口测试2.1 接口自动化为什么 pytest 手感最好Java 项目又该怎么选接口自动化是性价比最高的自动化测试形式因为接口稳定、执行快、断言明确。Python 生态里我常年用 pytest 搭配 requests断言简洁、fixture 可以复用登录态、参数化直接解决多组用例遍历问题。给你看一个我常用的最小模板import requests import pytest BASE_URL https://api.example.com pytest.fixture() def auth_token(): resp requests.post(f{BASE_URL}/login, json{user: test, pwd: 123456}) assert resp.status_code 200 return resp.json()[token] pytest.mark.parametrize(page,size, [(1, 10), (2, 20), (3, 0)]) def test_list_items(auth_token, page, size): headers {Authorization: fBearer {auth_token}} resp requests.get(f{BASE_URL}/items, params{page: page, size: size}, headersheaders) assert resp.status_code 200 assert resp.json()[code] 0这段代码解决了两件事一是用 fixture 把登录态只做一次二是用参数化把三组数据塞进同一条用例新增用例只需要往列表里加元组。Java 项目如果技术栈已经锁死我建议直接用 RestAssured 或 HttpClient 封装一层公共请求类防止每个用例都重复拼 URL 和 Header。说实话如果不是团队强制 Java我更推荐在 Python 侧多花点心思开发效率差距非常明显。2.2 UI 自动化从 Playwright 到 Appium 的环境搭建与踩坑UI 自动化的推荐顺序很明确Web 端直接 Playwright移动端用 Appium。Playwright 的优势是自带浏览器管理不需要手动装 chromedriver自动等待机制也远比 Selenium 的显式等待好用。搭建环境只需要三步pip install playwright playwright install chromium python -c from playwright.sync_api import sync_playwright; print(OK)Appium 的环境搭建则是另一个故事。你不但要装 Appium Server还要处理好 JDK、Android SDK、adb 和 UiAutomator2 驱动之间的版本匹配。我给新手的建议是先把 Appium Inspector 跑起来能手动定位到元素再谈写脚本否则你会花费大量时间在“环境怎么还不通”上面。Appium 官网的文档其实写得很清楚但很多人根本没看直接复制网上的旧教程版本一冲突就开始抓瞎。2.3 让测试脚本可维护用例分层与数据驱动很多团队的自动化测试活不过三个月不是因为技术难而是因为用例动不动就崩、一崩就没人修。我踩过最大的坑是“一条用例把元素定位、操作和断言全揉在一起”改一个页面结构就要把所有用例翻一遍。正确做法是分三层页面对象层管元素定位和操作用例层管业务场景数据层管输入输出。数据驱动的思路也很好理解把测试数据从代码里抽出来放到 YAML 或 JSON 中新需求来了只加数据不动代码。我用过一个项目把 200 条用例从“天天修”改成“一周只修两三次”靠的就是这个思路。现在 AI 自动化测试的概念很热但 AI 充其量帮你生成初始脚本和识别异常页面分层和数据驱动的基本功仍然是团队能走多远的地基这两样做不好AI 也救不了乱成一团的测试工程。3. 从 Shell 脚本到 Ansible再到 PVE 云镜像模板3.1 Shell 脚本入门for 循环、参数传递和常见坑Shell 脚本是 Linux 运维的第一课。我见过不少同学背了一堆 Windows 命令到了 Linux 上第一反应是这也能算脚本对就这么简单。下面这段是最常用的 for 循环用来批量处理一组服务器上的命令#!/bin/bash for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do echo $ip ssh root$ip uptime free -h done这里有三点要重点提醒。第一变量一定要加双引号防止空值或空格把命令搞坏for ip in这种写法尤其容易踩到“变量里有空格”的坑。第二循环体内部尽量保持简短超过三行的逻辑拆到函数里面否则脚本一长就变成意大利面条。第三脚本开头强烈建议加set -euo pipefail它能让脚本在出错时立刻停下来而不是带着错误状态继续跑下去酿成更大的事故。批量登录路由器执行配置检查、跑 wifi 工具箱这类小脚本也是同一个套路。3.2 在 Linux 上正确运行 Python 脚本环境、路径与 nohupPython 脚本在 Linux 上跑不起来十有八九是环境问题。最典型的三类错误一是直接敲python发现没有这个命令因为系统里装的是python3二是脚本里用了第三方库但当前环境没装三是路径写法有问题比如在 crontab 里用了相对路径。我的建议是正经项目一律建虚拟环境别图省事直接往系统 Python 里装依赖否则某天升级系统包把依赖搞坏了你都不知道去哪哭。后台运行用 nohup 配合日志重定向再把 PID 写进文件方便以后杀进程nohup python3 /opt/scripts/my_task.py /var/log/my_task.log 21 echo $! /tmp/my_task.pid重定向、21把标准错误合并到标准输出、放到后台执行这三者的含义和应用值得花十分钟背下来它在日常运维里出现的频率高到你无法忽视。另外一个高频需求是“给另一个 py 脚本传递参数”最简单的做法是sys.argv按位置取参参数多了就用argparse服务的场景则把配置放到 YAML 文件里运行时指定文件路径。3.3 Ansible 与网络设备自动化写一次到处生效当服务器从三五台涨到几十台还在用 for 循环一台台 ssh 过去敲命令效率就太低了。Ansible 的核心思路是无 Agent通过 SSH 把任务批量推给目标机器playbook 用 YAML 写人类可读性极强。比如下面对所有 webserver 主机安装 nginx 并启动- hosts: webservers become: yes tasks: - name: install nginx apt: name: nginx state: present - name: start nginx service: name: nginx state: started网络设备自动化其实也差不多很多交换机、路由器都支持 SSH 或 RESTCONF配合 Ansible 的 ios_command 模块可以批量拉配置、批量改端口。关键是先把 inventory 里的主机分组想好分类清楚后面写 playbook 会省一半力气。这套脚本沉淀好之后再往 CI/CD 流水线里一挂pipeline 脚本就成了承载一切的壳代码提交、触发测试、执行部署、回传报告全链路自动跑。3.4 实战案例PVE 9.0 Debian 13 cloud-init 自动化虚拟机模板这个案例是我最近在一个内部环境里验证过的完整流程。PVE 9.0 基于 Debian 13配合 cloud-init 可以把“装系统、改配置、装软件”的标准步骤全部固化成模板之后创建虚拟机只需 30 秒到一分钟不必再手动装系统。大致的步骤是先下载 Debian 13 的 cloud 镜像比如 genericcloud 版本然后在 PVE 上创建一台虚拟机执行qm importdisk把镜像导入为磁盘再在硬件设置里把 cloud-init 驱动器加上写入默认用户、SSH 公钥和网络配置。最后把虚拟机关机转换成模板。最关键的一步是用qm template将这个 VM 转换为模板前必须确认磁盘为 VirtIO 且启用了“不复制”属性。很多人卡在这里模板创建后新建虚拟机还是完整克隆原因就是没做这个开关。模板建好后克隆出来的每台虚拟机都能独享 cloud-init 配置等你把用户、密码、网络、软件清单这些“变量”全部交给 cloud-init手动装机这件事就算彻底退休了。4. Windows 脚本实战与高频错误排查4.1 PowerShell 入门与开机自启脚本Windows 上做自动化绕不开 PowerShell。它比 CMD 强的地方在于输出是对象而不是字符串可以像操作数据库一样操作进程和文件。一个很常见的需求“开机自启”用 PowerShell 实现起来很直白把要执行的脚本注册成计划任务$action New-ScheduledTaskAction -Execute powershell.exe -Argument -File C:\Scripts\startup.ps1 $trigger New-ScheduledTaskTrigger -AtStartup Register-ScheduledTask -TaskName MyStartupScript -Action $action -Trigger $trigger -Force另外一个效率点是批量处理文件。比如把某个目录下所有超过 30 天没修改的日志文件移动到归档目录$oldFiles Get-ChildItem C:\Logs\*.log | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-30) } $oldFiles | Move-Item -Destination D:\Archive这种写法比在 CMD 里用 for 嵌套要清晰得多可读性接近自然语言。Windows 自带的任务计划程序虽然也能配但写成脚本的好处是可以纳入版本管理换机器之后一条命令恢复全部配置。4.2 “无法将 pnpm 识别为 cmdlet”的三分钟排查这个报错几乎每周都有新人来问报错长这样pnpm : 无法将“pnpm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。它的本质只有一个PowerShell 找不到 pnpm 的可执行文件也就是 PATH 里没有。常见的两个原因一是安装 Node.js 后没有重启终端PATH 没刷新二是用 npm 全局安装了 pnpm但 npm 的全局目录不在 PATH 里。排查方法很简单先确认 pnpm 装在哪npm prefix -g Get-ChildItem (npm prefix -g)如果有 pnpm.cmd 文件说明装上了只需要把那个路径加到系统环境变量 PATH 里重新打开终端即可。顺便说一句遇到claude : 无法将“claude”项识别为 cmdlet...这类报错排查思路完全一样。别急着重装先看 PATH。你重装一百遍PATH 不对还是同样结果。4.3 脚本窗口一闪而过真正的原因与排查双击 .bat 或 .ps1 文件窗口一闪而过什么都看不见——这是 Windows 脚本最经典的“灵异事件”。真正原因通常不是脚本出错而是执行方式不对。CMD 双击运行 .bat如果脚本内部报错会立刻关闭窗口PowerShell 默认执行策略也会拦截脚本。排查方法是用命令行手动运行脚本把窗口留住powershell -ExecutionPolicy Bypass -File C:\Scripts\check.ps1如果手动运行能看到具体报错问题就好解决多了。我目前遇到的高频原因包括脚本路径里含有中文或空格导致解析错误、引用了不存在的网络驱动器、编码问题导致中文字符出现乱码。建议在脚本开头加上Set-ExecutionPolicy -Scope Process Bypass或直接用cmd /k参数保留窗口调试。等脚本稳定之后再改成双击运行别一开始就双击那不是调试是开盲盒。5. AI 辅助、桌面脚本与自动化的边界5.1 AI 与自动化办公让助手帮你写脚本的正确方式AI 辅助写脚本现在已经是效率利器了。Claude、ChatGPT、Copilot 都能把一段自然语言描述变成可运行的 Shell 或 Python 脚本。我的经验是给 AI 的指令要尽量具体说明输入是什么、输出要什么格式、运行环境是什么、有哪些边界条件。比如“写一个 PowerShell 脚本扫描 D:\data 下所有 7z 文件解压到同名目录如果解压失败把文件名记到 error.log”这样得到的脚本基本能直接跑。如果只说“帮我写个解压脚本”得到的代码大概率要改半天。AI 写得再快最后把关的还是你脚本里的危险命令rm -rf、清空表、覆盖文件一定要逐字检查。我自己有过一次惨痛教训AI 生成的清理脚本里带了--force参数差点把不该删的目录清掉。从那以后凡是涉及删除和覆盖的操作我一律先输出文件列表给人眼确认再执行真正的清理。5.2 桌面软件脚本CAD、Illustrator 与日常文档处理桌面软件的脚本化是最容易被低估的领域。Illustrator 支持脚本可以用 JSX 批量导出资源、自动排版开源脚本社区里也有很多现成工具可以直接借鉴。CAD 里的“当前页面的脚本发生错误”是很多人的日常解决方法一般是先清理 AutoCAD 的临时插件再检查是否有第三方工具版本不兼容。 Office 方面Word 和 Excel 的宏依然是文档处理的稳定方案而 LibreOffice 则可以用命令行无头转换格式批量转换 PDF 时效率极高。另外还有一种常见的办公自动化场景是“定时下载网络资源”Windows 下用 curl 加计划任务就能实现早年我做过网盘定时镜像备份的小脚本注意下载脚本里要加超时和重试判断避免网络抖动导致文件损坏。开发场景里“把数据库导出成 SQL 脚本”也属于这一类IDE 和命令行工具都能做本质是把重复的备份动作固化下来避免每次手工点导出。5.3 iOS/Android 自动化与设备老化测试泛终端的几个切入点iOS 自动化最常见的是快捷指令它虽然没有传统脚本那样自由但胜在生态无缝定时提醒、剪切板操作、相册整理都能用可视化流程完成。专业一点的 UI 自动化可以用 XCTest 或 Appium 的 XCUITest 驱动。安卓侧则有 gkd 这类基于无障碍服务的开源自动化工具用来实现自动点击、跳过广告等操作它的“工作模式”本质上就是无障碍服务加规则引擎理解这个原理之后你就能自己扩展规则。设备老化测试全自动执行脚本这个需求属于比较典型的“重复执行 数据采集”场景。我在实验室里搭过一个方案Python 脚本通过 adb 定期拉起被测 App执行若干操作记录页面响应时间、CPU、内存数据同时驱动设备循环重启或烧机日志统一落库。这套脚本的核心其实是两个点一是时间策略要可配置二是异常恢复逻辑要足够强硬不能因为一次卡死就把整晚的测试作废。遇到无响应的设备脚本要能自动 adb reboot 并继续任务。5.4 关于游戏脚本与安全测试我的合规建议每次写自动化的文章都有人问游戏脚本和“出金脚本”能不能讲。我的态度很明确游戏脚本里真正做挂机、自动战的那些已经涉嫌破坏游戏公平性和用户协议我不建议碰也强烈不建议去尝试账号风险和法律责任都划不来。像星露谷这类单机游戏里玩家常说的“自动化”其实是游戏机制本身的农场布局设计和外部脚本完全不是一回事不要混为一谈。浏览器上的一些用户脚本比如油猴脚本本身是合法工具但如果你往页面里注入超大脚本导致页面打不开问题通常出在脚本体积和运行时机上你需要对脚本进行分块懒加载或者使用 MutationObserver 等待目标节点出现后再执行而不是一进页面就暴力执行全部逻辑。至于安全测试里的“布尔盲注”这类技术请务必只在获得授权的测试环境中使用任何未授权的布尔盲注爆破都属于越权行为。这个边界想清楚了自动化才能给你带来长期的收益而不是短期的麻烦。最后分享一个心得。自动化脚本的价值不在语法多高级、框架多流行而在于你能不能长期维护它。我给自己定了一条规矩任何自动化脚本要么写好后一周内用超过三次要么干脆不写。写脚本前先手工把流程跑干净确定每一步结果都符合预期再让脚本去复刻这个过程。这样你每写一个脚本省下来的都是实打实的时间而不是重新造出一个需要你持续伺候的“自动化负债”。