这段视频是《The Pragmatic Engineer》播客对知名开发者 Peter Steinberger 的深度专访。Peter 曾经开发了被全球超过十亿台设备使用的底层 PDF 框架 PSPDFKit。在经历了严重的职业倦怠并卖掉股份后，他彻底离开了科技界三年。今年，他带着一个名为 Clawbot（一款在 GitHub 上迅速爆火的超级个性化 AI 助手）的新项目重返大众视野。

访谈的核心探讨了 AI 代理（AI Agents）如何彻底颠覆传统的软件工程工作流。Peter 分享了他现在的开发模式——他称之为“代理式工程（Agentic Engineering）”。在这个模式下，他不再逐行手写或阅读大部分部署的代码，而是像架构师一样，同时指挥 5 到 10 个 AI 模型（如 Codex、Claude）并行工作。他强调了“闭环（Closing the loop）”原则，即通过让 AI 自己编写测试脚本和 CLI 工具来验证代码，从而确保 AI 生成代码的可靠性。

此外，Peter 还提出了一系列前卫的观点：他认为传统的代码审查（Code Review）意义正在减弱，未来的 Pull Request 应该被称为 Prompt Request（提示词请求）；过度复杂的 AI 编排（如 MCP）不如简单的命令行接口（CLI）高效；以及未来的软件公司或许只需要目前 30% 的人手就能运转。这期访谈生动地展示了一位顶尖开发者如何驾驭 AI 工具，实现个人生产力的几何级跃升。

---

主题：早期黑客生涯与缔造十亿级装机量产品 PSPDFKit 的起伏历程

Peter Steinberger 出生于奥地利的乡村，从小性格相对内向，但对计算机展现出了极大的热情。他最早的“极客”行为发生在 14 岁左右，当时他破解了学校里的一款老旧 DOS 游戏，并为其编写了防拷贝保护程序以便自己出售。进入大学后，由于家庭经济条件有限，他必须全职工作来负担自己的学费。在接触到初代的 iPhone 后，他立刻被其流畅且颠覆性的体验所折服，但这并没有立刻让他成为一名 iOS 开发者。

他真正踏入应用开发的契机非常具有戏剧性：有一次他在地铁上使用一款基于网页端封装的约会软件，花了很长时间打下了一段饱含深情的长篇信息。结果当列车驶入隧道失去信号时，该网页的 JavaScript 禁用了发送按钮、复制粘贴以及滚动功能。眼睁睁看着自己写的心血白白丢失，Peter 感到出离愤怒。回到家后，他立刻下载了 Xcode，不顾当时技术的生疏，通过正则表达式强行解析该网站的 HTML，用一系列测试版的开发工具（如 iPhone OS 3 Beta、带块编译器的魔改 GCC），硬生生为这款约会软件做了一个原生的 iOS 客户端。他将应用以 5 美元的价格上架 App Store，第一个月就赚了 1 万美元，甚至因为最初填了爷爷的银行账户，让老人家看到巨款后受到不小的惊吓。尽管这个应用最终因涉及违规图片被苹果官方下架，但这次经历让他正式踏入了 iOS 开发的顶尖圈子。

随后，他接手了一个给 iPad 杂志应用修复 Bug 的短期外包项目。那个项目的代码如同灾难——成千上万行的代码全塞在一个文件里。Peter 决定推倒重来，其中最核心也最困难的部分就是 PDF 渲染。在早期只有 64MB 内存的移动设备上，渲染一个可能需要占用 30MB 内存的 PDF 页面，还要保证旋转屏幕时的丝滑动画，是一个极其硬核的底层挑战。他花了两个月时间完美解决了这个问题，后来又敏锐地察觉到了商机，将其剥离出来在 Twitter 上售卖。这便是后来被全球超过十亿台设备使用的底层 PDF 框架 PSPDFKit 的雏形。

在公司发展的 13 年里，Peter 极其注重框架的细节和“苹果式”的丝滑体验。尽管市面上有更早、功能更多的竞品，但开发者在试用后往往会爱上 PSPDFKit 的手感。随着业务扩张，公司采取了企业级定制报价（Enterprise Pricing）策略，根据客户规模来决定价格，从而实现商业价值的最大化。在这个过程中，他遇到过极其夸张的边界测试：比如一位加拿大客户上传了一本多达 50000 页的“文字圣经”，每页有超过 100 个链接，总计 500 万个链接。原有的数据模型瞬间崩溃，加载一个文件需要 4 分钟。Peter 被迫闭关两个月，在不破坏现有外部 API 接口的前提下，将底层代码全面重构为懒加载模式才解决问题。

