看过我之前文章的同学应该知道，我和 Firekylin 的缘分已经很久了。2016 年我还写过一篇《PMBlog 转火麒麟》，当时为了搬博客，专门写了个导出插件。后来博客又折腾过其它方案，不过兜兜转转，这次我又把 Firekylin 拿出来折腾了一遍。

区别在于，这次有 AI 一起干活了。

本来是个积累了不少历史包袱的老项目，这一轮却从基础库、后台组件，一路改到了模板引擎和插件体系。折腾下来最大的感受就是：AI 真的太强了。

本地示例站点的默认主题首页，使用展示用文章。

老项目升级，AI 比我想象中能干

Firekylin 是一个有些年头的项目，里面不少基础库也跟着停留在了很多年前。拿 React 来说，这次直接从 0.15 升到了 React 19，原来的 Class Component 也一起改成了 Function Component。其它基础库的升级同样跨过了好几个大版本。

这种升级如果自己做，光是看各个版本的变化、找替代写法、修改已有代码，就得花不少工夫。然而交给 AI 之后，整个过程比我想象中顺畅得多。我主要需要做的事情，就是把需求描述清楚，再做一些简单的 Code Review。

原本看着觉得“这得改到什么时候”的老代码，AI 改起来居然没什么压力。这种感觉还是挺奇妙的。

模板引擎直接换了一套

其中让我印象最深的是模板引擎的换血。

Firekylin 原来使用的是 Nunjucks，这次换成了 Eta。换一个依赖只是开始，真正麻烦的是主题里已有的模板也要跟着改。原来取数据、做判断、遍历列表的写法，都得转换成新引擎支持的形式。

结果这种事情刚好是 AI 特别擅长的。把迁移需求说清楚之后，它就能把原来的主题模板翻译成 Eta 的写法，整个过程相当丝滑。

以前碰到这种改造，我可能光想想要改多少文件就已经开始头疼了。现在发现，只要目标明确，这类大量重复、又需要理解上下文的修改，AI 做起来是真的轻松。

参考一个项目，不用先把它研究透

另一个印象比较深的事情，是插件体系。

我希望 Firekylin 能有一套更完整的插件扩展能力，于是让 AI 参考 Typecho 的插件体系，结合 Firekylin 的现状给出改造方案。

有意思的地方在于，我并不需要先把 Typecho 的具体实现研究得非常透彻，再逐项告诉 AI 应该怎么写。把想参考的方向和需要解决的问题说明白，它就能去理解相关实现，给出一套架构比较清晰、又能结合 Firekylin 当前情况的方案。

参考别人的思路，再结合自己项目做取舍，这件事情以前也能做，只是中间需要花很多时间去阅读和理解。现在 AI 能帮忙把这部分工作一起做掉了。

当然，改造一大，代码量也会跟着上来。如果一次给出一个巨大的 PR，Review 起来还是挺费劲的。这时候可以让 AI 把改造分成几个步骤，提交多个 PR，我们再逐个 Review、合并。

需求拆清楚，改造分步走，每次看一块。整个过程就没有一开始想象得那么吓人了。

顺便把 Firekylin 和 Waline 接到了一起

这次还有一件挺开心的事情，就是终于把我自己的两个项目，Firekylin 和 Waline，接到一起了。

Firekylin 之前本身没有评论管理能力，一直用的是第三方评论服务。文章在博客里写，评论则交给另外一套服务处理。这次改造之后，Firekylin 后台也能直接查看、回复和管理评论了。原生评论管理，算是这一轮比较直观的变化。

既然我自己就在维护 Waline，那评论能力当然可以从这里接过来。不过，要做的也不只是给文章页挂一个评论框。我们希望评论的业务能力能复用，数据和管理流程又能融入 Firekylin 本身。

其实 Waline 之前就有用户提出过，希望把评论能力接入自己的系统。所以在能力设计上，我们一直保持着开放，并不是只能按一套固定的部署方式来使用。

为了进一步解耦，这次又把评论的核心业务逻辑抽象成了 @waline/core。第三方系统需要接入时，可以直接复用这部分业务逻辑，再把它需要的依赖接好。

比如数据怎么存、用户身份怎么识别、Markdown 怎么渲染，这些事情由接入方提供对应实现。评论核心不用跟某一个系统绑死，接入方也不用重新写一遍评论业务。放到 Firekylin 里，就是把这些依赖接到它已有的数据模型和服务上。

而这部分工作，正好也是 AI 擅长的事情。两边的职责和接口明确之后，让 AI 帮忙梳理需要哪些依赖，再结合 Firekylin 的现有实现逐项适配，就能把两个项目之间的连接补起来。

这和前面迁移模板有点相似：需要理解两边的上下文，也有不少具体的转换和对接工作。目标说清楚之后，AI 能把这些事情一起推进，不用我自己挨个接口从头写起。

隔离示例站点的实际评论管理界面，图中为演示评论。可以筛选待审核和垃圾评论，也可以直接回复、编辑和删除。

对我来说，这件事情还有点额外的乐趣。两个各自维护了很久的项目，终于通过一层清晰的核心接口连到了一起。Firekylin 获得了原生评论管理，Waline 的核心能力也更方便被其它系统复用了。

我需要做的事情也变了

这次改造让我感受比较明显的是，很多以前要自己逐个文件修改的事情，现在可以交给 AI 去完成了。

比如把 Class Component 改成 Function Component，把老模板转换成 Eta，或者梳理一套现有项目里的扩展接口。这些事情当然各有细节，但只要把目标和需求描述清楚，AI 就能把大量具体工作接过去。

我主要做的事情，变成了说明白想要什么，再看看它改得是不是那么回事。碰到范围比较大的改造，就让它拆开提交，每次 Review 一部分。

这里说的简单 Code Review，也不是完全不看代码了。需求有没有理解偏、方案是不是适合 Firekylin、改完后的行为是不是自己想要的，还是得自己判断。只是不用每一行都亲手写，整个事情就轻松了很多。

以前想给老项目做一次大升级，光是列出待办事项可能就不太想动了。这次真正做下来，发现这些积攒了很久的改造，已经没有想象中那么难推进了。

然后，让博客本身也能用上 AI

用 AI 升级完程序之后，我又把 AI 接进了博客本身。

现在可以在编辑器里生成标题、摘要，逐处审阅修改；也可以在后台直接对话，让 AI 调用工具查文章、整理草稿。再通过 MCP，自己常用的 AI 客户端也能连接博客。

这些功能具体怎么配置、怎么用，我放到了另一篇《Firekylin：一个 AI 友好的博客平台》里，配了实际操作的截图和录屏。Eta 主题市场和基于 Widget 的扩展体系，也一起介绍。

这篇就先记一下这次折腾的感受。对我来说，AI 带来的变化很具体：一个放了很久、知道应该改却迟迟没动的项目，现在终于能继续往前走了。

感兴趣的同学可以看看 Firekylin 的源码，也欢迎一起折腾。