一份长期学习路线可以排得很完整，却无法说明学习者今天真正会做什么。日历能够列出未来十八个月的 Linux、容器、云基础设施和可靠性工程，但它通常回答不了几个实际问题：

• 昨天的任务已经完成，还是只读过一遍？
• 学习者能否脱离原步骤解释结果？
• 哪个薄弱知识点应该在本周重新出现？
• 下周应该减量、保持，还是适度加量？

为了解决这些问题，我把学习路线实现成了一个带状态的反馈闭环。课程表负责定义预期顺序，每日计划从中选择有限任务，提交的证据推动进度状态变化，周复盘再按明确边界调整后续负载。

日历为什么不够

最初设计是一条按周排列的长期主题序列。它能说明范围，却不能可靠处理学习中断、调度器重复运行、理解薄 …

一个按周运行的媒体流水线需要支持同一 ISO 周内发布多期内容。原来的周标识不再唯一，因此任务目录和历史记录改成了 2026-W32-0、2026-W32-1、2026-W32-2 这样的版本化形式。

但增加序号只解决了一半问题。调度器可能在分配任务后、记录成功前异常重启。如果每次重跑都重新申请“下一个序号”，同一次逻辑运行就会消耗多个任务 ID。对于付费流水线，后果不只是目录混乱：后续命令还可能初始化第二个任务，并向供应商重复提交请求。

重试为什么会重复创建任务

这套流程必须同时满足两个看似冲突的要求：

1. 同一周内的不同运行必须获得递增序号；
2. 同一次定时运行的异常重试必须拿回原序号。

只看 …

我一直使用桌面快捷方式，在不开启 TUN 的情况下为 Codex 单独设置本地代理。一次应用和代理客户端升级后，双击快捷方式不再启动 Codex，也没有清楚的错误提示。

检查发现 Codex 安装本身正常，真正的问题是启动脚本和全局配置都写死了旧代理端口，而代理客户端已经切换到新端口。脚本在启动应用前检测失败并直接退出。

不再猜测端口

修复后的 PowerShell 脚本按以下优先级选择代理：

1. 用户显式传入的 Proxy 参数；
2. Windows 当前用户代理设置；
3. 没有有效代理时明确报错并停止。

系统代理可能是简单的 host:port，也可能按 HTTP、HTTPS 分项配置。脚本统一解 …