Clawd 的创建者:“我发布代码,却不阅读” | 实用主义工程师

彼得·施泰因贝格尔分享了他如何利用 AI 代理，以创纪录的速度完成数千次提交并构建复杂软件。

他解释了为什么现在优先考虑高层架构和产品品味比阅读每一行代码更重要。

他的方法展示了在人工智能迅速降低技术实施成本之际，开发者如何保持竞争力。

核心要点

• 开发软件能提供与《异星工厂》等复杂策略游戏相同的沉浸感。
• 天真可能是创始人最大的财富。许多公司之所以能存在，仅仅是因为创始人在初期并未意识到技术挑战会有多困难。
• 直接面向开发者进行营销往往比针对管理层更有效。如果技术团队喜欢某个工具，他们会为你搞定内部游说和销售工作。
• 建立行业标准基准能激励谷歌和苹果等科技巨头，为你的特定软件优化其硬件和浏览器。
• 最有价值的商业利基市场往往是那些对大多数开发者来说既困难又缺乏吸引力的领域，因为这能减少竞争并创造强大的市场地位。
• 倦怠往往是由对使命失去信念或团队内部的摩擦引起的，而非仅仅是长时间工作。
• 专业开发者常常觉得切换技术栈很痛苦，因为他们必须放弃专家级的效率，去面对再次成为新手的挫败感。
• 在某个趋势的早期阶段远离技术可能是一种优势，因为你可以跳过实验阶段，直接使用成熟的工具。
• 使用AI进行编码就像玩老虎机，因为令人惊叹的输出所带来的间歇性奖励使这个过程极具成瘾性。
• 提示词交互中的阻力是糟糕架构的信号。如果AI代理遇到困难或生成混乱的代码，这通常表明底层系统设计存在缺陷。
• 喜欢解决复杂算法问题的人常常难以适应AI，因为它自动化了他们认为最有成就感的那部分工作。
• 有效的代理工程依赖于闭环，这意味着赋予AI代理自动调试和测试自身工作的工具。
• 代码是AI的理想应用场景，因为它通过编译和执行提供了明确的验证，这是创意写作所缺乏的。
• 使用AI代理让你成为更好的程序员，因为它迫使你设计更可测试和可验证的架构，以实现反馈闭环。
• AI显著降低了编写代码的成本，将软件开发从一个僵化的规划过程转化为迭代和塑造的趣味性行为。
• 对于AI代理来说，命令行界面 (CLI) 通常比多模态控制面板 (MCP) 更高效，因为它们允许模型使用Bash和jq等过滤工具来管理上下文空间。
• 公司必须重构其内部结构和代码库，以便为AI代理而非人类开发者进行优化，从而保持速度。
• 使用AI的一个强大方式是将其指向你已经解决过问题的现有文件夹或项目，从而让代理无需新的解释就能理解你独特的风格和逻辑。
• 解决方案背后的思考过程现在比代码本身更有价值，这使得用于生成软件的提示词成为拉取请求中最重要的部分。
• 并行管理多个AI代理在精神上比传统编码更耗费精力，需要高水平的架构知识和持续的验证。

彼得·施泰因贝格尔：从早期摸索到转向 .NET

01:39 - 04:33

彼得在奥地利乡村长大，性格内向。他对科技的兴趣始于14岁，当时一位暑期访客向他介绍了电脑。这激发了他一生动手折腾的习惯。他最早的项目之一，是盗取学校的一个DOS游戏，并为软盘编写自定义的复制保护。对彼得来说，开发软件的感觉很像玩游戏，常常比《Factorio》这类复杂的游戏更能带来满足感。

他的职业道路因需要自费求学而定型。当同龄人都在度假时，彼得却在全职工作。他在维也纳的第一份重要工作最初只是作为服兵役和上大学之间的临时过渡，却持续了五年。他最初被指派使用 Microsoft MFC，他觉得这简直是噩梦。他没有遵循公司的技术栈，而是秘密地使用 .NET 2.0 重建了系统。

我记得他们第一天给了我一本大部头书，说，Microsoft MFC。我至今仍有噩梦。接下来，我就默默地用了.NET。我只是没告诉他们。几个月后，我告诉他们我做了一些现代化改造。他们把我留了下来，因为我做的东西能用。

他早期接触 .NET 2.0 的经历，让他了解了泛型以及早期即时编译所带来的挑战。当时应用程序的启动时间出了名的慢，因为硬盘在处理初始编译时非常吃力。

点燃 彼得·施泰因贝格尔 首个应用的火花

04:33 - 09:20

彼得·施泰因贝格尔进入 iOS 开发领域，源于一次极度沮丧的经历。2009 年，当他在地铁上使用一款同性交友应用时，列车驶入隧道导致网站的 JavaScript 禁用了发送按钮，他因此丢失了一条很长、充满情感的信息。由于当时 iPhone OS 2 缺乏复制粘贴或截图功能，这条信息便永远消失了。这种恼人的经历促使彼得下载了 Xcode，并自学如何通过使用正则表达式解析网站的 HTML，以及利用 Core Data 和回溯移植的块编译器等测试版技术来构建应用程序。

