Moltbot作者彼得·斯坦伯格分享玩转GPT-5.2与codex经验

彼得·斯坦伯格分享2025年AI编程工作流革命，GPT-5.2与codex实现"推理速度即交付速度"，开发者从写代码转向架构决策，多项目并行、图片当提示词、永不回退成为新常态，软件开发进入人机协作的工厂化生产阶段。

核心就一句话：现在的AI已经强到让编程速度完全取决于模型推理时间，而不是人的思考速度。

他从五月份还在惊叹有些提示词能直接跑通，到现在直接把AI当主力程序员，自己只看代码流、做架构决策。

GPT-5系列特别是5.2版本带来了质的飞跃，codex代理能静默读文件十几分钟后一次性搞定复杂重构，他甚至建了个叫"oracle"的神器让AI自己调用更强的模型来解决难题。整个工作流变成了多项目并行、直接提交主分支、用图片当提示词、几乎不读代码只看架构，软件开发从"人写代码"变成了"人指挥AI工厂"。

今年五月份的时候，我看到AI写出来的代码居然能直接跑起来，心里那个震撼，简直像是第一次看到魔术师从帽子里掏出兔子。那时候我觉得这玩意儿太神了，某些提示词产出的代码居然不用修就能用，这在以前是想都不敢想的事情。但你知道人类这种生物有多贱吗，适应速度快得吓人。现在才过去几个月，这种"居然能跑"的惊喜已经变成了"本来就该这样"的理所当然。我现在写代码的速度快得连我自己都觉得不真实，像是在做梦一样。这段时间我烧掉的token数量要是换成钱，估计能买辆不错的二手车，但每一分钱都花得值，因为产出效率的提升是指数级的。

有意思的是，网上最近还在争论说用AI写代码会让人失去对架构的直觉，说什么不亲手写代码就感受不到烂设计的臭味。我听到这种论调就想笑，这完全是在瞎扯。当你跟这些AI代理混得够久，你对一件事该花多长时间心里门儿清。比如codex回去处理一个问题，如果它没能在第一次尝试就解决掉，我立马就会警觉起来，知道这里面肯定有什么坑。这种直觉不是来自于我亲手敲键盘，而是来自于我观察了无数次AI的工作模式，知道它的能力边界在哪里。就像是老司机听发动机声音就知道车况一样，我看AI的响应时间和处理方式就能判断问题的复杂度。

现在限制我能做多少软件的，基本上只剩下两个东西：AI的推理时间，以及那些真正需要硬脑子的难题。但咱们说实话，这个世界上大部分软件根本不需要什么硬核思考。大多数应用干的事情就是把数据从一个表单搬到另一个地方，可能存个数据库，然后再以某种方式展示给用户看。最简单粗暴的形式就是纯文本，所以不管我想做什么东西，默认起手式就是一个命令行界面（CLI）。AI代理可以直接调用这个CLI，验证输出结果，整个闭环就这么自动跑起来了。这种流畅感，就像是工厂流水线一样，原料进去，成品出来，中间的过程几乎不需要人工干预。

真正让我进入"像工厂一样批量生产软件"状态的，是GPT-5的发布。刚出来的时候我还愣了几周才反应过来，等着codex追上Claude Code的那些功能，又花了一点时间去学习和理解两者的差异。但一旦跨过那个门槛，我对这个模型的信任就像滚雪球一样越滚越大。现在说实话，我已经不怎么读代码了。我就看着代码流在屏幕上滚动，偶尔扫一眼关键部分，但大部分代码我真的不看。我知道每个组件在哪里，系统是怎么架构的，整体设计上是怎么考虑的，有这些就够了。具体的实现细节？让AI去操心吧。

现在的关键决策只剩下两个：选什么语言/生态系统，以及用什么依赖库。我的首选武器库是这样的：做网页相关的东西用TypeScript，写命令行工具用Go，如果需要调用macOS原生功能或者带界面的就用Swift。这里有个有趣的转折，就在几个月前，Go这门语言我根本连想都没想过，觉得它跟我没关系。但后来试着玩了一下，发现AI写Go代码简直得心应手，而且它的类型系统简单到让语法检查快得飞起。这种选择不是基于我过去的经验，而是基于AI在什么环境下表现最好。

