“300行代码写个Cursor,这是AI时代软件工程师的新底线。”Ralph Loop创造者、Claude Code核心技术设计者的暴论
<p data-type="paragraph">“软件开发已经死了,因为现在任何人都可以成为软件开发者。过去六个月的变化比过去三十年都多,而大多数工程师还在当 Jira 工单猴子,浑然不觉自己已经站在了悬崖边上。”</p><p data-type="paragraph"> </p><p data-type="paragraph">最近,Ralph Loop 的创造者 Geoffrey Huntley 在播客节目中与主持人 Hendrik Krack 展开了一场火花四溅的对话。</p><p data-type="paragraph"> </p><p data-type="paragraph">这套“痴呆但管用”的内存管理方法,如今已经被 Claude Code、Cursor、Copilot 等主流工具内置进去。</p><p data-type="paragraph"> </p><p data-type="paragraph">Ralph Loop 最早在 2025 年 7 月由 Geoffrey 提出,到 12 月前后开始在开发者社区发酵,并被 Claude Code 吸收到自己的 harness 里。它解决的问题是:当一个任务需要持续推进、反复检查、不断修正时,怎么让 agent 不要跑一轮就停下。</p><p data-type="paragraph"> </p><p data-type="paragraph">在原始 Ralph Loop 里,agent 会先规划、拆任务,再开启新的 session,用干净的上下文继续推进。Claude Code 后来则进一步改进了这个 Loop:它没有完全照搬这种多 session 方式,而是在单个 session 里加入循环机制,通过最大迭代次数、safe word 和 stop hook,让 Claude 在任务没完成时继续跑下去。也就是说 Ralph Loop 最重要的意义是把 coding agent 从一次性生成,推向了长时间运行。</p><p data-type="paragraph"> </p><p data-type="paragraph"></p><p data-type="paragraph">在这次播客中,他们从“软件开发已死”的宣言聊到“K 型分化”下的职业生存法则,从 Ralph Loop 的“痴呆”设计哲学聊到代码审查的“心理折磨”。下文基于播客视频整理,经 InfoQ 编辑。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>太长不看版:</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Q:软件开发真的"不行"了吗?那我怎么办?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>A: </strong>任何人用上 Cursor 都能生成代码。如果你只把自己定义为"软件开发者",那现在人人都是了——你正在跟时薪 10.42 美元的岗位赛跑,<strong>麦当劳做汉堡都比这高</strong>。但"软件工程师"依然稀缺。区别在于:你能不能用 300 行代码构建一个 Coding Agent,并讲清楚它的架构?解释不清的话,你只是个"使用者",不是"构建者"。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>我们这一行之所以最先被 AI 冲击,恰恰因为它可以被机械地验证——软件要么编译通过,要么不通过。</strong>但模块化、数据建模、安全这些没法"一键验证"的硬核能力,才是真正的护城河。</p><p data-type="paragraph"><strong>Q:"工单猴子( JIRA ticket monkeys)"还有转型机会吗?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>A: </strong>有,但窗口期很短。技术不断变化,过去六个月的变化比过去三十年都多,员工用时间和技能换钱。如果你公司禁止用 AI,这本身就是危险信号——就像当年禁止上云一样,是在把你往死路上推。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Q:那我该重点学什么?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>A: </strong>三个方向优先级最高:首先是软件验证——代码生成已经免费了,但生成的东西对不对才是瓶颈。去了解 TLA+、Lean、Coq 这类定理证明器;再次是属性测试、确定性系统测试——比单元测试高一个维度;最后是类型系统更强的语言(Rust、Haskell)——无效数据根本建模不了,编译不过就拒绝幻觉,自然到不了代码审查环节。Python 和 Ruby 生成完不跑一遍你不知道会不会炸,验证成本太高。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Q:Ralph Loop 是什么?为什么都在聊它?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>A:</strong> Ralph 很简单:给一个目标,用最少的上下文,让它自回归地逼近结果,这是一种“痴呆”技术。最喜欢的用例是把一个开源项目从一种语言自动移植到另一种语言。比如.NET,转变成 Rust。但记住: Python、Rust、Go、TS 是"被祝福"的语言,而 Ruby、Java、.NET、Kotlin,前沿实验室根本不会自己内部去用这些。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Q:我该从哪开始?最紧急的一步是什么?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>A: 如果你不能在几个小时内重建 Cursor,你下次面试会非常艰难,因为那只是 300 行代码的一个 while 循环。</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>以下是原文:</strong></p><p data-type="paragraph"> </p><h2 data-type="heading" data-id="heading0">软件开发已死</h2><p data-type="paragraph"><strong>Geoffrey:</strong>软件开发已经死了(译者注:Geoffrey 在自己介绍这个 Loop 的博客里曾说过:“软件开发已死——是我亲手毁了它”),因为现在任何人都可以成为软件开发者,产品经理们也能直接“吐出”代码来。但你得区分清楚:你是“写代码的人(coder)”,还是“软件工程师(software engineer)”,这两者之间有天壤之别。很多人一直只是在蒙混过关,把编程等同于敲键盘,现在这部分工作已经被取代了。任何人只要用上 Cursor 或类似的工具,就能生成代码。而如果你把自己定义为“软件开发者(software developer)”,恭喜你,现在人人都是软件开发者了。你正在跟一个时薪只有 10.42 美元的岗位赛跑,拜托,在麦当劳做汉堡的时薪都比这高。</p><p data-type="paragraph"> </p><p data-type="paragraph">计算机一直以来都是有门槛的,你要么是那个学会让计算机“可塑”的人,学编程、学如何塑造它、让它服从你的意志,要么你就只能乖乖用别人给你的用户界面。过去 30 年里,绝大多数人都是后者。但现在,这个局面被彻底翻转了。他们现在拥有了让计算机变得可塑的能力,他们现在也是“软件开发者”了,但这绝不意味着他们是“软件工程师”。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:对我们这些过去一直深陷在“写代码”这件事里的软件开发者来说,还剩下什么可做的?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>如果你能称自己为“高级软件开发者”或“高级软件工程师”,那我问你:你能不能只用 300 行代码就给我构建一个 Coding Agent?能不能在白板上画出来,讲清楚它的架构?如果你根本解释不清这东西是怎么工作的,你只是一个消费者。</p><p data-type="paragraph"> </p><p data-type="paragraph"></p><p data-type="paragraph"></p><p data-type="paragraph">剩下可做的其实还有很多。软件模块化(modularity)、抽象(abstractions)、思考数据和数据库非常重要,身份验证、安全依然很难。但任何人都能随手生成东西了,这确实改变了游戏规则。对于那些还在纠结“我到底还有没有工作”的人,如果你保持好奇心,你就有工作。如果你在过去两年里没有保持好奇心,你就是可替代的。</p><p data-type="paragraph"> </p><h2 data-type="heading" data-id="heading1">K 型分化</h2><p data-type="paragraph"><strong>Hendrik:你昨天发表了一个关于“K 型分化”(K-shape)的演讲,我们正处在一条分岔路上,大家应该注意什么?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph">译者注:K 型分化,是 Geoffrey Huntley 在 AI:Engineer Miami 大会演讲中抛出的概念。如图所示,往右上角走的是模型优先公司,往右下角走的是还在抗拒 AI 的传统大公司。模型优先公司就像顶级掠食者,它们在潜空间中构建,人更少,可以像经典的初创公司那样更灵活。传统公司,通常不会担心初创公司,因为初创公司要花很长时间才能进入市场来攻击它。但在 K 型分化的概念中,随着模型、工作流、实践变得更好,运营得更精简,会得到“坡上加坡”的加速效应,时间线将被加速、被压缩。模型优先公司的收入数字,是指数级的,可以在利润率上碾压。</p><p data-type="paragraph"></p><p data-type="paragraph"></p><p data-type="paragraph">参考链接:<a href="https://www.youtube.com/watch?v=7Pkwv353DeI" title data-type="link">https://www.youtube.com/watch?v=7Pkwv353DeI</a></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>如果你的公司商业模式是 SaaS,按人头收费,你要明白,没有人知道未来会怎样,包括我自己。任何声称自己百分百确定未来走向的人,都是在吹牛。但我们百分百确定的是,现在完成同样的事情,你绝对需要更少的人。而如果你的公司靠向客户收费赚钱,那些客户也需要更少的人,那么你的收入基线就会变得非常不稳定,我们管这叫“遗留 SaaS”(legacy SaaS)。从财务角度来看,变化的不仅仅是我们的职业,整个单位经济模型已经变了。</p><p data-type="paragraph"> </p><p data-type="paragraph">现在创始人正在思考新的单位经济模型,比如,你能不能按“动作(action)”收费,而不是按人头收费?假设我们现在做的这期视频要被转录,你可以按转录次数收费,而不是按你的音视频团队有多少人来收费,或者按存储录像的每 GB 容量来收费,基于使用量的定价(utility-based pricing)正在成为新的趋势。</p><p data-type="paragraph"> </p><p data-type="paragraph">当我们进入 K 型分化时,公司需要两到三年时间来完成人员转型,搞清楚如何用 AI,甚至先要搞清楚 AI 对它们到底有没有用,很多公司正在强迫 AI 做它做不到的事。</p><p data-type="paragraph"> </p><p data-type="paragraph">与此同时,有一类新兴公司,它们只有五到十个人,正在顺着 AI 的趋势构建产品,它们天生就是 AI native 公司。</p><p data-type="paragraph"> </p><p data-type="paragraph"></p><p data-type="paragraph"><strong>Hendrik:我看到的未来是,我们会拥有更多的创业公司。我们现在有能力探索更多事情,构建更多东西。你觉得我们必须为一个拥有更多小公司、但每个公司规模更小的世界做好准备吗?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>这就要说到杰文斯悖论(Jevons Paradox)了。我认为软件开发者数量会爆炸性增长,因为现在人人都能当软件开发者。所以,软件工程师或开发者需要找到自己的区分度。软件开发本质上已经变得免费了,不过是些 token,而 token 比人便宜。但接下来往哪儿走?</p><p data-type="paragraph"> </p><p data-type="paragraph">现在创业比历史上任何时候都简单。但问题在于,不是每个人都适合当企业家,大多数软件工程师甚至不知道什么是产品工程师(product engineer)。如果他们不懂产品思维,就不可能成为好的创业者。这里有一个结构性障碍:如果你在一家遵循“丰田式 Spotify 敏捷流程”的公司工作,产品经理负责所有客户研究,工程师只负责给 Jira 工单估点数、写代码,如果你只是个“Jira 工单猴子(JIRA ticket monkeys)”,那你完蛋了。产品经理也一样,如果产品经理还在试图说服别人该建什么,他们也完蛋了,因为产品经理现在可以用 AI 做客户研究并直接构建产品。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:如果我现在就是个“工单猴子”,该怎么办?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>如果你在一家禁止使用 AI 的公司工作,你应该立刻辞职。我们这行一直是个“自动扶梯”,技术不断变化,过去六个月的变化比过去三十年都多,员工用时间和技能换钱。还记得当年有人因为公司不上云而离职吗?道理一样。AI 不是 IntelliJ 那样的工具,它更像一把吉他,你应该去弹它、去发现、去培养直觉:知道 AI 擅长什么、不擅长什么、在哪会翻车。如果你的公司禁止你学这个,你应该为了自己的职业生涯离开它。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:这让我想起,我在湾区计算机历史博物馆看到 1970 年代 IBM 的薪资表,软件工程师下面竟然还有“打孔卡冲压员”这个职位。你觉得软件工程师也会变成博物馆里的展品吗?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>我不确定,软件工厂(software factory)模式是否会持续存在,直到我们拥有更好的编程语言和形式化验证方法。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:但英语不就是现在的编程语言吗?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>不,我觉得数学正在成为真正的编程语言,我们终于要真正定义“工程”的含义了。软件工程师这个职位至少还会存在五到十年,我不认为它会马上像打孔卡冲压员一样消失。但有一点是绝对确定的:现在,软件开发,人人都能做。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:</strong>这有点像印刷术的发明,突然之间所有人都能读写和分发知识了。</p><h2 data-type="heading" data-id="heading2">Ralph Loop:内存管理,刻意遗忘</h2><p data-type="paragraph"><strong>Hendrik:</strong>聊聊你最近的成果,Ralph Loop。我现在就有一个 Claude bot 在 24/7 监督运行,帮我整合用户反馈到 Jira 工单,再触发 CodeRabbit 的规划工作流,循环到审查通过,然后把已解决的问题发布到 GitHub。<strong>你最喜欢 Ralph Loop 的哪些用例?我的方向对吗?</strong></p><p data-type="paragraph"> </p><p data-type="paragraph">译者注:Ralph Loop(拉尔夫循环)是 Geoffrey Huntley 提出的一种极简的 AI Agent 工作模式。名字来源于《辛普森一家》的角色 Ralph Wiggum,寓意是“最简单、最笨”的方法。它的核心做法是:为 Agent 分配一个单一的、明确的目标。将所有相关的上下文(规格、代码、审计历史等)“钉”在这个任务的周围,形成一个聚焦的上下文数组。然后让 Agent 在这个受控的边界内循环执行,直到完成目标。简单来说,Ralph Loop 就是把大语言模型有限的上下文窗口当作一个需要严苛管理的内存空间,通过给每个循环分配一个独立、聚焦的“内存阵列”,来换取高任务成功率和低认知负载。</p><p data-type="paragraph">参考链接:<a href="https://www.youtube.com/watch?v=zX_Wq9wAyxI" title data-type="link">https://www.youtube.com/watch?v=zX_Wq9wAyxI</a></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>Ralph Loop 的本质是内存管理。上下文窗口就是一堆内存,用得越多,性能越差,所以我让 LLM 自己决定什么最重要。一开始我像高指挥官一样定义所有事情,后来我只给它一个任务列表,让它自己选优先级。结果它居然能按正确的实现顺序来,比如先做日志系统和审计追踪,再处理数据库。这让我震惊:它有品味和判断力了。</p><p data-type="paragraph"> </p><p data-type="paragraph">Ralph 很简单:给一个目标,用最少的上下文,让它自回归地逼近结果,这是一种“痴呆”技术。别人都在搞复杂的 agent-to-agent 并行计算,我却用小的顺序循环,刻意遗忘、重新分配目标和上下文,效果惊人地好。它不完美,有漏洞,但它是增量的进步。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:</strong>当我在 Claude Code 上尝试这个概念时,我印象非常深刻。我产品的第一次迭代有大约 300-400 个用户。周末跑完 Ralph Loop 回来,发现登录按钮不好使之类的好多小问题都被修了。虽然不是大的架构问题,但效果很惊艳。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>我最喜欢的用例是把一个开源项目从一种语言自动移植到另一种语言。我会把源码给它,让它把源码缩减成产品经理式的规格说明和测试用例,然后告诉它创建一个查找表,再直接说“这是.NET,我要它变成 Rust”,然后扔 tokens 进去。我认为它改变了很多事情,比如,人们通常因为大的开源生态生态系统而采用某样东西,选择具有正确健全性、正确高级别能力、易于验证的工具或编程语言。但我不再关心这个了,对于边缘、小众的东西,比如,你想用 OCaml?尽管用。以前大家说 OCaml 开源生态不够大,现在无所谓,你直接生成就行。Ruby 的库好?缩减一下,现在 OCaml 里也有了。</p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Hendrik:但训练数据还是偏向流行框架吧?比如 Gemini 生成 Web 应用会选 React 而不是 Angular。</strong></p><p data-type="paragraph"> </p><p data-type="paragraph"><strong>Geoffrey:</strong>我同意,这就像木工活,要顺着木纹走,不要逆着木纹干。比如用 OCaml,训练数据较少,但质量非常高。但如果你想做 Web,就会有点困难,你必须做上下文工程,比如"这是我的 OCaml 自定义框架如何工作的",才能得到一个 Web 应用。而如果你直接说“我想要一个网站”,出来的就是一堆垃圾。现在 Python、Rust、Golang、TypeScript 算是“被祝福”的语言,因为前沿实验室在用它们做自主软件开发,软件、模型都自己构建自己,它们在“dog fooding(内部自用)”这些语言。而 Ruby、Java、.NET、Kotlin,前沿实验室根本不会自己内部去用这些,只是 benchmark 里的一个数字,所以选择实验室自己用的语言有战略优势。</p><h2 data-type="heading" data-id="heading3">代码审查是“心理折磨”</h2><p data-type="paragraph"><strong>He