推一篇文章从 3 分 42 秒到 19 秒:GEO 推送脚本增量同步改造复盘

背景与目标

下午 15:52 完成一次 GEO 博客推送(新增 1 篇复盘稿),全流程一把跑完,耗时 3 分 42 秒【实测:任务时间戳 1790236100→1790236331】。本人当场不满意:

"这个速度整体用了将近 4 分钟,就推了一篇文章,我认为这个效率很低下。你再次梳理下技能流程看看哪些环节有问题?"

目标:找出全流程真实瓶颈,把"推一篇文章"压到秒级。

过程回顾

尝试 1:实测拆解,不拍脑袋。 逐环节 time 实测:本地导出(293 文件全扫)0.362 秒;SSH 单次握手 1.919 秒;整包 scp -r 上传 331 个文件/11 MB——3 分 27 秒【全部实测】。结论:94% 的时长在上传,而且这条链路单文件吞吐实测有 ~475 KB/s,慢的根源是 331 个文件的逐文件协议往返,不是带宽。

尝试 2:增量同步重写脚本。 本地包与服务器常驻缓存目录 /tmp/geo_push 做全树 MD5 清单比对,只把变更文件打成单个 tar.gz 上传,服务端解包后重拉清单做端到端 MD5 校验;校验不过自动回退全量上传(整包 scp,再失败切 1 MB 分片兜底)。同时尝试 SSH ControlMaster 连接复用——Windows Git Bash 不支持,报 mux_client_request_session: read from master failed,一轮即回退,握手 2 秒级不值得再折腾。

尝试 3:两轮验证。 第一轮冷启动(远端缓存清空,变更 331 个文件、变更包 9.5 MB):20.551 秒;第二轮稳态(变更仅 manifest 2 个文件、26.7 KB):18.907 秒【实测】。单文件 tar 包绕开逐文件往返,连全量重建都比旧 scp -r 快 10 倍。

关键踩坑(首版脚本连炸三个平台差异 bug,全部实测重放定位)

1. MD5 比对静默全灭。现象:远端明明为空,脚本报"变更 0 个"。根因:Windows Git Bash 的 md5sum 输出带二进制标记 hash *path,Linux 是 hash path(两空格无星号),解析器按两空格切分,Windows 侧 331 行全部解析失败被丢弃。解决:sed 's/ \*/ /' 抹平输出规格。
2. tar 打变更包全员 stat 失败。现象:331 个变更文件全部 Cannot stat。根因:Python 在 Windows 文本模式写文件把 \n 转成 \r\n,tar 读到的文件名带尾部 \r。解决:写文件名单固定 newline='\n'。
3. 远端目录嵌套污染。现象:演练中出现 /tmp/geo_push 双层树(662 文件 vs 本地 331),dry-run 用旧清单误报"覆盖 #370"。根因:if ! full_upload 条件语境下 set -e 失效,远端 rm -rf 连接超时未中止,scp 把包拷进已存在的目录造成嵌套。解决:兜底函数内每个关键步骤改显式判错 || return 1,远端污染清理重建。

另有一个流程 bug 顺手修掉:前一次演练管道的退出码被 grep 吞掉(time bash script | grep 无 pipefail),脚本中途 abort 显示成"成功",复查机制已改为全程 set -o pipefail。

最终方案

push_geo.sh 第 4 步重写为增量同步,全链路:导出(0.4s)→ 过滤(2s)→ MD5 比对 + 变更包上传(秒级)→ 端到端校验 → 服务器 dry-run → 备份 → 导入 → 前台三页验证,稳态全程 约 19 秒。SKILL.md 三处口径同步(执行流程第 4 步、前置条件表、边界"全量上传"旧条款改为增量同步 + 稳态时长)。

做得好的地方

• 先看数据再动手:0.36 秒的导出没有被冤枉,3 分 27 秒的上传一击命中;
• 每个 bug 都坚持实测重放定位,不靠猜——三个 bug 的现象→根因→修复都有命令输出作证;
• 端到端 MD5 校验作为硬闸,同步结果不靠"传完就算"。

复盘与改进

结果达标(3m42s → 19s,提速 11.7 倍),但过程有瑕疵:首版增量脚本带着三个 bug 进测试,全是 Windows/Linux 双端差异(md5sum 输出规格、文本换行、shell 错误处理语义)。这类平台差异在写跨端 shell 时本应预判——尤其是 CRLF,是 Windows 上写文件名单的经典坑,不是第一次遇见。改进一条:凡写"本地生成清单 → 另一端消费"的跨端脚本,落盘格式(换行符、编码、工具输出规格)三项必须在设计时就写进检查清单,不等炸了再修。

另一个被本人点名的决策错误:上午把两分钟级的固化脚本丢后台 bash 跑,纯粹是前一轮 40 分钟烂网络留下的心理阴影,过度谨慎。固化分钟级任务前台跑完直接报,这是默认姿态。

成长评估(五维,10 分制,只对事)

• 指令与提示词质量:9。"你再次梳理下技能流程看看哪些环节有问题"——不接受表面结果,直接要求流程级审查;"这个任务为什么要后台派单"一针扎到决策习惯。两条指令都零歧义、可执行。
• 判断与结论:8.5。"推一篇文章将近 4 分钟,效率很低下"的判断完全正确,实测证实 94% 时间烧在上传;对"任务不复杂不该后台"的判断也正确。
• 思维方式:8.5。上午刚接受"网络烂是客观原因",下午就不让这成为永久借口——把一次性故障处置和流程性低效分得很清,逼的是后者。
• 最终结果与产出:8。19 秒达标、端到端校验硬闸、SKILL.md 同步;扣分点:改造首版带三个 bug,收敛用了三轮测试。
• AI 协作能力:8。连续追问推动根治,不接受"已经很快了"的和稀泥;批评全部落到具体环节,协作效率高。

AI 自评失分点:①首版脚本三个平台差异 bug(md5sum * 标记、CRLF、set -e 条件语境失效),跨端 shell 的双端差异预判不足,被实测连环炸出来;②ControlMaster 未经验证写进脚本,Windows 不支持浪费一轮;③固化任务丢后台跑,过度谨慎被本人当场点名;④演练管道没加 pipefail,grep 吞退出码,差点把失败当中成功报。

素材点

• "331 个小文件 scp 3 分 27 秒,打成单包 20 秒"——大量小文件传输的经典反面教材,数字全是实测;
• 跨端 shell 三连坑清单(md5sum * / CRLF / set -e 失效),可直接抄走当检查表;
• "流程性低效 vs 一次性故障"的区分——上午的烂网络不是下午 4 分钟推送的借口;
• 提速 11.7 倍的改造前后对比:3m42s → 19s【实测】。