AI编程实践：个人博客升级

摘要

鉴于以下几点原因：

1. 上篇博客说了我要升级博客
2. 我的博客没用Vercel托管而是部署在自己服务器上导致Hugo这种静态框架失去优势
3. 我想要更多的可自定义的需要结合后端的功能（记录博客浏览数，AI审核评论区）
   我借助Zed加gpt-5.3-codex medium使用Nuxt前端、FastApi后端的技术栈完成了你们目前看到的这个全新的博客网站。

本文主要内容是对构建过程的简单记录和一些感受。

构建过程

需求分析和设计阶段（半天）

需求分析

1. 在飞书上告诉OpenClaw，我想要做一个博客网站，让他建一个仓库，同时建一个我指定名字的在我服务器上的git远程仓库。首先在仓库中建好docs文件夹。
2. 告诉OpenClaw，我想要的核心功能就兼容Hugo文章元信息和提供和之前类似的博客阅读体验。让他据此写一份仅包含基本功能点列表和用户场景的需求文档。
3. 查看OpenClaw的需求文档，发现不符合自己想像的功能和情景指出来，并且描述自己这一方面理想中的场景。
4. 直到得到一份满意的需求文档。

架构设计

博客这种项目架构比较固定，我直接定好总的架构就是前后端+数据库的架构。

然后前端我只略懂一些，架构全权交给AI设计，我主要提出了关于后端架构的约束（要有哪几个功能模块，分别都是做什么的，各个模块之间如何交互以满足需求）。

然后同样的，通过文档来回交流几次，直到在架构文档上达成共识。

详细设计

先定好我熟悉一点的技术栈，前端我说用Vue，AI问我要不要用Nuxt，挺它说感觉像Vue的升级版，反正我不管前端代码，就用它说的。后端我直接指定FastAPI。数据库用SQLite。

还是一样的思路，我把我能立即想到的设计，比如数据表应该要有什么表，各个表有什么字段，各个表之间是什么关系告诉AI。然后其他的详细设计，比如后端的接口设计，关键业务逻辑流程，我让它根据需求和架构文档给出一版文档。前端直接让他自由发挥。

同样的，阅读它给的设计和建议，给出我的建议（比如去掉某些无用的表和字段，某些接口应当有统一的前缀表示这是同一个模块，某些接口应该使用路径参数而不是请求体参数等等）和采纳它给出的建议（博客文章和博客标签是多对多关系，应当单独设置一个文章和标签之间的关系表。博客分类同理）。

直到达成共识。

Demo 实现阶段（半天）

这部分就更简单了，我直接开新会话。让他根据之前的文档实现基础的功能，然后简易部署在我的服务器上，我直接手动测试使用，每次都提出几条优化意见和Bug修复。

直到得到一个核心功能都工作正常的版本。

到目前为止，我都没有使用过电脑，全程都是在飞书上和OpenClaw聊天，然后通过我的虚拟内网和Nas服务查看它给出的文档和访问它部署的网站。正好这几天过年，我在旅游路上做这个事情，非常合适和惬意，打字我都懒得打，直接语音转文字，想到什么说什么（后面整一个识别飞书语音消息的Skill，甚至不用转文字了，直接发语音使唤AI）。

目前的Agent工作表现令人满意，到目前为止的阶段都非常顺利。

不过，到开始添加之前没有考虑和设计的额外功能和进行更加细致的优化（界面排版和美化，数据库、本地文件同步逻辑、系统的性能、模块之间的解耦、和代码的简洁性），单纯的聊天已经不能给我足够的控制力了。

细致功能的添加和系统代码优化阶段（三天）

这三天我主要都是旅行结束后回来在电脑前把代码从远程仓库上clone下来使用本地IDE和Agent做的。

具体过程就略讲了：

代码阅读

对于我在意的后端代码我先从程序入口开始，深度优先读了一遍（现在我发现根本不用明白每个函数具体都是怎么实现怎么用的，对于不清楚的用法，直接根据名字揣测其意思，不懂的直接问AI。就像读文章一样，遇到不懂的词先根据上下文猜，不懂的查词典，把握全局意思即可。我就说程序员也是一种文字类工作吧）。