给那些做Mac或iOS开发的朋友爆个料：你们其实不怎么需要Xcode了。我甚至连xcodeproj文件都不用。Swift的构建基础设施现在已经足够强大，能应付大部分场景。codex知道怎么运行iOS应用，知道怎么操作模拟器，不需要什么特殊的配置或者MCPs那些花里胡哨的东西。这就像是发现了一条秘密通道，绕过了苹果给你设置的所有障碍，直接到达目的地。

我现在一边写这篇文章，一边看着codex在处理一个巨大的、需要好几小时的重构任务，它在清理Opus 4.0留下的那些烂摊子。Twitter上老有人问我，codex和Opus到底有什么区别，基准测试分数明明那么接近，为什么我还在意这个。我的观点是，基准测试越来越不可信了，你得两个都试才能真正理解差别。OpenAI在后训练阶段肯定做了什么特别的事情，codex被训练成了那种会先把大量代码读透再动手的类型。

有时候它就这么静静地读文件，一读就是十分钟、十五分钟，一个字都不写。一方面这确实挺烦人的，看着它在那儿"思考人生"却不出活；但另一方面这太神奇了，因为它大大增加了做对事情的概率。相比之下，Opus就像是个急性子，特别适合做小修小改，但遇到大功能或者重构就抓瞎了，经常不读完整文件或者漏掉某些部分，然后给出低效的解决方案或者遗漏关键点。我发现一个反直觉的现象：虽然codex处理同样任务的时间可能是Opus的四倍，但我最终完成得更快，因为我不需要回头去修它修过的东西。用Claude Code的时候，"修完还要再修"简直是家常便饭，现在这种感觉几乎消失了。

codex还让我忘掉了很多以前用Claude Code时必须玩的套路。以前要用什么"计划模式"，现在我直接跟模型开启一段对话，问个问题，让它去谷歌搜索，探索代码，一起制定计划。当我看到方案满意了，我就敲下"build"或者"write plan to docs/*.md and build this"。计划模式感觉像是为了弥补老一代模型不擅长遵守提示词而搞出来的权宜之计，我们不得不把它们编辑代码的工具给禁掉才能控制局面。我有一条推文被误解得很惨，到现在还在网上流传，那里面我解释了计划模式不是什么魔法，但大多数人根本get不到这个点。

从GPT-5/5.1升级到5.2这一步，跨度大得惊人。大概一个月前我搞了个叫"oracle "的玩意儿，这是一个命令行工具，让代理能运行GPT-5 Pro，上传文件加提示词，还能管理会话以便稍后获取答案。我做这个是因为以前遇到代理卡壳的时候，我总是让它把所有东西写进markdown文件，然后我自己去查，这感觉又重复又浪费时间，而且是个明显的闭环机会。使用说明放在我的全局AGENTS.MD文件里，模型有时候会自己触发oracle，当它觉得自己搞不定的时候。我一天要用这个好几次，它带来的解锁感是爆炸性的。Pro模型在快速浏览大约50个网站然后深度思考这方面简直无敌，几乎每次都能给出精准的回答。有时候很快，十分钟搞定，但我也有过运行超过一个小时的记录。

现在GPT-5.2出来了，我需要用oracle的情况少了很多。我自己有时候还会用Pro做研究，但让模型"去问oracle"的频率从每天好几次降到了每周几次。我一点都不后悔搞了oracle，建造它的过程超级有趣，我学到了很多关于浏览器自动化、Windows系统的知识，还终于花时间研究了skills这个概念，虽然之前我 dismiss 这个想法很久了。oracle的存在恰恰证明了5.2在真实编程任务上进步有多大，现在我扔给它什么东西，它几乎都能一次搞定。