然而，随着公司规模膨胀到 70 人，Peter 逐渐感到力不从心。作为 CEO，他成了全公司的“垃圾桶”，每天要处理各种管理问题和人事纠纷。更恐怖的是技术带来的精神高压：某周末凌晨 5 点，他得知某家大型航空公司的飞机因为他们的 PDF 软件崩溃而停飞。虽然最终查明是客户篡改源代码触发了版权保护机制导致的，但这种随时可能“搞垮一家公司”的压力，以及管理团队内部的分歧，让他彻底陷入了严重的职业倦怠（Burnout）。最终，他选择了激流勇退，卖掉全部股份，彻底离开了科技圈。

主题：长达三年的隐退与遭遇 AI 编程带来的“原子弹级”震撼

隐退之后的整整三年里，Peter 几乎完全切断了与代码和科技圈的联系。为了缓解之前创业带来的严重心理透支，他在这段时间里大量弥补了自己错过的生活体验。有好几个月的时间，他甚至连电脑都没有打开过。因为在如此年轻的年纪就实现了财务自由，失去了传统意义上的“工作目标”，他的心理状态一度非常挣扎和迷茫，不知道接下来该用什么来填补生活的空白。在这与世隔绝的三年里，科技界发生了翻天覆地的变化，尤其是在人工智能领域，大语言模型突飞猛进，但 Peter 完美地错过了这一切前期的演进。

直到今年的 4 月份，他才决定重新坐回电脑前。起因是他想继续完成一个多年前一直萦绕在脑海里的业余项目——一个类似于 Twitter 数据分析的工具。当时他想用现代的 Web 架构（如 React 等）来重写这个项目，但对于一直深耕苹果生态底层和 C++ 的 Peter 来说，Web 前端领域几乎是他的知识盲区。他发现自己陷入了所谓的“专家陷阱”：在 Swift 领域他可以闭着眼睛写出最优雅的代码，但在 Web 技术栈里，他却需要为了最基础的语法（比如什么是 prop）去不停地 Google 搜索。这种从顶级大师瞬间跌落为新手的摩擦感和挫败感让他感到极度痛苦。

为了摆脱这种效率低下的泥潭，他决定尝试一下大家都在谈论的 AI 编程工具。他最早接触的是刚刚推出测试版的 Claude Code。他把一个极其杂乱的、包含 1.3 MB 文本的 GitHub 仓库打包丢进 Gemini 模型，让其生成了一份 400 行的需求规格说明书，然后把这份说明书输入给了 Claude Code。令人震撼的事情发生了，他只需要不断地输入“继续执行”，AI 就在后台不断地阅读代码、编写功能并自我修复。当他加入 MCP（Model Context Protocol）让 AI 能够使用浏览器后，仅仅循环了几个小时，AI 就硬生生地把一个带有 Twitter 登录页面的网站雏形跑通了。

这一瞬间，Peter 感受到了前所未有的震撼。他敏锐地意识到，软件工程的底层逻辑已经被重塑。以前，因为人的精力有限且跨界学习成本极高，开发者必须极其谨慎地挑选自己要投入精力的业余项目；但现在，所有的语言壁垒和技术栈壁垒都被 AI 抹平了。无论是不懂的 Go 语言，还是陌生的 Web 框架，只要具备顶级的系统架构理解能力和产品直觉，就可以让 AI 去填补具体的实现细节。这种如同拥有了“魔法”般的感觉让他彻底上瘾。他连续几个月都处于亢奋得无法入睡的状态，经常在凌晨 5 点还在给 AI 下达指令。他将这种感觉比作在赌场拉动老虎机的操纵杆：每一次输入 Prompt，它都可能给你一个震撼人心的精妙实现。他在伦敦甚至戏谑地成立了一个名为“黑眼圈俱乐部（Black Eye Club）”的群组，里面全是被他“安利”后沉迷 AI 编程无法自拔的资深开发者朋友。这段复出的经历，让他正式从一个逐行手写代码的传统程序员，蜕变成了掌控全局的“AI 代理架构师”。

