我的 blog 技术栈与 AI 发布链路：从草稿到上线如何稳定运行 ​

这篇文章不讨论主题美化，而是拆开一件更关键的事：

如何把一个技术 blog 做成低维护成本、可持续更新、可验证发布的工程化写作系统。

目标先行：它是工作流，不是展示页 ​

我对这个站点的定位很明确：

• 持续沉淀开发过程中的真实经验
• 把可复用方法写成可检索内容
• 用最小维护成本保持稳定更新

换句话说，重点不是“页面多炫”，而是“流程是否可持续”。

技术栈：轻量但闭环 ​

当前基础栈很直接：

• VitePress：站点生成
• Markdown：内容载体
• npm scripts：统一命令入口

package.json 中已覆盖日常核心动作：

• npm run nine:dev：本地开发
• npm run nine:build：生产构建
• npm run nine:preview：构建预览
• npm run nine:new：创建草稿入口 docs/post/新文章.md
• npm run nine:time：生成发布时间戳

核心思路是：工具可以少，但关键链路必须完整。

站点配置：优先默认可用 ​

站点主配置位于 docs/.vitepress/config.mts，当前策略偏务实：

• 顶部导航包含 主页 与 文章列表
• socialLinks 指向 GitHub
• 开启 lastUpdated
• 开启 sitemap
• 搜索使用 local
• 提供 editLink 跳转 GitHub 编辑页

这些配置不花哨，但足够支撑内容组织、检索、维护和回溯。

内容结构：先统一入口，再统一命名 ​

我把写作入口固定在 docs/post，核心对象只有三类：

• 正式文章：docs/post/<timestamp>-<slug>.md
• 草稿入口：docs/post/新文章.md
• 索引页面：docs/post/post-list.md

统一入口的意义是：写作阶段只专注内容，不在一开始就消耗在命名和归档上。

发布链路：把重复动作固化 ​

一篇文章从草稿到发布，固定执行这 6 步：

1. 在 docs/post/新文章.md 完成草稿
2. 整理标题、小节与表达结构
3. 运行 npm run nine:time 生成时间戳
4. 重命名为正式文件名
5. 更新 docs/post/post-list.md 索引
6. 必要时运行 npm run nine:build 验证构建

重点不是步骤多，而是步骤固定。固定之后，维护成本才会长期下降。

自动提交的角色：补充，不替代 ​

自动提交脚本可以提升效率，但它不应替代内容整理与结构校验。

它更适合处理“最后一步机械动作”，不适合承担“文章质量与结构正确性”这类需要人工判断的环节。

AI 在链路中的位置：执行节点，而不是自由发挥 ​

我更看重的是 AI 是否能按仓库约束稳定执行，而不是“写得像不像人”。

在这套流程里，AI 的价值主要体现在：

• 先收窄边界，再改正文
• 基于现有文件与命令落地
• 区分“已验证事实”与“未验证内容”
• 只改必要文件，不顺手扩散改动

当这些点可持续成立时，AI 才真正成为工作流的一部分。

结语 ​

这个 blog 的技术栈并不复杂，真正重要的是链路清晰且可重复：

• 有统一草稿入口
• 有固定命名规则
• 有索引维护路径
• 有构建验证命令
• 有 AI 可遵循的执行约束

对我来说，这才是“能长期维护”的 blog 形态。