Code X 把我的博客重新装修了一遍，我才发现个人网站还能这样折腾

比如一个几年没认真打理的博客。

它不像一个普通文件夹，删了就删了；它里面有以前写过的文章，有半夜折腾 Hexo 的记录，有当时觉得很酷的主题，也有后来回头看会忍不住笑出来的排版。

这次重新打开博客的时候，我的第一反应不是“我要大改一版”，而是：

算了，能跑起来就不错了。

结果没想到，最后一路从环境配置、依赖升级、文章迁移、UI 调整、图片封面、GitHub Pages 发布，一直折腾成了一次完整的博客翻新。

更有意思的是，这次陪我折腾的不是某个教程，也不是某个群友，而是 Code X。

说实话，一开始我对它的期待很简单：帮我看看项目还能不能跑。

后来我发现，它不只是能看项目，它是真的能动手干活。

01 老项目最怕的，不是旧，而是不敢动

这个博客不是新项目。

它之前是在另一台电脑上开发的，现在换到 Mac 上继续折腾，第一步就是经典灵魂拷问：

这个项目到底需要装什么环境？

Hexo、Node、npm、主题配置、部署脚本、GitHub SSH……每一项看起来都不复杂，但凑在一起就很容易劝退。

以前遇到这种情况，我大概率会先百度十几篇文章，然后在终端里来回试命令。试着试着，项目没跑起来，心态先跑偏了。

这次我直接让 Code X 读项目。

它先看目录结构，再看 package.json、Hexo 配置、主题配置、资源目录、部署方式。不是上来就“建议你重装”，而是先把项目脉络摸清楚。

这点我很喜欢。

很多时候我们问“为什么跑不起来”，背后可能是依赖问题，可能是配置问题，也可能只是命令执行目录不对。

Code X 的优势，是它可以把整个项目放在一起看，而不是只回答你问的那一句。

02 真正麻烦的，是那些藏在细节里的坑

博客能跑起来之后，问题才开始一个个冒出来。

旧依赖要不要动？临时文件能不能删？以前生成的封面还需不需要？文章日期为什么不对？GitHub 为什么又推不上去？

其中最熟悉的一个报错是：

git@github.com: Permission denied (publickey).

看到这行字的时候，我相信很多人血压都上来过。

SSH key、passphrase、GitHub 权限、端口、网络环境，每一个都可能是坑。

这次 Code X 不只是告诉我“去配 SSH key”，而是继续往下排查：确认 key、判断远端、处理 Hexo deploy 失败，再切到 `.deploy_git` 手动推送，最后还验证远端提交是否真的更新。

以前写教程，我经常会写一句“然后推送到 GitHub 即可”。

现在回头看，“即可”两个字，简直太轻飘了。

真正折腾过的人都懂：教程里最简单的一步，往往就是你卡一晚上的地方。

03 文章迁移：比改 UI 更麻烦

博客的壳修好了，内容才是重点。

这次我还把之前公众号里的文章重新放进了博客。

一开始我以为导入文章就是复制粘贴。

结果真做起来才发现，事情没那么简单。

标题要处理，发布时间要处理，封面要匹配，正文里的图片路径要替换，旧内容还要清理。最麻烦的是文章日期。

后来发现，文章文件名里其实包含了原始发布时间。于是 Code X 帮我调整导入逻辑，从文件名识别时间，再写进文章信息里。

这一步看起来小，但对博客很关键。

博客不是单纯展示内容，它更像一个长期记录系统。以前的文章是 2020 年写的，它就应该待在 2020 年，而不是莫名其妙跑到 2026 年首页来装新文章。

时间对了，记录感才回来。

04 UI 改造：从“能看”到“想多看两眼”

老实说，最开始我只是想让博客恢复正常。

但人就是这样，能跑起来之后，就开始嫌它不够好看了。

首页背景、导航栏、文章封面、侧边栏、底部 banner，都有点“不对味”。比如导航栏宽度不对，文章封面重复，页面往下滑后背景太单调。

于是又继续改 UI。

这次没有推翻重来，而是在原来 Butterfly 主题的基础上调整：导航栏拉满，文章列表更柔和，封面换成文章自己的配图，底部 banner 做得更完整一点。

我以前改 UI，很容易陷入一个属性一个属性试的状态。

阴影调大一点，圆角调小一点，透明度改一下，最后页面像是被补丁糊出来的。

