我用不到4小时把25篇 Medium 文章搬到了自己的博客

一个本来应该继续躺在备忘录里的项目

我想把 Medium 上的文章搬到自己的博客，已经想了一段时间。

不是因为我想离开 Medium。Medium 仍然是一个有用的发布平台。它给写作一个表面，一个网络，也给文章一点走出自己圈子的机会。

但当我越来越认真地写 AI、软件工程和叙事之后，我开始需要一个更像“家”的地方。Medium 像一间租来的公寓。方便、好用、也布置得不错，但终究不是自己的。

我想要一个有自己结构、自己设计、自己归档的地方。最终，我也希望它能同时容纳英文和中文版本。

算一下就知道，这件事并不轻松：大约 25 篇文章，每一篇都需要抓取、格式整理、页面生成、标签分类。因为我想做双语发布，还要翻译成中文。手动做的话，肯定不止一个周末。更现实一点说，这就是那种会一直躺在备忘录里，标题叫“个人网站迁移”，直到你换邮箱都还没开始的项目。

最近我听了不少关于 Hermes agent 的讨论，于是决定试试看。

结果是：不到四个小时，我有了一个可以运行的博客网站。文章被迁移了，中文版本也生成了，标签和分类都整理好了，甚至 About Me 写得比我自己写的还要好。

这听起来像是那种为了把 AI 写得很神奇而故意包装出来的句子。

但真正有意思的，不是它成功了。而是它在哪些地方差一点就成功了。

迁移：抓取很有用，但并不完美

我让 agent 做的第一件事，是抓取我的 Medium 文章归档。

这比我们想象的都要难。Medium 并不是一个为批量导出而设计的平台。它有预览、有不同页面结构、有访问限制，同一篇内容在不同页面里暴露出来的方式也不一样。

最开始的几次尝试，都没有完整抓到正文。Agent 需要不断调整：换一种方式，部分失败，检查结果，再换一种方式，再改进。

经过几轮试错和反馈之后，它成功抓下了 25 篇里的 20 篇，而且格式几乎都整理好了。剩下 5 篇抓不到，可能是付费墙、访问限制，或者页面结构不适合批量抓取。

一次拿到 80% 很厉害，但真正重要的是：我必须检查。 我得数文章数量。我得发现缺口。Agent 可以抓取，但它不能可靠地告诉我它漏掉了什么。

所以我又把那 5 篇缺失文章的链接逐个贴给 agent。单篇 URL 比归档页更容易处理。这一次成功了。最后，25 篇文章全部落到了磁盘上。

这个结果既让人兴奋，也让人清醒。

兴奋的是，如果手动复制、整理 25 篇长文，这件事会非常无聊。我大概率又会把整个项目往后拖。

清醒的是，agent 并没有神奇地绕过所有限制。它仍然要和平台结构打交道。它仍然会漏东西。它仍然需要验证。

抓取不是智能。抓取更像是谈判。Agent 在和 Medium 的结构谈判，它谈到了足够有用的程度，但还没到可以盲目信任的程度。

网站设计：少，不等于没有

我告诉 agent，我想要一个极简博客。不是热闹的作品集，也不是创业公司的落地页，而是一个安静的写作空间，有一点粉色强调色，让文章本身成为主角。

Agent 设计了网站，搭好了结构，创建了路由，组织了内容。它选择了一个干净的主题，有浅色和深色模式，有充足留白、粉色点缀，以及把正文放在中心的布局。

这一部分意外地顺利，因为需求很清楚。博客是一个成熟的模式。它需要文章列表、文章详情页、导航、元数据，也可能需要语言版本。Agent 不需要发明一个全新的产品形态，只需要按照我的偏好实现一个熟悉的结构。

这正是 agents 有用的地方。

当目标足够结构化，审美方向也足够清楚时，它们可以推进得非常快。

网站第一版不需要完美。它需要先存在。仅仅这一点，就会改变一个项目的能量。

翻译：很快，但“翻译完”不等于“可以发布”

我让 agent 把全部 25 篇文章翻译成中文。

第一版看起来很完整，直到我真的开始读。

有些句子翻得很顺，但另一些句子显得僵硬、不自然。还有英文词散落在中文里。上一句可能翻得很好，下一段突然冒出一个英文词，像米饭里硌到一颗小石子。比如 “exhilarating.”、“prosper.” 这种小词，立刻就会打断阅读。

远看像是完成了。近看并没有。

我让 agent 做了第二轮，专门处理这些残留英文。第二轮修掉了大部分，但没有全部修完。我自己检查时又抓到了一些。

