把博客的重复劳动交给 Agent 的改造方案
以这个博客为例，拆一遍哪些运营劳动适合交给 Agent、哪些必须留在人手里，附上具体的任务清单设计。
写博客三年，我越来越觉得最累人的不是"写"，而是写之外的那一大堆琐事：每篇要检查 Markdown 格式对不对、SEO 的标题和描述补没补、封面图尺寸压没压、发布前通读一遍链接有没有死链、改完错别字再统一提交。这些事单篇只要二十分钟，但一周三四篇积累下来，几乎吃掉我一半的业余时间。更糟的是它们低价值、高频、且极易因为"赶着发"而被跳过，结果就是博客质量忽高忽低，读者未必说得出哪里不对，但就是觉得"这篇有点糙"。
于是今年我把这批重复劳动系统性地交给了 Agent。不是简单地"写了个脚本"，而是把其中一部分升级成"可以自己判断、自己兜底"的 Agent 任务。这篇文章想讲清楚两件事：第一，哪些活真的适合交给 Agent，哪些看着像但其实不该；第二，从"写脚本"到"交给 Agent"之间那条该不该跨的阈值在哪里。我会把我家博客实际用的工具栈、每一项任务的落地代码、以及改造前后的时间账都摊出来。
我不会把自动化说成万能。恰恰相反，我踩过的坑有一半来自"过度自动化"：把不该让机器判断的事也交了出去，反而引入了新的错误来源。下面把盘点和取舍都讲清楚，希望你别重交一遍学费。
博客运营的重复劳动盘点
先把我自己每周在做的"非写作"劳动列一遍，这是后面判断的素材。我按"是否规则化"给每项打了标，方便后面对照。
- Markdown 格式检查：标题层级是否跳跃、代码块有没有闭合、图片路径是否存在、中英文之间有没有该加的空格。这类高度规则化，错就是错。
- SEO 元信息补全：每篇文章的
title、description、keywords、Open Graph 标签是否齐全且不过长。规则明确，但"写什么词"带一点品味。 - 封面图处理：统一尺寸、压缩体积、生成不同分辨率的版本、命名规范。纯机械，零判断。
- 发布前检查：通读全文找死链、找断裂的锚点、找错别字、确认内外链可达。规则与判断混合。
- 死链扫描：定期爬全站，找出已经 404 的站内站外链接。纯事实，零判断。
- 引用巡检：确认文末引用的来源链接仍然有效，且没有被对方改得文不对题。这里"文不对题"带语义判断。
这六类里，前五项高度规则化，判断空间小；最后一项带一点"语义判断"，但不多。真正完全不适合自动化的，是"这篇写得有没有价值""观点站不站得住"：那是只有我自己能做、也必须自己做的部分，我绝不会交出去。划清这条线，后面所有决策都有了锚点。
哪些适合自动化，哪些不适合
我的判断框架只有一条主轴：这件事的判断依据是"规则"还是"品味"？规则能写清楚，就可以自动化；品味写不清楚，就别碰。
适合自动化的，是那些"错了能被机器自己发现"的活。比如格式检查，错就是错，标准明确；死链扫描，返回 200 还是 404 是铁事实。这类任务交给 Agent 后，即使它偶发漏判，人工抽检也能低成本兜住。封面图处理更是教科书级的自动化对象：输入一张图，输出几张固定规格的图，中间没有任何需要"理解"的环节。
不适合自动化的，是那些"错了只有人能看出来"的活。最典型的是"改写标题以更吸引人但不标题党"：这件事的边界极度依赖品味，机器很容易滑向夸张，而我一旦没审就发，伤害的是博客的长期信誉。还有"根据读者反馈调整观点"，这涉及我对议题的真实判断，交出去等于把博客的灵魂外包了。我见过有人把"选题"也自动化了，用 Agent 扫热点生成选题清单，结果博客越写越像资讯聚合号，丢了自己的声音，这就是把品味外包的代价。
我给自己划的红线是：任何会直接改变"我说了什么"的步骤，都留在自己手里；任何只改变"它长什么样、在哪、能不能打开"的步骤，都可以自动化。这条线帮我挡掉了很多危险的自动化冲动。再补一句更硬的：凡是产出会直接对读者可见且带"观点属性"的，人工终审；只带"呈现属性"的，可以机器终审。
从"写脚本"到"交给 Agent"的阈值
很多人问我：这些事用脚本不就行了，为什么要上 Agent？我的答案是看"异常处理的复杂度"。如果一个任务的正常路径占九成、异常路径能枚举干净，脚本更稳更快，别用 Agent。
阈值出现在"异常无法被完整枚举"的时候。举个例子，发布前检查死链：大部分链接正常，但偶尔会遇到"返回 403 因为对方防爬""返回软 404 但状态码是 200""跳转三次后才是真地址"。这些边界脚本很难穷举，而 Agent 能基于页面内容判断"这到底算不算死链"。当任务需要"读懂情形再决定怎么办"，Agent 的性价比才显现。
我总结的阈值清单，照着逐条对就能少走弯路：
- 正常路径占比高、异常可枚举 → 写脚本，别用 Agent。
- 需要读懂非结构化内容再决策 → 可以考虑 Agent。
- 失败成本高、且 Agent 可能误判 → 即使能用 Agent，也要保留人工确认闸门。
- 任务频率低、单次就行 → 不值得为它专门做 Agent，手动更快。
- 需要跨多步推理且中间要回看前文 → Agent 更合适，脚本会写成状态机噩梦。
Agent 不是脚本的升级版，而是"脚本处理不了模糊性"时的另一个工具。我用它的场景，几乎都卡在"模糊"二字上。封面图压图我用脚本（Pillow 一行搞定），死链语义判断我用 Agent，这个分工跑了半年没出过事故。
具体任务逐项拆解：我的自动化清单
光讲原则太空，下面是我家博客实际落地的四项自动化，每一项都给代码，方便你照抄或避雷。
Markdown 格式检查，纯脚本，零 Agent。它要的是确定，不是聪明：
import re
from pathlib import Path
def lint_md(path: str) -> list[str]:
text = Path(path).read_text(encoding="utf-8")
errors = []
lines = text.splitlines()
# 标题层级不能从 # 直接跳到 ###
last_level = 0
for ln in lines:
m = re.match(r"^(#+)\s", ln)
if m:
level = len(m.group(1))
if level > last_level + 1 and last_level > 0:
errors.append(f"标题层级跳变: {ln[:20]}")
last_level = level
# 代码块必须成对
if text.count("```") % 2 != 0:
errors.append("代码块未闭合")
return errorsSEO 元信息补全，我用 Agent 生成草稿、我确认。它要"写词"，带一点品味，但不决定观点，所以交出去安全：
def build_seo_prompt(title: str, body: str) -> str:
# 让 Agent 只产出草稿，且必须附理由，便于人工快速判断
return (
f"为下文生成 description(80字内)和 keywords(5个)。"
f"标题: {title}\n正文前500字: {body[:500]}\n"
f"要求: 输出同时给出'为什么这样写'的一句话理由。"
)封面图处理，纯脚本批处理。我固定生成 1200x630 的社交图和 800x400 的列表图：
from PIL import Image
def make_covers(src: str, out_dir: str):
im = Image.open(src).convert("RGB")
for size, name in [(1200, 630), (800, 400)]:
im.resize((size[0], size[1])).save(f"{out_dir}/cover_{name}.jpg", quality=82)死链扫描，外层脚本探活、内层 Agent 做软 404 判断。脚本负责快进快出，Agent 只处理"状态码 200 但内容像出错页"的疑难样本：
import requests
def scan_links(urls: list[str]) -> dict:
result = {"dead": [], "suspect": []}
for u in urls:
try:
r = requests.get(u, timeout=8, headers={"User-Agent": "blog-bot"})
if r.status_code >= 400:
result["dead"].append(u)
elif "page not found" in r.text.lower():
result["suspect"].append(u) # 交给 Agent 语义判断
except requests.RequestException:
result["dead"].append(u)
return result这四项的分工刚好印证了前面的阈值：确定性强的用脚本，模糊的用 Agent，且 Agent 只接"难样本"而非全量，成本和误判都压到最低。
发布前检查：一个完整流程设计
下面是我实际跑的"发布前检查" Agent 流程。它结合了脚本的确定性（链接可达性）和 Agent 的判断力（内容层面的问题），并在最后留了一个人工闸门。
第一步，脚本层做硬检查，速度快、零歧义，见上面的 lint_md 和 scan_links 思路。第二步，Agent 层做软检查，读全文判断语义层面的问题：标题是否和正文不符、锚点是否对得上小标题、有没有明显的事实性硬伤措辞。这一步我给 Agent 的指令非常克制，只让它"列出可疑点并给出理由"，不做任何修改。
第三步，汇总结论。脚本的硬错误是阻断级的，只要有站内死链，直接卡住发布；Agent 的软提示是建议级的，列出来给我看，我决定改不改。这个"硬阻断 + 软建议"的二分，是整个流程不翻车的关键。
def gate(hard: list[str], soft: list[str]) -> bool:
# 硬错误阻断发布，软提示仅展示
if hard:
print("阻断：存在硬错误", hard)
return False
if soft:
print("建议人工确认：", soft)
return True我特意没让 Agent 自动改完直接发。发布是离读者最近的一步，我把最终点头留给自己。Agent 的角色是"把要我看的疑点提前捞出来、排好优先级"，而不是"替我做决定"。这个定位让我既省了时间，又没丢掉掌控感。后来我把这个闸门做成了一个命令行：blog check 文件路径 先出硬错误，过了再 blog review 文件路径 出软提示，两步分明。
我的自动化工具栈
讲完任务，说一下我实际用的一层薄工具栈，避免你以为要上多重的平台。我的原则是"能用现成 CLI 就别造轮子"。
- 格式与链接：上面那几个 Python 脚本，挂在
pre-commit上，每次git commit自动跑。 - 封面图：Pillow 脚本 + 一个
make covers命令，写完后顺手敲。 - SEO 与软检查：一个轻量 Agent 封装，底层走我博客后端的 OpenAI 兼容接口，prompt 固定在仓库里版本管理。
- 调度：死链扫描用系统
cron每周日凌晨跑，结果发到我的笔记 inbox，只在有dead时才通知我。 - 存储：所有检查结果写回每篇文章同级的
slug.check.json，发布流水线读取它决定是否放行。
整套东西没有引入任何重依赖，全部是几百行脚本 + 一个 Agent 调用封装。我想强调这点，是因为很多人一听"交给 Agent"就觉得要上编排框架、上向量库、上一整套平台。对我这种个人博客，过度工程才是最大的坑。Agent 在这里就是一个"会读页面判断死链"的函数调用，仅此而已。
改造后的每周时间账
光说省时间不够直观，我记了改造前一周和改造后稳定期的实际耗时，单位按"篇"摊到每周约四篇来算。
- 格式检查：改造前每篇约 8 分钟，改造后脚本自动跑、我扫一眼报告约 1 分钟。
- SEO 补全：改造前每篇约 6 分钟手填，改造后 Agent 生成草稿我确认约 2 分钟。
- 封面图：改造前每篇约 5 分钟手动压图，改造后脚本批量处理约 0 分钟（顺手完成）。
- 发布前检查：改造前每篇约 12 分钟通读，改造后 Agent 预检 + 我针对性复核约 5 分钟。
- 死链扫描：改造前每月专项花 1 小时，改造后定时任务每周跑、异常才通知，摊到每周约 5 分钟。
加总下来，每周从大约 160 分钟的非写作劳动，降到大约 50 分钟。省下的两个多小时，我拿去读论文和写更有深度的长文，博客真正值钱的是这部分。另一个变化是质量曲线变平了：以前赶时间会跳过检查，现在检查是零摩擦的，反而更少出错。读者最近留言说"你最近排版稳了"，我知道那是自动化替我兜住了下限。
踩过的坑：别把"判断"也交出去
最后讲两个我交了学费的坑。第一，我曾让 Agent 直接"顺手修掉错别字并发布"，结果它把一处我故意用的口语化表达当错字改成了书面语，语境全变。从此我规定：Agent 可以标，不能改"表达风格"类问题，只能改"确定性错误"类问题（比如把 {xxx} 渲染错的占位符补上）。改和标是两件事，标是辅助，改是替我决策，这条线不能混。
第二，SEO 描述我一度完全信了 Agent 生成的那版，后来发现它为了凑关键词堆了重复词，读起来像垃圾站。现在我要求 Agent 生成后必须附一句"为什么这样写"，我读那句就能快速判断它是否理解了文章。让 Agent 解释自己的产出，是我筛掉低质自动化的一个廉价手段。还有一次死链扫描的 Agent 把"登录页返回 200 但内容为空"判成了正常，我加了一条规则：空正文且长度小于 50 字一律标 suspect。这些补丁都来自真实翻车，攒成现在的稳定流程。
自动化不是一蹴而就：我的渐进路线
我建议的落地顺序是"先零风险、后高风险",别一上来就把所有环节都交给机器。第一步只接封面图处理和死链扫描,这两项零判断、错了也只影响呈现,即使 Agent 抽风最多图歪了或漏报一个死链,代价可控。跑顺两周、建立信任,再上格式检查。SEO 和发布前软检查是最后才接的,因为它们离"我说了什么"更近,需要我更紧地盯着。
这个渐进路线还有一个好处:每一步你都在积累"机器靠不靠谱"的样本。等接 SEO 时,你已经知道它在封面图任务上的误判率大概多少,心里有底。一口气全上的团队,往往在第一周就遇到某个环节的离谱错误,然后一气之下把整个自动化全关了，这是我见过的典型失败模式。自动化像信任,是逐次小额建立起来的,不是一次授权拿走的。
当 Agent 判断出错时，怎么兜底
自动化最怕的不是它经常错,而是它"自信地错"。我的兜底有三层。第一层是范围隔离:Agent 永远只在副本上操作,不直接改源文件,确认无误我才 apply。第二层是差异可见:任何 Agent 的修改都生成 diff,我扫 diff 比扫全文快十倍,异常一眼就能看出来。第三层是可回滚:所有自动化产出带时间戳版本,出问题 git revert 即可,不慌。
我还给 Agent 设了"不确定就明说"的规矩。比如死链语义判断,置信度低于阈值时它必须标 suspect 而非 dead,宁可让我多看一下,也不擅自下结论。这条规矩把"静默误判"转成了"显式待确认",是我整套兜底里最值钱的一条。它成立的代价只是偶尔多耗我几分钟,换来的是再没出过"机器悄悄发错"的事故。
把检查织进发布流水线
单独跑检查脚本容易忘,我把它织进了发布流水线:本地 blog publish 文章slug 会依次跑格式检查、死链扫描、SEO 校验，任一硬错误直接中断并给出行号；全过才生成静态页并打 git tag。这样"发布"这个动作本身就成了质量闸门,想跳过检查得主动绕过命令,成本高到没人愿意。
对单人博客来说,这种"把纪律写进命令"比靠意志力靠谱得多。我以前也试过"发之前记得跑一下检查",结果忙起来就忘;现在不跑检查根本发不出去,纪律由工具兜底,人只管内容。这也是我把重复劳动交给 Agent 的底层哲学:让机器承担"记得做",让人专注"做得好"。
一个真实的翻车与修复记录
讲一个我印象最深的事故,它让我把"硬阻断"这道闸从可选改成了必选。有次我图省事,把发布前检查设成了"有软提示也不阻断",因为那天赶着发一篇时效性强的稿。结果 Agent 标了个"标题与正文疑似不符"的软提示,我扫了一眼觉得没事就发了。第二天读者指出,标题写的"全面解析"但正文只讲了三个点,确实有夸大。虽然不致命,但损害了我一向在意的严谨人设。
修复很简单:把软提示也接进发布闸门,但分成"必须看"和"建议看"两级，标题类问题升为"必须看",错别字类保持"建议看"。同时我加了一条铁律:时效性稿可以走快速通道,但快速通道也要在发后二十四小时内补一次完整检查。这次翻车没造成大损失,但它教会我:自动化的闸门可以分级,但不能被"赶时间"整体绕过,否则绕过一次就会有第二次。
检查项的边界：什么时候该关掉自动化
自动化不是永远该开着。我发现两类情况应该主动关掉或调低某些检查。第一类是"创作早期草稿":这时候格式乱、链接没填都正常,跑检查只会刷一堆噪音打击写作心流,我只在定稿后跑。第二类是"实验性内容":比如我写的一篇吐槽文,故意用了不规范标点,格式检查会狂报错,这种时候关掉反而清爽。
判断标准就一句:当检查的输出频率远高于它的修正价值时,关掉它。检查是手段不是目的,它的存在是为了在"该认真"的时刻兜底,而不是在每个随意的时刻制造负担。我会给博客的草稿目录和正式目录配不同的检查配置,正式目录全开,草稿目录只开死链这种"错了真疼"的项。这种差异化配置,让自动化既可靠又不烦人。
度量改造本身：别让自动化成了新负担
我定期回看自动化花在我身上的"维护时间"。如果某条自动化平均每周救我十分钟,但它自己每周要我修五分钟 bug,那它就是负收益,该删。博客自动化跑半年,我删过两条:一条是自动生成"相关文章推荐",因为我发现它推荐的关联性很弱、读者从不点;另一条是自动校对英文术语,误报太多反而拖累。删掉后整体反而更顺。
这条原则叫"自动化也要算 ROI"。工具的寿命不该靠沉没成本维系,而该靠它持续产生的净收益。我每季度做一次"自动化盘点",留下净正的、砍掉净负的、合并重复的。保持这个习惯,你的工具栈才不会越长越臃肿,最后变成另一份重复劳动。写博客是为了表达,不是为了养一堆半夜报错的脚本。
当博客规模变大，自动化怎么演进
内容多到几十篇后,我加了一个"全站体检"任务:每周扫一遍所有历史文章,检查有没有格式在新规范下变旧、有没有新出现的死链、SEO 描述是否需要随搜索趋势更新。这个任务单次要跑很久,所以是离线的、结果进一个待办清单,我周末统一处理。它把"自动化"从"单篇发布时"延展到了"全站生命周期",是我博客进入第二个年头后最值钱的一条。没有它,旧文章会像温水煮青蛙一样慢慢变质,而我根本察觉不到。
另一个演进是"读者反馈闭环":我让 Agent 每周汇总读者来信里提到的错误,生成一份"疑似勘误"清单。它不自动改,只列出来,我确认后手动修。这一步把"人工读信"也部分自动化了,但保留了最终判断，和发布前检查同一套哲学。规模变大后,自动化的价值不在于省单次时间,而在于让"持续维护"这件事不再可怕。一个人维护几十篇长文,靠的不是勤奋,是让维护本身变成低摩擦的习惯。
一点工具选型的私心
很多人问用哪家模型做这些 Agent 任务。我的选法很朴素:格式、死链这类确定性校验根本不需要大模型,规则脚本就行;只有 SEO 生成、软检查这种要"理解"的才调模型,而且用便宜的中小模型足够,不必上旗舰。博客自动化对延迟不敏感(我又不等它回复),所以我把 batch 任务全排在低价时段跑,成本几乎可以忽略不计。
工具选型上,别为低频任务付高价,这是个人项目最该守的纪律。我曾试用过一个昂贵的 Agent 平台来做死链扫描,月底账单吓一跳,换成自写脚本加廉价模型后,效果一样、成本零头都不到。自动化的 ROI,往往卡在"你为先不先进付费"还是"你为省不省事付费"这个选择上。我的答案一直是后者。
一张表外的提醒：别神话自动化
最后想泼一点冷水。自动化能把"下限"稳住,但"上限"永远是人。我见过有人把博客做成全自动流水线后,文章反而越来越像机器生成,因为人把精力全花在调脚本上,忘了写。工具是仆人不是主人,这条界限一旦模糊,博客就死了。
我每周强制留半天"纯手写、不碰任何脚本"的时间,就是为了防止自己沦为自动化系统的运维。那半天里我不检查格式、不跑死链、不补 SEO,只对着空白页想把清楚一件事。回头看,博客里最被读者记住的几篇,都出自这种"没人管机器"的时刻。自动化省下的时间,只有流回"人该做的事"才叫赚,流去调机器本身,就是另一种重复劳动。
结语
把重复劳动交给 Agent，本质是把"我时间里的低价值部分"移到"机器的确定性部分"，把腾出来的注意力留给只有人能做好的判断。关键是守住那条线：机器管"对不对、在不在、能不能打开"，人管"值不值得说、怎么说才像我"。跨过这条线去追求"全自动发布"，短期爽，长期是在拿博客的信誉换懒惰。
我的建议很具体：先脚本化所有能脚本化的，再只在模糊处引入 Agent，并且永远在离读者最近的那一步，给自己留一个确认闸门。自动化不是目的，把省下的时间换成更好的内容，才是这件琐事值得做的唯一理由。半年跑下来，我最满意的不是省了那两小时，而是博客的下限终于稳了，而上限，依然牢牢握在自己手里。