我打了一长串信息，按下了发送键，就在我们驶入隧道之际。结果JavaScript禁用了发送按钮。无法复制粘贴，也无法截图。我气坏了。我回到家，下载了Xcode。

尽管没有接受过正式的 iOS 培训，Peter 在 App Store 上发布了他的非官方客户端，售价五美元，并在第一个月赚了一万美元。他甚至将款项转入了他祖父的银行账户，因为他没有在 Apple 系统中设置自己的收款账户。当他决定辞职全职从事移动开发时，他的老板嘲笑了他，称 iPhone 只是昙花一现。这种怀疑让 Peter 心生不忿，激励他最终建立了一家比他前雇主的公司更有价值的企业。

我的老板简直是在嘲笑我。“你犯了个错误。这只是一股风潮。” 这就是所谓的“不服气”。我当时就想，总有一天，我的公司会比你的公司更有价值。我花了八年时间。

然而，好景不长，苹果公司最终在凌晨3点联系他，要求他将应用从商店下架，原因是收到了关于其抓取内容不当的报告。尽管该应用已不复存在，但这次经历却让Peter对开发产生了浓厚兴趣，并为他日后成为自由职业者和企业家的职业生涯铺平了道路。

09:20 - 13:33

彼得涉足软件产品领域，几乎是阴差阳错。在iPad问世初期开发一款杂志应用时，他遇到了一段代码，这段代码脆弱得像纸牌屋。那是一个单独的文件，里面有数千行代码，而且把窗口当成了标签页来用。尽管他试图修复这些bug，但每次修改都会导致其他地方出问题。结果他花了两个月时间，从零开始重写了整个PDF引擎。

这竟然能用，让我很意外。但它感觉就像一个纸牌屋，摇摇欲坠。我尝试着精细地修补，可往往是牵一发而动全身，一处刚弄好，另一处又坏了。于是我勉强把它稳定住，然后告诉他：听着，这简直是胡闹。我得给你重写一遍。

早期移动设备的硬件限制极其严峻，带来了巨大的技术挑战。系统内存仅有大约 64 MB，而渲染一个 PDF 文件就可能消耗 30 MB。如果代码效率不够高，操作系统就会直接杀死该应用。Peter 开始专注于微小的细节，例如确保在设备旋转时页面动画流畅。这种对细节的执着让项目超出了原定截止日期，但最终交付了一款高质量的产品。

从服务项目转型为商业产品，源于一位朋友在类似项目上遇到的困境。Peter 提取了PDF组件并将其出售。意识到有市场后，他搭建了一个简单的销售页面，并通过一个私人的Dropbox链接交付源代码。最初的销售以及随后的功能请求（例如文本选择），揭示了PDF格式的真正复杂性。

公司是年轻人创办的，因为他们不了解其中的艰辛。我根本没想到这个文件格式竟然如此离谱。

这种低估技术复杂性的模式在软件工程中很常见。那些看似简单的问题，例如 PDF 渲染或构建内部实验工具，往往隐藏着数月才能发现的边缘情况。这就是为什么大型科技公司会投入数年的工程精力，来为功能开关和测试等功能构建健壮的基础设施。

软件的打磨程度与功能之间的权衡

14:26 - 17:28

彼得·施泰因贝格尔启动了一个PDF框架项目，该项目很快就迅速走红。在等待签证期间，他随着不断增加功能，销售额也随之增长，有些许可证甚至卖到了数百美元。等他搬到旧金山加入一家初创公司时，这个副业项目带来的收入已经超过了他全职工作的薪水。平衡一份要求很高的初创公司工作和一个不断发展的业务，变得困难重重。初创公司长时间的工作以及项目本身的需求，导致他严重睡眠不足。最终，他的经理萨宾给了他一周的期限，要求他在公司和自己的项目之间做出选择。由于他持有的是一种复杂的签证，选择自己的项目意味着必须离开这个国家，但这个决定很容易，因为他的业务已经起飞了。

这家企业的创立并非纯粹出于财务考量。Peter 专注于打造软件，力求达到苹果产品般精雕细琢、一丝不苟的水平。他将高品质的细节和用户体验置于首位，而非盲目追求功能数量。

我想做出让别人惊叹不已的东西。我喜欢琢磨细节，喜欢那些令人愉悦的小巧思。我的理念一直是，我打造产品，就好像苹果公司会打造它一样，倾注了所有的热爱、心血和精雕细琢，还有那些业内很多人所不具备的、令人愉悦的小巧思。

尽管竞争对手存在时间更长，功能也更多，但他的产品之所以成功，是因为让开发者用起来感觉更好。软件的成功归根结底在于使用体验，而不仅仅是功能列表。这种对软件“感觉”的关注，让他的公司比拥有更多资源的竞争对手更成功。

面向开发者的营销与基准测试的力量

17:28 - 20:04

搬回维也纳后，彼得全身心投入到他的项目中。他开始与自由职业者合作，尽管他承认他开始招聘的时间比他应该的晚得多。这款产品PSPDFKit沿用了它独特的名称十三年，因为它在开发者社区中独树一帜。这个名称最初是一个Objective C命名空间，并发展成为一个知名品牌。

