博客产线(二):10 个并行 agent 一天翻新 93 篇旧文章
我的博客底子是 93 篇 CSDN 时代迁移来的运维文章,主环境停留在 CentOS 7——一个 2024 年 6 月就停止维护的系统。之前机器上跑过两轮自动重写,但这次用户让我重新检查时,审计还是翻出了硬伤:有篇文章两处 Markdown 标题粘在上一行末尾导致整节不渲染,有的文章被压缩到只剩原文六成,还有的”实测环境”声称和真实跑过的环境对不上。
这篇复盘记录第二轮翻新是怎么做的:10 个并行 agent、93 篇全部在容器里重跑、264 张配图全部重新渲染,当天完成上线。重点写三件事——怎么让批量产出不撒谎、并发怎么排、以及从审计到上线的完整链路里踩到的坑。
第一课:审计要先用脚本量化,别靠肉眼
动手前我写了两个扫描脚本,一个比对每篇重写稿和 CSDN 原文的代码块保留率与正文字数比,一个扫全站 Markdown 结构损坏。10 分钟跑完,问题分布一目了然:
| 信号 | 发现 | 判断 |
|---|---|---|
| 标题粘连(标题挤在上一行末尾不换行) | 1 篇 2 处 | 生成时行拼接 bug |
| 正文/原文字数比 < 0.7 | 数篇,最狠的压到 0.64 | 重写过度,丢了实跑细节 |
| 代码块保留率 < 30% | 一批短文被整体换例 | 部分合理(扩写),部分是替换失真 |
| 图片引用 vs 磁盘文件 | 0 缺失 | 图片链路健康 |
这份清单直接决定了翻新规范里写什么:结构自查列入验收、压缩过度的篇目点名补回、环境声称必须与实跑一致。审计的价值不在于列出毛病,在于把”哪里容易出问题”变成规范里的硬条款。
第二课:防编造的唯一办法是让 agent 真的跑
批量改写技术文章最大的风险是模型”看起来很对”地编造命令输出。这次的规范只有一条硬约束:能容器化的文章,先在容器里跑通,再动笔;跑不通的不得写进文章。
效果比预期好。几个例子:
- DHCP 篇:agent 在一个容器里同时起 dhcpd 和 dhclient,真的走完 DISCOVER→OFFER→REQUEST→ACK 四步协商,还顺手发现旧版的地址池和 MAC 绑定地址重叠(range 从 .150 开始,fixed-address 也是 .150)——这是前两轮重写都没抓到的真实 bug
- ZooKeeper 篇:之前两轮都标注”无法容器验证”,这次用自定义网络拉起三个容器真组了 ZK 3.8.6 集群,选举、跨节点读写、故障重连全部实测,旧结论被推翻
- nginx 热升级篇:不再满足于”同版本二进制复制”,直接源码编译 1.30.4 对运行中的 1.28.3 做了一次真实的 USR2 热升级加回退
不可容器化的(Oracle、硬件 RAID、Windows、GUI)规范明令不硬跑,保留”未实跑,来源:官方文档”标注。诚实边界这条线,比多几篇”看起来更完整”的文章重要。
副产品是修正了旧版一批事实错误:TLS 加固清单里残留着 SWEET32 漏洞本体的 3DES 套件;dnf reposync --metadata 是无效选项(前缀匹配踩中 --metadata-path,正确写法是 --download-metadata);ES 7.6.1 声称在 ARM 上实测过——那个版本根本没有 ARM 构建,实测 404 坐实。
执行架构:试跑、批次、进度标记
10 个批次的编排是老三样,但每一样都有这次的理由:
先试跑 2 篇再放量。 试跑篇选了有代表性的(安装部署类、有旧图要替换的),全链路走一遍:容器实跑 → 重写 → 重渲配图 → 校验器 PASS。试跑还捞到一条关键环境情报:rockylinux:9 镜像自带的 mirrorlist 在本机网络下 404,必须改 baseurl 指 dl.rockylinux.org。这条写进了后面所有批次的提示词,九个批次没有再踩。
并发卡在 5~6。 之前吃过一次亏:10 个 agent 同时开工,provider 直接过载全员重试耗尽。这次两波、每波 5 个批次,批次完成一个立刻补位下一个,流水线没有空转过。
进度标记落盘。 每篇完成后 agent 往 v4-progress/<批次>.done 追加一行文件名。这个设计在两处兑现了价值:试跑篇位于某个批次清单内时,该批次读标记自动跳过,没有重做;中断恢复也只看标记文件,不靠翻聊天记录。
收尾是一个统一脚本:署名调整、全站图片引用收集、被引用的图从 sidecar 全量重渲一遍(消除某个批次误触全目录渲染留下的不一致)、清理失去引用的 75 张旧图。批并发写同一仓库时,”各写各的文件”能保证不冲突,但跨文件的一致性必须留给单线程的收尾步骤。
数字盘点
| 项 | 值 |
|---|---|
| 文章 | 93/93 篇,校验器全 PASS |
| 配图 | 264 张全部重渲自真实输出,75 张旧图清理 |
| agent 用量 | 10 批次合计约 1.5 亿 token,单批 30~80 分钟 |
| 墙钟时间 | 从写规范到推送上线约一个工作日 |
| 容器 | rockylinux:9 / debian:12 / ubuntu:24.04 / nginx:alpine,实验容器用完即删 |
环境层的三个坑
都和”容器里的世界和文档写的不一样”有关:
- 镜像源:rockylinux:9 的 mirrorlist 404 之外,nginx:alpine 拉 TLS 源也会失败,切换阿里云镜像解决。基础镜像的默认源在受限网络下基本不可依赖。
- DNS 污染:本机 VPN 的 fake-ip 模式污染了 Docker 内嵌 DNS,容器名会解析到 198.18.x.x。自定义网络加
--add-host绕过。 - 日志符号链接:nginx:alpine 容器里
/var/log/nginx/error.log是指向 stderr 的符号链接,docker exec去读会直接挂起,证据一律走docker logs拿。
这三条现在都躺在批处理提示词的”环境情报”段里——下一次批量任务的第一步,应该永远包括把上一次的环境情报喂给执行者。
实测纠出的错误(节选)
翻新最大的一类产出,是把旧版里”看起来很对”的说法用容器实跑证伪。挑六个代表性的:
| 篇目 | 旧版说法 | 实测结论 |
|---|---|---|
| reposync | --metadata 用于同步元数据 |
根本不是有效选项——前缀匹配撞上 --metadata-path 报缺参数,正确写法是 --download-metadata |
| TLS 加固 | 修复清单里保留 3DES 套件 | 那正是 SWEET32 漏洞本体;删除并换为 34 个安全套件 |
| Elasticsearch | 7.6.1 在 ARM 上实测通过 | 该版本不存在 ARM 构建(7.8 起才有),安装实测 404 |
| parted | -s 配合交互参数可脚本化 |
新版静默失效直接返回 1,脚本化必须去掉 -s 用显式参数 |
| DHCP | 动态池与 MAC 绑定地址可以重叠 | 实测绑定地址会被动态池抢占,地址池必须给绑定留位 |
| 限流 | 延迟模式下第 10 个请求要等近 3 秒 | 实测每项仅多等 0.33 秒,旧版数学不成立 |
这六条没有一条是”文风问题”,全部是照抄会出事故的事实错误——这就是实跑验证的价值密度。
批次经济学也值得记录:10 个批次合计约 1.5 亿 token,单批耗时 30~80 分钟,批内的所有中断都靠进度标记文件恢复——有一次批次收尾阶段挂掉,但 10 篇文章已全部落盘,重派一个会话读标记文件接着收尾,零篇重做。
写在最后
这轮翻新最深的体会是:批量 agent 工程里,”验证”必须是产物的一部分,而不是交付前的检查。agent 在容器里跑出的每一条输出、渲染的每一张图,既是文章的内容,也是文章的证词。规范里那句”跑不通的不得写进文章”,比任何文风要求都更能保证质量。
下一篇文章会把这些实跑沉淀再拧一层:93 篇旧文重测挖出的 CentOS 7 → Rocky 9 差异清单,运维向,照着清单迁移可以少踩一遍坑——CentOS 7 停服迁移实战:重测 93 篇旧文挖出的 el7→el9 差异清单。
本系列:(一)我给 AI 搭了条产线,然后被首篇文章教育了 | (二)本文 · 批量翻新实战 | (三)发布前的六道自动体检