这个博客是怎么搭起来的：一次与 AI 协作的实录

这个博客从构思想法到上线，用了一天。

起点

起因是想尝尝最新上线的Kimi-K3模型，看看它的前端能力怎么样。

一开始只是和它说搭一个博客，顺利搭建后发现只是去拉了一个模板，审美风格我并不满意，于是后面我又尝试重构了。

设计稿与审美风格

我比较青睐Anthropic式的审美风格，于是先和模型对话、让它尝试解析风格，并做出了一个网页给我呈现。通过网页呈现和细化描述，我和模型最终敲定了一个设计稿。

设计稿定了几条原则：纸面质感、发丝线、衬线、克制。技术栈是 Astro + 一套主题骨架，部署到 GitHub Pages，另备一个 Docker 镜像以后上服务器。

第一天晚上线了基础站点和第一批功能：文章导航、相关文章、友链页、页脚的朱砂印章和「已书写 N 字」统计、Konami 码解锁的隐藏主题。第二天上了清单一到三档的剩余功能：阅读进度条、项目页 GitHub 同步、系列文章、此刻流、相册、生长状态、修订次数、节气日期、暗色问候、随便看看，外加 Giscus 评论和 Umami 统计。

并行智能体：快，但要看住

为了速度，功能被拆成互不重叠的文件块，派给多个子代理并行实现。两轮下来，教训比代码多。

代理会跑题，而且理直气壮。 让它做「GitHub 仓库同步」，它交回来一个没人要求的统计页，还顺手改了导航；让它做「印章与统计」，它去改了别人的文章页。两个跑题的代理，失败模式一模一样：不做被指派的，做自己想到的。对策只有一个——文件所有权写死在任务书里，完工后用 git status 对账，越界一律回退。

代理的报告不可全信。 有代理弄坏了页面模板（两个 div 没闭合），报告里写「构建通过」；有代理把真实的编译错误称为「历史遗留问题」。所以每一条代理汇报都要对着磁盘验证：diff、构建、浏览器实测，一个不能少。

验证要针对功能，不只是构建。 「随便看看」按钮在代理环境里一直静默降级到归档页——因为它拿生产域名的 atom.xml 和本地预览比同源，全部丢弃。构建是绿的，功能是坏的。这类 bug 只有真的点一次才能发现。

数据诚实

书单、相册、装备这些页，上线时都是空态——「清单整理中，照片还在冲洗」。这是故意的。代理曾经「贴心」地在装备页写了我没说过的东西（KDE Plasma 桌面），被发现后删掉了。个人站点的每一行个人事实都必须是真的，空着比编的好。

人也干了活

不是一切都交给 AI。身份改名、印章字样是自己在间隙里改完直接提交的；使用说明书也是自己先写了一版——AI 不知情，又写了一份覆盖上去，发现后恢复了人的版本，只把新信息补进去。网络抖动时推送也是手动完成的。

协作里最舒服的分工大概是：人负责审美判断、事实和最终拍板，AI 负责体力活和全量验证。

现在的样子

打开首页能看到纸面和印章；文章页顶部有进度发丝线，日期旁有节气或 🌱；底部有上一篇下一篇、相关文章和评论区；页脚能「随便看看」，暗色模式下多一句问候。输任意页面上 ↑↑↓↓←→←→BA，会解锁第四套配色。

剩下的没做完：Newsletter 需要外部账号，书单和相册等我慢慢填。清单在仓库里，做完一项勾一项。

方法论小结

• 拆任务按文件所有权拆，不按「聪明程度」拆
• 代理汇报一律对账磁盘，构建绿不等于功能对
• 空态优于编造，回退优于报错
• 人保留审美和事实的最终决定权