1. 为什么我选择 WorkBuddy Flask SQLite 这套组合先说结论这套组合不是拍脑袋选的是我在试过 WordPress、Shopify 和纯静态生成器之后根据自己的实际需求筛出来的。我的需求很明确——要有一个自己能完全掌控的站点能日更内容数据存在本地不依赖任何外部平台的审核和规则变动同时开发成本要低到一个人就能维护。WorkBuddy 在这个链路里扮演的角色是AI 辅助开发的工作台。你可以把它理解成一个懂代码的搭档你告诉它要做什么它帮你生成 Flask 路由、SQLite 建表语句、前端模板甚至帮你排查报错。它不是建站工具本身而是加速建站过程的工具。这一点很多人一开始会搞混以为 WorkBuddy 是类似 WordPress 那种开箱即用的 CMS其实不是。它更像是一个能理解你意图、帮你写代码、帮你改代码的协作环境。Flask 是我选的后端框架。为什么不用 Django因为我的站点功能不复杂就是内容展示、分类、搜索这几块Django 的 ORM、Admin、中间件这套东西对我来说太重了。Flask 的微内核设计让我可以按需加扩展路由写起来直观模板用 Jinja2学习曲线平缓。而且 Flask 的社区资源极其丰富遇到问题基本都能搜到答案。SQLite 是数据库选择。有人会问日更站点用 SQLite 扛得住吗实测下来只要不是高并发写入场景SQLite 完全够用。它零配置、单文件、备份就是复制一个文件对于个人站点来说运维成本几乎为零。我目前的站点日均 PV 在几百到一千左右SQLite 的读性能毫无压力。写入方面日更意味着一天也就几次写操作SQLite 的写锁机制完全能应付。注意SQLite 适合读多写少的场景。如果你的站点有大量用户同时提交内容比如评论区高频写入那就要考虑 PostgreSQL 或 MySQL 了。但个人日更站点SQLite 是性价比最高的选择。这套组合的整体思路是WorkBuddy 负责加速开发Flask 负责业务逻辑SQLite 负责数据存储。三者各司其职没有过度设计也没有短板。2. 环境搭建从零到能跑起来2.1 Python 环境与依赖安装第一步是 Python 环境。我推荐用 Python 3.10 或以上版本因为 Flask 3.x 对 Python 版本有要求。安装 Python 本身没什么好说的官网下载安装包勾选Add to PATH一路下一步就行。但这里有个坑Windows 上如果之前装过多个 Python 版本PATH 里可能会有多个 python.exe导致 pip 装包装到了错误的版本里。我的做法是装完之后立刻在终端里执行python --version pip --version确认版本号一致并且 pip 对应的路径和 python 在同一个目录下。如果不一致就用python -m pip install来代替直接pip install这样能保证装到当前 python 对应的环境里。接下来建虚拟环境。这一步很多人会跳过觉得麻烦但我强烈建议不要省。虚拟环境能把你这个项目的依赖和系统全局的包隔离开避免版本冲突。命令很简单python -m venv venvWindows 下激活venv\Scripts\activatemacOS 或 Linux 下激活source venv/bin/activate激活之后终端提示符前面会出现(venv)字样说明你已经在虚拟环境里了。然后安装依赖pip install flask如果你还需要处理表单、数据库迁移等可以一并装上pip install flask-sqlalchemy flask-wtf不过我个人习惯是先用原生 sqlite3 模块等确实需要 ORM 的时候再上 SQLAlchemy。因为原生 sqlite3 更轻调试的时候能看到实际执行的 SQL对理解数据库操作有帮助。2.2 WorkBuddy 的接入与配置WorkBuddy 的安装方式取决于你用的平台。我是在 Ubuntu 上用的也有朋友在 Windows 和 macOS 上用。安装过程不复杂按照官方指引走就行。装完之后关键是配置好工作目录和项目上下文。我的做法是在 WorkBuddy 里把项目根目录设置为工作区这样它能读取到我的 Flask 项目文件理解项目结构。然后我会在对话里明确告诉它这是一个 Flask 项目数据库用 SQLite模板用 Jinja2前端用原生 HTML CSS不引入前端框架。这样它生成的代码风格才能和我现有的代码保持一致。WorkBuddy 的自定义指令功能很实用。我配置了几条常用指令比如生成 Flask 路由、生成 SQLite 建表语句、检查这段代码的 SQL 注入风险。这样每次不用重复描述需求直接调用指令就行。实操心得WorkBuddy 生成代码后不要直接复制粘贴就用。一定要自己过一遍尤其是数据库操作和用户输入处理的部分。AI 生成的代码在逻辑上通常没问题但在边界条件处理上可能不够严谨。我一般会让它生成完之后再让它检查这段代码有没有 SQL 注入风险或这段代码在空输入情况下会怎样多问一轮质量会好很多。2.3 项目目录结构设计一个清晰的目录结构能让后续维护轻松很多。我的 Flask 项目结构是这样的myblog/ ├── app.py # 主入口 ├── models.py # 数据库操作 ├── routes.py # 路由定义 ├── templates/ # Jinja2 模板 │ ├── base.html │ ├── index.html │ ├── post.html │ └── admin.html ├── static/ # 静态文件 │ ├── css/ │ └── js/ ├── data/ # SQLite 数据库文件 │ └── blog.db └── venv/ # 虚拟环境这个结构的好处是职责分明。app.py只负责创建应用实例和注册蓝图models.py封装所有数据库操作routes.py处理 URL 映射和请求逻辑模板和静态文件各归其位。数据库文件放在data/目录下方便备份和迁移。3. 数据库设计SQLite 建表与核心操作3.1 文章表与分类表的设计我的站点核心是文章所以先设计文章表。字段包括自增主键、标题、slug用于 URL、正文内容、摘要、分类 ID、发布时间、更新时间、发布状态。CREATE TABLE IF NOT EXISTS posts ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, slug TEXT UNIQUE NOT NULL, content TEXT NOT NULL, summary TEXT, category_id INTEGER, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, status INTEGER DEFAULT 1, FOREIGN KEY (category_id) REFERENCES categories(id) );分类表CREATE TABLE IF NOT EXISTS categories ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE, slug TEXT UNIQUE NOT NULL, description TEXT );这里有几个设计决策值得说明。第一slug字段加了 UNIQUE 约束因为它是 URL 的一部分必须唯一。第二status用整数表示1 表示已发布0 表示草稿这样查询已发布文章时直接WHERE status 1就行。第三created_at和updated_at用 TIMESTAMP 类型SQLite 会自动处理但要注意 updated_at 需要在更新时手动设置或者用触发器。注意SQLite 的外键约束默认是关闭的。每次建立连接后需要执行PRAGMA foreign_keys ON;才能让外键生效。这个坑我踩过当时删分类的时候发现文章没被约束查了半天才发现是外键没开。3.2 用 DB Browser for SQLite 管理数据命令行操作 SQLite 虽然直接但日常查看和编辑数据有个可视化工具会方便很多。DB Browser for SQLite 是我用得最顺手的免费、跨平台、功能全。安装之后打开你的blog.db文件就能看到所有表和数据。它的几个功能我经常用浏览数据直接以表格形式查看和编辑数据改完点Write Changes保存。执行 SQL在Execute SQL标签页里直接跑查询适合调试和批量操作。数据库结构查看表结构、索引、外键关系一目了然。导入导出支持 CSV 导入导出批量录入数据时很方便。我一般用它来做这几件事检查文章是否正常写入、手动修改测试数据、查看表结构确认字段类型、导出数据做备份。3.3 增删改查的实操代码在 Flask 里操作 SQLite我用的是原生sqlite3模块。先写一个获取数据库连接的函数import sqlite3 from flask import g DATABASE data/blog.db def get_db(): if db not in g: g.db sqlite3.connect(DATABASE) g.db.row_factory sqlite3.Row g.db.execute(PRAGMA foreign_keys ON) return g.db def close_db(eNone): db g.pop(db, None) if db is not None: db.close()row_factory sqlite3.Row这一行很关键它让查询结果可以像字典一样通过列名访问而不是只能用索引。比如row[title]而不是row[1]代码可读性提升很多。插入文章def create_post(title, slug, content, summary, category_id): db get_db() db.execute( INSERT INTO posts (title, slug, content, summary, category_id) VALUES (?, ?, ?, ?, ?), (title, slug, content, summary, category_id) ) db.commit()注意这里用了参数化查询?占位符这是防止 SQL 注入的关键。千万不要用字符串拼接来构造 SQL比如fINSERT INTO posts (title) VALUES ({title})这是典型的安全漏洞。查询文章列表def get_posts(page1, per_page10): db get_db() offset (page - 1) * per_page return db.execute( SELECT p.*, c.name as category_name FROM posts p LEFT JOIN categories c ON p.category_id c.id WHERE p.status 1 ORDER BY p.created_at DESC LIMIT ? OFFSET ?, (per_page, offset) ).fetchall()更新文章def update_post(post_id, title, content, summary): db get_db() db.execute( UPDATE posts SET title ?, content ?, summary ?, updated_at CURRENT_TIMESTAMP WHERE id ?, (title, content, summary, post_id) ) db.commit()删除文章def delete_post(post_id): db get_db() db.execute(DELETE FROM posts WHERE id ?, (post_id,)) db.commit()这些操作看起来简单但每个都有细节。比如commit()不能忘否则数据不会真正写入。再比如更新时updated_at要手动设置因为DEFAULT CURRENT_TIMESTAMP只在插入时生效。4. Flask 路由与模板让站点跑起来4.1 路由设计与 URL 规划路由是站点的骨架。我的 URL 设计遵循几个原则简洁、语义化、利于 SEO。首页是/文章详情是/post/slug分类页是/category/slug关于页是/about后台管理是/admin。from flask import Blueprint, render_template, abort from models import get_posts, get_post_by_slug, get_categories main Blueprint(main, __name__) main.route(/) def index(): page request.args.get(page, 1, typeint) posts get_posts(pagepage) categories get_categories() return render_template(index.html, postsposts, categoriescategories) main.route(/post/slug) def post_detail(slug): post get_post_by_slug(slug) if post is None: abort(404) return render_template(post.html, postpost) main.route(/category/slug) def category_posts(slug): posts get_posts_by_category(slug) return render_template(category.html, postsposts, category_slugslug)用 slug 而不是 ID 作为 URL 参数好处是 URL 可读性强对搜索引擎友好。比如/post/flask-sqlite-tutorial比/post/123好得多。slug 的生成规则我一般是用标题转拼音或英文去掉特殊字符用连字符连接。4.2 Jinja2 模板的复用技巧模板复用的核心是base.html。我把所有页面共用的部分——头部、导航、侧边栏、底部——都放在 base 模板里其他模板通过{% extends base.html %}继承。!-- base.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title{% block title %}我的站点{% endblock %}/title link relstylesheet href{{ url_for(static, filenamecss/style.css) }} /head body header nav a href{{ url_for(main.index) }}首页/a {% for cat in categories %} a href{{ url_for(main.category_posts, slugcat.slug) }}{{ cat.name }}/a {% endfor %} /nav /header main {% block content %}{% endblock %} /main footer p版权所有/p /footer /body /html文章详情模板{% extends base.html %} {% block title %}{{ post.title }}{% endblock %} {% block content %} article h1{{ post.title }}/h1 time{{ post.created_at }}/time div classcontent{{ post.content | safe }}/div /article {% endblock %}这里{{ post.content | safe }}的safe过滤器表示内容按 HTML 渲染不转义。这适用于你自己写的文章内容。但如果内容来自用户提交就绝对不能加safe否则会有 XSS 风险。4.3 后台管理页面的快速搭建后台管理不需要花哨能增删改查就行。我搭了一个简单的 admin 页面用表单提交文章。admin.route(/post/new, methods[GET, POST]) def new_post(): if request.method POST: title request.form[title] content request.form[content] summary request.form.get(summary, ) slug generate_slug(title) create_post(title, slug, content, summary, None) return redirect(url_for(admin.post_list)) return render_template(admin/edit_post.html)模板就是一个表单form methodPOST input typetext nametitle placeholder标题 required input typetext namesummary placeholder摘要 textarea namecontent rows20 placeholder正文/textarea button typesubmit发布/button /form这个后台很简陋但够用。日更场景下我打开后台填标题、写正文、点发布整个过程不超过两分钟。WorkBuddy 在这里帮了我不少忙——我让它帮我生成了表单验证逻辑、slug 生成函数、以及发布成功后的重定向处理。实操心得后台管理页面一定要加访问控制。我一开始图省事没加结果被爬虫扫到了后台地址虽然没造成损失但吓出一身冷汗。后来加了一个简单的登录验证用 Flask 的 session 实现几行代码的事但安全性提升很大。5. 日更流程与自动化让更新变成习惯5.1 内容创作与发布的标准流程日更最难的不是技术是坚持。我把发布流程压缩到了极致减少每一步的摩擦。我的标准流程是打开后台管理页面登录。填写标题系统自动生成 slug。写正文用简单的 Markdown 语法后端渲染成 HTML。填写摘要用于列表页展示。选择分类点击发布。整个过程我控制在十分钟以内。如果某天实在没时间写长文就发一条短的内容保持更新频率。日更的核心是不断更而不是每篇都长。Markdown 渲染我用的是markdown库import markdown def render_markdown(text): return markdown.markdown(text, extensions[fenced_code, tables])这样我写正文的时候可以用 Markdown存进数据库的是原始 Markdown展示的时候再渲染成 HTML。好处是数据干净以后想换渲染方式也方便。5.2 用 WorkBuddy 辅助内容生成与代码维护WorkBuddy 在日更流程里帮了我两件事。第一是代码维护。站点跑起来之后总会遇到一些小问题比如某个页面报错、某个查询慢了、想加个新功能。我把报错信息贴给 WorkBuddy它基本能定位到问题并给出修复方案。第二是内容辅助。有时候我写技术文章需要一段示例代码我会让 WorkBuddy 生成一个基础版本然后自己修改调整。它生成的代码不一定能直接用但能省去从零开始写的时间。WorkBuddy 的自定义指令我配置了这几条生成 Flask 路由功能是...生成 SQLite 查询语句条件是...检查这段 Python 代码的性能问题把这段代码改成参数化查询这些指令覆盖了我日常开发中最高频的需求用起来很顺手。5.3 数据备份与站点维护SQLite 的备份极其简单——复制blog.db文件就行。我写了一个定时任务每天凌晨把数据库文件复制到备份目录文件名带上日期。#!/bin/bash DATE$(date %Y%m%d) cp /path/to/blog.db /path/to/backup/blog_$DATE.db # 只保留最近30天的备份 find /path/to/backup -name blog_*.db -mtime 30 -delete这个脚本用 crontab 每天跑一次。备份文件保留 30 天超过的自动删除。这样既不占太多空间又能应对误删或数据损坏的情况。站点维护方面我每周会做一次检查查看错误日志、检查数据库大小、确认备份是否正常、更新依赖包版本。这些工作加起来不超过半小时但能避免很多突发问题。6. 常见问题与排查实录6.1 数据库锁定与并发问题问题现象访问页面时偶尔出现database is locked错误。原因SQLite 默认的写锁是排他的当一个写操作在进行时其他写操作会等待。如果等待超时就报这个错。日更场景下如果我在后台发布文章的同时有爬虫在抓取页面就可能触发。解决方法设置连接超时时间让写操作多等一会儿。g.db sqlite3.connect(DATABASE, timeout10)另外把journal_mode设置为 WAL 模式能显著提升并发读的性能g.db.execute(PRAGMA journal_modeWAL)WAL 模式下读和写可以同时进行不会互相阻塞。这个改动对我的站点效果很明显之后基本没再出现过锁定错误。6.2 中文乱码与编码问题问题现象文章标题或内容里的中文显示为乱码。原因通常是数据库连接的编码设置不对或者模板文件的编码不对。解决方法确保数据库连接使用 UTF-8g.db sqlite3.connect(DATABASE) g.db.text_factory str同时确认 HTML 模板头部有meta charsetUTF-8Python 文件本身也保存为 UTF-8 编码。这几个地方都确认一遍乱码问题基本就能解决。6.3 静态文件不更新与缓存问题问题现象改了 CSS 或 JS 文件刷新页面却没变化。原因浏览器缓存了旧版本的静态文件。解决方法在静态文件 URL 后面加一个版本号参数link relstylesheet href{{ url_for(static, filenamecss/style.css) }}?v1.1每次修改静态文件后把版本号加一浏览器就会重新加载。或者用 Flask 的url_for配合文件修改时间自动生成版本号但手动改版本号更简单直接。6.4 常见问题速查表问题可能原因排查方法解决方案页面 500 错误代码异常查看终端错误堆栈根据堆栈定位修复数据库锁定并发写入检查是否有同时写操作设置 timeout 和 WAL 模式中文乱码编码不一致检查数据库和模板编码统一使用 UTF-8静态文件不更新浏览器缓存强制刷新测试URL 加版本号外键约束不生效未开启外键执行 PRAGMA 查询连接时执行 PRAGMA foreign_keysON文章 slug 重复标题相似检查 slug 生成逻辑加随机后缀或时间戳避坑技巧Flask 开发时一定要开启调试模式app.run(debugTrue)这样出错会直接在浏览器显示详细堆栈排查效率高很多。但上线后必须关掉调试模式否则会暴露源码和敏感信息。7. 我踩过的坑与实操心得第一个坑是数据库文件路径。我一开始用相对路径blog.db在本地跑没问题但部署到服务器后用 systemd 启动工作目录变了数据库文件找不到站点直接起不来。后来改成绝对路径问题解决。所以数据库路径一定要用绝对路径或者基于app.root_path动态生成。第二个坑是忘记提交事务。有一次我写了个批量导入脚本跑完之后发现数据没进去查了半天才发现是忘了commit()。SQLite 的 Python 驱动默认是手动提交模式不调用commit()数据就不会真正写入。这个坑很隐蔽因为不报错只是数据消失了。第三个坑是模板里的变量未定义。Jinja2 默认对未定义变量是静默处理不报错但页面会显示空白。我一开始没注意以为数据没查到后来发现是模板里变量名写错了。解决方法是开启严格模式app.jinja_env.undefined StrictUndefined这样未定义变量会直接报错方便定位问题。第四个坑是 SQLite 的日期时间处理。SQLite 没有专门的日期类型CURRENT_TIMESTAMP存的是 UTC 时间。我一开始没注意显示出来的时间比本地时间少了 8 小时。后来在展示的时候做了时区转换或者干脆在插入时用 Python 生成本地时间字符串。这些坑说起来都不复杂但每一个都花了我不少时间排查。写出来是希望后来的人能少走弯路。8. 后续可以扩展的方向站点跑稳之后我陆续加了一些功能。搜索功能是用 SQLite 的LIKE实现的简单但够用def search_posts(keyword): db get_db() return db.execute( SELECT * FROM posts WHERE status 1 AND (title LIKE ? OR content LIKE ?) ORDER BY created_at DESC, (f%{keyword}%, f%{keyword}%) ).fetchall()RSS 输出也不难用feedgen库生成 XML 就行。站点地图用 Flask 路由动态生成提交给搜索引擎。这些扩展都是锦上添花核心还是保持日更。如果你也想用这套方案建站我的建议是先把最小可用版本跑起来——能发布文章、能展示文章、能管理文章这三件事做完站点就算立住了。剩下的功能边用边加。不要一开始就追求大而全那样很容易在配置阶段就耗尽热情。WorkBuddy 在这个过程中扮演的是加速器的角色它不能替你决定做什么但能帮你更快地做出来。Flask 和 SQLite 是稳定的底座让你把精力放在内容和体验上而不是跟环境搏斗。这套组合我用了大半年日更没断过站点运行稳定备份和迁移都很省心。如果你也在找一个能自己掌控、成本低、可持续的建站方案不妨试试这条路。