Codex 的瓶颈是我
对 Codex、Claude Code 这类工具蠢蠢欲动时，最自然的方式就是直接上手。要找文献，就让它帮忙搜。要写代码，就让它搭框架。要分析数据，就把表格和问题丢进去。更不用说写文章、改摘要、润色标题，这些本来就是 LLM 很擅长的事。
随后你的小红书或某些平台上就会被充满：“如何用 AI 三天写完论文”、“一键生成文献综述”的技巧。每一个看起来都有用，每一个都像是一扇门。点进去之后，后面还有更多门。
一开始会觉得这条路很顺。过去要自己一点点花时间磨的东西，现在好像都能先生成一个版本。小红书、公众号里，也到处都是类似的经验：某个提示词，某个插件，某个 workflow。看过几次以后，平台会继续推送更多。文献综述、研究设计、Python 代码、论文配图、投稿信……无所不包。
大模型确实让创造变得简单了。这当然是好事。很多过去卡住人的地方，确实变轻了。至少不用每次都从一张空白文档开始，也不用因为一个小脚本跑不通，就在晚上耗掉三四个小时。
但用久了以后，问题也会慢慢出来。这里先不说各种 skill 本身的坑。用多了自然会发现，很多内容跟骗子也没什么两样。一方面大模型本身就基于概率，同一个 skill 吐出的东西自然也是有差别的。另一方面是创造变得廉价之后，围绕创造的噪音也会变得廉价。这几乎是必然结果。
真正的困扰发生在和它互相折磨过一段时间后。你会发现聊到后面，大模型的输出越来越不好用。你想换个新方向，在对话框里特意叮嘱“忽略前面的逻辑”，但它吐出来的下一段话，依然带着几个小时前那个错误方案的影子，怎么也甩不掉。反倒是当你往上滚动滚轮，想找回昨天下午它给出的一段核心定义时，却发现那个干净的文本早就被成页的报错日志和废代码吞噬了，怎么也找不到了。
这种不好用不仅仅是它的上下文限制等技术问题，更是我自己。我经常迷茫在它产出的无数内容中，根本没有任何可能去处理。大模型在 30秒内生成 10 版方案的能力很强。但这种“一键即享”的体验带来了一个直接的后果——人类不再有耐心去逐字阅读上千字的过程文件了。实际产出的文本体量是过去的十倍，人的精力却被稀释了。
这时候，你绝对不能指望刚刚帮你生成 10 版方案的那个对话窗口来帮你做审核。因为在生成的过程中，它已经给自己注入了某一个特定方向的概率偏向。它无法跳出自己刚刚写下的文字去吐出真正尖锐的反对意见。
在同一个对话窗口里，可能前半小时还在让它写一段复杂的清洗数据代码，后半小时就推给它一段文本，让它设计一个扁平、高对比度的极简 UI 界面。我们习惯了把它当成一个全能的节点，一会儿是程序员，一会儿是设计师。
但在现实中，这两类人几乎不共享同一种上下文，他们用完全不同的思维语言。
把这些任务混在同一个窗口里，很快就会出问题。大模型的运转逻辑是基于上文预测下一个词。它刚刚自己输出了几千字的代码逻辑，这些字就变成了后续对话的沉重背景。这时候即使你输入“抛弃历史包袱、扩充思路”，它也很难真正跳出来，依然会在既有的几千字里绕圈子。它记得太多了，反而转不过弯来。
解决这个问题的办法其实很简单，就是物理隔离。
这就像现实中的课题组：科研助理（RA）守在屏幕前盯着报错、清洗 CSV 数据，导师坐在白板前听汇报、挑逻辑漏洞。导师在把控方向的时候，大脑绝对不会允许被那些具体的代码环境和语法报错的杂音塞满。
把这种分工搬到大模型上，就是直接准备两个独立的窗口，甚至用不同的系统提示词（Prompt）把角色完全分开。一个窗口是研究助理。你发给它具体的指令：“把这个文件夹里的 CSV 文件合并，去掉空值。”它会快速吐出代码，你负责复制、运行、看结果。它的大脑里全是代码和错误日志，没关系，它就是干这个的。
这种隔离，是在帮我们找回在流程中的位置。这件事情并不容易，因为过程中无时无刻不在对抗自己的惰性。
用大模型到最后，相不相信它其实不是一个需要纠结的问题。你只能相信它，直到错误发生，然后一起调整。
摇摇欲坠的隔离也是隔离