【转载解读】以LLM推理的速度交付软件
《以LLM推理的速度交付软件》深度解读
一、文章概览
1.1 作者背景
Peter Steinberger（网名 steipete）是 iOS 开发领域的知名人物。他于 2011 年创立了 PSPDFKit ——一家专注于 PDF 处理 SDK 的技术公司，从零开始 bootstrapped（自筹资金）运营十年，于 2021 年成功退出（该公司后获得 1.16 亿美元融资）。此前他曾在旧金山担任高级 iOS 工程师，是活跃的开源社区贡献者和技术会议演讲者，常居维也纳与伦敦之间。
退出 PSPDFKit 后，Steinberger 全面转向 AI 原生开发，成为 2025 年"代理工程"（Agentic Engineering）实践中最具影响力的个人开发者之一。他在一个月内创造了超过 6,600 次 git 提交的记录，其 AI 代理项目 Clawdis 在 GitHub 上的增长速度一度超过 Tailwind CSS。
1.2 一句话总结
一个拥有 15 年深厚工程经验的资深开发者，用 3 个月花费 5.1 万美元 API 费用，探索出一套"以 AI 推理速度发布软件"的极限工作流——他几乎不再阅读 AI 生成的代码，而是将注意力完全转向架构设计和系统验证。
1.3 写作背景
这篇长文写于 2025 年 12 月底，距离 GPT-5 发布约半年、GPT-5.2 发布不久。作者自述，2025 年 5 月他还在惊叹于"提示词能生成可工作的代码"，到年底这已成为基线期望。整篇文章是对自身半年极限实践的复盘——不是理论推演，而是大量一手工程经验的提炼。
二、核心内容解读
2.1 关键观点拆解
观点一：推理速度即发布速度
Steinberger 提出的核心命题是：“我能创造的软件数量，现在主要受限于推理时间和深度思考。”
他的论据是：大多数应用程序本质上是数据在表单、存储和展示之间的流转，这类任务的架构复杂度有限。当 AI 模型能够可靠地完成编码执行， 人类的产出瓶颈就从"写代码"转移到了"等待模型推理"和"做架构决策" 。这就是标题"以推理速度发布"的含义——你的发布节奏与模型的推理速度挂钩。
观点二：模型转变——GPT-5 的关键解锁
作者将 GPT-5 视为"工厂级构建"（factory-scale building）的转折点。在此之前，模型在大型重构任务中表现不稳定；GPT-5 之后，他的工作方式发生根本变化：
“如今我不再逐行阅读代码，而是观察输出流，偶尔关注关键部分。”
他的注意力从代码细节转向系统级关切：整体架构、组件关系、结构设计。这是一个从"程序员"到"架构师+AI 指挥者"的角色跃迁。
观点三：“不再阅读代码"的工作模式
这是文章中最具争议的观点。Steinberger 声称他发布了大量自己从未完整阅读过的 AI 生成代码。他对此的辩护逻辑是：
- 大量的代理交互建立了直觉 ——他能凭经验判断一个任务应该耗时多久，当模型卡住时能立即察觉
- CLI 优先策略 ——所有项目先做命令行工具，这样代理可以直接运行并验证输出，形成闭环测试
- 代码不是目标，工作的功能才是 ——他关注的是功能是否正确运行，而非代码本身是否优雅
观点四：Codex vs Opus 实战对比
这是文章中极具参考价值的一线对比：
| 维度 | OpenAI Codex | Claude Opus |
|---|---|---|
| 大型重构 | 显著优于 Opus | 容易丢失上下文，需要后续修正 |
| 工作模式 | 默默阅读文件 10-15 分钟后才开始写代码 | 优先追求速度，快速输出 |
| 小型编辑 | 可胜任但非优势 | 表现出色，速度快 |
| 耗时 | 有时需要 4 倍时间 | 快速但可能需要返工 |
| 知识时效 | GPT 5.2 知识截止至 8 月 | Opus 截止至 3 月中旬（差距 5 个月） |
| 上下文管理 | 内部 token 节省机制更好 | 输出较为冗长 |
关键洞察：Codex 的"慢即是快”——它花更多时间理解代码全貌，从而在大任务上实现"一次成功"（one-shot），避免了反复修改的循环。
观点五：Oracle——用 AI 研究辅助 AI 编码
Oracle 是 Steinberger 开发的专用 CLI 工具，它调用 GPT-5 Pro 进行深度研究任务。当编码代理在某个技术问题上卡住时，Oracle 会被自动触发：
- 能快速扫描 50 个网站
- 单次分析可以超过一小时
- 以高置信度回答大多数技术问题
他将研究指令写在全局 AGENTS.MD 文件中，模型在需要时自行调用 Oracle。这种"AI 辅助 AI"的分层架构，是他工作流中的独特设计。
观点六：Clawdis——全系统 AI 代理愿景
Clawdis 是 Steinberger 当前的主力项目，代表了他对"无处不在的 AI 助手"的构想。这个代理拥有对多台计算机的完整系统访问权限：
- 通讯 ：iMessage、Email
- 智能家居 ：灯光（OpenHue）、摄像头（Camsnap）、温控（床温控制 Eightctl）
- 娱乐 ：音乐（Sonoscli）、社交媒体（自定义推文 CLI）
- 系统控制 ：屏幕操控（Peekaboo）、语音交互
Clawdis 甚至有自己的"人格"（clawd.bot），会在监控其他代理时发出"刻薄评论"。这已超出编码工具的范畴，更像是一个具有个性的通用 AI 管家。
2.2 工作流架构深度解析
多项目并行管理
Steinberger 同时管理 3-8 个项目。典型模式是：一个主力项目集中攻坚，其余项目由 AI 代理自主推进。开发节奏为：发送初始提示 → 30 分钟处理阶段 → 迭代优化，多个项目交替进行。
队列化异步流水线
大量使用 Codex 的队列功能（queueing），批量发送提示后异步处理。他没有采用复杂的多代理编排系统（multi-agent orchestration），而是选择了更简单的迭代式探索模式。
他用登山做比喻：
“构建软件就像爬山。你不会直线上升，而是盘旋而上，有时走偏了需要折返。过程不完美，但终究能到达目的地。”
版本控制策略
- 从不回滚代码 ，而是让模型在当前基础上修改
- 直接提交到 main 分支 ，不使用分支管理（因为单人开发）
- 大型重构在注意力分散时（如写文章期间）后台运行，每次 1-2 小时
提示词工程的演进
随着模型能力提升，提示词反而越来越短。语音输入逐渐替代打字，图片辅助文字描述（尤其在 UI 迭代中）。不再手动引用文档文件，而是通过自定义脚本 docs:list 自动注入文档上下文。
文档与上下文管理
- 在项目
docs/目录下维护子系统和功能文档 AGENTS.MD文件包含全局代理指令- 文档结构优先考虑 代理导航效率 而非人类阅读体验——这是一个值得注意的范式转变
- GPT 5.2 之后，他不再为每个任务重启会话，而是保持长会话持续运行，利用
/compact端点进行上下文压缩
Codex 配置参考
model = "gpt-5.2-codex"
model_reasoning_effort = "high"
tool_output_token_limit = 25000
model_auto_compact_token_limit = 233000 # 273000 - (25000 + 15000)
[features]
ghost_commit = false
unified_exec = true # 替代 tmux 和自定义运行脚本
apply_patch_freeform = true
web_search_request = true # 非默认但很有用
skills = true
shell_snapshot = true核心配置思路：提高 tool_output_token_limit （默认值过低，会导致模型看不到完整文件而静默失败）；开启 unified_exec 统一执行环境；启用 web 搜索能力。
三、深度搜索研究与分析
3.1 社区反馈全景
Hacker News 核心争议
文章在 Hacker News 上引发了激烈讨论，观点明显分为两派：
支持派论点：
- 成本效率 ：用户 gwern 指出，3 个月 5.1 万美元的成本低于一个初级开发者的全额薪酬，关键在于产出密度
- 行业变革信号 ：用户 jeswin 认为文章揭示的是行业级变革——花 1,500 美元用 AI 构建一个 TypeScript 编译器，在以前需要一年且完成度更低
- 实际节省验证 ：用户 CurleighBraces 报告用 Vibe Coding 构建了替代 Duolingo、热量追踪等多个工具，2 个月仅花费 $3 API 成本
批判派论点：
- “AI 心理症"质疑 ：用户 causal 注意到作者在朋友聚会时也在手机上编码，将其比作老虎机——“拉杆看结果很有趣，但判断真正需要什么这个核心难题变得更难了”
- 产出质疑 ：用户 rocmcd 援引费曼的警告——“最容易被欺骗的人就是你自己”，质疑花了 5 万多美元却看不到明确的产出成果
- 环境成本 ：用户 ossa-ma 估算这些 API 调用消耗的能量相当于 450 个美国家庭一年的用电量
实务派洞察：
- 用户 elevation 指出真正的加速点在于：将原本需要数天的重复性工作缩短至 15 分钟
- 用户 svantana 提出关键反思：“原型用 4 小时还是 24 小时做出来，真的那么重要吗？真正有价值的是经过深思熟虑、高度打磨的应用，那仍然需要以人年计算”
- Steinberger 本人在 X 上公开分享了这篇文章，引发广泛讨论
- 访谈总结 强调他使用的是"代理工程”（Agentic Engineering）而非简单的 Vibe Coding——多代理并行 + 闭环测试验证
- 分析帖 将其视为"AI 改变执行瓶颈"的标志性案例——个人杠杆被极大放大，创业变得更加意愿驱动
3.2 批判性视角
代码质量与可维护性风险
多项研究为"不阅读代码"的做法提供了警示数据：
- CodeRabbit 报告 ：AI 生成代码出现问题的概率是人工代码的 1.7 倍 ，且高严重度问题占比更高 (来源)
- SonarSource 分析 ：AI 加速的代码库中，代码质量下降几乎不可避免，技术债务（Technical Debt，即为了短期速度而积累的长期维护成本）以更快的速度增长 (来源)
- Forbes 警告 ：快速 AI 代码生成正在引发"安全风险海啸"——AI 会复制训练数据中的已知漏洞 (来源)
- 学术研究 (arXiv) ：LLM 代理显著加速开发，但同时导致代码质量明显下降，引发长期维护风险 (来源)
“验证转移"理论
Frédéric Pattyn 在 The Vibe Coding Trap 中提出了一个深刻的洞察：
AI 编码的根本风险不是"更多 bug”，而是 返工从代码层转移到了隐性的监督和验证层 。
具体表现为：
- 监督成为新瓶颈 ：AI 加速了生产，人工审查成为制约因素
- 错误跨层复合 ：AI 产生的错误不是简单累积，而是在架构层级间"传染和放大"，比传统 bug 更难检测、修复成本更高
- 第一轮完成度的欺骗性 ：AI 输出看起来很完整，表面的"光鲜"掩盖了底层的脆弱性
3.3 平衡观点
将 Steinberger 的实践放在更广阔的背景下，需要看到几个前提条件：
作者的独特优势（不可忽视）：
- 15 年 iOS 开发和公司运营经验——他不是在"盲目信任 AI"，而是凭借深厚经验进行判断
- 个人项目而非团队协作——没有代码审查、合并冲突、知识共享等团队约束
- 全部为新项目——不涉及维护遗留代码库的复杂性
- 高风险容忍度——作为独立开发者，bug 的业务影响有限
速度红利的真实边界：
- 对数据流转型应用（CRUD、CLI 工具、自动化脚本）效果显著
- 对需要深度领域知识、安全关键型、高性能计算的场景，速度红利递减
- “原型速度"与"产品质量"之间仍存在鸿沟
四、扩展内容
4.1 概念演进：Vibe Coding → Agentic Coding → Context Engineering
2025 年 AI 辅助编程领域经历了快速的概念演进：
Vibe Coding (2025 初)
│ 由 Andrej Karpathy 提出
│ 核心理念：用自然语言描述"感觉"，AI 直接生成代码
│ 特点：低控制度、创意优先、适合原型
│
├─→ Agentic Coding (2025 中)
│ 核心理念：AI 代理自主完成子任务，人类做架构决策
│ 特点：闭环验证、多代理协作、任务队列化
│ 代表人物：Peter Steinberger
│
└─→ Context Engineering (2025 末)
MIT Technology Review 定义的新范式
核心理念：精确设计和管理 AI 的输入上下文
特点：结构化提示、文档驱动、可复现性
重点从"怎么让 AI 写代码"转向"怎么给 AI 正确的信息"Steinberger 的实践恰好处于 Agentic Coding 到 Context Engineering 的过渡地带——他的 AGENTS.MD 、 docs/ 目录体系、自定义文档注入脚本，本质上都是上下文工程的实践。
4.2 行业趋势对照
2025 AI 编程工具生态
| 类别 | 代表工具 | 定位 |
|---|---|---|
| IDE 集成 | Cursor, GitHub Copilot, Windsurf | 代码补全 → 代理模式演进 |
| 独立代理 | OpenAI Codex CLI, Claude Code | 终端级自主编码代理 |
| 一键部署 | Bolt.new, v0, Lovable | 从描述到完整应用 |
| 多模型编排 | 自定义方案（如 Steinberger） | 根据任务类型路由不同模型 |
模型能力跃迁时间线（2025）
- Q1 ：Claude 3.5 Opus、GPT-4 Turbo 主导，大型重构仍不可靠
- Q2 ：GPT-5 发布，首次实现"工厂级构建”——大型任务一次成功率显著提升
- Q3-Q4 ：GPT-5.2 推出，“几乎所有问题一次解决”；Claude Opus 持续在对话质量和创意性上占优
4.3 与传统软件工程的对比
不变的内核
| 维度 | 传统方法 | AI 原生方法 | 本质 |
|---|---|---|---|
| 架构设计 | 架构师主导 | 仍由人类决定 | 人类不可替代 |
| 需求分析 | 需求评审 | 提示词设计 | 理解"做什么"仍是核心 |
| 验证 | 测试+审查 | 运行+验证输出 | 必须确认正确性 |
| 依赖决策 | 技术选型 | 仍需人类研究 | 生态判断无法委托 |
根本性改变
| 维度 | 传统方法 | AI 原生方法 |
|---|---|---|
| 编码执行 | 人类逐行编写 | AI 批量生成 |
| 重构 | 计划 → 分阶段执行 | 一条提示 → 整体替换 |
| 调试 | 断点 + 日志 + 推理 | 描述症状 → AI 定位修复 |
| 文档 | 写给人看 | 写给代理看（新范式） |
| 项目并行度 | 通常 1-2 个 | 可达 3-8 个 |
五、实践落地指南
5.1 个人开发者：可直接借鉴的 5 个实践
实践 1：CLI 优先的开发策略
做法 ：任何新项目，先做命令行接口，后做 GUI。
原因 ：CLI 输出是纯文本，AI 代理可以直接运行命令并验证结果，形成"编码 → 运行 → 验证 → 修复"的自动闭环。GUI 项目需要截图或人工检查，反馈循环慢得多。
示例 ：Steinberger 的 Chrome 扩展项目（YouTube 摘要）起步就是一个 CLI 工具 summarize ——先在命令行跑通所有逻辑，再包装为浏览器扩展。
实践 2：队列化批量提示
做法 ：将多个任务以提示的形式批量发送到代理队列，异步等待结果。
核心思路 ：不要在一个任务上"盯着看"。发出提示后切换到其他工作或思考，30 分钟后回来检查结果。这种模式将等待时间转化为生产力。
实践 3：多模型协作
做法 ：根据任务性质选择不同模型。
| 任务类型 | 推荐选择 |
|---|---|
| 大型重构、复杂逻辑 | Codex（愿意"慢工出细活"） |
| 小修改、快速迭代 | Claude Opus（速度优先） |
| 深度技术研究 | GPT Pro / 高推理模型 |
| UI/UX 设计迭代 | 支持图片输入的模型 |
实践 4：跨项目模式复制
做法 ：用 ../other-project 路径引用已有项目，让代理学习并复制成功模式。
应用场景 ：新项目的构建配置、CI/CD 流水线、测试框架搭建——不需要从零开始，让代理参照已有的成功范例。
实践 5：文档驱动的代理上下文
做法 ：在项目中维护 AGENTS.MD （全局代理指令）和 docs/ 目录（子系统文档），确保代理每次启动时获得正确的上下文。
关键原则 ：文档结构优先考虑代理的导航效率。这意味着：清晰的目录、一致的命名规范、明确的模块边界描述。
5.2 团队场景：渐进式采纳路径
Steinberger 的极限工作流是个人实践，团队采纳需要循序渐进：
Phase 1 — 辅助编码
- 引入代码补全工具（Copilot / Cursor）
- AI 用于代码解释、文档生成、测试编写
- 人工审查所有 AI 输出
- 目标：团队建立对 AI 输出质量的直觉
Phase 2 — 代理编码
- AI 代理独立完成明确定义的子任务
- 建立 AI 代码审查清单和验收标准
- 引入自动化测试覆盖率要求
- 目标：可信赖地委托执行层面的工作
Phase 3 — 工厂模式
- 多代理并行处理不同模块
- 架构师角色取代传统程序员角色
- 上下文工程成为核心能力
- 目标：接近 Steinberger 描述的"推理速度发布"
5.3 风险管控清单
代码审查 Checklist
- 安全审查 ：是否存在注入漏洞（SQL、XSS、命令注入）？
- 依赖安全 ：新增依赖是否来自可信来源？版本是否有已知漏洞？
- 边界验证 ：用户输入、API 响应等外部数据是否做了校验？
- 错误处理 ：异常路径是否被正确处理而非静默忽略？
- 敏感数据 ：是否有硬编码的密钥、token 或个人信息？
- 性能影响 ：是否引入了 N+1 查询、内存泄漏或不必要的计算？
技术债务监控指标
- 代码重复率变化 ：AI 生成代码容易引入相似但不同的实现
- 依赖数量增长 ：AI 倾向于引入新依赖而非复用已有方案
- 测试覆盖率趋势 ：确保覆盖率不因快速迭代而下降
- Bug 密度 ：每千行代码的缺陷数，对比 AI 生成与人工编写的模块
5.4 工具链推荐
模型选择矩阵
| 场景 | 首选 | 备选 | 说明 |
|---|---|---|---|
| 日常编码 | Codex (gpt-5.2-codex) | Claude Code | Codex 大任务更可靠 |
| 代码审查 | Claude Opus | GPT-5 | Opus 在分析和解释方面有优势 |
| 深度研究 | GPT Pro | Claude w/ Extended Thinking | 需要长时间分析的技术调研 |
| 快速问答 | GPT-4 Fast / Claude Haiku | — | 低成本高速度 |
成本控制建议
- 设定月度预算上限 ：Steinberger 月均约 1.7 万美元，个人开发者应根据实际情况设定（多数人 $100-500/月 即可获得显著效率提升）
- 按任务匹配模型等级 ：简单任务用低成本模型，仅在大型重构时使用高性能模型
- 利用队列化降低实时成本 ：批量异步处理比实时交互更经济
- 监控 token 消耗 ：提高
tool_output_token_limit时注意观察成本变化
六、总结与思考
一句话总结
这篇文章展示了一个资深工程师如何将 AI 代理从"辅助工具"推到"执行主力"的极限—— 它不代表所有人的未来，但它照亮了一条值得认真研究的路径。
三个关键启示
- 瓶颈已经转移 ：对于经验丰富的开发者，编码执行不再是限制因素。架构决策、需求理解、验证策略——这些"软技能"的价值被急剧放大。
- 上下文工程是新核心能力 ：能否让 AI 高效工作，取决于你能否为它提供正确的上下文——项目文档、代理指令、目录结构、参考项目。这是 2025 年最值得投资的能力。
- 经验的价值不降反升 ：Steinberger 之所以能"不读代码就发布"，恰恰是因为他有 15 年的经验来判断什么时候该信任 AI、什么时候该干预。没有经验基础的"不读代码"只是盲目。
值得警惕的三个风险
- 技术债务的隐性积累 ：速度越快，债务积累越快，但感知却越迟钝。研究数据显示 AI 代码问题率为人工的 1.7 倍——这些问题不会立即爆发，而是在规模和时间中逐渐显现。
- 验证能力的萎缩 ：如果长期不阅读代码，开发者对代码质量的判断直觉可能逐渐退化。这形成了一个危险的正反馈循环：越不读代码 → 越依赖 AI → 越无法判断 AI 的输出质量。
- 幸存者偏差 ：Steinberger 是有 15 年经验、已经财务自由、做个人项目的特殊个体。他的工作流在这些前提下成功，但简单复制到团队协作、遗留代码维护、安全敏感系统等场景，可能产生严重后果。
展望
AI 辅助编程正处于从"新奇体验"到"基础设施"的转折点。Steinberger 的实践是一次极限压力测试——它展示了上限，同时也暴露了边界。
真正的问题不是"AI 能否替代编码"（在执行层面上，答案越来越明确地指向"能"），而是**“我们需要建立什么样的验证、治理和质量保障体系，来确保以推理速度发布的软件是值得信赖的”**。这个问题的答案，将决定 AI 原生开发能走多远。
参考来源
| 来源 | 链接 |
|---|---|
| 原文 | Shipping at Inference-Speed |
| HN 讨论 | Hacker News Thread |
| Pragmatic Engineer 访谈 | The Creator of Clawd |
| Vibe Coding 批判 | The Vibe Coding Trap |
| AI 代码质量报告 | CodeRabbit: AI vs Human Code Report |
| AI 代码库质量分析 | SonarSource Analysis |
| AI 代码安全风险 | Forbes: Security Risks |
| 学术研究 | arXiv: LLM Agent Development |
| 概念演进 | MIT Tech Review: Vibe to Context Engineering |
| 行业趋势 | TheNewStack: AI Engineering Trends 2025 |