“如果你不能用300行代码写个Cursor，这行你就别待了！”Ralph Loop创造者、Claude Code核心技术设计者的暴论

“软件开发已经死了，因为现在任何人都可以成为软件开发者。过去六个月的变化比过去三十年都多，而大多数工程师还在当 Jira 工单猴子，浑然不觉自己已经站在了悬崖边上。”

最近，Ralph Loop 的创造者 Geoffrey Huntley 在播客节目中与主持人 Hendrik Krack 展开了一场火花四溅的对话。

这套“痴呆但管用”的内存管理方法，如今已经被 Claude Code、Cursor、Copilot 等主流工具内置进去。

Ralph Loop 最早在 2025 年 7 月由 Geoffrey 提出，到 12 月前后开始在开发者社区发酵，并被 Claude Code 吸收到自己的 harness 里。它解决的问题是：当一个任务需要持续推进、反复检查、不断修正时，怎么让 agent 不要跑一轮就停下。

在原始 Ralph Loop 里，agent 会先规划、拆任务，再开启新的 session，用干净的上下文继续推进。Claude Code 后来则进一步改进了这个 Loop：它没有完全照搬这种多 session 方式，而是在单个 session 里加入循环机制，通过最大迭代次数、safe word 和 stop hook，让 Claude 在任务没完成时继续跑下去。也就是说 Ralph Loop 最重要的意义是把 coding agent 从一次性生成，推向了长时间运行。

在这次播客中，他们从“软件开发已死”的宣言聊到“K 型分化”下的职业生存法则，从 Ralph Loop 的“痴呆”设计哲学聊到代码审查的“心理折磨”。

下文基于播客视频整理，经 InfoQ 编辑。

太长不看版：

Q：软件开发真的”不行”了吗？那我怎么办？

A： 任何人用上 Cursor 都能生成代码。如果你只把自己定义为”软件开发者”，那现在人人都是了——你正在跟时薪 10.42 美元的岗位赛跑，麦当劳做汉堡都比这高。但”软件工程师”依然稀缺。区别在于：你能不能用 300 行代码构建一个 Coding Agent，并讲清楚它的架构？解释不清的话，你只是个”使用者”，不是”构建者”。

我们这一行之所以最先被 AI 冲击，恰恰因为它可以被机械地验证——软件要么编译通过，要么不通过。 但模块化、数据建模、安全这些没法”一键验证”的硬核能力，才是真正的护城河。

Q：”工单猴子（ JIRA ticket monkeys）”还有转型机会吗？

A： 有，但窗口期很短。技术不断变化，过去六个月的变化比过去三十年都多，员工用时间和技能换钱。如果你公司禁止用 AI，这本身就是危险信号——就像当年禁止上云一样，是在把你往死路上推。

Q：那我该重点学什么？

A： 三个方向优先级最高：首先是软件验证——代码生成已经免费了，但生成的东西对不对才是瓶颈。去了解 TLA+、Lean、Coq 这类定理证明器；再次是属性测试、确定性系统测试——比单元测试高一个维度；最后是类型系统更强的语言（Rust、Haskell）——无效数据根本建模不了，编译不过就拒绝幻觉，自然到不了代码审查环节。Python 和 Ruby 生成完不跑一遍你不知道会不会炸，验证成本太高。

Q：Ralph Loop 是什么？为什么都在聊它？

A： Ralph 很简单：给一个目标，用最少的上下文，让它自回归地逼近结果，这是一种“痴呆”技术。最喜欢的用例是把一个开源项目从一种语言自动移植到另一种语言。比如.NET，转变成 Rust。但记住： Python、Rust、Go、TS 是”被祝福”的语言，而 Ruby、Java、.NET、Kotlin，前沿实验室根本不会自己内部去用这些。

Q：我该从哪开始？最紧急的一步是什么？

A： 如果你不能在几个小时内重建 Cursor，你下次面试会非常艰难，因为那只是 300 行代码的一个 while 循环。

以下是原文：