主题：从手写代码到“代理式工程”的范式转变与闭环验证

Peter 提出了一个在传统开发者听起来极其离经叛道的观点：“我部署那些我甚至都不读的代码（I ship code I don't read）。”他坦言，现代应用程序中大量的代码实际上只是枯燥的“管道工程（Plumbing）”——数据从 API 进入，被解析、转换格式存入数据库，然后再被提取出来渲染成 HTML。这些琐碎的搬砖工作完全不需要人类去逐行斟酌。他现在的角色不再是“码农”，而是更像一个“系统架构师”或“建造者（Builder）”。他将精力集中在整体架构的设计、系统的交互感觉以及产品愿景上，而将具体的编码工作全部下放给 AI。

在他的日常工作流中，他将这种模式称为“代理式工程（Agentic Engineering）”。为了保持沉浸式的工作心流（Flow State），Peter 不会只盯着一个 AI 干等，而是会同时开启 5 到 10 个 AI 代理（如 Codex、Claude）并行处理不同的任务。他将这种状态比作在玩《星际争霸》或是像国际象棋大师同时下多盘盲棋：他在这里给一个代理下达构建子系统的指令，预估它需要“烹饪” 40 分钟，然后立刻切到另一个终端查看另一个代理的进度，给出反馈或微调。他强调，与 AI 编程绝不是简单地丢过去一个死板的需求文档，而是一场“对话”。他会像和资深同事讨论一样询问 AI：“如果我们采用这种结构会怎样？”“你有没有考虑过这个功能的边界？”通过不断的探讨和启发，与 AI 共同塑造出完美的系统。

然而，AI 生成的代码并非总是完美的，这就引出了代理式工程中最核心的秘诀——“闭环验证（Closing the loop）”。很多开发者对 AI 失望（比如著名开发者 Nala 曾写博客批评 AI 代码无法一次性编译通过），是因为他们缺乏正确的闭环思维。Peter 指出，模型就像是我们人类集体知识的幽灵，你不可能指望它一次性写出 100% 无 Bug 的代码。成功的关键在于让 AI 具备自我测试和调试的能力。例如，在开发 Mac 应用时，由于传统的浏览器或 UI 循环测试极慢且难以让 AI 直接介入，Peter 会特意让 AI 编写一个专门用于测试核心逻辑的 CLI（命令行工具）或者构建包含本地测试环境的 Docker 容器。当代码出错时，AI 可以自己读取错误日志、分析问题并自我修复。讽刺的是，由于必须将系统设计得更易于被 AI 测试，Peter 发现自己现在主导构建的软件架构，甚至比他以前纯手工编写时还要清晰和健壮。不仅如此，他连测试用例和文档都不再自己写，而是把产品权衡的思路告诉模型，让模型自动生成逻辑严密、对新手极其友好的技术文档。

主题：Clawbot 的诞生与架构哲学：打造具有“灵魂”的超级 AI 助手

在彻底体验了 AI 的威力后，Peter 开始构思一个酝酿已久的想法：打造一个如同电影《Her》中那样的“超级个性化助手”。他不想要那种只会每天早上发生硬邮件提醒的呆板机器人，而是想要一个懂他、有“灵魂”、且极其全能的数字挚友。这个助手能敏锐地察觉他的情绪，比如主动问他：“我注意到你每次见完某个人心情都很低落，为什么？”或者在发现他很久没联系某个朋友时，主动根据对方的社交动态提议他去打个招呼。

这个想法最终演变成了在 GitHub 上一周狂揽 3300 多颗 Star 的爆款开源项目——Clawbot（最初叫 WhatsApp Relay）。Clawbot 的惊艳之处在于其极高的“资源整合能力（Resourcefulness）”和跨越次元壁的执行力。Peter 分享了一个他在摩洛哥旅行时的神奇经历：当时他在街头，随手给 Clawbot 发送了一段语音，几秒钟后 AI 就给出了完美的文字回复。事后他查看日志才发现，AI 在后台展现了极其恐怖的自主性——它识别出文件是 OGG 格式，立刻调用电脑上的 FFmpeg 工具进行格式转换；接着它发现系统里没有安装本地的 Whisper 语音识别模型，于是它聪明地去翻找电脑里的 OpenAI API Key，自己写了一段 Curl 命令调用云端服务完成了语音转写。还有一次，因为 Peter 需要早起但没有回复消息，远在伦敦的 Clawbot 通过 SSH 远程连接到他摩洛哥的笔记本上，强行把音量调到最大播放音乐，甚至还在信息里对他开启了“吐槽模式”。

