结合win系统的codex app 和 WSL 中的 Codex CLI 做一个可定时执行的新闻日报系统

发布于 2 天前  1 次阅读

结合win系统的codex app 和 WSL 中的 Codex CLI 做一个可定时执行的新闻日报系统

项目文件：
通过网盘分享的文件：new_report_daliy
链接: https://pan.baidu.com/s/1z9ekfSULRT4nKZw09JUOXw?pwd=9eyu 提取码: 9eyu
--来自百度网盘超级会员v5的分享

注：当前文章由ai生成

背景

这次我想实现的目标很明确：

  • 每天定时检索和 AI、科技、国际关系相关的新闻
  • 自动整理成中文 Markdown 日报
  • 把文件保存到本地目录
  • 尽可能给每个栏目补一张本地图片

一开始尝试的是 Codex app 自带的自动化能力，但实际测试下来，任务虽然会更新调度时间，真正的执行记录和文件产出却没有稳定落地。后来改成了一个更可控的方案：

  • 用 Windows 计划任务做定时调度
  • 用 PowerShell 作为启动器
  • 用 WSL 里的 Ubuntu 22.04 执行 Codex CLI
  • 再由 Windows 脚本补做本地图片下载和 Markdown 回填

这个方案的优点是路径清晰、日志明确、失败点可查，而且不依赖桌面版 Codex app 的内置自动化是否稳定。

最终目录结构

项目目前和这套日报自动化直接相关的文件主要有这些：

AI_design/
├─ daily_news_reports/
│  ├─ 2026-03-19.md
│  └─ images/
│     └─ 2026-03-19/
│        ├─ ai.png
│        ├─ tech.png
│        └─ world.png
├─ logs/
│  └─ daily_news_codex/
├─ scripts/
│  ├─ powershell/
│  │  ├─ install_daily_news_task.ps1
│  │  ├─ run_daily_news_with_wsl_codex.ps1
│  │  └─ test_news_codex_runner.ps1
│  └─ prompts/
│     └─ daily_news_codex_prompt.txt
└─ blog_posts/
   └─ codex-wsl-daily-news-automation/
      └─ README.md

为了让项目更干净，我还顺手删除了之前遗留在 scripts 目录里的周报、Word、PPT 相关旧脚本，只保留这次日报系统真正需要的内容。

整体执行流程

整个流程可以概括成下面这条链路：

Windows Task Scheduler
-> powershell.exe
-> run_daily_news_with_wsl_codex.ps1
-> wsl.exe
-> Ubuntu-22.04 / bash
-> codex --search exec
-> 生成 Markdown 日报
-> PowerShell 下载本地图片并回填 Markdown

它不是靠 Windows “自动发现脚本然后执行”，而是因为系统里已经注册了一条计划任务。到了指定时间，Windows 的任务计划程序服务会自动拉起 powershell.exe，再由 PowerShell 去执行脚本。

Windows 为什么会自动执行这些脚本

原因其实很简单：因为我已经把任务正式注册进了 Windows 计划任务系统。

安装脚本 install_daily_news_task.ps1 做的事主要是：

  1. 指定要执行的脚本是 run_daily_news_with_wsl_codex.ps1
  2. 创建一个“每天 18:00”触发的定时任务
  3. 把这个任务注册为 DailyNewsWithWSLCodex

核心逻辑大致是：

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File `"$scriptPath`""
$trigger = New-ScheduledTaskTrigger -Daily -At $Time
Register-ScheduledTask -TaskName $TaskName -Action $action -Trigger $trigger -Settings $settings -Force

也就是说，Windows 自动执行脚本的根本原因，不是脚本本身有什么“开机自启魔法”，而是任务计划程序在后台记住了：

  • 什么时候运行
  • 运行哪个命令
  • 用哪个用户身份运行

到点后，它会主动启动：

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\heisuo\project\AI_design\scripts\powershell\run_daily_news_with_wsl_codex.ps1"

运行脚本做了什么

run_daily_news_with_wsl_codex.ps1 是整个系统的核心。

它主要完成了下面几步：

  1. 计算项目根目录、日报目录、图片目录、日志目录、prompt 模板路径
  2. 根据当天日期生成一个临时 prompt 文件
  3. 把 Windows 路径转换成 WSL 可识别的 /mnt/c/... 路径
  4. 调用 wsl.exe 进入 Ubuntu-22.04
  5. 在 Ubuntu 里执行 codex --search exec
  6. 等 Codex 把日报 Markdown 写到本地后，再读取这个 Markdown
  7. 提取 AI、科技、国际关系 三个栏目中的首个来源链接
  8. 根据来源域名下载对应站点图标到本地
  9. 把本地图片路径插回 Markdown 对应栏目下面
  10. 把本次执行过程写入日志

这一步里最重要的一条命令是：

codex --search exec --skip-git-repo-check --color never --full-auto -C '<workspace>' - < '<prompt-file>'

这表示让 Codex 在指定工作区中，按照 prompt 文件里的要求，自动检索信息并直接产出结果。

为什么改成 WSL 里的 Codex CLI