软件开发已死

Geoffrey： 软件开发已经死了（ 译者注 ：Geoffrey 在自己介绍这个 Loop 的博客曾说过：“软件开发已死——是我亲手毁了它”）因为现在任何人都可以成为软件开发者，产品经理们也能直接“吐出”代码来。但你得区分清楚：你是“写代码的人（coder）”，还是“软件工程师（software engineer）”，这两者之间有天壤之别。很多人一直只是在蒙混过关，把编程等同于敲键盘，现在这部分工作已经被取代了。任何人只要用上 Cursor 或类似的工具，就能生成代码。而如果你把自己定义为“软件开发者（software developer）”，恭喜你，现在人人都是软件开发者了。你正在跟一个时薪只有 10.42 美元的岗位赛跑，拜托，在麦当劳做汉堡的时薪都比这高。

计算机一直以来都是有门槛的，你要么是那个学会让计算机“可塑”的人，学编程、学如何塑造它、让它服从你的意志，要么你就只能乖乖用别人给你的用户界面。过去 30 年里，绝大多数人都是后者。但现在，这个局面被彻底翻转了。他们现在拥有了让计算机变得可塑的能力，他们现在也是“软件开发者”了，但这绝不意味着他们是“软件工程师”。

Hendrik：对我们这些过去一直深陷在“写代码”这件事里的软件开发者来说，还剩下什么可做的？

Geoffrey： 如果你能称自己为“高级软件开发者”或“高级软件工程师”，那我问你：你能不能只用 300 行代码就给我构建一个 Coding Agent？能不能在白板上画出来，讲清楚它的架构？如果你根本解释不清这东西是怎么工作的，你只是一个消费者。

剩下可做的其实还有很多。软件模块化（modularity）、抽象（abstractions）、思考数据和数据库非常重要，身份验证、安全依然很难。但任何人都能随手生成东西了，这确实改变了游戏规则。对于那些还在纠结“我到底还有没有工作”的人，如果你保持好奇心，你就有工作。如果你在过去两年里没有保持好奇心，你就是可替代的。

K 型分化

Hendrik：你昨天发表了一个关于“K 型分化”（K-shape）的演讲，我们正处在一条分岔路上，大家应该注意什么？

译者注：K 型分化，是 Geoffrey Huntley 在 AI:Engineer Miami 大会演讲中抛出的概念。如图所示，往右上角走的是模型优先公司，往右下角走的是还在抗拒 AI 的传统大公司。模型优先公司就像顶级掠食者，它们在潜空间中构建，人更少，可以像经典的初创公司那样更灵活。传统公司，通常不会担心初创公司，因为初创公司要花很长时间才能进入市场来攻击它。但在 K 型分化的概念中，随着模型、工作流、实践变得更好，运营得更精简，会得到“坡上加坡”的加速效应，时间线将被加速、被压缩。模型优先公司的收入数字，是指数级的，可以在利润率上碾压。

参考链接：https://www.youtube.com/watch?v=7Pkwv353DeI

Geoffrey： 如果你的公司商业模式是 SaaS，按人头收费，你要明白，没有人知道未来会怎样，包括我自己。任何声称自己百分百确定未来走向的人，都是在吹牛。但我们百分百确定的是，现在完成同样的事情，你绝对需要更少的人。而如果你的公司靠向客户收费赚钱，那些客户也需要更少的人，那么你的收入基线就会变得非常不稳定，我们管这叫“遗留 SaaS”（legacy SaaS）。从财务角度来看，变化的不仅仅是我们的职业，整个单位经济模型已经变了。

现在创始人正在思考新的单位经济模型，比如，你能不能按“动作（action）”收费，而不是按人头收费？假设我们现在做的这期视频要被转录，你可以按转录次数收费，而不是按你的音视频团队有多少人来收费，或者按存储录像的每 GB 容量来收费，基于使用量的定价（utility-based pricing）正在成为新的趋势。

