我用 GrooMe 这个 skill 写一个挺简单的 API 端点时，被拷问的怀疑人生。他问了我三十五个问题，没开玩笑。压力很大，也很烦人，而且逼着我做了更多思考。今天的嘉宾就是这个热门 skill 的创作者 Matt Pocock。Matt 是从开发者转型的教育者，以他的 Total TypeScript 系列闻名，现在又以他的 AI Skill 和教学视频广为人知。
今天我们会聊聊 Matt 进入科技圈的不寻常之路。他做了很多年发声教练，还自己动手做过教学软件，还会聊 Matt 那些热门的 Skill Grill Me Wayfinder 以及为什么这些 Skill 会传得这么广。从几十年前的编程书里汲取灵感，用 AI 构建更好的软件，还有很多其他内容。如果你想了解在使用 AI agent 时，哪些软件工程基本方法依然非常管用，这一集就是为你准备的。
Matt，很高兴你能来上播客，终于来了，太棒了！我是你的忠实粉丝，我看了好多期这个节目，我觉得这里就像软件工程师领域的 Tiny Desk，也就是小桌音乐会，你懂我意思吧？这可是件大事，所以很高兴能来。而且也很高兴能再碰面，因为大概一年前我们在微软 Build 大会之后也一起吃了午饭，当时特别开心。
不过现在能正式聊聊这个也很棒。说到这儿，我想问问你的背景，和科技界以及这个博客上的很多人不同，你一开始并不是学计算机科学的，对吧？完全不是在成为程序员之前的六年里，我一直是一名发声教练。我是个声乐老师，在伦敦工作，也在我读大学的埃克塞特工作。我教口音，教唱歌，教发声，我还念了这个方向的硕士。我花了很多时间，以为这就是我以后的职业了，对吧？
我对技术一无所知，根本没往那方面想过。我自己做过网站之类的，不过是的，我做了很久的发声教学，它对我的人生，包括对我的性格，都产生了极其重要的影响。能具体讲讲吗？做声音这块是怎么开始的？发声教练具体做些什么？来找你寻求帮助的都是些什么人？他们需要什么样的帮助？我一开始是做声乐老师的，大学的时候我参加过乐队之类的，我多少有点唱歌的经验，所以在大学时就自己成立了一家公司，做这些业务。
来找我的人就是想唱得更好，想在合唱团里用嗓子，或者纯粹当做爱好，并没有什么特别专业的需求。后来我去读了这个方向的硕士，开始去戏剧学校教学生念莎士比亚之类的台词，也招揽一些想做公开演讲的客户。我给几家咨询公司接过几场大活，去教他们怎么演讲，怎么把话说得更好。那阵子挺疯狂的。我之所以离开这一行，是因为我意识到要想做到不错的水平，就必须住在伦敦。
我不想住在伦敦。我试着住了大概两年，我就是讨厌那里。我很讨厌那里。我不是在伦敦长大的。我想回到乡下，回到我成长的地方。我也确实这么做了。于是我开始学着做程序员。为了能有一份可以远程做的工作，我基本上全是自学的。所以，基本上你是在找那些人在伦敦以外也能做有职业前景或未来发展的行业。一点没错，而且我自学过怎么做东西，用
JavaScript 写写基础的东西，因为我想让学生的上课体验更好，所以我做过那种抽认卡小工具。
我做过的第一个应用，可以说是我尝试过最有野心的东西了，那是一个网页音频分析器，可以分析你声音的频谱图，看看产生了哪些共振峰，你的 T 一和 T 二是否平衡之类的。做的极深，跑起来奇卡无比，但确实让我的课程效果提升了一点点。我一上来就在用很烂的代码做相当硬核的东西，后来我意识到，好吧，我开始看招聘启事，心里想我会一点 JavaScript，会一点 CSS，会一点零碎技能，于是我就直接转行了。
我辞了职，休息了几个月，最后终于找到了一份工作。那是二零一七年前后，当时在英国找工作比现在要容易一点，我就这么一步步走过来了。我觉得在某些方面你也挺幸运的，因为那时候正好是顶峰，那时候对工程师的需求极高，上过培训班只有几个月经验的人都能拿到机会。我觉得只要有动力、有干劲、又聪明，很多地方都会给机会，对吧？
对，而且因为我之前总跟人打交道，那成了一个巨大的优势，对吧？我去面试时听起来像个通情达理的正常人，而不是那种计算机专业刚毕业可能还不具备这些沟通技能的人。所以我有一种很奇特的能力，就是完全不懂技术，或者说懂得很有限。一开始的时候，但却有能力把技术知识给别人讲明白，对吧？所以基本上我只需要把自己的技术知识补上来一点点就行，而且我对此非常有热情。
那部分知识涨得挺快的。后来这两种能力结合起来，就显得有点不讲道理。因为我在好几家不同的公司里升职都非常快，我也说不上来。如果你能理解的话，就觉得自己跟我一起工作的其他软件开发者不太一样。那你是怎么一步步往上走的呢？就比如你决定了要做这行，自学了，去参加了一些面试，拿到了一个机会。我猜那肯定是一家小公司，对吧？
对一家很小的公司，里面有几个特别能启发人的软件开发者。基本上有一个人，我就不说他名字了，因为他喜欢保持匿名。但他常年穿凉鞋，在运河船上住了很长时间，留着长头发，特别硬核。差不多就是微软收购 GitHub
那阵子。我记得他走进来的时候几乎快哭了。对，一个极度讨厌微软的人，对，非常有代表性。我记得他让我做的第一件事就是在我的 Windows 电脑上装 CentOS 六，这是一种 Linux，一个相当硬核的 Linux 发行版，一个非常硬核的 Linux 发行版。
因为我们云端跑的应用用的就是它之类的。他人特别好，特别棒，而且一开始就教会了我很多东西。后来那家公司遇到了财务困难，我不得不很快跳槽去了一家外包公司，在那儿拿到了一个更高的职位。从那儿过了九个月，我又跳到了另一家外包公司，然后又是一家，就这么在不同的外包公司之间跳来跳去。后来我开始做开源，这就是故事的下一部分了。
在外包公司的时候，你们当时用的是什么技术栈？没错，当时的技术栈就是 TypeScript 和 React 这套，当时就已经用上 TypeScript 了。其实我那时就已经挺迷 TypeScript 了，差不多到了我的第二份工作，我觉得我就已经在做分享，讲 TypeScript 有多重要了。我们当时在给一家汽车制造商做一个学习管理系统，对吧？
就是典型的很无聊的外包项目，对吧？当时的前端团队规模挺小的，而且后端团队是在葡萄牙，对吧？典型的按前后端拆分，后端团队进展神速，而我刚加入的时候，前端团队动作非常慢，我们有一大堆 bug，后端团队老是不跟我们打招呼就改接口契约，我们就觉得需要某种东西来更好的把彼此衔接起来。TypeScript感觉就是顺理成章的选择。
一旦上线之后，我们的开发速度一下子就上去了，比后端团队还要快。最后他们因为我们太快了，甚至从我们组抽调走了几个人。所以对，这就是我跟TypeScript的渊源。这算是我跟他的起点故事。你是怎么进入开源圈子的？是在工作中还是业余时间？是业余时间，我业余一直在断断续续摆弄开源，对各种不同的东西都挺感兴趣。
那时候我已经开始玩Twitter了，我会在网上关注别人，觉得那是我想学习、想效仿的人。当时有一个人进入了我的视线，叫David Horseshed，也就是Twitter上那个专门讲状态机和TypeScript的人。他人特别特别好，说实话，我的职业生涯很大程度上都归功于他。我当时在做一个项目，我想这应该是在我的第四份工作里。
当时我们需要一个状态机，那是一个非常复杂的应用。你在跟别人打视频通话，同时还能通过某种 Matterport 集成，实时一起在一栋房子里逛。跨网络边界需要做很多联动，有大量复杂的内部状态。于是我当时用了一个叫 State 的库，我记得是 State 第四版，那个效果特别成功。所以我就琢磨，好吧，我怎么能让它变得更加类型安全呢？
于是我开始围绕它做一些工具，自己摸索着玩，写了一个围绕它搭建的 CLI。这引起了 David 的注意，我也成了 State 核心团队的成员。我开始提 issue，参与讨论这个库的未来。这让我接触到了一批我以前从未见过的顶尖开发者。David，还有另一位叫 Matias Berzinski 的人，在 Twitter 上叫 Andres Rake，他们是我见过最有才华的开发者，可以说是另一个层级了。
后来 David 想围绕这个项目开一家公司，他想重注状态图和可视化编程，认为这就是开发的未来。他们拿到了一些融资，那基本上是我第一份拿到美国薪酬的工作。对我来说是一次巨大的跃升。对大家都知道，欧洲或者当地公司，哪怕是英国公司开的薪资差距其实挺大的。我在写《Tree Model Nature of Software Engineering Compensation》时也聊过这一点。
美国公司，特别是在欧洲和在美国本土，他们看待薪酬和衡量创造价值的方式是不一样的，对吧？完全没错，他改变了我的生活，不管是看待金钱的方式，还是看待自由度的方式，而且这意味着我是在做自己热爱的事情。在那儿的时候，我开始做一些布道推广，因为公司很小，我做了大量的开发工作，但我也想帮他做推广，因为我相信他。
直到现在，我依然觉得状态图对某些工作来说是非常棒的元语。我现在对他的信念算是稍微往回收了一点儿。尤其是在AI时代，但我当时在多做一些这方面的事，这引起了Versail几个人的注意。因为当时Versail那边负责开发者教育的是Lee Robinson，他们有一支非常出色的团队，Delba de Oliveira、Lydia、Haley，他俩现在都在Cloud Code了。
还有利本人，我在那里拿到了一份工作，在Jared Palmer手下做类似那种角色，哇，居然是那个Jared Palmer本人，就是那个Jared Palmer，对他其实是我非常好的朋友，而且后来去了GitHub的，就是他他发起或者主导了堆叠式diff，也就是堆叠式PR，现在他在Cognition。对他去了 GitHub，做出了堆叠式 diff，然后走人，不做任何解释。
现在人在 cognition，一点没错。对，不过他确实也是业界的传奇人物了。是的。是的，他这个人很好。我在 Vsauce 在他手下没干多久，我总共只待了大概三个月。从那之后，我在 Vsauce 拿了一份挺奇怪的合同，因为我当时已经在琢磨 TypeScript 的想法，思考 TypeScript，想着或许可以做点 TypeScript 的教学内容。
我在 Stateley，也就是那家 State 公司的期间，就一直有一股想教东西的冲动。你知道，我之前教了六年书，那时候我已经有四五年没教了，可能都有六年了。我当时就想，我得重拾这个老本行。我很想念它，我喜欢做东西，喜欢做内容，喜欢教人。于是我便开始做这件事，从高级类型开始做。当时为了强行让 X
Date 实现类型安全，我接触了大量疯狂的类型技巧，很多非常高阶的 TypeScript 玩法，非常非常艰难的任务。
我觉得大体上是个不可能完成的任务。于是我做了几个小技巧。我做了这些两分钟的小技巧视频，发在Twitter上，反响一下子就爆了。那种感觉我以前从未体会过。我意识到这里面有市场，于是，一个周日，我一口气做了大概十三到十五个这种两分钟小技巧视频。我把它们排期在接下来的几周里发，我的粉丝量就从四千涨到了一万左右。
就像这样。你突然感觉到大家对这个有着巨大的兴趣，对吧？正是这样，一股巨大的浪潮扑面而来。可能是我表达的方式，我讲的内容结合在一起，产生了一种前所未有的共鸣。在我的职业生涯里，这种情况其实只发生过两次，所以我当时已经在考虑做一门课了，而且我知道自己能做好。我知道只要有合适的受众，只要能对上电波，我就能做出一门极好的课程。
于是，我进了Versail。我拿到的合同最初只要求每周工作三天，签了三个月，这是非常少见的。这是你想要的，还是说 Versail 那边大概是在试水，看看效果怎么样？Versail 一开始是想让我做全职的，你知道还有另外这条路，所以如果能做的话，就两头下注，留个后路，对吧？Excel成了我这边的奇怪备选，对我这挺疯狂的，对我来说很不可思议。
对大多数人来说，这会是梦想中的工作，对吧？我知道。所以说出来有点难为情，因为显然那是很多人的梦想工作。但我当时的心态是：行吧，我需要一份每周三天、稳定的朝九晚五，好让我去试试另外那件事。不过，平心而论，我觉得这样很合理，对吧？要是回顾一下你当时的处境，你职业生涯的大部分时间都在做声音教练，算是有六年吧。
然后有五年时间你一直在写代码，你喜欢写，觉得自己擅长，也觉得自己可能能教别人，但谁知道呢，对吧？到了那个节点，要说好吧，让我赌一把去做一件成败未卜的事。但如果你能一边拿着稳定的工作，一边把它做成，而且有了起色，那情况就不一样了，对吧？很多工程师都有抱负和想法，尤其是做软件工程，可以远程工作。你可以拿着自己的想法去开家公司，他们就会想：好吧，我是不是该直接放手一搏？
我是不是该辞职还是不辞职？某种程度上，我觉得这算是一种挺独特的模式。要是能做成的话，我是说。那是件特别离奇的事，因为很快就变得非常明显。我基本上没法留在Versail，大概是在我入职Versail两个月的时候。其实我经历了一段非常动荡的时期，因为他们在发布TurboPack时，我正好在那儿。TurboPack最初的一些文档还是我写的，我还建了一些团队成员。
那个。是个快得多的构建系统，对吧？对，本质上是个构建系统。当时他们做这个是想抗衡Webpack。写文档那会儿，我一开始就在我飞去了旧金山。他们发布那天，我也在Next.js Conf现场，是一次非常棒的经历。我跟所有人在一起，大家都在做各种筹备。我做着那些事，脑子深处已经在琢磨，因为我看到通讯订阅，还有我做的偷偷 TypeScript 那些东西在往上涨。
我意识到这里面有个很大的机会。当我搞了一次预售，直接就爆了。假设我在 Versaille 拿一份收入 X，预售进来的差不多就是三十到四十倍，可以说是立竿见影。而在 Versaille 拿一份 X
报酬本身就已经非常非常好了。确实，我对那份收入非常非常满意。但就是这样，太明显了，我没有别的选择。我很喜欢在 Versaille 工作，以后某个时候我可能还会回去，但我当时就是留不下来，我必须去做这件事儿。
那跟我聊聊 Tolo TypeScript 吧。你有了这个想法，开始每周用两天加上周末来做，然后搞了预售。那那是什么？我基本上尽量从不在周末工作，在这件事上我态度极其坚决。我也说不上来，不过我觉得自己大多时候做不到，因为我是个挺容易较真的人。我喜欢把事情做成，但我不是那种人。叫什么来着？旧金山那边管每周工作六天，朝九晚九叫什么？
九九六工作制，九九六工作制，那让我反胃。我极其讨厌那一套。我做的一切都是想建立一种生活方式，过一种大部分时间能陪家人的生活。这就是我的目标，先做这么个铺垫。在那之后，我的所有决定放进这个背景里看，希望能更说得通。关于 Total TypeScript，当时我是和一个叫 Joe Hooks 的人合作。
Joe Hooks 特别风趣，对我影响也极大。我和他合作到现在已经有四年了。Acad 就是他创办的，他帮 Kent C. Dodds 做过课程，是一个在幕后极其成功的课程创作者。我当时主动联系他，问他说：“你想做这门课吗？”他说：“太想了，我们就是从那儿开始的。”所以当时我一边在 Vsauce 上班，一边跟 Joe 合作，我们做了这次预发售。
就像我刚才说的，直接卖疯了。我意识到，好吧，我得全身心投入进去了。大概到了二零二三年一月、二零二三年二月左右，我们上线了完整课程，我记不清了，得去翻翻那个时候的图表。但它极其迅速的突破了七位数，这当然是我和 Joe 之间的收入分成，里面还有成本，但单看原始营收，简直让人极度兴奋。对，但七位数，那就是一百万美元，这可以说是很不可思议的里程碑，对吧？
真的疯了，彻底改变了生活。我意识到，原来我可以早上醒来，这笔钱依然能源源不断进账。这正是我以前当声乐老师时梦寐以求的事情。做出能在网上卖的内容，这是我奔着努力了很久的目标。一种高杠杆率的工作，我可以把事情做完，然后抽身回去陪家人。接下来的两三年里，我都扑在 TypeScript 上，扩充课程，卖几门补充课。
Total TypeScript 大体上就是这么个情况。过去这四年里，我最主要的一部分成功就是 Total TypeScript，以及把这套东西搭建起来。对，而且 Total TypeScript 一直很励志，尤其是你在总营收突破二百五十万美元的时候公开分享了这个大里程碑。我觉得对于很多软件工程师来说，当然我们知道这是分成前的数字，里面也有开销，但这明摆着比很多很棒的软件工程岗位赚钱潜力更高。
不见得是所有人，特别是看美国本土以及一些 AI 实验室之类的，那些可能算例外。但这说明这里面有市场能做成一门生意，而且我觉得这算是一种挺坦荡的模式。就像是你看，我做出了这个东西，大家想学就掏钱买，而且他们希望从中得到价值，不然就会申请退款，对吧？没错，我们给的退款期限非常长，我也不大想去收任何其他形式的钱。
我不太喜欢去做赞助内容，我也不能说绝不碰，但我真不太。我有个 GetUp 赞助页面，但我一直在想办法把它关掉。很长一段时间，我都想把它关了。我很喜欢这种定位，就是明确告诉大家这些是我卖的产品，你可以用这种方式来支持我，而且希望能带给你十倍的回报。毕竟这是个非常赚钱的行业，对吧？很多人手里都有能报销的培训预算，如果你想把一部分培训预算花在我身上，我的商业模式基本上就是这样。
这里面的很大一部分钱，很多买课的人花的都是员工培训预算，是各家公司过来给培训砸大钱，能推着我走向这个市场。意识到这一点，只有我在里面起了非常关键的作用。我以前对这个行业里到底飘着多少钱没什么概念，尤其是那个时候，老实说，现在也是。但短短两三年内就能这么快达到那个里程碑，我是说彻底改变了生活，听起来确实是个很棒的故事，甚至可以像童话一样收尾。
比如你这辈子就一直做教育内容，需求还极其旺盛，但后来AI出现了。大家都知道，它正在极大的改变我们的工作方式，改变我们寻找信息的方式。比如我自己，我都不怎么用谷歌搜东西了，我其实都在用AI agent或者深度研究功能这类东西。我听过一些教育从业者做线上教育的人说，他们的营收、市场份额还有心智份额全都在往下掉，因为既然直接找个bot就能解决，大家可能就不愿意耐着性子去听一门课或者上一整节课了。
你怎么看AI对整个行业、对人们的学习方式造成的冲击，以及对你的业务、对你作为一名老师的影响？这很复杂，因为AI改变了整个游戏规则，对吧？它改变了知识的重要性，尤其是哪类知识重要？我在讲课的时候会觉得内容分成两个层次，一方面显然是在教语法，教的是具体是什么，但背后还有一层为什么，对吧？要是不讲具体是什么，其实很难讲清楚背后的为什么，你懂我的意思吧？
所以这个载体就是我来教你这个语法，你也许就能体会到围绕它的一套智慧，对吧？我教你的是知识，但我同时也想教给你智慧。现在获取知识的成本非常低，对吧？非常非常低，你随手一查就行。我写了个 teach skill，就能带你学，教会你需要的知识。但智慧并没有变得更容易学到，对吧？它还是在那儿。要是你之前没掌握那份智慧，哪怕有了 AI，你该踩的坑还是一个都躲不掉。
至于我做 Total Typescript 的收入，显然掉下来了，因为我觉得大家对那些内容没那么感兴趣了。我觉得教那些内容的人日子会不太好过，因为知识本身已经不再难找了。我之所以能挺过来，倒也不一定叫挺过来，但我花了好久才想清楚自己在 AI 领域该待在什么位置，因为我又不是 Open AI
出身的调优人员，我其实没有那个资历来聊这些东西，特别是在 2020 年，我是 2023 年底才开始关注这个方向的。
刚开始我做的是怎么把 AI 放进应用里的课程，我当时想，好吧，我自己写了这么久前端应用。AI正在让那个领域发生一些改变，做这个合情合理。后来我越来越清楚地意识到自己押错注了，收益没达到我的预期。课程内容是不错，我也挺自豪的，但我不想再接着做那类东西了。到了去年十二月前后，很多人都会提到那个时间点。对，我们都知道，或者说大家常说的那次寒假，所有人回来都喊着AI killed。
对，就是那样Peter Break，对吧？就是Peter Break这个假期，没错。就是 OpenCL Break，当时 Open 4.5 刚出，大家放了长假，开始拼命猛用，然后猛然发现，哇，事情真的开始不一样了。我也遇到了同样的情况，我意识到现在的 AI 已经好到你可以放心把活儿委托给他了。你可以在 agent 外面搭架构，agent 可以去处理具体的知识语法，也就是我说的战术层面的东西。
而你可以去负责战略层面的东西，负责长远思考。我经常用这个思路。我知道你这档播客请过 John Osterhout，我自己也一直特别想跟他聊聊，他对我影响很大。他讲过战术性编程和战略性编程之间的区别。区别，在我看来，战术性编程大半已经被 AI 吃掉了，留给我们的就是把控战略。我意识到，在战略层，我是可以做出一门课来的。
我当时在看 Ralph Loops Jeffrey Huntley 那会儿在做很酷的东西，能让 agent 循环运行并盯牢目标。我就想，这里肯定有东西可做，我只需要找一个框架把它装进去，理顺怎么去摆弄它。我记得关于 Ralph Loops，你还发过一个视频，在 YouTube X 上都特别火。你大概是在说，瞧，我是这么打 Ralph Loop 的。
比如我手里有个任务很多的工程，你讲的特别棒。我们会在下面的节目简介里放上那个视频链接。你说我们以往让 A 阵干活的方式，通常是先提前定个计划，然后一步步执行，就是那种自顶向下的传统规划。而你说问题在于。在你执行的过程中，甚至在 agent 执行的过程中，他会意识到，等等，我得干更多的事。那这时候你怎么改计划呢？
接着你就引出了 Ralph Loop，介绍了你当时用的结构。当时大概是个 Markdown 文件，他把内容留在那里，一边消耗，一边不断往里补。这真的让我眼前一亮。心想，原来还能这么去思考怎么用 agent。我花了两三年琢磨怎么把 agent 放进应用里，那段经历在这儿帮了大忙。因为当你想做一个带 agent 的应用时，脑子里想的永远是数据流。
你会琢磨数据怎么流进来，格式是什么样，优先级怎么定，到底该放进系统提示词还是用户提示词？你工作的层级比平时用测试脚手架时要低得多，所以当我转去用那些测试脚手架时，感觉就是这套东西我太熟悉了。我无非就是要考虑状态存在哪儿，怎么把状态传给
agent，它该是什么样的数据结构，要怎么去压缩或者清空它。那时候，Cloud Code出来其实没多久，Cloud Code那会儿刚出了五六个月，用起来感觉顺理成章。
从那之后，我就开始抠这些东西。现在我们大概会叫它们Loop，但其实它们就是一套套流程，其实就是把各个Agent串起来的不同方式，就是。有点像那种流程图，对吧？要是你能从一个东西画箭头指到另一个东西，你就可以把它叫成循环，尤其是当它有一条回路连回来的时候，或者你也可以叫它工作流、流之类的，对吧？我会管它叫有限状态机，感觉有限状态机。
感觉跟我之前在 State 里做的东西特别像，它是基于流程的，基于状态的，有时也是基于事件的，也就是最底下的 Agent 会把一个事件反向调回到顶层，然后我就开始看到非常不错的效果，我会做一些实验。试着把自己的流程搭出来，我会给我手头在做的几个应用搭功能来拓展工作。比如我有个自己定制的视频编辑器，还有个挺大的代码库，另外还有几个开源项目，我就一直在搭这些小循环和小流水线。
有时候我干脆把它停掉，切回默认配置，我就发现区别特别大，就觉得哇，我在这儿搞的这套东西真是在给我铺路。我就开始琢磨能把这套东西分发出去的最好方式是什么？我怎么才能更好的把它分享给其他人？后来我就慢慢把 Skill 当成了这套东西的分发机制。这就是专门给 AI 机器人的测试脚手架用的 skill，通常在里面定义好，装上之后就可以用斜杠命令来调用了。
没错。所谓 skill，其实就是放在你电脑某个位置的一个 Markdown 文件文件夹 agent，既可以自己去调用它们，也就是模型调用的 skill。你也可以有一些 agent 本身并不知道，但你可以自己去调用的 skill，也就是用户调用的 skill。接着我就开始看到各种 skill 集到处冒出来，像 superpowers 之类的，还有你可以装的 cloud code 插件。
我觉得 G stack 也算一个。我意识到，也许我可以把我这套流程做成一组 skill 分发出去，看看大家觉得怎么样。起初我就直接传上去了，然后自己去忙别的事。我当时在做一门课，后来回头一看才发现，天哪，它的 star 数比我以前做过的任何东西都多。我甚至都没怎么宣传过，他就那么自己搁在那儿。我猜全靠口碑吧。
我就写了一点点文档，真的不多。结果他就已经彻底爆。于是我就想，行，也许我应该在这上面多花点心思，也许我应该去聊聊他们。然后我就去做了场演讲，好像就是咱们上次见面的地方，四月份的AI Engineer London，也就是AI工程师大会伦敦站。那场演讲的题目叫《软件基本功依然重要》，现在播放量大概已经到了一百二十万次左右。
我在里面提到了这个Skill级，这个Skill级现在的Star数已经到了二十三万。它现在是全球 star 数第二多的 skills 仓库，在历史所有仓库的 star 总榜里，大概能排到第二十到二十五名。哇，对吧？这到底是怎么回事？所以大家显然对这个需求非常大。这是我职业生涯里的第二次，就像当年我发那些 TypeScript 短视频的时候一样，我感觉到了哇，这里有股势头，有事情正在发生。
所以我觉得我必须在这上面加倍投入。那些 skill 你是怎么写的呢？这是在试图沉淀你的工作流，沉淀你对 agent 怎么用才管用的理解吗？不仅是眼下的理解，当然你还会考虑状态，考虑之前怎么把 AI 整合进应用里。虽然当时那套没有真正大火起来，但你学到了东西，所以这算是 Matt 的工作流，算是 Matt 亲测有效的一套做法吗？
对，就是这样。我首先在想的是，大家用这些 skill 的时候，肯定会去改动调试它们。那我怎么做出最简单的一套 skill，让大家能非常容易的看懂审查呢？我在想，怎样才能让更多的人在工作中把它用起来？比如说， grill me 这个 skill，它是最受欢迎的一个。我不知道你用过没有，不过我也在用。对，好，你看吧，他盘问起我来，真让人烦透了。
我当时就问了他一下，我就说我想暴露一个API端点，只要持有验证过的token，我这边做一些基础认证，能不能告诉对方这个邮箱是不是我邮件列表的订阅用户？因为我想把它和我正在办的一个活动连起来，给付费订阅用户优先权。这其实挺简单的，对吧？然后那个 Groomey 就开始不停盘问我，比如，好，那认证怎么做？
你是想要 bearer token 还是放在 JSON 里？放在 JSON 里可没那么安全，等等等等。我就想，行吧，这确实是个该做的决定。然后我们把这些决定全都过了一遍，他甚至问到了非常底层的细节，比如，好，频次限制怎么做？说到频次限制，你是想严格卡在一天一千次，多一次都不行吗？这样做复杂度会更高。
我才突然意识到，我已经很久没有跟一个团队或者工程团队做过这么深入的设计讨论了。通常只有对方拥有深厚领域知识时，才会有这种讨论。我一方面觉得烦，心想这本来挺简单的，别操心那个了；但另一方面又很惊叹，这个AI这个大模型竟然能通过一连串prompt把这些全做下来。其实每个人都有一段用 grow me 的经历。
我在各种大会上听到太多人说了，大家会说：“你看，你做了这么简单的一个 skill，它其实就是让 agent。”抓着这个话题不停地追问你，这是一个非常小的 skill，但它身上带有一种奇妙的涌现行为。模型会开始跳出固有思维去琢磨，然后开始抛出各种想法。我觉得我最初是从 Claude Code Tariq 那儿学来的，他的意思基本上是让 agents 来面试你，你就会看到更好的结果。
于是我把它写成了一个小 skill。后来我发现，哇，它比我用过的任何东西都要好上差不多十倍。那个 Grill Me 是第一个。他让我有点想起，在我第一份工作时跟那位穿凉鞋的大神讨论事情的情景。就是屋里有一位非常资深的工程师，逼着我深入反思自己做过的每一件事。这给我的感觉最像是在State和Andreas Rake一起工作时的体验，感觉就像一位水平极高的开发者在向我提出这些好问题。
我就想，哇，有意思。然后我就顺着这个思路去琢磨，怎么才能从这个 agent 身上挖出更多软件基本功层面的东西？怎么才能让它更像一个真正的开发者，一个真正的资深工程师？我该怎么去触碰那片合适的潜在空间，好让他的行为发生改变，以更有趣的方式向我发起挑战？因为只要你能做到这一点，只要你能提高你和 agent 之间的对话质量，你就能提高产出的质量。
我喜欢 GrooMe 这个 skill 的地方在于，它逼着我去拍板儿。只要我想一想，我就知道该怎么选。但拍板的人是我，所以它不像我输一个类似 slash go 的命令，说把这个做出来，然后他就跑去执行，把所有决定或者大部分关键决定都给做了。GrooMe 让我喜欢的是，不仅我自己能拍板。而且有时候他还会提醒我那些没怎么深思过的事儿，或者提醒我去查一查。
比如他问我想用哪种认证，是Bearer Token还是走Post，甚至走Get，我就想。等等，我得去查一下区别，或者开一个新窗口去问问清楚。这能让我变成一个更专业的工程师。而且我一直有这样一个信念：跟AI一起工作时，只要我们还在学，我觉得就没问题。只要我们停止学习，把学习全都外包给这个东西，那几个月或者几年后，可能就要出麻烦了。
百分之百赞同，这里有两点，对吧？我觉得所有人真的是所有人都低估了 agent 的一点，就是你和 agents 之间是存在沟通鸿沟的，对吧？中间是有一道屏障的。你会觉得，因为 agent 不是人，而且你自己心里清楚自己的价值排序，你就会以为 agent 也能自然领会到，对吧？总有这么一种感觉。觉得尽管相信模型就好，尤其是面对顶尖模型的时候，尽管相信模型。
但是不管 agent 有多好，模型有多聪明，哪怕是 Mathias，他也不会读心术，他不可能看穿你的心思。所以你必须得有一套流程，把你的价值观传达给 agent。因为很多时候，当你只是定个目标，心想随便给我刷出一段代码，生成点垃圾代码就行，agent 产出的东西就会和你完全脱节，因为他根本不懂你在意什么。
Gromy不光是关于实现细节，它也是在确立好做这个这个在范围之内，这个不在范围之内，这些是我认为重要的东西。这是Agent在了解你的过程。Matt刚才介绍了 Grill Me 这个 skill。当我用它来设计 API 端点时，他问的第一批问题就是：这个端点允许做什么，不准做什么，以及它被允许为谁做。
在我这里，我心里大概有数。但要是让 A 镇去林场发挥决定认证和授权，这往往是个极其糟糕的主意，而他们经常会这么干。那你还做了哪些 skill 呢？从那儿开始，我就在想，好吧，我该怎么把那段对话变成代码？我当时立刻就害怕了，因为我之前接触模型的时候，正好是在他们变好之前，在那个东西真正变得好用起来的十二月之前，所以我感受到了以前用过的那些东西带来的束缚。
比如我知道，你给 agent 喂的上下文越多，它的表现就越差。我知道你之前请 Dex Horvath 上过这档播客，Dex 对我的影响非常大，尤其是他提出的聪明区和笨拙区的概念。聪明区和笨拙区，对这个概念的意思，简单来说，免得大家还得去把那期节目从头听一遍。虽然大家确实该听听。其实就是你给 agent 上下文越多，每一个 token 都在大声争夺注意力。
你往那个屋子里塞的声音越多，就越难听清真正重要的声音。于是模型就开始丢掉事物之间的关联，并因此犯错。你可以把它看成是一个缓慢下滑的过程，但在上下文窗口里确实存在表现比较好和表现比较差的区域，所以就有了聪明区。在目前的顶尖模型里，我觉得大概是前十五万个token，在一百万token的窗口里，对，不管多大容量的token窗口都一样，不管多大容量的token窗口。
上下文窗口有多大都没关系，全看 token 的绝对数量，全看注意力关系的原始数量，剩下的部分就会慢慢退化的越来越厉害。于是我就开始想怎么把超过十五万 token 的工作，其实也不算很大，拆分到多个上下文窗口、多个会话里去。这花了我很多次尝试，用各种不同的方法反复折腾。Ralph loops就是其中的一个版本。
Ralph loops的设计初衷就是充分利用聪明区，因为他们本质上就是给Ralph loop一个目标，然后说做能让我们往那个目标推进一步的最小改动，然后清空你的上下文。然后清空上下文，从头开始。没错，严格来说你并不是从头开始，因为你手头有代码库，对吧？文件系统和环境里保存了一点状态，但本质上模型里没有。
这就是背后的思路。那我就开始琢磨怎么把 Routh Loop 这个想法拿过来，让它稍微更稳定一点，并把它做成 Skill 呢？我意识到自己需要两种不同类型的文档。你需要一份说明你要去往何方的文档，也就是目标文档。对我过去管它叫产品需求文档，也就是PRD。现在我叫它规格说明书，也就是那份写明什么时候算到终点的规格说明书。
然后你需要把这份规格说明书拆解成一个个任务工单，一次session一个工单。这样我就会有一个非常简单的 skill，先出规格说明书，再出工单。于是你把之前做的那次 grilling session 拿过来，变成一份规格说明书。现在这份规格说明书可以管，比方说三十到四十个工单，你可以有规模非常庞大的整块工作，全挂在这份规格说明书下面。
这就是核心思路。你先盘问深挖，把盘问结果变成一份规格说明书，然后对着那些工单跑某种实现循环，直到搞定一大块工作。盘问深挖之后，你还会获取用户输入吗？还是整个过程中都有？或者看情况？我当时主要是按完全离开键盘来设计的，就是用户人不用再，因为有一种说法叫白班和夜班，你听过这个吗？没没听过。这个想法特别好，大体上跟 agent 协作的最佳方式就是在白班做规划，到了夜班让 agent 干活，对吧？
这样，但愿你早上醒来就能看到写的清爽漂亮的代码。我当时就是想围绕这个来优化流程，因为我真的很烦那种在终端之间切来切去、上下文不停切换的状态。我到现在多多少少还在这么干，就是整天噼里啪啦切个不停。我想要的也一直在努力优化的是，踏踏实实做完一大块规划，然后让 agent 跑上两三个小时，我好去干别的工作，能有成块的时间，比如专注干一件事十五分钟，做做规划，然后再来审查代码，做这些事。
我做 Ralph loops 一直在优化的就是这个，而我十二月发现的一大收获就是，这帮家伙已经足够好，完全可以把事情交出去了，我可以人离开键盘直接跑。你还有另一个 skill，野心更大一点，叫 wayfinder skill。我们能聊聊那个吗？当然可以。就像我注意到具体实现需要拆到多次 session 一样，有时候你在盘问、深挖某样东西，就会碰上限。
你打算深挖一个东西，比如帮我做一个 Stripe 的克隆版之类的，对吧？你肯定会撞上限的，你绝不可能在十五万 token 里把它全规划完。所以我就想，我该怎么把它拆开，好让盘问深挖 session 可以无限长下去呢？我怎么拆分深挖过程，才能让它像这样运转？于是我就想出了这个点子。我还是在琢磨信息流，本质上它需要什么才能在深挖 session 里表现良好？
它大概需要完全搞清楚这次深挖 session 的目的是什么，但它也需要知道到目前为止都决定了什么，还需要知道眼下可能还在并行哪些其他的深挖 session。我就想出了地图这个概念。地图会是你做出的所有决策所需一切信息的核心集节点。一旦你有了地图，你就会意识到，在摸索通往目的地的路上，我知道有些事情是必须定下来的。
地图上有些点就像里程碑一样，而且还有战争迷雾。这个绝妙的比喻就这么带着我，把这个 skill 的其余部分设计完了，对吧？因为你有了地图，有了战争迷雾，隐约知道自己要去哪。每进行一次拷问环节，地图上就会解锁更多地点，你也就差不多摸清了方向。这就有点像一个有向无环图，你顺着它一直往下走，直到抵达最终目的地。
所以你有了地图，里面每个单独的环节就是地图上的一张张工单。然后我意识到，拷问环节是不错，但如果你需要做原型怎么办？如果你需要做调研怎么办？如果你需要做某个随手的工作，比如配置点基础设施之类的，又该怎么办？这些其实就是地图上不同类型的工单。Are we find 的基本上就是在整个过程中引导你。我的某些地图上有过五十张、一百张工单之类的，直到我最后抵达目的地。
我其实还一直用它来规划课程，也就是非技术类的事情，效果特别好。我还用它在自家花园里搭了个花园办公室，对吧？很多这类技能，我们往往会觉得这适合工程，但随后你就会意识到，工程也不过就是一门专业，我们到底在干什么？我们其实只是在讨论某些事情，在现实生活中做做事，比如在网站上点来点去之类的，你就会发现它能多么轻易的对应到其他领域。
所以这算是，也许我们稍后可以聊聊这个。也就是我正在思考这些东西迁移到不同学科、不同生活领域里的可能性有多大。所以，we find一直很好用。对，但如果我们想想工程和软件工程很有意思的一点，Pielowin来上播客时，他采访过一些工程师，也就是他认为的真正的工程师：化学工程师、机械工程师、土木工程师，想弄明白软件工程到底算不算真正的工程。
最后，他发现可能确实算，但他提到软件工程里有一点很有意思，和其他所有工程专业都截然不同，那就是我们打交道的材料，在其他任何一个领域，机械工程、土木工程，甚至化学工程，你的材料都有一个耐受极限，你无法完全确切的知道它具体怎样，你只知道它大概能承受这么大的载荷等等。但在软件里，材料本身就是软件，它就是像程序一样运行。
抛开非确定性不谈，虽说非确定性可能更接近传统的工程概念，但软件一段代码，你运行一千次，它一千次做的事情都是一样的，而其他领域做不到这样。他说他看到了很大的区别，不过现在有了大语言模型，我们可能也会遇到这种情况。你运行它一千次，它就会出现大部分工程领域都有的那种方差。所以谁知道呢？说不定在大模型上有用的做法，也能用到本身就存在这种方差的其他工程领域。
或者我们可以从其他工程专业借鉴一些方法，用来跟AI这种材料打交道，效果也许会不错。我完全同意。我觉得软件工程有意思的地方，以及 agent 善长处理它的原因，在于它的所有输入和所有输出全都是基于文本的，全部都是输入是代码、文档给 agent 操作指令，全都是文本，而输出是更多的代码、测试套件、类型检查结果、代码检查，所有这些东西也都是文本。
agent 真正感到吃力的是任何非文本的东西。你看过那些令人惊艳的演示？有人第一次尝试就一枪生成了完美的 UI。可是，要是那个 UI 里出现交互问题呢？要是你鼠标悬停在某个东西上，动画看着不对劲呢？你打算怎么把这些传给 Agent？我想你可以录一段视频，让它停在某些帧上。假设是这样，但它目前的视觉能力其实还没那么强。
所以，任何非文本的东西，agent给出的都跟垃圾一样，它根本处理不了。所以，我觉得在那些专业里，如果你能把它转成，我猜他们会做仿真，对吧？我猜他们会做某种，我不知道有没有能检查建筑图纸的代码检查工具，我相信肯定有类似的变体，对吧？某种仿真，如果你能把它变成文本形式。如果你能把你日常生活中的交互变成文本，其实大部分本来也就是文本，那么 agent 就会完成的相当出色。
这也是我目前正在尝试做的事儿，就是把我使用的所有服务都接入 agent，对吧？让 agent 能够调用它们。不过，确实，我们越能把工作变得对 agent 友好，拿到的结果就会越好。再转回到整个 AI 以及它到底改变了什么？它确实改变了非常多东西，但大家聊到 AI 时常提的一点，尤其是研究人员和 AI 公司里的人常说的，就是无先验知识。
面对 AI，你应该丢掉过去所知道的一切，因为这东西完全不同，从零开始。过去的那些方法可能行不通，甚至干脆假设他们行不通。重新去想新办法。你在AI出现前就是开发者了，而且你一直很热衷于做出高质量、优秀的软件。你觉得AI到底改变了多少东西？包括那些基本功吗？这事儿我以前也这么想过，我想着没错，I改变了一切，我是不是要把婴儿和洗澡水一起倒掉，对吧？
我觉得我们得用全新的眼光去看待一切。我开始大量这么尝试。我当时尤其关注规格驱动开发，我对它其实算是有好有坏。我觉得这是个很奇怪的词，它涵盖的东西太多了。我想，好吧，也许英语真的是最火的新编程语言了，对吧？就是有人在网上发了之后爆火的那个说法。一点没错，我想着，也许我只要写一份规格说明，这份规格说明就能一直保留，我可以随时修改它，让 agent 边做边改。
但随着我深入实验，我试了很多次，出来的结果比我自己手写代码还要差，而且一点都没有变好。我发现每次我按这种循环来跑，也就是改规格、看代码变化，代码就会变得更烂。按说人是不该去看代码的，但我看了一眼，简直就是垃圾。我就想，agent在这种环境下怎么可能表现得好？它怎么可能跑得通？因为。反馈回路对 agent 来说太关键了。
如果你的测试套件很烂，agent 从中得到的信号就会很烂，跟人是一模一样的。我就想该怎么改进测试套件，怎么才能把这套东西搭好，不至于每次都吐出一堆垃圾。然后我就翻开书架上的一本书，我第一次把它抽出来的时候。塑料膜好像都还没拆，就是《程序员修炼之道》，所有人都劝我读，所有人都在说，对，这是有史以来最好的一本书，你一定要读，我就买了，但出于某种原因一直没看。
我翻开它，里面有一整章、一整节都在讲软件熵增。所谓软件熵增，熵的意思就是事物总是倾向于走向更混乱的状态，这比走向有序的状态概率高得多。我意识到软件熵增是不可避免的，而我在这里看到的是 agent 制造软件熵增的速度比以往任何时候都要快。我开始更深入地看那本书，几乎读到的每一行，我都觉得天哪，这简直就是为今天写的。
对吧？真该回去重温那本书里面的观点，比如车速不要超过车灯照射范围，永远在反馈回路内工作，巧合编程，示踪胆开发有太多聪明的点子了。我意识到这本书已经出版二十五年了，对吧？这些很可能早就存在于 agent 的先验知识里了。也许我只要提一下其中的某些概念，尤其是那些非常精炼的词，比如“失踪弹开发”，也就是你手头的活儿一定要能很快得到反馈。
我猜“失踪弹”的概念就是，就像留下一道痕迹的失踪球那样。你先跑通一条能用的路径，比如软件里很重要的一个功能，而不是先建数据库层，再建应用层，再建不知什么层，不是把三层全建完再拼起来，而是每一层只建一部分，但它们能连通工作。这正是我在 agent 身上看到的问题。你让他去写一个软件，哪怕用上
Ralph loops，他也会先把整个数据库全建好，再在上面把整个应用层全写好，然后再把整个 React 组件库全写完，直到最后他才开始把各部分拼在一起，才开始对自己在做的事情获得反馈。
这让人抓狂，因为数据库里的东西是会影响你在前端展示的内容的。只有当真正看到它穿透这些集成层时，你才知道这东西到底合不合理。另一个概念就是垂直切片，对吧？不是在这些不同的可部署单元上做水平切片，而是做一个垂直切片。让他能立刻对自己在做的事拿到反馈，然后再往外扩建。于是我在跟 agent 对话时，开始在 prompt 里用这些短语，然后我开始注意到他也会用这些短语来回复我。
他开始把这些词回敬给我，他会说：“好的，我来把这个做成视宗谈开发。既然这是视宗谈开发，那我就这么做。”他在自己的推理链里用上了我说过的那些词。所以，我把这叫做引导演算词，或者说主导动机，算是个挺高大上的文学词汇。也就是你在 skill 或者 prompt 里重复几次某个简单的短语，来引导 agent，以此改变它的行为。
示踪弹开发就是一个极好的例子。于是我开始翻各种书，把能找到的书全翻了一遍，想从中挖掘出引导演算词。另一个例子是 John Ousterhout 的软件设计哲学，我从里面学到了很多好东西，比如深度模块，这个对我启发特别大。想想看，挺有意思的。这些 agent 显然是在那些书上训练过的，那些书现在还在印。
当然，关于他们拿这些书做了什么之类的，一直有争议。但如果这些内容在他们的训练数据里，agent在训练过程中把这些不同概念串联了起来，那么这些所谓的引导演算词就能唤醒那些概念。我好奇这跟现实中聊某个话题有多大区别？你作为一个外行跟专业人士沟通，努力描述自己想要什么，专业人士说了一个恰当的词，另一个同行立刻就懂了。
其实这就是行话，对吧？一方面，行话在刚加入一家公司的时候让人觉得不太友好，但我们之所以用它，是因为它能让事情变快、变简单，减少误解。确实，这个想法引导我去思考另一件事，因为显然这些引导演算词本来就在 agent 的先验知识里，对吧？像示踪弹开发那些东西，那怎么描述我的应用呢？怎么描述我的代码？我该怎么让 agent？
因为说实话，agent 实在太啰嗦了，对吧？尤其是 Opus 五，不知为什么大家总喷那个模型太啰嗦，而且它确实是，我就想怎么才能让它少说点废话？我和 Agent 之间怎么才能开始用一种共同语言交流，消除这种沟通障碍？这就让我找到了滴滴，也就是领域驱动设计。Eric Evans 那本极棒的书里讲到了通用语言，这种语言也是深深扎根在 Agent 的先验知识里，他理解的特别透。
我开始琢磨着能不能把 Grill me 稍微改一下，因为 Grill me 是个非常简单的 skill。但如果我们构思的时候琢磨要做的应用的时候，顺便也建立一套领域语言呢？如果我们顺便敲定该用哪些术语呢？于是这就变成了一个叫 Grill with Dogs 的 skill，名字起得很烂，但它本质上就是在推进的过程中边走边建这套领域语言。
一旦你让 agent 用上这套领域语言，效果简直判若云泥。因为突然之间，你们在说同一种语言了，你能用少得多的字句描述你想改动的东西。比如我手头在做的这个应用里面有一种很复杂的交互，有草稿课和正式课。当你把某个草稿单元、某个草稿课程里的某节草稿课变成正式课时，意味着那个草稿单元也得转成正式，草稿课程也得转成正式。
这要怎么解释？其实这就是级联实例化，对吧？这些术语是你琢磨出来的，对，跟 agent 一起想出来的，对吧？agent 其实非常擅长提炼这些术语，所以我做了一个领域建模的 skill。我们说是行话，但本质上是领域语言。如果你能把它融进去，不仅融进你聊这个应用的方式里，还融进应用的代码本身，那事情就成了，对吧？
这让人非常兴奋，而且它意味着 agent 在你的代码库里穿梭会容易得多。它能找到提到那个特定领域术语的函数，只要一个简单的 graph 就行，简直太棒了。所以我一直在把自己所有工作流的方方面面都跟滴滴深度结合。但这太有意思了，因为为了让这些 agent 效率更高，或者为了让工作流能写出更好、更少出错的软件，你开始往回倒腾，翻出这本现在恐怕有二十三、十四十年历史的书。
你甚至还在往前翻，去找那些宝藏。我相信你早晚会翻到人月神话。对我手头已经有了，那是必须的。那本书距今都五十多年了，你还在试图找到合适的词来描述事物，这特别耐人寻味。因为我和 Ken Beck 聊起当年他和 Ward Cunningham 怎么结对编程时。他们刚提出领域设计模式这个概念那会儿，手头甚至放着一本同义词词典，在桌上翻来翻去，就为了找到那个词义完全贴合的词义。
现在感觉我们又回到了基本功，回到了大家一直在琢磨的那些门道上，时不时就有人把它写进书里，当成智慧流传下来。而现在我们又回到了原点，也就是你现在想传授的核心智慧。很神奇，对吧？因为AI跟人太不一样了，你必须去适配它。想象一下，你面对的其实是一个每天早上醒来都不记得自己是谁的人，对吧？就像记忆碎片里的那个主角，你懂吧？
这就是记忆碎片驱动开发，对吧？我们是在努力为新人优化代码库，所以我们正努力做出有史以来最健康的代码库，因为如果你。人面对一个很烂的代码库，还能绕过去，他们慢慢就形成了记忆。他们就是一次又一次不停的去碰壁，直到摸索出来。但 agent 做不到这一点，他每一次绘画都是从零开始，所以你得为这么一个人去优化你的代码库，这会引你走上一些很有意思的方向。
而且事实证明，软件基本功一直都在强调，我们其实从头到尾都在努力做这件事，对吧？我算是彻底被 Eric Evans 这一套给洗脑了。我算是彻底迷上了软件基本功。我们多少有点在改写规则，但也可能只是在重新强调一些我们明知该做却可能没去做的规则。我觉得这非常有意思，而且肯定好玩得多。好，顺着这个思路，我我觉得很容易理解为什么基本功很重要。
但具体是哪些基本功呢？如果我是一名工程师，尤其是可能一直埋头写代码、做更偏战术性编程的人，我该怎么去找到那些真正重要的基本功？回过头来看，你发现哪些东西是管用的？这是个非常难的问题，对吧？这真的很难，因为战略性编程一直都特别难学，原因就在于它的反馈周期非常长。你经常会发现，有些人在六个月后离职了，他们的战略性错误就永远找不上他们，对吧？
可能那个战略性错误要过九个月才会反噬到你身上。我觉得学习战略性编程有点像你面前摆着一个巨大的调音台，上面有好多不同的滑块。可能其中一个滑块就是你拥有的可部署单元数量，你把它推上去，微服务就变多了，对吧？你把它拉下来，就变成单体架构了。你怎么做这个决定？那个滑块该停在哪个位置？对，因为这有点像你在做母带处理，你在给音乐做混音，但你得等九个月后才能听出哪里出了问题，对吧？
直到那些错误找上门来。所以我觉得，唯一能让这个反馈周期变快的，就是跑得更快。AI现在能让你跑得更快，对吧？你的战略性错误也会更快反噬到你身上，他们会更快找上门，因为AI产出代码的能力太强了。所以你需要去思考的是，你的代码就是agent运行的环境，你应该时刻想着去改善那个环境，去想怎么把它做得更好。显然，这需要一些战术层面的知识，对吧？
你得搞懂代码是什么，代码之间怎么拼接，内存限制是什么，等等这些东西。但要想在战略性编程上做得更好，你就得时刻站在那个层面去思考。而且，我觉得还要去读这些书，因为只要具备了解释这些概念的语言，理解运用战略性技术和不运用的区别，这才是胜负的关键。在 AI
出现之前，对于资深开发者、资深工程师或者主任工程师来说，你通常见不到工作经验不足五年的资深工程师，因为即使在快节奏的环境里，你也通常需要那么长的时间去获得反馈闭环，去犯错误，犯属于你自己的错误。
而等到大家做到主任工程师的时候，往往都差不多有十年以上的经验了。有些人可能早一些，但他们身上通常都带着一身伤痕。有人启动一个新项目，他们过去稍微调整一下，别人都看不懂为什么要调，他们就会说：“信我，没错，我们这是在避免线上事故，或者避免值班被叫醒之类的惨剧。”但所有这些全都是切身经历出来的。现在AI把节奏加快了，它也让改错变得更容易。
所以我在想，这可能会带来什么变化？一方面，我能看到它确实可以加速经验的积累。比如，一年之内，有些人和团队交付的项目会比他们过去四年交付的还要多，或者大致相当于过去三四年的量。所以你能积累多得多的经验。但我也在想。有时你犯的错误是不是就没那么严重了，因为你很快就能修好。现在我怀疑这种学习效果会不会没那么深刻，因为话说回来，有些战痕、有些惨痛经历就是一次非常严重的宕机事故。
我们因为没有加密等价而亏了一大笔钱，然后到了现在，你自然就懂得什么是密等性了。这不是个容易的概念，但要是你吃过它的亏，它就变得很重要。诸如此类，如果你现在是一家公司，想培养下一代初级开发者，既然这种战略性编程知识现在这么有价值，能发挥出高得多的杠杆率，你真的会去雇一个完全不懂这些的人吗？你为什么要这么做？
前几天我采访了 Uncle Bob，他的建议是：行吧，你就招个人，先把他当成 agent 用一阵子。你就只管给他派任务，让他先保持那种战术性的思维方式，直到他的错误开始找上门来。但这太浪费钱了，对吧？在很多国家，软件工程里那些战术性的活儿，成本都已经跌破最低工资了。所以答案是，我也不知道。我只知道战略层面的东西，对代码的理解，对长远全局的把握，比以往任何时候都更有价值，对吧？
因为你能从中撬动太大的杠杆了。我向大家征集了想问你的有趣问题，这正好跟这个很相关。有人问，怎么向非工程团队的利益相关方证明投资软件基本功很重要？哪怕表面上看可能会降低速度和产出。我觉得这里的问题在于，如果有人主张说，你看，我们确实想打好基本功，这意味着我们得放慢一点，仔细推敲决策，可能还要提升自己的认知，而不是只顾着埋头出活。
十年前，你也可以问同样的问题，对吧？而且那会儿问也同样成立，你懂我意思吧？就像，只是换成具体的软件概念，我们以前会问要不要还技术债。没错，其实是一回事，对吧？我们一直在聊同一种事，这让我觉得挺有意思。因为你需要某种指标来弄清楚这件事，而现在要弄清楚会稍微容易一点，因为 agent 能让你跑得更快。而第一步就是在你的组织里，对每一个 agent 建立可观测性，看他在做什么，成功率和失败率是多少。
以前我们从来不可能对开发者这么做，对开发者来说这有点太冒犯了。对，但对 agent 来说就应该这样，没问题。没问题，对吧？我们付了服务费，对吧？我们需要了解自己优化的效果到底怎么样。第一步其实是给你的 agent 搞一套测试脚手架或者可观测性体系，覆盖整个组织，弄清楚哪些奏效，哪些不奏效。而且，你可能需要找个人，他的全职或部分工作就是看这些数据，弄清楚我们在做什么。
可能你们组织里的某些代码仓库成功率比其他的更高，那就可以把里面的经验提炼出来，分享给大家。我还觉得，大多数组织都需要围绕一套通用的skill凝聚起来。你需要一套通用的软件工作流，让大家都能贡献回馈，这样你才能做实验、做 A/B 测试。可以让一个团队做一套东西，另一个团队做另一套，事后再去问他们。在任何组织里用 agent 的人都需要这种实验思维。
你得去想花掉的这些 token 怎么才能压榨出更多价值。可观测性就是第一步。对，我也在想有没有人在回路中的反馈。我的意思是，直接找同事聊聊。我们设立例会、团队会、全员会是有原因的，可以在那儿分享我用什么有用，什么没用，学到了什么。毕竟定规则、决定怎么用，在哪儿用，在哪儿不用，全是我们说了算。还有哪些地方我们要说不行？
这得百分之百由人类来做，甚至根本不让 AI 介入。这在每家公司又会各不相同。不仅如此，很多事情现在根本不需要人在回路中了，对吧？为了建一个更好的代码库，你其实不用花那么多时间。我有几个循环，基本上每天早上都会运行我改进代码库架构的skill，给我提个建议，告诉我代码库里有什么可以改进的地方，然后我点个按钮就行。
我说好，把这个转成工单，然后上线吧。这做起来挺容易的，也很容易跟其他工作并行串起来。所以我不知道你需不需要把百分之二十的时间用来关注生产软件的这套工厂，而不单是软件本身，因为我觉得那是对未来杠杆率一笔巨大的、惊人的投资，不仅能放大你工作的杠杆，还能放大你团队的杠杆，让大家更懂、更擅长那些技能。但当然，你需要拿结果说话，你可能得先把这部分工作藏一阵子，然后再拿出来给大家看。
这就是我们一直在做的事。这取决于你的工作环境，不过确实是这样。你要是回过头来说，顺便说一句，各位，我还把这个做好了，没人会冲你生气的。对，没错。我想问问你具体都是怎么用工具的？第一个是用在本地还是云端的编程 agent？你最近发了一条挺有争议的推文，用你的话说就是我正在放弃我的本地开发环境，现在本地对我来说完全讲不通了。
很多人问我怎么让你的 skill 支持协作，你怎么做多人的盘问会话？答案就是光靠你和你的终端是不够的，对吧？我们现在处于一个阶段，每个开发者手头好像都有一百个终端可以用，这看起来太离谱了。感觉应该把这一百个终端提供给你的整个团队用，大家得能在一个共享空间里协作。你得能去叫个人，把某人艾特进你的盘问会话里，跟他说好了，来做这个。
那对我来说，把这些交互直接放在大家平时工作的地方就很有意义，比如 Slack、Discord、Teams 或者 Linear。这其实就是推动我去摸索这个方向的动力。我自己倒不怎么跟团队一起干活，但我明白那样的价值，所以一直在试着把这套东西融入自己的工作流。所以在坐火车过来的路上，我是在 Discord 里跟我的 Hatsune 机器聊天，给我的课程写点东西，或者修修学员碰到的 bug。
那我能看出来，只在本地弄东西现在价值没那么大了。既然我有这么一套配置，可以做端口转发，看着开发服务器在发生变更，我觉得这比弄一台非常非常贵的笔记本电脑来做这些事儿合理的多。那感觉就像是在浪费算力，尤其是因为在那台远程机器上，我能设置定时任务。我知道那台机器是一直开着的，我会跟自己的 agent 开个类似晨会的东西，让他替我安排好一天的日程，他也能看懂我所有的 Discord 的聊天记录之类的。
对，把这些放到远程，感觉对我来说合理太多了。我现在在本地唯一干的事儿就是调试远程机器人的问题。对，我在想是不是有一个把一些挺复杂的本地环境复制到云端有多容易的问题？可一旦行得通了，大概就只是早晚的事儿，而不是能不能成的问题。对，而且要说的话，大家在本地环境上其实也碰到了类似的问题，对吧？上千个
Git 工作树就那么堆在硬盘里，而且一个工作树就得跑差不多五个 Docker 容器才能把本地开发环境搭起来，这要怎么办？
那在云端往往会容易一点，因为你可以按需调配需要的资源。顺便说一句，我们看到像 Ramstripe、Uber 这类公司，他们有平台团队，能把本地开发者的完整环境搬到云端的一台云主机上。现在你只要在 Slack 里艾特一下，或者通过网页就能调用。他们看到大家用这些 Agent 的频率高得多。除了前端工作以外，前端你还是希望有那种反馈闭环。
确实有少数几种情况，你非常需要那种本地开发环境来保证低延迟之类的。但他们也看到，有百分之七十、百分之八十的开发者都是自愿转向云端的。我觉得只要打通隧道就行了。要是那边跑着开发服务器，你直接在本地机器上显示出来，这跟放在本地有什么区别呢？对吧？我不知道，我没试过这个。但之前我聊到这个话题，说可能前端是个不错的例外时，别人当场就是这么反驳我的。
我觉得听起来有道理。我想问问你关于规划和需求方面的事。你非常认可 grill me 和做规划，提前做规划或者先拿到方案再让 agent 去干活。但这里有另一种反向的观点，agent 实现起来太快了。你其实可以让几个 agent 去实现不同的架构，那种既然他们实现起来很快，那我可能就不需要做那么多前期规划的想法。
你怎么看？边做边调整方向就行了。这取决于你在做什么样的工作，对吧？因为我觉得你不该什么事都用 grill me。本质上，你需要用 grill me 的是一些实际要做的事情，规模相当大，而且很难往回退导的工作。如果你觉得这个功能可能是一个全新的页面，可能是一个大功能，这段代码要是 agent 写错了，那错误的代码就会留在它的上下文窗口里，影响之后的所有东西。
事后再倒回去改那些东西做对齐成本会很高，而针对那些情况先对齐，先把所有棘手的问题回答清楚，比如你的 JSON cookie 之类的，你的认证 token，然后再动手就说得通。但对于某些情况，比如修个简单 bug，或者把这个按钮往左挪三个像素，显然在做之前是不需要先对齐的。你能看到东西，要是只有五行代码的改动之类的，你事后再对齐也行。
这就是我的看法，只要能做到，就应该尽量往后移。其实我视频剪辑软件里就有个小按钮，能直接往里面发反馈。我经常拿它来处理非常简单的任务。我一把反馈发出去，它就变成一个 GitHub issue，马上就会有负责实现的 agent 接过去，立刻开始弄。然后会有个代码审查 agent 进来审代码，最后我就能看到这东西确实被修好了。
到时候我再去做对齐。对于那些很容易写清要求、不需要我去反复盘问的事情，这种做法效果非常好。你有的选择就是这些。这事是不是小到我可以事后再对齐？那就别用 grill me。一次会话能不能搞定？那就用 grill me。他跨了多次对话吗？我需要对整件事对齐方向，那就用 way finder。有意思，因为这跟很多科技公司多年前的做法其实差不多，也就是写 P R D 产品需求文档。
要是很微小的事情，直接动手做就是了；要是需要整个团队介入，属于团队层面的范围，那就写个 P R D 发给团队，可能再抄送几个其他团队，但它不会卡住进度。如果事情更大，那就得先卡住，比如我们得等反馈回来。大体上，我们以前常说的是，如果是个一个月的项目，花个两天，花个一两天做规划不算坏事儿，因为后面能省时间。
但如果是个一天的项目，就别费这劲儿了。如果是个一年的项目，我们到底在干什么？应该把它拆得更小才对。太对了，而且我想说，你这么一说的时候，我能听到房间外面有一点批评的声音，那就是我们这么搞听起来难道不像瀑布模型吗？每当我在聊 Wayfind 或者在写任何规格说明书的时候，在走到那一步之前，我其实会做大量非常激进的前期原型开发。
这种质疑反复出现，就是说这不就是瀑布模型吗？我们这是在干嘛？梦回七十年代吗？但 agent 给了你一种直接批量倒垃圾代码的能力，对吧？有时候你可以把这点化为自己的优势，因为做原型嘛，就是为了摸清楚它大概长什么样。你可以直接搭出三到四个不同版本，选你最喜欢的一个去迭代，一直不断的出，不断的出。这套打法可以非常强大，我们以前可没有这种条件，对吧？
以前做原型的成本向来很高，现在是史无前例的便宜。对我来说，写规格说明书非常核心的一部分，就是去把这些原型做出来。对，不过说到对瀑布模型的批评，我想Grady
Booch可能也跟我讲过这个，就是说别忘了，我们其实不该去批评瀑布模型，因为很多大厂最大的几家科技公司，从亚马逊、微软、谷歌到Meta之类的，他们其实一直在做微型瀑布模型，在AI出来之前，他们就一直在跑微型的瀑布模型，也就是先定计划，达成一致，动手做。
最后发布上线，而这些全都在两周、一个月、两个月或三个月里搞定。三个月就已经算极端的了。但 Grady Booch 当时说，瀑布模型的问题从来不在于这个。瀑布模型的问题在于，做规划真的能做上差不多一年，整整一年，然后实现又要花三年。等四年后，他终于做出来了，根本不是我们想要的东西。问题出在这里。他说，问题根本不在于用瀑布模型去做个一两个月的项目或者一周的项目，问题向来在于动不动就按年来算。
而且他说，整个行业已经有几十年没见过真正的瀑布模型了，所以我们现在用这个词，有点像是在批评他或者批评微型瀑布模型。其实那不一定就是坏事儿，你懂我意思吧？就像我们在立个稻草人自己打一样。是的，它成了一个早就已经不存在的皮纳塔。它可能还存在于某些我们谁都不知道的受监管行业的疯狂大型企业项目里，但我觉得，哪怕在那里，它八成也已经过时了。
对我觉得，就算我们打的是个皮纳塔，把它挂在那儿，其实也挺管用的。它就像是一个有用的幽灵，或者一个有用的前车之鉴，对吧？因为哪一种模式更契合 agent 的打法，肯定是敏捷开发，对吧？因为人工成本降了这么多，我们随时可以极快的去改代码。不知道，我觉得这个比喻挺贴切的，所以我倒不介意去踩一踩瀑布模型，哪怕根本没人再用它了。
那还有另外一样刚好过时的东西，我们倒没有讨厌它，那就是测试驱动开发，也就是 TDD。你觉得把它们用在 agent 这类事情上怎么样？我之前跟 Ken Beck 聊的时候，我们聊到过，这在很多方面可能都非常合适，但我还是没怎么看到有人真正这么用。我看到大家在写测试 agent 也是事后补测试，大多数人都是这么干的。
但我记得你一直挺提倡 TDD，也就是测试驱动开发，对吧？对我确实有一个推荐大家用的 TDD skill，而且这聊的挺巧的，因为我最近一直在琢磨这事儿，只是还没怎么发出来。TDD 针对的是工作记忆非常小的情况来做优化的，对吧？你先写一个测试，这个测试理应通不过，这意味着就算你分心了，去喝了杯咖啡或者去散了个长步，等你回来的时候，测试依然挂着，提醒你刚才实现到哪一步了，并引导你去做下一件事。
Agent 不需要这个。A镇厉害的地方就在于他们的工作记忆比人类大得多，对吧？他们脑子里能同时记下的东西，目前其实比人类多得多，这非常有用。但他们并没有无限的工作记忆，而且我觉得 TDD 有点解决错问题了。但 Agent 真正需要的是反馈回路，所以他们需要看到自己在做什么，以及这跟代码环境是怎么交互的。
他们需要时刻去探测试验。如果让 agent 先把失败的测试写出来，agent 也很难在上面作弊。这样一来，你不仅是在迫使 agent 建立自己的反馈回路，agent 也在一边做一边向你证明这东西确实管用。所以，哪怕我没有直接用 TDD
那套先写失败测试，再修复，再重构的流程，我也经常会对他说：“证明你的改动确实做到了声称要做到的事，给我拿出符合 TDD 精神的证据，证明要是没有这处改动，它就通不过，对吧？
”这在改善反馈回路上效果非常好。因为关于 TDD agent 容易搞砸的另一件事是，他们经常会写出一堆烂测试。他们经常会写出同一反复测试，也就是测试只是在断言实现细节本身，完全就像是把实现代码抄了一遍。比如他定义了一个常量，然后测试就写期望这个常量等于这个值，这测试有什么意义呢？只是在断言实现本身而已。
所以对 TDD，我的心态挺复杂的。我依然推荐它，仅仅是因为站在人的角度，它能让你对自己写出来的东西更有信心。不过，我也开始看到反对意见了。我们来聊聊技术债吧。Y Combinator的Jared Friedman发过一条推文，我用他的话说，过去当代码库足够大的时候，技术债是你不得不忍受的东西，现在不再是了。
然后你回复说是的，现在哪怕在极小的代码库里，你也能忍受它了。这句念出来确实挺有意思的，你把那种讽刺的味道念出来了。对，agent实在太容易产出垃圾了，对吧？哪怕是非常聪明、非常强大的agent，因为他们无法做战略性思考，只盯着眼下在做的事，他们极容易产出技术债。那什么是技术债呢？对吧？技术债就是任何随着时间推移让代码库变得更难修改的东西。
好的代码库是那种容易修改的，在里面做改动不容易引发连环崩溃，对吧？所以，一个有着扎实测试覆盖率和优秀测试套件的代码库，就是一个容易修改的代码库。但 Agent
极容易随着时间推移，让代码库变得越来越差。这是个非常棘手的问题，你需要有战略思维去考虑它。因为我发现有一点非常管用，那就是自动化审查。你让一个实现 agent 去做具体的事，然后让另一个自动化的审查 agent 去推行你的编码规范，找出这些同意反复测试，随着时间推移去提高测试套件的质量。
但你怎么知道这个自动化审查 agent 做的好不好呢？所以在极小的代码库里，哪怕只改一行代码，agent 也可能产出垃圾，对吧？所以我觉得这就是我们不得不忍受并且需要持续与之抗争的东西，也不是什么坏事。当你理解好代码长什么样，能认出什么是技术债时，我们能带来很大的价值，而且这也是我们一直都有的问题。
你懂我意思吧？就像。它并没有消失，没消失，我感觉就是这样。我们只是在重复过去二十年一直在聊的话题，只是屋里多了一头显眼的新大象。我想问问你，住在英国和搞AI的事儿，这也是一位读者提的问题。你现在常住英国，在伦敦以外，但你现在在做AI方面的教学，离硅谷和那些实验室的总部更远，对你来说是变容易了还是更难了？
我其实就是在各走各的路。我挺早就意识到自己根本没能力预测未来，对吧？因为我离那些核心圈子太远了。我只是身处一线，在用这些东西的人，我没办法知道未来会发生什么，对吧？我不知道模型会不会变强，我没有内部特权渠道，所以我只专注于眼下行得通的东西。正因如此，我觉得这反而帮我收拢了一点关注范围。这意味着我可以只管把自己手头的东西跑通，而且现在效果居然这么好，我自己都挺意外的。
毕竟我并没有那些特权渠道，我只是想把这种方法做成。所以我想你说的可能没错。如果我住在旧金山，大概也能做这些事儿，但我可就得住在旧金山了。我可不想去那儿，太难受了。我在现在这里过得很舒服。我父母就住在同一条路上，我儿子也在乡下长大，所以事情就是这样了。陈总，你骨子里是个做教育的人。你觉得软件工程师教学这个行业有什么变化？
还有大家想怎么学？如果你观察到了什么跟以前不一样的趋势的话，比如你刚入局的时候，我觉得正赶上网课和视频学习大火的时期，不像大概十年前可能流行看图文教程，再往前则是看书。当然，他们现在依然存在，只是大家的偏好不同了。对，大概是疫情那会儿，视频教程真的火起来了。我觉得大家想要更丰富的学习体验，而我大概正好赶上了那波浪潮之后吧。
我觉得人们的学习方式其实没怎么变，对吧？他们对特定类型材料的需求也没变。我觉得直接来个 agent
就能把什么都教会你，这种想法听起来很吸引人。在某些场景下确实管用，但其实你真正想要的是内容编排，对吧？你想要的是一个真人参与进来，理解信息之间的脉络流向。我总觉得信息就像一张图谱。对吧？一个知识点依赖另一个知识点，那个知识点又依赖另一个知识点，而把这张图谱理成一条线性路径，就是我对自我工作的定义，对吧？
我只是想教你，就像在图谱里跑一遍Dijkstra算法，让你能按最合理的方式学会它。这种程度的编排，说到底又是战略层面的东西了，对吧？这并不是AI特别擅长的事。我是说，我自己显然做了一次巨大的转型，从 TypeScript 这种战术性的内容转到了现在的战略层。目前看效果还算可以。做这行的其他人情况如何，我不好说。
而且我知道很多人大概并没有取得。这种程度的成功，所以我觉得这表明 agent 彻底改变了大家看重什么，以什么为优先的游戏规则，而且整个行业在七个月里的变化速度，我觉得比以往任何时候都要快。这是个巨大的转变。这不意味着我们要抛弃以往的工作习惯，但确实意味着我们的关注点变得不一样了。我觉得自己挺好的跟上了这一步，而其他人可能就没跟上，因为他们关注的重点不一样。
我想知道，对你而言，不管是做 Total TypeScript，还是更早前在 TypeScript 上分享的一些内容，你当时都是在帮大家掌握当下正大火的工具 TypeScript。当时市场份额一路攀升，大家纷纷从 Java 迁移到 TypeScript，从 Python 迁移到 TypeScript，诸如此类。
所以，开发者们都想学得非常精通。很多人，或者说前百分之十、前百分之二十，随便怎么说吧，都想把 TypeScript 学得非常非常精，而且他们也在寻找高效的学习方法。现在AI来了，正在改变我们作为软件工程师的工作方式。我觉得很明显，开发软件很有价值。但现在有个问题是，我该怎么更高效地使用这些工具？这比怎么高效写 TypeScript 更迫切，尤其是有这些 agent 的情况下。
所以我想知道，你是不是有点像当初从配音转行那样，在伦敦以外做不了配音，就转向了在伦敦以外能做的事情，也就是教课。你只是转去教一个不同的领域，而这个领域眼下又成了很多人都在关注的事情。我觉得我基本上就是运气好，在对的时间选了对的事情。我本来很容易就会，其实当初别人费了挺大劲才说服我转向AI。大概两年前，是我的合伙人Joel一直催我说：“你真得试试这个。
”这东西其实挺好用的，你能拿它做各种各样的事情。然后我实际尝试了大概三个月，一次次试，一次次失败，最后我才意识到，好吧，这东西确实厉害。我只是觉得自己挺幸运的，在对的时间来到了对的位置，而且我也尽量不去把它编织成某种叙事。我尽量不去想，哎呀妈，你做的真棒，太聪明了，在对的时间走对了这步棋。因为我也犯过好几个错误，而且我也很容易就落到另一个领域里去了。
我是说，那也没什么不好的，大不了我就回去接着做工程师，那也是我热爱的事情。设身处地想一想，如果你现在是一个刚入行的新人，对于今天刚入行、处于职业早期的新人来说，你在战术层面会建议他们做些什么？比如他们会明白，看我想拿到那种经验，想拥有那种判断力、品味和基本功，你得不断去练。如果你处在他们的位置，你会怎么做？
比如我想成为一名创造者，成为一名能用好所有这些 AI 工具之类的软件工程师。而这现在让人很困惑，因为现在大家很纠结：我是该用这些 AI 工具来替我做事，还是该去死磕基本功？而那样又很慢，诸如此类。我是说，我现在其实很想当个新人，我很想回到我二零一四年时的那种状态。当时我正在给自己的学生做那些工具，对吧？
前几天我还真挺怀念那段日子的。我想着，真希望能回去教教声乐，因为那种能力太棒了。比如我刚上一堂课，接着就能给 agent 写个 prompt，说这个工具在那方面不太好用，我也许能稍微改一下，然后看看效果。我就是觉得，正确的做法是尽可能多的使用这些 agent，因为以后大家都会这么工作。我觉得自己的技能组合里很有价值的一点，就是你能始终跟上正在发生的变化。
Grimi不仅让你能和资深开发者交流，对吧？那对开发者有好处，对你自己也同样有好处。它能让你不断思考这些更深层的想法。回想我当年做那个声谱分析工具时，捣鼓出来的纯垃圾代码。如果当时有个 agent 跟我一起做，效果肯定会好得多。当时那东西跑起来慢得要命，性能简直烂透了。如果当时我能说好了，现在的帧率掉到了每秒十帧，这该怎么修？
他就会看到那六层嵌套的 for 循环，然后说好吧，你这里也许该换个写法了。所以我觉得，只要你不仅关心自己写的代码，还关心写代码的整个过程，现在做这些东西就比以往任何时候都更能赋能开发者。现在也比以往任何时候都更适合做一个内省型的程序员，时刻反思自己的做事流程，保持自省。那听起来，只要有动力，学起来应该能比以往任何时候都快得多。
没错，关键就在于保持好奇心，保持适应力。我看到，在这个新环境里混得风生水起的，正是十年前就很出色的那一批人，因为他们就是对这项工作感兴趣，对做出更好的软件感兴趣，对自己的流程感兴趣。说到做出更好的软件，我想问问你关于园艺的事。X 上有一位叫 Lauren
的软件工程师发了条动态，我引述一下他的原话：每个团队都需要一个园丁，默默看着涌入代码库的 PR 水流，察觉代码异味，察觉像常春藤一样在你精心种植的花园里蔓延的坏习惯，用稳健的手去清理那些本会吞噬花园的杂草。
而你回复说，我觉得你的团队唯一需要的就是园丁。大概也确实需要其他几个人，对对，但具体来说，我想问问这种所谓的园艺概念。我其实非常喜欢罗恩描述的这种杂草霸占花园，然后把它们清理出去的说法。我记得不久前我发过一条推文，说我们是当时我差不多在琢磨 Ralph 纲目 Agent 循环处理事情的方式。我们本质上就是 Ralph 的平台工程团队，对吧？
我们现在就是这个角色，我们就是自己 Agent 的平台团队，我们是在努力为他们搭建能取得成功的环境。你完全就应该这么去思考，这同样是战略层面的事情。而且那个园丁的比喻很贴切，因为花园本身就很容易发生熵增，对吧？去长出杂草，搞出那一堆破事。那在这些东西在你自己代码库里变成问题之前，理解并排查出它们，就是一项核心技能，甚至可能就是那项最核心的技能，对吧？
只要你能给 agent 排上活，只要你能搭出咱们现在开始见到的这些循环。也就是 agent 根据 bug 报告和反馈来改进代码库的这些流程，在我看来，这活儿就很酷，而且既体面又有意思。咱们聊过一些特别出色的软件工程师，你从他们身上学到了东西，得到了启发。在今天，你觉得什么样的技能组合、经验和做事方式能造就一个优秀的软件工程师？
我举个例子，就是在 Versaille 做 AI SDK 的 Lars Grammel，我前几天刚跟他聊过，他正在给自己的开源库打造一整套软件工厂，那个库非常火，能收到海量的 issue。咱们又聊回到管道工，聊回到园丁，像是在思考软件开发的流程。要是让我用一个词来概括，我觉得会是内省，也就是审视你自己，并且有能力把自己做的事提炼出来，变成AI能拿来干活的东西。
你本质上就是在试图把自己的流程用语言表达出来。我之前做 Skill 也一直是这么做的。我一直在做的那些自动化也都是想做到这一点，就是我看看自己正在做的事，然后想我怎么能把这事儿做得更好。还有就是我怎么把这套东西编码进摆在面前的这个奇怪生物里？我怎么能让他按我想要的方式干活？这种心态对我来说非常有帮助，这也是我很看重Last的地方，以及看重我合作的所有人在面对Agent时展现出的这种特质。
那在收尾的时候，你会推荐哪本书或者哪几本书？我会选《程序员修炼之道》，John Ousterhout的《软件设计哲学》，还有我觉得Eric Evans写的《滴滴》，也就是讲通用语言的那本，读前三章左右，特别是那本里面的通用语言概念、领域建模都非常棒。至于具体把它编码成代码的部分，我倒没那么推崇。但这三本绝对是分量最重的三本。
太棒了，Matt。好的，谢谢你。这期聊得很有意思，也很好玩。终于上播客了，感觉真好。对，能见到这位名人本尊，太棒了。显而易见，我们之前见过，但来这儿真的太棒了。跟妈坐下来聊，真的很开心。我不得不说，知道他曾是台词教练和演员之后，我就明白他说话为什么能这么顺，听起来为什么让人这么舒服了。这次对话里最有意思的部分，大概是 Matt 在探索怎么更好地跟 AI 协作时，他发现真正管用的并不是那些现代方法。
相反，他回过头去看了经典的软件工程书籍，《程序员修炼之道》《软件设计哲学》和《领域驱动设计》。这里面多少有点讽刺意味。二十多年前记录的最佳实践，比如这本书里的战术性编程和战略性编程，不仅依然管用，而且在用 AI agent 写代码时反而变得更重要了。还有一个相关的点，我想强调一下，就是跟 AI 交流时引导词的重要性。
当 Matt 开始使用“失踪蛋开发”或者“垂直切片”这类术语时，模型在规划时就能更好的跟上他的思路。仔细想想，这也讲得通，因为软件工程文献本来就是大语言模型训练数据的一部分，所以这些术语也是模型先验知识的一部分。同样有意思的是，用准确的词来描述你的问题，这可不是什么新概念。比如 Kent Beck
来上播客的时候就讲过，三三十五年前他和 Word Cunningham 桌上就放着一本同义词词典，他们用它来为自己正在描述的具体事物找到最恰当的词，这又是一次印证用词到底有多重要。
最后我很赞同 Matt 提倡的一点，就是你要追求一个干净的代码库。这不仅是因为人类查阅起来更容易，虽然我觉得冲这一点你也确实该这么做，但同时还有一个附带的好处：A
车没有长期记忆，每次新运行它都会重新去看你的代码库。在一个结构良好的代码库里转悠，要比在一个乱成一团的代码库里轻松得多。大家可以查看下方的节目介绍，里面有我对《软件设计哲学》的作者 John Ousterhout 的专访，那是一本我非常喜欢的书，还有针对 AI 工程和上下文工程的相关深度解读。
如果你喜欢这期节目，请务必在你的播客软件上订阅。如果能顺手给个好评，那就太感谢了。感谢收听，咱们下期再见。