我发现了一个把 Codex 用到极致的小技巧：用 Automations 做低 token 窗口启动器
我发现一个把 Codex 工作窗口利用率拉满的小技巧
最近在高强度使用 Codex 的时候，我发现一个很实用的玩法：
不要等到真正开始工作的时候，才手动发第一条消息。
而是用 Codex Automations 设置几个固定时间的“轻量级窗口启动任务”。
这不是绕过限制，也不是自动刷任务。
核心思路是：用极低 token 的定时任务，提前启动/刷新 Codex 工作窗口，然后等我真正开始工作时，可以直接接上。
我的工作时间大概是：
- 09:30 上班
- 12:00–13:30 午休
- 20:00 下班
- 晚上还会继续用到 01:30 左右
如果按 5 小时一个窗口来规划，最舒服的节奏不是 09:30 开始，而是：
07:00 启动第一轮窗口
12:00 午休刷新
17:00 下午刷新
22:00 夜间冲刺刷新
01:30 收工
这样一来，真正高强度使用时，Codex 的窗口刚好覆盖：
09:30–12:00
13:30–17:00
17:00–22:00
22:00–01:30
最重要的是：
Automations 不要让它读整个项目，不要扫 README，不要扫 docs，不要跑测试，不要构建，也不要自动改代码。
我只让它维护一个极简状态文件：
D:\ai\codex\codex_window.md
每次定时任务只做一件事：
- 读取这个状态文件
- 在顶部追加一条窗口记录
- 整理 3 条以内的下一轮待办
- 输出极短 summary
- 不读其他文件
- 不执行项目命令
- 不提交 commit
- 不创建 PR
这样做的好处是：
- token 消耗非常低
- 不会因为自动任务乱读项目导致上下文污染
- 不会误改代码
- 每个 5 小时窗口都被安排到关键工作时段
- 我打开 Codex 时，不是从零开始，而是已经有一个干净的窗口状态
- 白天、午休、下班前、夜间冲刺都能自然接上
我现在的理解是：
Automations 不适合自动大改项目。
Automations 更适合做“低 token 启动器 + 状态锚点 + 人工接手前的准备”。
我给每个 Automation 的核心要求是：
这是一个轻量级 Codex 定时窗口任务。
目标：只启动/刷新本轮 Codex 工作窗口，并维护一个极简状态文件。
不要大量读取项目。
不要扫描 docs。
不要读取 README。
不要分析全项目。
不要跑测试。
不要构建。
不要修改业务代码。
唯一允许读取和修改的文件：
D:\ai\codex\codex_window.md
如果该文件不存在，请创建它。
如果目录 D:\ai\codex 不存在，请只创建这个目录和这个状态文件。
除此之外，不要读取、扫描、分析或修改任何其他项目文件。
请只做以下事情：
1. 读取 D:\ai\codex\codex_window.md。
2. 在文件顶部追加一条本次窗口记录，包含：
- 当前时间
- 本轮窗口类型
- 本轮建议用途
- 上一轮遗留事项摘要
3. 如果文件中存在“下一轮待办”，请只整理成 3 条以内。
4. 不要读取 README。
5. 不要扫描 docs。
6. 不要检查 git diff。
7. 不要分析全项目。
8. 不要执行测试命令。
9. 不要执行构建命令。
10. 不要运行项目。
11. 不要修改业务代码。
12. 不要提交 commit。
13. 不要创建 PR。
14. 不要访问除 D:\ai\codex\codex_window.md 以外的任何文件。
最后只输出一个极短 summary：
- 本轮窗口已启动
- 下一步我应该做什么
- 是否有上一轮遗留事项
严格限制：本任务的核心价值是低 token 启动/刷新窗口，不是解决问题。不要为了“显得有产出”而扩大范围。
我觉得这个玩法最大的价值不是“自动干活”，而是：
把 Codex 的有效工作窗口，和人的真实工作节奏对齐。
这个方式对每天长时间用 Codex 的人很有用，尤其是那种白天工作、晚上继续冲刺的人。
5 个帖子 - 5 位参与者
来源: LinuxDo 最新话题查看原文