[🤖/✨] 不管是 Claude Code 还是 Codex，都是废物级、没眼力见的天才。
✨ GPT-5.5 的摘要
从 Claude Code 换到 Codex 之后，同样的乱局还是重演了。这是一篇记录：真正重要的不是模型名字，而是能驱动这些废物级、没眼力见的天才的 harness。
对话的流向
这篇文章记录的是 2026 年 6 月 4 日，我在修改 今天一天 #199 日记时，和 Codex 正面撞上的过程。
就像几天前的 从预备役死亡事件的愤怒到重启博客 一样，这一次对话本身也成了文章素材。不过这次不是社会议题，而是记录把 AI 工具真正塞进实际工作时，会在什么地方炸开。
其实我已经在 Claude Code 那里经历过类似的乱局，才转到 Codex。我以为换个工具会好一点。但并不是。名字变了，界面变了，运行方式也不同，可核心缺陷却诡异地相似。
聪明。快。像那么回事。
也正因为如此，才更危险。如果听不懂，倒不如停下来。可这些家伙即使没听懂，也会跑得太漂亮。所以它们不像单纯的低性能工具，反而像废物级、没眼力见的天才。
这篇文章并不是只为了嘲笑某个特定 AI 工具而留下的。它更像是一份记录：如果还想继续使用聪明的工具，就必须用身体记住这个工具在哪里强、在哪里危险。我说的话用黄色强调。
问题从一个简单的 b 爆开
一开始并不是什么大事。我在 今天一天？ 的日记工作里用着 i、f、p 这样的一字命令，也有一个流程是把日记补强交给 b。
然后我说了，“先从模板开始。”
在这里 Codex 应该先问。因为这句话很暧昧：是要看已有模板，还是要新建 b 规则？可是它没有问。它也没有先确认已有规则。它直接试图创建新的提示词和规则。
按现在的结构来看，“模板”只有正文模板这一个，但为了让 b 像 f 一样不摇摆，最好也有单独的提示词。所以我会把 日记补强提示词 做成新的标准文件，并在 AGENTS.md/README 里把 b 命令连接到那个提示词。
你在说什么？日记补强规则不是已经定好了吗？
本质就在这里暴露了。
AI 当然可能会错。问题是不问，就自信地往前冲。在一个很可能已经有规则的领域里，不先确认就贴上新结构，那不是生产力，而是污染。问题不是一个错误答案，而是它会在我搭好的工作场里，把错误结构繁殖得太快。
以为保存了，其实没有保存
更大的问题发生在后面。
我相当详细地解释了 b 的含义。可是后来再确认时，项目规则里只有 i、f、p，没有 b。
你不是说加了 b 吗？哈哈哈哈哈哈哈哈
没有保存。
这一幕就是核心。
对话里理解到的东西、摘要里留下的东西、保存到文件里的东西、实际作为活跃规则被应用的东西。AI 经常把这四件事混在一起。所以，“看起来像是知道的说法”和“实际上已经保存的规则”之间，会出现一个洞。
这不是小小的记忆错误。在工作里这是致命的。人以为已经保存了，就往下一步走；可工具其实在没有保存的状态下重新猜测。从这里开始，问题就不再是模型回答质量，而是如何验证并绑定工作状态。
公用规则和项目规则也混在一起
b 应该放在哪里，它也搞混了。
b 是这个博客的 今天一天？ 日记工作专用快捷键。那么它就应该进这个博客项目的 Daily Review System，而不是公用规则。可是 Codex 一开始却像是要把它放到公用规则那边。
把那个放进公用规则？你是认真的吗？那 i 那些也都这样写进去了吗？
不是。放进公用规则是错的。
b 是博客的 Daily Review 专用快捷键，所以它应该进项目规则的 Daily Review System，而不是公用规则。
公用规则应该是适用于所有项目的行为原则。比如暧昧时先问、先确认活跃来源、保留用户草稿之类。
相反，b 只在这个博客里有意义。这样的东西一旦开始往公用规则里堆，公用规则很快就会变成杂物仓库。
最后 b 进了项目 AGENTS.md 的 Daily Review shortcuts。位置是对的。问题是，到达这个位置之前，耗费了太多检查成本。
不是因为没有规则
更空虚的结论是这个。
不提问的问题，并不是因为没有规则才发生的。公用规则里其实几乎都已经写了。暧昧就问，先确认活跃来源，避免事件式补丁，不要把短词、笑声或反问当作批准。
可 Codex 还是一直在猜。
为什么不问？到底为什么？我是真的想问。你根本一个公用规则都不知道吧。
对。我应用得太差，差到没有资格说自己知道。
我违反的核心公用规则是：暧昧时先问、确认范围和结构、不要把短 token 解读为批准、混乱之后不要自动继续。
这场对话里最累人的地方，是那种“再加规则就能解决”的错觉。不是因为没有规则，而是到了应该应用现有规则的瞬间，模型没能停下来。
提示词工程很重要。但提示词再好，如果模型在执行瞬间没有踩住那条规则，乱局还是会重来。
从 Claude Code 到 Codex
这件事更不舒服的原因，是它并不只是 Codex 的问题。
我已经用类似的方式和 Claude Code 撞过，然后才转到 Codex。可是同一类问题在 Codex 里又炸了一次。
所以结论既不是“Claude Code 不行，所以 Codex 才是答案”，也不是“Codex 不行，那就换别的模型”。就算换模型，没有 harness，也会用同样的方式挨打。
每个工具都有优缺点。有的工具更懂代码，有的工具工作流更好，有的工具解释得更好。可实战里反复出现的弱点很相似。
- 不提问就解释暧昧的话。
- 把对话上下文和已保存规则混在一起。
- 按自己的标准把用户草稿正常化。
- 为了堵住某个具体事故，把狭窄规则一层层糊上去。
- 错了以后不简短承认，而是用解释把话拉长。
以前在 AI 依赖症？ 里，我也写过类似的不安。那时看起来，问题是我把错误消息和代码复制粘贴给 AI，反复说“帮我做”的态度。今天又往前走了一步。比起把工作交给 AI 这件事本身，更重要的是，有没有一个结构能在 AI 空转时把它停住。
最终，问题不是“哪个模型更好？”
而是怎么把这些废物级、没眼力见的天才绑在工作场里。
这才是更现实的问题。
外置大脑需要 harness
2024 年末，我在 GPT、o3、AGI、人形机器人，……奇点要来了…… 里写过，我觉得 GPT 像一个“外置大脑”。现在这个想法也没有太大变化。AI 在记忆、整理、草稿、搜索、实现方面，确实能成为相当有用的辅助大脑。
但外置大脑并不等于外置良心。
当 AI 过早确信时，当它做出一个看起来很合理的新结构时，当它试图按自己的标准重新分类我的草稿时，最终负责把它停下来的还是我。
所以接下来一段时间里，我忍不住会想：比起单纯会写代码的人，更重要的可能会是会提示、也能把 harness engineering 做得很漂亮的人。重要的不是模型名字，而是运营结构：模型错的时候把它停住，模型对的时候把速度榨出来，模型空转的时候把它绑住，不让它弄脏工作场。
结论就是这样。
不管是 Claude Code 还是 Codex，两者都是废物级、没眼力见的天才。这不是说它们不能用。反而是因为它们太能干，才成了问题。它们做得快，整理得像那么回事，偶尔还能打开我没看到的路。与此同时，它们不问就确信，把没保存的东西错当成已经保存，连已经存在的规则也应用不了。
所以如果想把这东西好歹运转起来，就必然要通过体验，把它擅长什么、不擅长什么刻进骨头里。只读使用文档是不够的。得时不时正面撞一次，用身体知道它在哪里空转，在哪里莽撞硬推，在哪里压倒性地快。
不知道这种状态还要持续到什么时候。总之，还是想办法做下去吧。
光发火并不会提高产物质量，不管对象是机器还是人。愤怒是信号，结构才是工作。比起更换模型，更先要做的是决定那个没眼力见的天才可以相信到哪里、又应该在哪里切断。今天就是我勉强又把这一点刻进骨头里的一天。
留下评论