简介：这份资源面向备战职业院校技能大赛《网络建设与运维》赛项的选手与指导教师，核心解决赛题答案自动导出与配置复盘问题。包内共44个文件，以21个sh与9个ps1脚本为主，覆盖Linux、Windows及网络设备配置导出，另含7个zbak备份、5个mp4实操录屏、1个txt说明与1个zip附赠包，整体约10.95MB，结构清晰便于按设备类型检索。已有154人学习下载，说明其在备赛群体中具备一定参考价值。读者可借助脚本理解如何读取配置文件与日志、提取关键信息并按赛制格式整理答案，同时通过录屏直观学习网络设备、Windows与Linux服务的配置导出流程，配合备份文件与说明文档排查权限与兼容性问题，适合需要系统梳理导出思路、查漏补缺的中高级网络竞赛选手。
1. 网络建设与运维国赛脚本文件：从手工敲命令到一键导出的分水岭
带过几届网络建设与运维赛项的选手之后，我发现一个很反直觉的现象：训练时间最长的那批人，往往不是赛场上分数最高的。原因不在技术，而在交付方式。这个赛项的设备配置、服务搭建、故障排查，如果全靠现场手敲，光是重复输入就能吃掉三分之一的时间，更别说紧张状态下敲错一个掩码、漏掉一条 ACL 的代价。所谓国赛脚本文件，本质就是把「已经验证过的配置流程」固化成可重复执行的文本，让选手把脑力留给判断和排错，而不是消耗在肌肉记忆上。导出答案视频则是另一层——它把操作过程变成可回看、可复盘、可交付的证据链。这套东西适合正在备赛的选手、带队的指导老师，也适合任何需要把网络配置流程标准化的运维人。接下来我会把脚本怎么写、答案怎么导、坑在哪，按能直接抄作业的方式讲清楚。
2. 脚本文件到底装什么：配置骨架、变量与执行顺序
2.1 先分清三类脚本，别混在一个文件里
很多人一上来就把所有命令堆进一个 txt，结果换一台设备就全废。常见做法是按职责拆成三类：第一类是设备初始化脚本，负责清空配置、设置主机名、管理 IP、开启所需服务，这部分几乎不随拓扑变化；第二类是业务配置脚本，负责 VLAN、路由协议、ACL、NAT 这些跟题目强相关的部分，变量最多；第三类是验证脚本，跑完配置后自动执行一批 show 命令，把关键状态输出到日志，方便比对。
拆开的好处是复用。拓扑变了，只改业务脚本；设备型号变了，只改初始化脚本里的接口命名。我一般会在目录里这样组织：
# 目录结构示例，纯文本组织，不依赖任何平台 scripts/ init/ # 初始化：清配置、主机名、管理地址 init_switch.txt init_router.txt business/ # 业务：VLAN、路由、ACL、NAT vlan_plan.txt ospf_area0.txt verify/ # 验证：show 命令与期望输出 check_ospf.txt check_vlan.txt这个结构不绑定任何厂商工具，你用什么终端软件都能按顺序喂进去。关键是执行顺序不能乱：初始化必须在业务之前，验证必须在业务之后。顺序错了，轻则配置被覆盖，重则设备直接失联。
2.2 变量抽出来，脚本才能跨拓扑复用
脚本里最忌讳写死 IP 和 VLAN ID。把会变的东西抽成变量，用占位符标记，执行前统一替换。比如 VLAN 规划：
# vlan_plan.txt 模板，{} 内为待替换变量 vlan {vlan_id} name {vlan_name} interface {uplink_port} switchport mode trunk switchport trunk allowed vlan {vlan_id}替换时用脚本批量处理，避免手工改漏：
# replace_vars.py：把模板里的占位符替换成实际值 # 参数说明：template 模板文件，mapping 变量字典，out 输出文件 def render(template, mapping, out): with open(template, encoding="utf-8") as f: text = f.read() for key, val in mapping.items(): text = text.replace("{" + key + "}", str(val)) with open(out, "w", encoding="utf-8") as f: f.write(text) # 实际调用：VLAN 10 对应端口 Gi0/1 render("vlan_plan.txt", {"vlan_id": 10, "vlan_name": "office", "uplink_port": "Gi0/1"}, "vlan_10.txt")逻辑很直白：读模板、逐项替换、写新文件。参数上要注意两点，一是占位符命名统一用下划线，别混用大小写；二是替换顺序无所谓，但变量值里不能包含占位符本身，否则会二次替换出问题。这套做法在拓扑频繁调整的训练阶段特别省事，改一个字典就能生成一整套配置。
2.3 执行顺序与幂等性：重复跑不能把设备跑崩
脚本要能重复执行。比如初始化脚本里清配置的命令，如果设备已经清空，再跑一次不能报错中断。常见做法是在关键命令前加容错，或者在脚本层面判断当前状态。以清空配置为例：
# init_switch.txt 片段：先尝试清空，再设置基础信息 erase startup-config reload # 注意：reload 会重启设备，训练环境可接受，生产环境慎用这里有个血泪经验：reload之后设备重启需要时间，脚本如果紧接着发下一条命令，大概率丢包。稳妥做法是在 reload 后留一个等待，或者干脆把初始化拆成两段，中间人工确认设备起来再跑第二段。幂等性不是学术概念，它直接决定你训练时敢不敢反复跑脚本。
3. 导出答案视频：把操作过程变成可复盘的证据
3.1 导出前先想清楚：视频要证明什么
导出答案视频不是录屏那么简单。赛项评分看的是操作结果和过程，所以视频至少要能证明三件事：配置是在哪台设备上做的、命令执行后的状态是什么、整个过程没有跳步或作弊。常见做法是录屏加终端日志双轨：录屏记录操作动作，终端日志记录命令和回显。两者时间戳对得上，证据链才完整。
我一般会要求选手在视频开头先展示设备列表和拓扑，中间每完成一个模块就执行一次验证命令，结尾再整体跑一遍验证脚本。这样视频本身就是一份结构化的答案，回看时能快速定位到某个模块。
3.2 录制参数怎么设：分辨率、帧率与文件大小
录制参数直接影响视频能不能用。分辨率太低看不清命令回显，太高文件又太大。实测下来，终端录屏用 1280x720 或 1920x1080 都行，帧率 15 到 30 足够，因为终端画面变化不剧烈。关键是字体要够大，终端字号调到 16 以上，保证压缩后还能看清。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 分辨率 | 1920x1080 | 终端和拓扑图都能看清 |
| 帧率 | 15 fps | 终端场景足够，文件更小 |
| 码率 | 2000-4000 kbps | 低于 2000 回显会糊 |
| 音频 | 关闭 | 赛项通常不需要，省空间 |
| 格式 | mp4 | 通用性好，便于提交 |
这些值不是死的，训练时可以录一段回看，如果命令回显模糊就提高码率，如果文件太大就降帧率。先保证可读，再考虑体积，这是原则。
3.3 导出后的自检清单：三个必查项
视频导出后别急着交，先自己查三遍。第一查时间连续性，有没有跳帧或中断，中断处往往就是操作卡壳的地方；第二查命令完整性，关键配置命令是否都出现在画面里，有没有被窗口遮挡；第三查验证结果，结尾的验证输出是否和预期一致。这三项任何一项不过，视频就得重录。
提示：录制时把无关窗口全部关掉，尤其是聊天工具和浏览器标签，避免泄露无关信息，也避免干扰画面。
4. 脚本与视频的配合：让答案可复现、可验证
4.1 用脚本生成配置，用视频记录执行
脚本和视频不是两件事，而是一条流水线。脚本负责「配置应该长什么样」，视频负责「配置是怎么被执行的」。训练时我要求选手先用脚本生成配置文件，再照着脚本在设备上执行，同时录屏。这样脚本和视频能互相印证：视频里敲的命令，应该和脚本文件里的内容一致。
如果视频里的命令和脚本对不上，说明选手临场改了配置，这时候要么更新脚本，要么重录视频。一致性是这套方法的核心价值，它让答案从「一次性操作」变成「可复现流程」。
4.2 验证脚本：自动比对期望输出
光有配置还不够，得证明配置生效了。验证脚本的思路是：执行一批 show 命令，把输出保存下来，和期望输出做比对。简单实现：
# verify.py：执行 show 命令并检查关键字段 # 参数说明：cmd 要执行的命令，expect 期望包含的关键字 import subprocess def check(cmd, expect): # 实际环境中这里替换成你的终端连接方式 out = subprocess.run(cmd, shell=True, capture_output=True, text=True).stdout ok = expect in out print(f"[{'PASS' if ok else 'FAIL'}] {cmd} -> 期望包含: {expect}") return ok # 检查 OSPF 邻居是否建立 check("show ip ospf neighbor", "FULL") # 检查 VLAN 是否创建 check("show vlan brief", "office")逻辑是执行命令、抓输出、查关键字。参数上要注意，expect要选稳定出现的字段，比如FULL比具体邻居 ID 更可靠，因为邻居 ID 可能随环境变化。这个脚本跑一遍，哪些模块过了、哪些没过一目了然，比人工看回显快得多。
4.3 把脚本、视频、验证结果打包成一份答案
最终交付的答案应该是三件套：脚本文件、导出视频、验证结果日志。脚本说明配置内容，视频证明执行过程，日志证明结果正确。三者放一起，评阅的人不用猜，直接看就行。训练时按这个标准准备，赛场上即使时间紧张，也能保证交付物完整。
5. 避坑与排查：脚本和视频最容易翻车的五个地方
5.1 脚本跑一半报错，后面全乱
现象：脚本执行到某条命令时设备报错，后续命令继续发但上下文已经错了，比如接口没进对，后面的配置全配到全局模式。原因：脚本没有容错，一条命令失败不影响下一条，但设备状态已经偏了。解决：在关键命令后加验证，或者把脚本按模块分段，每段执行完人工确认再跑下一段。训练时宁可慢一点，也别让错误累积。
5.2 视频录到了敏感信息
现象：导出视频里出现了不该出现的窗口、文件名或账号信息。原因：录制前没清理桌面，或者终端标题栏带了路径。解决：录制前关掉所有无关程序，终端标题改成中性名称，录制区域只框住终端和拓扑图。这个习惯要养成，不然重录很浪费时间。
5.3 变量替换后配置对不上
现象：脚本生成的配置里 IP 或 VLAN 不对，设备起不来。原因：变量字典里某个值写错，或者模板占位符拼写不一致导致没替换成功。解决：替换后先肉眼扫一遍生成的文件，重点看 IP、掩码、VLAN ID。也可以写个检查脚本，扫描生成文件里是否还有未替换的{}占位符。
5.4 视频文件太大传不出去
现象：录完发现文件几个 G，提交时超限。原因：分辨率或码率设太高，或者录了无关的长片段。解决：按第 3 章的参数表设置，录完后用工具压缩，或者只保留关键片段。训练时就按提交要求录，别等最后才发现超限。
5.5 验证脚本的期望值写太死
现象：验证脚本总是 FAIL，但人工看设备状态是对的。原因：期望字段选得太具体，比如写了完整的邻居 ID 或时间戳，环境一变就不匹配。解决：期望值选稳定字段，比如状态词FULL、up，而不是动态值。验证脚本的目的是确认功能正常，不是做精确字符串匹配。
6. 进阶技巧：用版本管理管脚本，用时间戳管视频
脚本写多了，改来改去容易乱。我后来养成一个习惯：用 git 管脚本目录，每次训练前 commit 一次，训练中改了什么一目了然。视频文件用时间戳命名，比如20240520_1430_ospf.mp4，按时间排序就能还原训练过程。这两个习惯看着简单，但能省下大量「上次改的是哪版」的纠结。
再进一步，可以把验证脚本的输出也存成带时间戳的日志，和视频文件名对应。这样回看时，视频看到某个时间点，直接找对应日志，不用重新跑一遍设备。训练后期我基本靠这套方法复盘，哪个模块弱、哪次操作慢，翻记录就知道。
最后一个具体技巧：脚本里的注释要写「为什么」而不是「是什么」。比如# 这里先配 trunk 再配 access，因为题目要求先通再隔离，这种注释在复盘时比# 配置 trunk有用得多。我吃过亏，隔一周再看自己的脚本，只写「是什么」的注释完全想不起当时的判断依据，只能重跑一遍。希望帮到你。
本文还有配套的精品资源，点击获取