在底层架构的设计上，Peter 展现出了对现有 AI 流行工具的深刻反思。目前业界极力推崇 MCP（模型上下文协议）来让 AI 调用外部工具，但 Peter 却认为 MCP 目前是一个极其笨重且愚蠢的“拐杖”。MCP 要求在会话加载时将所有工具的描述和函数一股脑塞进上下文，然后通过庞大的 JSON 数据进行交互。由于模型无法在 MCP 内部进行数据过滤，获取一个简单的伦敦天气可能会返回几百个无关的冗余字段，极大消耗了 Token 和处理效率。相反，Peter 极度推崇古老但高效的 CLI（命令行界面）。他为家里的灯光、音乐、日历等所有服务都编写了 CLI。因为 CLI 允许 AI 像使用传统 Linux Bash 一样，利用 jq 等工具精准过滤数据，还可以将多个命令串联组合。通过这种化繁为简的架构，Clawbot 甚至能在终端里通过 TUI（文本用户界面）完成带有仪式感的“出生引导”，生成包含用户喜好、内部笑话的“灵魂文件（Soul.md）”，让冰冷的代码真正拥有了温度。

主题：颠覆传统的软件团队管理：重构代码审查与新人的破局之道

Clawbot 的成功不仅仅是一个产品的胜利，它更像是一个测试用例，揭示了未来软件工程公司可能面临的组织架构大地震。Peter 断言，如果今天让他重新创办 PSPDFKit 并开发同样的底层框架，利用现在的 AI 代理工作流，他只需要以前 30% 的员工就能完成所有的工作。这意味着未来的科技公司将不再需要大量只负责“写基础代码”或单一职能（如单纯的前端、单纯的 UI 设计）的员工。未来的团队将由极少数具备“高代理权（High Agency）”、能掌控全局视野的复合型顶尖人才组成。这种生产力的跃升也暗示了未来严峻的就业形势，传统模式下的许多开发岗位可能面临被淘汰的风险。

在具体的协作流程上，传统的开发法则正在被彻底颠覆。在 Clawbot 的开源维护中，Peter 每天要合并几百个 Pull Request（代码合并请求），他自嘲自己已经变成了一个“无情的合并按钮（Human Merge Button）”。但他明确表示，传统的代码审查（Code Review）已经毫无意义。他现在看重的不再是贡献者提交的“代码”，而是他们使用的“提示词（Prompt）”。他提议将 Pull Request 改名为 Prompt Request（提示词请求）。因为提示词展现了开发者是如何思考问题的、如何引导 AI 的、以及他们设计的边界条件。只要思路和架构（Taste）是对的，具体的代码实现完全可以让 AI 瞬间完成。如果有贡献者提交了一个只修复了几个小 Bug 的传统 PR，Peter 甚至会拒绝，并告诉对方：“你发这种 PR 让我去一行行审查，浪费了我 10 倍的时间。你不如直接告诉我 Prompt，我自己输入给 Codex 几分钟就修好了。”此外，繁琐的云端 CI/CD（持续集成）流程也被他抛弃，他现在只依赖本地的“Full Gate（全量闸机）”自动化测试，因为 AI 代理在提交代码前就已经在本地把测试跑通了。

面对这种对经验丰富的极客极度友好的新世界，刚毕业的计算机新手该何去何从？Peter 承认，新手入行的门槛被不可逆转地拔高了，因为他们缺乏对大型系统架构的宏观认知。但他给出了极其诚恳的建议：保持无限的“好奇心（Curiosity）”。不要把编程当成死记硬背语法的苦差事，而是把它当成一场游戏。新手应该去 GitHub 上寻找那些复杂的、优秀的开源项目，然后利用不知疲倦的 AI 代理作为你的“私人导师”。你可以向 AI 提出无数个“为什么”——“这段代码为什么要这样设计？”“这里的边界情况是什么？”。通过在庞大的代码库中进行这种剥丝抽茧的对话，去培养对软件系统的“嗅觉”和“品味”。更重要的是，新一代的年轻人没有传统软件工程思维的思维定势（Baggage），他们生来就把 AI 当成基础设施，这种没有任何历史包袱的直觉，将是他们在未来“代理式工程”时代破局的最大武器。