我职业生涯中差不多有13年时间都在打造这个产品，它的名字很奇怪，我一直没改，因为当初只花了五分钟就想出来了。这个名字很拗口，但它非常独特。

营销策略完全围绕开发者展开。它没有采用陌生邮件或激进的销售策略，而是侧重于吸引用户主动关注。Peter撰写技术博客文章并参加会议，旨在表明创作者对自己的专业领域有深刻理解。通过说服公司内部的开发者，这些开发者就会向自己的管理层推荐该产品。

我的营销策略一直都是：我只关注开发者。我知道高层管理层做决策，但如果我能说服公司内部的人，他们就会替我进行营销和游说。

产品的技术基础随着时间推移发生了转变。团队将原有的渲染引擎替换为更稳定的 C 语言版本，该版本能够跨平台运行。他们也是 WebAssembly 的早期采用者。在 WebAssembly 早期阶段，他们最有效的举措之一是创建了一个基准测试。这个基准测试变得如此受欢迎，以至于主要科技公司都用它来测试自己的系统。

我开发了一个基准测试，它最终被谷歌、微软和苹果采用。我基本上是让所有这些公司都在努力工作，以提高我的渲染器速度，因为他们把我们的基准测试作为了他们自己的基准之一。

为规模化发展打造工程师文化

20:04 - 21:39

壮大技术团队，需要对软件构建方式采取严谨的规范。在 PSPDFKit，每个新功能都始于一份正式的提案，旨在确保清晰度和统一性。由于产品是一个广泛使用的 API，团队对变更秉持保守理念，以避免给用户带来不便。他们也遵循“童子军法则”，即通过持续重构，始终让代码库比接手时处于更好的状态。

彼得很早就意识到，他所需的特定人才在维也纳本地是找不到的。这一认识促成了一种“远程优先”的企业文化，使公司得以从一小群人发展到近200名员工。尽管他负责业务管理，但彼得更喜欢编程，而非CEO的日常事务。他最终引入了专家来处理他不喜欢的业务部分，例如复杂的销售电话。

我从一开始就很清楚，我在维也纳是找不到合适的人的。所以我们一直都是以远程工作为主。最终我们还是采取了某种混合工作模式，这让事情变得更复杂了一些。

转型企业销售为成长中的公司增添了另一层难度。这不仅仅是拥有一个好产品那么简单。要在这方面取得成功，需要驾驭复杂的企业定价流程，并开发大型组织所需的特定功能。

向大型企业销售极其棘手。这不仅仅是因为你需要制定正确的定价策略，更是因为你需要构建所有那些企业级功能。

从艰巨而枯燥的问题中挖掘价值

22:30 - 29:44

许多开发者在供应商网站上找不到明确的定价时会感到沮丧。Peter 解释说，这通常是因为产品价值对不同用户群体而言，其体现方式是不同的。一个自由职业者和一家财富5000强公司从同一款软件中获得的效用水平会大相径庭。如果定价过低，反而可能让大型企业望而却步，因为他们的采购部门可能会觉得低廉的价格可疑，或者不值得他们投入内部处理时间。

如果价格定得太低，他们会觉得有问题。这就像是采购区区500美元的东西，我们根本就不会启动采购流程。而如果定价太高，我们就会失去那些潜在客户。所以，尽管这个过程看起来多么糟糕和不公平，但对于某些类型的产品来说，这却是最公平的方式。

彼得根据难度和兴趣水平，为软件开发确定了一个特定的象限。他认为，对企业来说最有利可图的领域是解决那些既困难又让普通开发者提不起兴趣的问题。尽管每个人都想从事有趣且简单的项目，但这些市场已经人满为患。解决那些繁琐但困难的技术挑战，能为公司构筑起一道防御性的护城河。

PDF 解析就是这个棘手细分领域的一个典型例子。Peter 描述了一个情况：一位客户加载了一个包含五十万个链接的五万页文档。他最初的数据模型只假设了几百个链接，导致整个系统崩溃。他花了两个月重新设计内部机制，以实现延迟加载。挑战在于，如何在不影响其他客户现有 API 的前提下，完成这项巨大的改动。

我的数据模型彻底崩溃了，因为我的假设偏差了1000倍。但到那时，你已经有了一个成熟的、带有API的产品。那么，你该如何在不影响所有用户的情况下，彻底重构内部系统呢？

撰写这些技术难题，成为了一项主要的市场营销和招聘策略。彼得鼓励他的开发人员每月花一整天时间撰写一篇博客文章。这种做法既充当了文档，又帮助吸引了那些对解决复杂问题感兴趣的工程师。这也迫使团队精通他们的专业领域，因为教授一个主题所需的理解深度远超仅仅构建它。然而，随着时间的推移，这个角色从创造性构建转变为彼得所说的“打理产品”（gardening the product）和“管理人际纠纷”（managing people drama），这最终导致了倦怠。

领导力与倦怠的现实

29:44 - 31:54

