《以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 生成代码。他对此的辩护逻辑是：

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

观点四：Codex vs Opus 实战对比 #

这是文章中极具参考价值的一线对比：

关键洞察：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 小时做出来，真的那么重要吗？真正有价值的是经过深思熟虑、高度打磨的应用，那仍然需要以人年计算”

Twitter/X 社区评价 #

• 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”，而是返工从代码层转移到了隐性的监督和验证层。

具体表现为：

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 编程工具生态 #

模型能力跃迁时间线（2025） #

• Q1：Claude 3.5 Opus、GPT-4 Turbo 主导，大型重构仍不可靠
• Q2：GPT-5 发布，首次实现"工厂级构建”——大型任务一次成功率显著提升
• Q3-Q4：GPT-5.2 推出，“几乎所有问题一次解决”；Claude Opus 持续在对话质量和创意性上占优

4.3 与传统软件工程的对比 #

不变的内核 #

根本性改变 #

五、实践落地指南 #

5.1 个人开发者：可直接借鉴的 5 个实践 #

实践 1：CLI 优先的开发策略 #

做法：任何新项目，先做命令行接口，后做 GUI。

原因：CLI 输出是纯文本，AI 代理可以直接运行命令并验证结果，形成"编码 → 运行 → 验证 → 修复"的自动闭环。GUI 项目需要截图或人工检查，反馈循环慢得多。

示例：Steinberger 的 Chrome 扩展项目（YouTube 摘要）起步就是一个 CLI 工具 summarize——先在命令行跑通所有逻辑，再包装为浏览器扩展。

实践 2：队列化批量提示 #

做法：将多个任务以提示的形式批量发送到代理队列，异步等待结果。

核心思路：不要在一个任务上"盯着看"。发出提示后切换到其他工作或思考，30 分钟后回来检查结果。这种模式将等待时间转化为生产力。

实践 3：多模型协作 #

做法：根据任务性质选择不同模型。

实践 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 工具链推荐 #

模型选择矩阵 #

成本控制建议 #

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 原生开发能走多远。

参考来源 #