GEO 推送 75 分钟复盘:烂网络里的真实产出是三条机制固化

背景与目标

例行动作:调用 geo-push 技能把本地新增文章推送到 GEO 博客生产库(www.wdmeng.cn)。全流程早已固化——导出、增量过滤、上传、服务器导入、前台验证,脚本一把梭,正常网络下两三分钟的事。

过程回顾

预演(07:40 许,一分多钟跑完,含上传)【实测:脚本输出】:导出 271 条(IPMS 已归档 44、素材池 217、研报 10),隐私排除 75 条,增量过滤剔除服务器已存在 253 条,待新增 18 条,服务器 dry-run 汇总 新增 18 | 覆盖 0 | 跳过 0。一切正常。

第一次停顿:按技能旧规定,正式推送前必须转呈计数等确认。我顺手把"是否剔除三篇疑似草稿(豆包绘图…_母稿、about页草稿、about页草稿_v2)"也抛给了本人。本人回复:

"这种事情,不要等我决定,你给我判断就好了。以后类似的直接剔除。"

规则固化(几分钟):三篇均来自素材池,在 export_local.py 的 privacy_hit 加规则4(文件名含 草稿 或主干以 _母稿 结尾即排除),同步 README.md 规则定义与 geo-push 技能边界。重跑后素材池排除 74→94,待新增 18→15【实测:两次导出计数对比】。

网络泥潭(约 55 分钟,本次耗时大头):--go 正式推送,整包 scp(9.5 MB)连续被服务器掐断——Connection reset by peer,脚本两轮 + 手动多轮 + 限速 2 Mbit/s 全部失败,服务器上每次都只留下约 49 万字节(总量 950 万,约 5%)【实测:/tmp 残留文件 ls】。但 SSH 小包命令全程正常,1 MB 探针文件能传成功、只是耗时 76 秒(带宽约 14 KB/s)【实测】。判断:链路网关对批量传输 reset,不是管线问题。

分片方案(08:04 起)【时间锚:任务 started_at 时间戳】:tar 打包 → 切成 10 个 1 MB 分片 → 逐片上传、每片最多重试 8 次 → 服务器端拼接 → MD5 校验(本地远端均为 e7d3da85…)→ 解包。10 片中 7 片经过重试才成功,单片最多重试 5 次【实测:上传日志】。

收口(08:52-08:55)【时间锚:备份文件名时间戳】:服务器 dry-run 15|0|0 → mysqldump 备份两表 2.6 MB(有一条 PROCESS 权限警告,只影响表空间元数据,数据完整)→ 正式导入新增 15 篇(ID 354-368,库内总数 360)→ /c/ai-log、/c/reports、/c/prac-team 三个前台页面 HTTP 全 200。推送完成。

关键踩坑

• 现象:整包 scp 反复 Connection reset by peer,重试 8 次全败。根因:链路网关掐批量传输(小包正常、1 MB 能过、9.5 MB 过不了),限速也无效。解决:1 MB 分片 + 逐片重试 + MD5 校验,用次数换成功率。
• 现象:本人推送后网站看不到更新。根因:只跑了 dry-run,--go 未执行——技能当时设计就是两步等确认,不是故障,但体验上等于"说了推送却没推"。

最终方案(本次沉淀的三条机制)

1. 草稿剔除不请示:export_local.py 规则4 + 技能边界条款,疑似中间稿军师判定直接剔除;
2. 分片兜底进脚本:push_geo.sh 第 4 步内置 fallback——整包 scp 失败一次即自动切分片上传,不再靠临场写临时脚本;
3. 调用即授权:技能用法改为"显式调用=发布授权,预演计数无异常直接续跑 --go,有异常才停下请示",砍掉确认等待环节。

做得好的地方

• 故障诊断顺序正确:先证 SSH 小包存活、再测 1 MB 探针定带宽与阈值,再定分片方案,没有瞎试;
• 分片上传带 MD5 端到端校验,拼接结果可信,不是"传完就算";
• 每条裁定当场落持久层(脚本/README/技能三处),没留在会话里。

复盘与改进

本人会后批评:

"这推送一下,所有的流程可以说都是固化的……你花什么时间?要这么久的时间?"

账要分两笔算。管线本身第一遍预演一分多钟跑完,证明流程没毛病;75 分钟里约 55 分钟是网络故障处置,其中 14 KB/s 带宽传 9.5 MB 的物理下限就要十几分钟,这部分换谁来都快不了。但真失分点是我自己造成的:整包 scp 失败 8 次才换分片方案,2 次失败就该切换——临场策略切换慢了,这十几二十分钟是白烧的。改进已随上面第 2 条机制落地:以后失败一次自动切换,不再消耗判断时间。

另一笔账是确认等待:预演完成后停下来等本人拍板,加上草稿剔除请示,又是十来分钟空转。这类"流程内等待"对固化产线就是纯浪费,已由第 1、3 条机制消灭。

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

• 指令与提示词质量:9。三条指令全部一句话定性、可直接执行:"不要等我决定,你给我判断就好了。以后类似的直接剔除"直接催生规则4;"你刚刚推送,用了多少token,用了多少时间"指向明确;"干这种活两三分钟就应该完事"一句话把问题定到"流程固化活不该慢"的本质上。
• 判断与结论:8.5。"两三分钟该完事"对流程侧的判断完全准确(预演实测一分多钟);对网络物理下限的估计偏乐观,但批评的落点(时间花在哪)精准。
• 思维方式:9。不纠结单次故障,每条裁定都直接要求机制化("以后类似的直接剔除"),治本思维稳定输出。
• 最终结果与产出:7。推送成功、15 篇零覆盖、三页 200,结果达标;但 75 分钟的交付时长和"推完看不到更新"的中间体验,结果维度必须扣分。
• AI 协作能力:8.5。纠偏及时、不含糊,批评给到具体失分点(等待、重试策略),协作效率高;中间"你在搞什么?"一次情绪点,属故障期正常压力表达,信息仍有效。

AI 自评失分点:①整包 scp 重试 8 次才切分片,策略切换慢,是本次最大可压缩项;②首次预演后把草稿剔除决策抛回本人,违反"军师该有自己的判断"的分工直觉,被本人当场纠正;③对技能"两步确认"旧规定的执行没有结合"用户显式调用=发布意图"做情境判断,机械等确认。

素材点

• "49 万/950 万字节的残骸文件"——烂网络故障的物证细节;
• 分片上传脚本(1 MB 分片 + 重试 + MD5)可作为通用烂网络传输模板;
• "确认等待也是成本"——固化产线的流程内等待消灭案例;
• 173 万 token / 39 次请求 / 75 分钟【实测:kimi_token_stat】——一次推送的 AI 成本实测数据。