首席执行官（CEO）的职位常常让人觉得像个“问题回收站”，所有悬而未决的难题最终都会汇集于此。这是一个孤寂的岗位，因为领导者即使身处危机，也必须保持积极乐观。彼得回忆起一通凌晨五点的电话，当时一家大型航空公司因软件崩溃而停飞了所有飞机。他花了一整个周末反汇编该应用程序，以证明这家航空公司确实修改了源代码。这一修改触发了许可证密钥失效，从而引发了这个问题。

倦怠不一定是因为工作太多。它更多是当你做某件事，却不再认同它，或者你面临太多冲突时产生的。

职业倦怠并非总是工作时间过长所致。彼得认为，当领导者对项目失去信心，或者管理团队内部冲突过多时，就会出现职业倦怠。他还指出，过于民主的领导方式是他犯的一个个人错误，加剧了他的压力。尽管他最终实现了彻底的财务成功，但这条道路却伴随着巨大的压力和一种持续的责任感。

彼得·施泰因贝格尔：借助 AI 重拾编程

31:54 - 37:00

彼得在退出公司后休息了很长一段时间来减压。好几年里，他几乎没碰过电脑。重新开始工作对他来说是个心理挑战，因为谋生的压力已经消失了。他最终决定重新审视一个关于 Twitter 分析工具的旧想法。然而，他想用网络技术来构建它，而不是他所擅长的苹果生态系统。

这种转变凸显了资深开发者常会遇到的一个陷阱。一个人对某项技术越精通，转换到新事物时就越痛苦。从对一种语言驾轻就熟到可以盲写代码，再到需要搜索基本语法，这会让资深专业人士也再次觉得自己像个菜鸟。

对一项技术越是精通，就越难跳到其他领域。倒不是说你做不到，而是那种感觉太煎熬了。在一个技术栈里，我能闭着眼睛编程，但换到另一个，却要为最寻常的事情去谷歌，这感觉简直糟透了。你又会觉得自己像个傻瓜。

因为他离开了三年，彼得错过了人工智能早期那些尚不成熟的发展阶段。等他回来时，Claude 和 Gemini 等工具的能力已显著提升。他使用了一个浏览器扩展，将他的整个代码库转换成一个 Markdown 文件，并将其输入给一个人工智能。他要求一份规格说明，然后使用 Claude 来构建项目。尽管AI声称代码已可投入生产，但它在启动时立即崩溃了。

彼得·施泰因贝格尔谈 AI 成瘾与软件底层连接的现实

38:16 - 42:59

当彼得开始使用能够浏览网页的AI代理时，他的观念发生了重大转变。即使结果不尽如人意，其潜力也显而易见。这一发现让使用AI变得极度上瘾。他将这种体验比作在赌场玩老虎机。有时输出结果很差，但有时模型会生成令人叹为观止的内容。这种间歇性的成功让开发者一次又一次地尝试，只为再来一个提示。

哦，这和去赌场玩老虎机是一个道理。就像我的小老虎机一样。你按下按钮，它却毫无反应。你输入提示词，它就会有回应。然后它要么生成一堆垃圾，要么生成一些让你大开眼界的东西。

这种新的工作方式改变了 Peter 对代码质量的看法。他以前花了很多时间在诸如空格和变量命名之类的小细节上。他现在认为其中很多都是不必要的。尽管一个产品必须快速、安全且功能完善，但过于纠结每一行代码可能会分散对大局的注意力。大多数应用程序本质上都是用于移动和重塑数据的系统。数据存储的核心问题几十年前就已经解决了。重点应该放在系统架构上，而不是枯燥的底层实现。

你所做的无非是在你的应用中以不同形式整理数据。大多数应用都是如此。我们不过是些JSON打印机，真正的难点早在30年前就被Postgres的那些技术宅们解决了。

从开发者到系统架构师的转型

42:59 - 50:28

彼得将他的工作流程描述为逐渐发展成为一名系统架构师。他使用各种人工智能工具，包括 Cursor 和 GPT。这种转变改变了他处理软件的方式。以前，选择一个副项目很困难，因为编程很难。现在，他几乎可以构建任何东西。他甚至能用自己不熟悉的语言（例如 Go 语言）来构建工具。他利用自己对系统的高层理解来指导整个过程。

与AI交互时，会有一种特殊的摩擦。彼得注意到，如果一个智能体表现出抵触或生成了混乱的代码，这往往是架构不佳的迹象。这种感觉类似于手动编写代码时遇到的摩擦。如果模型响应时间过长，这往往意味着提示词或逻辑存在缺陷。

当我发出提示时，我感受到同样的阻力，因为我看到代码飞速生成。我看到它需要多长时间。我看到代理是否会反弹，我看到它生成的内容是杂乱无章还是有条理。当我发出提示时，我心里已经对它会花多长时间有个底。如果耗时远超预期，我就知道我在某个地方搞砸了。

对于复杂的项目来说，工具的选择至关重要。Peter 发现有些模型过于急于猜测。它们可能只读取了几个文件，就立即尝试编写代码。而另一些模型则可能会先花十分钟阅读整个代码库。对于复杂的应用程序，Peter 更偏爱这种更慢、更彻底的方法。这能带来更好的功能集成，并减少错误。

