我把博客当产品养：批次开发 + AI 结对
一个问题，五六年
这篇文章的起因很简单。我想回答一个问题：一个不会编程的人，是怎么把博客做成现在这样的？
为了找答案，我打开代码仓库看了一眼提交记录：558 次。
其中 207 次，集中在今年五月。剩下三百多次，也几乎没有一次是「一口气写完」的 —— 今天加个功能，明天修个 bug，后天再改回来。
那一刻我才想明白该怎么描述这个博客：它不是「做」出来的，是「养」出来的。
这篇不讲怎么搭博客，那种教程到处都是：随便找套主题，一天就能上线。我想讲的是「养」的方法：批次开发，把大目标切成一批批能交付的小事；以及 AI 结对，我负责想，它负责干。
装修思维：我的前五年
先说五年前的我，好给现在的做法当参照物。
2020 年疫情宅家，我在「奶爸建站笔记」这类教程站上第一次接触到 WordPress 建站，那个站现在还在更新。突然觉得，拥有自己的网站好像没那么难，就想搭一个自己的博客。结果上来就碰壁：像样的主题要钱，好用的插件也要钱。那会儿一分预算都没有，只能到处找免费方案。
之后几年，我几乎把主流方案试了个遍。中途折腾过 Typecho，还写过一篇《Handsome 美化记录》；2023 年换到 VuePress，一边学 JS 一边写博客，甚至研究过怎么给博客配置公众号导流插件；2024 年又试了 Halo，生态不完善，放弃。
问题就出在这：我一直在换，但从没有真正「用完」过任何一个。
2022 年末，我停下来问了自己一个问题：为什么每个方案都用不长？
原因有两个。第一个：服务器和 WordPress 我用不顺手。第二个才是根上的：我不会编程。我想要的功能，哪怕只是改个样式、加个模块，都实现不了，只能等主题作者更新，或者去翻插件市场。
那几年的模式是固定的：新鲜感 → 折腾 → 撞上不会的东西 → 停滞 → 换下一个方案。我管这叫「装修思维」：一直在换房子、换家具，却从没想过房子到底要怎么住。装修靠的是一股热乎劲，劲头过去，房子就脏在那里了。
转折点：Astro，和两个时代的 AI
转折有两半。
一半是 2025 年偶然遇到 Astro。最直观的冲击是编译速度：保存、刷新，页面几乎瞬间出来，顺滑得不像话。那是一种「想一直待在里面」的感觉。选型时我也认真考虑过 Strapi 这类方案，最后还是被这种写起来很轻的体验留住了。
另一半，是 AI。
最早的用法很笨：Astro 官方主题满足不了需求，我就让 AI 帮我加功能。但那时候的 AI 编程还是聊天式的，它给一段建议，我自己去改；改坏了再问，它再给一段。来回几次就没了耐心，项目又搁置了一阵。
2025 年下半年开始，情况变了。AI 发展突然加速，尤其是今年，氛围编程（vibe coding）加上各种 agent，「想改什么，当场就能改」：我把需求讲清楚，它直接动代码、跑构建、做验证，然后把结果摆到我面前。
我没变强。变的是工具链，它终于成熟到了「我这种人也能把事情做完」的程度。
于是这个博客进入了快车道。从今年春天开始，几乎每隔一两周就有一次像样的迭代，直到变成你现在看到的这个样子。
我的五步循环
养博客的第一步，是承认它养不完。功能永远可以加，样式永远可以调，这个博客没有「做完」的那天；所以真正重要的，是「用什么方式持续做」。
我现在的每一批工作，都走同一个循环：
graph LR
A[盘点] --> B[方案]
B --> C[批次]
C --> D[验证]
D --> E[存档]
E -.->|下一批| A
先说盘点：不动手，先看。现在有什么、缺什么、哪里在漏风。十月这次大改造之前，我先把插件、依赖、构建流程全部盘了一遍。不盘不知道，光依赖包的已知漏洞就有十个。
然后是方案：先写文档，再动手。哪怕只是「首页加个热门榜」这种小事，也把目标、步骤、回滚写清楚。以前我觉得这纯属浪费时间，后来发现恰恰相反，写方案会逼你把「好像要加个功能」变成「我要加什么、为什么加、到什么程度算完」。而且方案是我和 AI 之间的约定：它按方案执行，我按方案验收，扯皮少了一大半。
第三是批次：一次只解决一个主题，边界清清楚楚，不攒「顺便」。比如「把手工活干掉」是一批，「补历史欠账」是另一批。批次最大的好处是失败成本可控：这批搞砸了，回滚重来就好，不会把整个博客拖下水。
第四是验证：跑通才算完。本地构建要过、单元测试要过、线上还要抽查关键页面。这条我盯得最紧，它决定了我对 AI 的信任能放多大。AI 干活快是真的，偶尔自信地干错也是真的，后面细说。
最后一步是存档：每批结束后，把过程、坑和定稿的约定写进 AI 助手的「技能库」。下次遇到同类问题，直接按上次验证过的流程走，不重复踩坑。
这套循环没有什么原创性，就是把正经的软件工程压缩到了个人博客能承受的量级：方案不用长，三五行也是方案；验证不用全覆盖，关键路径都过就行。
案例一：把手工活一个个干掉
第一批认真做的大改造，主题叫「自动化」。
以前一套流程里，大半是我在动手：改完代码要一步步构建、上线，页面上的数据也得挂心着更新，改一次算一次，全凭记性。于是一批批地换，每一批只动一个环节。
先是部署。代码推到仓库，构建和上线全交给 CI，推完就走人。 然后是文章。我把文章拆进了单独的仓库，发文章变成「推一个文件」，站点自动收到通知、自动重建。 再然后是数据。番剧、书影音、随笔、友链文章，全部改成构建时自动抓取，再也不用维护列表。 还有杂活：首页的「近期热门」从统计服务的快照自动生成；友链申请做成了「GitHub Issue 表单 + 机器人自动校验、合并、重新部署」，别人提交申请，我点一个标签就完事。
现在一次全站构建是四百多页，一两分钟出结果；整套日常检查半分钟上下。这一批做完，博客上其实没多出什么看得见的东西，真正变了的是我这边的体验：想改点什么，改就是了，剩下的它管。
这一步最大的经验是：自动化要一件一件做。我试过一口气改三处，结果一处出错，三处一起回滚排查。也是从那时候起，「一批一件事」成了铁律。
案例二：补历史欠账
自动化搞顺之后，我开始还债。博客欠了两笔账：一笔是搜索引擎的账，索引一直不健康，六月修过一轮，还留了个「写了方案没实施」的尾巴（那次的记录在这里）；另一笔是双语的账，页面看起来是中英双份，实际上英文区展示的还是中文文章，属于「假双语」。
两笔都是历史遗留、都不加新功能，所以我把它俩放进同一批解决。方案写得很顺，实施过程却翻了两次车，都值得记下来。
第一次翻车：文件命名。我们约定英文文章用 <slug>-en.md 命名，和中文版配对。第一次构建直接报错，原来 Astro 会把文件名里的英文句点吞掉，blog-seo-practice.en.md 这个写法，到了 URL 里会变成 blog-seo-practiceen。一个句点的距离，排查了半个多小时。
blog-seo-practice.md → /article/blog-seo-practice/ ✓ 中文blog-seo-practice-en.md → /en/article/blog-seo-practice/ ✓ 英文配对blog-seo-practice.en.md → ✗ 别用，句点会被吞第二次翻车更有意思：本地测试全绿，CI 却挂了。原因是 CI 是干净环境，本地有个自动生成的目录、CI 里不存在，两边类型检查的口径不一样。修倒是好修，但教训很值钱：验证环境的一致性，决定了验证结果的可信度。后来我把「按 CI 的环境口径复测一遍」也写进了检查流程。
收尾验证是逐条打勾的：含测试文章的 28 项断言、空状态的 12 项断言、主题模板的独立构建、线上 7 项抽查。每一项都有据可查，没有一条靠「我觉得没问题」。
现在的结果：写一篇英文文章丢进仓库，全站自动配对翻译、语言切换器直达、站点地图互相标注、搜索引擎同步收到推送。那笔从六月就挂着的欠账，终于清了。（你读到这里时，站上的英文区和推送都在跑了。）
AI 结对到底怎么结
写了这么多方法，不少人真正好奇的是：跟一个 AI 结对，到底谁在干活。先交代一句，我用的 AI 助手叫 Hermes，是跑在自己电脑上的 agent。我们的分工是：
| 我负责 | AI 负责 |
|---|---|
| 选题和方向感 | 调研、起草方案 |
| 拍板和口味：「这个不好看」 | 写代码、改代码 |
| 定验收标准 | 跑验证、出证据 |
| 说不（比说是重要） | 把过程写成技能，下次复用 |
用下来有三个心得，都不太好听。
第一，AI 会自信地犯错。前面 .en.md 那个命名就是它先提出来的，直到构建爆炸才暴露。它犯错的方式比较隐蔽：听起来都很合理，所以才更需要用验证把关。
第二，结对的质量取决于你的验收标准，和它的聪明程度关系不大。我给它立过一条规矩：不许说「完成了」，必须给证据：构建产物、测试输出、线上页面。规矩立完之后，「成功」里掺水的明显少了。
第三，别把它当搜索框用。搜索框是你问一句它答一句；结对是它动手改、你提意见、它再改。有时候它写方案写得比我想的还细，那就让它细，我只看方向对不对。
顺便说，连这个博客的配图都是结对产物：从最早的「blob 小黑」到现在的铅笔少年，那套插画风格就是跟 AI 一起磨出来的。
把坑变成技能
我的 AI 助手有套「技能库」，可以理解成它的长期记忆。每个批次结束，我把这次的经验写进去：踩过的坑、验证的口径、定稿的流程。
看起来不起眼，但它是整套方法里最有复利的一环。
举几个已经进库的例子：英文文章文件名不能用句点；CI 和本地的类型检查口径有差异，提交前要按 CI 口径复测；图片引用的路径在三处目录必须逐字一致。这些坑我以前会踩第二次、第三次，现在它们变成了规则，在写作、构建、发布的每个环节自动生效。
博客欠的「技术债」因此越还越薄。这可能是 AI 结对最被低估的用法：让它把你们的协作经验存下来，给未来的你省时间。
写在最后
558 次提交之后，我对这个博客的感觉变了。
回头看，它最值钱的地方是长出了一套「能一直长下去」的方式。主题会过时，功能会重做，但方法不会。我不再是那个「换个主题就重新开始」的人了，每一次提交都在给下一次铺路。
最后给同样想养一个博客、或者任何一个长期项目的你三条建议：
一是别追求毕其功于一役。把目标拆成批次，一次解决一件事。做不完没有关系，半途又换方向才最伤。
二是先方案后动手，哪怕方案只有三行。写下来的过程，会让手先停一停。
三是让 AI 干执行的活，但验收标准必须由你定。人可以外包工作，不能外包判断。
装修管一时，养管很多年。
五年前我想要一栋「漂亮的房子」；现在我有一座会自己长大的花园。