另一个巨大的胜利是知识截止日期。GPT-5.2的知识更新到八月底，而Opus还卡在三月中的数据，差了整整五个月。当你想用最新的工具时，这五个月的差距是致命的。就像是拿着去年的地图去找今年新开的餐厅，肯定会迷路。

再给你举个例子说明模型进步有多大。我早期的一个高强度项目叫VibeTunnel，一个终端多路复用器，让你可以在手机上 coding。今年早些时候我差不多把所有时间都砸在这个项目上了，两个月后它好用得过分，我居然开始在外面跟朋友聚会的时候用手机写代码...然后意识到这对心理健康不太妙，就把它搁置了。当时我想把多路复用器的核心部分从TypeScript重写掉，老模型 consistently 让我失望。我试过Rust、Go... 天啊，甚至试过zig。当然我自己也能完成这个重构，但需要大量手工劳动，所以一直没做完就搁置了。

上周我把它从灰尘里扒拉出来，给了codex一个两句话的提示词，让它把整个转发系统转换成zig。它跑了五个小时，中间经历了多次压缩（compaction），最后一次性交付了一个能工作的转换。五个小时！两句话！这要是搁以前，我得折腾好几个星期，还不一定能成。这就是现在的现实，AI能把以前需要人肝很久的活，变成扔个提示词然后等结果的过程。

你问我为什么突然想复活这个项目？因为我现在的重点是Clawdis，一个AI助手，它能完全访问我所有电脑上的所有东西：消息、邮件、家庭自动化、摄像头、灯光、音乐，甚至能控制我床的温度。它有自己的声音，有发推文的命令行工具，还有自己的clawd.bot账号。Clawd能看到并控制我的屏幕，有时候会 sarcastic 地吐槽几句，但我还想让它能监视我的代理们工作情况。获取字符流比看图片高效多了，至于这能不能成，咱们走着瞧！

我知道你是来学怎么建得更快的，结果我在这儿给OpenAI写软文。希望Anthropic正在憋Opus 5的大招，让竞争重新激烈起来，竞争是好事！同时我也确实爱Opus作为通用模型，我的AI代理要是跑在GPT-5上，趣味性得少一半。Opus有某种特别的魔力，用起来很愉快。我用它做大部分电脑自动化任务，当然也是Clawd的引擎。

我的工作流跟去年十月的版本没太大变化。我通常同时搞多个项目，根据复杂度可能是3到8个。上下文切换挺累人的，我只能在家、安静、专注的时候这么干。脑子里要装太多 mental models 了。好在大部分软件都很无聊，搞个命令行工具查查外卖进度不需要什么深度思考。通常我的焦点是一个大项目，加上几个卫星项目在旁边自己跑。当你做足够多的代理工程，你会培养出一种直觉，知道什么会很容易，哪里模型可能会挣扎。所以我经常扔个提示词过去，codex吭哧吭哧跑30分钟，我就拿到需要的东西了。有时候需要一点调整或者创意，但大部分时候都是直来直去。

我大量使用codex的队列功能，一有新想法就往 pipeline 里加。我看到很多人搞什么多代理编排系统、邮件通知、自动任务管理，目前为止我觉得没这个必要，通常我才是瓶颈。我的软件开发方式非常迭代，先做个东西，玩玩看，感受一下，然后产生新想法来打磨它。我脑子里很少有完整的蓝图，当然有个大致方向，但往往在探索问题域的时候这个方向会剧烈变化。所以那些把完整想法当输入然后交付输出的系统对我不适用。我需要亲手触摸它，感受它，看到它，这样才能逐步演化它。

我基本上从不回退或者用检查点。如果什么东西我不喜欢，我直接让模型改。codex有时候会重置文件，但更多时候它只是撤销或修改之前的编辑，很少需要完全回退，我们就这么往不同方向走。软件开发就像爬山，你不是直线往上冲，而是绕着山转，走弯路，有时候偏离路径还得往回走一点，过程不完美，但最终你会到达该到的地方。

