文章写多了以后，问题会慢慢变得琐碎：旧文章有没有过时？图片有没有 alt？外链是不是失效了？哪篇文章最近流量下滑？哪些关键词曝光很多但没人点？评论有没有该回复的？在 AI 搜索时代，文章是否足够清晰，能不能被 ChatGPT、Perplexity 或 Google AI Overview 准确引用？
这些事情都很重要，但没有一件会让我每天主动打开后台去处理。
所以我给自己的 WordPress 博客飞觞醉月做了一套自动化系统： oheng virtual team
它不是一个简单的聊天机器人，而是一支围绕博客长期运营的小型 AI 团队：每天巡检、每周复盘、持续记录、发现机会、提醒我做决策，并在安全范围内自动完成一部分低风险维护。
大概两个月的迭代之后，它已经不太像一个实验项目了，更像是围绕个人博客生长出来的一套“自动化编辑部”。
这支虚拟团队现在能做什么
oheng virtual team 目前主要覆盖几个方向：内容维护、读者互动、SEO / GEO 增长、站点健康、数据分析和运维监控。
- 内容保鲜审计
系统会扫描博客文章，判断哪些内容可能已经过时、误导或需要更新。判断依据不仅是发布日期，而是文章是否仍然把旧信息当作当前事实呈现。比如十年前的旅行随笔未必需要更新；明确标注为历史记录的政策或价格信息也未必有问题。真正需要处理的是那些读者可能会当作当前建议参考的旧内容。 - 评论回复草稿
系统会检查最近的 WordPress 评论，结合文章上下文生成回复草稿，但不会自动发布，而是保留人工审核。评论区不是客服系统，仍然需要人的语气和判断。 - 飞书随笔收集
我可以把零散想法、文字或图片发到飞书，系统会定期收集并整理到 WordPress 的月度草稿中，相当于一个“灵感入口”，减少那些随手记录却再也找不到的碎片。 - 节日和节气文章翻新检查
系统会检测是否接近特定节日或二十四节气，如果存在相关旧文，就可以辅助进行翻新并重新推荐。这类场景规则明确，适合自动化。 - GA4 流量数据同步
每天同步 Google Analytics 4 数据，包括 PV、用户、会话、热门页面和来源分布，并写入数据库，用于后续趋势分析和周报。 - Google Search Console 数据分析
分析搜索词、曝光、点击、CTR 和平均排名，找出 SEO 标题机会、关键词排名变化以及需要翻新的文章。 - 关键词排名追踪
保存关键词每日排名快照并比较变化。如果某些高价值关键词明显下跌，就会进入告警或周报分析范围。 - GEO 优化分析
GEO 指 Generative Engine Optimization，也就是面向生成式搜索引擎的内容优化，例如让文章结构更清晰、结论更明确，从而更容易被 AI 搜索系统引用。 - 图片 Alt 修复
扫描高价值文章中缺少 alt 的图片，生成中文、SEO 友好的 alt 文本，并优先通过 WordPress 媒体库更新 alt_text。对正文 HTML 的写入非常克制，以避免破坏 Gutenberg block 结构。 - 外链健康检查
检查高流量文章中的外链状态，识别断链、超时或异常跳转。对个人博客来说，这是一个常见但很少主动维护的问题。 - 站点健康与性能审计
内置站点审计工具，检查页面状态、资源体积、缓存头、安全头以及 PageSpeed / Lighthouse 指标。虽然不能替代专业 APM，但足够支持个人博客的定期巡检。 - Slug 和 URL 健康检查
审计 WordPress slug，发现不规范、重复或过长的 URL，并生成更新计划和重定向辅助文件。实际修改仍需要人工确认。 - 成本与运维监控
每次 LLM 调用都会记录成本和用量，同时记录 daily / weekly 任务耗时、状态、错误和跳过原因，用来监控自动化系统本身是否健康。
每天定时任务做什么
Daily ops 是这套系统的“日常值班”。核心原则是：
每天采集信号，尽量少打扰人；成功时保持安静，失败时再发告警。
目前每日任务包括：
- WordPress 索引增量同步
- 内容保鲜审计
- 节日文章翻新检查
- 评论回复草稿
- 飞书随笔收集
- GA4 流量数据同步
- 运维健康检查
- 关键词排名追踪
- 外链健康检查
- 图片 Alt 修复
Daily ops 更像“数据采集 + 轻量维护”。这些任务每天运行，但不一定都会形成文章建议，它们更多是在持续记录博客的运行状态。
每周定时任务做什么
Weekly ops 更像一次“编辑部周会”。
它不再重复做大量数据采集，而是读取日常积累的数据进行综合分析，并生成一份每周总结。
- SEO 标题机会
- GEO 优化机会
- 内容保鲜分析摘要
- 流量异常检测
- 评论回复执行跟踪
- 每周增长简报
- 关键数据备份
如果说 daily 是“巡逻”，weekly 就是“复盘”。
为什么不直接做成 WordPress 插件
一个自然的问题是：既然它服务于 WordPress，为什么不直接做成插件？
原因主要有几个：
- 很多数据并不来自 WordPress，而是来自 GA4、GSC、飞书、邮件、LLM、GitHub Actions 和 PostgreSQL。
- 我希望任务可以离线、定时、批量执行，而不是依赖访问流量或后台触发。
- Python 生态更适合做 LLM、数据处理、异步任务和 CLI。
- 把自动化放在外部系统，也能减少 WordPress 本身的性能压力。
因此 WordPress 仍然是内容发布系统，而 oheng virtual team 更像是一个独立的运营团队。
它不是一个聊天机器人，而是一个小型运营系统
从技术角度看，oheng virtual team 是一个 Python 模块化单体应用。
我没有把它拆成微服务，也没有引入 Celery、Kubernetes 或常驻 worker。这个项目服务的是一个个人博客，目标不是企业级复杂度，而是低成本、低维护、结构清晰。
目前主要技术栈包括：
- Python + Typer / Rich CLI
- FastAPI 作为内部 API
- LangGraph 用于需要状态和记忆的 agent workflow
- Azure OpenAI 负责推理与生成
- Neon PostgreSQL + SQLAlchemy + Alembic
- pgvector 用于语义检索
- GitHub Actions 执行 daily / weekly 任务
- GA4、GSC、WordPress API、飞书等外部集成
- LangSmith 用于可观测性和链路追踪
架构上，AI 在 vibe coding 过程中把它整理成了一个清晰的五层结构：
- Interface：CLI、FastAPI、GitHub Actions
- Application：任务注册表、任务执行器、写入策略
- Domain：内容维护、增长分析、站点健康
- Infrastructure：WordPress、Google、飞书、LLM 等客户端
- Persistence：SQLAlchemy、Alembic、运行记录和审计日志
这个分层听起来有点工程化，但目的其实很简单：避免自动化系统越长越乱，尤其避免出现“某个 CLI 命令悄悄改写 WordPress 正文”这种灾难。
我对个人 AI 自动化的理解
做完这一套以后，我对 AI agent 的理解也变得更实际。
一个对个人项目真正有价值的 agent，不一定要像人一样聊天，也不需要每次生成很多内容。它更应该像一个可靠的值班同事：
每天出现
知道该看什么
知道什么能做、什么不能做
能把结果写进记录
失败时说明哪里坏了
成功时安静退场
oheng virtual team 对我来说，就是这样一支团队。它不替我表达，但帮我维护表达的现场；它不决定我要写什么，但会提醒我哪里值得回头看看。它没有把博客变成自动生成内容的农场，而是让一个长期写作的人，少被后台维护和数据碎片消耗。
这大概是我目前最喜欢的 AI 使用方式：不是让 AI 抢走笔，而是让它帮我把桌面收拾干净。
