vibecoding IMiss_Blog个人博客

项目简介#

这就是你正在看的这个站本身：IMiss Blog，用 Astro 做静态生成、Svelte 做交互部件的个人技术博客。文章、学习路线、相册、书签导航、桌宠都放在同一个仓库里，和源码一起。

整个站是用 vibecoding 的方式做出来的：我提需求和验收标准，AI 写代码，我判断改得对不对。每一条改动背后都有一条实际跑过的命令和一份输出。

它是怎么做出来的#

起点是一个基于 Astro 的博客主题，它已经把文章渲染、代码块高亮、站内搜索这几块打磨好了，这些保留；站点自己的身份和内容按想法重做：配色换成《鸣潮》爱弥斯的色调，导航重新排，横幅、侧栏、页脚逐块调整。项目、相册、书签导航、学习路线这几块主题里没有，从页面到数据一步步加上去。

vibecoding 的做法很朴素：先把要改什么、改完怎么算对说清楚，再让 AI 动手。常遇到的情况是代码跑得起来但不是要的效果，这时不靠文字描述，而是自己跑一遍，把真实的报错或渲染结果贴回去，等它改完再验一次。

验收脚本分几层#

每改一次都跑这几条命令，各有各的管区：

pnpm check —— 看类型和模板；
pnpm verify:posts —— 逐篇检查文章的前置数据、slug 与正文里的图片引用；
pnpm verify:docs —— 核对文档里的数字与仓库实际情况是否一致（版本号、断言条数、截图张数、需求编号有没有闭环、文件有没有混进 BOM）；
pnpm build —— 完整构建，页数与学习路线的停靠点数都是构建期从文章实算的；
界面层还有一套在真实浏览器里跑的断言脚本，覆盖布局、桌宠、导航，以及产物里不许出现的字符串。

这几层里最容易出问题的是文档：代码改了、文档还在说旧数字，这种漂移肉眼很难发现，所以让它机械可比对 —— 文档里的每个数字都能对应到一条命令或一个文件。

站里现在有什么#

文章 —— 138 篇，分 12 个分类、42 个标签；
学习路线 —— 全站文章排成 8 条主线、141 个停靠点，标了难度和大概耗时，合计约 70 小时；
相册 —— 一个相册，9 张原图；
书签导航 —— 6 组共 39 个平时会用的站点；
动态与音乐 —— 1 条短动态；歌单是本地文件，侧栏和导航上各有一个入口；
爱弥斯桌宠 —— 右下角那只。她接了大模型，可以让她推荐几篇文章或介绍某一篇，答案只来自站内内容；后端连不上时走本地台词，页面不会因此报错；
站内搜索 —— 用 Pagefind，本地开发和生产用的是同一份索引；
壁纸 —— 6 支动态视频，横幅 / 全屏 / 透明覆盖三种模式，进站按北京时间选当下该看的那一支。

构建产物是 175 页静态页面，流程里排在前面的是生成占位图、生成搜索索引和字体子集化这些步骤，全部在本地跑完，不依赖任何运行时服务。

代码放在哪#

源码在 Gitee：https://gitee.com/a2186988646/imiss_-blog，站点源码、上面那些校验脚本和文档都在同一个仓库里。

文章放在 src/content/posts/<分类目录>/ 下，一个 Markdown 文件就是一篇；学习路线的数据收在 src/config/roadmapConfig.ts 一个文件里，按 category + slug 成对登记，构建时逐条解析，解析不到就直接失败 —— 所以「站内每一篇都能在路线页上找到」是构建期保证的。想了解这个站怎么用、怎么维护，站内有《本站使用与维护手册》。

音乐