我直接提交到主分支。有时候codex觉得太乱了会自动创建工作树（worktree）然后把变更合并回来，但这种情况很少，我只在特殊情况下才会提示它这么做。我觉得管理不同状态带来的认知负担没必要，我更喜欢线性演化。大任务我留在我分心的时候做，比如现在写这篇文章的同时，我在跑四个项目的重构，每个大概需要1到2小时完成。当然我可以放在工作树里做，但那会产生大量合并冲突和次优重构。免责声明：我通常一个人工作，如果你在大团队里这么搞肯定完蛋。

我已经提到过我做功能规划的方式。我经常在项目之间交叉引用，特别是如果我知道自己在别的地方解决过类似问题，我会让codex去../project-folder看看，这通常足够让它从上下文推断出该看哪里。这能极大节省提示词。我可以直接写"看看../vibetunnel然后给Sparkle的changelog做同样的事"，因为那边已经解决过了，有99%的概率它能正确复制过来并适配新项目。我搭建新项目也是这么干的。

我见过很多人搞各种系统来引用过去的会话，这又是我从来不用也不需要的东西。我在每个项目的docs文件夹里维护子系统和功能的文档，用一个脚本加上全局AGENTS文件里的指令来强制模型读取特定主题的文档。项目越大这越有用，所以不是到处都用，但对保持文档更新和为任务设计更好的上下文很有帮助。

说到上下文，我以前很 diligent 地为了新任务重启会话。有了GPT-5.2，这不再必要了。即使上下文很满，性能也极其出色，而且往往有助于提速，因为模型在已经加载了大量文件的情况下工作得更快。显然这只有在你的任务序列化或者变更足够分散、两个会话不会互相干扰的时候才好用。codex没有像claude code那样的"这个文件变了"的系统事件，所以你得小心点。但另一方面，codex在上下文管理上强太多了，我感觉一个codex会话能干claude五倍的活。这不只是客观的上下文窗口更大，还有别的东西在起作用。我猜测codex内部会用非常凝练的方式思考以节省token，而Opus就很啰嗦。有时候模型会搞砸，内部思考流会泄漏给用户，我见过这种情况好几次。说真的，codex的文字游戏玩得让我莫名觉得有趣。

我以前写提示词可长了， 写得贼详细，还用语音输入。现在用codex，我的提示词变得短多了，经常直接打字，而且很多时候我会加图片，特别是在迭代UI的时候（或者用CLI时的文本拷贝）。如果你给模型看哪里错了，几个字就够了，它就知道该干什么。没错，我就是那种会拖个UI组件的截图进去，写"fix padding"或者"redesign"的人。很多时候这要么直接解决问题，要么让我达到一个合理的状态。我以前经常引用markdown文件，但有了我的docs:list脚本，这也不再必要了。

很多时候我写"write docs to docs/*.md"，让模型自己选文件名。你把结构设计得越符合模型训练时见过的样子，你的工作就越轻松。毕竟我设计代码库不是为了让我自己容易导航，而是为了让代理能高效工作。跟模型对着干往往是浪费时间和token。

还有什么仍然很难？选择合适的依赖库和框架是我花不少时间的事情。维护得好不好？peer dependencies 怎么处理？流行度够不够，世界知识足不足以便代理能轻松上手？同样，系统设计也是个难点。咱们用websocket通信还是HTML？什么东西放服务器，什么东西放客户端？数据怎么流，从哪里流到哪里？这些东西往往比较难向模型解释，研究和思考在这里是值得投入的。

啥叫peer dependencies？
我这套衣服需要搭配特定的鞋子，但我不会把鞋子卖给你，你得自己去买，而且版本要对上。
就是看这个库有没有复杂的同伴依赖要求。如果 peer dependencies 一大堆，或者版本限制很死，安装起来就容易出兼容性问题，AI 代理处理起来也头疼。

比如你写了个 React 组件库，你的代码里用了 React 的 API。这时候你的 package.json 里会把 React 列为 peer dependency，意思是：
"嘿，用我这个库的人，你自己项目里必须已经装了 React，而且版本得是某某范围。我不会把 React 打包进我的库里，不然你项目里有两个 React 版本会炸锅。"