---

核心问答

Q1：Peter 宣称“我发布我甚至都不读的代码（I ship code I don't read）”，这听起来像是一场工程灾难。这个激进理念得以成立的“绝对前提”是什么？它的适用边界又在哪里？

A： 这个理念之所以没有演变成工程灾难，其绝对前提在于 Peter 极度强调的**“闭环验证（Closing the loop）”**。 在传统的开发中，人类通过“阅读代码”来在大脑中进行逻辑推演和人工查错。而 Peter 将这个人工查错的过程，替换成了“机器自动化验证”。他的逻辑是：只要系统的架构具备极高的可测试性，且 AI 能够自主运行测试、读取错误日志并自我修复，那么人类就没有必要去阅读那些为了实现功能而堆砌的“管道代码（Plumbing code）”。讽刺的是，为了让 AI 能够顺畅地完成“编写-测试-修复”的闭环，Peter 被迫设计出了比他纯手工编码时更解耦、更清晰的系统架构（例如为所有核心逻辑封装 CLI 以脱离浏览器环境进行极速测试）。

逻辑延伸与边界： 这种模式的边界在于“客观可验证性”。如果一段代码的正确性可以通过编译、单元测试、集成测试或明确的预设条件来衡量，那么“不读代码”是完全可行的。但是，一旦涉及到主观体验、感官反馈或强物理交互（例如 UI 动画的“丝滑感”、硬件设备的力反馈、或者是极其微妙的并发资源竞争），AI 就无法依靠简单的报错日志来形成闭环。Peter 自己也承认，AI 缺乏人类的“品味（Taste）”。因此，在涉及到产品灵魂和感官体验的边界处，人类不仅要读代码，甚至还要像工匠一样去微调。

Q2：在整个行业都在狂热追捧 MCP（模型上下文协议）以扩展 AI 能力时，Peter 为什么坚定地逆流而上，推崇古老的 CLI（命令行接口）？这暴露了当前 AI 发展的什么底层缺陷？

A： Peter 拒绝 MCP 的核心原因在于上下文效率（Context Efficiency）与可组合性（Composability）。 MCP 的设计逻辑是“大包大揽”，要求在对话初始阶段将所有工具的描述、参数格式以巨大的 JSON 形式塞进模型的上下文，并且返回的结果往往也是未经加工的庞大数据（比如问个天气，会返回包含经纬度、风向、湿度等几百个字段的 JSON）。这不仅极大地消耗了 Token，还容易导致 AI 在信息噪音中迷失。相反，CLI 继承了优雅的 Unix 哲学：模块化、单一职责、文本流转。AI 可以像一个老练的运维工程师一样，使用 jq 等命令行工具精准过滤它需要的数据，并将多个命令通过管道串联起来。

逻辑延伸与推演： Peter 的选择精准击中了当前 LLM 的软肋：模型的推理能力与其上下文视窗中的“信噪比”强相关。喂给模型的信息越冗余，它“变笨”的概率就越大。然而，Peter 的逻辑也有其时代局限性。CLI 的本质是字符串解析，这其实是非常脆弱的（一旦命令行输出格式微调，正则匹配就会失效）；而 MCP 提供的是强类型的结构化契约。随着未来 AI 模型原生上下文窗口的无限扩大（如 Gemini 1.5 Pro 的长上下文）以及模型原生工具调用（Native Tool Calling）成本的断崖式下降，MCP 的结构化优势最终会盖过其当前的笨重感。Peter 只是在当前技术约束下，找到了最高效的局部最优解。

Q3：Peter 预言未来的软件公司只需要现在的 30% 的人手。对于传统科技大厂而言，向“代理式工程”转型最大的陷阱是什么？