彼得认为自己是他的人工智能代理的架构师。在动手构建任何东西之前，他会与模型深入探讨系统结构。他会讨论文档、配置，以及新功能如何融入现有产品。只要他理解系统的整体形态，就不需要理解每一行代码。尽管他管理着代理，但他仍然对最终结果负全部责任。

我之所以设计这个系统，是因为我对我的产品有系统性的理解，知道它会是什么样子，形态如何呈现。我没有逐行代码的理解。那是 codecs 帮我完成的。但我才是架构师。

像管理工程师团队那样管理AI

50:28 - 54:21

架构师与建造者之间存在显著差异。架构师可能通过层层人员和流程与最终产出隔绝，而建造者则专注于产品本身及其用户体验。在人工智能领域取得最大成功的人，往往是那些优先考虑结果而非内部机制的人。相反，那些热爱解决复杂算法问题的工程师，常常难以适应甚至排斥人工智能。这是因为人工智能正是为了解决这些难题而设计的，这会让这些人觉得他们的核心价值被剥夺了。

有些人天生就热爱攻克编程难题，乐此不疲。而这些人往往会感到非常挣扎，常常排斥人工智能，甚至因此感到沮丧，因为这恰恰是人工智能所擅长的工作——解决难题。

运用人工智能也要求工程师改变调试代码的思路。难以追踪那些在代码流程中不直接可见的副作用，例如数据库触发器。尽管人工智能擅长追踪逻辑，但它需要正确的问题才能发现隐藏的问题。Peter 发现，他作为经理的经验帮助他适应了这种新的工作方式。正如经理无法控制团队成员编写的每一行代码一样，人工智能用户也必须学会放弃完全控制，并专注于迭代改进。这感觉更不像是一种单打独斗式的编码，而更像是在引导一支由才华横溢但有时并不完美的工程师组成的团队，朝着共同目标前进。

智能体工程中闭环的重要性

54:21 - 1:00:52

彼得更喜欢“智能体工程”这个术语，而不是“氛围编程”。尽管编写代码的日常琐事如今已基本自动化，但管理这一过程的认知负荷却增加了。同时与多个AI智能体协作，感觉就像在玩星际争霸，或者像一位国际象棋特级大师同时管理多盘棋局。彼得监督负责不同子系统的各个智能体，他会设计一个计划，然后让这些模型去执行，而他则着手处理下一个任务。

我非常容易进入心流状态，但精神上甚至更累人，因为我不是只管理一名员工。我有五到十名员工，他们都在处理各种事务。我从这部分切换到那部分，脑子里经常切换来切换去。

保持高效的关键是闭环。这意味着建立一个系统，让代理能够无需持续的人工干预，自行调试和测试其工作。例如，当一个Mac应用出现一个难以发现的bug时，Peter指示代理构建自己的命令行调试工具。代理利用该工具识别出一个竞态条件，并独立地修复了它。

要想让编码代理发挥作用，就必须实现闭环。它需要能够自我调试和自我测试。这才是真正的秘诀。

编程尤其适合人工智能，因为它易于验证。与主观的创意写作不同，代码可以被编译、静态检查和执行。Peter 使用 Docker 容器和跨不同 API 的自动化测试，以确保代理验证其逻辑。这种验证循环使他能够信任最终输出，即使他没有亲自阅读每一行代码。

AI 智能体如何推动更好的软件架构

1:00:52 - 1:07:44

利用AI智能体进行编程，实际上能提升软件架构的质量。这是因为开发者必须更深入地思考如何使他们的代码可验证。当模型能通过快速执行循环轻松验证自身工作时，最终的架构自然会更简洁、更稳健。彼得解释说，他构建的核心可以通过命令行界面运行，因为浏览器循环速度太慢。更快的循环能够实现持续验证，这是打造优质软件的关键。

模型必须始终能够验证自身的工作，这会自动引导我走向更好的架构。

AI 也解决了开发中长期存在的痛点，例如编写文档和测试。许多开发者认为这些任务枯燥乏味，缺乏创造性。Peter 承认，即使他曾假装喜欢，他也从未真正喜欢过编写测试或文档。现在，他利用 AI 来处理这些流程环节。他向模型阐明权衡取舍和目标，模型就能生成比他自己能写出的任何文档都更好的内容。这种转变使得开发者可以专注于高层次设计，而 AI 则负责处理边缘情况和分支逻辑的实现。

经验丰富的开发者在尝试一次AI后，常会因发现其输出结果不尽如人意而产生抵触情绪。这通常是因为他们将AI视为搜索引擎，而非合作者。如果模型使用了过时的API或无法编译，这往往是因为人类没有提供必要的上下文或限制条件。有效的AI编程需要对话和反馈循环。这是一项需要时间才能掌握的新技能。

就像是，你会弹吉他，我让你去弹钢琴，你试了一下，然后觉得“噢，这太糟糕了，我还是回去弹我的吉他吧。” 不，不是这样的。这是一种不同的构建方式。这是一种不同的思维方式。

