过去一段时间，我主要用 OpenClaw 来更新老达AI博客。它接入了飞书，我可以在飞书里下达指令，让它搜索资料、整理内容、发布文章。这个工作流在刚开始时确实很有吸引力：手机上发一句话，后台自动处理，看起来很像一个“随身 AI 编辑部”。
但这两天，我几乎把更新博客的任务全部转移到了 Codex 上。原因很简单：在真实维护网站这件事上，Codex 的执行结果更稳定、更可控，也更接近我想要的效果。
这篇文章不是做一个绝对评测，也不是说 OpenClaw 没有价值。它更像是一次老达AI博客的真实运营复盘：为什么我从 OpenClaw 转向 Codex？哪些地方 Codex 明显更顺手？它还有什么问题？普通站长如果想用 AI 更新博客，应该怎么选？
一、我之前是怎么用 OpenClaw 更新博客的？
之前的工作流大概是这样的：
- 我在飞书里给 OpenClaw 发指令；
- OpenClaw 根据指令搜索相关信息；
- 整理成博客文章；
- 调用 WordPress 发布；
- 再配置分类、标签、图片等信息。
从产品形态上看，这套流程很适合“移动端下指令”。我不一定要坐在电脑前，只要能打开飞书，就可以让 AI 去处理内容。这也是 OpenClaw 最吸引我的地方。
但真正持续用下来，问题也逐渐暴露出来。博客发布不是只要“把文章发出去”就完事，它还涉及格式、摘要、SEO、特色图、alt 文本、分类、标签、站内链接、旧文章关联、页面检查等很多细节。只要其中一个环节漏了，文章质量就会打折。
二、OpenClaw 最大的问题：能跑，但结果不够稳
我遇到最多的问题，是发布文章时的细节不稳定。
有时文章格式不正确，比如标题层级混乱、正文结构不够规整，或者不该出现的标题标签出现在正文里。对 WordPress 博客来说，这类问题会直接影响阅读体验和 SEO 结构。
有时图片忘记配置，或者特色图和文章主题不够相关。最近我也意识到一个问题：如果多篇文章都用同一类模板图，网站首页看起来会很单调，放眼望去都是一个模子出来的图，用户体验很差。
还有时标签设置不理想。标签要么漏配，要么和文章主题不够相关，要么创建了一些只有一篇文章的新标签。对一个长期运营的网站来说，标签不是装饰品，它会影响站内结构、索引质量和用户浏览路径。
这些问题单独看都不致命，但累积起来就很麻烦。每次发完文章，我还要回头检查、补图片、改标签、调格式。这样一来，自动化带来的效率就被抵消了。
三、飞书入口很方便，但链路不稳定会影响执行体验
OpenClaw 通过飞书下达指令，这是它的优势，也是它的潜在短板。
优势很明显：手机端非常方便。灵感来了，打开飞书发一句话，就可以让 AI 开始工作。这种入口对内容运营很友好。
但问题也在这里。只要飞书和 OpenClaw 的连接不顺畅，整个工作流就会变得卡顿。有时消息链路不够稳定，有时状态反馈不够清楚，有时任务执行到哪一步也不容易判断。
对简单问答来说，这些问题还能忍。但对“搜索资料、写文章、发布 WordPress、配置图片和标签”这种长链路任务来说，中间任何一环不稳，最终结果都可能出问题。
四、为什么 Codex 更适合我现在的博客维护？
这两天转到 Codex 后，我最大的感受是：它更像一个能在项目里稳定干活的执行者。
比如文章发布这件事，我已经把流程固化到了项目内：
- 草稿格式怎么写；
- 摘要要控制在 80-150 个中文字符；
- 正文不能写
<h1>； - 至少加入 3 条站内链接；
- 优先复用已有核心标签；
- 发布后检查 title、description、keywords、OG 图、特色图 alt 和正文结构。
这些规则写进项目后，Codex 不需要每次重新猜我要什么，而是可以按固定流程执行。前两天我还专门把这个过程整理成了 把博客发文流程做成项目内 Skill 的复盘，这正是从“临时对话”走向“稳定工作流”的一步。
五、文章编辑、发布、图片、标签：Codex 的稳定性更好
在实际发文过程中，Codex 给我的感觉更稳。
文章编辑方面，它更容易保持结构清晰。比如导语、分段、小标题、事实梳理、影响分析、老达点评、延伸阅读，这些模块能比较稳定地组织起来。
发布方面，它可以直接使用 WordPress REST API，并且只取必要字段做检查，减少无意义的接口返回。发布后再用脚本检查页面结果，而不是只看“发布成功”四个字。
图片方面，Codex 可以配合 AI 图片生成能力，为每篇文章生成更贴合主题的特色图，而不是反复使用同一张模板图。这个问题我以前忽视了，但现在回头看，特色图对首页观感影响很大。
标签方面，Codex 可以读取项目内配置，优先使用已有核心标签，比如 AI实践、AI Agent、AI编程、OpenAI Codex、Codex CLI，而不是随手创建一堆低质量新标签。
这些细节组合起来，才是真正的网站运营效率。
六、Codex 在修改网站代码和主题文件上优势更明显
如果只是写文章，很多 AI 工具都能做。但老达AI博客不是一个纯内容平台，它还经常需要改主题、调样式、检查页面结构、补 SEO meta、写脚本、修发布流程。
这部分是 Codex 的强项。
我可以直接让 Codex 阅读项目文件，理解 AGENTS.md、主题函数、发布脚本、草稿目录和现有配置，然后按我的要求修改。它不只是“给建议”，而是能实际改文件、跑检查、发现问题、再修正。
相比之下，OpenClaw 在执行代码修改时，经常不能完全按照我的意图落地。有时思路是对的，但文件改动不到位；有时执行结果和我的预期有偏差；有时需要我反复解释同一个需求。
对网站维护来说，这个差距很关键。因为改代码不是写一段漂亮说明，而是要真的改对、能跑、可验证。
七、成本：Codex 的可控性也很重要
成本也是我转向 Codex 的重要原因。
Codex 现在对我来说成本比较可控。Plus 套餐一个月大约 150 元人民币左右，和国内一些大模型 coding plan 的价格差不多，但实际效果明显更好。毕竟背后用的是顶流模型，代码理解、长任务执行、文章结构和工具调用都更稳。
而如果用 OpenClaw 调用 GPT-5.4 这类高能力模型，费用就完全不是一个量级了。内容运营和网站维护是高频任务，不是偶尔跑一次 demo。如果每次搜索、写稿、改稿、发布、检查都在烧 API，长期成本会很难控制。
这也是很多个人站长容易忽视的问题：AI 工具不是只看单次能力，还要看长期运营成本。一个月能稳定用、成本可预测，比一次效果惊艳但费用不可控更重要。
八、Codex 唯一明显短板：手机入口没有 OpenClaw 顺手
如果说 Codex 目前还有什么明显问题，那就是手机端不够方便。
OpenClaw 通过飞书下指令，这一点确实舒服。人在外面，只要手机能发消息，就能让后台开始处理任务。Codex 目前更偏电脑端、项目端、CLI 和桌面工作流，不像飞书机器人那样天然适合移动指令。
但这个问题不是无解。
我的判断是，手机可以作为输入端，电脑或移动笔记本作为执行端。比如出门时用手机记录选题和需求，回到电脑后让 Codex 执行；或者随身带一台轻薄笔记本，用热点和远程环境处理任务。未来也可以通过消息入口、远程桌面或 Agent 中控，把手机指令转给 Codex 执行。
我之前专门写过一篇 Codex 有手机版吗？手机控制电脑自动执行的 3 种方案，里面讲的就是这个问题。手机入口不是没有办法，只是目前还需要自己搭一层工作流。
九、OpenClaw 不是没价值，而是适合的任务不同
我并不认为 OpenClaw 完全没有价值。它的飞书入口、移动端指令、多工具串联能力，依然适合一些轻量任务。
比如：
- 临时记录选题；
- 收集资料线索；
- 做简单摘要；
- 把灵感同步到知识库；
- 触发一些低风险自动化。
但如果任务进入“正式发布”和“网站维护”阶段，我现在更愿意交给 Codex。因为这些任务更看重结构、权限、检查、代码理解和执行稳定性。
这其实不是 OpenClaw 和 Codex 谁全面打败谁，而是我对工作流做了重新分工：OpenClaw 更像移动入口，Codex 更像生产执行端。
十、我的新工作流：Codex 负责主流程，移动端负责输入
接下来，我更倾向于采用这样的工作流：
- 手机端记录灵感、选题、素材和临时想法；
- Codex 在项目里整理草稿、补结构、查资料；
- Codex 生成或选择主题相关特色图；
- Codex 设置栏目、标签、摘要、内链和 SEO meta；
- 发布后用脚本检查页面结果；
- 必要时再让 Codex 修改主题、脚本或站点结构。
这套流程的重点不是“全自动”，而是“稳定可控”。我不需要 AI 假装什么都能自动完成，我更需要它每一步都可靠：知道规则、按规则执行、执行完能检查。
这也是我最近一直在整理 AI 智能体与自动化专题 和 老达AI实践专题 的原因。AI 真正进入工作流后，核心问题不是会不会聊天，而是能不能稳定交付。
十一、普通站长应该怎么选？
如果你只是想用手机发一句话，让 AI 帮你记个灵感、整理一点资料，OpenClaw 这类飞书入口工具很方便。
如果你要长期维护一个 WordPress 网站，尤其是涉及文章发布、图片生成、标签治理、SEO 检查、主题改造、脚本维护，我更建议把 Codex 放到主流程里。
原因很直接：
- Codex 更适合读取和维护项目文件；
- Codex 更适合执行可验证的代码和发布流程；
- Codex 更容易把网站规则沉淀进项目；
- Codex 的成本更可控；
- Codex 生成的结果更接近可发布状态。
如果你还在比较 AI 编程工具，可以延伸看 AI 编程工具专题 和我之前写的 Cursor、Windsurf 还是 Claude Code。但对我来说，最近这两天的结论已经很明确：老达AI博客的主力维护工具，正在从 OpenClaw 转向 Codex。
十二、老达点评：AI 工具最终拼的是稳定交付，而不是入口多酷
这次迁移给我最大的感受是：AI 工具的入口可以很酷，但最终决定能不能长期用的，是稳定交付。
OpenClaw 的飞书入口确实方便，适合移动端指令。但当任务变成正式发布文章、配置图片标签、修改网站代码、检查 SEO 输出时，我更在意结果是否准确、流程是否可复用、成本是否可控。
Codex 在这些方面更符合我现在的需求。它可以在项目里持续工作，可以把规则写进文件，可以调用脚本发布和检查，可以修改主题代码，也可以生成与文章主题相关的特色图。它不是最方便的手机入口，但它更像一个靠谱的执行端。
所以我的结论是：移动入口可以慢慢补，稳定执行必须先有。对一个长期运营的博客来说，这个优先级很清楚。
