把 Codex 接入博客 MCP 以后，手工发布只是第一步。真正能节省时间的，是让系统在固定时段自动选题、写作、配图和发布。但无人值守任务比手工调用更容易出现重复文章、中文乱码、并发执行和失败重试失控，因此调度脚本必须把“可控”放在“自动”前面。
整点自动发布由哪些组件组成
一个稳定的 Windows 自动发布方案可以拆成四层：Windows 任务计划负责在整点唤醒；PowerShell 脚本负责时间窗口、防重锁和日志；Codex CLI 负责执行写作任务；博客 MCP 负责分类、标签、图片和文章入库。每层只承担一种职责，出错时更容易定位。
为什么要设置明确的发布时间窗口
即使任务计划已经配置了 09:00 到 18:00 的十个触发器，脚本内部仍应再次检查当前小时。这样即使管理员误点“立即运行”，或者系统恢复后补执行任务，也不会在深夜发布。窗口判断应在调用 Codex 之前完成，减少无效模型调用。
$hour = (Get-Date).Hour
if ($hour -lt 9 -or $hour -gt 18) { exit 0 }防重锁怎样避免同一整点发布两篇
自动写作和图片处理可能持续数分钟。如果上一轮尚未结束，下一次触发又启动新进程，两轮任务可能选择相似主题并同时发布。解决方法是在运行目录创建锁文件，启动时检查锁的更新时间；45 分钟内存在有效锁就直接跳过，超过阈值则视为异常遗留锁并清理。
- 任务计划设置为已有实例运行时不启动新实例。
- 脚本使用锁文件形成第二道防线。
- 发布接口使用标题唯一检查形成第三道防线。
- 失败后不自动快速重试，避免重复内容。
如何避免中文正文变成问号
Windows PowerShell 5 的默认编码很容易让中文 JSON 在管道中变成问号。提示词应保存为 UTF-8 文件，通过 Get-Content -Raw -Encoding UTF8 读取；需要把大段中文传给 PHP 时，优先使用 UTF-8 请求文件或 Base64，而不是依赖控制台默认代码页。
日志应该记录什么而不应该记录什么
每轮任务至少记录开始时间、Codex 退出码、MCP 发布结果、文章 ID 和 URL。模型完整提示词、发布 Token、HMAC 签名、OSS AccessKey 不应进入日志。建议把普通运行日志与 Codex 原始 JSONL 输出分开保存，便于排查又避免日常日志过大。
无人值守发布的安全参数
- Codex 使用临时会话，避免长期线程积累无关上下文。
- 工作区采用只读沙箱，写文章只通过 MCP，不让模型修改生产代码。
- 任务设置 40 分钟执行上限，防止异常进程长期占用。
- 发布提示词要求每次只调用一次发布工具。
- 接口失败时输出原因并停止，不猜测成功状态。
上线前如何验证
先运行 Dry Run，确认路径、时间窗口和提示词可读；再手工执行一次真实任务，观察分类、标签、正文和图片；最后查看任务计划中的十个触发器以及下一次运行时间。连续观察一天日志后，再考虑让任务在用户注销状态下运行。
总结
整点发布不是简单地每小时运行一条命令，而是一套包含窗口校验、防重、编码控制、最小权限和可观测日志的流水线。只有把失败路径设计清楚，Codex 自动发布才能长期稳定运行。
评论 0