当我们进入 K 型分化时，公司需要两到三年时间来完成人员转型，搞清楚如何用 AI，甚至先要搞清楚 AI 对它们到底有没有用，很多公司正在强迫 AI 做它做不到的事。

与此同时，有一类新兴公司，它们只有五到十个人，正在顺着 AI 的趋势构建产品，它们天生就是 AI native 公司。

Hendrik：我看到的未来是，我们会拥有更多的创业公司。我们现在有能力探索更多事情，构建更多东西。你觉得我们必须为一个拥有更多小公司、但每个公司规模更小的世界做好准备吗？

Geoffrey： 这就要说到杰文斯悖论（Jevons Paradox）了。我认为软件开发者数量会爆炸性增长，因为现在人人都能当软件开发者。所以，软件工程师或开发者需要找到自己的区分度。软件开发本质上已经变得免费了，不过是些 token，而 token 比人便宜。但接下来往哪儿走？

现在创业比历史上任何时候都简单。但问题在于，不是每个人都适合当企业家，大多数软件工程师甚至不知道什么是产品工程师（product engineer）。如果他们不懂产品思维，就不可能成为好的创业者。这里有一个结构性障碍：如果你在一家遵循“丰田式 Spotify 敏捷流程”的公司工作，产品经理负责所有客户研究，工程师只负责给 Jira 工单估点数、写代码，如果你只是个“Jira 工单猴子（JIRA ticket monkeys）”，那你完蛋了。产品经理也一样，如果产品经理还在试图说服别人该建什么，他们也完蛋了，因为产品经理现在可以用 AI 做客户研究并直接构建产品。

Hendrik：如果我现在就是个“工单猴子”，该怎么办？

Geoffrey： 如果你在一家禁止使用 AI 的公司工作，你应该立刻辞职。我们这行一直是个“自动扶梯”，技术不断变化，过去六个月的变化比过去三十年都多，员工用时间和技能换钱。还记得当年有人因为公司不上云而离职吗？道理一样。AI 不是 IntelliJ 那样的工具，它更像一把吉他，你应该去弹它、去发现、去培养直觉：知道 AI 擅长什么、不擅长什么、在哪会翻车。如果你的公司禁止你学这个，你应该为了自己的职业生涯离开它。

Hendrik：这让我想起，我在湾区计算机历史博物馆看到 1970 年代 IBM 的薪资表，软件工程师下面竟然还有“打孔卡冲压员”这个职位。你觉得软件工程师也会变成博物馆里的展品吗？

Geoffrey： 我不确定，软件工厂（software factory）模式是否会持续存在，直到我们拥有更好的编程语言和形式化验证方法。

Hendrik：但英语不就是现在的编程语言吗？

Geoffrey： 不，我觉得数学正在成为真正的编程语言，我们终于要真正定义“工程”的含义了。软件工程师这个职位至少还会存在五到十年，我不认为它会马上像打孔卡冲压员一样消失。但有一点是绝对确定的：现在，软件开发，人人都能做。

Hendrik： 这有点像印刷术的发明，突然之间所有人都能读写和分发知识了。

Ralph Loop：内存管理，刻意遗忘

Hendrik： 聊聊你最近的成果，Ralph Loop。我现在就有一个 Claude bot 在 24/7 监督运行，帮我整合用户反馈到 Jira 工单，再触发 CodeRabbit 的规划工作流，循环到审查通过，然后把已解决的问题发布到 GitHub。你最喜欢 Ralph Loop 的哪些用例？我的方向对吗？

译者注：Ralph Loop（拉尔夫循环）是 Geoffrey Huntley 提出的一种极简的 AI Agent 工作模式。名字来源于《辛普森一家》的角色 Ralph Wiggum，寓意是“最简单、最笨”的方法。它的核心做法是：为 Agent 分配一个单一的、明确的目标。将所有相关的上下文（规格、代码、审计历史等）“钉”在这个任务的周围，形成一个聚焦的上下文数组。然后让 Agent 在这个受控的边界内循环执行，直到完成目标。简单来说，Ralph Loop 就是把大语言模型有限的上下文窗口当作一个需要严苛管理的内存空间，通过给每个循环分配一个独立、聚焦的“内存阵列”，来换取高任务成功率和低认知负载。

