一个在山羊农场养羊的工程师,用五行代码造了一门编程语言
一个在山羊农场养羊的工程师,用五行代码造了一门编程语言工程师与PM的未来 本文讨论了在山羊农场养羊的工程师 Geoffrey Huntley 用五行代码造出一门编程语言 CURSED 的故事，以及其背后的 Ralph Wiggum Loop 技术对产品经理（PM）工作的启示，关键要点包括： 1.工程师背景与经历：Geoffrey Huntley 有在 Optiver 和 Canva 工作的履历，后因感情破裂去养羊，同时远程做技术咨询和教育。 2.创造编程语言：他用五行 Bash 脚本，通过 Ralph Wiggum Loop 技术，花三个月造出 CURSED 编程语言，花费 14000 美元（单版本约 5000 美元），有 1198 个 commit、完整编译器和测试套件，支持多平台。 3.任务交付思维模型：Ralph loop 本质是任务交付思维模型，即设计能快速发现和纠正错误的循环，而非追求开始前计划完美。 4.循环有效运转条件：一是有明确“错了”信号，如编程里的编译器报错等；二是反馈速度决定一切，应缩短反馈回路；三是写清楚“完成”标准比“怎么做”更重要。 5.应对不确定性：Ralph loop 虽有不确定性，但可将系统设计成不依赖单次成功，降低出错代价，使“快速试错”成为可操作策略。 6.能力价值转变：写代码能力贬值，设计循环能力升值，PM 需准确写需求文档、清晰定义成功标准。 7.PM 工作重点：在新分工里，定义问题、设计循环和判断循环停止时机是 PM 更重要的工作。 "设计一个能快速发现错误、快速纠正的循环，然后让它跑。"而非追求开始前计划完美。 他是谁，为什么值得听他说话 Geoffrey Huntley 不是一个典型的硅谷布道者。他的职业履历不差——在 Optiver（全球顶级高频交易公司）做过技术负责人，在 Canva（澳大利亚最大科技独角兽）领导过开发者工具团队。两家公司对系统可靠性的要求都极高：交易系统的延迟以微秒计，Canva 的用户量以千万计。这种背景意味着他对"系统在压力下会不会崩"这件事有很深的直觉。但 2019 年底，他的长期感情关系破裂。他自己的原话是："整个经历让我粉碎、灵魂被摧毁、倦怠到了极点。"他去露营，去丛林，遇到了一群长期住在厢型车里的人，沿着大洋路一路开到南澳大利亚，最后在袋鼠岛上买了一块地——首付是用开源社区的捐款支付的。他在那里开了一个叫 Jean-Paul Goatier 的山羊农场（名字在恶搞法国时装设计师 Jean-Paul Gaultier），同时远程做技术咨询和教育。这段经历解释了他为什么说话不留情面、不考虑职业形象——他已经把那套东西丢掉过一次了。然后 AI 编码工具出现了，他做了一件让整个技术社区都在讨论的事。 Ralph Wiggum 循环的诞生 Huntley 写了一个五行的 Bash 脚本（Bash 脚本是一种让电脑自动执行一系列操作的脚本文件）： while true; do ? cat PROMPT.md | claude ? git add -A && git commit -m "ralph loop iteration" done 翻译成大白话：把一个写好的任务描述文件反复喂给 Claude，每次 Claude 产出的代码自动保存，下一轮循环时 Claude 能看到自己上一轮写的内容——包括错误——然后继续。如此反复，直到任务完成或者你手动停止。他用这个循环造了一门叫 CURSED 的编程语言。 CURSED 用 Gen Z 俚语做关键词：slay 是函数声明，sus 是变量定义，bestie 是 while 循环，damn 是 return，文件后缀是 .?。 结果是认真的：1198 个 commit，一个完整的编译器，17 道 LeetCode 题作为测试套件，支持 macOS、Linux、Windows 三个平台。总 API 费用 14000 美元。如果只做一个语言版本，大约 5000 美元。 
这个技术他命名为 Ralph Wiggum Loop，取自《辛普森一家》里那个又蠢又乐观、不知疲倦的角色。Anthropic 的 Claude Code 产品负责人 Boris Cherny 后来把它做成了官方插件。 Ralph loop 作为任务交付思维模型 很多人看到这里的反应是：这跟我有什么关系？我又不写代码。但 Ralph loop 的本质不是一个编程技巧，而是一个任务交付的思维模型：与其花大量时间在开始前把计划做到完美，不如设计一个能快速发现错误、快速纠正的循环，然后让它跑。这个思维模型对 PM 的工作同样适用——需求文档、产品迭代、用户测试的设计逻辑，本质上都是在问：我的反馈回路有多快？我怎么知道自己跑偏了？Huntley 从 CURSED 的经验里总结出三个条件，让循环有效运转： 第一，必须有一个明确的"错了"信号。?编程里这个信号是编译器报错和测试不过。对 PM 来说，这个信号是什么？可能是数据指标，可能是用户访谈里某句话反复出现，可能是开发说"这个需求写不了"。信号越明确，纠偏越快。最怕的状态是：做了三个月，最后发现方向错了，但中间没有任何时刻有明确的错误信号。 第二，反馈速度决定一切。?Huntley 的原话是："如果你的构建要五分钟，agent 就会在那五分钟里做出错误的判断。"换到产品语境：如果你的用户反馈要三个月才能回来，你就会在那三个月里做出大量基于错误假设的决策。缩短反馈回路——哪怕是粗糙的快速测试——比做出精确的长期计划更有价值。 第三，写清楚"完成"长什么样，比写清楚"怎么做"更重要。?CURSED 的任务文件 PROMPT.md 里最核心的不是操作步骤，而是成功标准——测试通过、功能完整、有文档。Claude 自己决定怎么实现。对 PM 来说：当你给工程师或设计师交代任务时，你描述的是结果标准还是执行步骤？如果是后者，你可能在替对方做了本该由他们做的判断，同时失去了他们可能带来的更好方案。 外界对 Ralph loop 最常见的批评是：循环的不确定性太高，agent 可能在死胡同里浪费大量资源，你醒来发现一晚上什么有用的也没产出。Huntley 的回答值得认真对待： "That's the beauty of Ralph — the technique is deterministically bad in an undeterministic world." 意思是：这个方法承认失败会发生，然后把系统设计成不依赖单次成功。当一次迭代的成本只有几美分时，浪费一千次也不过几十美元。问题不在于会不会出错，而在于出错的代价是否低到可以被预算进去。 这个逻辑对 PM 的职业成长同样适用。很多 PM 在推动一件不确定的事时，会花大量时间在前期论证上，试图在开始之前就证明它值得做——因为失败的成本太高，一次失败会影响评价。但如果你能把一次尝试的成本足够压低（时间、资源、政治风险），"快速试错"就不再是口号，而是可操作的策略。真正的问题不是"这件事会不会成"，而是"如果不成，我需要付出多大代价才能知道"。 同期，OpenAI 的工程师 Ryan Lopopolo 用一套复杂的多 agent 协调系统做到了类似的事：几十个 AI 并行工作，六层架构，有专门负责审查的 agent 和专门负责执行的 agent。系统复杂，但可靠性更高，适合企业级场景。 把两者放在一起，你会看到同一个结论从两个方向被验证：写代码本身在贬值，设计循环的能力在升值。?知道什么问题值得解决，知道成功标准应该长什么样，知道怎么把这些转化成可执行的指令——这才是稀缺的。这对 PM 来说既是机会也是压力：AI 工具正在把"需求不清晰"的代价放大。以前工程师可以在执行过程中靠经验填补需求的模糊地带，现在 agent 会按字面意思执行，或者在模糊地带里反复打转。需求文档写得越准确、成功标准定义得越清晰，工具才越有用。Huntley 花了一个月才发现自己的语言规范里有一个关键词被矛盾地定义了两次。在那一个月里，agent 反复在这个矛盾上打转，浪费了大量循环。他的反思是："很容易怪工具，但问题出在操作者身上。"这句话用来描述 PM 和工程团队的协作关系，同样成立。 当一个在山羊农场养羊的人，用 5000 美元造出了以前需要一支专业团队数年才能完成的编译器——真正值得追问的不是"AI 会不会取代工程师"，而是：在这个新的分工里，谁来定义问题，谁来设计循环，谁来判断什么时候循环该停？这三件事，一直都是 PM 的工作。只是现在，它们变得比以前重要得多了。 名词速查表 Bash 脚本?让电脑自动按顺序执行一系列操作的指令文件。就像你写了一张清单，电脑照着清单一条一条执行，不需要你每次手动操作。 Git / Git 仓库?一个代码的版本管理工具。每次改动代码，Git 都会留下记录，可以随时回到之前任意一个版本。仓库（repository）就是存放这些代码和记录的地方。 Commit?在 Git 里，每次把改动正式保存下来的动作叫一次 commit。1198 个 commit 意味着这个项目经历了 1198 次有记录的改动。 编译器?把人写的代码翻译成电脑能直接执行的语言的程序。就像把中文翻译成机器能读懂的二进制指令。 LLVM?一套用来构建编译器的基础工具。很多编程语言（比如 Rust、Swift）背后都用了它。CURSED 能编译成在电脑上直接运行的程序，依赖的就是 LLVM。 测试套件?一组预先写好的测试案例，用来验证代码是否按预期工作。跑一遍测试套件，就知道哪里通过了、哪里出问题了。 API 费用?调用 AI 服务（比如 Claude）时按使用量付的费用。每发送一段文字、每收到一段回复，都会产生对应的计费。 Agent?在 AI 语境里，agent 指能自主执行任务的 AI 程序——不只是回答问题，而是能主动采取行动、使用工具、根据结果调整下一步。 多 agent 协调系统?多个 AI agent 同时工作，由一个上层系统分配任务、协调配合。类似一个项目组，组长负责拆解任务，不同组员并行执行不同部分。 反馈回路?从"做了一件事"到"知道这件事做得对不对"之间的时间和路径。回路越短，纠错越快；回路越长，跑偏越久才能发现。 开源社区?由全球开发者自愿参与、共同维护的软件项目生态。代码公开，任何人都可以使用、贡献和改进。 需求文档?产品经理（PM）用来描述"要做什么、为什么做、做成什么样"的文件，是工程师和设计师开工的依据。 Huntley 文章里说："很容易怪工具，但问题出在操作者身上。"他说的是 AI agent 在一个矛盾的规范里反复打转，浪费了一个月。但这句话精准地描述了我见过的几乎每一次产品失败的深层原因——不是团队不努力，是问题定义本身就有漏洞，然后所有人在那个漏洞里内耗。 回顾：三条线索，一件正在发生的事 第一条线索，是工具在加速，但瓶颈在转移。过去二十年，软件开发的瓶颈一直在"怎么写代码"——工程师是稀缺资源，写代码慢、贵、容易出错。AI 编码工具的出现，正在把这个瓶颈向上移：代码越来越便宜，但"写清楚要做什么"越来越贵。就像印刷术普及之后，抄写员不稀缺了，但编辑和作者反而更值钱。 第二条线索，是个人生产力的天花板在抬高。Huntley 一个人，五行脚本，三个月，造出了一门有完整编译器的编程语言。这在五年前是一支专业团队的体量。不只是软件行业——这件事意味着一个人能独立完成的工作边界，正在被系统性地扩大。《钢铁侠》里托尼·斯塔克靠一套 AI 助手管理整个实验室，现在这件事在现实里开始有了低配版本。 第三条线索，是"设计循环"这件事从工程专属变成了通用能力。Ralph loop 的核心不是代码，是一个思维模式：定义清楚什么叫成功，设计一个能快速发现错误的机制，然后让它跑。这个逻辑在产品迭代、运营策略、组织管理里同样成立。以前只有工程师需要想"我的反馈回路有多快"，现在这个问题变成了每个职能都该问的基本功。 展望：两件我比较确定会发生的事 第一件，PM 的核心竞争力会从"沟通协调"转向"问题定义"。这不是说沟通不重要，而是说：当 AI 能承担越来越多的执行工作，人和 AI 之间最关键的接口，就是你怎么描述你想要什么。描述得模糊，AI 会按自己的理解跑，结果可能离你想要的很远；描述得精准，AI 就是一个不知疲倦、不会情绪化的执行者。这个能力，以前叫"写好 PRD"，未来可能叫别的名字，但本质没变：你得真的想清楚，才能说清楚。 第二件，"一个人的公司"会成为一种真实存在的商业形态，而不只是自由职业的浪漫化说法。Huntley 的 $297 完成 $50000 合同这件事，说明的不只是"省钱"，而是单个个体的生产力边界正在跨越某个临界点。当一个人能可靠地完成以前需要一个团队才能做的事，组织的边界就会重新被定义——不是所有公司都会变小，但"规模大"不再自动等于"能力强"。 试试另一种可能 
"这些变化并不是要把任何人替换掉。更准确的说法是：它在重新分配哪些事情值得人去做。" Huntley 在山羊农场养羊、写代码、跑循环——他选择的不是一种技术路径，而是一种生活方式下的工作方式。 这件事本身就在告诉我们，"工程师"这个词所指向的生活形态，正在比我们预期的更快地被重新书写。
Ralph Wiggum 循环的启示
五行代码，三个月，一门编程语言
PM 真正需要理解的那一层
不确定性不是缺陷，是前提
学这个有什么用
编者按