原因是桌面版 Codex app 的本地自动化在这台机器上没有稳定跑通，而 WSL 里的 Codex CLI 已经验证可用：

  • Ubuntu 22.04 存在
  • codex 命令存在
  • 已登录到 ChatGPT
  • 能直接在 Windows 挂载目录里写文件

相比之下，Windows 侧直接调用本机 Codex 程序时遇到了权限问题，命令行入口不够稳定，所以最后选择了“Windows 调度，WSL 执行”的组合。

配图是怎么实现的

配图不是交给 Codex 在云端下载完成的，而是由本地 PowerShell 做后处理。

原因是：

  • WSL 中的下载能力在这个环境里不稳定
  • 但 Windows 侧 Invoke-WebRequest 可以正常下载部分资源

因此最后采用了一个稳妥的折中方案：

  1. 先让 Codex 只生成日报正文，并在三个栏目下保留 IMAGE_PENDING
  2. 脚本在日报生成后，再读取 Markdown 内容
  3. 提取每个栏目中的首个新闻来源 URL
  4. 取该域名对应的站点图标
  5. 把图标下载到本地目录
  6. 用本地图片路径替换掉占位符

目前下载的是每个栏目一张图，位置类似：

daily_news_reports/images/2026-03-19/ai.png
daily_news_reports/images/2026-03-19/tech.png
daily_news_reports/images/2026-03-19/world.png

Markdown 中插入的是本地相对路径，例如：

## AI
![AI image](images/2026-03-19/ai.png)

这套方案的重点不是“图片多精美”，而是“保证每天都能稳定生成本地配图文件”。如果以后要升级，也可以继续往真正的新闻缩略图或更高质量封面图方向做。

现在的自动执行状态

当前这套系统已经注册了一个 Windows 计划任务：

  • 任务名：DailyNewsWithWSLCodex
  • 频率：每天
  • 时间：18:00
  • 运行用户：Administrator
  • 当前模式：Interactive only

这意味着：

  • 电脑开着，且该用户已登录桌面时，到 18:00 会自动运行
  • 它不是“开机就运行”
  • 它也不是“关机后自动补跑”
  • 它当前更接近“登录态下的定时任务”

所以如果有人问“它会不会自动执行”，答案是：

  • 会，它会按计划时间自动执行
  • 但不是开机自动执行
  • 也不是无论是否登录都运行

“无论是否登录都运行”为什么没有直接启用

理论上，Windows 计划任务支持“无论用户是否登录都运行”的模式，但这个项目里还额外跨了一层：

PowerShell -> WSL -> Ubuntu -> Codex CLI

这时候真正的不确定性不在任务计划程序本身，而在后台非交互会话中：

  • wsl.exe 是否能正常启动目标发行版
  • Ubuntu 中的用户环境是否完整
  • codex 的登录状态是否在非交互模式下依旧可用

也就是说，对普通脚本来说，这种模式常常更稳；但对“调用 WSL 里的 Codex CLI”这种链路来说，还是需要单独验证，不能想当然地直接启用。

日志和验证

为了避免“看起来像跑了，其实没产出”的情况，这套方案加了几层验证：

  • 自检脚本 test_news_codex_runner.ps1
  • 执行日志目录 logs/daily_news_codex/
  • 真实报告目录 daily_news_reports/
  • 本地图片目录 daily_news_reports/images/<date>/

只要一次执行成功，通常会同时看到三类结果：

  1. 生成了一份新的 Markdown 日报
  2. 生成了对应日期的本地图片文件
  3. 日志中记录了 WSL 调用和图片下载信息

这比单纯依赖 Codex app 的自动化状态要清晰得多。

这套方案的优点

  • 调度端稳定，依赖 Windows 自带任务计划程序
  • 执行链路清楚，哪一步失败都比较容易定位
  • 产物全部落在本地，方便归档和二次处理
  • 不依赖 OpenAI API key
  • 继续利用了 Codex 的检索和写作能力

这套方案的局限

  • 目前配图还是以站点图标为主，视觉效果一般
  • 任务当前依赖登录态，不是彻底的后台无人值守模式
  • 控制台里中文显示有时会乱码，但文件本身通常是正常的
  • 如果 WSL 登录态或 Codex CLI 环境变化，任务也会受影响

如果后续继续优化

后面如果继续迭代，我会优先考虑这几个方向：

  • 把计划任务升级成“错过时间后补跑”
  • 测试“无论是否登录都运行”的后台模式
  • 提升图片质量，尽量从站点图标升级为真实新闻配图
  • 优化 Markdown 标题和中文编码处理
  • 给日报增加更统一的版式和摘要格式

总结

这次最后落地的不是 Codex app 原生自动化，而是一套更实用的替代方案：

  • 用 Windows 负责定时
  • 用 WSL 负责运行 Codex CLI
  • 用 PowerShell 负责本地文件、日志和图片下载

从工程角度看，这样的分层更容易控制，也更容易解释“为什么会自动执行”。Windows 自动执行这些脚本，不是因为脚本本身特殊，而是因为系统的任务计划程序在指定时间主动调用了它们。

如果只是想做一个每天固定时间生成本地新闻日报的系统，这套方案已经能跑起来，而且产物、日志、目录结构都比较清楚，适合作为一个实用型自动化案例。

最后更新于 2026-03-19
啥也没有呀