参考链接：https://www.youtube.com/watch?v=zX_Wq9wAyxI

Geoffrey：Ralph Loop 的本质是内存管理。上下文窗口就是一堆内存，用得越多，性能越差，所以我让 LLM 自己决定什么最重要。一开始我像高指挥官一样定义所有事情，后来我只给它一个任务列表，让它自己选优先级。结果它居然能按正确的实现顺序来，比如先做日志系统和审计追踪，再处理数据库。这让我震惊：它有品味和判断力了。

Ralph 很简单：给一个目标，用最少的上下文，让它自回归地逼近结果，这是一种“痴呆”技术。别人都在搞复杂的 agent-to-agent 并行计算，我却用小的顺序循环，刻意遗忘、重新分配目标和上下文，效果惊人地好。它不完美，有漏洞，但它是增量的进步。

Hendrik： 当我在 Claude Code 上尝试这个概念时，我印象非常深刻。我产品的第一次迭代有大约 300-400 个用户。周末跑完 Ralph Loop 回来，发现登录按钮不好使之类的好多小问题都被修了。虽然不是大的架构问题，但效果很惊艳。

Geoffrey： 我最喜欢的用例是把一个开源项目从一种语言自动移植到另一种语言。我会把源码给它，让它把源码缩减成产品经理式的规格说明和测试用例，然后告诉它创建一个查找表，再直接说“这是.NET，我要它变成 Rust”，然后扔 tokens 进去。我认为它改变了很多事情，比如，人们通常因为大的开源生态生态系统而采用某样东西，选择具有正确健全性、正确高级别能力、易于验证的工具或编程语言。但我不再关心这个了，对于边缘、小众的东西，比如，你想用 OCaml？尽管用。以前大家说 OCaml 开源生态不够大，现在无所谓，你直接生成就行。Ruby 的库好？缩减一下，现在 OCaml 里也有了。

Hendrik：但训练数据还是偏向流行框架吧？比如 Gemini 生成 Web 应用会选 React 而不是 Angular。

Geoffrey： 我同意，这就像木工活，要顺着木纹走，不要逆着木纹干。比如用 OCaml，训练数据较少，但质量非常高。但如果你想做 Web，就会有点困难，你必须做上下文工程，比如”这是我的 OCaml 自定义框架如何工作的”，才能得到一个 Web 应用。而如果你直接说“我想要一个网站”，出来的就是一堆垃圾。现在 Python、Rust、Golang、TypeScript 算是“被祝福”的语言，因为前沿实验室在用它们做自主软件开发，软件、模型都自己构建自己，它们在“dog fooding（内部自用）”这些语言。而 Ruby、Java、.NET、Kotlin，前沿实验室根本不会自己内部去用这些，只是 benchmark 里的一个数字，所以选择实验室自己用的语言有战略优势。

代码审查是“心理折磨”

Hendrik：你提到，你不再相信代码审查了。怎么回事？

Geoffrey： 我相信也不相信，关键在于我们怎么做。我一直在思考，应该采用一种基于风险分级的方法来决定是否需要代码审查。现在的情况是非黑即白：你做了一个改动，就得追着同事到处跑，让他们给你“打勾、打勾、打勾”，这到底给业务带来了什么价值？很多时候，我们使用代码审查的方式，不幸的是变成了对同事的骚扰和霸凌，往往价值极低。

Hendrik： 我得反驳一下，代码审查有学习价值，尤其是对初级工程师。

Geoffrey： 是有，但你跟初级工程师聊聊，他们会说他们被批得体无完肤。它本应是指导，但指导并没有发生在代码审查中。全是吹毛求疵，那根本不是学习，是心理折磨。当然不是所有公司都这样，但我们确实没有用好代码审查。它本应是指导，但并没有做到。

