《Shipping at Inference-Speed》当AI编程速度成为唯一瓶颈：一位开发者的工作流进化七个月前，我还在惊叹于"有些提示词能直接生成可用代码"。如今，这已是我的基本预期。代码产出速度快到不真实。有人说用AI编程会让人与代码架构脱节，我完全不同意。当你与AI代理相处足够久，你会精确感知一个任务该花多长时间。当Codex没能一次搞定时，我立刻就会起疑。现在，我的软件产出主要受限于两件事：推理时间和深度思考。坦白说，大多数软件不需要深度思考——无非是把数据从一个表单搬到另一个，存储，展示。所以我的项目默认从CLI开始，AI可以直接调用并验证输出，形成闭环。+ 关于模型选择真正的转折点是GPT 5。花了几周适应后，我开始越来越信任它。现在我几乎不怎么读代码了。我看着代码流滚动，偶尔关注关键部分，但大部分代码我不读。我只需要知道组件在哪、结构如何、系统怎么设计——这就够了。现在最重要的决策是语言生态和依赖选择。我的首选：TypeScript做Web，Go写CLI，Swift处理macOS相关或UI。几个月前我对Go毫无兴趣，但发现AI写Go特别顺手，简单的类型系统让lint飞快。给Mac/iOS开发者：你不太需要Xcode了。Swift的构建基础设施已经足够好。Codex知道怎么运行iOS应用、怎么操作模拟器，不需要特殊配置或MCP。+ Codex vs Opus的本质差异基准测试越来越难以信任，必须亲自体验才能理解差异。OpenAI在后训练上做了什么我不清楚，但Codex被训练成在动手前会阅读大量代码。有时它会静默读文件10到15分钟才开始写代码。一方面让人着急，另一方面这大大提高了修对东西的概率。Opus则更急切——小改动很棒，大功能或重构就容易漏读文件、产出低效方案。虽然Codex有时比Opus慢4倍，但我整体更快，因为不用反复修复"修复"——这在用Claude Code时太常见了。Codex还让我卸下了很多Claude Code时代的仪式感。不再需要"计划模式"，我直接和模型对话，问问题，让它搜索、探索代码、一起制定计划，满意后写"build"或"把计划写到docs/*.md然后构建"。计划模式像是为老一代不善遵循提示的模型设计的hack——我们不得不拿走它们的编辑工具。+ Oracle：让AI求助更强AI从GPT 5/5.1到5.2是巨大飞跃。一个月前我构建了oracle——一个CLI，让AI代理能调用GPT 5 Pro，上传文件和提示词，管理会话以便稍后获取答案。以前AI卡住时，我让它把所有内容写进markdown，然后自己去查询——这是重复劳动，也是闭环的机会。现在指令写在我的全局AGENTS.MD里，模型卡住时会自动触发oracle。Pro在快速浏览50个网站后深度思考，几乎每次都能给出精准答案。有时10分钟，有时超过1小时。GPT 5.2出来后，需要oracle的场景从每天多次降到每周几次。这说明5.2在实际编码任务上进步了多少——它几乎能一次搞定我扔给它的任何东西。另一个巨大优势是知识截止日期。GPT 5.2到8月底，Opus停在3月中旬——差了5个月。当你想用最新工具时，这很关键。+ 一个具体例子VibeTunnel是我早期的密集项目，一个终端复用器，让你能随时随地编程。投入两个月后，它好到我发现自己在和朋友出去时还在用手机写代码——然后决定该停下来，更多是为了心理健康。当时我想把核心部分从TypeScript重写，老模型一直让我失望。试过Rust、Go，甚至zig。当然我能完成这个重构，但需要大量手工，所以一直没完成。上周我重新拿起它，给Codex一个两句话的提示，让它把整个转发系统转成zig。它跑了5小时多，经历多次压缩，一次交付了可用的转换。+ 我的工作流我通常同时做3到8个项目。上下文切换很累，只有在家、安静、专注时才能做到。幸运的是大多数软件很无聊。创建一个查外卖进度的CLI不需要太多思考。通常我专注一个大项目，卫星项目在旁边慢慢推进。我大量使用Codex的队列功能——有新想法就加进去。很多人在试验多代理编排、邮件或自动任务管理——我目前不需要这些，通常我才是瓶颈。我的方法非常迭代：构建、把玩、感受，然后产生新想法去精炼。我脑中很少有完整图景，需要触摸它、看到它，才能进化它。我基本从不回滚或用检查点。不喜欢就让模型改。构建软件像爬山——你不会直线上升，而是绕着它转弯，有时走错路要退回一点，不完美，但最终会到达目的地。我直接提交到main。有时Codex觉得太乱会自动创建worktree再合并回来，但很少。我发现思考不同状态的认知负担没必要，更喜欢线性演进。当然，如果你在大团队工作，这套流程显然行不通。我经常跨项目引用，特别是知道某处已经解决过某问题时，让Codex看../project-folder就够了。这极大节省提示词。我可以写"看看../vibetunnel，对Sparkle changelog做同样的事"，99%的概率它会正确复制并适配新项目。我在每个项目的docs文件夹维护子系统和功能文档，用脚本和全局AGENTS文件里的指令强制模型读取特定主题的文档。项目越大，这越有价值。关于上下文：我以前很勤快地为新任务重启会话。用GPT 5.2后不再需要了。即使上下文更满，性能依然极好，而且模型加载了很多文件后工作更快。Codex的上下文管理远超Claude，我感觉一个Codex会话能完成5倍于Claude的工作。这不只是客观上更大的上下文窗口，还有其他因素。我猜Codex内部思考非常精简以节省token，而Opus很啰嗦。提示词方面，我以前用语音输入写长而精细的提示。用Codex后，提示词变短了很多，我又开始打字了，经常附上图片，特别是迭代UI时。给模型看哪里错了，几个字就够让它做你想要的。是的，我就是那个拖进一张UI组件截图写"fix padding"或"redesign"的人。+ 工具与基础设施什么仍然困难？选择正确的依赖和框架需要投入时间。维护得好吗？peer dependencies怎样？够流行吗——这样AI才有足够的世界知识？同样，系统设计：用websocket还是HTML通信？什么放服务端什么放客户端？数据怎么流动？这些更难向模型解释，研究和思考会有回报。我管理很多项目，经常让AI在项目文件夹里跑，发现新模式时让它"找到我所有最近的go项目，实施这个改动并更新changelog"。每个项目的changelog里都有递增的补丁版本，当我回来时，一些改进已经等着我测试了。当然我自动化一切。有注册域名和改DNS的skill，有写好前端的skill。AGENTS文件里有关于我tailscale网络的笔记，所以我可以说"去我的mac studio更新xxx"。我通常在两台Mac上工作。MacBook Pro接大屏，Jump Desktop连到Mac Studio在另一个屏幕。有些项目在这边煮，有些在那边。有时我在两台机器上编辑同一项目的不同部分，通过git同步。比worktree简单，因为main上的漂移容易调和。额外好处是需要UI或浏览器自动化的任务可以移到Studio，不会用弹窗烦我。另一个好处是任务在那边持续运行，所以无论我去哪，远程成为主工作站，即使我合上Mac任务也继续跑。我试过真正的异步代理如Codex或Cursor web，但我怀念可操控性，最终工作变成PR，又增加了复杂性。我更喜欢终端的简单。我以前常安排专门的日子重构和清理项目，现在更即兴了。每当提示开始变慢或看到丑陋代码飘过，我立刻处理。我试过linear或其他issue tracker，但没坚持下来。重要想法我立刻尝试，其他的要么记得要么不重要。当然我有公开bug tracker给用开源代码的人，但我发现bug时会立刻提示——比写下来再切换上下文快得多。无论你构建什么，先从模型和CLI开始。我脑中有个Chrome扩展总结YouTube视频的想法很久了。上周我开始做summarize，一个把任何东西转成markdown再喂给模型总结的CLI。先把核心做对，然后一天内构建了整个扩展。它在本地、免费或付费模型上运行，本地转录视频或音频，和本地daemon通信所以超快。我的默认模型是gpt-5.2-codex high。KISS原则。xhigh除了慢得多几乎没什么好处，我不想花时间想不同模式或"ultrathink"。所以几乎所有东西都跑在high上。+ 一些感悟我为代理设计代码库，而不是为自己。让结构对模型训练数据来说显而易见，你的工作就会更轻松。与模型对抗往往是浪费时间和token。很多时候我写"把文档写到docs/*.md"，让模型自己选文件名。我不是为了方便自己导航而设计代码库，而是为了让代理能高效工作。Opus作为通用模型我依然喜爱。我的AI代理如果跑在GPT 5上，乐趣会减半。Opus有某种特质让它用起来很愉快。我用它处理大部分电脑自动化任务。希望Anthropic正在烹饪Opus 5，让风向再次转变。竞争是好事。x.com/steipete/status/2005393881395835045