这里是对 Peter Steinberger 的文章《Shipping at Inference-Speed》（以推理速度交付）的详细分析。这篇文章发布于 2025 年 12 月 28 日，反映了作者在 GPT-5 和新一代 AI 编码代理（Codex）发布后的开发工作流变革。
摘要
本文详细阐述了作者 Peter Steinberger 在 2025 年下半年利用 AI 代理（特别是 GPT-5 和 Codex）彻底重塑软件开发流程的经验。核心观点在于，开发效率不再受限于手动编写代码的速度，而是受限于模型的“推理速度”（Inference Speed）和人的深度思考。
作者指出，自 2025 年 5 月以来，“Vibe Coding”（感觉流编程）已成常态。他不再逐行阅读代码，而是像监督流水线一样看着代码生成，仅关注架构和关键组件。他比较了 Codex 和 Claude Opus 的差异：Codex 擅长通过长时间的“静默阅读”来理解大型代码库并进行大规模重构，而 Opus 则更适合快速的小型修改。
文章还介绍了作者的“线性迭代”工作流：不依赖复杂的规划模式（Plan Mode）或版本回滚，而是通过持续对话、跨项目引用（让 AI 参考其他项目的代码）和视觉提示（截图）来推进项目。他在基础设施上采用了双 Mac 设备（MacBook Pro + Mac Studio）和 CLI 优先的策略，并分享了具体的 Codex 配置文件。最终，作者认为大多数软件开发并不需要复杂的思考，AI 已经能够胜任从 CLI 到完整 UI 的构建，开发者应专注于架构决策和系统设计。
内容精简
主题一：开发范式的根本转变——从“读写代码”到“监督推理”
在 2025 年末，软件开发发生了质的飞跃。作者将其描述为从“惊讶于 AI 能写代码”到“期望 AI 瞬间交付代码”的转变。这种模式被称为“以推理速度交付”（Shipping at Inference-Speed），意味着软件构建的速度瓶颈已经从人类的打字和思考速度，转移到了 AI 模型的生成速度（Inference Time）上。
核心变化：
- 不再阅读代码： 随着 GPT-5 的发布，作者对模型的信任度大幅提升。他坦言自己现在几乎不再阅读生成的每一行代码，而是“看着代码流过”，仅在关键节点检查架构设计和组件位置。这种“不读代码”的方式并没有导致失控，因为他对系统的整体设计了如指掌。
- CLI 优先原则： 绝大多数软件本质上是数据的搬运和展示。作者现在的构建流程通常从命令行界面（CLI）开始。因为 AI 代理可以极快地调用 CLI 并验证输出，从而形成一个自动化的闭环。
- 技术栈的选择： 现在的决策重点转移到了语言和生态系统的选择上。作者偏好 TypeScript（Web 开发）、Go（CLI 工具）和 Swift（macOS/iOS 开发）。特别是 Go 语言，由于其简单的类型系统和快速的 Lint 检查，非常适合 AI 代理编写。对于 iOS 开发，AI 已经可以直接处理构建过程，无需频繁打开 Xcode。
这种范式转变要求开发者具备更强的架构把控能力，能够像工厂经理一样，指挥 AI 代理完成繁重的工作，而不是亲自下场拧每一个螺丝。
主题二：模型战争与策略——Codex 的“深思”与 Opus 的“灵动”
作者深入对比了当时（2025 年底）两大主流模型：OpenAI 的 Codex（基于 GPT-5.2）和 Anthropic 的 Opus。
Codex 的特性：
- 静默阅读（Silent Reading）： Codex 的一个显著特征是它在开始写代码前会进行大量的阅读。它可能会花费 10 到 15 分钟静默地扫描代码库。虽然这有时令人焦急，但这种机制极大地提高了它在大型重构任务中的准确性。
- 适合大规模重构： Codex 能够一次性处理巨大的、跨越数小时的重构任务，并能修正旧模型留下的烂代码。它拥有极强的上下文管理能力，即使在长对话中也能保持高效。
- 告别“规划模式”： 随着模型能力的提升，旧时代的“Plan Mode”（先写计划再写代码）显得多余。作者现在直接与模型对话，探索代码，一旦满意就直接下令“构建”。
Opus 的特性：
- 急切与灵动： Opus 反应更快，非常适合小规模的编辑和快速修复。
- 局限性： 在处理大型功能或重构时，Opus 往往因为没有读完所有文件而遗漏细节，导致需要人工反复修正。
Oracle 工具的兴衰： 作者曾开发了一个名为“Oracle”的 CLI 工具，允许代理在卡住时调用 GPT-5 Pro 进行网络搜索和深度思考。然而，随着 GPT-5.2 的发布（知识库更新至 2025 年 8 月且能力更强），Oracle 的使用频率大幅下降，因为新模型通常能“一次通过”（One-shot）解决问题。
主题三：极简主义的线性工作流与上下文管理
作者的工作流强调迭代、直觉和上下文复用，摒弃了复杂的敏捷管理工具。
工作流细节：
- 多项目并行： 作者通常同时推进 3-8 个项目。利用 AI 处理“无聊”的代码（如数据搬运），让他能专注于核心逻辑。
- 线性迭代（Linear Evolution）： 他几乎不使用 Git 的分支或 Checkpoint 回滚。如果 AI 做错了，他会要求 AI 修改，而不是回滚版本。软件构建被视为“爬山”，允许绕路，但始终向前。
- 跨项目上下文复用： 这是一个巨大的效率提升点。作者经常指示 AI：“查看
../vibetunnel项目，并在本项目中通过类似方式实现 Changelog 功能”。AI 能够理解跨项目的上下文并完美迁移代码，这极大地节省了 Prompt 的编写时间。 - 文档驱动： 在每个项目中维护
docs/*.md，记录子系统设计。这不仅是给人看的，更是给 AI 看的。通过脚本强制模型在特定任务前阅读相关文档，能有效保持代码的一致性。 - 视觉提示（Visual Prompting）： 在 UI 调整中，直接截图并标注“修复间距”或“重新设计”，比文字描述高效得多。
上下文管理： GPT-5.2 允许超长会话而无需重启。作者发现 Codex 在长上下文中表现优异，甚至因为已经加载了大量文件而运行得更快。Codex 的内部思维似乎非常精简，节省了 Token，而 Opus 则相对啰嗦。
主题四：基础设施配置与自动化哲学
为了支撑“以推理速度交付”，作者构建了一套独特的基础设施。
硬件与远程开发：
- 双机联动： 使用 MacBook Pro 作为主显示终端，通过 Jump Desktop 连接到 Mac Studio。
- 任务分离： 耗时的后台任务、浏览器自动化测试等放在 Mac Studio 上运行，避免干扰主机的操作。这种设置还支持他在旅行时通过远程连接无缝继续工作，任务在 Mac Studio 上持续运行，不受笔记本合盖影响。
配置揭秘（config.toml）： 作者分享了他的 Codex 配置，核心设置包括：
model_reasoning_effort = "high"：始终使用高推理模式，不浪费时间在低智模型上。unified_exec = true：替代了旧的 tmux 脚本，提供统一的执行环境。tool_output_token_limit：设置为 25000，为上下文压缩留出空间。
自动化哲学：
- 即时 Bug 修复： 不使用 Issue Tracker。发现 Bug 立即 Prompt 修复，速度快于记录 Bug 的时间。
- 全自动化： 从域名注册到 DNS 修改，全部通过 AI 代理自动化完成。
- CLI 到 UI 的路径： 无论是开发 Chrome 扩展还是其他应用，先做核心 CLI，核心逻辑跑通后，AI 能在一天内生成完整的 UI 或扩展外壳。
问答
Q1: 作者提到的“以推理速度交付”（Shipping at Inference-Speed）是什么意思？ A: 意思是指软件开发的瓶颈不再是人的编码速度，而是 AI 模型的生成速度（推理时间）。开发者变成了监督者，看着代码像流水线一样生成。
Q2: 为什么作者现在几乎不阅读生成的代码？这安全吗？ A: 因为 GPT-5 级别的模型可靠性极高。作者通过通过整体架构设计和组件布局来把控质量，而不是逐行审查。只要系统设计正确，细节通常由 AI 准确处理。
Q3: Codex (GPT-5.2) 和 Opus 在作者的工作流中分别扮演什么角色？ A: Codex 用于大型重构和复杂功能开发，因为它会在写代码前“静默阅读”大量文件，理解全局；Opus 用于快速的小修改和日常计算机自动化任务，因为它反应更敏捷。
Q4: 作者如何在新项目中快速复用代码？
A: 通过跨项目引用路径（例如 ../other-project）。他指示 AI 参考已有的项目代码来实现新项目中的类似功能，AI 能自动理解并适配上下文。
Q5: 什么是“线性迭代”工作流？ A: 作者不使用分支（Branch）或回滚（Revert）。如果代码有问题，就让 AI 继续修改（Forward fix），像爬山一样不断修正方向往上走，而不是退回到起跑线。
Q6: 作者的硬件设置有何特殊之处？ A: 他使用两台 Mac。MacBook Pro 用于交互，Mac Studio 用于运行耗时的后台任务和 AI 代理，通过 Jump Desktop 远程连接。这样既保证了性能，又支持随时随地的远程开发。