一个人怎么养四端博客：节奏、取舍与不做什么

随笔 · 全栈复盘
系统地图请读自文档《导读：这个系统是什么》；请求链路见《多端架构》——本文只谈一个人怎么撑住、哪些坑故意不踩。

写在前面

仓库里常年躺着四端（有时五端）：

外加 RPG、支付、RAG、自文档连载、若干外发专栏。一个人维护时，真正决定生死的不是「会不会写 Clean Architecture」，而是节奏与取舍。

时间线（压缩版）

不必精确到周，阶段感就够：

1. 能发文、能管文 — Nest CRUD + Admin + 简单前台
2. 能读得舒服 — Nuxt SSR、主题、评论通知
3. 能运维 — SQL patch、部署脚本、RBAC、限流
4. 差异化 — RPG（签到/任务/抽奖）、实时 /realtime
5. 移动对齐 — uni-app TabBar「冒险」；Go 对等 API 练手
6. 变现与智能 — 支付宝充值/赞赏、RAG FAB、工具箱 AI
7. 吃自己的狗粮 — 自文档 00–18 + 手册截图；外发深挖专栏（RPG/RAG/Stream…）

每一阶段都留下「可演示的垂直切片」，而不是先画完大图再开工。

决策一：双后端，不是炫技

Nest 已经能跑通生产，为什么还养 Go？

代价：修 bug 有时要改两处。规矩是——生产主路径认准一端（Web/Admin→Nest）；Go 以对等与联调为主，不强迫一天内 100% 功能镜像。

决策二：RPG / RAG 都是「可关掉的垂直模块」

registry.ts 里 Pay、Rpg、Rag 与 Features 并列。一个人养站时：

• 玩法爆了 → 值得继续加表、加 WS
• 某季度没空 → 模块还在，但不抢 Features 发文带宽
• 拆服务时 → 已有 blog:events 双消费者组（rpg-handlers / rag-indexer），过渡成本可控

反例是把经验计算写进 CommentService：评论域永远被 RPG 拖死。异步事件 + 窄 exports，是一个人项目的生存技能，不是架构师表演。

决策三：文档是第二产品

自文档系列、Admin/Home 手册、外发专栏（docs/columns/*）共用一套：

Markdown SSOT → 生成 SQL → 导入 MySQL → 无需 redeploy

好处：

• 写功能时顺手沉淀，减少「半年后自己也不懂」
• SEO / 留存有内容可发，不必另起博客主题
• SQL 导入不发 Stream——RPG 经验与 RAG 索引要另触发，这是已知取舍（S1 写过）

一个人最贵的是上下文切换；文档管道把「写代码」和「写文章」焊在同一工作流里。

刻意不做什么

独立开发者的护城河是可持续，不是架构完整性打分。

工具链（极简）

• 本地：MySQL 3306 + Redis 6379 常驻；各端端口见 01 文
• 发布：环境变量对齐部署目录（改生产 env 勿忘 deploy/pm2 等）
• AI：Cursor 写专栏 md → build SQL → import；站内 RAG/工具 AI 是产品，不是主写作台
• 验证：关键路径手测 + 子项目既有脚本；Agent 起的 dev 服务用完关掉，免端口占用

若只给后来者三句话

1. 先垂直切片，再铺模块图。
2. 横切用 Redis（缓存 / Stream / WS Adapter），业务用窄边界。
3. 文档管道化，否则一个人必忘。

更细的地图：自文档 00 + 01；数值与 AI 见 RPG/RAG 专栏；模块与事件见 Nest 基础设施专栏。

相关路径

• blog-server/src/modules/registry.ts
• blog-server/docs/self-doc/
• blog-server/docs/columns/
• 本轮外发：rpg-design / rag-ai / nestjs-infra / toolbox