翻译很适合说明“生成”和“可发布”之间的距离。 技术句子也许可以承受粗糙翻译。反思性的句子不行。而当写作本身很个人、语气承载了一半意义时，从“生成了”到“可以发布”，中间的距离比看起来大得多。

第一版有了基本意思。第二版更完整。但即便如此，对于我在意的写作，我也不会把翻译当成一个完全自动化的步骤。

那个让我停顿的 About Me

整个迁移里，最让我意外的时刻，和抓取、建站都没有关系。

是 About Me。

Agent 抓取了我的 Medium 个人主页。但它没有停在那里。它似乎也读了我的文章，并且综合出了一些我从来没有明确告诉它的细节。

比如我同时有传播和软件工程背景。比如我写作里的主线：AI、认知、叙事，以及技术如何改变人思考的方式。这些细节，我从来没有写进任何简介里。

Agent 写出了一个比我自己会写得更好的 About Me。

那种感觉很奇怪。倒不是可怕。更像是有人比你预期中更认真地读了你的作品，然后把你总结了一遍。

写自我介绍本来就很难。大多数人不是低估自己，就是用力过猛，或者把自己压扁成几个职位名称。我们写的是自己觉得“可以说”的东西，不一定是作品一直在替我们说的东西。

Agent 没有这种犹豫。它横向看了我的文章，找到了那条线。它在我命名之前，看到了形状。

这也许是 AI 在创作里一个被低估的用途：不是从零生成，而是把你自己的作品里已经存在的模式反射回来。

它没有发明我。它压缩了关于我的证据。

第一轮用的是 Kimi K2.6

这次迁移的第一轮，我用的是 Kimi K2.6。

我不想把这篇文章写成模型排行榜，因为那不是这个实验的重点。我不太关心某个模型是否“赢了”，更关心它能不能在一个混乱、多步骤的工作流里持续有用。

这不是一个单提示词任务。它涉及抓取、调试、文件组织、网站设计、翻译、清理和迭代。在这样的工作流里，模型能力当然重要，但工具使用、持续推进、上下文处理，以及从部分失败里恢复的能力同样重要。

Kimi K2.6 帮我很快把想法推进成了一个可运行的网站。但更重要的经验，并不是关于某个模型，而是关于协作的形状。

我不是在让模型给我建议。我是在让它执行。

这是完全不同的测试。

从一个 YouTube 链接开始的多 Agent

迁移之后，我开始实验多 agent 设置。

我之前听过这个概念：不同 agent 扮演不同角色，并行运行，共享记忆，互相交接工作。理论上听起来很强。

我是在一个讲共享记忆和日志的 YouTube 视频里学到这个多 agent 设置的。创作者给了一个几乎简单到荒谬的建议：把视频链接贴给 agent，然后让它搭建这个系统。

所以我试了。我复制 YouTube 链接，贴进 Hermes，然后输入：“帮我创建这个多 agent 设置。” 让我意外的是，它真的做出来了。Agent 把视频里的想法变成了一个实际可运行的结构。

这句话现在想起来还是很荒谬。但事情确实就是这样发生的。

Agent 创建了整套设置：一个共享工作区目录、每个 agent 角色的每日日志、基于 markdown 文件的交接协议，以及可以把多个 agent 并排打开的 tmux 启动脚本。

我从三个 agent 开始：Writer、Designer 和 Translator。每个都有自己的角色设定，也分配了不同模型。它们在一个 tmux 会话里并排运行。Writer 负责草稿，Designer 思考呈现，Translator 负责语言转换。

共享工作区是关键：把文件系统当成邮箱。一个 agent 写一个文件，另一个 agent 读它。不需要复杂基础设施，只需要约定和 markdown 文件。

端到端的文章流水线

我又往前推了一步，用一个 orchestrator 脚本搭了端到端流水线。流程大概是这样：

概念 → 草稿 → 编辑建议 → 作者确认 → 应用编辑 → 配图 → 翻译 → 校对 → 集成

理论上，它很漂亮。看起来像是在你的机器里跑着一个小型编辑生产团队。

每个阶段由不同的 agent profile 处理，并根据任务分配不同模型：

Agent	阶段	模型 - 默认 / 备用
Writer	概念与草稿	deepseek-v4-pro / kimi-k2.6
Editor	编辑（建议 + 应用）	gpt-5.5 / kimi-k2.6
Illustrator	图像生成	gpt-5.4-image-2
Translator	中文翻译	deepseek-v4-pro / kimi-k2.6
Proofreader	最终质量检查	gpt-4o-mini / kimi-k2.6
Developer	发布与集成	kimi-k2.6

---

