11 Aug 2026
最近我是怎么使用 Codex 的
最近一段时间，我开始把 Codex 从一个“帮我写代码的聊天工具”，变成一个可以持续协助我工作的工程助手。
它不只是在我提问时回答问题，还可以按时检查信息、操作本机软件、准备测试环境、生成文档，并在我离开电脑以后继续执行任务。
这篇文章记录一些我最近真正用过、并且觉得比较有价值的方法。涉及工作内容的部分都做了抽象，不包含具体公司、产品和项目信息。
一、定时任务不是闹钟，而是定时执行工作流
我最开始理解的定时任务比较简单：到时间提醒我做一件事。
实际使用后发现，更有价值的方式是让 Codex 到时间以后直接完成一段工作：
定时触发
→ 读取指定信息
→ 按规则分析
→ 只保留需要我关注的内容
→ 给出下一步建议
每天学习一个 Codex 最佳实践
我设置了一个每日任务，让它分享一个 ChatGPT 或 Codex 的高级使用技巧。为了避免每天收到泛泛的入门介绍，我在任务里写清楚了自己的背景、关注方向和固定输出格式：
- 面向后端开发、SRE 和云原生场景；
- 优先选择能直接用于真实工程的技巧；
- 覆盖代码审查、Debug、架构分析、Agent 和自动化；
- 必须提供实际案例和可复制的 Prompt；
- 不要重复已经介绍过的内容。
这样得到的就不再是“AI 可以帮助写代码”这种结论，而是变更影响分析、跨仓库审查、故障排查证据链等可以马上尝试的方法。
每天筛选真正需要处理的邮件
另一个任务是每天检查本机邮件客户端，找出需要我回复、确认或参与的邮件。
关键不是总结所有邮件，而是先定义什么叫“需要处理”：
立即处理：有明确截止时间、阻塞或紧急风险
今天处理：需要回复、确认、提供材料或参与讨论
可稍后处理：与我相关，但当前不阻塞其他事情
忽略：广告、订阅、群发和纯通知
输出只保留发件人、主题、为什么需要处理和建议动作。任务默认只读，不自动回复、转发或删除邮件。
这个边界很重要。AI 可以帮助我减少信息筛选时间，但真正对外发送内容仍然应该由我确认。
每周从会议纪要中提取行动项
会议纪要很容易变成“看过了，但没有形成行动”。我设置了每周任务，读取最新的例会纪要，只输出两类内容：
- 我需要完成的事情；
- 我需要关注、跟进或协作的事情。
相比“请总结这封邮件”，“找出和我有关的任务、截止时间、依赖人和下一步动作”明显更有用。
监控额度，而不是用完以后才发现
我还尝试让 Codex 定期检查每周剩余额度，在剩余 50% 和 10% 时分别提醒，并增加消耗速度预警。
这个任务让我意识到，好的提醒不能每次运行都发消息。它应该有状态：同一个阈值每周只提醒一次，没有新情况就保持安静；如果无法准确读取数据，也不能猜一个结果。
云端还是本地
我给自己定了一条规则：创建定时任务时优先使用云端，只有任务必须访问本机资源时才使用本地。
只依赖网页、公开信息或云端服务 → 优先云端
依赖本机文件、邮件客户端、桌面应用或设备状态 → 使用本地
云端任务不依赖我的电脑是否开机，适合生成每日技术简报、学习内容和公开信息跟踪。本地任务可以读取邮件客户端和操作桌面软件，但执行时电脑必须可用，应用也要保持登录。
先判断数据在哪里，再决定任务运行在哪里，比先创建任务、出错后再修改更可靠。
二、离开电脑以后继续指挥 Codex
我经常遇到一个场景：一个部署或测试任务还没有结束，但已经到了下班时间。
最近我的做法是让开发电脑锁屏后保持运行和网络连接，再通过手机远程查看任务进度、补充指令。这样我不需要一直坐在电脑前，也不必因为离开办公室就中断一个长任务。
远程协作比较适合：
- 查看长时间构建、部署或测试的结果；
- 根据新日志让 Codex 继续定位问题；
- 调整任务优先级或补充约束；
- 让 Codex 整理结果，第二天直接 review。
但远程控制不等于完全放开权限。删除资源、修改环境、提交代码和对外发送消息，仍然应该设置明确的确认点。
三、让 Codex 操作电脑，而不只是给命令
以前使用 AI 时，我经常得到一组命令，然后自己复制、执行、观察报错，再把结果粘贴回去。
现在 Codex 可以直接使用终端和桌面应用，这个循环变成了：
检查当前环境
→ 制定方案
→ 我确认
→ 执行操作
→ 收集日志和截图
→ 修复问题
→ 验证结果
→ 生成文档
准备本地测试环境
最近我让 Codex 评估本机资源、容器和 Kubernetes 配置，先生成一套本地测试环境方案。第一阶段只允许检查和写方案，不允许部署；我 review 配置以后，再明确授权它执行。
这个过程里最有价值的不是“帮我运行命令”，而是它能把环境检查、配置生成、部署、故障分析和文档更新连成一个完整闭环。
创建可以直接交付的文档
我也会让 Codex 根据聊天、仓库和实际操作结果生成 Markdown、Word 或其他文档。
好的文档任务需要提前说明：
- 读者是谁；
- 已经具备什么背景；
- 需要覆盖哪些内容；
- 是否需要命令、表格和架构图；
- 哪些信息不能出现；
- 完成后如何检查。
例如，同样是技术教程，写给初学者和写给已经有认证经验的工程师，内容深度和解释方式完全不同。
四、我现在常用的任务写法
经过这些尝试，我现在给 Codex 的任务通常包含五部分：
目标：最终要得到什么结果
上下文：相关目录、应用、数据和我的背景
约束：不能修改什么，哪些操作需要确认
输出：结果如何组织，什么信息最重要
验证：完成前要执行哪些检查
一个典型的任务可以这样写：
检查本机邮件客户端中过去一天的新邮件，找出需要我回复、确认或参与的内容。
优先个人直接发给我的邮件，忽略广告、订阅和纯系统通知。
按“立即处理、今天处理、可稍后处理”分组，说明判断原因和下一步动作。
只读，不要回复、转发、删除邮件或修改邮件状态。
没有需要处理的邮件时，只报告“今日无紧急邮件”。
这里最重要的不是写很多字，而是把判断标准、安全边界和输出格式写清楚。
五、最近的一些体会
先手动跑通，再设置定时任务
如果输入来源、判断规则和输出格式还没有稳定，自动化只会定期制造噪音。先让 Codex 手动执行一次，检查结果，再把成熟流程变成定时任务。
要行动项，不要泛泛的摘要
“总结邮件”和“找出我今天必须处理的事情”差别很大。对日常工作来说，后者通常更有价值。
没有变化时应该保持安静
定时任务最容易出现的问题是通知过多。应该明确无异常时是否静默、同一事件是否去重，以及什么情况下才升级提醒。
高风险操作保留人工确认
我的习惯是让 Codex 尽量多做调查、生成、验证和整理，但部署、删除、推送、发邮件等有外部影响的动作保留确认点。
把一次对话沉淀成长期规则
如果一条要求会在以后反复使用，就不应该每次重新输入。比如“定时任务优先云端，必须访问本机资源时才使用本地”，就适合保存成长期规则。
六、总结
我最近对 Codex 最大的认识变化是：它不只是更聪明的代码补全，也不只是一个回答问题的聊天窗口。
我正在把它当成一个可以持续协作的工程助手：
重复的信息筛选 → 定时任务
离开电脑后的长任务 → 远程继续协调
环境搭建和测试 → 让 Codex 操作并验证
经验和结果沉淀 → 自动生成文档
高风险和对外动作 → 保留人工确认
真正提升效率的不是让 AI 一次做更多事情，而是把输入、判断、执行、验证和 review 逐渐组成稳定的工作流。
ref
LEo
at 00:12