Ben Davis 的妹妹用 Codex 做表格，觉得很惊艳。可使用额度不够时，她却被模型名称和切换滑块难住了。科技视频作者 Ben Davis 用这些体验指出：Codex 有很强的能力，但不断增加的功能缺少统一方向，拼在一起反而越来越难用。
Ben Davis 的妹妹用 Codex 做表格，觉得很惊艳。可使用额度不够时，她却被模型名称和切换滑块难住了。科技视频作者 Ben Davis 用这些体验指出：Codex 有很强的能力，但不断增加的功能缺少统一方向，拼在一起反而越来越难用。
这种混乱也出现在最基本的会话管理里。Ben 认为，同时让多个智能体干活时，侧栏应该告诉用户哪些会话需要处理。Codex 的 Priority view，也就是优先视图，却没有做好这件事。
他期待的是一张待办清单。需要关注的会话出现在里面，用户进去处理，完成后就能把它移走。这样，每次打开侧栏，都能看见还没解决的事情。可他展示的实际体验更像历史时间线，只是把做过的会话按顺序摆出来。看见最近做了什么，并不等于知道现在该处理什么。
原来的项目列表也不适合这种工作方式。过去同时运行的智能体会话不多，按项目找还能接受。现在会话并行起来，用户还得来回寻找项目，再调整位置，操作就变得很吃力。
Ben 猜测，这可能与内部使用习惯有关。如果开发者主要在一个巨大的代码仓库里工作，长期依赖少数几个置顶的超长会话，就不容易碰到其他用户管理大量分散会话时的麻烦。这是他对问题为何迟迟没改善的猜测。
这样的体验问题，并不会因为模型更强就自动消失。Ben 认为，模型仍不擅长开放式的产品判断，尤其是那些需要人的品味和取舍、又很难明确判定对错的问题。
他拿编程举例。让模型把一个庞大的项目用 Rust 重写，可以给它一套测试。测试全部通过，就是一个明确目标。模型可以不断修改，再运行测试，根据结果继续调整。它知道该往哪里走，也知道什么时候算完成。视频里提到的高难度数学问题，同样有可以努力逼近的目标。
但界面用起来是否顺手，很难变成这样的检查程序。一个按钮放在哪里更自然，一组功能怎样组织才连贯，不能简单地靠测试全部变绿来回答。缺少清楚的反馈目标，多让模型反复尝试，也不等于它就会做出正确的产品决定。
所以，他并不觉得拥有顶尖模型的公司，理所当然就能拥有顶尖产品。他承认有模型更擅长这类判断，但仍然没有完全解决。也许以后能找到检验体验的方法，不过在他看来，目前还没做到。
这种产品判断，首先体现在用户要不要替系统理解那些复杂分区。Ben 能理解让同一个智能体负责各种任务的愿景，但他不理解，为什么界面还要让人分辨聊天、工作和 Codex 的区别。
他的建议很直接：让普通聊天也由 Codex 在底层提供能力。用户提出编程任务，就处理代码；妹妹问学校作业，就回答作业。用户表达要做什么，产品再提供相应能力，不必先让用户选对入口。
妹妹的经历把这个问题说得很具体。她需要处理表格，Ben 推荐了 Codex。她很喜欢，也用了很多。后来，她问怎样换模型，或者避免把额度用完。Ben 让她点击模型名称，再把滑块拖到第二个位置。她的反应却是：这些到底有什么区别，我只想把作业做完。
Ben 只好解释，那是一个更小、更便宜的模型。他承认，熟悉这些工具的人在意模型差异，也需要保留手动选择。但普通用户并不理解这些名称。单独分出一个聊天入口，也没解决问题，因为他认为那个入口又缺少 Codex 的不少能力，做表格时仍然得跨过去。
这些入口上的困惑，也来自功能不断增加，却缺少统一取舍。Ben 认为，现在把一个新功能做出来并上线，已经非常容易。模型可以完成交给它的任务，但未必采用最合适的方式。如果没有强烈的产品方向，也没有拒绝某些功能的能力，各种别扭之处就会逐渐累积。
他自己很喜欢 Spaces，这个可以整理页面、保存提示词的工作空间。他用它准备视频，还把剪辑步骤做成模板。剪辑师打开共享页面，就能运行预先写好的提示词，让智能体准备剪辑工程。
可好用的功能拼起来，体验却不连贯。修改页面时，系统会强行把他的整个电脑视图切回那个页面，让他看模型修改。同一段会话又能在页面里出现，也能打开成完整的 Codex 会话。连经常使用的 Ben，都说不清这些对象到底是什么关系。
他并不认为让 AI 写代码必然导致粗糙产品。他举出的正面例子是 Grokbot：同一种机器人，可以在桌面、手机和车里使用，体验仍然连贯。在他看来，关键是先有统一设计，再投入工程上的打磨，并且让改动容易检查和试用。
如果要把这种统一方向落实到 Codex，Ben 的第一步是删功能，再修好基础。他建议把 Codex 会话变成整个产品共同使用的基本单元。桌面应用、网页应用，以及通过命令操作的 CLI，都应该建立在同一种会话之上。
Dots 也可以沿着这个思路重做。它可以是一段有名字的 Codex 会话，再附上例行任务、记忆和外部连接。这样，不同用途的助手就能共享同一套基础。他借 Grokbot 的例子说明，自己看重的是一个可靠的基本单元，可以在不同场景反复使用。
等会话基础稳定下来，再把 Spaces 打磨成另一种清楚独立的对象。会话负责执行任务，Space 里面的页面则是会话可以操作的内容。用户应该能方便地把会话放到云端运行，也能留在本地。操作页面时，也应该支持在后台完成。
他还会保留页面里的输入框，但不让会话与页面死死绑定。从页面发起任务，就打开一段普通会话，并把该页面作为任务上下文带进去。之后用户可以继续在这段会话里做事。这样，页面提供材料，会话负责行动，两者的关系就清楚了。
妹妹已经体验过 Codex 做表格的能力，却仍会被产品本身难住。Ben 的核心批评是，强模型能让功能更快出现，却不能自动决定它们该怎样组成一个好产品。要改善体验，仍需要明确的方向、取舍和持续打磨。