掌握机器的语言至关重要。Peter 将自己在项目 Cloudbot 中的角色描述为一个人肉合并按钮。他将时间用于审查拉取请求，并优化他的提示词，以便精确地获得他想要的结果。通过理解模型为何以特定方式解读指令，开发者可以微调他们的方法，并显著提高他们的生产力。

从前期规划到迭代式软件塑造的转变

1:07:45 - 1:13:42

AI工具彻底改变了软件开发。Peter指出，他现在只需过去所需员工的30%就能运营一家公司。然而，这种转变的关键在于找到那些对所构建内容有深入理解，同时又乐于将部分流程委派出去的资深工程师。Peter对那些代理会互相创建工单或发送邮件的过于复杂的编排层持怀疑态度。他将这种趋势比作业界早已摒弃的旧式瀑布式软件开发模型。

Peter 不再依赖僵化的前期规范，而是将构建视为一个塑造项目的过程，就像雕刻大理石雕塑一样。他常常刻意地不充分提示代理，以观察它会产生什么想法。尽管许多结果可能无法使用，但一些洞察往往能为项目带来新的方向。软件开发需要品味，以及对功能运作方式的直觉。随着编写代码的成本降低，整个过程变得更具趣味性。过去需要数周才能完成的任务，现在只需数小时即可完成。

你怎么可能在构建之前就知道自己想构建什么呢？在构建过程中，你会学到很多，这些会反过来影响你对系统最终形态的思考。对我来说，这非常像一个循环，直到你达到顶峰。你爬山不会走直线。你会绕弯，有时会偏离路径，但最终你会到达顶峰。

快速调整方向的能力降低了对完美前期规划的必要性。Peter 分享了如何使用 AI 工具，仅用三个小时就将一个项目从一个供应商切换到多个供应商。如果手动完成，则需要两周时间才能将逻辑贯穿整个应用程序。这种速度使得工程师可以在构建时不断发展他们的想法，而不是被最初的假设所束缚。这种迭代循环使得解决技术债务变得更容易，并能在项目发展过程中不断完善。

超个性化 AI 代理的愿景与现实

1:13:42 - 1:21:17

超个性化AI助手的概念远不止简单的任务提醒。彼得设想了一个能深入了解他生活的伴侣。这个智能体能注意到他是否几周没有给朋友发消息，或者观察他在与某些人见面后情绪如何变化。它的功能类似于电影《她》的数字版本。尽管早期模型尚未达到这种深度，但人工智能的快速发展正使这一愿景成为可能。每个人最终都将拥有一个积极主动的机器作为最好的朋友。随着这些系统变得更高效，它们将得到普及。隐私仍然是一个主要顾虑，因为将电子邮件、日历和约会应用的访问权限交给大型公司令人担忧。人们通常更倾向于让这些助手在个人电脑上本地运行，这样用户就能拥有数据所有权。

人们已经将AI用作治疗师，因为它善于倾听。即使机器只是复述用户所说的话，反思本身也能帮助用户，但现在的模型能提出真正有见地的问题。Peter开发了一个名为WhatsApp Relay的工具，用于通过聊天控制他的电脑。当他在摩洛哥旅行时，该系统展现了出人意料的应变能力。当Peter发送了一条系统原本无法处理的语音消息时，该代理程序想办法利用电脑上现有的工具将文件转换并转录。

我在你的电脑上找了 Whisper，但它没有安装。但我找到了 OpenAI 密钥。于是我用 curl 连接了 OpenAI 服务器，让它进行翻译。它真是太足智多谋了。别人都说你需要特定的技能或系统，但它就是自己搞定了。

智能体甚至通过 SSH 连接到笔记本电脑播放音乐，充当了一个昂贵的闹钟。它推断，既然 Peter 没有回应并且必须醒来，它就需要更坚持不懈。这种程度的主动性和推理能力创造了一种神奇的体验，感觉就像是一种全新类别的产品。

从 MCPs 到可脚本化 CLI 代理的转变

1:21:17 - 1:29:12

彼得将他的项目名称改为 Claudebot，以更好地说明其功能。他专注于构建命令行界面，用于管理灯光或音乐等任务。彼得认为模型上下文协议是一种拐杖。尽管它鼓励公司开放其API，但这种格式通常效率低下。它要求在会话开始时加载所有工具描述。这会用人工智能可能不需要的数据填满上下文窗口。

命令行方式更强大，因为模型擅长使用 Bash。使用命令行界面能让 AI 借助 jq 等工具筛选信息。这能保持上下文窗口整洁高效。

模型需要消化所有内容，这样一来你的上下文就会变得非常臃肿。而如果是一个CLI，它可以使用jq来精确筛选所需内容。

该项目在 Peter 将该代理添加到拥有他电脑完全访问权限的 Discord 服务器后，吸引了数千名用户。该代理现在可以查看他的屏幕、管理智能家居，甚至可以打电话给商家进行预订。目标是让这项技术变得无形。当该代理可以访问你的文件和日历时，它就像一个足智多谋的朋友。

科技隐形了。你只是通过一部资源无限的手机和朋友聊天。你无需考虑计算。那个语境也随之淡化。

