夜雨聆风7月4日深夜，一位OpenAI员工在X上悄悄发了一条推文，没有官宣新功能，只抛出一个问题给全网开发者。
24小时不到，这条帖子涨到2832个赞、2830条回复、47.7万次浏览。评论区没人客套。
自己人先开炮
发帖的人叫Tibo，X账号@thsottiaux，简介写着「Codex & ChatGPT @OpenAI」，天天在内部用Codex的产品团队成员，身份写得明明白白。
"What is something that you feel is surprising that Codex still can't do well and we should have gotten right a while ago?"
「你们觉得Codex仍然有哪些做得不够好的地方，是我们早就应该搞定的，却让人惊讶地还没做到？」
▲ Tibo的原帖，2832赞、2830回复、47.7万次查看。不设预设答案，当场抛出问题。
这句话的杀伤力全在**"surprising"和"a while ago"**身上。它把大家逼着说出那些本该早就解决、现在还杵在那儿没解决的老大难。
外部批评容易被公关话术挡回去，内部人主动求锤，几乎堵死了所有辩解空间。开发者们显然也是这么想的，回复区两千多条，火力全开，毫不留情。
Codex到底是什么
如果你没跟上这一轮进展，先花三十秒补课。
2025年4月，OpenAI把Codex从一个单纯的代码生成模型，升级成了完整的AI代理系统。官方给出的区分很干脆：ChatGPT帮你想，Codex帮你干。
它能跨多个文件改代码、调用工具、在沙箱里执行命令、并行跑多个代理、长时间无人值守地干活。打个比方，ChatGPT像"聪明同事帮你出主意"，Codex更像"能干的实习生"，你告诉它目标，它自己拉代码、改文件、跑测试、部署，甚至做PPT、列购物清单。
2026年的Codex桌面App（先上macOS，再补Windows）被定位成"agent的指挥中心"：多线程管理多个代理、Git worktree让几个代理同时改同一个仓库互不打架、内置diff审查、还有可插拔的Skills（接入Figma、Linear、Vercel部署、GPT图像生成等专业技能包）。
听起来无懈可击。评论区却不这么认为。
吐槽第一名：前端和UI，几乎零异议
翻遍两千多条回复，出现频率最高的词只有一个：前端。
用户geluhorotan的回复堪称行为艺术，他什么都没解释，就打了一个词，配一段演示视频，拿下750个赞。
▲ geluhorotan只回复了一个单词"Frontend"（前端），配视频演示，750赞。
另一位用户brahimhamichan干脆挑明了说：
"Everyone is thinking it, I'm gonna say it. UI"
「大家都在想这件事，我来说出来吧。UI。」
▲ brahimhamichan的回复，414赞，配GIF。
具体差在哪？有开发者晒出实际案例：让Codex做一个SaaS落地页，结果生成的界面顶着一个不可点击的"API key已就绪"徽章、几个毫无意义的重复统计面板、一个永远消失不掉的"下一步"提示条，连"紫色渐变"这种老套配色都没落下。有人干脆调侃，Codex这次给的是"最正宗的5.5风格UI糊弄学"。
间距不统一、字体层级混乱、hover状态彻底缺失、移动端断点一碰就崩，功能能跑，审美掉线，这是几乎所有重度用户的共同体验。相比之下，Claude Code早早在设计感和即时预览上攒下了用户心智，差距被反复拿出来对比。
吐槽第二名：文档会把"内心独白"写出来
如果说前端问题还停留在审美层面，文档问题啃的是生产可用性。
用户TheGreenCedar（真名Albert）的回复拿到507个赞、31条跟帖，是整条线程里最有分量的证据之一：
"I didn't get to try 5.6 yet, but as of 5.5, codex cannot in any realm write human-friendly documentation. It leaks its instructions and inner monologue straight into readme files and frontend widgets. It's terrible."
「我还没试过5.6版本，但截至5.5，Codex在任何情况下都写不出对人类友好的文档。它会把指令和内心独白原封不动地泄漏到README文件和前端组件里。太糟糕了。」
▲ TheGreenCedar的回复，507赞、31条回复，评论区多人附和"同样的问题"。
翻译成人话就是：Codex写README的时候，会把"根据你的要求，我现在将创建一个……"这种自言自语原封不动地贴进去，有时候连系统提示词的片段都会混进正式文档。
审美层面的毛病，顶多让人皱眉；这里动摇的，是团队对交付物本身的信任。代码审查时，团队要额外花时间剥离这些"思考痕迹"；新人接手项目，对着夹杂agent独白的README一头雾水；开源项目提PR，这样的文档质量本身就是拉分项。
吐槽第三名：连原生Linux应用都没有
第三类吐槽跟产品线覆盖有关。用户Shikhar留了一句不给面子的话，436个赞：
"No native linux version. Even claude has one now, cmon guys!"
「没有原生Linux版本。连Claude现在都有了，加油啊各位！」
▲ Shikhar的回复，436赞，多名开发者（包括一位前OpenAI研究员）跟帖附议。
现实情况是：Codex的命令行工具（CLI）在Linux上能用，但缺了桌面App那套多代理可视化管理、worktree操作、消息通知的完整体验。很多开发者的主力机就是Linux，服务器、WSL、嵌入式场景到处都是，被迫要么委屈用CLI，要么专门开一台Mac伺候Codex。社区里已经有人搞出把Mac安装包转成Linux可运行版本的野路子，侧面证明这个需求有多真实。
有OpenAI员工在Hacker News上回应过原因：选Electron是为了能更快同时支持Windows和Linux，但沙箱在不同平台上的实现难度天差地别，尤其Windows的沙箱格外难搞，这才拖慢了进度。技术上说得通，用户体验上依然是"等等等"。
吐槽第四名：上下文一长就"失忆"
用户midasavocado的诉求简单粗暴，151个赞：
"Long-context tasks. GIVE US 1M IN CODEX!!!"
「长上下文任务。给Codex 1M上下文吧!!!」
▲ midasavocado的回复，呼吁在Codex中开放1M token上下文能力。
但"给1M"从来谈不上简单，数字背后是一整套工程博弈。后续讨论里，有用户描述了真实场景：让Codex调研十几个竞品方案，搜索结果一股脑塞进上下文，规划阶段一路膨胀到16万token以上，紧接着触发压缩（compaction），结果模型把前面刚研究过的关键约束和已经拍板的决定一起丢掉了，等于让一个刚开完会的同事突然失忆。
有人给出了更工程化的解法建议：让研究类任务交给独立的子代理（subagent）去跑，只把结论摘要交还给主线程，主线程不需要背着整个搜索历史往前走。这正是当下agent记忆分层管理的通用思路，但用户吐槽的重点是，Codex目前"几乎不会主动用子代理"，据反馈，唯一见它用过子代理的场景是安全检查功能，规划阶段更是甩一份方案出来就算完事，不会追问任何澄清问题。作为对比，Claude在规划时反而更爱多问几句。
还有一整面"吐槽墙"
除了这四大共识痛点，评论区还堆积了大量具体到令人心酸的细节：
- 计算机使用没有"叫人"机制
：用户RhysSullivan说，任务跑完或者卡住需要输入时，Codex应该"弄出个声音提醒我"，别让人一直死盯着窗口（116赞）。 - 项目只认单文件夹
：用户ItsTheDaybreak指出，一个Codex项目目前只能放一个文件夹，应该支持多文件夹协同写入。 图像生成效果不如单独打开ChatGPT；Git推送不够可靠；子代理用得"不专业"；用量剩余提示要点两次才能看到，还不能实时更新；Ctrl-R搜索卡顿明显，有人建议"用tantivy不就完了"；甚至有人吐槽"不能给浏览器标签加书签"、"打不开HEIC图片，还得先转格式"、"想在Codex里就地编辑.md文件"。
▲ ItsTheDaybreak的回复：目前一个Codex项目只能包含单个文件夹，呼吁支持多文件夹写入。
单看每一条都不算致命，但两千多条回复叠在一起，拼出的是同一件事：日常的小摩擦，攒多了照样能劝退用户。
官方愿景有多美，现实落差就有多大
翻回OpenAI两个月前发的Codex App官宣文章，画风完全是另一套语言。
官方称桌面App是"agent的指挥中心"（command center for agents）：可以同时管理多个代理并行工作、用Git worktree让多个代理安全地探索不同方案互不冲突、Skills生态已经开放给开发者接入Figma设计稿、Linear项目管理、一键部署到Vercel和Cloudflare。
▲ OpenAI官方博客"Introducing the Codex app"，强调多代理并行、Skills生态与自动化能力。
公开资料还显示，OpenAI内部已经把Codex当成了主力生产力工具，工程团队最早跟进，法务、招聘等非技术部门在2026年也快速跟上采用节奏，员工产出的相当一部分内容都经过Codex之手。
官方喊得响亮："指挥中心""并行代理""开放生态"。评论区摆出来的是另一副样子："前端糊弄学""文档写日记""Linux等到猴年马月"。反差大到没法忽视。这面镜子，是内部产品经理自己举起来的，用不着外部媒体动手拆台。
为什么这些"早该解决"的问题偏偏拖到现在
深挖一层，会发现每一类吐槽背后都对应着实打实的工程取舍。
前端为什么总是最后一块短板？ 后端逻辑、调试、数据处理这类任务有明确的对错标准，模型很容易在这些任务上快速进步。UI设计不一样，它依赖主观审美、品牌一致性、微交互细节，人类"扫一眼就知道好不好看"，但当前"文本描述→生成代码→肉眼检查→再改"这条链路里，缺一个真实浏览器渲染反馈加人类审美打分的闭环，模型自然容易做出"看着像但用不了"的东西。
文档为什么老是泄漏思考过程？ Agent系统内部通常塞满了大量隐藏指令，安全规则、格式要求、工具调用逻辑。如果没有专门的"面向人类的输出模式"做后处理过滤，模型很容易把这些思考链（chain of thought）原样吐出来。5.5版本依然如此，说明"把内部独白和最终交付物分开"这件事，还称不上默认动作。
Linux桌面为什么一拖再拖？ CLI轻量，沙箱好实现，所以能先在Linux跑起来；但完整的桌面体验要处理窗口管理、多会话、系统级通知、密码管理器联动等一整套操作系统深度集成，各平台的沙箱实现难度差别巨大，Mac优先很可能只是因为团队自己的主力设备就是Mac，能最快验证假设。
长上下文为什么"给了数字也不管用"？ 代理跑起来需要在"记住一切"和"别被噪音淹没"之间找平衡。压缩策略，摘要、滑动窗口、重要性打分，决定着用户会不会觉得"它还记得我们之前聊过什么"。1M token听起来很多，但工具调用记录、历史对话、搜索结果几下子就能把它填满。
这道坎，整个agentic coding行业都要跨，Codex只是先被架到了聚光灯下。
拉到行业坐标系里看
对比博客builder.io那篇《Codex vs Claude Code：哪个才是更好的AI编程代理？》，给出了更冷静的第三方视角。
▲ builder.io的对比文章，标题就是"Codex vs Claude Code：哪个是更好的AI编程代理"。
文章作者曾经从Cursor跳去Claude Code，后来又换了阵营。综合多篇同类评测和用户的并行使用报告，大致的结论收敛到几点：Codex的优势在于委托任务时更稳、方法论更细致（排查bug不留手尾）、和ChatGPT生态整合顺畅；短板集中在前端设计味、文档的人类可读性、Linux桌面覆盖，以及规划阶段主动提问、善用子代理这些"主动性"细节上。
于是不少重度用户干脆采取"看菜下饭"的策略，后台批处理、方法论要求高的任务交给Codex，前端和设计密集的项目切到Claude Code。这更像agentic工具还处在百花齐放阶段的正常现象，算不上零和游戏。
早该做好的事，才是护城河
这轮agentic coding浪潮，正卡在从"能跑出惊艳demo"到"能当日常主力"的转折点上。模型能力这几年涨得飞快，瓶颈已经悄悄转移到了系统集成、平台覆盖、人类可读的产出、长任务的可靠性，以及人和AI之间的协作界面上。
Tibo这条推文真正戳中人心的地方，是那两千八百多条真实反馈第一次被集中摆到了台面上。评论区提到的每一条，老用户其实早就在私下抱怨过；难得的是，一个天天用自家产品的内部人，愿意主动把这些"早该解决"的摩擦收上来，让分散在各个角落的抱怨，一次性浮出水面。
前端、文档、Linux、长上下文、通知机制，这些都算不上性感的新功能，甚至有点"基础到不好意思拿出来讲"。但恰恰是这些最基础的体验，决定了一个开发者会不会把真实工作长期托付给它。模型能力是门槛，能不能把这些细节做扎实，才是留住人的关键。
Codex会不会真的把这份清单一条条划掉，还得看接下来几个版本的行动速度。至少现在，题目已经被自己人摆在了所有人面前。
