# #520. PI的极简哲学与AI编程反思：为什么我们需要慢下来？
一凯: 欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目，通过先进的AI声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的AI财经，健康与科技领域精品内容，我是主播一凯，一位热衷于AI领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁，接下来让我为您简单介绍本期我们克隆的这档节目 [00:00:00 → 00:00:34]
并分享几句非常精彩的原话，本期我们克隆的是全球知名科技播客 The Pragmatic Engineer的一期深度对谈，这档节目由资深软件工程师Gergly Oros主持，这次他与两位奥地利嘉宾Marionar和Armin Ronaker坐下来，聊了聊时下最受关注的AI编码智能体PI Mario是PI的创建者 Armin则是著名Python框架Flask的作者，也是PI的早期核心用户，节目里有几段原话让我印象特别深 [00:00:34 → 00:01:08]
Mario非常直白地讲出了很多人的感受，那些公司都说代码全是智能体写的，没错,我们都知道质量是垃圾，我们用你们产品的时候，骨子里都能感觉到真的就是垃圾 Armin则从另一个角度谈到工程师的成长，如果你没有经历过那种伤疤，你实际上很难有效地说服别人，因为正是这种学习过程，才给了你在工程团队里说服其他工程师的权威 Mario还补充了一句，当痛苦变得足够大，作为人你就有动力去解决导致痛苦的根源 [00:01:08 → 00:01:43]
那我们就一起进入这期完整对话，听听他们如何在效率与质量之间守住工程的本心 [00:01:43 → 00:01:51]
Gergely Orosz: 我们能不能先聊聊，你当初为什么决定做PI的背后故事，我个人很喜欢简单稳定，我能靠得住的工具，哪怕他们有些部分是非确定性的都行 [00:01:51 → 00:02:04]
Mario Nahr: 所以你可以让派去修改，他自己PI本来没有MACCP 但大家就直接让PI去给自己加MCP支持，非工程师也能参与，但参与到工程过程中去 [00:02:04 → 00:02:17]
Armin Ronacher: 这件事本身就有意义，比如现在我们可能有个产品经理想试个功能, 但又不想浪费工程师的时间, 这事现在就能做, 但问题是, 大家现在都太盯着人人都能做所有事了, 以至于忘了你还是得处理好护栏, [00:02:17 → 00:02:31]
Gergely Orosz: 所有这些, 不过, 你最近刚写过, 我们所有人真的需要慢下来, 那些公司都说代码全是智能题写的, 没错, 我们都知道质量是垃圾, 我们用你们产品的时候, 骨子里都能感觉到, 真的就是垃圾, 我觉得人们需要, 如果我告诉你 2026年最有影响力的AI编码智能体之一，其实是由奥地利的一位开发者，一个人做出来的 [00:02:32 → 00:02:58]
Peter Steinberger: 而原因是他对现有的那些 AI编码智能体太失望了，你会怎么想，这就是波波一个极简，能自我修改的编码智能体，他已经悄悄的成了那个，人气超高的个人AI助手 OpenClaw背后的引擎 Mario Nahr是PI的创建者，今天和他一起的是Armin Raunaker Flask的创建者，现在也是PI的早期使用者和贡献者 [00:02:58 → 00:03:30]
在今天的节目里我们会聊PI的背后故事，为什么用AI智能体来做自我修改的软件会容易得多 Armin在采访了30多个工程团队之后，学到了什么AI智能体正在怎么改变它们的工作方式，为什么软件质量感觉在走下坡路反对MCP的理由，为什么C变得这么流行，还有好多别的 [00:03:30 → 00:04:01]
如果你想听行业里两个非常冷静的声音，坦诚地聊聊什么管用，什么不管用，以及为什么我们整个行业都需要慢下来，本期节目就是为你准备的，那么我们这就进入正题吧 Mario和Armin非常高兴你们能来上节目，谢谢邀请，谢谢你们 [00:04:01 → 00:04:26]
Gergely Orosz: 那么作为开头Mario你是怎么进入技术圈的，最后又怎么开始做AI的东西，那说来话长了，我们有多长时间，实际上我是90年代的小孩 [00:04:26 → 00:04:38]
Armin Ronacher: 我在1996年有了第一台电脑，其因是我特别喜欢电脑游戏，我们家说不上穷，但也是干活挣钱的，所以买不起gameboy和90s那些东西，但我有个叔叔，他有一台mega500 我隔天就去他家逛玩游戏 [00:04:38 → 00:04:51]
Mario Nahr: 后来我爸妈跟我说，你要是打工自己攒钱就能买一台电脑，但实际上我爸会去做点，怎么说呢，就是那种不太交税的事，对，所以他就是正常上班 [00:04:51 → 00:05:03]
Gergely Orosz: 正常下班之后再去修车，去工地干活，对就这样，这在欧洲挺普遍的，我知道好多人都这么干，对过了大概两三年，他们就觉得是时候了 [00:05:03 → 00:05:16]
Armin Ronacher: 带我去了附近大城市的一家电脑店，给我买了一台486 我就是这样开始的，基本上就是一台486 而且是一台486DX 4E 赵和姿，带 Turbo 按钮的，那就是我起步，我一直都很喜欢游戏，后来也由此接触了图形编程，很幸运，我在上大学的时候，在一家应用科学机构找到了工作，他们当时做的是自然语言处理和机器学习，应用机器学习，就是把研究成果往工业应用里塞，我就是在那入了机器学习的门，那还是深度学习活起来之前的事 [00:05:16 → 00:05:51]
后来我在2010 11年的样子离开了那个领域，因为我加入了旧金山的一家创业公司，再后来又回来，跟两个朋友在瑞典开了另一家创业公司，我们做了一个提前编译器，把一种语言编译到iOS上，那个公司后来卖掉了，从那以后 [00:05:51 → 00:06:07]
Gergely Orosz: 我的时间稍微多了一点，但一直在跟进机器学习的东西，因为实在太有意思了，再然后GPT就出来了，就是这样，然后我们就到这了，那么Armin你的，你的根在哪 [00:06:07 → 00:06:20]
对谈参与者: 我的出生肯定不是那种，干体力活的，倒不是这样，因为我父母开了一家建筑事务所，他们很早就用电脑做CAD绘图，我的第一台电脑，就是他们淘汰下来的旧电脑，我虽然年纪更小，但我第一台电脑是一台386 我真的很同情你，我基本从来没有过一台，能好好跑电脑游戏的电脑，因为一来，他们装的是，当时啥也干不了的Windows系统，你得自己想办法绕着走，唯一能让游戏跑起来的方式，是在系统还没进Windows95 [00:06:20 → 00:06:54]
或者Windows3.1之前，先切入DOS模式，我玩的是那种很老的DOS游戏，那会儿其实已经有更好的东西了，但因为这种限制，我就开始瞎玩Quick Basic和Turbo Pascal 还买了一堆相关的书，这些东西就成了我理解计算机工作原理的根基，老实说我从来就没真的擅长过，但就是觉得特别有意思，那种不说真的，我真的不擅长的感觉，这就是那个德国人吧，不我向你保证，我刚开始搞这些的时候，真的菜得一塌糊涂 [00:06:54 → 00:07:27]
不过只要你一直坚持，总会慢慢变好，然后到了2002或者03年，我有一段时间大量用Delphi 那玩意儿算是Turbo Pascal的可视化版本，也是在02、03年那会儿，有人给我看了，因为我当时一直有想法要改用Linux 结果Delphi在Linux上跑不了，我就找到了Python 于是开始写一些Python程序，那时候Ubuntu刚在04年出来，那是个风头支持的发行版，但它在各地建了很多本地社区，有点像Ubuntu协会之类的东西 [00:07:27 → 00:08:01]
所以我和一帮朋友就搞了一个，德国Ubuntu基金会，不是基金会了，是个协会，我们运营了一个叫Ubuntu用户的，在线社区，搞了四五年，因为Ubuntu很火，社区规模膨胀，各种扩展问题就来了，我就是这么掉进web开发坑里的，为了搭这个社区，我自己想造一个模板引擎，一套web库，诸如此类，最后我把它们打包在一起，做出了Flask这个框架，结果变得非常流行，即使在今天这框架依然有人在用，我觉得像Cloud这样的东西，有时也会直接往外吐他的代码，挺逗的 [00:08:01 → 00:08:35]
不过后来我就没再继续维护他了，之后在2013、14年间，我在伦敦做了几年电脑游戏，再然后又回归开源 [00:08:35 → 00:08:44]
Mario Nahr: 在Century干了十年，直到去年4月离开，想尝试点新事情，你们俩都是奥地利人，事实上你现在也还住在奥地利，对吧，你之前做游戏 [00:08:44 → 00:08:57]
Peter Steinberger: 又在Century工作过，更早也做过游戏，而第三个人，虽然今天不在这，但前不久刚上过这档播客的 Peter Steinberger 同样来自奥地利，挺有意思的，你们俩现在碰上了，我想问的是，你们三个是在哪认识的，我最近看到一些照片，尤其是OpenClaw和PI启动之前 [00:08:57 → 00:09:23]
Mario Nahr: 你们三个人聚在一起，捣鼓AI 做各种实验，我觉得我们俩是在网上认识的，对吧，在Reddit上，怎么说呢，其实我在大学的时候肯定见过你一次，但那时候你没认出我来，而且我当时挺没用的，当然我已经小有名气了，不过没错，我们算是抽象的在互联网上认识的，但我们后来还是在维也纳线下见了面，我们在网上经常互相打吵，不过方式挺可爱的 [00:09:23 → 00:09:50]
Armin Ronacher: 完全没有对抗性，即便我们在很多方面想法并不一致，那也是一种很有修养的交流，我觉得挺棒的，至于Peter 基本上就是六度分隔Peter Steinberger 我当时在我镇上一间办公室工作，那家公司免费给我工位，交换条件是我给他们CEO当导师，而那家公司跟Peter的PS PDF Kit 有些业务往来，后来他来到格拉茨的办公室，我想呢就是我们第一次碰面，同年我们在伊斯坦布尔的一个会上 [00:09:50 → 00:10:16]
Gergely Orosz: 又遇到了一起跑了整整一晚，差不多就从那会开始了，不错，那后来是怎么，做了那个，你们俩是怎么从对AI这些工具，持怀疑态度 [00:10:16 → 00:10:29]
Peter Steinberger: 后来转变过来的呢，要知道到2022年那会儿，你们都已经在不同领域，构建复杂软件，至少十多年了，你们的第一反应是什么 [00:10:29 → 00:10:42]
Gergely Orosz: 后来又是怎么一步步走到这东西，其实相当有意思，这一边的，对我来说我记得是 2022年GitHub Copilot 出来的比RPT还要早，对是在2021年 [00:10:42 → 00:10:54]
Armin Ronacher: 没错因为我之前创业的经历，我跟Ned Friedman和Zimmering的，米格尔迪，哈萨都认识，他们收购了，我之前提到的那家，做Java编译器公司，我因为早期创业的事，认识了Netty 后来他去了GitHub 2022年那会儿，他应该是在我的私信里问我，想不想用GitHub Copilot 那个哒哒哒的自动补全功能，我当时想的是，我其实不太在乎，我不觉得这个东西能走多远，他说不是，兄弟，这就是未来，你得试试，这就是未来，于是我就试了，结果体验，烂得一塌糊涂，不过到了GPT出来以后 [00:10:54 → 00:11:28]
尤其是他们开放API访问之后，我做了很多项目，专门去摸清楚哪些行，哪些不行，不限于编程领域，后来他们加入了工具调用，或者OpenAI当时叫函数调用，那个时候事情才变得非常有意思，但要说到真正觉得有用，差不多是到2024年年底 10月份左右，那时编程智能体才开始变得靠谱了，然后到了2025年 Claude Code的团队推出了Claude Code 并引入了Chantic搜索，说白了就是给智能体一个途径，让它能在你的文件系统里翻找，读取所有文件 [00:11:28 → 00:12:02]
这一下就完全不同了，之前那些东西，比如Cursor的索引啊，各种基于RAC的，向量数据库的方案啊，瞬间都相形见处，我知道Chroma的CEO听了可能会不高兴，但实话实说，关键的区别就在于，它不是那种稠密稀疏搜索那一套，而是直接给智能体开放你的文件访问权，对我来说 [00:12:02 → 00:12:25]
Mario Nahr: 正是这一点，让整个事情突然就通了，我觉得我的经历，其实挺相似的 Copilot出来的要早不少，但我知道GitHub 当时有一个项目，好像是什么维护者小组之类的，让我提前用上了Copilot [00:12:25 → 00:12:38]
对谈参与者: 我当时就觉得，这东西会很有意思，但完全不是现在这个样子，因为我在开源圈里，待了这么长时间，看到他们竟然用开源数据，来训练模型，我第一反应是，这事至少会闹出很大争议，我那时候根本没想过，它能提升多少生产力，只是觉得用开源数据训练，这肯定会是个争议事件，我还记得，我几乎是想方设法去试探它，看看它到底会不会 [00:12:38 → 00:13:05]
Mario Nahr: 卡马克的逆平方根，不不，我是在用一种对抗性的方式试探它，我测试的一个点就是，它会不会复述出GPL代码，我记得有一次我让它吐出了，卡马克的逆平方根 [00:13:05 → 00:13:17]
对谈参与者: 卡马克的快速逆平方根函数，对吧名字非常特别，所以很好回想起来，但我还发现，如果你用某种方式去戳它，它会在代码上面加上，完全错误的许可证文本，这段代码本来应该是来自，某个GPL开源项目的，如果它真按原样输出，那应该是GPL的代码，结果它却把一个随机人式的 MIT许可证给附上去了，我当时就想 Copilot先生，这你可搞错了，那条推文当时火得一塌糊涂，然后很多人开始跟我分享各种东西 [00:13:17 → 00:13:51]
因为我那时候其实并不了解，那些实验室里AI真正的进展，是的，我本来不是AI或机器学习圈子的，在大学里我只知道有AI寒冬这回事，然后觉得后来就没什么进展了，但因为那条推文和其他一些事，我意识到这里面确实有点东西，有些公司的CEO是真心相信这能成，于是我才开始关注，我那时用API设了各种东西，比如能不能自动修bug 慢慢地越来越感兴趣 [00:13:51 → 00:14:19]
Mario Nahr: 但当时完全不觉得世界会因此而改变，直到那个什么，而且你对天哪，他在to开源代码，他都记住了，这件事态度也变了，因为这么多年来 [00:14:19 → 00:14:31]
对谈参与者: 我个人的主张一直是我希望大家多分享，我觉得人类的进步，就是靠彼此在前人的基础上构建，我非常支持美国那种做法，你可以把知识从一家公司带到另一家公司，而不会有经验限制，我挺喜欢这种高等教育的知识分享方式，所以对我来说，最理想的状态是专利根本不存在，或者至少受到极大限制，因此我并不在乎他，吐出GPL代码和乱加许可证，我当时想的是，这说不定能彻底干翻版权体系，如果最终结果是那样 [00:14:31 → 00:15:05]
我完全没问题，所以一开始这确实挺有意思的，他等于是制造了这种许可证违规，我就想看看，这到底能引发多大的混乱，而到现在，我觉得主要产生了一种强烈的信念，美国现有的版权体系其实有一些预设前提，而我们目前是故意忽视这些，因为大家想先把局面搅乱，然后可能再重新制定规则，毕竟从理论上看，按照历史上对版权法的解读，我们现在产出的很多东西，很可能根本不受版权保护 [00:15:05 → 00:15:39]
我觉得有好多发现，其中一点也不意外的是，每当人们休假的时候，他们就会花更多时间去尝试这些工具，对，很多不同的人，比如像欧洲那些恐龙级别的公司，比如我说的欧洲恐龙公司，比如西门子那种，我也跟一些处于关键领域的公司聊过，我所说的人们休假时采用工具，意思是当你的CEO或技术主管跑来说，你现在必须用Cursor 你现在必须用Claude Codes 你其实并不会立刻领悟，因为你需要花上两到三周的时间，才能真正上手找到感觉 [00:15:39 → 00:16:13]
我一直觉得我所认识的那些人，包括我自己，都是有大量空闲时间的，比如我从4月到10月离开了公司，我就一头扎了进去，我想的是，这玩意儿怎么会有人不明白，那简直是猫拨和上头，疯狂上瘾，我觉得都睡不好，但在公司内部，实际情况是，感恩节假期，对欧洲人来说是夏天，还有圣诞节，大家会在这些时候获得免费额度，于是越来越多的人开始尝试，会慷慨地赠送很多使用额度，所以越来越多的人开始用上了，尤其是圣诞节之后 [00:16:13 → 00:16:48]
我估计在我聊过的公司里，超过一半在圣诞节后，真的是爆发式采用，而且爆发的形式，也完全在意料之中，突然之间代码质量就下降了，但这不一定是因为，大家想写出更差的代码，而是因为要保持代码质量不下降，反而需要额外花力气，我们去年夏天在创业圈，已经看到这种现象了，如果你留意YC的初创公司，他们中有一些会把代码放在GitHub上，或者有一段时间放在上面，你可以去看看，那时候他们会迁入类似planMD这样的文件 [00:16:48 → 00:17:23]
所有东西都标明归属到云，那种氛围式编程主要用来做原型什么的，这已经非常明显了，但后来逐渐演变成，一部分代码库里开始掺杂了一点氛围编程的味道，更有意思的是，现在工程团队和公司是如何应对这种情况的，有各种不同的发现，但很大一个挑战是代码审查 PR越来越长，而且变得非常很耗心神，是的，而且那些PR里的很多代码 [00:17:23 → 00:17:56]
工程师自己是不会那样写的，因为作为一个工程师，你在提交某些代码时，心里会非常不安，你会替未来的自己着想，但智能体根本不在乎，我经常讲一个故事，当年我在做一款Xbox One游戏，正好赶上Xbox One发布，那是个必须在固定日期发布的死线，我当时在开发光环，事关掌和集，里面有一个匹配组件，那真是全员上阵，大家得去清理人类，自己制造出来的一团乱麻，那个匹配系统，那个系统状态多到离谱 [00:17:56 → 00:18:29]
我们把它叫做永线式状态机，它里面有16个波尔值，理论上只有6种有效状态，但实际可能的状态数，是爆炸性增长 AI生成的代码就是这种感觉，它本来应该是一个定义清晰的系统，但现实中它却是这样，工作配置加载不了，那就捕获异常，然后加载默认配置吧，结果原本应该直接失败的地方，现在却试图恢复，这样一来你的代码就比原本复杂多了，因为它进入了更多意料之外的失败状态，这就让你很难继续维护这些代码 [00:18:29 → 00:19:03]
Mario Nahr: 而且你也很难让智能体去反思整个应用，说这种情况也可能发生，所以我们得保留这个遍体，我觉得情况甚至比你描述的那种人为打造的复杂系统还要糟糕 [00:19:03 → 00:19:14]
Armin Ronacher: 因为智能体有时会灵光一线输出完美又简洁的代码，恰好是你不需要的那类东西，而且代码量不多不少，因为资深工程师看到这个会觉得哇太棒了，然后就可以袖手旁观不再关心，因为智能体显然在干活，可两分钟后同一个窗口里另一个智能体在跑，却突出一堆可怕的垃圾，你也许根本注意不到，因为你已经掉进了自动化偏见 [00:19:14 → 00:19:38]
Peter Steinberger: 以为智能体干的不错，你觉得这是不是人类的一种偏见，因为你知道，通常带新工程师的时候，比如一个刚毕业的来了，你审查他们的代码，要是代码很糟糕，你接下来会审得更仔细，直到有一天，他写的代码跟你写的一样，好，这个过程通常得花六个月或一年，然后你就觉得 [00:19:38 → 00:20:06]
Gergely Orosz: 这个人可以信任了，对吧，但智能体完全不是这么回事,智能体不会学习,你可以在智能体里塞很多信息,给它建一个记忆系统,但那跟人类的学习方式不一样。当然,人类也不是万能,但人确实有学习的能力,还能把学到的东西留下来,对吧? [00:20:06 → 00:20:25]
Armin Ronacher: 对,而且人类还会感到痛苦,我觉得这恰恰是人的一个关键特征,其实也跟你刚才说的连得上,当痛苦变得足够大,作为人你就有动力去解决导致痛苦的根源。在代码库里，那个根源通常就是，糟糕的接口 [00:20:25 → 00:20:39]
Gergely Orosz: 可怕的复杂性，你因为再也维护不了，那个系统，就会想把它们清理掉，这不就是为什么，资深工程师总是抢手吗，在CEO眼里，资深工程师就是能把事搞定，可实际上那些 [00:20:39 → 00:20:52]
Peter Steinberger: 真正高效的资深工程师，个个都带着伤疤，被折腾过，感受过痛苦，亲眼见过放任不管的话，技术会陷入什么样的死亡螺旋 [00:20:52 → 00:21:05]
Gergely Orosz: 所以他们做的所有决策，都是因为他们清楚，怎样能避开这些坑，当然这样一来，项目进度反而更快，我个人觉得，当然你的看法可能不一样 [00:21:05 → 00:21:18]
Armin Ronacher: 一个真正好的工程师，是那种经常说不，经常说我不需要这个的人，因为这样能把复杂度压住，而你用智能体的时候，情况完全反过来了，你会说好我要这个，我要那个，我还要这个，再要那个，反正不用我自己敲代码，不用我自己想，只要给那个小机器发个提示，它就能突出，看起来差不多像那么回事的东西，能用就行了，而这就是所有问题的开始，我还认为好的工程 [00:21:18 → 00:21:45]
对谈参与者: 说到底就是清楚，你得做哪些取舍，有时候正确的解法，要是你做在大学里学，你可能反而会学到，你不该这么做，在某种程度上，记得凯尔亨德森说过类似的话，你应该先用最笨的方案，直到它彻底跑不动为止，因为现实是你要做的事太多了，如果你一上来就追求，所谓正确的完美的解法，反而会制造出那种，规模一大就要命的复杂性，这一点工程师是慢慢才学会的，而且如果你没有亲历过那种上巴 [00:21:45 → 00:22:17]
你实际上很难有效地说服别人，因为正是这种学习过程，才给了你在工程团队里，说服其他工程师，我们就该这么干的权威，那是一方面，但另一方面，智能体现在给你接通了世界知识，我最近采访很多工程团队，就发现资深的人凭借经验说了不，然后48小时后，一个初级工程师过来说，我跟智能体聊过了，我之前就有这种感觉，但现在所有证据都摆在这，证明我们确实不该那么干，而放在以前 [00:22:17 → 00:22:49]
Mario Nahr: 你根本拿不出这种现成的论据，就好像终于有东西能帮你证明，你是对的资深人士，对吧，而这又制造出了，以前没有的另一种压力，不是每个团队都有这种情况，因为你有一个 [00:22:49 → 00:23:02]
Gergely Orosz: 这就像有人拿着一份ChatGPT的打印出来，去找医生说，你看这可是机器说的，你最好照着做，根据你现在看到和聊到的情况，我们是不是能这么说 [00:23:02 → 00:23:15]
Peter Steinberger: 有经验的工程师会越来越难，越来越难去说，不即便面对产品经理或初级工程师，再说某个方案好得多 [00:23:15 → 00:23:26]
Mario Nahr: 更糟的是产品经理直接进来发pull request 而且还能自动把他们合进去，对这又是另外一个现象了，非工程师参与到工程流程里，现在已经是个事实了，你问问Armin他是怎么经历的吧，问问他到底怎么干的 Armin这到底是怎么运转的，这很难，因为一方面出发点是好的，对吧如果有人不是，你实际碰到的状况是什么，是你自己公司的情况，还是跟其他人聊的，首先我们公司也有一点点 [00:23:26 → 00:24:00]
毕竟我们规模小，所以比如说 [00:24:00 → 00:24:02]
对谈参与者: 我的安娜有时候会在网站上发一个PR 我还跟那些规模更大的公司聊过，看到营销团队突然就在网站上搞点东西，销售团队整出越来越复杂的销售演示，最后这些代码就落到了GitHub组织里，最搞笑的一次是，有个销售演示做出了一项根本不存在的功能，但居然没人发现，你看所有这些都是新现象对吧 [00:24:02 → 00:24:27]
Mario Nahr: 因为以前从来不会发生这种事，那你觉得这算不算是一种，负权比如如果你整个，这确实能赋予人力量，而且它也有好的一面，如果你的整个组织，如果新组织里的每个人都能以某种形式 [00:24:27 → 00:24:40]
Armin Ronacher: 参与软件的创建对吧，以前人们做不到这一点，比如设计师可以在Figma里设计出东西，但可能没法把它放进一个，可点击的演示员行里，或者产品经理想试一个功能，又不想浪费工程师的时间，现在你可以做到了，但问题是人们现在太关注，人人都能做所有事，以至于忘了你仍然需要一个流程，来给这一切加上护栏，而且集成这部分是最难的，是的就像Peter提出的 [00:24:40 → 00:25:06]
Mario Nahr: 那个prompt request的想法，但我其实越来越接受这个想法了，一旦你演示过了，我就不再需要他们的代码了，简单回顾一下 prompt request就是说，他不喜欢收到pool request [00:25:06 → 00:25:20]
Peter Steinberger: 他更愿意看到那个prompt 因为他会去运行它，或者稍作调整, 然后它就会按照它的风格生成代码。对我来说, [00:25:20 → 00:25:32]
对谈参与者: 这倒不只是我想看那个prompt本身, 而是想搞清楚它到底要做什么。而且现在我们明白了, 因为实际上在很多方面, 有意思的点在于, 一开始你通常并不完全清楚自己想做什么, 所以创造的这个行为本身会帮你理清真正想做的东西。这个部分非常有价值, 但最终出来的方法和代码, 往往不是一个足够资深的工程师，会采用的做法，所以不是说我要你的prompt 好让我用我的笨办法重新跑一遍，让它好那么一点点，更像是既然现在我们都搞清楚了，要做什么 [00:25:33 → 00:26:07]
可能我自己从头开始会更快，是的，而且我对Peter说的 [00:26:07 → 00:26:11]
Armin Ronacher: 我只要你的prompt 也有点不同意，我其实挺看重看到一个糟糕的实现，比如如果我们在PI的仓库里，收到一个pool request 我们收到的大多数pool request 都是智能体生成的，没什么人工干预，那我马上就知道，好吧这回是堆垃圾，但是是有价值的垃圾，因为有人至少花了一点点心思，指导他们的智能体创建了这个pool request 我就能看到他们想做的那个东西的糟糕实现长什么样，我就不用浪费自己的时间去试了，别人已经试过了，就是那个天真的笨笨的智能体 [00:26:11 → 00:26:46]
把事情做了一个零错误的版本，这反而省了我的时间，我不是说我喜欢智能体生成的pool request 因为它们确实很烂，我应该现在就把它们关掉，但它们确实有价值，这不只是一个prompt 它是一个指数，它是一切，我是说它最终会成S型曲线，因为特定的动态，但我觉得我们会比以前几个周期，更早地发现这是一件坏事，不,那是好消息，但我觉得这会很有意思 [00:26:46 → 00:27:16]
对谈参与者: 而且我也不知道答案，不过我读到了一篇很精彩的讲述，英国工业革命，如何改变纺织业的文章，工业革命，对对，那篇文章的核心论点是，每当流水线前端的，某个环节被优化，就会在下游创造出，新的激励，催生新的东西，对吧，所以一开始，如果你能更快地支部，那最终你就需要，能承受更快支速的杀线，然后渐渐地，瓶颈会一路往下游转移，而最终，整个链条里最大的瓶颈，结果变成了，我认为 [00:27:16 → 00:27:50]
其实是我们在工程领域，正遇到的下一个瓶颈，那就是曾经你做了件衬衫，如果不喜欢，你会回去找做衬衫的那个人，他会帮你修好，所以实际情况是，如果衬衫很差，没人会在意，是谁在过程中把它弄坏了，你只会去拿件新的，对吧，也就是说，责任实际上，从链条中的任何一个个人，转移到了整个工厂身上，工厂作为一个整体，不再需要承担责任了，因为我们已经把整个东西，商品化到了这样的程度，你不再需要去做这件事了 [00:27:50 → 00:28:23]
而如果你用工程的视角来看，运营公司和运营服务中，很重要的一部分，就是要可靠地运行它，所以你会对事故进行事后复盘，找出流程里哪里出了问题，然后你回去修那件衬衫，是的，问题在于我们整个体系，都建立在这样一个想法上，每一个参与这个创造过程，并最终导致结果的工程师，都承担着一定的责任，我们会找到那个人，不是要去责怪他，而是要搞清楚，你这里为什么做错了 [00:28:23 → 00:28:56]
所以如果现在机器，能以十倍的速度生产东西，那么责任这件事，就没法以同样的方式扩展了，因为机器没法被追究责任，而且我真的不确定，在我们运营工程的方式中，未来是否能把人为事物，如此的抽象掉，以至于整个公司，不再关心是谁批准了一个，糟糕的pull request之类的，我们已经像自动化T恤生产那样，把它也自动化了 [00:28:56 → 00:29:21]
Armin Ronacher: 我目前还看不到这种未来，但是，所以事情是这样的，我觉得我们软件工程师，或者IT人员，严重低估的一点，就是这个世界到底有多复杂，以及每一个基角嘎拉里，藏着多少人类的模糊地带，对吧，我们之前想着，我们现在能把那件事自动化了，现在我们可以自动化一切，每种知识工作都可以，但我们作为软件工程师，太不擅长成为领域专家了，以至于我们看不到一个工作流里，所有那些非机器的部分，我们现在又在重蹈覆辙了，我们看到了模型能做不可思议的事情，我一点也不否认，对我来说，这简直就像 [00:29:21 → 00:29:56]
哇基本上我2000年代的所有研究，现在都作废了，因为Transformer能搞定所有这些事，但我们又像在软件领域一贯做的那样，把这种能力过度外推到一切事情上了，就像我们在教育科技里做的那样，是的，现在教室里有平板电脑了 [00:29:56 → 00:30:13]
Gergely Orosz: 当然现在教育变软了，因为我们有了电脑，事实上我听说不确定是哪个国家，但他们现在正在撤回了，瑞典，对瑞典他们把平板电脑，从教室里拿走了 [00:30:13 → 00:30:27]
Armin Ronacher: 是的从教室里，实施证明如果你对教育策略，和影响做一些科学研究，如果你只是把一堆平板扔进教室，关上门然后期待最好的结果，结果最好的情况，也是非常糟糕的 [00:30:27 → 00:30:41]
Gergely Orosz: 所以对我来说过去两三年，最大的收获就是，炒作太可怕了，因为它会让一切都去人性化，而我不想成为，那个马戏团的一部分，说到不想成为，马戏团的一部分，我们来聊聊PI吧 [00:30:41 → 00:30:55]
Peter Steinberger: 它是一款非常流行的，让我带上小丑鼻子，而且也是非常极简的，编码智能题，我们能不能从头讲讲 [00:30:55 → 00:31:07]
Gergely Orosz: 为什么你决定在市面上，已经有那么多，智能题框架的时候，还要去构建PI 对吧，因为那些方案都不够理想，所以多跟我说说，好，当然我一度是Code的信徒 [00:31:07 → 00:31:20]
Armin Ronacher: 正是因为他们基本上创造了整个品类，通过发明了智能体搜索，我是说发明，其实之前也有先驱和站在巨人肩膀上的东西，但他们是第一个，把它打包成一个非常有吸引力的产品的人，而且在当时，他非常贴合我的工作流，简单来说，他就是预测性的 LM本身带有启发式的，或者说随机的特性，有些不可预测，但围绕LM的一切都挺干净整齐，容易理解你曾经也是Claude Code的快乐用户，对吧，我当时超级开心到处跟人安利它，但后来他们的团队开始内部适用 [00:31:20 → 00:31:54]
消耗的token越来越多，我猜他们的开发速度和团队规模也上去了，随之而来的是更多的功能和越来越多，越来越多的bug 而我个人喜欢稳定且简单的工具，即使他们有些不确定性的部分，但所有确定性的部分都应该尽可能稳定，而Claude Code在2025年夏天左右的体验，完全不是这样，所以我对它真是彻底失望了，到底是bug还是预期之外的行为，感觉就是，他们剥夺了你对上下文的控制权，他们会在背后偷偷往里面注入东西，这非常糟糕，然后你原本能用的工作流突然就不行了 [00:31:54 → 00:32:28]
因为现在有一个你在UI里根本看不到的系统提醒，它会修改模型的行为，他们对系统提示词也这么干，我当时我还逆向工程了一下，当然从我这种偏底层的背景来说，打开一个混淆过的JavaScript文件，然后翻混淆，我都不好意思叫它逆向工程，但是在2025年的夏天，我逆向工程了Claude Code 并且做了一个小服务，可以用来追踪系统提示和工具定义的演变，就是Claude Code里的那些东西，差不多每次发布版本，它都会有些改动，如果你感兴趣，可以去看看我的CC History Mario Session 然后呢 [00:32:28 → 00:33:03]
这些东西确实打乱了我的工作流，如果我要选定一个开发工具，我希望它像一把锤子那样稳定可靠，我可不想我的锤子今天这里断，明天那里裂，对这太糟糕了，这就是我遇到的情况，跟Cloud有关，但我再说一次，我不是在抨击那个团队，我觉得他们有些人真的很好，我在网上认识过，他们只是在吃自己的狗食，内部测试，这完全没问题，我们需要有人以全速前进的方式去探索，不过我不想用那样的工具，因为我要完成工作，听起来就像是快速行动打破一切 [00:33:03 → 00:33:36]
对打破一切那一套不是我的菜，不适合 [00:33:36 → 00:33:40]
Mario Nahr: 然后我就开始看替代品 AMP和Droid大概就是那时候出来的，我觉得是在2025年初，我不太记得了 AMP是不是更早一点是吧，非常早，对我觉得他们基本上是从同一个时期开始的 [00:33:40 → 00:33:54]
Armin Ronacher: 因为据我所知 AMP在Claude Code出来的时候就已经有了，差不多那个时候，对总之我看了看那些工具，他们都超级棒，但就是太贵了，因为他们几乎都不能用上 Claude Code的那种有吸引力的方式，也就是在订阅的基础上还能是一个，很酷的工具那种模式，在企业环境里还行因为你，本来就是要按token付费的但，对于那些窝在车库里折腾的独立，开发者来说就完全不行了，虽然从经济意义上来说，我已经不再是那种窝在车库，里的独立开发者了但我内心，还是跟那个社区有共鸣我还是，想用我的订阅来做点什么 [00:33:54 → 00:34:29]
所以我就去看开源替代品然后，找到了open code虽然这满足了，我的一点开源情怀但它也会在，背后对上下文做一些我不喜欢的事情，比如在工具结果打到一定Token输出量之后，它会修剪掉部分内容，或者在模型每一次编辑后，就去询问LSP服务器，如果有错误呢 [00:34:29 → 00:34:46]
Gergely Orosz: 没错肯定会报错，因为模型还没完成它的工作，代码还不能编译，所以LSP服务器就会，指的是LSP那个语言，语言服务器协议，对，所以当你打开VS Code写TypeScript的时候 [00:34:46 → 00:35:00]
Armin Ronacher: 底部会有一些错误诊断信息，那些就是来自TypeScript的LSP服务器，而OpenCode会在后台替你运行一个LSP服务器，并在每次编辑后把诊断信息喂给模型，我们作为程序员是怎么工作的呢，我们会打开一个或多个文件，一行一行的编辑，直到最后才去看那些产生的错误，但在OpenCode或者其他也支持LSP的工具那里，模型调用编辑工具修改了代码型之后，他们会在每次编辑调用后就立即注入诊断信息，这真的不明智，因为现在你把模型弄糊涂了 [00:35:00 → 00:35:34]
他看到你有错误，你有错误，你有错误，而模型想的是，对我知道，我知道，我还没搞完呢，这样真的不好，总之open code不适合我，而且我还得fork 他的代码来修改，我觉得这不应该成为必要条件，所以我就想，这能有多难呢 [00:35:34 → 00:35:51]
Gergely Orosz: 不如我自己做一个小东西，然后，你的这个小东西挺极简的，他用了什么 PI的基本原理是什么 Pi的基本原理 [00:35:51 → 00:36:01]
Armin Ronacher: 首先是我自己对所有LM提供上API的抽象，因为我不喜欢versus SDK和AISDK 有各种原因，阿敏后来也写了篇博客谈到这个，当然那个SDK用起来不错，很多人在用 [00:36:01 → 00:36:14]
Gergely Orosz: 但它就是不太符合我这老派的抽象品味，这就是软件，尤其是开源的美妙之处，你永远可以自己造一个，没错一直如此，而现在有了智能体，你甚至可以做得更快 [00:36:14 → 00:36:27]
Armin Ronacher: 虽然做出来的东西可能会挺糟糕，充满冲突，但我还是做了个抽象层，然后又为通用智能体做了一个小小的抽象，支持工具调用，流逝传输等等，我还做了一个定制的终端小工具，它不会闪屏或者闪得很少，然后我把这些全部整合到一起，做成一个编程智能体，看起来就像Claude Code Codex或者现在那些东西就这样，而它的可扩展性来自于，这个最小核心有那么多的勾子点，你基本上可以通过一个，简单的TypeScript模块挂载进去，这个模块会被加载到，同一个node进程里，这样你就可以做一些事情 [00:36:27 → 00:37:02]
比如给LM提供自定义工具 [00:37:02 → 00:37:05]
Gergely Orosz: 实现你自己的上下文压缩，或者彻底改造整个TUA终端界面，你可以修改里面的一切，特殊工作流终端UI 对吧，正是如果你想让TUI [00:37:05 → 00:37:18]
Armin Ronacher: 针对你特定的工作流，有不一样的表现，比如你是个非技术背景的人，你就可以把工具改成，任何你需要的样子，我有几个非技术背景的朋友，就这么做了，因为他们不需要知道，怎么构建这些 [00:37:18 → 00:37:30]
Gergely Orosz: 他们只需要让PI去构建 PI就会修改他自己，所以这个是可行的对吧，因为有了这些扩展点，你可以让PI修改他自己，他可以编写代码来扩展自身，虽然这有点非主流，但确实是个很大的突破，这就是你之前说的吗，或者说OpenCode 你得Fork才能修改，它没有这个功能，它确实有插件系统，但是扩展点不多，而且非常死板，我想他们最近改了，现在应该开放多了，但我没怎么跟进了，可能已经好多了，所以我觉得PI这个东西非常极简 [00:37:30 → 00:38:04]
就我理解它有的工具就是读写，读写编辑批处理 [00:38:04 → 00:38:11]
Peter Steinberger: 就这些足够了，然后你就可以真正开始把它变成你自己的工具了，那你能举几个例子，大家一般会添加什么功能吗 PI本身没有MACCP [00:38:11 → 00:38:23]
Armin Ronacher: 人们就直接让PI给自己构建MCP支持 PI也没有计划模式，阿敏就会说，我的计划模式必须做的特别棒，量身定制超级，我没有计划模式，但他之前弄了大概五种Plan Mode的实现，直到后来发现Plan Mode根本没用，还有的人就是在UI上随便改改，比如把输入提示的那个编辑框，换成不同的视觉风格，都是些很表面的更偏装饰性的东西，也有人把它改造成了，完整的强化学习环境，给开源模型用，把PI当成执行环境里的智能体 [00:38:23 → 00:38:58]
所以真的什么都能做 [00:38:58 → 00:39:00]
对谈参与者: 除了实际使用它的酷抽象之外，吸引我的是自定义工具这部分，对我来说，一个关键时刻是在圣诞节，跟很多人一样，我有了些空闲时间，就试着做点别的 Peter在11月跟我聊，说他基本上可以不怎么看代码，就进入状态，我也说不清他原话是什么，但意思就是他几乎不看代码，就能把东西做出来，我就想，好我要做一个连我自己都不看代码的东西，我希望它最后看起来不像一团乱麻，而是像我自己写出来的样子，我还想做个游戏 [00:39:00 → 00:39:31]
于是我基本上就开始了这段基础PI的体验，我想做个游戏，但在做游戏之前，我希望你先这样搭建代码库，既能让你自己验证所做的修改，也能让我看到这些修改，这算是一种双管齐下的思路，我希望我始终在循环里，但同时智能体也能自我验证，最后出现的结果是，它先是在游戏里给自己做了些调试工具，可以截屏跑模拟，输出状态再读回去，而且PI还可以在玩具里展示图像，我又跟Lanker聊了聊，看看哪些事情比较有意思 [00:39:31 → 00:40:05]
最后我们做出来的是，所有这些截图我都能在UI里快速翻阅，还能利用这个很棒的功能，回退到对话中的某个早期状态，然后在对话里进行分支，我们围绕这个做了不少东西，因为这些绘画特别是包含截图的，很快就变得效率很低，其实PI早期比较擅长的另外一件事，就是处理大量截图，因为OpenClaw的人 [00:40:05 → 00:40:28]
Mario Nahr: 他们在聊天里塞了一大堆截图，而且OpenClaw用的就是PI式，所以我们不得不，但是这种体验对我来说真的很神奇，去面对这个问题 [00:40:28 → 00:40:39]
对谈参与者: 我不知道正确的工程方法到底是什么，但很明显一部分就是我得留在循环里，这样我们才能针对手头的问题，找出具体怎么做，结果我发现，无论是网页项目，电脑游戏，还是我尝试过的其他一些东西，它们虽然各不相同，但很多都归结到同一种模式，智能体现在与我的程序交互，它应该用最优的方式去做，而我则想在它和程序互动的同时，自己也参与其中，并且整个体验，对于我和智能体来说，都尽量不让人困惑，看到这种模式逐渐浮现 [00:40:39 → 00:41:14]
真的特别迷人，你的工具在这个程序里启动时，它的样子和感觉 [00:41:14 → 00:41:20]
Peter Steinberger: 跟在另一个程序里完全不一样，我很喜欢你刚才说的这一点 Armin 就是当工程师始终在循环里，系统能实际验证变更时 AI的效果最好，好了 [00:41:20 → 00:41:33]
Gergely Orosz: 让我们回到节目，聊聊通用工具和专用工具，这个话题，是我花了很多时间在工地挣钱，在工地上，你不会只用一把锤子解决所有问题，你有螺丝刀 [00:41:33 → 00:41:47]
Armin Ronacher: 有锤子，有电钻，有各种工具，我觉得做工程也是同样的道理，作为工程师，我不会对所有任务都用同一把工具，所以用智能体的时候，我不想什么任务都靠一个通用智能体，我要的是一个专门的东西，我知道它在这个特定任务上表现会是最好的，因为我们围绕这个任务，搭建了相应的框架，让智能体能最高效的工作，这正是我想用PI来实现的，不过话说回来，我可能是对PI改动最少的人，我就用两个扩展，而且都很简单，他们基本就是如果你看到像GitHub issue 或Pool request的URL [00:41:47 → 00:42:22]
就通过GitHub API拉取详情 [00:42:22 → 00:42:24]
Gergely Orosz: 在编辑器上方显示一个小部件，里面有issue标题，作者账号和链接，这就是我做的全部了，对于你这样的极简主义者来说，可能就够了 [00:42:24 → 00:42:38]
Armin Ronacher: 对我就是这样在PI的mono repo上工作的，因为我可能同时开着两三个绘画，每个都在处理issue或Pool request 这样我能记住每个绘画是干嘛的，但听起来就好像你们也专门为那个做了自己的PI [00:42:38 → 00:42:51]
Peter Steinberger: 为了在PI MonoApple上工作，弄了个特定的版本，如果你对如果你回去做游戏的话，你会肯定会有不同的设置，我以前从没想过，你可能会为不同的任务用不同的框架，我猜我们一般都觉得，大多数开发者就是做自己工作的主业，可能有个副项目，随便做实验，但这一点，我就在想这会不会是一件新事情，我们以前从来不可能为一个，项目定制专门的工具 [00:42:51 → 00:43:26]
这听起来太疯狂了，我的直觉是 [00:43:26 → 00:43:29]
Armin Ronacher: 我们正走向这样一个方向，软件能根据用户的愿望和需求，来自动修改自身，只要给智能体足够的权限，他们现在就能做到这件事，通过PI 我算是第一次涉足这种，可自行修改可速的领域，不过目前只限于编程智能体这个领域，但我认为，这实际上可以扩展到各种知识工作，当然在更大的知识工作集合里，针对具体任务，显然还得考虑去人化之类的问题，不过我的下一步计划，实际上是做一个替代的用户界面，来取代终端 [00:43:29 → 00:44:03]
因为终端显然有局限性，而最好的替代方案，无疑是web 它到处都能用，什么都能做，等我把这个做出来，就会变得非常有意思，因为你不再受限于，终端那种机遇航的渲染了，就能做非常非常酷的事情，我们拭目以待吧 [00:44:03 → 00:44:19]
Gergely Orosz: 在我知道PI是一个极简界面之前，我听说PI的一个原因就是 open call是怎么用它的，这是怎么开始的，记得我们经常一起玩，互相审阅博客文章，互相扔点子，到了十月份我开始做PI Peter则开始做他的小WhatsApp助手，叫Venor Relief 哦原来是这样开始的，是，他当时在找一个能复用 [00:44:19 → 00:44:45]
Armin Ronacher: 或复制的智能体核心，最开始他是拿了PI 然后克隆了一份改名叫Tao 在做修改，但后来他懒得维护了，就直接说我用你的东西吧，事情就这样定了，如果不是因为OpenClaw 我根本不会做压缩compaction功能，实际上我就是因为Peter在聊天里叫苦，说他需要压缩我才做的，好吧我给你压缩，但我得告诉所有用户，别用压缩那对你们不好，是 [00:44:45 → 00:45:11]
Gergely Orosz: 但这大概就是，在开源软件基础上，互相构建的美妙之处，对吧，这是有好有坏，是，我现在得享受，所有OpenClaw实力带来的后果 [00:45:11 → 00:45:23]
Armin Ronacher: 他们把OpenClaw里的bug 当成PI的bug 然后自动给我发来一大堆issue和pool request 那些用户可能都不知道，我还得在我的开源项目里处理这些，所以这算是个负面效应，所以 [00:45:23 → 00:45:36]
Gergely Orosz: 你其实只是承受这件事的，终端那一方，我想就像OpenClaw本身那样，它在这种问题面前暴露的更多，我是说他们现在积压了上万个 issue根本不可能对这些 [00:45:36 → 00:45:49]
Peter Steinberger: 做好有效的代码审查，但你是怎么应对这种情况的呢，你现在作为维护者，眼看着OpenClaw的那边，有AI自主的在你的，仓库里提各种东西 [00:45:49 → 00:46:01]
Gergely Orosz: 你有没有专门做工具来应对，并设法，把他们关掉，我确实给OpenClaw那类情况，做了一个工具，会把issue和pull request 嵌入到三维空间里，这样我就能看到 AI智能体发到仓库里的相似内容剧类，然后就可以批量选中，一次性关掉，真的，你还真弄了个三维可视化出来，我补充一下背景 [00:46:01 → 00:46:27]
对谈参与者: OpenClaw现在可能没那么疯狂了，但从12月底到大概2月中旬那阵子，真的是爆炸式增长，这种爆炸几乎直接转化成了，我当时不停刷新仓库，就看着Pool Request的数量往上涨，是 [00:46:27 → 00:46:41]
Mario Nahr: 我们当时其实也想帮Peter一把，试着做点贡献，但我马上就放弃了，我完全不知道该做点什么有用的事，看着那个状况，我就想，这真不是我所习惯的那种软件工程玩法，我可能花一小时修好两个地方，等提交推送完才五分钟，不知道哪个叮当兵，就跑来把我修的全给还原了，这根本没法工作，我们能聊聊 [00:46:41 → 00:47:06]
Gergely Orosz: 叮当兵这个名字吗，当然克隆人战争，星球大战，我其实从没看过，不过有朋友的孩子，在我们做客是老看，我算是通过渗透，得到了一些预感，那里面有一支，机器人军队，绝地武士们，叫他们clanker 也就是叮当兵，因为他们走起路来，叮当作响，对就是这么来的，所以这就是 AI带来的乐子，对完全正确，不过回到正题 [00:47:06 → 00:47:32]
Armin Ronacher: 怎么应对AI智能体，涌入提Pool Request和issue的情况，我现在的办法是，所有Pool Request一律自动关闭，不管是人发的还是智能体发的，我的做法是，如果我之前跟你没有过接触，我的GitHub工作流会知道这件事，因为你的账户名，如果不在我Git仓库的某个文件里，你的Pool Request就会被自动关掉，然后我的小工作流会在这条PR下，自动留一句评论说，嘿感谢贡献非常感激，能不能麻烦你用人类的口吻，开个issue 长度别超过一平文字，如果我觉得行 [00:47:32 → 00:48:06]
就会回复LGTM 我看没问题，然后那个账户名，就会被加进那个文件，下次再发PR就能通过了，而事实证明 AI智能体根本看不到，我的工作流在PR下面，发的那条评论，所以这成了一个，绝佳的过滤器，能把智能体筛出去，同时让人类开发者，多多少少免受 [00:48:06 → 00:48:26]
Peter Steinberger: 这种干扰，这挺有意思的，我在想，这会不会是一种，无法回避的未来，我们必须找到一种方法，来分辨这件事，到底是出自一个，有意图的人类 [00:48:26 → 00:48:39]
对谈参与者: 还是AI 我其实不太在乎，如果它真的是个优质的PR 就算是机器生成的，也还算能接受，我觉得在PI这个项目上，有意思的地方 OpenClaw就更明显，就是它会不断堆积 Pool Request 而这些请求背后，根本没有任何真正的意图，所以调度那台机器的人，其实并不怎么上心，或者说根本不知道有这个事，对甚至可能都不知道，我做开源很多年了，以前也见过类似情况，有人发PR或者issue说，嘿请修复这个，但后面连回答问题的意愿都没有 [00:48:39 → 00:49:14]
这种情况并不少见，那时候你倒不一定非要去修，但至少得把它关掉，因为也许还算是有用的输入，不过很明显，那个人对这事没那么上心，而现在PR的情况更糟，因为他们涌进来的速度太快了，很多PR如果不手动解决冲突，根本合不进去，而且这里面缺少一种反压机制，因为我作为人类，如果看到一个仓库开着500条PR 我多半就不想再贡献了，最坏的情况下，我只会让局面变得更糟，而且我觉得以前在开源界 [00:49:14 → 00:49:46]
Armin Ronacher: 也会有人直接提issue 态度非常理所当然，甚至说你要是不修它那个小问题，你就是世界上最烂的人，但那种情况还能应付，而那时候的pool request 是有点特殊的，因为它需要一个人投入相当多的时间才能做出来，但现在已经不是这样了，人们只会想，哦这应该很简单吧 Agent体替我把事办好，别出错发到这个仓库里去，但事情根本不会就这么简单，所以我们需要的其实是某种平静，我并不一定需要人去验证你是不是人类 [00:49:46 → 00:50:19]
我只是需要一个平静，让我作为一个人类能处理的过来涌入的这些请求，因为要让PI不退化成一堆垃圾，我仍然相信它需要我和其他有能力的人，至少去审核那些重要的代码，为了做到这一点，我必须得有平静，不然我真应付不过来 [00:50:19 → 00:50:37]
对谈参与者: 这就像是热力学第二定律，一切事物都会去向混沌，你必须额外注入能量，才能阻止它滑向那个结局，如果我们不再审视代码库，就再也感受不到代码的痛苦了，人们不再感受到痛苦，或者说他们失去了任何约束感，而且issue这东西很有意思，一方面如果有人做了一番调研，然后发给你一段描述，这可能是好事，也可能是坏事，但他们看上去都非常相似，你得花不少精力，才能区分一个AI生成的issue 好不好，不幸的是 [00:50:37 → 00:51:12]
他们大部分都不怎么样，但有些又确实挺不错的，说起来也挺怪的，整个状况都很怪，我确实在很多层面上，不知道开源的未来会怎样，因为开源过去在很大程度上，是靠人们扎堆功课难题运转起来的，大家聚集在一起说，好,我们需要一个好用的数据库，那我们就投入能量去把它做出来，开源的价值正是来自存在那些难题，然后大家把能量汇聚起来，想办法去解决，而现在我感觉开源变成了一种堆东西的竞赛，最让我恼火的是 [00:51:12 → 00:51:45]
很多人尤其是在所谓的生成式工程领域，现在做的事情全是给生成式工程添砖加瓦，就像是为了优步而优步，你懂吧，然后我看到一条推文说，嘿我解决了问题 XYZ这是我的解决方案，你点进去一看，这个东西才建了48个小时，那个人自己很可能 [00:51:45 → 00:52:05]
Mario Nahr: 压根就没用过他做出来的东西，我建议观众们去看一看 ARM在GitHub上的账号，过去一年发生的变化，是啊，我做了很多这类东西，但我不会跑到推特上说，嘿我解决了这个问题，对吧 [00:52:05 → 00:52:18]
对谈参与者: 我GitHub上有一大堆的vibe swap 我倒是希望能换种方式来推广自己，因为可能确实有一点用，但问题是，除非你的代码能在一年，一年半之后还在那里，还有人继续使用，否则它的效用，其实根本就没被真正验证过，而且现在GitHub上，有很多指标和数据，确实显示这类东西，在爆发时增长，但你要是换个角度，找一些别的数字来看，看看这些被创造出来的东西里面，到底有多少，真正变成了基础性的组件，能支撑起开源社区，并真正带来 [00:52:18 → 00:52:52]
可以规模化增长的价值，实际上我们并没有创造出 [00:52:52 → 00:52:57]
Mario Nahr: 很多Vibe工程化的项目，能做到这一步，我很喜欢你提到的活力，以及开源一直以来的运作方式，如果我们回想一下 AI出现之前 [00:52:57 → 00:53:09]
Peter Steinberger: 就拿Linux来说吧，它是最成功，用的最广的开源项目，它既有活力，也有结构，你看人们带着明确的意图，来想添加点什么，他们有一套流程要走，每个层级都有人的信任，他就像一个金字塔，最后一切都要汇聚回去，每一次代码变更请求，都要往上走一级，最终由Linus来拍板，这里有大量的活力，大量的意图，还有大量的人，对那里有很多人 [00:53:09 → 00:53:44]
一直以来，核心就是人的活力，而现在我们突然有了AI 它目前只是一些token 天知道这些token背后，有多少补贴，或者根本没有，反正就是机器在干活，然后突然间，他们会弄出一些 [00:53:44 → 00:54:02]
Gergely Orosz: 看起来像模像样的东西，看上去像是人的活力，让人难以分辨，就好像突然有，把扳手扔了进来，其实我不同意，我觉得开源并没有改变太多，数量变了，不好吧，是不过那只是个数字，就像你说的真正有用，并且有人维护的项目，他们的数量可能并没有太大变化，所以你是说那些已有的项目，他们都很有用，而且有人维护，甚至都不只是已有的那些项目，我是说新开源项目，能存活超过两周的比例 [00:54:02 → 00:54:37]
其实是有一个特定比率的，这个情况一直就是这样对吧 [00:54:37 → 00:54:40]
Armin Ronacher: 所以现在只是有更多项目在两天后就死了，比以前多，但我们能长期存活的项目，数量仍然跟以前差不多，因为最终还是需要有人，真正愿意长期维护它，需要建立一个个由人组成的社区 [00:54:40 → 00:54:54]
Mario Nahr: 来支撑整个项目，围绕整个开源项目，构建一个生态系统，让它能，你是说你不用交付很多个，不是，我是说Meta把那个放出来，做得真不错，超级有用 [00:54:54 → 00:55:08]
Armin Ronacher: 我觉得归根结底，我们有点过度恐慌了，其实根本没必要，因为除了我个人，没法以光速生成代码，去构建开源项目这一点，之外,而且构建开源项目，不仅仅关乎代码,还关乎，围绕它的社区,精神，和生态系统，其他东西其实并没有改变，改变的是那些机械性的部分，我需要处理那些成指数，机增长的智能体,拉曲，请求等等带来的瓶颈 GitHub本身就承受着巨大的压力，因为现在不光是人在，冲击他们的基础设施,还有，数十亿G的OpenClaw实力在冲击 [00:55:08 → 00:55:42]
是,大家都在，抱怨GitHub老实当机，我倒觉得他们做的相当不错了，毕竟从圣诞前后，从open call以来，涌向他们的流量是巨大的，所以我会更乐观一点，我们现在其实还处在，瞎捣鼓边试边看的阶段，而且每个人都想把token数量 [00:55:42 → 00:56:01]
Gergely Orosz: 当成kpi 就像当年把代码行数当kpi一样，我们可见过这一套了，说到不会变的东西，以及瞎捣鼓边试边看这个话题，你之前发过一条推文 [00:56:01 → 00:56:14]
Peter Steinberger: 还是在哪里写过，说你最大的敌人是复杂度，而且他也是你的智能体最大的敌人，我们来聊聊这个，道理很简单 [00:56:14 → 00:56:27]
Armin Ronacher: 假设我有一个600行的代码库，而我的智能体最多也就在，大概20万token的上下文窗口内，才能有效工作，那么它能消化多少代码，三分之一吗，对吧，就算你能把某个任务相关的，所有代码都塞进那个上下文窗口，你可能还勉强过得去，但这本身就是一个独立的信息检索问题，而且目前还没解决，智能体搜索也解决不了，也就是说，你其实没法保证智能体真的找到了，完成一个任务所需要的全部相关代码，很多垃圾代码就是这么来的，因为它根本看不到所有需要看到的东西，好吧，我们假设最理想的情况 [00:56:27 → 00:57:01]
信息检索问题解决了，所有东西都完美的装进上下文了，智能体也干得不错，但这不是我们所处的现实，因为接下来，智能体会吐出超大量的代码，等到要做新任务的时候，他自己根本就不可能，把这些代码重新读进他的上下文了 [00:57:01 → 00:57:17]
Gergely Orosz: 你明白我的意思吧，对没错，他们自己把自己的上下文窗口给撑爆了，是，没错，他们自己增加的复杂度，就是他们最大的敌人 [00:57:17 → 00:57:30]
Armin Ronacher: 因为最终那个代码库会变得极其庞大，极其复杂，偶合度极高，以至于智能体在技术层面上，根本没办法把所有需要的上下文都吃进去，来完成新任务，我还要指出的是，这些智能体是从互联网，也是从我们身上，学到所有这些垃圾的，因为互联网上满是我们以前写的旧代码，虽然里面也有一些珍珠，但更多的是珠石，因为我们有海量早期GitHub项目，都是我们当时随便试试手的东西，像Linux或者其他，真正维护的很好 [00:57:30 → 00:58:04]
写的很漂亮的开源项目，跟所有这些垃圾比起来，简直是九牛一毛，而机器学习模型呢，它不会趋向于那些精心打磨的佳作，而是趋向于平均值，那这个平均值又是什么，它并不是那少数几个工程上，极其出色的项目，而是互联网上所有的垃圾，所有的货物崇拜时代，所有今天流行什么就写什么的东西，当我们让智能体包办一切的时候，我们得到的就是这些，是，所以我们面临的问题就是 [00:58:04 → 00:58:36]
Peter Steinberger: 事情变得越来越复杂，而这会拖慢智能体的速度，进而实际上影响质量，我们刚才正是在聊这个，不过Armin 既然你现在在创办自己的公司，你们两位都在创业，而且你们也在用智能体工作，对吧，他们也会遇到这些问题，那你们是怎么处理代码生成，产品构建 [00:58:36 → 00:59:00]
Mario Nahr: 以及如何在质量技术开发，和复杂度之间取得平衡的，我们正在处理着呢，处理得很糟糕，听着我觉得，我们是在应付，不是在真正处理问题，我不确定我是不是在博客里写过这个，但我肯定在一次会议的幻灯片上放过，我极其享受从4月到大概10月的那段时间 [00:59:00 → 00:59:24]
对谈参与者: 因为我觉得自己无所不能，但同时当时也没有什么过高的期望，好像整个世界还没有习惯，所有事情都必须提速10倍这个概念，有那么一段时间，我觉得我们一开始是在那种 [00:59:24 → 00:59:38]
Mario Nahr: 共振隧道里工作，那感觉特别有趣，因为我当时有时间陪孩子们玩，我在手机上稍微提示一下，然后觉得，所谓的共振隧道，就是你用手机和你的智能体，对话的那种状态 [00:59:38 → 00:59:52]
对谈参与者: 在一台机器上，基本上就是个简易终端，对，而且我们也没用它做太多事，但它带着一种很愉快的氛围，我知道我在电脑前花了太多时间，但我并没有感受到压力，但现在的情况是，我们集体觉得，所有东西都必须更快交付，更快迭代，我们在保证度等等方面，想要达到的基线也必须更高，所以现在感觉压力非常大，即便是在你自己的创业公司里，而你们还是，还是一个很小的公司，对吧，是因为在某种程度上，你没法 [00:59:52 → 01:00:26]
你可以是世界上最坚韧的人，这种情绪还是会影响到你，我现在正在慢慢学着，跟自己的情绪共处，学着去应对这些，但我发现这非常非常难，因为我原来习惯了一套特定的做事方法，我知道该怎么处理一些事情，后来我却太多的掉进了那种陷阱，像机器让步，用一些我平时根本不会用的方式去做事，这些事情你会后悔，绝对是生成式后悔，从后悔到更后悔，对所以，坦白说答案就是，我觉得现在借助一点点后见之明，学到了一些 [01:00:26 → 01:01:01]
我真希望去年11月就学会的东西，跟我们说说吧，很大程度上就是意识到，当你用AI代理的时候，你跟代码库之间，你和其他工程师之间，没有了那种回传通道，正常情况下是存在这种回传通道的，就是那种感觉，代码库里有些东西不太对劲，现在改动的难度和复杂度在增加，比如你看到拉曲请求的复杂度在变高，但如果你只是橡皮图张式地批准，假装没问题，那回传通道又在哪呢，所以这种机制 [01:01:01 → 01:01:36]
Mario Nahr: 这种规范压力，代码库里的这种摩擦，在你跟智能体一起工作时，是感觉不到的，我觉得有一种方法可以衡量它，就好比如果我扫描一个项目，从开始到现在的所有绘画 [01:01:36 → 01:01:48]
Armin Ronacher: 我估计脏化的出现频率是在上升的，因为智能体会开始出更多错，因为它自己也没法，应对项目积累起来的复杂度，我还真的挺想知道，这是不是能量化的，因为我现在在大多数项目里都能感觉到 [01:01:48 → 01:02:02]
Peter Steinberger: 我骂脏话的次数确实多了很多，但你提到了软件中的摩擦，你没说技术债务，也没说复杂度，这个摩擦到底是什么 [01:02:02 → 01:02:14]
Mario Nahr: 因为我完全不记得在AI时代之前，我们讨论过这个，这事我觉得既讽刺又有点悲哀，我不会点名，但我猜有一起事件，至少部分原因是某种反工程 [01:02:14 → 01:02:27]
对谈参与者: 他们推送了一个配置变更，最终导致了一个安全问题，当然出问题是难免的，但我看到那家公司，在社交预览里的口号，口号是无摩擦交付，这真的让我顿了一下，因为作为一名工程师，我知道我们以前总说，你要清除路障，这样你才能开心地交付东西，但总有些变更，是你真得仔细想想的，比如你是不是要删库，你是不是要合并一个可能锁表，甚至让你整个服务挂掉的迁移，对吧，时不时就有这种时刻，你本来应该好好想清楚 [01:02:27 → 01:03:01]
人们为此创建了检查清单，或者设置了一些机械的闸门，让你必须在某些地方确认，特别是如果你在运营一家SaaS公司，会加入这类东西，目的就是让事情慢下来，在一些最优秀的工程团队里，为了让一个服务成熟，你必须定义思路，你必须定义各种期望，如果你的服务被定义为关键级别，那么需求数上，就会解锁其他一些东西，很多工程师觉得，这又是官僚主义，但现实是，如果你正确操作，它能节省你的时间 [01:03:01 → 01:03:36]
让你更开心，你不会在凌晨三点被叫醒，所有这些机制都是有用的，这就像是被故意注入的摩擦，用来有益放慢速度，对 [01:03:36 → 01:03:47]
Peter Steinberger: 我想最简单的例子就是，在任何一家有点规模的公司里，服务都会根据关键程度分级，最高级别的软件，现在可能需要两到三次代码审查，或者要主管批准才能做配置变更，这些全都让流程变慢，但我们知道，这是有意为之通过增加这种摩擦，我们是想让你思考 [01:03:47 → 01:04:11]
Gergely Orosz: 我是不是真想推进这件事，值得我投入时间精力去层层说明吗，等等，这让我会想，如果我知道最终效果是得走完这一整套流程，那我真的还想把这东西加到代码库里吗，所以这又回到了对自己说，不为了避免经历那套流程带来的痛苦，然后当你非常确信这是完美的 [01:04:11 → 01:04:35]
Peter Steinberger: 你有底气有背书也有信心的时候，你就会承担这份痛苦对吧，所以通常来说如果是高摩擦的事情，比如一级服务或者最高级别服务，需要主管签字，如果你是新来的，第一天上班，不了解背景，你大概知道这是个大事，你可能会先去社交，获得一个资深同事的认可，然后说，这样做是对的，你会跟着他一起做，这又回到了一点人际动态上 [01:04:35 → 01:05:10]
我觉得整个事情里，有一个非常微妙的平衡 [01:05:10 → 01:05:13]
对谈参与者: 因为你不想让摩擦，仅仅是因为糟糕的开发体验，而意外产生的，对吧，但有些东西看起来很像，但实际上是非常刻意的，只是可能没有被充分记录，但现在有一种思潮是，扫除所有摩擦，好让智能体可以高度自主，让你可以同时跑很多个，很大一部分是出自这个原因，这些事情其实相当慢，你从中能获得的唯一真正时间节省，就是并行处理，所以这里面有个陷阱，我觉得现在自己管理这个陷阱，更有经验了，但我也还没解决方案，而且我不会说 [01:05:13 → 01:05:47]
哪个代码库是让我对自己构建的东西，感到非常非常满意的，除了在XGTBT时代之前的那些老库，我对他们还有很强的感情依附，写他们的时候会小心得多，比我们在PI的其他那些，我没有访问权限的代码要小心得多，哦不 [01:05:47 → 01:06:05]
Armin Ronacher: 在PI里也有很多潦草代码，但我会尽量在那些，我知道是重要的部分避开它，比如我们有一个HTML导出功能，它把当前绘画直接吐出一个HTML文件，你可以托管到GitHub上什么的，那个功能我一行代码都没看过，它坏了我不关心，只要输出看起来对就行，但像智能提出循环，扩展加载机制等等那些是重要的，我确保这些部分高质量的方法，或者至少试图确保的方法，就是无情的重构，因为这会把我拉进代码库里，我需要理解从结构上我要改什么，而不是一行一行的看语法之类的 [01:06:05 → 01:06:39]
我需要理解正在发生什么，才能做好重构，我时不时就这么做，就像现在我想加一个当前架构不支持的新功能，就被驱动着去做了沉浸到代码中，是保持代码库高质量和低复杂度的唯一办法 [01:06:39 → 01:06:55]
Gergely Orosz: 但这跟行业里尽可能燃烧更多token的智慧是背道而驰的，对这就是这倒是个有意思的现象，但你最近就同一个主题写了一篇博客 [01:06:55 → 01:07:07]
Peter Steinberger: 叫我们都需要放慢他妈的速度，能不能重温一下其中的一些想法，以及是什么触发，你把它发出来的，说白了是这样 [01:07:07 → 01:07:20]
Armin Ronacher: 你的AI代理现在能比你多突出10倍的代码，但这意味着他突出的错误也多出10倍，即便他的错误率只有你的一半，那错误量也不是多10倍，而是5倍，而且仍然比你突出的错误多，所以你的代码库质量恶化的速度就加快了，这就带出了安工厂的概念，现在你派100个这样的代理去折腾你的代码库，最终结果会是什么，这就是第一个问题，对吧，你总得有个办法来审查所有这些新生成的代码，修复所有那些bug 可你作为人类做不到 [01:07:20 → 01:07:52]
因为人类一天习惯写1500行代码，大概也就是你能认真审查的极限了，对吧，如果你的代理一天产出10倍于这个量，你根本没可能审查的过来，而且代理生成的代码并非全都重要，比如那个html导出之类的东西，对吧，但即便代理一天只铲除三到五千行代码 [01:07:52 → 01:08:12]
Gergely Orosz: 你也根本没有办法进行任何有意义的审查，然后如果你再搞一只代理大军，我的意思是，然后就是代理大军，这点很有意思，你把这叫暗工厂 [01:08:12 → 01:08:25]
Peter Steinberger: 想法是几十几百甚至几千个代理，你给他们一份规格说明书，他们就去拆解任务，自己组织起来，搞个什么市长之类的角色，还有QA代理，你给他们分配角色，给他们上下文，再给他们海量的token和预算，而背后的想法或者说期望是，哦 [01:08:25 → 01:08:50]
Gergely Orosz: 你的软件很快就能完成了，哦，事情肯定会有结果的，我敢肯定，先有结果的会是你的钱包，好了，不开玩笑，让那些能做到的人去搞吧，我尊重他们，我自己也能做到 [01:08:50 → 01:09:03]
Armin Ronacher: 而我认为我能做到的原因是，我依然在乎产品的质量，不管它是用手工还是用代理构建的，我只要求质量好，既包括开发者这边容易维护，容易添加新功能，也包括用户那边，那些声称所有代码都是代理写的公司，没错，我们都知道质量很垃圾，正在下降，我们用你们产品的时候，身体的每一个细胞都能感觉到这东西很烂，所以我不想要那样，基本上我觉得人们需要回头想一想，嘿我们到底在干嘛，我们现在有了这些美妙的机器 [01:09:03 → 01:09:36]
他们能帮我们处理那些我们讨厌做的事情，而且做得很好，帮我们省去很多痛苦，我们为什么不从这一点开始，给自己多腾出点自由时间，去琢磨那些有趣的部分，把那些我们知道他们能干的事，大规模的委托给他们呢，比如在整个组织内部，找出所有让你烦透了的事情，让代理帮你自动化掉，然后你突然就有时间去思考，我们到底想构建什么用户，到底需要什么，而当我们决定要构建某个东西的时候，再把代理拉进来说，我们要把这个东西打磨到极致 [01:09:36 → 01:10:09]
因为现在我们有了时间，手段和工具去做到出色，但我们现在的工作方式不是这样，我们是组建一支代理大军，设定好节奏，然后写一份大二全的规格说明书，寄希望于这回产出什么惊人的东西，但问题是，我们之前聊过代理们，从哪里学到的知识，互联网，所以质量就是垃圾到平庸，好现在你写一份规格说明 [01:10:09 → 01:10:33]
Gergely Orosz: 你所能拥有的最好的规格说明是什么，最好的规格说明，就是你精确定义它应该怎么运作，你给它测试用力，对吧，最好的规格说明，其实就是软件本身，哦我明白你的意思了，没错确实是这样，好你说的对，一份不是软件本身的规格说明，这意味着里面有很多需要填补的空白，对吧，那你觉得代理会怎么填这些空白呢，最有可能就是用他的训练数据里的东西来填，对吧 [01:10:33 → 01:11:06]
而我们已经明确了那些训练数据的质量是什么，对吧，垃圾到平庸 [01:11:06 → 01:11:12]
Peter Steinberger: 其实甚至在AI之前，别忘了stack overflow就曾因为一件事，受到大量批评，你从stack overflow上ctrl加c ctrl加v复制代码，而往往第一个答案要么不对，要么不够好，在很多例子里，电子邮件证则表达式，就是个典型，你搜索邮件证则表达式，第一页就是stack overflow 然后所有人都直接复制，第一个解决方案，我记得在那个问题下面，第三还是第四个答案里才提到 [01:11:12 → 01:11:46]
第一个方案漏掉了很多情况，没错，但是关键在于 [01:11:46 → 01:11:50]
Armin Ronacher: 我并不是说代理比人类更好，他们显然不是，但代理也没有解决那个问题，如果你不仅让一个生产力，已经是你十倍的代理，去做他更擅长的事，而你作为人类去做你更擅长的事，而是让一百个这样的代理去干 [01:11:50 → 01:12:04]
Gergely Orosz: 你觉得结果会是什么，对吧，这不过是非常简单的算术，我们谈谈另一个很有争议的话题 Mucky对CLIO的天 [01:12:04 → 01:12:17]
Peter Steinberger: 这个话题最近真的是越来越热了，你也知道，现在我听到很多人真的在说，克里才是未来，而且我觉得就这两者而言 MACP在大公司内部也非常流行，特别是当你和很多，在大公司工作的人聊的时候，看起来MACP在大型企业里 [01:12:17 → 01:12:41]
Mario Nahr: 找到了真正的产品市场契合点，不管大家怎么想，其实我没那么讨厌MACP 到那个程度，对对我也是，等等我们可录着音呢 [01:12:41 → 01:12:54]
对谈参与者: 好吧我们不搞非黑即白，我们都是务实派，我对MACP最根本的疑虑是，首先这个规范实在太复杂了，但话说回来，规范这种东西差不多都这样，这也算是那个时代的产物吧，本身就有内在的复杂性，不过如果你问它到底在做什么，归根结底，它就是认证，然后调用一些东西 MACP理论上还支持结构化响应，但大多数时候，它就是运行点什么，把结果塞回上下文，然后基于这些结果来工作，所以你的上下文窗口，很快就会被填满 [01:12:54 → 01:13:28]
Cloudflare有一个CodeModem CP 我其实挺喜欢的，我自己也有一个用来做测试的MCP 是一个JavaScript解释器，可以让我访问Google API 像这样的MCP跟一个技能相比，其实差别并不大，因为技能同样也需要一个助手提示词来定义，但代理们真的极其极其擅长跑代码，而MCP并不是真正的跑代码，它基本上就是接收输入，做点事情，可能还会发生一些模型，看不到的状态转换，从这个角度看，它要解决的问题很难，但它确实解决了一大堆问题 [01:13:28 → 01:14:03]
我希望它能跑通，但我到现在，还是没能让它正常工作，我是真的希望它能行，我仍然怀疑，胶水层必须是代码执行，但因为MCP服务器，大多没有被定义成，模型能真正理解的方式，我还没找到，可靠组合MCP工具的办法，我找到的办法，是让MCP本身可组合，也就是把MCP暴露成一个工具 [01:14:03 → 01:14:26]
Mario Nahr: 去跑代码，但我还没找到编排更大规模MCP的方法，我希望它能行，而且我觉得它已经找到了自己的小众市场，不会消失，我觉得它确实是自己成功的受害者，整件事最开始是在 [01:14:26 → 01:14:40]
Armin Ronacher: 2024年10月，它基本上就是个把外部服务，接近消费者聊天应用的方案，对连上你的邮件，连上你的OneDrive 连上各种东西，差不多就是这样，然后IDE们也捡起来用了，因为它方便嘛，像Cursor, Windsurf,对, 但我觉得起源其实是在消费者那头, 不是开发者那头, 而且那是个非常好的用力, 我可不想让我妈折腾什么代码生成, 去调用这个API, 那个API之类, 所以这用力完全没问题, 然后开发者那边也接过来, 觉得,嘿,这可是给我的大语言模型提供工具的好办法, [01:14:40 → 01:15:14]
就像在系统提示里说, 如果你想调用这个工具, 就提供这个Jason在喝, 然后你就能拿到返回结果, 对吧,而且当时那感觉, 确实挺对路的，因为你如果去读 Anthropic的文档，他们会说，我们的模型能在上下文里处理，大概30到40个工具，但其实连那都不是真的，实际也就12到20个模型，就会崩掉，不过没关系，当时还是让人觉得，好的，如果你把它保持的小巧聚焦，非常针对你的用力，它是能工作的，然后大家就开始构建 MCP服务器，基本上就是把整个OpenAPI 规范映射成不计其数的工具，对 [01:15:14 → 01:15:49]
事情就从这里开始垮了，所以第一个问题，大公司搞出了非常烂的mcp服务器，他们心想，我们现在就需要这个，能最快搞出什么东西，直接把自家API的openAPI后端，往里一套，生成一个mcp服务器，那就是个垃圾，第二个问题是，它天生不可组合，如果你想组合两个不同的 API服务器的工具输出，这些输出都必须经过上下文窗口，模型自己得做数据转换，把拉取回来的多份数据组合起来，然后进行比较，这就像有命令行管道一样，对吧没错 [01:15:49 → 01:16:22]
模型其实只看到输入和输出，它可以非常自由的揉捏数据，这也就是code mode背后的思路，基本上就是个曲巧的办法，好吧，我们现在有了mcp 但我们知道它在这种特定场景下行不通，我们有多方数据，你想把它们组合起来，但又不想把所有东西都塞进上下纹里，那我们搞个code mode吧 code mode说白了就是，我们把所有mcp服务器暴露成typescript中的函数，然后模型实际上可以直接写点代码，去调用MCP服务器，然后在代码里完成组合，这就好像在问 [01:16:22 → 01:16:56]
我们到底要几层交互啊，我们完全可以让模型直接写代码嘛，我们根本不需要MCP服务器，然后第三个问题是 David from C是MCP的大力支持者，因为他是开源的东西 [01:16:56 → 01:17:08]
Mario Nahr: 说实话这对我来说也非常合理，但这样一来，模型本身好像就没什么意义了，我觉得存在一个MCP 2.0的事件，有点讽刺的是，它可能会更多的基于，我知道一家公司叫Stainless [01:17:08 → 01:17:22]
对谈参与者: 他们基本上是从OpenAPI规范生成SDK 我最近越来越接受一个想法，也许MCP完全基于OpenAPI的规范，基于酷，基于酷或者更直接的，应该是针对OpenAPI规范发起请求，因为如果你在那里就把东西组合好了，我觉得有一件事被低估了，比如如果你去看PI做事，因为它对工具调用是透明的，有时候它表现得很神奇，那些代理在处理大量输出时，非常有创造力，举个例子 PI在Bash里运行程序 [01:17:22 → 01:17:57]
产生了太多行代码，它实际上只读，我不知道具体阶段是多少，但它就读前面几行，然后说，如果你想看剩下的文件，它有20兆，放在这个文件里，接着代理就会想 20兆太大了，我直接去抓文件吧，对吧，它们在互动方式上变得非常巧妙，而MCP却把这种能力拿走了，问题是你该如何定义MCP 才能不拿走这些能力，让它仍然保留所有那种魔法和可能性，我真的不知道答案，因为这很难，但认证问题需要解决，可组合性也需要解决 [01:17:57 → 01:18:31]
我认为这类东西未来很光明，另外就像Mario说的，如果编码代理没有变得如此流行，那么用代码生成和代码运行，去解决非代码问题的想法，大概也不会这么快起飞，不过现在最有能力的个人代理，比如OpenClub 其实只是隐藏在你背后的编码代理，这样一来，自然会有某个非程序员的普通人问，我该怎么搞定这件事，模型不会说装这个MCP 而是会说，好吧，我可以写段Python脚本来做，所以在消费者那一侧 [01:18:31 → 01:19:04]
Mario Nahr: 你会很自然地看到更多代码执行的采用，但在合规约束的企业场景里，却没有这一套，那里的路径不一样，我个人认为，未来对于任何实质性任务，模型除了走代码生成这条路，不会有别的方向 [01:19:04 → 01:19:17]
Armin Ronacher: 我觉得这主要是因为代码生成的训练数据非常多，而且代码生成是控制计算机非常容易的手段，所以我不认为模型实验室近期会推出什么不同的方式，因此如果把这一点作为未来的假设 [01:19:17 → 01:19:31]
Gergely Orosz: 那我们就只需要想办法让代码生成在企业的环境里跑通，同时带上企业所有的那些条条框框，那么我们来做个有趣的尝试，预测一年后的情况，这很难 [01:19:31 → 01:19:43]
Peter Steinberger: 但在2027年基于这些基本面，还是从第一性原理出发，你们觉得这些编码代理会发展到什么程度，软件工程工作流又会变成什么样，当然这纯粹是推测，我们知道没法预测未来，但你们认为接下来一年，哪些地方会受到重点关注 [01:19:43 → 01:20:07]
Gergely Orosz: 在乐观的情况下，我们可能在工具工作方式上看到哪些成果，哪些行得通，哪些行不通，我完全不知道，说实话，我真的不知道，我可以编一些大概不会发生的事，我觉得自我修改的能力显然是我相信的东西，我认为我们会看到更多这样的东西，看到像自修改软件，对，对 [01:20:07 → 01:20:31]
Mario Nahr: 包括构建软件所用的工具本身，我认为这不仅仅会在技术领域扩展，也会扩展到非技术领域的生成式AI工具，是不是像狗年那样，乘以7是这么算的吧，我基本上就是按这个模型，来理解现在的事情 [01:20:31 → 01:20:45]
对谈参与者: 你问我一年后会怎么样，那感觉就像过了七年，这让我觉得根本没法预测未来，因为现在感觉远不止一年，也许从人们开始用云代码算起才一年，但感觉时间已经过了很久很久，已经走过了更多的路，如今我能想象到的最接近的图景是，我们知道代码执行和代码生成，以及围绕它的这些驾驭方式，这就是未来的方向，因为强化学习正拿到越来越多的数据，而且我有个非常强烈的假设，随着越来越多的人开始意识到 [01:20:45 → 01:21:18]
你可以用代理做很多有趣的事，社会上也会逐渐认识到，我们对两家公司的依赖有多深，我觉得我们会有关于这一点的对话，尤其是作为欧洲人，我们应该有这样的对话，因为这边真的没有这些实验室，所以我希望我们能展开这种讨论，但我最好的猜测是，我们会猛然发现，我是说已经有工程团队告诉我，他们有一些代码库是机器生成的，他们觉得自己再也维护不了了，我猜其中一家公司会上市，然后突然间一切都会变得非常昂贵 [01:21:18 → 01:21:51]
我觉得这件事可能会成为主导话题，或者至少它引发的讨论，会远大于你在用PI还是Claude Code这类问题，我也看到我们之前也看到了这一点是 [01:21:51 → 01:22:02]
Armin Ronacher: Mistroma那个新的云模型，不是Spot 那个新的GPT模型，他们只提供给特定合作伙伴，所以现在我们看到，谁能拿到最好的智能正在出现分裂，对 [01:22:02 → 01:22:14]
Peter Steinberger: 或者那个感知上的最佳智能，当然这会是有趣的动态，那么你们两个都在做AI 都在打造热门的AI工具，你在创业 [01:22:14 → 01:22:27]
Gergely Orosz: 当然也在用AI 而且也是代理相关的，你们俩是怎么跟上节奏的，到现在为止我见过的东西也不少，现在在想拉我上什么炒作列车，可不像以前那么容易了 [01:22:27 → 01:22:39]
Armin Ronacher: 不过这个年纪有关，不住在旧金山确实轻松很多，因为我觉得那边会让我抓狂，比如我常听那边的同行说这说那，我心里就想算了，我还是别去旧金山了，多谢，就这样 [01:22:39 → 01:22:52]
Gergely Orosz: 身边有个安静的环境，不全围着寄宿转，可能还挺有帮助的，有个孩子也有帮助，出去爬爬树，画画冰，然后回头看看自己半小时前干了啥，心想我干嘛要那样啊 [01:22:52 → 01:23:05]
对谈参与者: 那简直太蠢了，我得说，这可能会让那些想联系我的人挺难受的，但我现在特别擅长不去静音通知，也不看邮件，在过去这一年多里，这甚至变成了一种必要，可我后来发现，时间一长，好多事反而清楚了，因为如果那件事真的重要，他迟早会再找到你，我自己沉迷推特，这也没啥好骄傲的，但作为获取有趣信息的来源，推特还是有用的，不过我现在换了个办法，如果某件事真的特别特别重要，他会在讨论里一直挂着，我就等着 [01:23:05 → 01:23:39]
等过了三周他还在那，那估摸着确实值得关注，而且说实话，我也不一定非要那三周的先发优势，可老实讲，这真的很难，要应对这种局面太难了，因为这里面确实有一种真实的兴奋感，我干软件工程20多年了，这经验很多时候帮了大忙，但同时也会在另一些地方打击你，你本来觉得会有个稳固的根基, 有东西可以依赖, 有个坚持的基础, 可现在的感觉是, 其他人好像全都不在乎这个根基了, [01:23:39 → 01:24:10]
Mario Nahr: 那也许你根本就不需要这个根基, 而且有相当一段时间, 事情好像也能跑得通, 这就很奇怪了, 而且我知道, 我有点觉得, 从2025年我们快乐事业那会儿, 当这一切刚开始时, 我们其实已经强跑了, [01:24:10 → 01:24:24]
Armin Ronacher: 就好像我们俩和Peter, 去年4月就已经有过那股兴奋劲了, 就跟赢了似的, 当时没别人, 真的那会儿没谁像我们那么兴奋，然后圣诞假期一过，现在所有人开始有了，我们去年4月就有了兴奋感，对吧 [01:24:24 → 01:24:38]
Gergely Orosz: 所以现在他们才组学习小组，把自己折腾的严重缺窍，搞出一堆烂代码，不过我觉得这现象会自我纠正的，因为这根本不可持续，我们也确实看到了这个趋势 [01:24:38 → 01:24:51]
Peter Steinberger: 3月初我在Pragmatic Engineer播客，做了一期深聊，当时很多人一月份，还对这些新模型特别兴奋，开始上手试，他们能干什么，两个月内就在工作或项目里，全面铺开了，结果不少人开始觉得，等等这引入了好多复杂度，有各种问题，我的进展根本没预想的那么快，等等，所以我觉得这挺自然，面对任何新东西，不管是新工作还是别的，都会有个蜜月期，你会戴上眼罩，只看到好处 [01:24:51 → 01:25:24]
其实也该这样，然后你开始意识到问题，可能会过度纠正 [01:25:24 → 01:25:32]
Gergely Orosz: 但说实话，做了决定之后，总得花时间才能看到结果，对吧，所以什么DockFooding翻车了，软件一死SaaS完蛋了，这些论调我一点也不担心，我基本上相信，这只是那台炒作机器的正常运转，它自己会纠偏的，好的，最后收个尾，你能推荐一本书吗，说说为什么 Code那本，作者是Petzold 经典 [01:25:32 → 01:25:58]
Armin Ronacher: 我就是爱这本书，读起来太棒了，非技术背景的人也完全能读，要是有人问我工作到底是做什么的，我第一个就推荐他，这本书其实跟计算机本身关系不大，讲的远不止这些，我最近读了Brickneck [01:25:58 → 01:26:12]
对谈参与者: 可惜我想不起来作者名字了，它有点像在探索中国是怎么运转的，或者说欧美之间有何不同，我起码觉得，它挺引人思考的 Mario和Armin 非常感谢你 [01:26:12 → 01:26:26]
Gergely Orosz: 这场对话，能当面聊真的特别好，感谢邀请我们，谢谢你，这次对话真的很有意思，感谢Mario和Armin [01:26:26 → 01:26:38]
Peter Steinberger: 自我修改软件这个概念，越来越吸引我 Mario提到Pi还没有MyCP支持，计划模式，以及开发者想要的很多其他功能，但你可以把这些能力，写进他自己的代码里，到目前为止，这样做是行得通的，他之所以受欢迎，就是因为他能修改自己，我很好奇，这种由AI驱动的自我修改软件概念 [01:26:38 → 01:27:09]
会不会扩散到开发工具之外呢，如果会又是什么时候呢，另外我也很喜欢我们聊到的一个观察，智能体感受不到痛苦，但人类可以，当一个代码库变得过于复杂时，人类工程师会感受到，由此带来的各种问题，这种技术债务就会推动重构和重写，但智能体根本不会这么做 [01:27:09 → 01:27:40]
它们只会持续地往上叠加复杂性，而如果一个代码库的开发者，能经常感受到代码库的痛苦，并且动手去解决，那么代码质量大概也会更好，最后聊聊MACP和CLI的讨论，这个话题很有意思 MACP更侧重于通过上下文为AI提供工具，而Klein则允许你以管道的方式串联起一个又一个工具，不过Mario和Armin更偏爱Klein 但公平地说 [01:27:40 → 01:28:15]
MAP也有它的用武之地，比如在大公司内部，针对合适的任务选择合适的工具，请务必查看下方的节目资料，里面有Pragmatic Engineer相关的深度内容，会更深入地探讨相关话题，如果你喜欢这期播客，请在你常用的播客平台和YouTube上订阅我们，如果你还能给节目打个分，那就更感谢了，谢谢我们下期再见 [01:28:15 → 01:28:44]