Code X 的好处是，它会顺着项目原来的结构改。哪些写在自定义 CSS，哪些用 JS 辅助，哪些地方别碰主题核心文件，它能把边界控制住。这对博客很重要。

因为主题以后可能还会升级。如果把主题源码改得乱七八糟，下一次升级基本等于重新做人。

这也是为什么这次我觉得 Code X 真挺适合维护老项目。

它不会嫌你项目历史包袱多，也不会看到几百篇文章就摆烂。

它会一点点查，一点点改，一点点验证。

这对个人开发者来说，其实很珍贵。

05 Code X 到底帮我做了什么？

如果简单汇总一下，这次 Code X 不是只写了几行代码。

它更像是一个一直在线的项目搭子。

它做了这些事情：

• 读项目结构，判断 Mac 上继续开发需要的环境
• 清理旧文件、旧缓存和无用资源
• 导入公众号文章，匹配封面和配图
• 修正文章发布时间和首页排序问题
• 优化导航、文章列表、背景和底部 banner
• 修复 GitHub Pages 推送问题
• 构建、部署，并验证线上是否真的更新

以前这些事情我当然也能做。

但问题是，我可能要拆成很多天做。

今天弄环境，明天修依赖，后天改 UI，再过几天处理文章，再某个晚上被 GitHub SSH 报错劝退。

而这次的感觉是：我负责判断方向，它负责把路一段段铺出来。

我说“这个导航不对”，它去看 CSS。

我说“文章日期还是有问题”，它去看导入逻辑。

我说“推不上 GitHub”，它去排查 SSH 和部署目录。

这就是 Agent 类工具和普通聊天工具最大的不同。

它不是只给建议，而是可以进入项目、读取文件、修改代码、运行命令、验证结果，最后把东西交付出来。

06 但它不是魔法，人的判断依然重要

当然，这里也不能吹得太过。

Code X 不是魔法。

它也需要你给方向，需要你判断审美，需要你告诉它哪里“不对味”。

比如 UI 这块，我就反复说过：

这个不行。

导航长度不对。

首页图片不要改。

文章封面重复了。

背景太纯色。

这些反馈很重要。

如果没有人的审美和判断，它可能会做出一个“技术上没问题，但你不喜欢”的版本。

所以我现在更愿意把 Code X 理解成：一个执行力很强、耐心很好、能持续读项目上下文的搭子。

你越清楚自己想要什么，它越能帮你把东西做出来。

07 个人博客这件事，仍然值得

折腾完这次博客后，我又想起很早以前写过的一句话：

个人博客不只是一个网站，它更像是你在互联网上给自己留的一块地。

公众号、平台、短视频都很好，但它们更多是流量场。

博客不一样。

它是档案馆，是作品集，也是一个人长期留下来的痕迹。

以前搭博客，门槛不算低。

你要懂域名、GitHub Pages、Hexo、主题、Markdown、图片路径、命令行。

现在有了 Code X 这类工具后，门槛确实被降低了很多。

不是说你完全不用学，而是你不用每一步都独自硬扛。

以前卡住一个报错，可能一晚上过去了。

现在你可以把项目交给它一起看。

这对很多想做个人网站、想整理作品、想把公众号内容沉淀下来的人来说，是个很大的变化。

08 写在最后

这次博客改造最让我开心的，不是页面变好看了，也不是文章重新导入了。

而是我突然意识到：以前很多因为“太麻烦”而搁置的事情，现在真的可以重新捡起来。

个人博客可以重新整理。

旧项目可以重新维护。

公众号文章可以重新归档。

图片、封面、UI、部署这些零碎又烦人的活，也不一定非得一个人闷头搞。

Code X 这种工具的意义，不是让人变懒。

恰恰相反，它让很多原本因为麻烦而不想开始的事情，重新有了开始的可能。

如果你也有一个荒废很久的博客，或者一个放在硬盘深处吃灰的项目，真的可以找个时间翻出来看看。

也许它并没有过时。

它只是等一个人，和一个足够能干的搭子，把它重新点亮。

如果这篇文章对你有点启发，欢迎点个“在看”。

也欢迎你留言说说：你有没有一个一直想重启，但还没开始的项目？

说不定下一次，它就真的重新跑起来了。

最终Blog网址：https://dpw09.cn/