1. 为什么我选择 WorkBuddy + Flask + SQLite 这套组合
先说结论：这套组合不是拍脑袋选的，是我在试过 WordPress、Shopify 和纯静态源码建站之后，针对"个人内容站 + 日更 + 数据自己攥在手里"这个具体需求，反复权衡后定下来的方案。WorkBuddy 负责把建站和日常运维的重复劳动吃掉，Flask 负责把业务逻辑写清楚，SQLite 负责把数据存明白。三者各司其职，没有一个是多余的。
很多人一提到建站，第一反应是 WordPress。WordPress 确实成熟，插件生态庞大，但它的问题也很明显：主题和插件一多，性能就开始往下掉，安全补丁要跟着官方节奏走，数据库是 MySQL，你得单独维护一个服务。Shopify 更省心，但它是托管电商，你付的是月租，数据在别人服务器上，想做个自定义的数据分析或者导出原始表结构，处处受限。自建站的核心价值就在于"可控"——代码可控、数据可控、成本可控。而 Flask + SQLite 这套轻量组合，恰好把"可控"这两个字落到了实处。
WorkBuddy 在这套组合里扮演的角色，是"建站加速器"和"日常运维助手"。它不是一个替代 Flask 的框架，而是帮你把建站过程中那些琐碎但必要的环节——比如项目脚手架生成、依赖管理、部署脚本、定时任务配置——用更少的命令和更清晰的流程串起来。我实测下来，从零到跑通一个能日更的站点，用 WorkBuddy 辅助比纯手工搭环境至少省掉一半的折腾时间。
提示：WorkBuddy 有国际版和国内版之分，功能上大同小异，安装方式略有差异。本文的操作以通用流程为主，具体安装命令请以你所用版本的官方说明为准。
这套方案适合谁？如果你满足下面任意一条，那这篇记录对你就直接有用：
- 想做一个自己的内容站，但不想被 CMS 的插件和主题绑架；
- 会一点 Python，想用 Flask 练手但不知道从哪开始；
- 已经在用 Flask，但日更流程太手工，想自动化；
- 对 SQLite 有兴趣，想知道它到底能不能撑住一个日更站点的数据量。
不适合谁？如果你要做的是高并发电商、多用户实时协作平台，那 SQLite 和这套轻量方案不是最优解，该上 PostgreSQL 和成熟框架就上，别硬扛。
2. 建站前的整体设计与技术选型拆解
2.1 三层结构：展示层、逻辑层、数据层怎么分
我把整个站点拆成三层，这个分法不新鲜，但每一层用什么、为什么这么用，值得说清楚。
展示层用 Flask 的 Jinja2 模板引擎。为什么不用前后端分离？因为日更内容站的核心是"内容快速上线"，前后端分离会引入额外的构建步骤和接口联调成本。Jinja2 直接服务端渲染，改一个模板文件刷新就能看到效果，对个人站点来说效率最高。如果你后期确实需要前端交互，再局部引入 JavaScript 或者换成 API 模式也不迟，不用一开始就上重装备。
逻辑层就是 Flask 的路由和视图函数。这里的关键设计是：把"内容管理"和"内容展示"分开。展示路由（比如首页、文章详情页）只读数据库，管理路由（比如发布、编辑、删除）才写数据库。这样即使管理端出问题，展示端也不受影响。
数据层用 SQLite。为什么不用 MySQL？因为日更站点的写入频率极低——一天几条到几十条，SQLite 的写入性能完全够用，而且它是单文件数据库，备份就是复制一个文件，迁移就是拷走一个文件。MySQL 你要装服务、配用户、管权限，对个人站点来说是过度工程。SQLite 的并发读性能其实很好，多个读者同时访问首页完全没问题，瓶颈只在写入，而日更场景下写入根本不是瓶颈。
2.2 为什么用 WorkBuddy 而不是纯手工搭
纯手工搭 Flask 项目不是不行，但有几个痛点：
第一，环境配置容易出错。Python 版本、虚拟环境、依赖包版本，任何一个环节对不上，报错信息能让你查半天。WorkBuddy 把这部分流程标准化了，减少了"环境问题"这类无效折腾。
第二，日常运维重复劳动多。日更意味着每天都要做类似的操作：写内容、入库、检查站点状态。这些操作如果全靠手工，时间长了必然出错或者偷懒。WorkBuddy 的自定义指令和 skill 机制，可以把这些重复操作固化下来，一键执行。
第三，部署环节容易踩坑。Flask 开发服务器不能用于生产，要用 WSGI 服务器加反向代理。这套配置对新手来说门槛不低，WorkBuddy 提供的部署辅助能把这个过程简化。
注意：WorkBuddy 是辅助工具，不是黑盒。我建议你在用它的同时，至少把 Flask 的基本路由、SQLite 的基本 SQL 语句搞明白。工具能帮你省时间，但出了问题最终还是要靠基础知识来排查。
2.3 数据库表结构设计思路
日更内容站的核心表其实就几张。我用的是下面这个最小可用结构：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| articles | 存文章主体 | id, title, slug, content, created_at, updated_at, status |
| categories | 存分类 | id, name, slug |
| tags | 存标签 | id, name, slug |
| article_tags | 文章与标签的关联 | article_id, tag_id |
为什么用 slug 而不是直接用 id 做 URL？因为 slug 对搜索引擎和用户都更友好，/article/flask-sqlite-guide比/article/123可读性强得多。slug 的生成规则我放在逻辑层做：取标题的拼音或者英文，去掉特殊字符，重复时加数字后缀。
status 字段用来控制文章状态，我定义了三个值：draft（草稿）、published（已发布）、archived（归档）。这样写内容的时候可以先存草稿，确认没问题再改成已发布，避免半成品被读者看到。
3. 从零搭建：环境准备与项目初始化实操
3.1 Python 环境与 WorkBuddy 安装
第一步是把 Python 装好。我建议用 3.10 或以上版本，因为 Flask 新版本对 Python 版本有要求。Windows 用户去官网下载安装包，安装时务必勾选"Add Python to PATH"，这一步漏了后面命令行找不到 python 命令，能让你怀疑人生。macOS 用户可以用 Homebrew 装，Linux 用户用系统包管理器或者 pyenv 都行。
装完验证一下：
python --version pip --version两个命令都能正常输出版本号，说明基础环境没问题。
接下来装 WorkBuddy。安装方式根据你用的版本不同会有差异，通用思路是：先确认你的系统架构（Windows/macOS/Linux），然后按官方文档给的命令执行。Linux 和 Ubuntu 用户注意，有些依赖需要提前装好，比如 build-essential 和 python3-dev，否则安装过程中编译环节会报错。
装完之后，我习惯先跑一个初始化命令，确认 WorkBuddy 能正常工作，再开始建项目。这一步别省，很多问题在初始化阶段暴露比在项目中途暴露好排查得多。
3.2 用 WorkBuddy 生成项目骨架
项目骨架我让 WorkBuddy 生成，但生成之后我会逐个文件看一遍，搞清楚每个文件的作用。这一步很重要，不能生成完就直接用，否则出了问题你连从哪查都不知道。
一个典型的 Flask 项目骨架长这样：
myblog/ ├── app/ │ ├── __init__.py │ ├── models.py │ ├── routes.py │ ├── templates/ │ └── static/ ├── instance/ │ └── blog.db ├── config.py ├── requirements.txt └── run.pyapp/__init__.py里做应用工厂（application factory），这是 Flask 推荐的组织方式。为什么用工厂函数而不是全局 app 对象？因为工厂模式让测试和配置切换更方便，你可以在测试时传入不同的配置，而不用改全局变量。
models.py里定义数据库模型。我不用 ORM 的重型方案，直接用 Flask 自带的 sqlite3 接口加手写 SQL，原因是：SQLite 的 SQL 语法简单，手写 SQL 可控性更强，而且能避免 ORM 带来的额外抽象层。如果你习惯用 SQLAlchemy，也完全可以，只是我个人偏好轻量。
instance/blog.db是数据库文件存放位置。Flask 约定 instance 文件夹存放不应该进版本控制的实例数据，数据库文件放这里正合适。
3.3 数据库初始化与 DB Browser 可视化
数据库初始化我用一个独立的脚本做，不放在应用启动流程里。原因是：初始化只需要做一次，放在启动流程里每次启动都检查一遍是浪费。
import sqlite3 def init_db(db_path): conn = sqlite3.connect(db_path) cursor = conn.cursor() cursor.execute(''' CREATE TABLE IF NOT EXISTS articles ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, slug TEXT UNIQUE NOT NULL, content TEXT NOT NULL, status TEXT DEFAULT 'draft', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ''') conn.commit() conn.close()写完建表语句，我强烈建议装一个 DB Browser for SQLite。这是一个免费的可视化工具，能直接打开 .db 文件，看表结构、看数据、手动执行 SQL。为什么需要它？因为命令行里查数据效率太低，尤其是调试阶段，你想确认一条记录到底写进去没有，用可视化工具点两下就看到了。Android Studio 里也有 SQLite 的可视化工具，但那是给移动开发用的，做 Web 站还是 DB Browser 更顺手。
实操心得：DB Browser 里改完数据记得点"Write Changes"提交，否则改动只在内存里，关掉就没了。这个坑我踩过不止一次。
4. 核心功能实现：内容管理与日更流程
4.1 文章发布与 slug 生成逻辑
文章发布的核心是把表单数据写进数据库。这里有个细节：slug 的生成要处理重复。我的做法是先按标题生成基础 slug，然后查数据库看有没有重复，有的话加数字后缀。
import re def generate_slug(title, cursor): base = re.sub(r'[^\w]+', '-', title.lower()).strip('-') slug = base counter = 1 while True: cursor.execute('SELECT id FROM articles WHERE slug = ?', (slug,)) if cursor.fetchone() is None: return slug slug = f"{base}-{counter}" counter += 1这段逻辑看着简单，但有个坑：如果标题全是中文，re.sub处理完可能得到空字符串。所以我在实际项目里加了一层判断，slug 为空时用时间戳兜底。中文标题的 slug 处理，要么用拼音库转拼音，要么直接用文章 id 加时间戳，我选后者，简单可靠。
4.2 日更流程的自动化设计
日更最怕的是"今天太忙，忘了发"。我的解决方案是把日更流程拆成"写"和"发"两步，写可以随时写，发用定时任务自动执行。
具体做法：文章先以 draft 状态入库，然后设置一个定时任务，每天固定时间检查有没有当天写的 draft 文章，有的话自动改成 published。这样即使我白天没空点发布，晚上站点也会自动更新。
WorkBuddy 的 skill 和自定义指令在这里派上用场。我把"检查并发布今日草稿"这个操作固化成一个指令，定时触发。指令的核心逻辑就是一条 SQL：
UPDATE articles SET status = 'published', updated_at = CURRENT_TIMESTAMP WHERE status = 'draft' AND DATE(created_at) = DATE('now', 'localtime');SQLite 的 update 语句这里要注意localtime，因为 SQLite 默认用 UTC 时间，不加这个修饰符，你晚上写的文章可能被算到第二天去。
4.3 模板渲染与页面结构
模板部分我用 Jinja2 的模板继承。基础模板base.html定义头部、导航、页脚，子模板只填内容块。这样做的好处是改一次导航，全站生效。
首页展示文章列表，按 created_at 倒序，分页显示。分页用 SQLite 的 LIMIT 和 OFFSET：
SELECT id, title, slug, created_at FROM articles WHERE status = 'published' ORDER BY created_at DESC LIMIT ? OFFSET ?;文章详情页按 slug 查询，查不到返回 404。这里有个安全细节：所有从 URL 或表单来的参数，一律用参数化查询，不要用字符串拼接。SQLite 的参数化查询用?占位符，这是防注入的基本功，别偷懒。
5. 部署上线与日常运维要点
5.1 从开发服务器到生产部署
Flask 自带的开发服务器只能本地用，不能直接暴露到公网。生产部署的标准做法是 WSGI 服务器加反向代理。WSGI 服务器我推荐 Waitress（Windows 友好）或者 Gunicorn（Linux 友好），反向代理用 Nginx。
部署流程大致是：先把代码传到服务器，装好依赖，然后用 WSGI 服务器启动应用，最后配 Nginx 把请求转发过去。WorkBuddy 在部署环节能帮你生成启动脚本和配置模板，但服务器本身的配置还是要你自己确认。
注意：部署前一定要把
debug模式关掉。开发模式下暴露的错误页面会泄露代码路径和配置信息，这是个常见的安全疏忽。
5.2 数据库备份与迁移
SQLite 的备份简单到令人感动：直接复制 .db 文件就是完整备份。但要注意，复制的时候如果有写入操作正在进行，可能拿到不一致的快照。稳妥的做法是用 SQLite 自带的备份命令：
sqlite3 blog.db ".backup backup.db"迁移更简单，把 .db 文件拷到新环境，改一下配置里的路径就行。这也是我选 SQLite 的重要原因之一——数据迁移零成本。
5.3 日更站点的性能观察
日更站点上线后，我观察了几个指标：首页加载时间、数据库文件大小、并发访问表现。实测下来，几千篇文章的 SQLite 数据库文件也就几十 MB，首页查询加渲染在普通服务器上响应时间在几十毫秒级别。真正影响体验的往往不是数据库，而是图片等静态资源，所以静态文件我建议单独放对象存储或者用 Nginx 直接服务，不要走 Flask。
6. 常见问题与排查技巧实录
6.1 高频问题速查表
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| 启动报 ModuleNotFoundError | 依赖没装或虚拟环境没激活 | 检查 pip list，确认虚拟环境 |
| 数据库写入后查不到 | 没 commit | 检查是否调用了 conn.commit() |
| 中文乱码 | 编码不一致 | 确认数据库和连接都用 UTF-8 |
| 页面 404 | 路由或 slug 不匹配 | 打印实际请求路径和数据库里的 slug |
| 定时任务没执行 | 时区或触发条件不对 | 检查系统时间和 SQL 里的时间条件 |
6.2 几个我踩过的坑
第一个坑：虚拟环境没激活就装依赖，结果装到了全局环境，项目里反而找不到。后来我养成了习惯，每次开终端先确认虚拟环境激活了没有。
第二个坑：SQLite 的CURRENT_TIMESTAMP是 UTC，我一开始没注意，导致文章时间显示比实际早八小时。解决办法是在查询时用datetime(created_at, 'localtime')转换，或者写入时就存本地时间。
第三个坑：slug 重复导致插入失败。因为 slug 字段加了 UNIQUE 约束，重复插入会直接报错。后来我在插入前先做重复检查，生成唯一 slug 再插入。
6.3 关于 WorkBuddy 和 CodeBuddy 的配合
WorkBuddy 偏建站和运维流程，CodeBuddy 偏代码编写辅助。我在实际使用中，建站阶段用 WorkBuddy 生成骨架和部署脚本，写业务逻辑的时候用 CodeBuddy 辅助写 Flask 路由和 SQL。两者不冲突，配合起来效率更高。但记住，工具给的代码一定要自己看懂再上线，尤其是涉及数据库操作的部分。
7. 我对这套方案的真实体会
这套 WorkBuddy + Flask + SQLite 的组合，我用了几个月，日更也坚持下来了。最大的感受是：轻量方案的上限比很多人想象的高。SQLite 不是"玩具数据库"，它在读多写少的场景下表现相当稳。Flask 也不是"只能做小项目"，它的扩展性足够你从个人站点长成一个中等规模的平台。
真正决定站点能不能长期跑下去的，不是技术选型有多先进，而是日更流程有没有被自动化、数据有没有被妥善备份、出问题的时候你能不能快速定位。这三点，这套方案都给了我满意的答案。
如果你也想从零建一个自己的站点，我的建议是：先用最小可用方案跑起来，别一上来就追求完美架构。跑起来之后，你会更清楚自己真正需要什么。