最好的代码审查方式一直是：尽早打开一个变更（CL），然后持续进行代码审查，堆叠 PR（stack PRs），在每个增量上做审查，这才是指导型的方法。但看看所有企业或公司，代码审查实际上已经变成了一个“橡皮图章”，人们追着同事说“快给我盖章、盖章、盖章”。它被奉为不可侵犯的神圣之物，但我们都知道它只是个幌子。不过它还是有价值的，因为它能捕捉回归缺陷。

所以，我希望改变代码审查的方式：默认不进行代码审查。如果有人要更新营销文案，直接发布，它只是文本。对于网站，发布。国际化、翻译，发布。但如果是更关键的东西，比如给数据库加索引，那就需要代码审查。这就像值班（on-call）的哲学：如果半夜寻呼（paged）叫醒一个工程师，它应该链接到一个运行手册，里面有明确的指示需要做什么。整个目标实际上是最小化发送给你团队的寻呼数量，因为这被视为需要作为工程严谨性来完成的事情，但我们需要最小化我们做它的次数。而在代码审查中，没有人会想：”我们如何最小化我们做的代码审查数量？”

如果代码审查是基于变更类型的风险分类触发的呢？或者可以触发一个 Agent，自动通知相关同事：“我跑了这段代码路径几次，关于认证这块，我觉得可以，但可能不够，让我们听听第二意见。”随着模型越来越好，我们完全可以多跑几轮代码路径，检查安全和其他问题。我们可以做一些事情来减少代码审查，或者重塑我们对代码的思考方式，我们需要对发布的内容负责。我绝不是说我们需要完全的 YOLO，“永远不做代码审查”之类的，我只是认为我们应该有意识地思考，如何通过工程化来消除对代码审查的需求，从而最小化需要代码审查的次数。

Hendrik：那你的升级方案是什么？上次 AI 工程大会上，我和 Max Kanat-Alexander 聊过，他非常推崇代码审查，并把通过代码审查进行指导的做法奉为圭臬。如果我们按你设想的那样“废除”代码审查，你打算如何向初级工程师和即将到来的新一代传递知识？

Geoffrey： 现在很多组织正在强行把 AI 塞进工作流，他们嘴上不说，但员工能感觉到“不用 AI 就滚蛋”。这制造了一种焦虑：人们觉得自己在使用 AI 这件事上被审判。

我亲眼见过这种场景，我们在一家公司推出了一个功能：所有人的 prompt 都是公开可见的。起初效果非常好，大家互相分享“如何拨弄 LLM 这把乐器才能弹出好曲子”，分享的是技巧，而不是结果，这是一种很棒的知识共享。但绩效评估季一到，所有人都慌了。每个人都在拼命写绩效文档，AI 使用突然变成了“强制任务”，焦虑瞬间蔓延。最后我们不得不关掉这个功能。

修复这种指导式的“师徒”关系是有方法的，其中一个是自动与同事共享 prompt，并建立“prompt 治理”机制。就像软件物料清单一样，每次代码增量提交时，把用到的 prompt 也“盖章”上去。但前提是必须有心理安全感，人们得愿意分享。而现在的问题是，人们害怕自己被评判，害怕自己“AI 用得不够好”，而 AI 本身又在飞速变化，没人知道什么才算“足够好”，这整个系统是破碎的。

用语音输入让创造力流淌

Hendrik：以前我会花很多时间精心打磨 prompt，但现在我发现，用 Whisper Flow 这类语音输入工具，直接把自己的想法“碎碎念”进去，效果反而更好。你觉得呢？

Geoffrey：Whisper Flow 或者任何语音输入，绝对是上帝模式。我想让大家思考一件事：当你写作时，你通常有“写作模式”和“编辑模式”两种状态。你写一封邮件，但不会立刻发送，你需要时间和空间来思考。问题是，“先写后改”是一项需要学习的技能，尤其是刚开始做内容创作、公开演讲和写作的人。而大多数人在打字时，会把“写作”和“编辑”同时进行：打一个字，“不对，不是这个词，换一个”。他们陷入了高度控制循环，这极大地限制了创造力的流动。

