最近看了 Jason Liu 写的 Codex-maxxing。这篇文章讲的不是“怎么写一个更厉害的提示词”，而是一个更重要的问题：
怎么把 Codex 从代码问答工具，用成一个能持续推进事情的工作助理。
很多人用 Codex，还停留在这几种用法：
- 帮我解释一下这段代码
- 帮我修一个报错
- 帮我写个页面
- 帮我跑一下测试
这些当然有用，但只是入门。
真正拉开差距的地方在于：你能不能让 Codex 记住背景、持续跟进、等待反馈、回来继续改，并且把每一步产物都留在可检查的位置。
换句话说，Codex 不只是“写代码更快”。它更像是一个可以接进你真实工作流里的执行环境。
这篇文章不是逐字翻译。我会按国内用户更常见的场景，把里面值得借鉴的做法重新整理一遍。
先别急着问它问题，先给它分工
很多人用 AI 的方式是开一个新窗口，问完就关。这个习惯没错，但它只适合临时问题。
如果是持续一两周甚至更久的事情，比如改一个产品页、维护一个开源项目、写一组文章、整理一批客户反馈，就应该给它一个固定线程。
你可以把线程按工作线拆开：
- 一个线程专门管某个代码项目
- 一个线程专门管文章和选题
- 一个线程专门管 PPT、文档和资料整理
- 一个线程专门盯评论、反馈和待办
- 一个线程专门处理日程、邮件和会议纪要
这样做的价值不是“省得重新打开聊天”，而是让上下文慢慢沉淀下来。
比如你一直在一个线程里改同一个后台系统，Codex 会逐渐知道项目结构、构建命令、你常用的组件、哪些方案之前试过、哪些坑不要再踩。下次继续做，它就不是从零开始。
但长期线程也不要滥用。所有临时问题都塞进去，最后会把上下文弄得很脏。
我的建议很简单：
真正会反复推进的事情，才开长期线程。一次性问题，用完就走。
把记忆写进文件，不要只相信聊天记录
长期线程有用，但只靠聊天记录并不稳。
更可靠的方式，是让 Codex 把重要信息写到项目文件里。比如你可以准备一个很简单的工作库：
vault/
├── TODO.md
├── projects/
├── decisions/
├── people/
├── notes/
└── AGENTS.md不用一开始就搞得很复杂。关键是让 Codex 知道每类信息该放哪里：
TODO.md放未完成事项projects/放各项目进展decisions/放已经确认过的决定people/放协作对象、偏好和注意事项notes/放零散材料AGENTS.md放通用规则，比如说中文、构建命令、代码风格
这个做法比“AI 说它记住了”靠谱得多。
因为文件有三个好处。
第一，线程丢了也能接上。你新开一个线程，让 Codex 先读这些文件，就能恢复大部分背景。
第二，你可以审查它记了什么。放到 Git 里以后，每次 Codex 更新记忆，你都能看 diff。它有没有理解错、有没有漏掉关键点，很容易发现。
第三，团队也能用。一个人沉淀出来的项目规则，后面可以给其他人或其他 Agent 继续接。
AI 的记忆如果不能被你检查，就只能算“印象”。写进文件，才开始变成资产。
语音输入很适合喂给 Codex
语音输入不是为了显得高级，它真正适合的是那些还没整理好的想法。
打字的时候，人会下意识把话说得很短，很像命令：
“优化一下页面。”
“改一下文案。”
“查一下这个问题。”
但很多真实想法没这么规整。你可能真正想说的是：
“这个首屏我说不上来哪里怪，可能是标题太满，也可能是按钮太靠下。你先打开页面看一下，然后给我两个改法，不要改得太花。”
或者：
“上次客户好像在飞书里提过类似问题，但我不确定是不是这个需求。你帮我从项目记录和文档里找一下，看有没有相关背景。”
这种话打出来很烦，说出来很自然。
Codex 最需要的不是漂亮提示词，而是足够多的真实上下文。语音输入刚好能把你脑子里那些没来得及整理的信息倒出来。
尤其是做产品、运营、内容、咨询、方案的人，这个习惯很值得试。
不要等它做完，边做边纠偏
很多人用 AI 有个误区：发一个大任务，然后等它全部做完。
问题是，等它做完以后你才发现方向不对，成本就已经花出去了。
更好的方式是边执行边纠偏。
比如 Codex 正在改一个页面，你可以一边看预览，一边继续补充：
- 标题再短一点
- 首屏不要这么满
- 移动端按钮间距拉开
- 这段文案太像公告，改得像人话
- 改完跑
npm run build - 如果通过，就整理一段更新说明
这时候 Codex 不再是“一问一答”，而是在处理一个不断变化的任务队列。
这个能力对前端、文档、PPT、数据看板特别有用。因为这些东西很少一次生成就能交付，更多时候是边看边调。
你要做的不是写一个完美提示词，而是让它尽快拿出可看的东西，然后围绕结果继续改。
让它看见真实工作现场
只让 AI 看代码，很多问题是解决不了的。
真实工作里的问题，常常藏在这些地方：
- 浏览器里的页面预览
- 后台管理系统的表单和弹窗
- 飞书、企业微信、钉钉里的反馈
- 邮件里的客户回复
- Excel、PDF、PPT、Markdown 文档
- 设计稿、截图、报错页面
Codex 的价值在于，它不只是能读文件，还能逐渐接触这些工作现场。
比如：
- 用内置浏览器打开本地
localhost页面 - 截图理解当前界面哪里不对
- 操作网页里的按钮、输入框、上传控件
- 读取文档、表格、图片和网页资料
- 把反馈整理成待办，再回到代码里修改
国内用户不必完全照搬国外那套 Slack、Gmail、Calendar。你可以把它映射到自己每天用的工具上：
- Slack 换成飞书群、企业微信群、钉钉群
- Gmail 换成企业邮箱、QQ 邮箱、网易邮箱
- Linear/Jira 换成 TAPD、禅道、飞书项目
- Google Docs 换成飞书文档、语雀、腾讯文档
核心不是用哪个工具，而是让 Codex 能看到反馈、理解反馈，并回到项目里处理反馈。
最小可行做法很简单：让它改完页面后，直接打开浏览器预览。你看到哪里不顺，就继续让它改哪里。
这比在聊天窗口里读一堆说明可靠得多。
最值得学的是“定时回来看看”
原文里我最喜欢的一点，是让线程按固定节奏回来检查。
很多工作不是现在立刻能完成，而是卡在“等别人回复”“等构建完成”“等评论出现”“等客服接入”。
这些事情很琐碎，但很耗人。
你可以让 Codex 做这种定时检查：
- 每 30 分钟检查一次 PR 有没有新评论
- 每小时看一次文档有没有新批注
- 每 20 分钟看群里有没有人反馈预览页面
- 每天早上整理一次待处理邮件和会议
- 客服排队时，每 5 分钟看看有没有人工接入
以前这些都要靠你自己记着。忘了，就断了。
一旦 Codex 能定时回来，它就能把反馈链路闭起来：
发现反馈，理解反馈，更新待办，修改文件，跑测试或构建，再把结果发回去。
举个很常见的例子。
你做了一个活动页，把预览链接发到飞书群里请同事看。然后让 Codex 每 20 分钟检查一次群消息。有人说“移动端图片被裁了”“报名按钮不明显”“标题太像广告”，它就把这些反馈整理成任务，改页面，跑构建，再给你一版新的预览。
这才是 Agent 真正省时间的地方。
它不是替你灵光一现，而是替你守住那些最容易断掉的中间环节。
给 Codex 的目标必须能验收
长期任务最怕目标太虚。
“帮我优化一下项目。”
“把这个页面做好看点。”
“帮我整理一下资料。”
这种话不是不能说，但最好不要作为最终目标。因为 Codex 不知道做到什么程度算完成。
你应该把目标写得能验收：
- 页面改完后，
npm run build必须通过 - 移动端和桌面端都要能正常阅读
- 每条反馈都要有对应修改或明确回复
- 文档要改成适合公众号发布的语气，不能像内部公告
- 表格要整理出核心指标，并能一眼看出变化趋势
- 代码修改后要说明改了哪些文件、为什么这么改、还有什么风险
一句话：
没有验收标准的目标，只是愿望。
Codex 越能跑长任务，你越要把终点说清楚。否则它可能忙了很久，但产出并不是你要的东西。
我建议你从这套工作流开始
如果你已经装好了 Codex，不用一上来就追求全自动。
先把这套最小流程跑起来：
- 为一个真实项目固定一个长期线程
- 在项目里写
AGENTS.md，说明语言、构建命令、代码风格和注意事项 - 建一个
notes/或vault/文件夹，存决策、待办和反馈 - 每次改完，让 Codex 同步更新对应记录
- 前端项目必须打开浏览器预览，边看边改
- 每个任务都写清楚验收方式，比如 build、测试、截图、预览链接
等这套顺了，再加语音输入、浏览器操作、定时检查、远程控制。
不要一开始就幻想“全自动完成所有事”。更现实的路径是先让 Codex 可靠地处理一条小闭环，然后再扩大范围。
最后说句实际的
现在很多人讨论 AI 编程，还是在比哪个模型更会写代码。
模型当然重要，但真正决定使用效果的，往往是你有没有自己的工作流。
同样一个 Codex，有人只拿来问报错，有人会把线程、文件记忆、浏览器、Git、反馈、构建和验收标准串起来。最后的体验完全不是一个级别。
Codex 真正值得学的地方也在这里。
它不只是一个代码助手，而是一个能留在工作现场、持续接收反馈、不断推进任务的执行环境。
如果你只让它写函数，它确实能省时间。
但如果你把它接进真实工作流，它省下来的就不只是打字时间，而是那些最容易被遗忘、拖延、断线的中间环节。