A： 最大的陷阱在于：试图用新时代的生产力工具，去适配旧时代的组织架构。 Peter 明确指出，想要利用 AI 提效，“不仅仅是重构你的代码库，更是重构你的公司”。传统大厂的组织架构深受“康威定律（Conway's Law）”影响，系统设计往往等同于组织结构——产品经理提需求、UI 画图、前端切图写页面、后端写接口、测试找 Bug。如果在这种流水线式的结构中强行引入 AI，结果只是每个环节的员工用 AI 摸鱼，沟通成本和跨部门摩擦依然存在，整体效率根本无法实现质的飞跃，更别提裁员 70% 了。

逻辑延伸与推演： “代理式工程”需要的是一种全新的职业物种——“高代理权建造者（High Agency Builder）”。这个人必须兼具产品直觉、系统架构能力和极强的跨界融合能力。未来不再需要“专职前端”或“专职后端”，一个人带领 10 个 AI Agent 就能完成一个跨职能小队的产出。因此，大厂转型的真正阻力不是技术，而是政治与人性。中层管理者会为了保住自己的职权范围而抗拒这种扁平化、全能化的超级个体模式。谁能最先打破旧有的“流水线组织图”，建立起以“超级节点（核心大脑）+ AI 代理集群”为运作单元的新模式，谁才能真正吃到这波红利。

Q4：将 Pull Request（代码合并请求）改为 Prompt Request（提示词请求），这一视角的转变对人类协同开发意味着什么？它引入了什么新的技术债务风险？

A： 这一转变意味着人类协作的粒度从“微观的语法层面”跃升到了“宏观的意图与架构层面”。 在传统的 Pull Request 中，Reviewer 会审查空格、变量命名、算法复杂度等细节；而在 Prompt Request 中，审查的焦点变成了：“你向 AI 下达了什么指令？”“你是否考虑了系统边界？”“你的架构权衡（Trade-offs）是什么？”。正如 Peter 所说，他更愿意看别人写的 Prompt，因为这能直接反映开发者的“思考过程”，只要思考路径对了，AI 生成的代码就不会偏离大方向。

逻辑延伸与推演： 然而，这种模式引入了一种极其隐蔽的**“黑盒化技术债务（Black-box Tech Debt）”**风险。如果所有人都只审查 Prompt 而不看生成的具体代码（Glue Code），虽然代码能通过当前的自动化测试，但它内部可能隐藏着冗余的依赖、糟糕的内存管理或微小的性能衰退。随着时间推移，这种由机器生成的、无人问津的“暗物质代码”会在系统中不断堆积。当遇到极端边缘情况或需要进行底层安全排查时，人类开发者将面临一个完全陌生的、由多个不同时期的 AI 代理拼凑而成的庞大“弗兰肯斯坦”系统。届时，除错的成本将呈现指数级上升。

Q5：对于刚入行、缺乏系统架构经验的新手（Junior）来说，如果底层代码都被 AI 写了，他们面临着怎样的“经验悖论”？他们未来的核心竞争力到底是什么？

A： 新手面临着一个残酷的经验悖论：Peter 能够指挥 AI，是因为他通过 15 年纯手工排雷（如处理 500 万个链接的 PDF）积累了顶级的系统直觉；但现在的 AI 剥夺了新手通过“写底层烂代码并被前辈痛骂”来积累经验的途径。如果直接用 AI 堆砌高级功能，新手将永远停留在“知其然不知其所以然”的表面，一旦 AI 生成的系统出现深层逻辑崩塌，新手将束手无策。

逻辑延伸与推演： 打破这个悖论的关键，是从“语法学习者”转变为**“系统考古学家”和“高维试错者”。 Peter 给出的解法是“利用 AI 解释复杂的开源项目”。这意味着新手的核心竞争力不再是“手写算法的速度”，而是“提问的质量（Curiosity）”和“验证逻辑的严密性”。同时，年轻人的巨大优势在于没有历史包袱（No Baggage）**。老一代程序员脑子里充满了 OOP（面向对象）、微服务、各种设计模式的条条框框；而新一代开发者生来就以 AI 为基础设施，他们不会被传统的“正确开发姿势”所束缚，敢于用最天马行空的方式去编排 AI。谁能最快地掌握与机器对话的底层逻辑（机器语言的思维模式），用极低的成本进行海量试错并提炼出架构规律，谁就能在全新的赛道上弯道超车。