先直说,不绕弯子
Codex App 的能力确实很前沿.它能直接读项目、改代码、跑测试、控制桌面应用,也能调用子代理处理任务.放在几年前,这些东西多少有点科幻.
但是,作为 OpenAI 这种大厂推出的官方编程工具,它现在还是有点拉跨
Bug 满天飞、性能优化不怎么样、偶尔会出现反人类的交互设计,还有一些很奇怪的门控小巧思.最近越来越多 ChatGPT 相关能力也在往同一个产品壳里塞,我能理解他们想把功能做完整,但实际使用起来的体感就是越来越臃肿.有时候新功能还没来得及高兴,先得研究为什么我的按钮不见了、权限被挡了,或者同一个能力为什么在另一个入口里才能用.
当然,我一边骂还是一边在用
因为只看“能帮我把项目做到什么程度”,Codex App 目前确实很强.只是想把它用得舒服一点,不能完全顺着客户端的默认设计走.下面这些习惯不是官方标准答案,而是我在长时间会话、多任务项目和几次上下文事故以后慢慢留下来的经验.
本文基于 2026 年 8 月 17 日 的使用体验整理.Codex App 更新很快,具体按钮、门控和内部文件格式以后都可能变化.
先把项目放在找得到的地方#
如果一个线程只是临时问两句话,默认目录倒也无所谓
但只要准备长期使用,或者会生成代码、图片、文档、测试产物,我都建议先给它一个单独的工作目录.最好一个长期项目一个目录,名字不必花哨,关键是过几个月还能看懂里面放的是什么,也知道什么可以备份、什么不能乱删.
刚开始把所有东西都堆进默认位置,看起来没有问题.等里面混进项目副本、临时素材、预览产物、依赖目录和不知道属于哪个会话的文件,再碰上一次清理硬盘,就会开始后悔.
工作目录不只是存放位置.它决定 Codex 默认能看到哪些文件、命令会从哪里开始执行,也决定项目自己的规则能不能被读到.先把地方站对,后面少解释很多事.
一个线程最好只聊一类事情#
不要在同一个线程里上午写论文,下午改博客,晚上再让它帮你写情书
GPT 的长上下文能力已经很强了,但上下文被不同任务反复污染以后,它也遭不住.前一个任务的术语、路径、格式要求和语气偏好,都有可能在后面的回答里偷偷冒出来.
最简单的判断方式是：这些内容是否共享同一批文件、同一套背景和同一个最终目标？
如果答案是否定的,就新开线程
同一个项目内部当然可以持续聊.博客的首页、文章页、播放器和部署本来就会互相影响,放在一个长期线程里有价值.但论文和博客文章即使都需要写 Markdown,也没有必要硬塞在一起.
线程不是越长越厉害.能持续继承有效背景才有意义,只继承噪声就不是什么优点了
给项目留一张能接住上下文的便签#
长项目最怕的不是模型忘了一句需求,而是大家都忘了已经做过什么
聊到几百轮以后,哪些文件不能碰、哪个方案已经失败、当前改到哪里、有没有留下能回去的版本,如果全靠模型从聊天记录里猜,迟早会出事.所以我会在项目里放一份开发笔记.它不需要写成日报,更像一张会跟着项目一起长大的便签.
项目里如果有 AGENTS.md,可以把它理解成项目主人给 Agent 留下的注意事项：哪些内容不能碰、这台机器常用什么终端、改动前要不要备份.它不是给新人背诵的规则书,而是让每次开工的人少踩几次已经踩过的坑.
我现在会把开发笔记按四个动作来用：读 → 验 → 做 → 回写
先读#
开始前先看项目原来的注意事项和开发笔记,尤其是和当前任务有关的部分.以前有没有遇过同类问题,用户有没有特别在意的地方,哪些方案已经被否决,上次测试到哪里,这些信息都比重新猜一遍有用.
不需要一口气读完整本笔记.找到当前功能、报错或目录对应的小节就行.重点不是“看过一份文档”,而是别让模型每次都像第一次打开项目一样工作.
再验#
笔记里的内容是线索,不是现实本身
动手前先确认自己确实在正确的项目里,看看当前有没有别人留下的修改,也确认这次要做的事情不会碰到无关内容.笔记说某个问题已经修好,但实际文件或页面显示另一回事时,应该相信重新看到的证据,然后把笔记改正.
这一步听起来没什么技术含量,但它能避免最难受的一种事故：你以为自己在修 A,结果悄悄把 B 的现场弄乱了.
再做#
确认目标以后再动手,修改尽量收在明确的范围里.中文文件在终端里显示不正常,不等于文件坏了；命令报错也不等于多试几次就会成功.先弄清楚正在用什么终端、文件原来是什么样子,再找合适的做法.
涉及已经验收的功能、多文件改动、图片素材或第二轮返工时,先留一个能回去的版本.这可以是一条本地提交,也可以是一份只保存当前改动的补丁.目的很简单：这次尝试不对时,能准确退回这次尝试以前,而不是把整个项目一起拖下水.
测试也要分开看.代码写完不等于测试通过,测试通过不等于页面已经看过,页面看过也不等于已经发布.把这几件事分开记录,下次接手时才知道还差哪一步.
最后回写#
确认根因、改了方案、跑完测试、做了备份或拿到人工验收以后,给笔记补一条真正有用的结果.写清楚改了什么、为什么改、哪些地方验证过、还有什么没完成就够了.
不要把整段聊天记录、几百行日志和当时的猜测全部贴进去.下一次需要的通常只有结论、关键文件、能回退到哪里和下一步该做什么.
这四步连起来以后,开发笔记才不是单向的备忘录.它在开工时阻止重复调查,在执行中保护现场,在结束时把新证据交给下一轮恢复.
子代理不是按任务描述长短来分#
刚开始用子代理时,很容易走到两个极端：要么觉得什么都得自己做,要么看见工具就想把一堆代理全叫出来
我的判断方式不是看任务描述有几行,而是看它会不会把主线程拖进一团很长、很杂、很难收回的工作里.例如要在很多文件里找一个入口、读很长的日志、检查很多图片、追一个时好时坏的问题,这些都不适合让主线程默默硬扛.
反过来,如果修改位置已经明确,只差一两步就能完成,那就直接做.子代理有沟通成本,没必要为了“看起来很专业”而多开一层.
我现在大致这样分工：
luna便宜而且快,适合扫目录、读长文件、整理日志、处理图片,以及代替主线程操作浏览器terra适合帮忙审方案、看一个明确的 Bug,或者检查一段实现有没有漏掉什么sol更适合留在主线程处理真正难的判断,例如任务方向、复杂状态、风险和最终验收
简单说就是价格 luna < terra < sol,速度 luna > terra > sol,判断能力通常也是 luna < terra < sol.这不是让人给模型排座次,而是别拿最慢最贵的那一层去做重复点击、翻文件和搬日志.
交给子代理的任务越小越好.告诉它要找什么、可以碰什么、不能碰什么、最后只需要回什么.一个代理只做一件清楚的事,结果回来以后由主线程判断能不能用.如果第一次结果不对,说明问题后再让它修一次；还不行就收回来,不要在同一个死胡同里反复催它.
浏览器别留给主线程#
这一条我说得更绝对一点：无论看起来只是点一下还是要完整回归,都不建议主线程自己调用浏览器工具
主线程通常用的是最强也最慢的模型.浏览器却是一连串的动作：点击、等待、看状态、再点击.每一步都要来回一次,延迟会一层层叠起来,最后最简单的页面检查也能拖很久.
浏览器交给 luna max 更合适.主线程只要说清楚要打开哪里、看什么、什么结果算通过、碰到什么情况必须停下. luna 负责点击、悬浮、滚动、刷新和保存必要的截图.它每一步更快,用户也能更快看到页面到底发生了什么.
涉及登录、发布、删除或保存线上设置时,让它停在最后一步.是否真的提交,仍然应该由人决定.
图片会把线程撑胖,而且比想象中快#
图片在对话里只出现一次,并不代表它只占一点地方.很多工具会把图片转换成一大段 Base64 文本放进线程记录.可以把它理解成：图片虽然看不见了,但它的内容还背在这条对话身上.
真正容易出事的不是只看一张普通截图,而是一次原样读取好几张高分辨率图片.几张 4K 原图、连续截图或图片处理中间结果一起进来,线程体积会很快膨胀；请求或工具载荷超过限制时,还可能直接撞上 413 Payload Too Large,连下一次请求都发不出去.
上下文压缩能总结文字,却不会保证把历史图片都处理干净.我处理过一条很长的会话,在备份并清理不再需要的 Base64 媒体数据以后,文件体积缩到了原来的大约五分之一.
不过要先提醒一句：清理线程里的旧媒体不是官方公开保证的维护功能.真要做,先备份,再用一条单独的维护会话去定位和检查,不要直接对正在使用的线程文件搜索替换.
更可靠的办法还是从源头控制.原图永远留在本地,模型只看审查副本.先把尺寸压到适合查看的程度,高分辨率图优先转成体积更小的格式；有透明通道或必须看像素细节时,再单独交局部裁切或无损版本.
图片查找、截图和简单处理也不要都让主线程硬吃.交给 luna 以后,让它承接工具返回的图片内容,最后只把真实图片路径、必要的尺寸信息和一句结论交回来.主线程仍然知道该看哪张图,却不用把每一张图片再背一遍.
一张小图而且位置明确时,没必要专门分派.但一旦变成多张高分辨率图片、连续截图或一整条图片工具链,先压缩,再让 luna 承接返回内容,通常比事后抢救一条越来越胖的线程轻松得多.
不要每次都等客户端替你压缩#
长会话迟早会碰到上下文限制.客户端会自动压缩,但它挑的时间不一定刚好.
比如一个复杂问题刚交付,你马上要开始同项目的另一个大任务.这时上一件事的收尾、刚加的新需求和工具输出很容易挤在一起.如果做到一半才被自动压缩,新的任务背景反而可能在最不合适的时候被打断.
我更喜欢在一个任务真正结束时主动压缩：先把开发笔记补完,确认没有遗留的临时状态,再输入 /compact 开始下一段工作.重点不是盯着某个百分比,而是挑一个自己能说清楚“上一件事已经结束”的边界.
别把客户端问题都当成模型降智#
Codex App 出问题时,第一反应很容易是“它怎么突然不会了”
但真实情况可能是页面没有刷新、插件刚装好却还没重新加载、线程拿到的工具信息已经过期、工作目录不对,或者某个功能被门控挡住了.
我一般会先看几件很朴素的事：文件有没有真的写到磁盘,命令是不是在正确目录运行,工具有没有正常返回,页面是不是还在显示旧状态.这些都没问题以后,再怀疑模型到底有没有理解错.
尤其是安装或更新插件以后,重启 App 往往比在旧线程里反复试更有效.新开线程有时也能让它重新拿到环境,但不是每次都必须这样做.
最后还是得自己管项目#
Codex App 最容易给人的错觉,是它已经能自己读代码、自己改、自己测试,所以用户只需要等结果
短任务或许可以.长项目不行
你仍然要决定线程怎么拆、目录放在哪里、哪些素材不能碰、什么时候该停下来确认,以及什么结果才算真的修好.开发笔记、版本记录和子代理分工看起来都没有“一句话生成项目”那么酷,但它们才是让长线程不失控的东西.
我把更完整的项目规则和开发笔记参考放在这里：Yuimi-chaya/codex-development-guidelines
既然短时间内改变不了客户端,那至少可以先把自己的目录、线程和上下文管明白.这样下次它再冒出什么奇怪设计时,我们面对的就只是一个产品 Bug,而不是一整个已经没人说得清的项目现场.