目录
- 开场与嘉宾背景 [00:00:00 - 00:10:00]
- 从软件工厂到上下文工程 [00:10:00 - 00:20:00]
- 上下文工程的抽象与成本 [00:20:00 - 00:30:00]
- 封装工程与上下文边界 [00:30:00 - 00:40:00]
- Smart Zone 与 Dumb Zone [00:40:00 - 00:50:00]
- 循环工程与慢循环 [00:50:00 - 01:00:00]
- 循环工程的实践与陷阱 [01:00:00 - 01:10:00]
- 软件工厂与暗工厂 [01:10:00 - 01:20:00]
- Token Harder 与 Token Smarter [01:20:00 - 01:30:00]
- HumanLayer 与 AI 时代协作 [01:30:00 - 01:34:20]
开场与嘉宾背景
一凯：欢迎收听跨国串门计划,这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的AI声纹克隆技术,我们不仅将内容翻译成中文,还完美保留了原主持人和嘉宾的独特声音,为您呈现全球顶尖的AI财经,健康与科技领域精品内容。我是主播一凯，一位热衷于AI领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁，接下来让我为您简单介绍本期我们克隆的这档节目，本期我们克隆的是知名播客 The Pragmatic Engineer在2026年7月发布的一期深度对谈，主持人Gergely Oros与嘉宾Dex Horthy 展开了一场信息量极大的交流 Dex Horthy是HumanLayer的创始人 也是上下文工程这个词的提出者，过去几年他和数百位AI工程师深入聊过，并亲自带队测试了许多前沿想法，这一期他们主要围绕上下文工程，封装工程，循环工程，以及软件工厂，这些正在重塑开发方式的概念展开讨论，也坦诚分享了他们在实践中踩过的坑，那我们就一起来听听这期的完整对话，那什么是上下文工程，有点像把层层叠上去的抽象，再拆开来看reg [00:00:52]
Dex Horthy：记忆agent历史记录，说到底都是把token 喂进模型的不同方式，什么是smart zone 什么又是dumb zone 你用的context window越少，得到的结果就越好，现在有个新范式在传开，叫循环工程，你觉得它哪里不好，循环的问题在于，到某个节点，你会生成太多代码，多到你根本读不过来，我们在2025年7月，搭了一个关灯软件工厂，到11月就把它关掉了，能聊聊你说的Token Harder和Token Smarter 是什么意思吗，我在一个叫Hyper Engineering的群聊里，里面全是一群想把云订阅，用到极限的人，这就是我对Token Harder的理解，目标是，如果你让AI Agent连续几个月提交代码 [00:01:25]
Gergely Orosz：却没有一个开发者读过哪怕一行，会发生什么，今天的嘉宾就真的这么试过，他建了一个关灯软件工厂，四个月后，他别无选择只能把它关掉，因为东西就是跑不动了 Dex Horthy是HumanLayer的创始人，也是上下文工程这个词的提出者，比Andrew Karpathy和Toby Luska 把他带火还早了几天，过去两年，他跟几百位AI工程师聊过，想知道用 LLM构建时，到底什么才真正管用，并且带着自己的团队，在测试那些最有趣的想法，今天的对话我们会聊上下文工程它到底是什么,以及Context Window的物理边界,包括什么是Dumb Zone。循环工程从Ralph Wiggum Technique到Dex团队每晚运行的慢循环,早上醒来就能看到代码清理的PR。软件工厂的兴起 从1968年NATO的一场会议，到DevOps 再到今天的Agent工厂，规格驱动开发，以及为什么规格总是会跟代码本身产生飘移，还有很多，如果你想搞懂上下文工程，封装工程这些越来越重要的概念，或者想知道让Agent构建一切，这个想法到底能推到多远，从一个几乎比任何人都推得更远的人嘴里听到，答案那这期节目就是为你准备的 Dex欢迎来到播客，超级高兴能来，兄弟在我们聊上下文，工程和一些更劲爆，的话题之前先说说你是，怎么进入技术圈的你是，怎么爱上计算机的天 [00:03:10]
Dex Horthy：哪我本科读的是物理专业，后来我意识到自己不，喜欢学术界从物理系，出来基本上就两三，条路要么读博要么，进金融要么去做编程，那时候是2011 2012左右，我正读到大二大三，在想要干什么，我高中时做过一个实习，在加州喷气推进实验室，跟NASA的研究员一起工作，他们当时刚拿到一份超高精度的，最精细的月球南极地形高度数据集，月球南极特别有意思，因为那里有些陨石坑非常深，由于角度的关系，它被陨石风暴撞击的程度，是月球其他地方没法比的，所以有些极深的陨石坑，从未见过阳光，里面封存着月球形成时就存在的液态水冰，科学家们特别想下去探索它，我们拿到了这份超精细的地图，就想好，那我们来写软件 给定A点到B点，我知道探测车的限制，最大上坡角度是多少，最大下坡角度是多少，找出一条不违反这些坡度限制的路径，我当时17岁，从没翻过计算机科学的课本，我基本上写了一个非常幼稚，很糟糕的Dijkstra寻路算法版本，后来上了大学，我不确定自己要不要走学术路线，但我真的很享受当年编程的感觉，所以我决定转方向，修了差不多半个计算机科学的辅修，然后开始在芝加哥一家软件公司的 API平台团队工作 Sprout Social对吧 [00:04:49]
Gergely Orosz：对然后基本上就没再回头了，是啊那之后你又去了哪里，你是在哪里学到那些手艺的，因为很早你的第一份工作，这其实不太常见，你十多年前就在做平台工程了，从那时起
Dex Horthy：大概两三个月，我就注意到，公司里最有价值的工作，都是最早那几位工程师做的，他们什么都知道，清楚每样东西在哪，公司里最有价值的工程师做的，你花一整天处理一个客户公单，他们五分钟就搞定了，但你又必须自己去解决才能学会，我意识到，公司里最有价值的人，是那些在构建开发者平台的人 CI斜杠CD沙箱环境，预览环境这些，这大概就是我踏上这条路的第一步，从我第一份工作，干了三到六个月开始，我基本上就对软件工厂，这件事着迷了，我们现在聊软件工厂 [00:05:39]
Gergely Orosz：但你那时候就已经在聊软件工厂了，所以你当时已经开始觉得，这就是我们内部做出，更好软件的方式，那还是前AI时代，对吧，我一直挺惊讶的，有大批开发者说
Dex Horthy：我不想搞CI斜杠CD 我讨厌CI斜杠CD 我就想真的吗，因为构建那个，构建东西的东西，再构建那个，构建东西的东西的东西，这就像作为软件工程师，我们都很懒，我们想做杠杆率最高的事，让工作更轻松，所以如果我们能造一个东西，帮我们造另一个东西，再帮我们跑得更快，那对我这种懒工程师来说，就是最值得花时间的事，然后你去了另一家创业公司 Aspiration Aspiration 对 aspiration 也是做平台工程，对我被招进去，然后大概入职三个月，招我的工程VP 要么辞职要么被开了，我不太清楚，背后有些抓码，我可能不该聊这个，然后我在那待了大概一年，中间有段时间，算是代理CTO 招了几个人，帮忙招了新的工程VP 但后来我就离开了，我觉得我以后 [00:06:31]
Gergely Orosz：不会再做，面向消费者的产品了，我其实是个做BRB的人，了解了，然后你去了replicator 在那里实打实待了四年，从工程师，前端部署工程师，做到了产品经理 [00:07:23]
Dex Horthy：对我做了大概两年的核心工程，我们在做一个容器编排器，那时候Kubernetes还没出来 Docker Swarm也还没真正成气候，我们自己造了个编排器，创始人们有个愿景，觉得Docker会让交付本地部署软件，变得容易得多，我说的本地部署，不是指那种放在机房机柜里的，更像是把应用，带到数据所在的地方，而不是把数据传到某个云厂商那里 Docker让打包应用，迁移应用都变得容易太多了，所以他们有个判断，基本上可以做一个平台，让你获得像用GitHub Enterprise一样的体验，就是你安装它，它有个管理面板，然后你就能在自己的数据中心跑GitHub 代码永远不用离开你的数据中心，这样一来你就能做一个通用的SaaS 让所有人都能有这种体验，我在那做了两年工程师，然后我们的销售负责人 我们跟销售负责人分道扬镳了，而且说实话，我当时跟CTO在软件工厂的问题上，有很多争论，有点像那种厨房里厨子太多的感觉，我相信很多听众都有过这种经历，就是我知道我有这些工单要写，但是CI太烂了，我得修好CI 因为它太慢了，或者是有太多不同的构件，老是坏，我就想我先修好这个再去做那个，然后就是DEX 我需要你别再修构建流水线了，去做我给你的公单，你可能也有过这种经历，对，然后这就是你转去做前端部署工程师的原因吗，对，我真的很喜欢我们的客户，我们的客户是Hushcorp Tastex Puppet 所有这些很酷的工程品牌，还有Travis CI Circle CI 我就觉得，我真的很喜欢跟我们的客户一起工作，我们的客户太棒了，而且这是一个很好的方式 能跟很多非常优秀的工程师一起深入一线，他们都在解决公司最难的问题，就是怎么把一个做了三到五年的SaaS 拍完整打包，让一个完全不懂我们架构的人，也能在自己的AWS VPC里，自己的本地数据中心里，不管在哪都能可靠的运行起来，所以我成了公司第一个面向客户的工程师，大概三个月时间，我见了每一个在销售管线里，但没进展的客户公司，我们在三个月内拿下了大概12个单子 CEO的反应是，天哪 DEX 投资人又开始 [00:09:23]
从软件工厂到上下文工程
Dex Horthy：投资人又开始，接我电话了，我知道你想回去，写代码，但我需要你去，招三个人，把这个团队建起来，我觉得你可能，天生就是干这个的，所以我又做了，大概四年，把那个团队，建到了25人左右，然后ZERP事件发生了，团队缩水了很多，我们也意识到，我们的产品，其实还不错，我们一直在解决，很多早期创业公司，都会做的事，就是，产品有些可用性问题，我们就派一堆聪明人，去客户一线解决问题，这对销售很好，对留存很好，所有这些都好，但后来我们发现，这样做的利润率不够好，所以我们基本上就决定，好我们其实只需要，把产品做得更易用，走更偏PLG的路线 PLG就是产品驱动增长，产品驱动增长，让它更自主化一些，这样不需要一个专家，来教你怎么用，我当时就想 行如果这是最重要的事，那我想去做产品经理，因为我有一大堆想法，我在客户一线待了四年，手里有一长串产品路线，图上的事，我觉得能让产品更容易使用，更容易被采用，更容易实施和部署，现在你走完了整个弧线，你走向了黑暗面，没错，对我确实去做了，我当时想这下，我的技术口碑要完蛋了，对吧，但我其实挺庆幸的，很多工程师都怕，一旦去做面向客户的事，就会丢掉所有技术信誉，确实，我不再每天写十小时代码了，只是周六为了好玩，写三四个小时，但我们帮客户写YAML 我们做CLI 很多客户用的工具，都是我们维护的，只不过偏最后一公里的交付，不是核心平台，说点更个人的，我二十多岁的大部分时间，都觉得自己有点内向 有点社交上不太自在，我相信很多工程师都有同感，我叔叔是音乐制作人，跟Randy Newman 还有一堆很有名的音乐人合作过，叫Mitchell Fromm 有一次我跟他吃饭，应该是我还在读本科的时候，他给我上了一课，他基本就是说，如果你想在某件事上做到顶尖，就必须把它变成你唯一做的事，那种晚上和周末弹吉他，想让乐队起步的人，大概永远达不到伟大，真正能成的人，基本就是抱着不弹吉他，就没饭吃的心态，整天坐在街上，一天弹14个小时，那是唯一的出路，所以我就想，与其去读那些怎么变外向，怎么不设恐的自助书，不如干脆把跟人聊天，交朋友帮人解决问题，变成我他妈的工作，我觉得效果不错，推荐给大家，我觉得每个人都应该花一两年 去做点真正面向客户的事，你这么做
Gergely Orosz：是因为觉得内向在拖你后腿吗，我知道你从音乐人那里得到了动力，这点我理解，但到底是什么让你觉得，我要去做面向客户的事，毕竟那时候你写代码已经很厉害了，可以说你已经在没日没夜的写了，你是在哪里意识到，面向客户或者摆脱内向这件事，是你想做的，你是觉得他在拖你后腿，还是你单纯想把它做好 [00:12:44]
Dex Horthy：就是那种有点干扰，我整体生活幸福感的事，而且我本身也不是那种很有冲劲的人，我非常没有条理，不知道现在大家是不是管这叫ADHD 所以我能并行跑30个云环境之类的，但我以前真的特别不擅长处理邮件，日历和表格，我就是不在乎这些，也搞不懂，所以做这件事的另一个副作用，就是逼着我变得有条理，同时推进很多事情，当你走出舒适区，去学一些跟你以前做的事，完全不同的工业化的纪律时，会有一些意想不到的好处，机会来了，我就想反正我喜欢工作，试试看吧，结果进展很顺利
Gergely Orosz：我就想，行，看看这条路能走多远，然后现在，你开始了第二次创业，你成了创始人，而且很早就涉足了AI 甚至早到那时候，大家还没那么明显的意识到 [00:13:49]
Dex Horthy：AI会改变我们开发软件的方式，对吧，要我说，我其实可以更早的，因为我和芝加哥一个朋友，在2020年11月左右，在数据工程领域开了一家公司，我们是在2020年8月做的决定，就是Metal Analytics Metal Analytics 严格来说，现在跟HumanLayer 还是同一家公司，我们只是调整了方向，但当时，我从每个天使投资人那里，得到的建议，就是那些认识我之前，跟过的CTO的人，他们基本都说，你看现在逆风很强，不知道你了不了解，整个DBT数据工程 Fevertron那一波，曾经是个巨大的派对，大量投资人的钱，涌进这些公司，然后到了2021 2022年左右，出现了零利率现象，大家普遍意识到，这类工具的总市场规模，并没有当初想的那么大，总可循指市场，对，这类工具的总可循指市场 并没有我们所有人，当初想的那么大，所以那时候融资很难，获取客户也很难 [00:14:57]
Gergely Orosz：我是在HumanLayer的一个活动上，见到你的，我们聊了聊，会后也交流了一下，那大概是一年前，那时候你已经对，怎么用AI 有了一些非常鲜明的观点，其中一个就是，现在很有名的，十二要素agent宣言，我们现在管它叫宣言了吗，我叫它宣言，它就是一份宣言，我就这么叫了，我们来聊聊这个，这是十二条工程原则 [00:15:03]
Dex Horthy：用来构建可靠可投产的应用，你是怎么想到这些的，也许我们可以挑几条来谈谈，大概到去年八月左右，跟我一起创业的联合创始人，有点倦了离开了，我们关系很好，是双方都同意的决定，然后我就决定开始捣鼓AI的东西，开始做AI Agent 当时最火的就是Longchain,Crew,AI 这些Agent框架，你进Crew AI的Discord一看，一万人，好,感觉方向是对的，而且很明显有一种回声效应，你随便点进一个项目，他们都有Chrome ADB插件，都有Compose.io插件，很明显大家都在往同一个接口上靠，我就想这里面缺什么Agent 能调用工具，但你很难控制，它调用哪个工具，如果是聊天机器人，你当然可以在UI上，点批准或拒绝，但我当时特别着迷于 一种我称之为，外循环agent 或者说主动性agent的东西，在后台跑，由事件出发 OpenClaw 基本上就是这种形态，最极致的体现，有心跳，醒来，看看有没有活要干，试着做点事，我的想法是，如果它想做点什么的时候，我不能收到一条slack或iMessage 并且确定性的保证，我能批准或拒绝，或者拒绝时还能给反馈说，不对应该这样做，那我是不敢信任这个agent 去做任何有意义的事的，所以我们在那个方向玩了一阵，跟很多创始人和一线工程师聊 2024年秋天，我们带着这个想法去做了YC 我们在做这个API平台，有点像PagerDuty 但不是谁值班修服务器，而是谁值班来审批这个agent 能不能升级委托或推迟，类似这样的路由机制 我们为Crew AI Linechain Fidata 这个生态去构建，那时候这类框架太多了，然后我跟很多真正在做有意思的东西，而且确实在赚钱的AI工程师聊，签六位数合同给企业交付AI 他们全都试过那些框架，用了一两个月就扔了，然后全部手写API调用，他们做出来的东西更像流水线和工作流，而不是那种放手让agent在循环里自己调工具的模式，所以我聊了大概100个人，还花了大量时间跟我最好的朋友之一Boundary的Viva泡在一起，他们做了一个类似AI版Protobuf的东西，而且马上要发布一个完整的图灵完备的编程语言，但他思考agent 思考用模型构建，用推理构建的方式很不一样，他更关注结构化输出底层到底是什么 你AI工作流里的每一步，就是token进token出，你作为工程师的任务就是搞清楚，我要输入什么token 才能最大化输出token的质量，我把这些想法提炼成大概12条原则，写在GitHub上，就是一个12页的GitHub仓库，扔到Hacker News上拿了大概500个赞
Gergely Orosz：在首页挂了两天，我觉得确实引起了很多人的共鸣，我快速念一下这12条原则，然后我们挑一两条有共鸣的聊，这12条是工具调用用自然语言，掌控你的prompt 掌控你的context window 工具就是结构化输出，统一执行状态和业务状态，用简单API启动暂停恢复，用工具调用来联系人类，掌控你的控制流，把错误压缩进context window 小而专注的agent 从任何地方出发，在用户所在的地方，接住他们 [00:18:30]
Dex Horthy：让你的agent成为一个，无状态reducer 无状态那个，无状态reducer这条，有点其实有人在Twitter上，找我纠正过，说严格来讲，应该是transducer 因为工作流里，其实有多个步骤
Gergely Orosz：对对对，不过这已经是一年前的事了，在工具演进的速度里，这简直像过了一辈子，这里面哪些你现在回头看，仍然觉得站得住脚，确实是好东西
Dex Horthy：对我大概花了整个三月写那篇文章，四月发出来，然后AI Engineer的Swix联系我，说嘿你要不要来聊聊这个，所以我就在大概6月6号，做了那场分享，叫12 Factor 智能体 当时是个小房间，挤满了人，但可能也就100人左右，那年AI Engineer大会的场地很有意思，最底层物理意义上的地下二层，全是那种超大企业的东西，往上走一层稍微好一点 [00:19:34]
上下文工程的抽象与成本
Dex Horthy：然后最顶层全是那种奇奇怪怪，最前沿的创业公司玩意儿，就是那种你可能现在还不用太关心的东西, 所以我们就在最顶层讲这种关于agent的奇怪思路, 然后大概过了一两周, shopify的toby lucky说, 我真的很喜欢上下文工程这个想法, 我当时想我两个月前就写了这个, 太好了toby, 懂了, 又过了一周, andrejack carpathy也说, 我觉得我们该考虑的不是提示工程, 而是上下文工程, 我当时就想, 没错, 那是我的, 算了, 怎么说呢，你要是问Gemini 看他当天心情，他会告诉你是我想出来的，或者是Toby 或者是Andrej 你没法真正拥有一个词，没人记得是谁发明了提示工程这个词，但在所有原则里，第三条，掌控你的context window是最关键的，基本上 不管你是做agent 还是单步流水线，你能影响AI输出质量的唯一方法，就是极度重视输入是什么，并精心打磨它们 [00:20:54]
Gergely Orosz：那我们来聊聊上下文工程,我得说,这个词是你发明的,我做了一些调研,你好像确实早了几天,所以就这么定了是你发明的。我们给这期节目的SEO加点料,会在文字稿里写清楚是Dex发明了上下文工程。 [00:21:04]
Dex Horthy：不过得加个星号,本质上我是跟那上百位工程师和创始人聊过之后才学到了上下文工程,我只是把他们都在做的事情的共性提炼出来,然后给它起了个名字。所以不是我发明了这种做法，我只是觉得有这么个东西存在，而词汇和命名真的非常重要，尤其是现在关于AI的内容，充斥着大量毫无意义的炒作和黑化，我当时想，好这里有一个对开发者有用的词，能解释他们应该怎么去思考，构建自己的软件，那么什么是上下文工程，它有点像把很多层，叠在上面的抽象给拆解掉，你看有reg 有记忆，有agent历史记录，有结构化输出，所有这些在agent的编程框架里，都是不同的概念，但说到底，他们都是用不同的方式，把token塞进模型 然后让它产出通常是结构化的输出，理解这一点，比去死磕记忆这个概念，或者随便拿一个现成的agent框架，和记忆框架来用，要强大的多，当然，如果你想做到80% 想做一个很棒的演示，这些东西都很好用，但当你需要从80%提升到95% 甚至99%的时候，你就必须往下走一层，去思考我们到底，往context window里放了什么，根据不同的模型，内容的顺序该怎么排，所有这些都很重要，你手里有很多可以调节的杠杆，而上下文工程这个抽象概念，恰好就是思考，如何让AI尽可能准确地完成，我想做的事的正确方式，为什么上下文工程大概从一年前开始被越来越多人讨论 [00:22:12]
Gergely Orosz：这是不是因为我们能传给LM的context window本身发生了变化，是它开始扩大了，还是我们刚刚意识到通过传递更多信息能做更多事，最简单的例子当然是系统提示词，但当然不管你在背后构建什么LM应用，你都会传递额外的上下文，不只是用户的提示词，你会加一大堆东西，这大概是所有LM应用，心照不宣的秘密 [00:23:03]
Dex Horthy：但你觉得，为什么焦点会转移到，上下文很重要这件事上，我觉得它一直都很重要，我觉得需要发生的是，一大批聪明人，也就是我聊过的那些开发者，必须非常专注地，去做出能卖的软件，做出一个准确度足够高，让我自己感到骄傲，并且能卖给企业，让企业也满意的产品，要做出真正高质量的AI应用，最简单的方法，就是在token层面去思考，把一连串不同的LIM调用，看作一个整体，而不是仅仅把它当成，在一个循环里调用工具，那种方式很开放，很灵活，但不够可靠，要把agent看作工作流，看作流水线，看作是在循环中调用几个工具，与固定流程的某种混合体，而不是仅仅想着，嘿我有我的工具，我的模型和我的系统提示词，我只有这些杠杆 实际上，不你手里的杠杆多得多，这需要花更多功夫，你需要对LM 有更深的直觉理解，但这是我们一直都需要的东西，只是人们需要花时间，去用这项技术构建产品，然后才能发现，这个抽象层次，才是让你突破，质量天花板的关键，成本和上下文工程之间，又是什么关系，对，我今天早上还跟人聊到，用 LLM的时候，我常说的话是，先跑起来再做对，最后再提速，拿当时最强的LM试试，我记得我们录播客那会儿，还是O3 看O3能不能解决你的问题，然后交给用户，看他们想不想要，如果用户想要，而且用量很大，再去做一堆上下文工程，因为你的工程时间永远是平静，人去琢磨问题，搭评估，做改进，试不同维度，设JAP什么的，这些永远比直接用 更聪明的模型贵，除非你一天有几百万次请求，到那时候才说，好我们来做一堆上下文工程，把一个调用拆成三个，让它跑在GPT-4O上，再把其中两个拆出来，也跑在GPT-4O上，我用的是老模型名了，但重点是，你工作流里的某个任务，能不能用GPT-OSS 120B来解决，它的成本只有OPUS的千分之一，能不能让它搞定一部分问题，这样你只在真正需要最高智能的地方，才去消耗最贵的前沿模型的token 但你不应该一上来就把这些都搭好，过度设计，除非你已经证明了你有这个需求，它有价值，到了那个节点你才会说，好现在我要搬出E-Lite Gold Drive了，他写过一本书叫《目标》 讲的是怎么给你的工厂建模，我们聊软件工厂的时候肯定会讲到，核心问题是 你系统的瓶颈在哪里，总有一天瓶颈会变成延迟和成本，但你刚起步的时候大概率不是，上下文工程就是，你把人的努力加进等式里，去提升系统的效率，速度，价格和成本效益，有意思，最近还有一个概念，出现的越来越多，叫封装工程，什么是封装工程，我大概在10月还是11月，发过一篇帖子，说我发现了一个新东西，我管它叫封装工程，我当时给的定义，跟现在大家理解的不太一样，有个叫V的人，现在在Lanchin 写了很多关于agent 以及怎么理解封装工程的，好文章，他其实比我早几周写过一篇，叫封装工程的东西，但我当时还没读到，我的理解基本是，你构建agent的时候，你会用到封装，也会用到上下文工程，你使用agent的时候，因为我们2025年8月做过一场演讲 讲怎么把上下文工程，用到编程agent的使用上，这个思路慢慢演变成了，你怎么拿一个封装，比如Claude Code codex 去针对它的集成点做工程，包括命令MCP skill 你怎么组织代码库，怎么优化编程agent运行的环境，来拿到最好的结果，跟上下文工程一样，上下文工程是优化每一次prompt的输入，而封装工程就是，我怎么把地板抬高，让这个东西的每一轮结果都尽可能好，后来这个词变得很模糊，有人觉得封装工程是构建封装，有人觉得是围绕封装做工程，我其实更喜欢Martin Fowler提出来的说法，一如既往，他特别擅长给东西起名字，他大概是这样定义的，你有LM 然后有内封装，就是工具定义和集成点，比如Claude Code或Codex 或某个应用实际暴露出来的东西 那是你的内封装，然后你还有外封装，就是你作为人去做的那些定制，针对你的具体需求，你的代码库，你的语言等等，我觉得这是目前对封装工程最好的定义，有意思，命名这件事到现在还是这么重要，对吧，是啊，而且一旦你给什么东西起了名字，大多数人，其实我挺惊讶的，上下文工程过了一年，在大多数人脑子里，还是原来的意思，而且居然还有人在讨论，说实话，这对我来说是最疯狂的事 15个月前写的关于AI的东西，有多少现在还有意义，还有人感兴趣，里面的建议还管用，变化太快了，我觉得上下文工程之所以能活这么久，是因为它扎根在Transformer注意力机制的基本原理里，在我们有后Transformer模型，或者线性注意力或者别的什么之前，谁知道那要等到什么时候 上下文工程对任何在AI上做开发的人来说，都会一直有意思，一直重要，我们来聊聊上下文的物理特性吧，你发过一条推文叫上下文现实检验 [00:28:52]
Gergely Orosz：那是一张图显示当上下文达到100万时，质量会急剧下降，关于上下文我们需要了解什么，因为现在确实有模型支持 100万的context window 以后可能还会更长，但当你开始往上下文里塞更多东西时，效率反而会变低，从实际使用的角度看，如果有人往context window里加一堆东西，不管是mcp 工具 skill
Dex Horthy：还是其他什么，我们目前知道些什么，对更长的context window是好事，你可以跟他聊更久，他们做的不错，但说到底，尤其是像OPUS那样，有OPUS 4.5 然后又有OPUS 4.5 100万版，或者4.6和4.6 100万版，你并没有得到一个更聪明的模型，模型的智能程度，决定了它能否关注到 context window里的所有token 然后在下一轮判断出，在这10万或20万的上下文里 [00:29:32]
封装工程与上下文边界
Dex Horthy：在这10万或20万的上下文里，哪些部分对决定，下一步调用什么工具最相关，并且在一个循环里反复做这件事，我记得2025年有一项研究发现，当然那是老模型了，所以数字你可以往上调一点，但当时的情况是 Frontier Model大概能遵循 150到250条指令，之后能力就会开始下降，他们遵循所有指令的能力会掉得很快 Arise the Lori Voss 我其实没看过具体数据，但他们一年后用下一代模型做了研究，看起来能塞进去的指令数量好多了，但无论如何，我把上下温工程分成两类，大多数人想的是信息预算，比如我可以做reg 从文档里抽出相关片段，而不是把整本书塞进context window 我只去抓取相关的页面，但还有你的指令预算，如果你给模型太多指令 尤其是太多相互冲突的指令，这既包括你最初的提示词，也包括对话过程中，你开始走一条路，然后又改主意，开始走另一条，说算了那些我都不要了，我要做这个模型，需要做大量计算，才能意识到，它得忽略前面那一整段，当这两类东西，在context window里都靠后，到一定程度，只能被部分关注到时，它真正记住，你在十万个token之前，给出的确切指令的可能性，会显著下降，这些都很有意思，因为作为工程师 [00:30:53]
Gergely Orosz：当我们成为AI工程师时，现在很多软件工程师，都是这样，意思就是你用 LLM来构建软件，底层某处有一个LM层，你就是AI工程师了，恭喜，但听起来对我们的期望是，要成为一名优秀的软件工程师，在AI出现之前，你需要懂怎么写好代码，如果你对底层原理有一点了解，会有帮助，我们后来其实不太需要那么深入了，但懂了总没坏处，不过听起来，我们现在所处的阶段是，要成为一名能编写高效AI系统的工程师，你得理解上下文的动态机制，你得明白为什么，用某种方式塞满上下文，会消耗算力，会引入延迟，所有这些听起来更像是一种直觉，当然也有一些理论理解，但跟你聊下来 [00:31:28]
Dex Horthy：你的感觉就像是，它就是这么计算的，因为你知道你试过了，对吧，我并不是机器学习的博士，我没法给你画出一个数学证明，来解释这是怎么运作的，但我们知道注意力机制，是平方级的复杂度，你塞进去的东西越多，它就得把注意力，分散到所有东西上，这感觉完全是一个，全新的领域，跟我们习惯的软件工程，有点不一样，软件工程相对非黑即白，对吧，编译器没编译通过，就是没通过，没错，这是一种不同的直觉，我之前也聊到过，作为软件工程师，你经年累月，会培养出一种不同的直觉，它有很多类别，但我想特别指出一种，这是一种你没法教，没法从课本上学到的东西，唯一的学习方式就是，我之所以能识别出软件里的坏模式，是因为我在凌晨三点调试过它们 这是我在Netflix的朋友Jake 在AI Engineer Code大会演讲时说的，没有比亲身经历那些不奏效的东西，更好的学习方式了
Gergely Orosz：去搞清楚什么好什么不好，什么行得通什么行不通，说到被不靠谱的东西折磨，现在有一个新范式正在流行起来，就是循环循环工程，核心思路是别写prompt了，直接写循环，把你的循环搭起来，这一切都始于Ralph Wiggum technique 它大概算是循环的早期版本，就是围绕它做循环，现在有些最大的实验室也在聊，说他们其实就是在做循环工程，你怎么看，你自己做过循环工程吗，搭过一些循环吗，你觉得它好在哪不好在哪，对我对循环的理解是，这个我能聊上十分钟 [00:33:23]
Dex Horthy：够做一整场演讲了，我尽量讲一些高层的要点，然后你觉得哪里最有趣，我们再深入聊，我们有Ralph Wiggum 其实就在一年零四天前，我第一次看到Ralph Wiggum的演示，当时Jeff Huntley来旧金山，顺便过来，把所有人都镇住了，他说我就是让Sonic全天候跑，六周花了六千美元，然后我构建了一整门Gen Z编程语言，你看它能编译，还有一个第二阶段编译器，语言的编译器是用这门语言，自身写的所有东西都太疯狂了，我觉得从这一切里学到的核心一课，是被压这个概念，其实很多人很早就在做这件事了，就是怎么让模型检查自己的工作，怎么把反馈自动喂给模型，这有很多很多不同的做法，你可以用确定性的Linter 可以用单元测试 用Ralph构建编程语言之所以容易，部分原因在于编程语言可以被无限验证，你用这门语言写代码编译，如果编译器报错就去修编译器运行程序，如果程序报错就去修编译器，它的可验证性非常非常高，我觉得循环工程教给我们的是，如果你能把一个问题变得高度可验证，你就可以把它当成一个黑箱来处理，然后让它循环起来，因为验证循环已经就位，它会不断自我改进，没错，所以你可以用CI-CD来做这件事，我每次发布的时候都会这么做，我会想，我累了 CI-CD太慢了，去研究代码库，做个改动，提个pull request 跑测试，看看有没有变快，再试一次，跑pull request 跑测试，推到分支上再检查，看看有没有变快 所以如果它能在循环中验证自己的工作，你就不用说我们试试这个方案，或者试试那个方案来回折腾，你只需要说，我的目标是让CI变快，然后你告诉模型步骤，就这五步，你要写一些代码，提交推送启动一个子agent 去盯着任务直到完成，它会告诉你发生了什么，然后你再决定下一步做什么，这就是我能想到的，关于设计循环最简单的例子 [00:35:48]
Gergely Orosz：你只需要设定目标，比如Claude Code 我记得codex都推出了slash go功能，就是你设定目标，它会不断迭代直到达成，或者只要在持续取得进展就行，没错，所以只要它是可验证的 [00:36:16]
Dex Horthy：只要你能衡量，自动研究也是这个道理，自动研究就是，去把这个模型的速度提升一倍，它就是一个prompt 告诉模型反复去尝试，直到真的拿到好结果，这就是我对循环工程的理解，我们做的一种循环工程非常有意思，挑战在于，人们很容易对构建，能构建东西的东西，或者构建能构建，能构建东西的东西感到兴奋，所以大家会说，我们要把所有东西都重构成一个巨大的agent 优先的工厂，甚至可能是暗工厂，他们正在把整个系统重新设计成，未来五年的基础设施，我敢肯定，我们在工程领域，尤其是务实工程里，知道的一件事是，怎么让它更渐进，怎么让它更持续，很多人根本没得选，不能说我跑了一个Ralph循环三天，他修好了我们代码库里所有的Linter错误，这是一个6万行的PR 谁想review 谁愿意签字同意合并部署，并且保证不出任何bug 没人愿意，所以我最兴奋的，其实是我们所说的迭代循环，或者叫慢循环，我们基本上就是设一个crown job 循环的结构非常简单，就是跑这个linter 修一个问题，提交并推送，然后我们每晚在GitHub Actions里，跑这个，每天早上醒来，都会看到一个PR 让代码库变好一点点，我喜欢这个慢循环式，而且它有两个维度，所以你可以加，现在我们已经有了一套蓝图，而且Kyle刚发布了一个skill 让你可以自己搭建这些东西，你可以加更多的反馈机制，比如前端我们有react doctor 还有一个反模式，没有确定性的工具，但Kyle的做法就是，这是好的样子，这是坏的样子，去改一个地方，然后带回来，基本上就是prop narrowing 我们有一堆可选props 但大部分其实不需要是可选的，做法就是，怎么把这个prop变成币田，这样代码就更干净，更容易推理，所以你可以加更多条件，更多改一个地方，我早上醒来，想看到一个PR的东西，现在我们早上醒来，会看到四个PR 因为四个独立的事情在跑，然后另一个维度是，随着你信心增强，你可以扩大范围，不只改一个地方，改四个地方，所以这些是思考循环的，另一种方式，不是由人去触发启动，不管是Century的告警，用户反馈，客服公单PM写的Ticket测试失败，或者是一个Chrome定时任务，按计划跑，关键是出发条件应该是，你不需要去按按钮的东西，有一个定义好的工作流，让一切变得好一点点 [00:38:18]
Gergely Orosz：Dex刚才描述了，让Agent在没有人按按钮的情况下，去修东西，带着这个，我们回到Dex和那些，能自我出发的Agent循环，你说我们可以更激进，可以加更多东西进去，但我要引用你的一条推文，里面说，这可能让你意外，这话居然是我说的，但我觉得我们会进入一个，一到三年的时期，凌晨三点东西可能会挂，你靠循环去修，但没人真正理解底层在发生什么，你会把它看成公司的生存威胁，对那条推文反响很好，数据跑得很高，它引起了共鸣
Dex Horthy：另一面是，我觉得以今天的模型，今天的编程语言，今天的基础设施，你可能暂时不用读代码，也能混过去，循环的问题在于，到了某个节点，你会生成太多代码，多到你根本读不过来，这就是强VM案工厂 [00:39:42]
Smart Zone 与 Dumb Zone
Dex Horthy：这就是强VM案工厂，这就是Ryan Lepopolo那种封装工程，尽可能多的烧token 我们试过，我们在2025年7月，建了一个关灯的软件工厂，到11月就把它关了，我觉得大概需要三到六个月，你一直在交付，但没人读代码，然后你才会意识到，哇这变得越来越糟，从头重来比修它更容易，模型已经把代码库搞得一团糟，以至于真的更容易从零重新思考，也许这也没关系，因为我们有AI 从零重建东西更容易，而且通常工程师说，这个修不了，得重建的时候，反馈往往是，不就在原地重构，持续让代码库变好，你提到我说的话，你会注意到，我说的不是用循环，去交付用户想要的功能，我们用循环来提升代码库质量，而且我们读所有的代码 因为我们在意架构，我们在意的不只是系统架构，还有我称之为程序设计的那些东西，我觉得这是人们会逐渐关注的，接口在哪，接缝在哪，依赖注入怎么做，所有这些让你的代码库，随着时间推移更可维护，让你不掉进那个陷阱的东西，就是那种我在这边改了点东西，那边就挂了，这是软件工程的经典问题，软件工程之所以在1970年代被发明出来，就是因为我们意识到需要一些技术来避免那个问题，那一大团意大利面试的代码，我不觉得现在的模型足够聪明，我也不觉得我们真的有训练，基准测试和评估技术，能让模型写出随着时间推移，更可维护的代码，因为它们全是在Swebench 和类似Swebench的东西上训练的，对吧，所有基准测试基本上都是 这是Django的一个commit 这是当时提交的一个issue 看你能不能，复现人类做的那个修复，是Django 是Apache 是Go和C飞，和TypeScript和Java 等各种语言的上百个仓库，但他们全都是，用模型训练可维护性的问题，在于糟糕架构，和糟糕程序设计的代价函数，没法通过跑单元测试来评估，因为它会在三到六个月后，才打到你脸上，那时候你才惊呼，天哪，没人能改得动了，这个软件已经变得太难改了 [00:41:44]
Gergely Orosz：这跟高级软件工程师的成长路径，是不是很像，为什么一个人要花好几年，才能成为高级工程师，因为在典型环境里，你得慢慢熬，当然有些地方可以快一点，通常是节奏很快，问题一堆，你得不停修修补补的环境，但有时候，有些人在同一个地方干了十年，还是没到那个水平，关键就在于，他就是需要时间，你得真正踩过坑，才会明白，现在犯的一个小错误，会像滚雪球一样，最后变成灾难，等你被他狠狠教训过一次，你才会意识到，测试很重要，架构很重要，技术债真的能要命，我们现在不怎么聊这个了，但在AI之前，我们经常说，技术债会拖死一家公司，或者让它慢到被竞争对手反超，要么就是被困在一场两年的重构里，一个新功能都发不出去 [00:42:18]
Dex Horthy：而竞争对手已经迭代了一堆东西，跑到前面去了，我得说，也许GPT-7能解决这个问题，但如果你现在就把软件工厂的灯全关了，说我们不读代码了，没事模型够聪明，只要我们给对反馈，砸够token 它就会越来越好，这就是我发那条推文的原因，那种做法也许能行，但前提是三个月里没人读代码，你把所有的代码审查都换成各种循环，用户投诉了，丢给agent 程序崩了，丢给agent PM开了个ticket 丢给agent CEO在slack里写了一篇，又臭又长的文章，说我们该做什么，也丢给agent 然后你就不再读代码了，因为代码量太大了，根本没人读得过来 PR审查变成了瓶颈，于是你又用agent测试，和agent代码审查把它剃掉，但这些东西，对软件架构都没有直觉 因为我们还没训练出这种能力，于是某天你一觉醒来，就会碰到一个问题, 这事我们真遇到过, 当时我们扛过去了, 而且那时候觉得还值, 我们花了三周时间重新去熟悉那个三个月前就不再读的代码库, 因为不管我们用多复杂多专业的提示词都没法让Opus, 当时还是Opus 4.1真正找到根因, 我们不得不花好几天去翻代码, 最后才发现其实就是一个主件被一路传遍了整个系统, 它需要改成另一种对象类型，而且需要自己单独建一张表，所以这事真的发生在你们身上了，对真发生了，当时我的反应是，确实很糟糟透了，但我们搞定了，而且那时候我还觉得，大部分时间不读代码是值的，代价只是偶尔要花两周，手动修一个问题 但我现在不这么想了，因为我们现在能写的代码量，其实是以前的十倍甚至一百倍，问题只会越来越严重，那我们聊聊软件工厂吧，在你看来，我觉得这个词被用的太犯了 AI之前的软件工厂，和AI之后的软件工厂，你是怎么理解的，你知道软件工厂最早的定义，第一次被用是什么时候吗，是1968年的一次NATO会议，这个Grady Butch肯定知道，对没错，你该去问Grady 当时他们讨论的想法是，你得建一套步骤系统，就像工厂流水线一样，有编程环节，测试环节，验证环节，集成环节，那时候我们连CI斜杠CD都没有，版本控制也才刚起步，但你已经需要一条工厂了，后来这个概念，被东芝和一堆公司采用，再下一个节点就是DevOps 那时候的想法是，我们要做CI斜杠CD 要做自动化 要用Chef Ansible Puppet这些工具，所有这些技术的本质就是，不用再让人跑进数据中心，去手动扩磁盘，或者在AWS控制台上点来点去，对就是这样，相当于我们建了循环，服务器磁盘用到90% 发一条告警给Nagels Nagels触发一次Chef运行 Chef把磁盘扩容，这就是反馈循环对吧，这套思路已经存在很久了，然后到了2018年，有叫Nick Shalin的人，他当时是空军的CTO 还是首席软件官，写了一篇100页的文章，核心就是，国防部需要一个软件工厂，美国国防部，对国防部和空军，他管他叫DepthCops工厂，他说我们需要所有那些优秀企业都在用的东西，我们需要Jenkins 需要代码质量扫描，需要安全扫描 需要CI斜杠CD 需要能快速交付，我们当时三个月或一年才发一次版，我们需要像其他公司一样每天都能发版，而要做到这一点，我们就得真正拥抱这些自动化和技术，让90%的问题被自动化拦截，而不是靠人去手动检查，手动读代码，手动集成模块，在政府系统里谈这个，思想可真够超前的，我知道，不，我当时也很惊讶，心想哇不错啊，这其实也是其中一部分原因，就是说你看，我们正在落后，我不完全清楚所有原因，但我猜，也跟吸引真正优秀的人才有关，就是说你看，如果我们有现代化的技术战，我们构建速度很快，我们在乎效率，在乎善用大家的时间，在乎让大家把时间，花在工作的难点上 而不是手动去查CQO注入漏洞，这些是可以自动化的，所以这是AI出现之前的软件工厂 AI出现之前，现在因为AI 我听到这个词的次数多了很多，它跟之前是一回事吗，还是不一样，这个没有图，真的很难说清楚，但我尽量试着描述一下，软件工厂的核心，你得有一个工作来源，你可以想象成Linear Jira 或者某种状态，某种事实来源，不管是一个电子表格，还是别的什么，总之你得知道工作处在哪个阶段，在AI出现之前，你可能会做一些架构评审规划，可能会做一些Sprint规划，然后大家从队列里领任务，去把它做出来，接着你会提一个Pull Request 大家来Review 跑CI检查，然后把它推到生产环境，之后它会接触到你的用户，用户会抱怨各种问题 这些抱怨会流向你的支持团队，再回到你的工作追踪器里，程序会崩溃，你会收到问题报告，这些会进入你的监控系统，再进入你的追踪器，这就是你的循环，然后大家会根据优先级，从追踪器里领任务，产品经理，工程经理，工程师一起排优先级
Gergely Orosz：然后我们再去执行，这是第一个变化，这就像一个很长的流程，有很多阶段，这也是为什么，比如一个开发，修了一个bug 但等它再回到你手上，可能已经过了两三个月甚至更久，等它真正被修好，可能已经是一两年后了，这也是为什么你在用一款软件的时候，会遇到那种烦人的bug 你去跟客服沟通，但工厂的每个环节都有很长的延迟 [00:48:54]
Dex Horthy：可以这么说，而那个有人从队列里领走一个工作项，开始动手做的步骤，从开始做到真正集成进整个系统，触达用户，通常需要几个小时到几天，这还是在最理想的情况下，对吧，有时候你把它做出来，合进去，结果三个月后才真正发布，但我们假设自己处在一个，比较现代化的环境里，比如像Netflix 或Meta这样的地方，工程师有能力一天发布，一百次甚至一千次，但做这个工作本身，仍然需要两三个小时，而现在有了agent化的工厂，你要做的就是，把那个动手做东西的人拿掉，换成一个agent来做 [00:49:20]
循环工程与慢循环
Dex Horthy：换成一个agent来做，于是你就有了编排来触发任务，有了沙箱，有了LM 有了内部封装，也有了外部封装，也就是你为agent构建的开发环境，也许你给它一个浏览器，给它一个录屏工具，如果你用过像Cursor后台agent这类东西，它们其实就是在编程agent 这个内部封装外面，又构建了一层外部封装，然后你用这些来TPR 这里的问题是，好，现在做一次构建只要10分钟，而不是两小时或两天，于是瓶颈就变成了代码review 那好，我们就扔一堆AI agent 去做代码review 再搞agent化的测试，这样我们基本上能抓住，大量简单的问题，人类只需要聚焦在代码库里，最重要，最关键最核心的部分，然后你的agent化工厂，再往上一层 就是处理最顶端的环节，就是说，好代码部署了，上了生产，用户抱怨了，你直接把支持队列，接到agent上，有人抱怨什么 agent就试着去修，你不用去看公单，然后说好去发个什么，你直接把这个环闭合掉，取而代之的是，每次出问题，你就收到一个PR 每次Sentry或DataDog 或者别的什么工具里出现崩溃，它就进到追踪器，被agent领走，然后你收到一个PR 这就是Rampant Specs在做的事，唯一的区别是，这样一来你会有海量的代码，要review 然后大家就说，要不我们试试把灯关掉，我们干脆把所有人工测试和review步骤都拿掉，然后说，好，如果用户抱怨，那就是坏了，如果用户不抱怨，那就是好的，我们不去读代码，我们把整个系统当成一个黑盒来处理 你说你在OP4.1的时候试过这个，你建了软件工厂
Gergely Orosz：它跑得很漂亮，直到最后在你面前彻底崩了，你现在怎么看这个模型，因为我能想象一个理想世界里，它是可行的，但我们显然不在理想世界里，你觉得我们现在处在什么阶段，其中某些部分有没有可能在某个时间点真的跑通，或者说你现在看到了哪些进展，当下的实际情况是怎样的，你觉得这里面有多大比例是我们可以自动化的，或者说应该自动化的 [00:51:49]
Dex Horthy：如果你认识我关注我的东西，就知道我主张三件事，第一穿透炒作和术语，去试去跟真正在用的人聊，搞清楚哪些部分真的管用有价值，第二我们聊过用词，我会尽量找到并保护那些有用的语言片段，因为我觉得这能帮大家一起往前走，当你把一个有用的词，比如agent或者软件工厂拿去语意稀释，这也是Martin Fowler的词，让他什么都能指，大家都喜欢这个词，他就全变成炒作agent 就什么都不算了 agent可以是聊天机器人 slack机器人，编程agent 循环里的工具，什么都是，所以我喜欢保护重要有用的词，帮大家把对话从炒作和术语里拉出来，第三，我很在意往我平时工作的下一层深挖，我觉得永远是这样 跟上下文工程一个道理，我其实很少真的去构建ILM或理解训练ILM 但知道他们怎么训练Transformer怎么运作，会直接影响你在上一层怎么构建，放到软件工厂上，我的做法是，过去几周，我狠狠钻了一下，带可验证奖励的强化学习 RVR 它非常工程化，不像RLHF RLHF还是比较学术比较纯 RVR更像是这些实验室里，训练模型的一台机器，我还在研究编程agent基准测试，训练他们的技巧，比如给他一个小问题，让他解决，删掉他改的测试，回滚，打一个测试补丁，看能不能过，甚至今年前沿还有，这个我们可以后面展开 Frontier Code和Swebby Marathon 这些新基准，号称能更好的评估，模型长期维护代码库，写出可维护代码的能力 他们确实更好，但我觉得还不够，核心思路其实是，让Claude Code变好的，唯一东西就是强化学习，它变好的维度是，我们把模型和封装一起训练，于是模型变得特别擅长，调用那个封装里的具体工具，特别擅长读文件，写文件，搜索文件，所有这些都靠做这些题练出来，这就是它比之前所有CLI编程agent 都强那么多的原因，所以大家觉得，好这个强太多了，它们只会越来越强，但它只是在某一个维度上变得很强，而它们没有在变强的那个维度，因为难贵，也许我们需要在怎么设计这些验证器，和基准上更有创造力，是我怎么写出三个月后，能让人类和agent 主要是agent 在代码库里的生产力提升 而不是让代码库越来越烂的代码，所以你觉得这块就是缺失的，我们还没看到太多进展，我没看到，当然没人知道实验室内部在做什么，都很保密，但我觉得看基准测试，通常能反映实验室的方向，对吧，如果没有任何一个基准，能告诉我这个模型写的代码，会让我的代码库变好还是变差，那我们目前最好的，我觉得Cognition团队的Francirco很有意思，他会看测试过没过，然后有两层模型审查，一层是评判模型，检查模型打的补丁，跟标准答案集里的补丁像不像，就算模型没写出，基准期望的精确代码，功能上是不是等价的，再一层是另一个评判模型，做的代码质量审查，这确实更好，但还不够，这也是为什么我觉得 Agent做代码审查，确实能抓到问题，抬高你的下限 但我不相信写代码的模型，和读代码的模型是同一个，你问模型，这段代码好不好，他会说很好，很全面，有单元测试，你肯定试过，你说好，审查一下我同事写的这个PR 告诉我所有问题，他会说有这个毛病，那个毛病，但他很谄媚，想说你爱听的，所以我真的很难信任一个模型，去评估代码质量，我有一些想法，比如能不能建一个基准，让模型连续构建20个功能，全程维护代码库，而且不知道后面会来什么功能，你把它当成真正的产品团队，你不知道下周要做什么，直到到了那周，才知道什么最重要，然后我们能不能试着评估，能不能设计一个足够难的问题，让大多数前沿模型，在第六七个一手就挂掉，这么说公平吗，在AI之前 [00:55:49]
Gergely Orosz：软件工厂其实就是一大堆循环 PM给开发开个ticket 开发写完部署上线，用户客户用起来，客服收到反馈再开Ticket 然后PM排优先级，就这么一圈一圈转，现在是不是可以说，一个公司一个团队构建和维护软件的，这套软件工厂正在发生变化，因为每个人都在替换其中的某些环节，比如最不激进的团队，可能只是开发开始用Claude Code 或Codex写代码更快了，花在写代码上的时间变少了，再进一步，有些团队连部署和反馈环节也在改，还有一些agent已经在直接一键修bug了，所以是不是可以说，软件工厂正在到处发生变化，只是速度不同而已，我觉得每个在做生产级软件的团队，都在疯狂的试验尝试 只是节奏不一样 AI原生的创业公司，大部分环节可能都有agent了，而那些比较落后，或者说更谨慎的团队，可能只在少数几个地方 [00:57:37]
Dex Horthy：用了agent 其他地方还没动，我觉得关键就在这里，如果你想做循环工程，你应该一次只建一个循环，而且要让它小而可控，基本上，我觉得除了别读代码这条之外，其他建议都挺好的，把客服ticket 自动转成系统里的ticket 然后再自动转成PR 这很好，我在HumanLayer这边，一直在琢磨的是，怎么在这个工厂里，多加一个检查点，现在的情况是，只有一个人类视角，就是review PR 有时候PR是一百行，有时候一千行，但不管怎样，对人来说工作量都不小，尤其是代码写的烂，需要反攻的时候，人得花很大力气，去说这个不对，你得这么改，然后又把球踢回给agent agent再交一板新的，来回折腾好几轮，一旦方向已经定下来，开始往前冲了，再想掰回来就特别难，还不如直接推导重来 那怎么围绕这个环节，建立控制和机制呢，我的思路是，在把任务交给实现agent之前，先做一点人机协同的规划和讨论，不管叫规划也好，叫规格也好，规格驱动开发，这个词现在也被用得很乱了，意思已经模糊了，但核心就是，我们能不能在动手写代码之前，先花一个小时，让最后review PR的时候，只需要20分钟，因为代码已经是完美的了，而不是反过来，每个用户反馈的issue 都直接走循环变成PR 然后我们review 那个PR要花6个小时，因为要来回沟通反复修改，我追求的就是找到杠杆，在软件工厂这个框架下，你其实有三个选择，如果你要全面压住 agent化的软件工厂，你可以把灯一关，让一切自动流转，然后起到别致，造太多烂代码 起到下一代模型来得够快，别等到代码库，堆成一座垃圾山，你也可以把速度放得很慢，每个PR都仔细读，每一行代码都看，这样的话 I能带来的提升就比较有限，我觉得大概就是30%到50%的生产力提升，这是我在团队里实际看到的情况，或者你可以找到正确的杠杆点，让人力真正发挥作用，在规划上花一个小时 [00:59:35]
循环工程的实践与陷阱
Dex Horthy：在规划上花一个小时，能在实现阶段省下四个小时的反攻和设计修正时间，这就是我所说的寻找杠杆，找到正确的杠杆点来引导agent的工作，你就能在保持代码质量的前提下，把速度提升两到三倍，我说的质量是指，如果这段代码是人类仔仔细细手写的，它应该长什么样
Gergely Orosz：agent写出来的就接近什么样，稍微往回跳一下聊点之前的想法，后面我们再绕回来，这个是你更早提出的，大概是去年你有一个研究规划实现的框架，我们能不能聊聊最初那个RPI框架是什么样的，以及你后来对这个方法有了哪些新的认识，哪些地方你发现自己搞错了，好没问题 [01:00:24]
Dex Horthy：我们第一次聊RPI是在2025年8月，当时的基本思路是，在你动手写任何东西之前，先去读大量的代码，并行的派出一堆子agent 把代码全部理解清楚，这个技巧在处理复杂问题和复杂代码库的时候，特别好用，你直接让Claw去做一件事，他可能只读三个文件就改完了，完全没有上下文，所以你先做研究，甚至不告诉他你要做什么，只是问他，能不能给我讲讲，这个系统是怎么工作的，那个系统是怎么工作的，他们之间是怎么连起来的，然后你会拿到一份Markdown文档，这就是上下文工程的部分，这个过程可能消耗 10万Token的上下文，但你得到的是一份 1万Token的文档，把内容浓缩了，接着你开一个新的context window 开始做规划 说实话我们去年夏天做的那些规划，其实挺糟糕的，但基本流程就是很长一段，你说好这是我们要做的东西，这是研究文档，给我出一个实施方案，现在回头看大家都在痴迷于，怎么让agent工作的更久，我觉得2025年五六七八月那会儿，很多人对规划特别感兴趣，原因就在于它是一个非常有力的杠杆，能让agent持续工作更长时间，如果你说，给我做一个BRB的墨西哥卷，配送SaaS 他可能就给你一个首页，然后就没了，但如果你说，先给我出一个方案，他就会产出一份很大的计划，然后在下一个context window里，你说，这是方案，这是我们要做的所有改动，去执行吧，他就会一直做到方案完成为止，所以方案是一个很好的方式，能锚定agent 提醒他，嘿 这些全做完才算完，这就是最初的RPI 而方案文档的问题在于，它没有给你杠杆效应，方案里写的是，每一行要改的代码，用diff块的形式，还有所有要新写的东西，所以人们会去审这些方案，我们也推荐这么做，我们让大家去读方案，我们自己也都读，但后来我发现，我其实只是大概扫一眼，所以你并没有真正用它，来重新引导agent 它只是摆在那里，然后你去写代码，结果一团糟，有些人既审方案又审代码，结果就是方案要花你20分钟读 people request又要花你20分钟读，而且他们还不一样，所以你实际上花在读代码上的时间翻倍了，而不是减少了，你这是反杠杆，等一下规格驱动开发跟这个没关系吗 [01:02:36]
Gergely Orosz：比如一年前amazon kiro和github workflows做的那个，也是先生成一个方案，让人审一遍，你也可以编辑，然后他再去执行这部分，表面上看很漂亮，应该很好用，但结果被扔进了垃圾桶，除了一些维护项目，我觉得它基本就是不行，我收到的所有反馈都是，大家干脆不用了，因为它确实不太好用，这跟最初的RPI框架有点像，对吧 [01:03:25]
Dex Horthy：我们的做法 RPI和规格驱动开发最大的区别，有些人把RPI叫规格驱动开发，因为对一些人来说 SDD的意思，就是我在写代码的时候，用了一堆markdown文件，然后忘了里面写了什么，规格驱动开发，那些就是我的规格，我用它们来驱动开发，有个OpenAI的研究员，聊过规格驱动开发，说别读代码了，直接写规格，把写代码当成，把规格编译成代码，那部分一直没真正实现，也许GPT-7能行，但问题是，我在SpecIt的一个GitHub issue上，那个issue开了一年了，每隔几周我就收到邮件，县城里一堆人抱怨同一个问题，我改了规格，又改了代码，代码和规格就偏离了，代码再变，我怎么让规格保持同步，基本上就是 你现在有两个事实来源，它就没用了，所以RPI的思路是，这些文档，我们有一阵子留着，但两三个月后，我们就觉得，这些其实是战术执行文档，我做研究，做计划，做实现，然后把文档扔掉，下次需要研究的时候，我从头再做，因为token很便宜，我的时间很贵，而且如果我附用一个，已经跟代码库真实状态不同步的研究，可能浪费的时间更多，所以我们每次都现场生成，这就是为什么上下文工程仍然重要，把代码库的状态和构建者的意图，压缩成小的产物，能在未来某个任务范围内附用，这是一种非常强大的战术方法，但我不太纠结于，你该在代码库里留哪些长青文档，我见过有人试图在文档或规格，和代码之间保持同步 我不觉得有人真的觉得这很有用，你可以做也能跑通，但维护同步所花的精力，跟用AI大概也能轻松做到，但我从没见过有人说，对这很棒我们很高兴有它，你可以做也许有帮助，但我不觉得有人觉得，它有用到值得维护一套系统，来保持规格和代码同步，而不是始终把代码，当作唯一的事实来源 [01:05:37]
Gergely Orosz：你刚才提到一个有意思的点，就是在做上下文工程的时候，有时候需要压缩，你之前也聊过有意识的压缩，当上下文很嘈杂的时候，刻意把有用的部分压缩成，一个清晰的markdown产物，验证一下，然后开一个新的对话，我们能聊聊这种压缩，以及它为什么重要吗，听起来它已经是上下文工程的，一个基础构建了，对吧，对 [01:06:04]
Dex Horthy：频繁的有意识压缩，就是那个基础构建，它完全来自上下文工程，上下文工程就是，我们怎么从今天的模型里，炸出最多的东西，我们怎么改变，未给模型，未进context window 未进agent对话的内容，我们怎么控制这些输入，来拿到最好的结果，这意味着，尽可能多的在smart zone里工作，也就是context window的，前十万个token 而这种有意识的，频繁的压缩，基本上就是研究阶段，我们去读一堆代码，把它变成一个文档，这就是我们的压缩，我们把它带到下一个绘画里，我们去读ticket和意图，把它变成一个我们叫设计文档的东西，就是这是我们要做的高层规格，这是高层的当前状态，期望的最终状态，然后是一堆模型提出的设计问题，像一个非常详尽 甚至有点过度设计的计划模式，然后你拿着研究和设计，开一个新绘画，新的context window 你说，好，你已经压缩了意图，压缩了代码库的状态，现在你可以做计划了，我们知道最终状态长什么样，知道要去哪，现在来拆解怎么到那里，所有这些不同的步骤之所以存在，是因为模型在每个阶段都有短板，研究阶段基本不用管，我不读研究文档，就是去读一堆代码，然后生成一个文档，模型做这个相当厉害，如果你让他找bug 还要他对代码库发表看法，那就不一样了，但如果你只是问他，这段代码的意图是什么，这些东西是怎么拼在一起的，那通常就很简单直接，但设计软件的最终状态，架构和程序设计，模型就不太擅长了，他们会做很多决策，有时候对 有时候错，所以这里我们希望，能有一个人参与把关，然后具体怎么一步步走到那个最终状态，我们之前聊过，模型特别喜欢做我称之为横向计划的东西，你让模型列一个构建这个应用的步骤计划，它就会说，好我们先做数据库，然后做服务层，然后做API 然后做前端，我就觉得这其实挺糟糕的，因为等我们写完2000行代码，假设这还是一个已有的代码库，我们要改动系统里所有这些不同的部分，不到最后根本没法测试，所以我的做法是，好，如果是我自己手动来写，我会怎么做，我大概会先搞一个mark API端点，返回假数据，然后去把前端大概做成我想要的样子，接着我才会真正去写服务层，把数据真正接进去，然后做一次数据库迁移，建我的新表 之后再加大量业务逻辑，最后再加一堆错误处理，这跟模型的做法完全是正交的，模型会直接把数据库层，和所有错误处理都写好，但根本没人碰过，看过那段代码，所以这也是我们喜欢，让人参与进来的另一个原因，因为人有很好的品位和判断力，我宁愿读五个独立的小diff 每个我都能手动验证和探索，也不愿意读2000行代码，然后说好吧，它跑不通，我也不知道问题在哪，你不知道问题在哪，因为代码是你写的，你本该把它写对的，我们聊到上下文工程师的压缩，聊到怎么让自己待在context window的smart zone里，而smart zone之外就是dumb zone 我先声明一下，如果你对这方面还没有直觉 [01:09:12]
软件工厂与暗工厂
Dex Horthy：如果你对这方面还没有直觉，这个划分是非常好的辅助框架，那我们先定义一下这些概念，什么是smart zone 什么是dumb zone 这个边界比我想要的要模糊一些，我记得去年11月我们聊的时候，说大概是context window的前40% 但后来我们有了百万token的context window 你指的是smart zone 后来有了百万token的context window 我就把它改成了大概前十万token 如果是那种特别强的模型，比如4.8 我通常会放到20万token左右，但基本上Jeff Huntley和Ralph Wiggum technique的核心就是，你用的context window越少，得到的结果就越好，所以基本上smart zone的意思是
Gergely Orosz：如果你的上下文都在前面那一部分，效果就会好很多，而Dump Zone就是，一旦内容堆到了那个区域，基本就别指望了，模型会犯迷糊，做不了什么事，表现会退化 [01:10:44]
Dex Horthy：对但有时候这需要靠直觉，我经常会把Token数推到30万 40万 40万比较少见，但我会推到25万 30万Token 去做某些特定类型的工作，因为我的直觉告诉我，我可以继续推进，性能不会退化，但如果你对LM没有很好的直觉，那么对于小一点的模型 10万Token是个参考线，对于Codex Opus 4.8这种特别强的模型 20万Token通常是一个不错的辅助参考，超过这个线，你的结果质量可能就会下降，我观察到最明显的信号就是，模型拼命想让测试通过，你已经用了20万Token了，它就开始，好让我试试这个，好让我试试那个，它会试一堆办法，而且越来越极端，甚至会想，让我把你的点文件删了再试一次，这时候事情就变得非常非常诡异了，所以如果你开始看到某些迹象 比如我们已经用了30万token 我还得修单元测试，我就会说，好，把我们做过的所有东西，写到一个文件里，或者我直接用模型自带的压缩功能，然后我开一个新绘画，从3万或5万token开始，我会说，好，我们现在要做一件难事，你要把这个该死的测试搞过，而且别犯蠢，对了 [01:11:51]
Gergely Orosz：你刚才提到模型犯傻的事，你说过，如果模型跟你说，你说的完全对，你就该重新开始了，我们都遇到过这种情况，他跟我说，哦你说的完全对，我当时只觉得烦 [01:12:12]
Dex Horthy：但为什么我们该重新开始，根据你的观察，这时候到底发生了什么，对，这个问题问得好，新的那句，你说的完全对，我觉得是你反驳的对，那个版本，对吧，对是Opus那个，对吧 Opus的表现就是那种，你没跑测试吧，你反驳的对，我确实没跑，但对我来说，你说的完全正确，永远是模型在你指出它，错得离谱时的标准回应，你要是生气沮丧，或者只是想指出它做错了什么，它就会回你一句，你说的完全正确，我们大多数人都有这种体验，它嘴上这么说，然后继续做错事，所以一旦它开始犯蠢，问题就出在context window里，四个关键因素上，一个是大小，也就是token数量，一个是信息质量，里面有没有错误信息，比如模型在思考过程中，认定了一件错误的事是真的，还有信息缺失 是不是缺了本该有的上下文，最后是轨迹，轨迹非常微妙，你可能遇到过这种情况，轨迹是指你的提示方式吗，是整个交互的历史记录，我管它叫轨迹，就是agent过去实际做了什么的，完整记录，比如我说改一下这个agent 做了修改，然后跑了测试，测试挂了，他又修好了测试，那我对他下一次改动的信心就非常高，因为他会沿着同样的路径走，对话历史里，上次用户让我做一件事，我改了代码，跑了测试，测试挂了，我修好了，然后告诉用户，但如果我说改一下，他改了，没跑测试，那我就走上了另一条轨迹，这时候我再说再改一个，他基本就是自回归的，在预测这条对话的下一条消息是什么，我们在No Vibes Law里聊过一个例子，模型犯了个错，你骂了它 它又犯了个错，你又骂了它，然后呢，这条对话的下一条消息该是什么，看看历史记录，我大概应该再犯个错，好让人类来骂我，所以我就觉得这是个绝佳的例子，说明该重新开始了，我们来聊聊软件工程正在发生的一些变化，你最近谈到编程范式的演进，是从Token Harder到Token Smarter 能讲讲你说的Token Harder和Token Smarter是什么意思吗，好Token Harder嘛，我有个群聊叫Hyper Engineering 里面全是一群想把云订阅额度榨干的人，哇好吧，听起来挺有意思的，那地方好玩吗，好玩是好玩，但全是Token Harder那一套，你看我做了这么多side project 你看我把云Token全用满了，我有六个Claude Code的账号，全部用到上线，每五个小时的周期我都掐好时间，保证Token一用完，限额一重置就立刻续上 这就像Eli Godra在目标里说的，你在优化工厂里，某一个节点的利用率和效率，而不是端到端的目标，我们怎么交付价值，交付人们喜欢，稳定，能长期用的东西，但这就是我对Token Harder的理解，按工厂那套也是一回事，如果你把人类从代码审查里拿掉，你就能往系统里塞更多Token 我们聊到了软件工厂，那按工厂又是什么，暗工厂这个概念来自一种工厂形态，里面所有东西都有机器人自动化，你可以想象一个汽车工厂，全是机器人在造车，里面没有灯，因为没有人类，原来是这样来的，暗工厂，对，你走进去没有灯，连电灯开关都没有，所以就是全自动化的软件工厂，基本上没有任何人类输入，没有人工输入，原材料进去，汽车出来 我觉得在微观层面，你可以在自己的流程里，搞一些暗的小循环，比如代码审查agent发现问题，就把它丢回给构建agent 修好再回来，这个循环就是暗的，不需要人去兜这个圈子，但完全不看代码的全暗工厂，确实是最大化token利用率的好办法，就好像如果你相信你的工作，就是从机器人那里，榨出尽可能多的智能，因为这样你才能从时间里，获得最大价值和最大杠杆，那就token harder 而我的看法，基本就是我们之前聊过的 Token Smarter是，好我怎么才能更快，怎么在不关灯的情况下，从AI那里，榨出尽可能多的价值，同时还能保持控制，品位和判断力，理解系统架构，并且把我做了，十年软件工程，积累下来的那些，固执己见的经验，应用到程序设计里，这样我才有信心，代码会随着时间推移，变得更好 更可维护，这就像你看 Google内部的SRE团队，他们出了一本书，叫SRE Site Reliability Engineering 整本书的核心思想是，我们要从一个数据中心，扩展到五个数据中心，而且需要同一个六人团队，就能管好五个数据中心，明年还是这六个人，要能管好五十个数据中心，本质上就是，我们怎么用软件来解决这个问题，而不是线性的扩张，比如每个数据中心需要五个运维，所以我们就得跟着加人，我们怎么持续地把那些，不需要人力的部分自动化掉，这跟我刚才说的可能有点不搭，甚至有点矛盾，但这个思路就是，你怎么找到杠杆，以及找到杠杆的方式 [01:16:54]
Gergely Orosz：我觉得你刚才说的意思是，在Google他们从来没想过，要把那些SRE从流程里完全拿掉，他们只是说，看我们能不能提前思考，让自己具备规模化能力，而且他们团队其实也扩张了，实际上不是六个人，我记得Google具体说的是，好我们现在有五个数据中心，明年会有五十个，你们有6个人，我们不想搞成60个人，也不想加管理层什么的，能不能用12个人，或者10个人搞定，然后等我们有500个数据中心的时候，实际上他们的SRE团队也变大了，但是，当然没错，但是他们从来没有，你知道，我觉得作为工程师，当有人说，好我们就是想做到零工程师，我们会感觉挺受威胁的，我是说，那可不是什么让人想待的地方，不过听起来 [01:17:38]
Dex Horthy：那也不是一个可能呆的地方，如果零工程师，那我们俩都没法在那工作了，对吧，但我理解Token Smarter 是不是就是，让我们把人留在循环里，持续增加价值
Gergely Orosz：然后找出哪些部分不那么相关，比较无聊，我们不需要亲力亲为，这样一来，一个开发者大概能比以前做更多事，但你被设计成整个体系的一部分
Dex Horthy：工厂的灯也还亮着，对，基本上我想表达的是，这里的关联在于SRE构建的东西，让人力规模按平方根函数，或对数函数增长，而产出却是线性增长，而你想说的是，做到这一点靠的是好的架构，和好的程序设计，所以为了避免陷入那种，不得不往问题上堆更多人，堆更多token的困境，如果你把软件设计的好，让它随着时间推移变得更可维护，更具可扩展性，而就目前来看，要做到这一点，基本上还是需要人留在循环里，我们来聊聊AI垃圾，你曾经写过 [01:18:53]
Gergely Orosz：没错I能帮你写代码，但它也能帮你写规格说明和PRD 但同样的规则始终是垃圾进垃圾出，如果你把自己的思考外包出去
Dex Horthy：你得到的就会是垃圾，对，所以基本思路是，我们怎么看待高质量输出这件事，你可以手写代码，也可以跟模型来回协作，可能稍微快一点，你掌握着控制权，他每次改完 [01:19:45]
Token Harder 与 Token Smarter
Dex Horthy：他每次改完，你都去看改动，改得不好就告诉他，不对，我要的是这样，然后你一点点，慢慢的推进，这大概算是跟agent协作的，第二或第三阶段 agent帮你写所有代码，但你全程深度参与，这样会让你更快，但不会快太多，离那个上限还差得远，有一个层级，然后是在你还在意，代码质量的前提下，能达到的最高速度，再然后是你把灯泉关掉之后，能达到的最高速度，所以我们一直从杠杆的角度，来想这件事，一切都从一句话，或一段语音备忘录的碎碎念开始，我想做这个东西，它大概是这样运作的，随便什么，假设平均就两句话，我得修这个东西，或者来了个支持公单，我得搞定它，如果你能用AI 把这两句话变成一页纸的文档 然后确认这一页是对的，再把这一页扩展成三页，确认三页是对的，再把三页扩展成十页的详细大纲，那你就能写出上百页的代码，也许不完美，你也不该在这些文档上死磕追求完美，但你是在提高确定性，你在降低输出的不确定性，可以这样想，你有一条他要走的路线，然后有一个概率范围，代表他可能偏到哪去，如果你在越来越详细的定义，你要做什么想怎么做的时候，一路都在审视，你其实是在压缩不确定性，压缩最终可能落到的那些中态的范围，这是我用物理学的思路在讲，你得把所有概率叠加起来，我有个感觉，特别喜欢玩即时战略游戏的人，可能会特别擅长用AI 因为你得怎么说呢，麦普卡刚聊到战争迷雾，还有那些处于前沿的东西，这个问题上，还有一些我们不知道的东西 怎么去发现，怎么根据我已经看到的信息，现在做出最好的决定，我看到了一些信息碎片，所以有30%的概率是这种情况 40%的概率是那种情况，我怎么获取更多信息，好在脑子里重新算一遍这些概率，判断哪条路最有可能带我们走向成功 [01:21:48]
Gergely Orosz：说到最有可能带你走向成功的路，我们来聊聊你的公司，你们刚刚结束隐身模式 HumanLayer HumanLayer是什么，你为成功设定了多大的概率 [01:22:07]
Dex Horthy：好问题100% 100%的概率，也许110% 不过不开玩笑 HumanLayer是一个AI IDE 一个协作平台，也是你软件工厂的构建模块，基本定位是帮工程师，在复杂代码库里解决难题，大体上有两类构建者，一类是用Vib Coding做side project 另一类是在做生产环境，软件风险很高，一旦出问题就要被罚几百万美元，或者让公司损失几百万美元，中间当然有一整个光谱，但如果你大概在这个光谱的左半边，你在做真正重要的软件，它得经得起时间考验，得长期维护，那我们就是在帮这样的人，用两到三倍的速度解决问题，同时不滑向SLAP 核心问题是 怎么保持接近人类的代码质量，同时快两到三倍，你构建这个产品时，带着哪些想法起步的，有一个想法，我们现在特别兴奋，其实都源于RPI和，用规格来驱动这件事，我前面一直在暗示这个思路，从非常高的层级开始，一层一层往下聚焦，不断重新调整方向，找到那个能让你加速，又能提高agent产出质量，让它更接近，你真正想要的东西的杠杆点，另外还有一个，我觉得很有意思的事，我昨天刚发了个帖子说，嘿各位，我们是不是该干掉poll request 这个我现在还不能聊太多，但基本思路是，未来的IDE需要从零开始，为agent重新设计，它甚至可能不是很多编辑器，一开始就是个文本框，然后硬加了一个agent的标签页 后来你看到像cursor3 我甚至找不到文本编辑器在哪了，我知道它存在，有人跟我说过，可以切到文件的文本视图，但它本身也是agent优先的，所以我们从零开始思考，一个为帮助开发者与agent交互，管理agent的工作而设计的IDE 应该长什么样，然后我们退一步看，怎么把它做成协作式的，内置同步引擎，持久化流，以及所有这些技术组件，让我能在实时状态下，就获得别人对我agent的工作的，输入和反馈，而不是等到pull request阶段，优秀的工程团队，几十年来一直在这么做，我们先做设计评审，用一两页Google Doc 或者实页什么的，讨论清楚要怎么建这个东西 PR Dirt 对你的架构需求文档，然后进入Sprint Planning 拆成一个个小Ticket 决定谁做什么 AA其实可以帮上所有这些环节 如果你只用AI来写代码，你会错过AI 能给整个软件开发生命周期，带来的很多好处，很多人说，我们不需要那些会议了，因为我们有循环，有安工厂，东西就在循环里自动流转，但问题是，如果你想真正提速又保持质量，那在动手写代码之前，就应该有这些检查点，而且应该用AI来帮忙，所以我们建了一个云平台，有点像Google Docs那种组件，你可以在上面评论 Agent可以展示Mockup Mermaid To HTML等等，基本上就是，怎么让Agent的工作方式，像Figma一样，一切都在云端，一切都是协作的，我能看到所有同事的绘画，他们也能看到我的，这有点像slack 相对于邮件的优势，你不需要参与每一个对话，就能知道发生了什么，你可以看到各个频道在闪，可以点进去看一眼，然后说行，这些我都不关心 但如果你看到一个，自己关心的对话，就可以直接跳进去，那怎么把这种模式，搬到工程工作中来，我们过去的方式非常死板，即使叫敏捷，其实也很瀑布 PRDR ticket 大家各自去开发，过一天PR回来了，然后一个人去review 怎么把它变成更像一锅汤的状态，这个世界的数据模型应该是什么样，你有agent的追踪轨迹，有文档，有任务和项目来组织这些东西，有实际的git diff到处在流，我为什么要一次性review所有代码，我完全可以让每个人的工作，都放在一个共享环境里，谁都可以随时去交互，这让我想起GitHub软件团队 [01:25:58]
Gergely Orosz：在GitHub和它的竞品出现之前，你可能有个tracker放在某处，但大多数团队在公司内部，基本是各自为政，你不知道另一个团队在做什么，我记得GitHub之前，各个团队独立运作，有些团队用贴满变迁的白板，但公司里其他人，完全不知道他们在干什么，大家都在孤立地工作，而现在有了GitHub 或者公司内部的GitHub版本，你随时可以看到一个团队在做什么，看到pull request飞来飞去，你可以加入进去，有历史记录，所有东西都连在一起了，很长一段时间里，大家觉得用GitHub是理所当然的，或者别人会去抄它，所以我感觉，你是不是想为软件工厂，那些按工厂和循环，遍布各处的地方，打造类似的工作流，一种新的工作方式 [01:26:41]
Dex Horthy：让人觉得自然，但把它想出来本身是件很难的事，是反直觉的，我们能不能做出一个东西，达到GitHub当年的效果，但好上十倍，更具体的说，比Poll Request这种离散的工作单元更连续，更实时更协作，我现在开始理解你为什么说，也许该干掉Poll Request了，因为Poll Request是GitHub发明的，对吧
Gergely Orosz：它不是Git本身的东西，而是GitHub做出来让你做代码review 在合并前修改或者直接拒绝等等的一种方式，而且它很可能比我们之前用的任何方式都好得多 [01:27:54]
Dex Horthy：之前的方式我猜就是把GitPatch用邮件发给Linus 请他合并到内核里之类的，他们现在还在这么做，对他们来说管用这就是关键，但也只对他们管用，是啊，我不认识还有谁这么干，我敢肯定，在GitHub出现之前，你们用的应该是CVS或者别的什么吧 CVSTF 前提是你从微软那里拿了很多钱，他们让我们本科用Subversion 因为发明Subversion 那哥们是芝加哥大学的，我毕业第二年他们就全换Gate了，我当时就想靠我学了个没用的东西，就为了满足别人的虚荣心，专门针对AI创业公司，或者说在AI之上
Gergely Orosz：构建产品做AI产品的公司，你觉得地理位置和人脉有多重要，尤其是你就在硅谷，我们看到有研究说，创业公司在这里拿到融资的比例，比普通创业公司更高，你感受到这种优势了吗，还有你觉得待在某个特定地方，不管是硅谷还是别处，有什么劣势吗，我对这事没什么特别强烈的看法 [01:28:48]
Dex Horthy：其实Paul Graham在瑞典做过一个演讲，讲为什么旧金山很酷，我就不复述了，推荐大家直接去看那个，我们可以把链接放show notes里，他讲了硅谷的各种动态，那种先付出后回报的文化，还有大家会因为你就待在这里，而更把你当回事，我在芝加哥住了很久，有很多从高中大学，在洛杉矶长大时认识的好朋友，但我从来没有像现在这样，感觉跟同类人这么合拍，从来没有感觉这么被看见，这么有连接，这里人太多了，回到刚才说的创始人那点，都是些非常在乎能力极强的人，我们遇到的问题都一样，喜欢的东西也都一样，我不会搞那种，一起打游戏的局域网派对，但我的朋友们会过来，我们在办公室待到11点 [01:29:13]
HumanLayer 与 AI 时代协作
Dex Horthy：我们在办公室待到11点，就是一起干活，捣鼓一些酷的好玩的项目，这种事你在别的地方做不了，没有足够的人群密度，没法走到哪都自然发生，我太喜欢这点了，拿什么我都不换，对人群密度这个点，真是一针见血，说到招聘，你们现在主要在招什么样的人，我很好奇招聘标准怎么变，对你来说一个出色的工程师，意味着什么，以及你怎么去确认这些特质，总的来说，我们在找软件基本功非常扎实的人，要懂分布式系统，懂计算机科学的核心基础，操作系统这类东西，不是说非得是搞内核设计的博士，但有这些基础会容易很多，我觉得我们可以在几个月内，把一个人教成很不错的AI开发者，能建立起足够的直觉，让你快速起步，然后持续成长，但要在三个月内，教完一个计算机本科的内容 那太难了，在软件工程或者产品工程，做产品这个领域，有什么问题空间是你特别兴奋，觉得未来几年会去攻克的有趣方向，我的联合创始人能聊得更深，但实时云端沙箱同步这些领域，有很多有意思的事情在发生，就是用这些过去几年变得非常扎实的新构建块，我们很喜欢ElectroCycle团队，也在用Durable Streams 问题是怎么去构建那种更分散更分布式，甚至接近去中心化的系统，这对编程来说很有意思，因为你希望能在任何地方运行编程agent 能短时间跑长时间跑按需跑定时跑，所有这些还要让他们都成为同一个大脑的一部分，所以怎么说呢，我们是在给AI做工具，但构建协作平台本身就有很多非常难的问题 现在有很多新技术让这事变得更容易更有意思，但离简单还差得远，听起来你的意思是基础设施层在某种程度上，一个新的基础设施层正在被构建，这需要一些时间 [01:31:47]
Gergely Orosz：但会变成新的构建块，最终成为原语，就像云，我们现在已经有原语了，但那花了好几十年才拼起来，对 ALL是2006年出来的吧 2006年
Dex Horthy：那Kubernetes是十年之后才有的，最后推荐一本书或者阅读材料吧，你自己很喜欢的，最近我们经常聊Martin Fowler的重构，经典，可能是因为我们花了很多时间，在改善现有代码的设计，想办法让模型写出好维护，好读，好理解，好扩展的代码，我觉得我应该有更好的答案，但这确实是最近脑子里想的最多的，我们在重读很多软件工程的经典，重构，代码整洁之道，程序员修炼之道，所有这些书，我觉得现在比以往任何时候都更有意义，太棒了 Dex 非常感谢，聊得很开心，太爽了，哥们谢谢你请我来 [01:32:13]
Gergely Orosz：真的很棒，我玩得很开心，不知道你听完什么感觉，反正我真的很喜欢这场对话 Dex对性别编程深信不疑，但偏偏是他提醒我们，一旦你不再读代码，大概三到六个月后，你的代码库就会变得重写比修还容易，这是他团队的第一手经验，他们搭了一个轻量级软件工厂，跑了一段时间，最后不得不关掉，我也很喜欢慢循环这个概念，循环工程这个词，对我来说其实有点空洞 Dex团队做的事反而很朴实，一个Crown定时任务，每晚跑一次，修一个问题或一种反模式，然后提一个小PR团队，每天早上醒来，代码库都比前一天好一点点，开发人员仍然需要审查和改进，说实话，这个做法任何工程团队，今天就可以直接用起来，最后那段历史课，我也听得很过瘾，软件工厂这个词，来自1968年的一次NATO会议 用工厂的类比来让软件去构建软件，这个想法已经超过60年了，我们行业每一代人都在尝试，把构建软件的循环自动化得更彻底 AI Agent不过是又一次尝试，虽然很可能是最成功的一次，别忘了看下面的show notes 里面有相关的The Pragmatic Engineer深度文章，对AI工程和相关话题挖得更深，如果你喜欢这期播客，请在你常用的播客平台和YouTube上订阅，如果能顺手给节目打个分，那就更感谢了，谢谢，下期见 [01:34:19]