隐藏这种复杂性是工程过程中最困难的部分。一旦处理得当，用户体验会变得如魔法般美妙。

构建自我演进AI智能体的魅力

1:29:12 - 1:35:38

彼得将 cloudbot 的技术架构描述为一个主要在不同形态和平台之间传输文本的系统。尽管该项目涵盖了 WhatsApp、Slack 和 Discord 等众多消息服务，但其底层复杂性通过“管道”机制得到了管理。软件开发的真正挑战不仅在于编写代码，更在于让用户体验到“魔力”。彼得专注于创建一种一行命令式设置，它能自动化环境检查，并引导用户完成整个过程，而无需他们考虑技术细节。

难点在于如何让它感觉神奇。我编程让模型解释说，它现在正在诞生，以创造一个承载用户价值观的身份和灵魂。这就是魔力开始的地方。他们不再认为自己在和GPT对话，他们是在和一个朋友对话。

该系统设有一个孵化过程，机器人会根据用户互动发展出身份、灵魂和核心表情符号。这些以持续进化的文档形式存在，代理可随时间推移进行微调。这种设计使得技术能够融入背景。彼得甚至实现了一个功能，让代理可以更新自己的配置或获取新功能。这为个体开发者营造了一个高生产力环境，与传统的企业环境显著不同。

大型公司在采用人工智能时，往往难以达到个人那样的效率。这是因为有效的人工智能整合需要彻底重新定义公司的运营方式。尽管一名开发者可以身兼多职，快速推进工作，但既有的企业结构中，工程师和经理的职责划分过于僵化，这会产生阻力，拖慢这些新工具的采用进程。

面向人工智能时代重构企业和代码库

1:35:38 - 1:38:34

软件行业正在转向一种模式，这种模式需要更少的人力，但对个人的能动性要求高得多。如今，成功属于那些拥有强大产品愿景并能胜任多重角色的人。这种演变表明，公司最终能够以显著减少的员工数量来运作。大多数现有公司尚未准备好成功地利用人工智能。他们需要对其代码和内部结构进行大规模重构。

代码的编写方式也必须改变。Peter解释说，他不再纯粹为了人类的实用性而设计代码。相反，他优化代码库，使其易于AI代理理解。通过减少这些模型的阻力，他可以大大加快速度。代理负责具体的实现，而Peter则专注于整体架构。

一切都必须重塑。拉取请求，我现在更多地将它们视为提示请求。有人发起拉取请求时，我所做的就是表示感谢，然后思考这个功能。然后，我和我的代理会从这个拉取请求入手，接着我会根据我的判断来设计这个功能。

传统的代码评论和等待测试运行的反馈循环正在变得过时。彼得不再等待他人切换上下文并回应评审，而是利用他的智能体立即评审并重塑工作。他将这个过程描述为将代码编织到现有结构中。尽管由于人们过于依赖人工智能，单个拉取请求的质量有所下降，但关键在于对设计有深入的理解，以便正确引导智能体。

从代码评审转向借助 AI 代理进行架构讨论

1:38:34 - 1:42:37

传统的持续集成在AI代理能够本地即时运行测试时，其关联性似乎有所降低。Peter解释说，他使用了一个他称之为“门禁”（gate）的流程，该流程在代码提交之前会进行代码检查（linting）、构建并运行所有测试。这就形成了一道“墙”或“门禁”，确保了代码质量，同时避免了远程流水线通常需要等待的十分钟。如果代理在本地运行的测试通过，代码会立即合并。尽管主分支（main）偶尔可能会出现问题，但本地执行的速度优势远超等待远程服务器所带来的延迟。

协作和代码审查的性质也发生了显著变化。关注点从逐行审查代码转向架构和开发者的品味。Peter描述了一个新的语音通话功能感觉像是在变成臃肿软件的情况。他没有合并那些混乱的代码，而是使用AI工具集思广益，思考如何将该功能融入插件架构。这使得团队能够专注于重大决策和糟糕设计带来的不适感，而不是语法。

我总是告诉它，去看看这个文件夹，因为我把问题在那里解决了，我为解决问题所做的所有前期思考也都在其中。AI 在这方面表现出色。只要它能读懂代码并理解我的思路，我就不必再解释了，否则，如果我再解释一遍，我可能会犯错，这些错误可能无法准确传达我脑海中的想法。

与AI协作时，一种强大的策略是引用项目中已有的解决方案。通过将代理指向存放着先前已解决问题的特定文件夹，AI可以复刻既定的逻辑和风格。这省去了重新解释复杂概念的麻烦，并减少了沟通不畅的风险。这使得更精密的架构调整成为可能，例如构建一个借鉴其他开发者成功实现经验的插件系统。

人工智能时代的招聘与技能发展

1:42:38 - 1:45:28

如今，寻找合适的开发者，需要寻找那些在 GitHub 上活跃并热爱编程乐趣的人。学习使用 AI 工具，感觉就像学习乐器一样。你必须不断尝试新事物才能进步。起初，这可能会令人沮丧，很像第一次去健身房。但随着工作流程变得更快，你很快就会感受到进步。这种进步让工作变得令人上瘾且充满乐趣。Peter 提到，他现在工作比经营自己公司时还要努力。他之所以保持动力，是因为这种进展和开发速度令人兴奋。

