Transcription
太棒了。
我想我们是的，我们肯定开始了。大家好？我与戴克斯在一起。你喜欢戴克斯还是德克斯特？我都可以。我非常，你知道，他们说好的工程师是懒惰的。戴克斯只有一半的音节，所以我经常用戴克斯。很好。是的。我想是“Jit the T”。嗯，是的。呃，我是马特·皮科。嗯，我们要谈论很多东西。基本上，我看了戴克斯在AI工程师大会上做的一个非常棒的演讲。我不知道你什么时候做的演讲，但它大约一个月前在YouTube上发布了，可以说。
是的，我想大概是十一月下旬。是的。我想都是关于拉尔夫的，寻找让AI编码真正在组织内部工作的方法。这在我脑海中点燃了一把巨大的火焰，我需要，嗯，我想是用汽油来浇灭这把火。所以，戴克斯，你在这里。呃，我只是想真正谈谈所有这些事情。呃，我不知道我是否真的只是注册了一个聊天服务，这样我就可以和戴克斯说话了。所以，我只想在本地打开聊天。
我们开始吧。嗯，我看看。但在我做这些小小的管理工作时，你为什么不向大家介绍一下自己呢？
当然。嗯，大家好？我是戴克斯。呃，我经常对编码代理及其使用方法大发牢骚。而且，呃，我花了很多时间与那些粗制滥造的AI炒作机器作斗争，并努力真正专注于实际有效的东西和解决难题。而且，呃，我认为最令人兴奋的部分是，你知道，我们做的很多工作仍然是软件工程，还有很多工程要做，仅仅因为API，仅仅因为AI为你编写代码，并不意味着你不需要思考，不需要对系统深思熟虑，以及我们如何，我们如何，我们如何优化工程师与AI的协作，这样我们所有人都能把时间花在最有杠杆作用、理想情况下最令人兴奋和有趣的部分，对吧，也就是构建、交付和设计系统以及解决难题。
是的，我就是这样，我的YouTube频道主要是TypeScript YouTube频道。我仍然对TypeScript着迷。我仍然非常喜欢TypeScript。我的职业生涯是建立在无法想象为什么。是的，我就是喜欢它，伙计。我最近发布了更多关于AI的内容，你知道，大约在过去一年左右。我发布了一个关于AI的课程等等，嗯，我在YouTube上看到的很多东西，奇怪的是在X上完全没有，都像是AI是垃圾，对吧？AI它只是产生垃圾。它就是，内容是垃圾，或者视频本身就是AI生成的，有人制作了一个关于“人类层”的视频，他们说“人类层”太疯狂了，然后你看了视频，就只是一个人在滚动。就像一个AI浏览代理在滚动完全不相关的GitHub问题，这些问题与他谈论的无关，也与我们做过的任何事情无关。我就是觉得这很糟糕。我的意思是，如果我打开这个，而我没有注意，我可能会说哇，有人制作了一个关于我们东西的视频，然后你仔细一看，你会觉得这里没有什么经过深思熟虑。这里没有什么是有意义的。它就像是喂养AI内容机器。但人们接受这种观点，因为确实存在真正的垃圾，然后他们把它归结到所有代码上，对吧？所以任何由AI创建的代码都必须是垃圾，对吧？我有点想让你直说，那不是真的，对吗？就像你所看到的，AI实际上可以产生高质量的输出。
是的，AI可以编写非常好的代码。嗯，你必须驾驭它，对吧？正如Source的Bang会说的，你必须知道如何掌握它。呃，你必须做一些，如果你以前从未写过代码，那么让AI编写好的代码会很难。嗯，而且很难知道代码是好是坏。呃，所以就像我不想，我认为Vibe编码非常有趣，而且令人难以置信。它为很多人打开了做事情的大门。但我们真正关注的是，我们如何为拥有数百万行代码和数千名工程师的公司中的员工和首席工程师提供工具，使他们能够一、实际使用AI更快地完成工作，在大多数事情上快两到三倍，这有点像我认为目前对于现有代码库来说是最好的，以及如何构建实践、平台和系统，以实现团队和组织内部的某种标准化，因为即使你有一百名工程师，他们都非常擅长使用AI交付高质量的代码，但如果他们都以不同的方式做事，那么你最终还是会陷入混乱，即使所有代码都像你手工编写的、你知道的，慢三倍的巅峰代码一样。
是的。嗯，我们也应该给你一个宣传的机会。那么你现在在做什么？你在构建什么？让我们在结束之前给你一个宣传的机会。
我们来做个小宣传。呃，是的，所以我们正在开发，嗯，它还处于非常早期。所以我们在大约九月份发布了一个开源IDE，用于管理大量的并行云代码会话。嗯，它叫做代码层。嗯，我现在已经公开说过一两次了，所以我想我们可以再提一次，就是它有一个等候名单，但它也是开源的，所以你可以自己去构建和玩它。等候名单，我们喜欢开玩笑说，等候名单有点像一个筛选器，如果你不能去GitHub仓库并弄明白它，那我们可能还没准备好，因为它是一个早期产品，所以，我非常兴奋有成千上万的人去弄明白了它，出现在我们的Discord中，并给我们发送了PR等等。基本上在过去的六周里，我们吸取了所有在向客户推广过程中学到的东西，并从头重建了整个产品，重新设计了，很有趣，六个月前我还在谈论“研究-计划-实施”。我当时说，看，魔力不在于提示。没有完美的提示。你应该理解的是上下文工程和有意的压缩，以及再次有意识地管理你的上下文窗口等等。我说了这些确切的话。我当时说，这些词不会是“研究-计划-实施”，提示会不同，可能甚至没有三个步骤，可能有六个，可能有两个，我不知道六个月后会发生什么，这就像我向“苦涩的教训”或其他什么致敬。
然后我们在十二月中旬醒来，就像你知道的，RPI不够，我们实际上需要六个步骤，就像基于“好吧，我们如何帮助人们，人们如何拿起这些提示并尝试使用它们，如果你使用它们一千小时，你可以获得令人难以置信的结果。”呃，我们看到很多人会尝试它们，获得非常好的结果，然后把它们交给他们的团队，而他们的团队会得到各种各样的结果质量。所以我们正在重建工作流程，现在步骤更多了。所以就像，好吧，我不想要求某人学习如何使用六个提示。三个已经很多了。那么，我们如何围绕更具指导性的工作流程重建产品，并基本上拆分这些非常长的，嗯，如果你阅读开源仓库中的“创建计划”提示。你试过吗？
没有。好的。我没试过。所以，有一个你可以使用的提示。它是“/create plan”，里面大约有50条指令。嗯，它基本上就像我六月份去谈论12要素代理时说的一样，不要用提示来控制流程。如果你知道，抱歉，如果你知道工作流程是什么，就用控制流来控制流程，因为它会更可靠。事情会按顺序发生，这是有保证的。所以，我们把规划过程分成了多个步骤。嗯，所以包裹着它并引导用户完成这些步骤的确定性代码，嗯，就像我认为我们真的非常痴迷于让它非常非常紧密和非常非常好。这样你就有机会获得非常好的结果，而且你参与的对话部分，比如你必须做的事情，是你能做的最有趣、最有杠杆作用的事情，而不是像，如果你在这个过程的这个部分不撒上这些魔法词，它可能就不会那么好用，你知道。
是的。所以听起来你几乎尽可能地接近人们在实际中做这件事并试图解决他们的问题，基本上就是让AI编码代理行为得体，并教人们如何正确地掌握它，以及构建一个帮助人们正确掌握它的产品，我认为这就是我今天想讨论的，那就是你如何正确地掌握这个东西，你明白我的意思吗？就像，这就是现在的问题，然后，好的。
我们为什么不先做一点场景设置呢，我真的很喜欢你演讲中的一点是，你谈了很多关于大型语言模型（LLM）的限制，以及你必须在这些限制内工作。具体来说，你提到在上下文方面，有一个“愚蠢区”和一个“聪明区”，对吧？
我可能会做的是，我可能会做一些实时图解。然后，我们开始吧。你边说边画。我是一个画图的，我一直想换过来。我认为Excalidraw看起来就像，嗯，我以前公开说过。我认为它看起来像连环杀手的涂鸦，我认为TL Draw等一下，让我，是的，你可以编辑那个。我想哦，是的。你给我发了一个链接。太棒了。我们开始吧。
而且T，因为我知道你改变了TL Draw中所有的快捷键，所以我得重新学习。我会慢一点，但是呃所以我想你好。这会起作用吗？哦，不。我实际上没有分享我的屏幕。那是我没做的事情。等一下。我们开始。整个屏幕。好了。你好。我们在这里。我们进来了。太棒了。哦，嗨。哦，你真的在这里。太棒了。
好的。所以，语言模型（LM）有一个上下文窗口，对吧？它们有，比如说，这是上下文窗口，这里某个地方有一个聪明区和一个愚蠢区。是的。对。假设顶部是聪明区，这里是愚蠢区。这对那些做这些事情的人来说具体意味着什么？嗯，是的，我的意思是，在编码代理之前，我们就会，答案是，你使用的上下文越少，你总是会得到更好的结果，对吧？我们对工具调用代理的看法是，你总是处于一个循环中，你正在获取这个上下文，所以，无论你的上下文窗口中首先有什么，嗯，所以我们把它放在这里，所以你有你的，让我们看看他们改变了多少快捷键，呃，你有你的系统消息，然后你有你的内置Claude工具，比如代理和任务，以及读写、编辑所有这些东西。你有你拥有的任何自定义MCPS或者工具搜索功能，但是，嗯，你知道，自定义MCPS不再是那么大的问题了。我还没有尝试过工具搜索，但它的前景看起来可能会相当不错。
是的。呃，然后你有你的自定义指令，对吧？你的Claude MD或者你的代理MD或者其他什么。我会谈论，我会使用很多云相关的词汇，但这对于你使用的任何大型语言模型（LLM）都是如此。比如它们都有二次注意力。它们都以这种方式工作。呃，然后你会输入，你知道的，
只是打断你一下。我想我会经常打断你，你能给我解释一下什么是二次注意力吗？那是什么意思？呃，是的。所以那基本上是，嗯，这个想法是，你的上下文窗口越长，嗯，基本上就像计算量和你从大型语言模型（LLM）那里得到的响应质量，嗯，所需的计算智能量，我不想说计算智能，它会随着令牌数量的增加而呈二次方增长。所以如果你有五个令牌，呃，然后你到十个令牌，十个令牌将是，你把令牌数量翻倍，你把消化所有上下文并实际对其进行操作所需的计算量翻四倍。
听起来对吗？是的，没错。而且那也是每层和每个注意力头，对吧？所以那简直是疯了，你知道，你可以有像50、80个，你知道，这些数字不是公开的，但它就是会变得非常疯狂。你添加的每一个令牌都会呈二次方地无限膨胀，而且它会，呃，让它变得非常愚蠢。
是的。而且，很多关于长上下文的基准测试都是关于这个的，比如它们是在一个叫做“大海捞针”的东西上运行的，我认为这实际上没有用。我的意思是，Jeff Hley，那个Ralph的家伙，在三月或四月的时候就谈论过这个，他说“大海捞针”没有用，因为大多数时候你不需要阅读，你知道，十万个单词然后挑出其中一句重要的。你需要阅读十万个单词并根据其中的所有信息采取行动，或者你知道，筛选出真正重要的五万个单词。呃，那是一个更难的问题，我们不擅长基准测试。我的意思是人们正在为长上下文代理等进行基准测试。但是，嗯，是的，回到上下文窗口的事情上。嗯，你准备好重新开始了吗？这是否充分回答了二次注意力的问题？
你做得非常棒。干得好。太棒了。嗯，所以我们会像你的用户消息会在这里进来，对吧？这可以吗？那太好了。现在，嗯，
你在这里选择了T Draw，不是吗？没关系。嗯，我准备好用它了。是时候学习它了。嗯，代理会调用一些工具。你会得到一些，呃，让我们看看，你会得到一些工具响应。这会发生，你知道，很多很多次。如果你问，这个项目的readme里有什么？那个很简单。嗯，然后你最终会得到某种助手响应，对吧？而且你的愚蠢区、聪明区，呃，更小，但是，呃，这不是按比例的。这么说吧。是的，这个上下文窗口要长得多。
是的。在某个时候，你会在聪明区耗尽空间，对吧？就像你会继续往下走，继续那种冗长的联系，然后你会碰到某种障碍。
是的。没错。嗯，所以这个想法，是的，这里的想法是，呃，使用编码代理有很多不同的方法。嗯，最天真的方法就是打开它，让它做一些事情，当它完成这些事情后，再让它做更多的事情。呃，基本上就像，我喜欢聪明区和愚蠢区，我认为这是一个经验法则，比如40，我总是说大约40%的上下文使用率，这基于我计算令牌的方式。实际上，我计算令牌的方式和我们在rip tide中计算令牌的方式与你在云代码中默认获得的方式略有不同，因为他们在百分比计算中包含了像结束缓冲区一样的东西，就好像他们实际上没有将其计为可用一样。
不太相关。重点是数字并不真正重要，真正理解这一点的方式是，对于不同类型的工作和不同类型的任务，呃，变化的数量是灵活的，嗯，但你使用的上下文越多，你得到的结果基本上就越差。
我认为重要的是那种偏执，对吧？就像那种感觉，我应该担心这个，或者我应该思考这个并努力优化它，对吧？
是的，基本上，那里的想法是，每次你即将发送新消息时，你都应该问自己一个问题，比如这是否可以是一个新的上下文，比如信息是否，有时我会保留它，有时会觉得这里有很多好的信息，我真的没有耐心等待模型在另一个上下文窗口中再次阅读所有这些文件，或者让它，嘿，我，或者我没有信心它能够准确地总结我们目前所拥有的一切，以便我可以加载新的上下文窗口，但你每次都应该问自己，这应该是一个新的用户消息还是一个新的上下文？我想，希望是你不需要问自己这个问题，而是你正在设计系统和工具，以优化聪明区并避免愚蠢区，对吧？而这也就把我们带入了拉尔夫，
对吗？我喜欢它。是的。我的意思是，对吗？所以，是的，Ralph是一个系统，它优化了总是在上下文窗口的早期部分工作，我喜欢把Ralph想象成一个控制循环。我以前也谈过这个。我喜欢把Ralph想象成一个控制循环。嗯，你有没有在Kubernetes世界里待过？
我？不，我一次都没碰过。所以，它的工作方式是建立在控制循环上的，这非常简单，就像你的恒温器就是一个控制循环，对吧？你读取世界的当前状态。哦，我的天。好吧。这不是TL Draw的东西。我今天早上就是打不了字。呃，然后你读取世界的期望状态，然后你采取一些行动，你只是永远这样做。就像你只是采取行动将世界的当前状态推进到世界的期望状态。让我们看看。是的。
好的，那个快捷键是一样的。不错。而且你只是永远在循环中做这件事，对吧？所以当我想到Ralph时，我把Ralph看作一个控制循环，嗯，你有一个系统提示，你的内置工具，你的云MCPs，你的用户消息就像告诉它读取几个文件，然后被拉入的基本上是规范，也就是你期望的世界状态。你让它查看源代码，也就是世界的当前状态，然后你说实现一件事，对吧？是的。
当我考虑聪明区时，我能给你的最实用的建议是，找出一项任务，而且这项任务的大小很重要，因为你基本上希望能够进行你的编辑、编辑、编辑工具调用，然后你将验证，比如运行测试或运行linter或其他任何东西。也许它坏了，你又做了几次编辑，嗯，然后你运行测试，它通过了。基本上，当我考虑任务大小，或者如果你正在做一次性的规划，而不是永远使用Ralph，你希望你的任务大小能够让你进行更改，运行测试，修复任何问题，运行测试，然后进行提交和推送，或者其他任何操作，所有这些都尽可能在最少的上下文中完成，对吧？
这里有权衡，因为如果你把测试做得太小，就会出现，你知道，你改变了一个文件，改变了一个函数的签名，然后测试就不会通过，直到你改变另一个文件。所以，有些这样的改变你不能每次循环只做一次编辑。我想是不是你谈论过那个光标的例子，就是循环太紧了，有人在X上谈论Ralph的某个实现中循环太紧了。
所以，我有点把它想象成你有了你有一些水，对吧？你需要你不能把所有的水都装在一个杯子里，对吧？所以你需要把它装在多个杯子里。我认为人们没有意识到的是，杯子比你想象的要小，对吧？代理可用的资源比你想象的要少。所以，这是一个非常有趣的问题。我的意思是，关于Ralph，有很多有趣的问题。
是的。比如，而且你有很多可以拉动的杠杆。比如，我们能再把白板调出来吗？
是的。是的。给你。是的。所以，就像你在这里有你的规格。你可以让规格更小更紧凑。你可以找到一种方法，让它更好地遍历源代码，这样就不会占用太多。你可以移除一些自定义MCPS。你可以禁用一些内置工具。就像你有很多，然后就像，好吧，这个任务有多大？这可能是你能做的最有杠杆作用的事情。但再次强调，就像你有很多杠杆可以拉动，来控制这里面有什么，以及你的任务有多大，以及你的平均上下文长度是多少。那实际上会非常有趣。如果我要构建一个像Ralph这样的工具，我构建的一部分就是让人们看到和衡量每个东西使用了多少上下文，这样你就知道哪个地方是你的瓶颈，你知道在循环结束时每个循环退出的上下文使用了多少，你可以按迭代绘制图表，然后理解，哦，这总是达到60%的上下文，我需要让我的任务更小。
是的。那是我发现的一件事，我的意思是我们可以稍后讨论这个，但我在本地自己实现这个时发现的一个真正棘手的问题是可观察性太差了，对吧，就像我在这里得不到任何真实的数据。嗯，但我们现在先保持在一个高层次上，那就是你正在尝试用Ralph构建一个系统。哎呀，我把你完全弄掉了，嗯。没关系。在你只是试图稍微填满每个杯子的地方，对吧，这样杯子里就有空间进行测试，进行，嗯，用玩家MCP或其他东西检查世界的状态。
是的。而且，你放入的水量的大小，就像，基本上就是整个游戏的关键。
然而，如果有人说：“好吧，我喜欢这个主意。嗯，我想让一个代理在循环中运行，就像做一些任务一样。”他们如何将其整合到他们的组织中？比如他们能做的一件小事是什么，你知道，因为我们在这里所做的一切，听起来很傻，拉尔夫·维古姆，对吧？但我们在这里所做的，只是运行我们已经拥有的工具，就像在循环中抓取代码一样，对吧？我们所做的就是这些。
你如何将它引入一个组织，只是为了你自己尝试一下？你如何设置它？是的。嗯，所以有很多方法，我的意思是，我最终做的确切步骤是，我不知道，我曾经讲过这个故事，嗯，但我们当时，我正和我们的一位前端工程师坐在一起，他正在查看一堆React代码，我们当时正在一起调试一些东西，他说，嗯，这段代码需要重构。我们需要重构。就像，“好吧，太棒了。你去修复那个东西。”而且就像我们工作的时候，我有点像在旁边。我正在聊天，我花了大约30分钟和Claude来回交流，比如“给我构建世界上最好的React风格指南。”它读取了代码，然后提出了一堆问题，比如“你是否想允许桶式导出，或者你想做其他事情，比如你想使用useEffect，或者你想使用Zustand存储？”就像我看到了所有这些不同的模式。哪些是正确的模式？花了大约30分钟回去回答。它返回了大约25或27条React规则，我分享了PR，你可以把它放在视频的节目说明或其他地方，因为PR，我稍后会解释为什么PR从未合并，但是你提出了这些规则。我又花了30分钟和前端工程师一起，我们来回迭代了几个，然后我们把它放进了一个仓库，我们做了一个Ralph循环，基本上就像我设置了一个GCP虚拟机，我打开了一个T-Mo会话。我抓取了这个风格指南，然后我对Jeff的提示做了一个小小的变动，对吧？因为Jeff的提示是“阅读规范并实现它们”。在这种情况下，世界的期望状态是所有代码都遵循风格指南。
是的。而且，它不是一个实施计划，而是一个重构计划。是的。那就是我们正在迭代的，包含了所有任务的，我们的“产物”。这东西运行了大约六个小时。我大约六个小时后检查它，我开始看到消息，比如“嘿，我们完成了，我想我也要这样做”，我当时想，那就是你知道的，就像Jeff总是谈论Ralph是“未完成”还是“过度完成”一样。
或者就像你想到，当你训练一个机器学习模型时，你通常会过度拟合它，然后你回滚到实际上是模型拟合的正确量的检查点。呃，同样的事情是，如果你让它运行太久，它会想出更多的事情要做。这些模型就像被训练成，如果用户让你做某事，比如找到一种有用的方法，对吧？
还有， 暂停一下，它的实现方式，至少我所看到的，我想可能是在原始文章中，以及我实现它的方式是你在一个bash循环中运行它，然后你说你告诉LLM当你完成时发出某种标记，然后我可以从你的输出中读取它，然后停止循环，对吧？你指定一些我从未做过的那部分。那是Anthropic插件所做的。我不知道。我还没探索过那个。我认为Ralph的乐趣之一就是让它自由发挥，然后由你来检查它，你可以随时回滚并尝试输出。但这其中一个令人兴奋的事情是，我不知道你有没有看过cursed lang仓库，那是Jeff用Ralph制作的编程语言，但你会看到各种奇怪的涌现行为，比如它作为工作的一部分，到处倾倒数百个markdown文件。就像你从未告诉它这样做，但在这里，嗯，它会让我分享我的屏幕吗？让我看看我能不能，呃，它可能不会，它可能实际上会，呃，在你做的时候，我从未想过那个。我真的从未想过不停止它，你明白我的意思吗？就像这就像我猜是紧张的我不想花费太多令牌或其他什么，但我从未想过就让它一直运行。
让我们看看这里。也许我可以，是的，让我看看我能不能分享这个。是的，因为，让我们看看。分享屏幕。我们分享窗口。没关系。嗯，所以这是那个“诅咒”仓库。这就是Ralph运行了很长时间的东西，像几周几周又几周。是的。
哦，有趣。看起来它被清理了一点。嗯，如果你去看更早的提交，你可能会看到，呃，我们回到这里。你把，呃，呃，字体大小调大一点。
是的。是的。是的。没错。嗯，好吧。也许我们可以去Rust分支。我不认为这个被清理得那么多。嗯，有趣。好的。呃，如果你看过这个的早期版本，那里有大约一百个markdown文件，全部大写，就像Claude正在进行的工作，只是在不断地产生想法、概念和文档之类的东西。
嗯，但是你会得到这些涌现行为，Jeff也有这个。比如，哦，我让它运行太久了，它决定它需要，就像它只是想出了更多要构建的东西。它就像是，好吧，我想我们可能也应该让这种编程语言支持后量子密码学之类的东西。
所以，我有点觉得它的乐趣之一就是少指定一点，看看会发生什么。显然，如果你想要真正好的生产软件，你应该尽可能多地指定，
但是是的。是的，那就是我的立场。那是因为我把这看作是我基本上可以完成工作的一种方式，而且带着那个带着我有的这个想法，我想我不知道我甚至是从哪里学到的，那是不是从Ralph插件学到的？我可能学到了，不是吗？嗯。
他们有像完成承诺和最大迭代次数。我就是这么做的。我就是这么做的。所以这对我来说很自然，因为我想做的是预先选择一个定义非常明确的工作范围。嗯，然后就让Ralph自己找到终点。
然而你所说的，有点像是选择一个未充分指定的工作量，然后就让Ralph在这个区域里自由发挥。而且，对我来说，我的版本感觉你需要做很多前期工作，但这正是我想要做的工作，因为我想磨砺我的想法。我想非常清楚地描述世界的期望状态。
但是，是的，我只是对你在这方面的想法感兴趣，比如你认为未充分指定的Ralph与过度指定的Ralph有哪些用例？我的意思是，我还要说，我曾在大量的规范上运行过Ralph。我让Ralph编写了规范。我曾说：“嘿，去阅读这个产品的所有文档，然后提取出像洁净室规范一样的东西，这些规范实际上定义了它如何从头开始工作，没有实现细节，然后你再在这些规范上运行Ralph。”所以，你有一个Ralph在构建规范，另一个Ralph在读取规范，然后就像，我想是添加AI功能。所以就像有另一个目录，里面充满了规范，这些规范就像是字面上的复制和粘贴。它非常像Lisp或流水线，就像你有一个Ralph将互联网转化为规范。你有一个Ralph将规范转化为如果这个产品有更多AI会是什么样子，然后你有一个下游的Ralph读取这些规范并将其转化为可工作的代码。
是的。疯狂。好的。我猜它进展不顺利。我没有阅读规范，我得到的东西我并不喜欢。而且那也是其中一部分，就像我认为Ralph可能不是我们如何构建生产软件的正确最终答案。我认为它可能，如果说有什么的话，它就像一个关于上下文窗口如何工作的不可思议的教训。我想Jeff一直在做的事情就是，不要使用Andropic插件。学习理论，因为理论才是让你成为更好的AI和编码工程师的原因。而且你仍然应该使用它，但你应该理解它为什么工作得这么好。那么，我们把Ralph定义为那种狂野的自由形式，就像玩耍的想法。当然。不过这里有一个想法，对吧？就像在一个循环中运行一些非常具体和紧密的东西，对吧？而且听起来如果那不是Ralph，那么那就是我不知道的别的东西，对吧？但是当你和那些正在做这件事的人交谈时，他们想要长时间运行的编码代理只是挂机运行，如果不是Ralph，你推荐什么结构？
嗯，所以那一部分，如果你正在做像这种重构计划一样的完全挂机操作，我可以完成讲述我们是如何做到的，以及我会怎么做。PR没有被合并。嗯，实际上我可以在这里把它调出来给你看。我认为那会是一个，嗯，可能有趣的东西。所以，我们去拉取请求。关闭。你也会喜欢这个名字的。呃，这工作量很小。嗯，就是这个。拉尔夫回来了。
拉尔夫回来了。所以，这是六小时内的20次提交。嗯，这是我与工程师一起制作的React编码标准文档。这是你可以实际查看的重构计划，它用来跟踪所有进度。你看到了丰富的div。嗯，所以这很酷。我们整合了所有自定义钩子。我们在所有地方添加了错误边界。我们确保使用了正确的表单状态，就像做了我们规范中的所有这些事情一样。
呃，这个没有被合并。嗯，原因是因为它，你知道，数千行，这是多少行？我们回到顶部。它是，呃，是的，两万行，其中一些是计划文件之类的，但是我当时觉得这是一个很酷的实验。我告诉工程师，他两天后看了看，有一百个合并冲突，我当时想，好吧，没关系。我们以后再做这个。就像你总是可以重新基于路由，对吧？Ralph的另一个好处是，你可以直接Ctrl+C它，扔掉所有代码，然后用相同的规范更新代码，再运行一次，而且成本很低。就像花了10分钟设置GCP实例，然后花了10分钟关闭它。是的。
嗯，我想如果我真的要在公司里做这样的事情，而且我们内部尝试过的一件事更倾向于，嗯，少做一点，就像Ralph是一个很酷的，比如世界的当前状态，世界的期望状态，做一次改变。嗯，我为我们内部的一个仓库部署了类似的东西，我设置它只运行，我每晚在cron上运行它，只运行三次循环。我希望每天早上醒来，就像免费得到代码库一样。我只是觉得代码库好了一点。
而且我们没有合并所有那些PR，但每天早上我们醒来都会说，哦，是的，这太棒了。而且我的规范就是我希望代码库看起来的样子。这就是我希望它在最终世界中被架构的方式。而Ralph只是做这些小小的增量。呃，所以我的建议是不要给你的同事发送一个重构整个代码库的20,000行PR。那在现实世界中是行不通的。但你可以使用这些概念，它就像一个构建块，你可以用它来放手不管，不用思考，每晚在GitHub Action中运行它，然后看看你得到了什么。
是的。我实际上正在考虑的一件事，我本来打算在我们开始之前尝试一下，但我们开始得早，所以我没有机会，但我有一些开源仓库，我基本上没有时间去分类所有进来的问题。所以这里有一个极其简单的Ralph循环，对吧？就是你把所有问题都输入到一个循环中，然后让它判断是否，你可以对它进行分类，对吧？你判断它是否是一个功能请求，不需要采取实际行动，或者你让它重现bug或类似的东西，然后你可能会把它反馈给另一个Ralph，那个Ralph正在寻找GitHub标签或类似的东西来实际修复bug并创建PR。这里只是一个工作流模式，对吧？就像
是的。你管理着小队列，然后Ralph的不同提示适用于不同的队列。
是的。而且你通过在循环中观察它的行为来调整这些提示。然后你让它像你基本上描述的那样，整晚挂机运行。我想，一次不要做太多是思考它的方式。我还要说，你应该小心从社区获取GitHub问题并将其输入到具有危险跳过权限的Claude中，因为它在技术上是不可信的输入。所以我们有一个Ralph会处理我们的线性队列，但在我们查看它并寻找HTML markdown注释中的隐藏提示以及所有这些东西并确保“好吧，这实际上对DSP中的模型来说是可以处理的”之前，它不允许看到任何东西。去吧。是的。是的，这完全有道理。
好的。那么，假设你已经设置好了这个循环，我们谈论的任务大小是什么？我们先谈那个。比如，这就像你在提示Ralph的时候吗？
是的。我喜欢Ralph的一个非常好的地方是，它让你摆脱了选择下一个任务的负担。如果你有一大堆问题或其他什么，你可以，你知道，只要它们被正确描述并且你已经把所有依赖关系都映射出来，那么你就可以让Ralph自己去做，选择下一个问题，然后从那里开始，这真是太好了。那么，当你告诉Ralph要做多大的改变时，你对它说了什么？你是想让它尽可能小，还是你认为呢？所以是的，在生产中，我们使用的工具再次更多地是人类在循环中，因为世界上最困难的软件问题不会完全自主完成。它们将在很大程度上与人类协作完成。但我认为这个建议在两个世界中都适用，那就是当你设计一个计划时，无论是你将交给Ralph的计划还是你将要计划的，我们都有一个单独的提示，它基本上就像运行一个父子代理，在子代理中运行每个任务，抱歉，一个父代理，然后在子代理中运行每个实现。父代理检查工作，然后进入下一阶段，提交并进入下一阶段。而且这已经是一个经过严格审查的计划。我不断发现的建议是模型无法做到的，而且是人类现在需要参与循环的事情。也许我们只需要改进提示。但模型不擅长以人类会做的方式规划工作。而且我认为，试图引导他们，就像我不知道，前几天我和一个朋友在做一些事情，就像我们前端有这40个东西。我们将把它们移到后端，通过API提供服务，然后让前端查询JSON并以这种方式渲染。模型想要的是，酷，首先我们要移动这40个东西，然后我们要连接API端点，然后我们要重构整个前端。三阶段计划，对吧？就像，好吧，如果你要构建这个，你会怎么做？就像，嗯，我会移动一个东西，让端点工作，确保一个东西正在工作，可能在这个过程中学到一些东西，然后就像在那个领域遇到一些惊喜。你就像你想要最小化改变的大小，就像如果你是一个工程师，你不会只是复制粘贴40个文件然后就走，我的意思是也许有些人会，我不会，呃，因为我想要更紧密的反馈循环，而且我知道会有未知数，这些改变会有我们没有想到的影响范围，我特别不想坐着，要么你有一个在代码库中有15年经验的人，他们会说哦是的你会遇到那个问题，要么你可以坐在那里三个小时研究代码库中的每一个东西，然后尝试在开始之前让计划完美。但这里有一个最佳点，那就是在实施计划的早期优化学习，然后像你写多少代码一样分割计划中的任务？没有AI。在你打开Web应用查看之前，你会写多少代码？或者在你暂停运行测试之前，你会写多少代码？而这对于Ralph或者一个非常像人类在循环中的AI来说是一个很好的任务大小，你正在做一个，你知道，更小的，你知道，五六步计划或类似的东西。但就像，我的经验法则是，作为一名工程师，你的直觉仍然非常非常好，你应该听从它们，仅仅因为你使用了AI，很多事情会改变，但很多事情不会。
《实用程序员》这本书有一个概念叫做“示踪弹”，就是你应该编写代码，就像你知道这个，对吧？是的。是的，就是你应该编写代码，它会告诉你你基本上要去哪里，并且它首先会通过所有的集成层，你不应该做一次巨大的改变。它应该是一个贯穿所有层的改变，这样你就能看到所有层都正常工作，对吧？
伙计，这太疯狂了。所以我大约12年前读了这本书，我喜欢这个想法，在过去的六个月里，我一直在向人们解释你所说的这个概念。
或者别的什么，我忘了它有个名字。这个我喜欢。我真的读了这本书。它在我书架上放了大概三年。还包着膜，对吧？但前几天我把它拿出来，一口气读完了。就像，它就是最了不起的、组织得最好的东西。是的。但是 >> 而这 20 年前的智慧仍然超级重要。>> 我会说它比以往任何时候都更重要，对吧？因为 >> 是的。>> 而且实际上，让我们稍微岔开一下，那就是如果你不读那些旧书，我们现在是用英语编程的。而那些书是用你能看到的最清晰、最完美的方式来描述好代码的，对吧？它们太棒了。所以我一直在回顾它们，就像我现在又买了四本。就像学习如何为编码进行提示一样，阅读那些 20 年前的书是一种惊人的方式。它真的令人难以置信。>> 我喜欢这个。我还有一本我最近一直很着迷的书，那就是嗯，你还记得吗？我想是 Martin Fowler。可能是 Uncle Bob 的东西，但就像这个学习测试的想法。你听说过这个吗？>> 不。不。现在。>> 好的。所以，学习测试是我一直喜欢的，特别是如果你正在与一个你不理解的系统集成，比如我们经常与云代码 SDK 进行集成，它的文档正在变得越来越好，但文档就是文档，这意味着你不能总是完全信任它们。嗯，而且它是闭源的，所以当我们准备构建一个功能时，我们会做到一半，然后说，“哦，我们以为行为是这样的，但事实并非如此。”就像惊喜会发生在实施过程中，然后我们不得不全部丢弃并回滚。所以学习测试就像你会把它构建在你的单元测试框架中。你会把它放在一个不会在每次构建时都运行的地方，因为它不是为此目的，但它就像一个单元测试，你知道描述、期望所有这些东西，但它是为了验证外部库如何表现，无论是你不知道的 bund color 还是某个巨大的战舰软件，比如云代理 SDK，你基本上说，我认为文档说它是这样工作的，我认为它是这样工作的，去写一个实际有断言和控制台日志的测试，解释这个东西的行为，而且通常假设是错误的。但是 Claude 真正擅长的是，编码代理真正擅长的是，就像，好吧，让我去迭代一下，直到我理解与这个外部系统的契约是什么，我有一些断言真的很不错，因为我们不总是运行它们，但三个月前我们写了一些关于会话 ID 如何工作的学习测试，然后他们改变了会话 ID 的行为，我当时想，我认为这是错的，再次运行学习测试，它就像，是的，他们打破了契约，或者契约改变了，就像现在它是如何工作的。这是在研究和设计新东西时可以做到的一个非常有力的前期工作，而且就像，再次，这是我的意思是他们为这个，他们没有改变概念没有改变，而且就像人们显然不应该写单元测试，因为智慧是你你不应该对外部软件写单元测试，这是他们的工作来测试它，就像你信任契约，你信任维护者，而且就像 >> 我不知道 >> 我的意思是 >> 超级有价值。我们完全跑题了，但是就像我几乎有，你知道当你辞职时，你会回想你在那份工作上本可以做得不同的事情。>> 就像我们有一个后端团队，他们非常不可靠，只是在发布垃圾。而我想做的是，我的意思是，也许他们的内部代码是好的，但他们只是不断打破我们之间前端和后端之间微小的 JSON 合约。他们会放，你知道，>> 嗯，一个不应该为 null 的地方，等等等等，拼写错误。所以我想在它之间放一个小的 zod 东西，只是在开发服务器上，只是为了，你知道，那就是你所说的，基本上就像，而这些东西对 LM2 很有价值。好的，回到。>> 是的。>> 嗯，所以你基本上是在说把任务分解得超级小，几乎和你所能做到的那么小，或者就像，有没有什么？有没有太小的尺寸，对吧？就像我认为它也与可验证性有关。就像如果你能写一个单元测试来测试它，那么就去做。>> 但再次，就像我把我的阶段划分成，我想要知道，我想要能够检查这个东西。我的意思是，对我来说，就像如果我们正在做非常困难的事情，我宁愿我宁愿检查每 100-200 行代码，因为你最不想看到的就是，我敢肯定你和 Ralph 一起遇到过这种情况，你到了最后，你说，我有 2000 行代码。它坏了。我不知道为什么。我甚至不知道如果我要重置，我将如何改变我的提示，使其不再损坏，除了，你知道，犯零错误，超厚，或者孩子们现在对模型说的任何话。所以就像我一直在寻找双重目的的计划，就像如果我想把它一次性发送出去，然后说，“嘿，在我不在的时候去做所有阶段，我会在最后来检查。”或者就像这真的很微妙。我对一切的外观和工作方式有很多看法，所以我会在每个阶段都检查一下。无论哪种情况，就像把它分解成一个可验证的块，而且它可能比你需要的要小。这是另一项我認為人们將會發展的技能，那就是我如何知道，或者模型如何知道它所做的東西正在按照我這個人類的意願工作。>> 是的。就像，好的，有两个问题。我先回答第一个。>> 你在说，就像，什么？>> 哦天哪，我刚意识到我可能，我得走了，伙计。我忘了我 9 点必须准时走。哦天哪。>> 你觉得>> 我们应该找个时间做第二部分。>> 我敢肯定你还有更多问题。这次很棒。>> 这太棒了，伙计。这太好了。我想>> 好的，你去忙你的事吧。>> 永远，永远让人们意犹未尽，Matt。这就是我学到的。>> 我太恼火了。我有很多事情。>> 我们会做的。如果你愿意，我周一再做一个。>> 听起来不错。我们再商量。下次见。>> 祝你好运，伙计。这次很棒。谢谢 Matt。再见。>> 再见，各位。哦，这真是太令人难过了。这真是太令人难过了。所以，各位，我还会留几分钟回答你们的问题，因为我们有，嗯，我们有相当多的人在这里。而我接下来想问的是，我们正在进入一个我们基本上与人工智能代理合作的时代，而我们将主要专注于构建好的计划和好的任务，并努力成为真正的首席开发人员。而对于那些在工作中从未做过这件事的人来说，这将是一个巨大的转变。而我，我很好奇。我的第一个问题是，你实际上是如何编写这些计划的，它们又是什么样子的？我自己对这个问题有一些看法。但我真正不知道的是，你如何对待一个从未处于过那种位置的人，你知道，基本上是在协调他们手下的多个初级开发人员，并赋予他们这些技能，因为我学会这样做的方式就是通过做，而且做得不好，然后希望做得更好。所以，我不知道。这很有趣，那些你基本上必须想象出期望的世界状态，弄清楚客户想要什么，然后把它变成代码的技能是很难教授的，我也不知道该怎么做。所以，各位，给我一些问题。否则，我也要走了。我有一些晚餐在等着，或者说还没完全等着，但我得先去做。啊，我喜欢 Dex 的地方在于他非常善于表达，非常，我不知道，他知道他在想什么，而且他敢于说出来，而且他说得非常好非常好，而且我不知道，很少有人以一种强调代码质量的方式谈论这些东西。总之，好了，我先走了。谢谢大家。这很有趣。