这种方式看代码就很快，很快就把后端理解地差不多了（具体接口怎么实现的我一行都没看，直接用FastAPI自带的SwaggerUI接口文档把所有接口都试一遍再看一遍定义了哪些数据模型就都明白了）。

重构优化

这个过程也没什么特别的，就把自己决定有问题（性能低下，冗余设计）的地方以及自己决定应该怎么做告诉AI，让他改到我满意为止，就Commit一次。

直到感觉对于当前的功能，目前的设计和优化已经足够了，就开始加新功能。

功能添加

这个时候就不用写文档，我一次只加一个基于当前系统不难实现的小功能，直接告诉AI我想要什么功能，用户场景是什么，以及简单的设计。当AI给出出版后进行测试，返回需要优化的问题和需要修复的Bug，不断重复过程直到觉得可以Commit即可。

当添加的功能给系统增加的复杂性使代码让人不可忍受，此时就又进行重构优化的过程。

小结

试一下新加的mermaid渲染功能

再附带一张commit记录

相较于之前的特色功能

浏览量统计

略

AI审核的评论区

这个有点意思，现在我可以完全自定评论的流动之后，在后端收到评论入库之前加一道基于带提示词的LLM审核处理就实现了这个功能。不得不说，AI做这个也挺合适的，我一个人也能实现轻松简单的评论管理了。

书架

增加了后端对如下文件夹目录的识别，践行我对文件系统即数据源的原则。

plaintext复制
books
├── 富爸爸，穷爸爸
│   └── meta.json
├── 深度工作
│   └── meta.json
└── 只是为了好玩
    └── meta.json

每个json里面填的是如下的内容：

json复制
{
  "url": "https://book.douban.com/subject/36303640/",
  "categories": ["人物传记", "计算机"],
  "status": "reading",
  "review_post_path": "" // 本人书评博客地址
}

基于第三网网站的信息加上我自己个人对这本书的记录信息完成对一本书的描述。
这个地方我对url做了抽象，进来的url会通过一个抽象的书籍信息链接处理接口提取出一本书的书名、作者出版社等信息，目前我只实现了豆瓣读书网的解析接口。

目前书架就长这个样子：

还没放几本书，后面觉得值得推荐或者个人比较认可的书都放上了。希望这个行为能让我看多点书。

本来是想提供电子书的下载的，不过怕侵权还有刷流量的，还是算了。

总结

主要有以下几点感受

1. 现在Vibe Coding真的很容易了，尤其是有了接入社交软件的OpenClaw这种Agent，用来做自己想做的项目简直就是一种顶级享受，走在路上，时不时拿出手机说几句话，审查结果，项目就不断按照自己的想法推进。这种不受地点时间限制的工作方式极大降低了我开启一个项目的成本。
2. Vibe Coding很强，不过要做真正能用的，自己愿意用的项目还是需要一些软件工程的知识和思维才能更加游刃有余一些。不过传统的观念也确实需要做出改变了，之前我特别不能接受使用我不了解具体实现方式的代码，导致和AI的协作仅限于让它把一整个模块做了我一点不看或者是我自己做不让AI做一点。不过现在我认为确实没必要完全掌控代码的实现逻辑了，靠文档和测试约束AI的实现，然后了解AI实现的大致逻辑和框架再和它交流反馈就能做到高效的协作了，在保持一定代码质量的同时不断推进项目按照自己的预期前进。
3. 经过这一次实践，我对事先设计和事后重构的时机更有把握了一些，没出现之前的举棋不定导致项目搁置以及史山堆积导致项目无法推进的情况了。只能说适时重构、动态调整才是最佳实践，永远不要过度设计和毫不设计。

最后关于上篇博客说的朋友圈功能，不打算做了，因为感觉不方便更新。这种性质的东西我设想的用户场景是我突然有感而发想针对某些事件说两句或者谈谈自己最新领悟到的道理。这些情况天然和需要坐下来整理思路的长篇博客是矛盾的。所以就不打算加入到这个博客形式的项目了，转而准备给OpenClaw加一个相关的Skill，让他直接把我临时想说的记录整理下来即可。