这个流水线围绕自动交接设计。一个阶段产出结果，下一个阶段接着处理，系统继续往前走。配图和翻译并行运行。作者确认会暂停流水线，等人工审核后，应用编辑阶段接过批准后的修改，流程再继续。

我拿一篇文章跑了一次完整流程。整个过程大约 50 分钟。在作者确认阶段，我没有提供人工反馈。我想看看这个系统自己能做到什么程度。

诚实评估：50 分钟，和多轮迭代得到的东西

结果和我平时跟一个 agent 多轮迭代出来的版本相比，差得还比较远。

文章结构是完整的，但缺少我在多轮打磨里能得到的锋利度。翻译又出现了迁移时同样的英文残留问题。校对抓到了一些问题，但也漏掉了另一些。

这里有一个很具体的失败模式，我想把它说出来：一旦工作流变得顺滑，它也会非常高效地把不够好的东西往前推。

一个糟糕的草稿，会变成一个糟糕的翻译稿。 一个模糊的概念，会变成一篇精致但仍然模糊的文章。 一个弱句子，会被校对，而不是被重写。 一个普通的想法，会被集成，而不是被挑战。

在人类编辑流程里，总会有人停下来问一句：“等一下，我们到底想说什么？”

自动化流水线没有足够多地做这件事。

它一直在动。它没有停下来。而好的写作，往往依赖那个停顿。

瓶颈出现在那些需要品味的阶段：写作、编辑和翻译。 这些都不是机械任务。写作不是遵循提示词。编辑不是查找替换。翻译也不是逐词转换。它们都需要理解一段文字“想成为的样子”，而不只是它现在已经是什么。

多 agent 流程创造了一个完整成品。但完整不等于好。

我仍然认为多 agent 工作流有真实潜力。但这个实验确认了我之前的怀疑：一个 agent 加上人的多轮迭代，仍然胜过很多 agent 但没有人的判断。

瓶颈不是吞吐量，而是品味。而品味不能被流水线化。

关于人的角色

做完这些之后，我不觉得正确的问题是：“AI agents 能不能做这些工作？”

更好的问题是：工作里的哪一部分是劳动，哪一部分是判断？

Agent 极大压缩了劳动。它抓取内容，创建文件，搭建页面，翻译草稿，生成结构，创建多 agent 系统，运行流水线。

但我仍然要判断结果。我得发现缺了 5 篇文章。我得抓到不完整的翻译。我得判断设计是不是对味。我得意识到 About Me 意外地好。我得把流水线产物和自己的质量标准放在一起比较。

这就是我不断回到的人的角色。不是亲手做每一个手动步骤。不是假装 AI 帮不上忙。但也不是放弃控制权。

更有用的角色，越来越像是编辑、架构师和品味守门人同时存在。你定义结果。你设定约束。你审阅作品。你决定什么可以发布。

Agent 可以做很多。但“很多”不等于“最终决定”。

真正需要改进的地方

如果明天让我搭一个更好的版本，我不会加更多 agent。我会加更好的关卡。这个工作流需要更多判断点，而不是更多吞吐量。

作者确认不应该是可选的。没有人工反馈，就不进入下一阶段。 否则，系统只会变成一条生产“看起来完整但其实还不够”的初稿流水线。

Editor 需要更有立场。不能只是“提出改进建议”，还要挑战核心论点：这篇文章有没有说出新的东西？哪里开始变得泛泛而谈？读者应该记住的那一句话是什么？

翻译阶段需要明确的质量检查：检查是否还有英文残留，标出听起来像直译的句子，确认每一段都有文化上的对应，而不只是词典上的对应。

校对阶段也需要更强硬：检测残留的源语言文本，检查格式一致性，包括标题、列表、markdown、元数据、链接、图片说明，并标出中英文版本之间不一致的术语。

一种奇怪的感觉

不到四个小时，我把所有 Medium 文章搬到了一个属于自己的博客网站。

有一种工作之所以会死掉，不是因为难，而是因为烦。内容迁移就是这种任务。搭一个个人博客有时候也是。清理文件、创建页面、翻译草稿、整理文件夹，这些事每一件都小到无聊，但合起来又大到足以让人失去动能。

Agent 移除了足够多的摩擦，让这个项目真的发生了。这很重要。

这也是我现在觉得 AI agents 最有意义的地方。不是它们让一切变完美。它们不会。也不是它们移除了人。它们不应该。但它们改变了一个项目的启动能量。

它们让开始变得更容易。 它们让第一版更快出现。 它们把模糊的意图变成可见的东西。

而一旦某个东西可见，我就可以回应它。我可以编辑它。我可以改进它。我可以决定。

Agent 做了无聊的工作。我做了判断的工作。对这类项目来说，这已经足够让整件事变成现实。