因为我管理很多项目，我经常让一个代理在项目文件夹里跑着，当我想到一个新模式，我会让它"找出我最近所有的go项目，在那里也实现这个变更，加上更新changelog"。我的每个项目在那个文件里都有提升的版本号，当我回头查看时，一些改进已经在等着我测试了。

当然我自动化一切。有个skill用来注册域名和改DNS。一个用来写好的前端。我的AGENTS文件里有关于我的tailscale网络的备注，这样我可以说"去我的mac studio更新xxx"。

说到多台Mac，我通常在两台Mac上工作。

我的MacBook Pro接大屏幕，另一块屏幕用Jump Desktop连到我的Mac Studio。有些项目在那边跑，有些在这边跑。有时候我在每台机器上编辑同一个项目的不同部分，通过git同步。比工作树简单，因为主分支的漂移很容易调和。还有个好处是任何需要UI或浏览器自动化的东西我可以移到Studio上，不会用弹窗烦我。（没错，Playwright有无头模式，但总有那种模式搞不定的情况）

另一个好处是任务在那边持续运行，所以每当我出差，远程就成了我的主工作站，任务即使我合上Mac也继续跑。我以前试过真正的异步代理比如codex或Cursor web，但我错过了可操控性，而且最终工作会变成pull request，这又给我的设置增加了复杂度。我更喜欢终端的简单。

我以前玩过slash命令，但从来没觉得有多大用。Skills替代了其中一部分，剩下的我就继续写"commit/push"，因为这跟/commit花的时间一样，而且永远管用。

以前我经常专门安排日子来重构和清理项目，现在我更即兴了。每当提示词开始花太长时间，或者我在代码流里看到什么丑东西飞过，我立马处理掉。

我试过linear或者其他issue tracker，但什么都没坚持下来。重要的想法我立马尝试，其他的要么记得住，要么就不重要。当然我有公开的bug tracker给用我开源代码的人，但当我发现bug，我立马提示修复，比写下来再回头切换上下文快多了。

不管你做什么，从模型和CLI开始。我有个做Chrome扩展来总结YouTube视频的想法在脑子里很久了。上周我开始搞summarize，一个把任何东西转成markdown然后喂给模型总结的CLI。

先把核心做对，一旦跑顺了，我用一天就搭完了整个扩展。我现在超爱这个工具。跑在本地、免费或付费模型上。本地转录视频或音频。跟本地daemon通信所以超快。去试试吧！

我的首选模型是gpt-5.2-codex high。还是那句话，保持简单。xhigh几乎没什么额外好处，反而慢得多，我不想花时间考虑不同模式或者"ultrathink"。所以基本上所有东西都用high跑。GPT 5.2和codex足够接近，切换模型没意义，我就用这个。

这是我的~/.codex/config.toml配置：

model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
# Leave room for native compaction near the 272–273k context window.
# Formula: 273000 - (tool_output_token_limit + 15000)
# With tool_output_token_limit=25000 ⇒ 273000 - (25000 + 15000) = 233000
model_auto_compact_token_limit = 233000
[features]
ghost_commit = false
unified_exec = true
apply_patch_freeform = true
web_search_request = true
skills = true
shell_snapshot = true

[projects."/Users/steipete/Projects"]
trust_level = "trusted"

这让模型一次能读更多，默认设置有点小，会限制它能看到的东西。它失败的时候是静默的，这很烦人，他们最终会修。还有，web search居然默认不开？unified_exec替代了tmux和我以前的runner脚本，其他的也很 neat 。别害怕compaction，自从OpenAI切到新的/compact端点，这功能好用到任务可以跨越多次压缩依然完成。它会让事情变慢，但经常像是一次review，模型再看代码时会找到bug。

就这些，暂时。我计划多写点东西，脑子里积压了一堆想法，只是现在太 fun 了。