大家好，我是小九。
说实在的，如果只用Codex写代码，真的有点浪费。
OpenAI Codex团队的工程师Jason（@jxnlco）前几天发了篇长文，题目就叫《Getting the most out of Codex》，直接教大家怎么榨干Codex。
他的核心观点是：Codex已经不只是个写代码的工具了，它正在变成一个能帮我们干电脑上所有活的“全能Agent”。
执行终端命令、浏览网页、调接口、导文档、自动化任务……这些活，Codex现在全都能干。
但大多数人还在用它干最原始的活：看代码库、改diff、跑测试、开PR。
钱都花了，这么用不划算啊！
所以，今天这篇，我把OpenAI官方团队分享的8个核心技巧给你讲清楚。
记住！这是一份来自Codex 官方的“榨干指南”。
把这8招组合起来用，你就能拥有一个7x24小时待命、而且越来越懂你的“超级副手”。
技巧一：语音输入——捕捉你脑子里最原始的“灵感火花”
你有没有这样的体验？
想跟Codex提个需求，但总要先在心里把话“润色”好几遍，就怕说不清楚。
你打字打出的是“经过包装的需求”，但这个过程会把那些最有价值的模糊信息、犹豫、强调和线索，全部过滤掉了。
正确做法是：直接用语音。
Codex内置了语音输入功能。它特别适合那种说起来容易打出来要仔细斟酌的模糊念头。
比如，你就直接对着话筒说：“我记得Ben在Slack里提过这事，细节我忘了，你去找找。”
就这么一句，对于一个能自己搜索、收集信息再汇报的Agent来说，完全够了。
你不需要去想“关键词是什么”“用什么搜索引擎”。
你把脑子里的一个大概想法给它，它自己就能开干。
非常适合捕捉你原始粗糙但却容易一闪而过的灵感。
技巧二：中途纠偏与排队——当AI的“导演”，而不是“观众”
这个技巧适合跟技巧一组成组合技。
在Codex任务执行的过程中，你有两种办法纠正它的方向：
- 转向（Steering)：发现方向不对，立刻打断Codex进程！
比如，Codex正在帮你做一个网站首页评审，你一边看一边说：“等等，这个按钮做小一点，这两个元素的间距感觉不对，这句文案写错了。”
- 排队（Queuing）：不打断当前任务，把下一个任务安排上。
比如：“活干完之后，把预览链接发到Slack上的评审人。”
这两者都让用户在任务展开的过程中保持参与。
技巧三：工具触达——让它的手脚伸到代码库之外
如果Codex只能读写代码库，那它只是工程链路中的一段。
但真正的软件工作，需求可能在Slack，决策可能在邮件，反馈可能在Google Docs。
Codex的厉害之处在于，它的“手”可以一层层往外伸。
-
$browser: 用侧边栏的内置浏览器直接看网页，做标注。
-
@chrome: 用你已经登录的Chrome，干那些需要登录状态才能做的事（比如查内部系统）。
-
@computer: 处理那些只能通过桌面GUI操作的任务（比如挂VPN、点某个按钮）。
-
MCP & 连接器： 连接到Slack、Gmail、日历，把一条消息、一封邮件，都变成它工作的起点。
比如，Reviewer在Slack里提了一个反馈，Codex能先读懂那段上下文，找到对应代码，修改实现，重新生成预览，最后把结果带回同一个Slack线程里等你确认。
看到了吗？
它干的不再是单纯的“写代码”了，而是在帮你“推进一件事”。
技巧四：线程自动化——让Codex在你下班后依然“自动上班”
如果只有你发消息时Codex才工作，那它还是个被动工具。
真正的进阶用法，是给长期线程加上“心跳”唤醒。
你可以设置一个“Chief of Staff”线程，让它每30分钟自动运行一次：
“检查Slack和Gmail里有没有需要我回复的消息。帮我判断优先级。如果有人问我问题，尽量深入研究，起草好回复，但不要发送（等我确认）。”
等你回来，最耗时耗力的“信息收集”和“初步判断”工作已经被干完了。
你只需要做最后的决定：发，还是不发。
技巧五：目标设定与验证——给它一个清晰的“终点线” （Goals）
很多人给Codex派任务，会说：“把这个Markdown文件里的计划实现一下。”
这是个弱目标，太模糊了，Codex根本不知道怎么做才算“完成”。
正确姿势是给它一个具体真实的目标。
模糊目标（不建议你这么干）：“把这个内部工具从Python迁移到Rust。”
具体目标（建议你这么干）：“把这个内部工具从Python迁移到Rust。所有单元测试通过，且现有命令行行为保持一致，才算完成。”
有用的验证机制包括：
• 测试套件 • 基准测试 • bug复现 • 验证矩阵 • 必须持续通过的端到端工作流
有雄心没有验证，不过是个愿望。
技巧六：侧边栏工作台——边看边改，告别来回切屏
Codex的侧边栏，它的核心价值不是展示区，而是一个即时工作台。
让Codex生成一份PPT、一个PDF、或者一个HTML页面，你直接在侧边栏打开审查。
你随口一句“这里调大一点”、“这个颜色不对”，它当场就能改。
网页既是输出，也是操控界面。
Codex可以构建产出物、在侧边栏打开、检查、调试，并就地持续打磨同一个对象。
这些载体特别好用：
• index.html，用于轻量静态产出物 • Storybook，用于UI审查 • Remotion Studio，用于程序化动画 • 基于浏览器的ppt，用于演示 • 数据应用，用于分析工作流
一个单独的index.html文件可以成为持久的交互式产出物，不需要服务器。
线程自动化也可以随时间刷新静态产出物，让用户回来时线程里有新内容等着。
技巧七：持久线程与长期记忆——别每次都从零开始
总开新对话，就像每次跟一个陌生人重新介绍自己。
聪明的做法，是把常用对话置顶，变成几个固定的工作空间。
比如，你可以建立一个：一个专属的“幕僚长”线程、一个专门管发版的线程、一个专门做文档审查的线程。
按 Command+1~9 就能秒切。
Codex会记得你之前的决策、偏好和进度，并且持续工作。
你不会再体验那种“换个话题，它就忘了“你是谁”的恼羞成怒。
技巧八：外部记忆库——给Codex一个“第二大脑”
持久线程很好，但重要的上下文不应该只存在对话记录里。
万一对话关了，记忆就丢了。
更稳的方式，是给Codex准备一个外部记忆库。
你可以用Obsidian，或者就是一个普通文件夹。
结构可能长这样：
vault/
├── TODO.md
├── people/
├── projects/
└── agent/
然后在顶层放一个AGENTS.md文件。
一个实用的AGENTS.md可以这样写：
把~/vault当作持久工作记忆；优先建立权威笔记，而不是笔记蔓延；明确分流TODO、联系人、项目、每日摘要和草稿笔记；保留决策、阻塞点、负责人、日期和有用链接；如果没有实质变化，不要更新vault。
代码库存代码，vault存滚动上下文：涉及的人、发生了什么变化、什么被卡住了、什么需要跟进，以及那些在会话之间会消失的信息。
告诉Codex怎么维护这个记忆库：记下决策、卡点、责任人、有用的链接。告诉它什么时候别瞎改。
一句话： 代码库存代码，记忆库存“滚动上下文”。
重要上下文不应该只活在对话记录里，要写到某个地方，让下一个线程可以接着用。
结尾：重新定义你的AI工作流
最后用一句话概括这篇文章的核心：Codex的上限，从来不取决于它会不会写代码，而在于你有没有把它当成一个可以持续工作的系统来设计。
从今天开始，去建立一个持久线程，开启第一次语音输入，或者写一个简单的AGENTS.md。你打开的，可能是一个全新的工作时代。
如果觉得本文对你有帮助，欢迎点赞、在看、转发，让更多朋友看到！
