文章写多了以后，真正消耗人的不是写作本身，而是那些散落在后台里的小事：旧内容有没有过时，图片有没有 alt，外链是不是失效，哪篇文章流量下滑，哪些搜索词曝光很多但没人点，评论有没有该回复的，在 AI 搜索时代文章是否足够清楚，能不能被 ChatGPT、Perplexity 或 Google AI Overview 准确理解。
所以我给自己的 WordPress 博客飞觞醉月做了一套自动化系统：oheng virtual team。
它一开始只是一些零散脚本，后来慢慢长成了一支围绕博客长期运营的小型 AI 虚拟团队。它不负责替我写博客，也不负责制造更多内容噪音；它更像一个会值班的编辑部：每天巡检、每周复盘、持续记录、发现机会、提醒我做决策，并在明确安全边界内自动完成少量低风险维护。
这篇文章是这个项目的阶段性记录。之前写完以后，项目又经历了几轮重构：从“几个自动化任务”收敛成了任务注册表、daily / weekly workflow、写入审计、异步 API、n8n 聊天入口和 Neon 搜索。现在再看，它已经不太像玩具项目，更像是为一个个人博客量身定制的运营系统。
现在这支虚拟团队能做什么
oheng virtual team 现在主要覆盖六类事情：内容维护、读者互动、SEO / GEO 增长、站点健康、数据分析和运维监控。
- 内容保鲜审计
系统会扫描博客文章，判断哪些内容可能已经过时、误导或需要更新。它不是简单按发布日期判断，而是看文章是否仍把旧信息当作当前事实呈现。历史随笔、旧笑话、明确标注为当时记录的政策或价格信息，不会因为年代久远就被粗暴判为问题。 - 评论回复草稿
系统会检查最近的 WordPress 评论，结合文章上下文生成回复草稿，但不会自动发布。评论区仍然需要人的语气和判断，所以机器只负责把“可回复的材料”准备好。 - 飞书随笔收集
我可以把零散想法、文字或图片发到飞书，系统会定期收集并整理到 WordPress 的月度草稿里。它相当于一个灵感入口，减少那些随手记下却再也找不到的碎片。 - 节日、月份和节气文章自动翻新
像“七月”、小暑、大暑、春节、中秋这类有明确日期的文章，会在命中当天自动更新发布日期和发布状态，把旧文章重新推到合适的位置。这个任务只改日期和状态，不改正文内容。 - GA4 和 GSC 数据同步
每天同步 Google Analytics 4 和 Google Search Console 的关键数据，包括 PV、用户、会话、热门页面、搜索词、曝光、点击、CTR 和排名变化，写入数据库供后续分析。 - SEO / GEO 机会分析
SEO 侧关注高曝光低点击、标题机会和排名下跌；GEO 侧关注文章是否适合被生成式搜索引用，比如结构是否清楚、答案是否明确、段落是否便于提取。 - 图片 Alt 和链接健康
系统会审计高价值文章里的图片 alt 和外链状态。图片 alt 默认优先更新 WordPress 媒体库的 alt_text；涉及正文 HTML 的写入会被严格限制，避免破坏 Gutenberg block 结构。 - 成本与运维监控
每次 LLM 调用都会记录成本和用量，daily / weekly 任务也会记录耗时、状态、错误和跳过原因。自动化系统本身也需要被观察，否则它迟早会变成新的黑箱。
Daily ops：每天值班，但尽量安静
Daily ops 是这套系统的“日常值班”。它的原则是：
每天采集信号，尽量少打扰人；成功时保持安静，失败时再发告警。
目前 daily workflow 包括：
- WordPress 索引增量同步
- 节日 / 月份 / 节气文章翻新检查
- 内容保鲜审计
- 评论回复草稿
- 飞书随笔收集
- GA4 流量数据同步
- 运维健康检查
- 关键词排名追踪
- 外链健康检查
这里面只有少数任务会触碰公开 WordPress 状态。例如日历文章翻新只更新日期和状态；评论回复只生成待审草稿；月度随笔默认只更新草稿，是否发布仍需显式开关或人工命令。这个边界对我很重要，因为自动化越强，就越需要知道它到底会改什么。
Weekly ops：每周复盘，而不是每天焦虑
Weekly ops 更像一次编辑部周会。它不重复做大量采集，而是读取 daily 积累的数据，生成一份综合分析。
- SEO 标题机会
- GEO 优化机会
- 内容保鲜摘要
- 流量异常检测
- 内容改进优先队列
- 每周增长简报
最近的一次重要重构，是把 weekly report 从“几个单独建议”升级成了增长闭环。系统会把 daily_metrics、freshness_audit_states、keyword_rankings、ops_runs、content_opportunity_records、llm_usage_logs、image_alt_fix_states、comment_reply_logs、geo_scores 和 ai_search_traffic_logs 这些数据汇总起来，再生成关键发现、改进回顾和优先行动建议。
我还加了 weekly action review。它不是自动改文章，而是把周报里的行动项整理成卡片：哪些值得做、风险多高、需要改标题还是补 alt、是否应该忽略或延期。对个人博客来说，这比“让 AI 直接改完所有东西”更可靠。
项目架构后来怎么变了
这个项目一开始带有很强的 agent 想象：似乎应该有一个会聊天、会记忆、会调用工具的“大脑”。但做着做着我发现，博客运营真正需要的不是一个永远在线的聊天角色，而是一组边界清楚、可以审计、可以重跑、可以失败恢复的任务。
所以现在的核心变成了任务注册表和 workflow：
- Task registry：每个任务都有名称、输入 schema、风险级别、触发来源、dry-run / execute 边界和结构化结果。
- Ops runner：daily 和 weekly 统一由 runner 编排，写入 ops_runs，使用幂等 key 和 advisory lock 避免重复执行。
- FastAPI / API tasks：外部调用不再随便丢 prompt，而是进入白名单任务队列，返回 task_id 后查询状态。
- WordPress 写入审计：公开文章的写操作会尽量记录变更字段和内容哈希，避免以后不知道是谁改了什么。
- Neon PostgreSQL：WordPress 索引、流量快照、GSC 数据、GEO 分数、周报和行动记录都沉淀到数据库。
以前项目里还有 repository-local 的 Agent / LangGraph 聊天面，现在已经移除了。需要 LLM 的地方仍然会用模型，但都被包进明确的任务 handler 里，而不是让一个泛化 agent 自由发挥。
n8n 聊天入口也换了一套脑子
网站前台的 AI 客服入口现在由 n8n 承担。它原来用过 Qdrant 作为知识检索，后来我把它迁到 Neon 里的 WordPress 文章索引上。这样 n8n 可以直接通过一个轻量搜索 workflow 查博客内容，不需要维护另一份向量库。
这个改动带来的好处是简单：博客文章同步到 Neon 后，聊天入口、GEO 分析、语义搜索和周报都可以复用同一份数据。数据源越少，长期维护越轻。
为什么不做成 WordPress 插件
一个自然的问题是：既然它服务于 WordPress，为什么不直接做成插件？
- 很多数据不来自 WordPress，而是来自 GA4、GSC、飞书、GitHub Actions、Neon、n8n 和 LLM。
- 我希望任务可以离线、定时、批量执行，而不是依赖访问流量或后台触发。
- Python 更适合做 LLM、数据处理、异步任务和 CLI。
- 把自动化放在外部，也能减少 WordPress 本身的性能压力。
所以 WordPress 仍然是内容发布系统，而 oheng virtual team 更像一个外部运营团队。
我现在更在意安全边界
这个项目越做越大以后，我最在意的反而不是“能不能自动做更多”，而是“哪些事绝对不能偷偷做”。
- WordPress 的
content.rendered只读，不写回。 - 正文写入必须使用 edit context 下的 raw content。
- 公开文章正文覆盖默认拒绝，除非是明确的受控操作。
- 图片 alt 默认先更新媒体库，正文 HTML 同步单独控制。
- slug、redirect、正文重写这类高风险动作，都不能藏在 daily / weekly 里悄悄发生。
这也是为什么我后来把很多东西从“自动优化”改成“生成行动卡片”。AI 可以帮我看见问题，但不应该默认替我决定一切。
目前的技术栈
- Python + Typer / Rich CLI
- FastAPI 作为内部 API 和任务入口
- Azure OpenAI 负责结构化分析与生成
- Neon PostgreSQL + SQLAlchemy + Alembic
- pgvector / 文本索引用于博客检索
- GitHub Actions 执行 daily / weekly workflow
- WordPress REST API、GA4、GSC、飞书、n8n、Brevo 等外部集成
- LangSmith 用于可观测性和链路追踪
我对个人 AI 自动化的理解
做完这一套以后，我对 AI agent 的理解变得更实际了。
一个对个人项目真正有价值的 agent，不一定要像人一样聊天，也不需要每次都生成很多内容。它更应该像一个可靠的值班同事：
每天出现
知道该看什么
知道什么能做、什么不能做
能把结果写进记录
失败时说明哪里坏了
成功时安静退场
oheng virtual team 对我来说，就是这样一支团队。它不替我表达，但帮我维护表达的现场；它不决定我要写什么，但会提醒我哪里值得回头看看。它没有把博客变成自动生成内容的农场，而是让一个长期写作的人，少被后台维护和数据碎片消耗。
这大概是我目前最喜欢的 AI 使用方式：不是让 AI 抢走笔，而是让它帮我把桌面收拾干净。
常见问题
个人博客为什么还需要一支 AI 虚拟团队？
因为真正持续消耗人的，往往不是写作本身，而是那些散落在后台里的维护工作：内容保鲜、图片 alt、外链健康、搜索表现、评论回复和周报复盘。这些事情单独看都不大，但长期累积会不断打断写作。
这支虚拟团队每天和每周分别做什么？
Daily ops 负责日常值班，主要做信号采集、低风险巡检和少量受控维护；Weekly ops 负责复盘，读取 daily 累积的数据，生成增长、GEO、SEO、流量异常和内容机会分析，帮助我判断下一步值得做什么。
为什么不直接把它做成 WordPress 插件？
因为它处理的不只是 WordPress 里的文章，还要连接 GA4、GSC、飞书、Neon、GitHub Actions、n8n 和 LLM。很多任务适合离线、定时、批量执行，放在外部系统里也能减少 WordPress 自身的性能和安全负担。
哪些事情可以自动做，哪些必须人工确认？
这套系统默认只自动处理低风险动作，比如日常巡检、数据采集、受控的日历文章翻新、待审评论草稿和周报分析。正文重写、slug 修改、redirect、公开文章覆盖这类高风险动作，必须明确进入受控流程，不能在 daily / weekly workflow 里悄悄发生。
我现在最看重这套系统的是什么？
不是它能不能自动做更多，而是它有没有清楚的安全边界、可靠的任务记录，以及在成功时安静退场、失败时把问题说清楚的能力。对长期写作的人来说，这比“多生成一点内容”更有价值。