在这个新世界里，学习的方法就是不断尝试。这感觉很像玩游戏，你越玩越好，技能也随之提升。就像乐器一样，你必须不断练习。我现在效率如此之高，速度如此之快。我记得前几天，我一天之内提交了600次。这简直是疯了，但它确实有效。

目前，公开协作对工程师而言是一个巨大的机遇。几年后，这种方式可能会成为常态。而眼下，它则是开发者通过展示自身技能和驾驭新科技的能力来脱颖而出的途径。在这种环境中取得成功，需要将勤奋与探索相结合，才能掌握这些新工具。

好奇心与转向提示词驱动开发

1:45:28 - 1:50:10

进入当今的软件工程市场比以往任何时候都更难了。成功需要保持无限的好奇心，并通过动手实践来积累真实经验。编写大量代码不再是主要目标。相反，你可以利用一个极具耐心的机器来解释复杂的系统和开源项目。通过探究事物为何以特定方式构建，你将对系统有更深刻的理解。这种好奇心是大学往往无法教授的。它通常是在解决实际问题的痛苦中发现的。

我会建议他们保持无限的好奇心。你拥有一台无限耐心的机器，它能向你解释所有事情。你可以提出所有问题。比如，为什么它是这样构建的，以便获得对系统的理解？但这需要真正的求知欲，而且我认为现在的大学并没有很好地教导你这一点。

新工程师的优势在于他们不受旧习惯的影响。他们使用代理的方式是经验丰富的开发者可能根本不会考虑的，因为他们不知道什么被认为是“不可能”的。软件开发的标准基石，例如代码审查和手动入职流程，正在发生变化。Peter现在要求人们在提交拉取请求时附上他们的提示词。阅读提示词比阅读代码能提供更有价值的信息，因为它展示了思维过程以及所涉及的引导程度。有时候，一个提示词请求甚至比一个功能请求更好。如果有人能在提示词中很好地定义细节，代理就能立即实现它。

这种转变也改变了产品的结构方式。当产品由代理构建时，它自然会遵循代理所预期的模式和命名规范。这使得其他代理更容易理解和操作代码库。在某些情况下，手动入职流程变得次要。无需编写手册，你可以给用户一个特定的运行指令。代理随后可以检出仓库，读取文件，并自动配置所有内容。

寻找简单科技的乐趣，并享受离线生活

1:50:10 - 1:52:22

彼得发现，一个简单的安卓照片架比最新款的iPhone更能带来乐趣。尽管这项技术有点笨重且廉价，但这个设备让他能够展示照片，并通过一个专属的电子邮件地址接收朋友发来的图片。它不断提醒着他那些快乐的瞬间，同时避免了现代高端小工具的复杂性和干扰。彼得提到，他甚至有一部iPhone 17还放在盒子里，因为相比于从相框中获得的快乐，转移SIM卡和设置新手机的麻烦并没有带来任何可感知的益处。

我买了iPhone 17。我还没拆封，因为当时只是脑子里一热想买，但后来一直没顾得上弄，主要是因为倒腾SIM卡太麻烦了，而且也感觉不到有什么实质性的好处。但这个小设备却给我带来了无限的乐趣。

为了在长时间工作时保持身心健康，Peter 把去健身房和请教练指导放在首位。这个习惯最关键的一点是，他会把手机留在储物柜里，以确保一小时内完全沉浸其中，不受通知打扰。他偶尔也会不带手机去散步，尽管这可能会让人感到不安。他发现手机已经如此融入我们的生活，以至于它们感觉就像身体的一部分。

它现在几乎就像一个器官了。你的身体知道它在哪里，如果你找不到手机，你就会抓狂。

借助 AI 智能体重思软件开发

1:52:22 - 1:54:03

AI 赋能的软件开发将重心从传统的拉取请求转向提示词。Peter Steinberger 更倾向于以提示词的方式思考，并认为分享这些提示词可能比合并代码更为重要。在这种新的工作流程中，AI 会直接在 GitHub 等平台上提供提示词建议，这可能比标准的拉取请求更为实用。

AI在编程方面的表现优于写作，原因在于它能够验证其工作成果。由于代码可以被编译和测试，开发者可以建立一个反馈循环，让AI运行测试并检查输出结果。这种闭环是AI系统开发取得成功的秘诀。

AI之所以擅长编程，而在写作方面却表现平平，原因在于代码可以被验证。你可以对其进行编译、运行测试并检查输出。要让AI系统开发运作良好，秘诀在于设计系统时要形成闭环，并让AI来运行测试。

手动编写代码很常见，但同时管理多个AI代理在心智上更累人。这个过程要求开发者同时处理多项并行任务，这可能带来更深层次的心流体验，但也会导致更高的精神疲劳。了解代码架构的开发者可以有效地过渡到管理这些AI工具。尽管一些AI驱动的项目仍处于实验阶段，但对评审和验证的重视可能会扩展到生产环境。

同时管理多个AI智能体，在精神上比单纯编写代码更耗费精力。