oheng.com这个运行了20多年的个人博客对于我来说，更像是个人公示版、备忘录、收藏夹和长期生活痕迹。可就是这样一个自有 VPS 上的 WordPress 博客，日常维护也是蛮耗精力里的。
AI时代，我常考虑的一个问题是如何让AI辅助我维护blog，让养博客这件事更轻松些。
AI 出现以后，我开始思考的不是“让 AI 替我写博客”，而是：能不能让 AI 帮我把那些繁琐、低频、但长期有价值的维护工作做起来？
那具体该怎么做呢？于是我有了下面这些尝试：
第一篇：AI 客服上线：从“能聊天”开始的博客 AI 实验
最自然、最容易被理解的 AI 应用，是让博客多一个聊天入口。
- 为什么最初想到给博客接一个 AI 客服
- 它解决的不是“客服压力”，而是“访客入口”和“博客内容问答”
- 个人博客上的 AI 客服和商业网站客服有什么不同
- 上线后发现的问题：加载性能、第三方脚本、移动端体验
- 这次实验带来的启发：AI 功能不能只看“聪明”，还要看维护成本和页面负担
第二篇：AI 帮我重新体检 WordPress 性能
真正开始把 AI 当维护助手，是从性能体检开始的。
- 自建 WordPress 博客常见的隐性维护成本
- AI 如何辅助分析 Lighthouse、缓存、CDN、插件脚本
- 发现 n8n chat、Site Kit、AdSense 等脚本对移动端性能的影响
- 为什么没有简单粗暴地禁用 Site Kit
- 从“优化一次页面”转向“建立可复查的审计工具”
- 结论：AI 最有用的地方，是帮人看懂复杂报告，并把问题拆成可执行动作
第三篇：AI 帮我判断哪些插件该留、该删、该替代
插件管理不是“越少越好”，而是理解每个插件的真实价值和代价。
- WordPress 插件越来越多之后的问题
- AI 如何帮忙梳理插件功能、性能影响、替代方案
- 哪些插件必须保留：例如 Site Kit、缓存、安全、评论、防垃圾等
- 哪些插件可以延迟加载、限制作用范围，或者用脚本替代
- “删插件”不是目的，“降低不确定性”才是目的
- 结论：AI 适合做插件盘点、风险解释和替代方案比较
第四篇：AI 帮我处理那些以前懒得做的困难工作
AI 帮我重新考虑以往困难工作的优化，例如这次 WordPress 到 Hugo 的迁移探索。
- 以前为什么想过从 WordPress 迁移到 Hugo
- 静态博客的诱惑：快、安全、低维护
- 迁移真正困难的地方：历史文章、图片、链接、评论、短代码、SEO、重定向
- AI 能帮忙的部分：内容清洗、格式转换、链接检查、迁移计划
- AI 不能替你决定的部分：是否值得牺牲 WordPress 的编辑体验和生态
- 结论：AI 不一定让你马上迁移，但会让“迁移是否值得”这件事变得可评估
第五篇：oheng-virtual-team：一个给个人博客打工的 AI 虚拟团队
从单点 AI 工具，升级成日常维护体系。
- 为什么单个 AI 助手不够，需要“虚拟团队”
- 当前团队角色：内容保鲜、SEO、GEO、图片 alt、评论回复、流量日报、周报等
- 每日任务和每周任务如何分工
- 为什么大多数任务默认不直接改线上内容，而是先生成建议、报告、草稿
- 安全边界：
--execute、dry-run、报告目录、不可泄露密钥、不能写回 rendered HTML - 最终目标：不是制造一个全自动博客，而是让博客维护从“想起来才做”变成“有人持续提醒和准备”