而语音输入完全打破了这种限制。我会对 Claude 说：“去看看这个组件的 HTTP 库，研究一下它。”然后继续说：“现在我想做一个集成到零的东西。去研究一下我们所有的客户端。这个零客户端需要用到我们的 HTTP 客户端。我需要你构建它，但在我喊‘动工’之前不许动手。”接着我会开始一个规划会话，来回推演，像揉面团一样探索它理解了什么。如果它不理解代码库的某个部分，我会说：“想搞清楚这个 HTTP 客户端怎么做重试？我们有单独的 HTTP 重试库，别自己编。”整个对话过程就是我的 prompt，用语音输入，你更富有表现力，产出也更好，因为它剥离了“编辑模式”。

Hendrik：对于那些处在“K 型”曲线顶端、走在好奇探索路径上的人，他们该怎么做才能保持领先？

Geoffrey： 软件验证。

Hendrik： 所以我构建的所有东西都必须附带单元测试、端到端测试……

Geoffrey： 甚至更多。如果你想站在 K 型曲线的最顶端，你应该去玩一玩 TLA+、Lean 和 Coq，学习什么是定理证明器、如何验证软件。去思考，如果我们拥有更强大、验证更严谨的编程语言，就能最大限度地减少代码审查和人工干预。你可以搞单元测试，但如果你想站在最顶端，你应该研究属性测试、确定性系统测试这些高阶主题。因为代码生成问题已经解决了，但生成的东西是不可验证的。

如果你能用不同的技术或更强大的工具解决验证问题，你就能比那些还在搞软件工厂或用 Python 写“Gas Town”的人获得更好的结果。我不是在抨击 Python，但从类型理论的角度看，它不是一个严谨的语言。你用 Python 生成代码，不跑一遍你不知道它会不会炸，Ruby 也一样，这意味着幻觉的验证成本更高。而像 Rust、Haskell 这类语言，无效数据根本无法建模，它编译不过，就会拒绝幻觉，生成周期就无法完成，无法提交 git，自然也就到不了代码审查环节。

Hendrik：在结束之前，还有什么其他建议或分享吗？

Geoffrey： 我现在正在做 Latent Patterns，一个教育平台，教大家基础知识。比如，“上下文窗口本质上就是一个来回传递的数组”、“子 Agent 就是一块可丢弃的内存堆”等等第一性原理，重点是教大家：AI 时代计算机科学的 CS 101 是什么？CS 102、103 又是什么？

我的建议是：现在就去自己构建一个 Agent。如果你不能在几个小时内重建 Cursor，你下次面试会非常艰难，因为那只是 300 行代码的一个 while 循环。几周前在立陶宛的 PyCon 上，一个 13 岁的孩子在现场展示了自己搭建的 Coding Agent，把所有资深工程师都震住了。如果你是个资深工程师，却不能从底层解释 AI 和重建 Cursor，那你就不再是资深工程师了，你是初级工程师。资深工程师应该保持好奇，理解引擎的每个部件，并且能重建整个引擎。

Hendrik： 我觉得这就是为什么 Dario Amodei 说过那句名言：软件和软件生成之所以遥遥领先，是 AI 最先解决的领域，因为软件工程师一直是劳动力中最好奇的一群人。

Geoffrey： 对，但能真正解释清楚这些东西的人数低得惊人。而现在市场对懂得这些并能教会别人的人，需求高得离谱。我们这一行之所以能最先被 AI 解决，是因为它可以被机械地验证——软件要么编译通过，要么不通过。现在我们有代码审查，是因为它编译通过了，但没实现该实现的功能，或者有 bug。如果我们能把所有状态建模成不可能编译通过的状态，就能减少代码审查的数量。

访谈视频原链接：https://www.youtube.com/watch?v=fbqAh46eMkc

其他相关链接：

https://ghuntley.com/loop/