---
url: /blog/ts7r6yju/index.md
description: 深度解读Peter Steinberger的AI编程极限实践：3个月5.1万美元API费用，探索AI代理工作流的上限与边界
---
## 《以LLM推理的速度交付软件》深度解读

> \[!note] 转载说明
> ℹ️
>
> 原文： [Shipping at Inference-Speed](https://steipete.me/posts/2025/shipping-at-inference-speed) | 作者：Peter Steinberger | 发布：2025.12.28

***

## 一、文章概览

### 1.1 作者背景

Peter Steinberger（网名 steipete）是 iOS 开发领域的知名人物。他于 2011 年创立了 [PSPDFKit](https://pspdfkit.com/) ——一家专注于 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 生成代码。他对此的辩护逻辑是：

1. **大量的代理交互建立了直觉** ——他能凭经验判断一个任务应该耗时多久，当模型卡住时能立即察觉
2. **CLI 优先策略** ——所有项目先做命令行工具，这样代理可以直接运行并验证输出，形成闭环测试
3. **代码不是目标，工作的功能才是** ——他关注的是功能是否正确运行，而非代码本身是否优雅

#### 观点四：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 配置参考

```toml
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](https://news.ycombinator.com/item?id=46441873) 上引发了激烈讨论，观点明显分为两派：

**支持派论点：**

* **成本效率** ：用户 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 上公开分享了这篇文章，引发广泛讨论
* [访谈总结](https://x.com/Hesamation/status/2016712942545240203) 强调他使用的是"代理工程”（Agentic Engineering）而非简单的 Vibe Coding——多代理并行 + 闭环测试验证
* [分析帖](https://x.com/rmay/status/2023365065152385065) 将其视为"AI 改变执行瓶颈"的标志性案例——个人杠杆被极大放大，创业变得更加意愿驱动

### 3.2 批判性视角

#### 代码质量与可维护性风险

多项研究为"不阅读代码"的做法提供了警示数据：

* **CodeRabbit 报告** ：AI 生成代码出现问题的概率是人工代码的 **1.7 倍** ，且高严重度问题占比更高 ([来源](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report))
* **SonarSource 分析** ：AI 加速的代码库中，代码质量下降几乎不可避免，技术债务（Technical Debt，即为了短期速度而积累的长期维护成本）以更快的速度增长 ([来源](https://www.sonarsource.com/blog/the-inevitable-rise-of-poor-code-quality-in-ai-accelerated-codebases))
* **Forbes 警告** ：快速 AI 代码生成正在引发"安全风险海啸"——AI 会复制训练数据中的已知漏洞 ([来源](https://www.forbes.com/councils/forbestechcouncil/2025/04/18/how-ai-generated-code-is-unleashing-a-tsunami-of-security-risks))
* **学术研究 (arXiv)** ：LLM 代理显著加速开发，但同时导致代码质量明显下降，引发长期维护风险 ([来源](https://arxiv.org/html/2511.04427v1))

#### “验证转移"理论

Frédéric Pattyn 在 [The Vibe Coding Trap](https://ellenblogs.com/vibe-coding-trap/) 中提出了一个深刻的洞察：

> AI 编码的根本风险不是"更多 bug”，而是 **返工从代码层转移到了隐性的监督和验证层** 。

具体表现为：

1. **监督成为新瓶颈** ：AI 加速了生产，人工审查成为制约因素
2. **错误跨层复合** ：AI 产生的错误不是简单累积，而是在架构层级间"传染和放大"，比传统 bug 更难检测、修复成本更高
3. **第一轮完成度的欺骗性** ：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 | — | 低成本高速度 |

#### 成本控制建议

1. **设定月度预算上限** ：Steinberger 月均约 1.7 万美元，个人开发者应根据实际情况设定（多数人 $100-500/月 即可获得显著效率提升）
2. **按任务匹配模型等级** ：简单任务用低成本模型，仅在大型重构时使用高性能模型
3. **利用队列化降低实时成本** ：批量异步处理比实时交互更经济
4. **监控 token 消耗** ：提高 `tool_output_token_limit` 时注意观察成本变化

***

## 六、总结与思考

### 一句话总结

这篇文章展示了一个资深工程师如何将 AI 代理从"辅助工具"推到"执行主力"的极限—— **它不代表所有人的未来，但它照亮了一条值得认真研究的路径。**

### 三个关键启示

1. **瓶颈已经转移** ：对于经验丰富的开发者，编码执行不再是限制因素。架构决策、需求理解、验证策略——这些"软技能"的价值被急剧放大。
2. **上下文工程是新核心能力** ：能否让 AI 高效工作，取决于你能否为它提供正确的上下文——项目文档、代理指令、目录结构、参考项目。这是 2025 年最值得投资的能力。
3. **经验的价值不降反升** ：Steinberger 之所以能"不读代码就发布"，恰恰是因为他有 15 年的经验来判断什么时候该信任 AI、什么时候该干预。没有经验基础的"不读代码"只是盲目。

### 值得警惕的三个风险

1. **技术债务的隐性积累** ：速度越快，债务积累越快，但感知却越迟钝。研究数据显示 AI 代码问题率为人工的 1.7 倍——这些问题不会立即爆发，而是在规模和时间中逐渐显现。
2. **验证能力的萎缩** ：如果长期不阅读代码，开发者对代码质量的判断直觉可能逐渐退化。这形成了一个危险的正反馈循环：越不读代码 → 越依赖 AI → 越无法判断 AI 的输出质量。
3. **幸存者偏差** ：Steinberger 是有 15 年经验、已经财务自由、做个人项目的特殊个体。他的工作流在这些前提下成功，但简单复制到团队协作、遗留代码维护、安全敏感系统等场景，可能产生严重后果。

### 展望

AI 辅助编程正处于从"新奇体验"到"基础设施"的转折点。Steinberger 的实践是一次极限压力测试——它展示了上限，同时也暴露了边界。

真正的问题不是"AI 能否替代编码"（在执行层面上，答案越来越明确地指向"能"），而是\*\*“我们需要建立什么样的验证、治理和质量保障体系，来确保以推理速度发布的软件是值得信赖的”\*\*。这个问题的答案，将决定 AI 原生开发能走多远。

***

## 参考来源

| 来源 | 链接 |
| --- | --- |
| 原文 | [Shipping at Inference-Speed](https://steipete.me/posts/2025/shipping-at-inference-speed) |
| HN 讨论 | [Hacker News Thread](https://news.ycombinator.com/item?id=46441873) |
| Pragmatic Engineer 访谈 | [The Creator of Clawd](https://newsletter.pragmaticengineer.com/p/the-creator-of-clawd-i-ship-code) |
| Vibe Coding 批判 | [The Vibe Coding Trap](https://ellenblogs.com/vibe-coding-trap/) |
| AI 代码质量报告 | [CodeRabbit: AI vs Human Code Report](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) |
| AI 代码库质量分析 | [SonarSource Analysis](https://www.sonarsource.com/blog/the-inevitable-rise-of-poor-code-quality-in-ai-accelerated-codebases) |
| AI 代码安全风险 | [Forbes: Security Risks](https://www.forbes.com/councils/forbestechcouncil/2025/04/18/how-ai-generated-code-is-unleashing-a-tsunami-of-security-risks) |
| 学术研究 | [arXiv: LLM Agent Development](https://arxiv.org/html/2511.04427v1) |
| 概念演进 | [MIT Tech Review: Vibe to Context Engineering](https://www.technologyreview.com/2025/11/05/1127477/from-vibe-coding-to-context-engineering-2025-in-software-development) |
| 行业趋势 | [TheNewStack: AI Engineering Trends 2025](https://thenewstack.io/ai-engineering-trends-in-2025-agents-mcp-and-vibe-coding) |