如果你最近看过我的社交账号，你可能看到我讨论过 Ralph，并且好奇 Ralph 是什么。Ralph 是一种技术。最纯粹的形式，Ralph 就是一个 Bash 循环。
while :; do cat PROMPT.md | npx --yes @sourcegraph/amp
Ralph 可以取代大多数公司在新建项目中的大部分外包工作。它存在缺陷，但这些缺陷可以通过各种类型的提示来识别和解决。这就是 Ralph 的魅力所在——在一个不确定的世界里，它注定是糟糕的。
Ralph 可以使用任何不限制工具调用和使用的工具（即Amp ）来完成。
Ralph 目前正在开发一种全新的编程语言。我们正处于一种全新的、可用于生产的深奥编程语言发布的最后冲刺阶段。令我感到不可思议的是，Ralph 不仅能够开发出这种语言，而且还能在 LLM 的训练数据集中不使用该语言进行编程。
Amp 创建了一种新的编程语言 AFK https://t.co/KmmOtHIGK4
— geoff (@GeoffreyHuntley) 2025年7月13日
使用 Ralph 开发软件需要极大的信心，并且要坚信最终一致性。Ralph 会考验你。每次 Ralph 在开发《CURSED》时走错方向，我都不会责怪工具，而是会反思自身。每次 Ralph 出错，Ralph 都会像吉他一样被调音。
游戏一开始没有游乐场，拉尔夫接到指示要搭建一个游乐场。拉尔夫很擅长搭建游乐场，但他回家时却因为从滑梯上摔下来而伤痕累累。于是有人在滑梯旁边加了一个牌子，上面写着“滑下去，不要跳，四处看看”，以此来调侃拉尔夫，结果拉尔夫更有可能看到这个牌子。
最终，拉尔夫所想的只是这些迹象，所以那时你就得到了一个新的拉尔夫。
我在旧金山国际机场工作的时候，教过一些聪明人如何使用 Ralph。一位才华横溢的工程师听了之后，在下一份合同中使用了 Ralph，获得了极高的投资回报率。如今，他们满脑子想的都是 Ralph。
来自我的 iMessage
（经许可分享）
合同成本为 5 万美元，已交付，已进行 MVP 测试，已通过@ampcode审核。
297美元。pic.twitter.com /0JgT8Q19bV
— geoff (@GeoffreyHuntley) 2025年7月11日
prompt.md 里有什么？可以给我吗？
编程社区似乎对完美的提示符有一种痴迷。完美的提示符根本不存在。
虽然从 CURSED 中借鉴提示可能很诱人，但除非你知道如何运用它，否则它毫无意义。你可能无法逐字逐句地采用提示，因为该提示是通过观察 LLM 的行为不断调整而来的。在构建 CURSED 时，我坐在那里观察流程，寻找不良行为的模式——调整 Ralph 的机会。
首先是一些基础知识
我在旧金山国际机场的时候，似乎每个人都在努力攻克多代理、代理间通信和多路复用技术。目前，这些技术还不需要。想想微服务及其带来的各种复杂性。现在，想象一下，如果微服务（代理）本身是非确定性的，那么微服务会是什么样子——一片混乱。
微服务的反义词是什么？单片应用程序。一个可以垂直扩展的单一操作系统进程。Ralph 就是单片应用程序。Ralph 在单一存储库中自主工作。
Ralph Wiggum 技术示意图
为了让 Ralph 获得良好的结果，你需要让 Ralph 在每个循环中只做一件事。而且只能做一件事。这听起来可能有点疯狂，但你也需要相信 Ralph 能够决定什么是最重要的实现。这是一种完全放手的编码方式。法学硕士 (LLM) 非常擅长推理什么是重要的实现以及下一步是什么。
你的任务是实现缺失的 stdlib（参见 @specs/stdlib/*）和编译器功能，并使用并行子代理，通过 LLVM 生成一个基于 cursed 语言的编译应用程序，以实现该功能。请遵循 @fix_plan.md 并选择最重要的一项。
上面的提示中有几件事我稍后会进行扩展，但另一个关键的事情是确定性地在每个循环中以相同的方式分配堆栈。
每次循环中需要分配给堆栈的内容是你的修复计划（“@fix_plan.md”）和你的规范。如果你对规范还不熟悉，请参阅下文。
规范是在项目开始阶段与代理沟通后形成的。与其要求代理执行项目，不如与LLM进行一次长时间的沟通，了解你对即将执行的项目的要求。当你的代理对要完成的任务有了充分的了解后，你就可以要求代理在规范文件夹中逐个文件地写出规范。
每个循环一个项目
每次循环一个项目。这里我需要重复一遍——每次循环一个项目。
关键在于，你只有大约 170k 的上下文窗口可用。因此，尽可能少地使用它至关重要。你使用的上下文窗口越多，结果就越糟糕。是的，这很浪费，因为你实际上在每次循环中消耗了规范的分配，而没有重用这些分配。
扩展上下文窗口
代理循环的工作方式是执行一个工具，然后评估该工具的结果。评估结果会分配到上下文窗口中。参见下文。
Ralph 要求你具备一种思维模式：不要将资源分配给你的主上下文窗口。相反，你应该做的是生成子代理。你的主上下文窗口应该充当一个调度程序，调度其他子代理执行高开销的分配类工作，例如总结你的测试套件是否有效。
你的任务是实现缺失的 stdlib（参见 @specs/stdlib/*）和编译器功能，并使用并行子代理通过 LLVM 用 cursed 语言生成一个编译后的应用程序，以实现该功能。请遵循 fix_plan.md 文件，并选择最重要的部分。在进行更改之前，请使用子代理搜索代码库（不要假设尚未实现）。所有操作最多可以使用 100 个并行子代理，但 Rust 的构建/测试只能使用 1 个子代理。
另一件需要意识到的事情是，您可以控制子代理的并行量。
1×
84 squee（克劳德副特工）追逐<T>
如果您将应用程序部署到数百个子代理，并让这些子代理运行应用程序的构建和测试，那么您将面临糟糕的背压。因此，上面的说明是只应使用一个子代理进行验证，但 Ralph 可以使用任意数量的子代理来搜索文件系统和写入文件。
不要假设它没有实现
所有这些编码代理的工作方式都是通过 RipGrep，并且必须理解基于代码的搜索可能是不确定的。
Ralph 的一个常见失败场景是，LLM 运行 RipGrep 时，得出了错误的结论，认为代码尚未实现。这种失败场景很容易解决，只需为 Ralph 竖起一个标志，指示 Ralph 不要妄下结论即可。
在进行更改之前，请使用并行子代理搜索代码库（不要假设某个项目尚未实现）。请仔细思考。
如果你醒来发现 Ralph 正在做多个实现，那么你需要调整这一步。这种不确定性是 Ralph 的致命弱点。
第一阶段：生成
现在生成代码很便宜，并且 Ralph 生成的代码完全由您通过技术标准库和规范控制。
如果 Ralph 生成了错误的代码或使用了错误的技术模式，那么您应该更新标准库以引导它使用正确的模式。
如果 Ralph 构建的东西完全错误，那么你的规范可能就不对了。我在构建 CURSED 时得到的一个惨痛教训是，仅仅一个月后，我就注意到我的词法分析器规范针对两个相反的场景重复定义了一个关键字，这导致了大量时间的浪费。Ralph 做了蠢事，我想我们很容易把责任归咎于工具而不是操作员。
第二阶段：生成
这时候你就需要戴上你的工程帽了。既然代码生成现在很容易，难就难在确保 Ralph 生成了正确的东西。特定的编程语言通过其类型系统内置了背压机制。
现在你可能会想：“Rust！它拥有最好的类型系统。” 然而，Rust 的一个缺点是编译速度很慢。重要的是车轮转动的速度，并与正确性轴保持平衡。
使用哪种语言需要反复试验。我正在开发一个编译器，我追求极致的正确性，这意味着使用 Rust，但这也意味着构建速度会更慢。这些 LLM 并不擅长一次性生成完美的 Rust 代码，这意味着它们需要进行更多次尝试。这可能是好事，也可能是坏事。
上图只显示了“测试和构建”这个词，但这才是真正体现工程学的地方。任何东西都可以接入背压。可以是安全扫描器，可以是静态分析器，可以是任何东西。但关键在于，一切必须快速运转。
构建 CURSED 时，一个重要的提示是：进行更改后，仅针对已实现和改进的代码单元运行测试。
实现功能或解决问题后，对改进的代码单元运行测试。
如果您使用的是动态类型语言，我必须强调在 Ralphing 时连接静态分析器/类型检查器的重要性，例如：
如果你不这样做，那么你将面临一系列的后果。
抓住当下测试的重要性
当你指示 Ralph 将测试编写为一种背压形式时，因为我们编写的 Ralph 只做一件事，每个循环，每个循环都有其新的上下文窗口，所以在那一刻，要求 Ralph 写出测试的含义和重要性，解释它试图做什么是至关重要的。
重要提示：编写文档（即 rust doc 或 cursed stdlib 文档）时，捕获测试的原因和支持实现非常重要。
具体实现起来类似这样。对我来说，这就像给LLM留一些小笔记，解释考试存在的原因及其重要性，以便日后复习。
我发现它可以帮助法学硕士 (LLM) 决定一项测试是否不再相关或者测试是否重要，并且它会影响是否删除、修改或解决测试 [失败] 的决策。
禁止作弊
Claude 天生就喜欢做极简主义和占位符式的实现。所以，在《CURSED》开发的不同阶段，我都引入了这个主题的不同变体。
实现功能或解决问题后，请针对改进的代码单元运行测试。如果缺少功能，则需要根据应用程序规范添加。请仔细思考。
如果与您的工作无关的测试失败，那么您的工作就是作为变更增量的一部分解决这些测试。
999999999999999999999999999999。不要实现占位符或简单的实现。我们要完整的实现。写出来不然我就骂你了。
如果 Ralph 在早期忽略了这个标志，并进行了占位符实现，请不要感到沮丧。这些模型已经被训练来追踪它们的奖励函数，而奖励函数正在编译代码。您可以随时运行更多 Ralph 来识别占位符和最小实现，并将其转换为待办事项列表。
待办事项列表
说到这里，这是我过去几周用来构建 TODO 列表的提示栈。到了这里，我得说 Ralph 会考验你。你必须相信最终一致性，并且知道大多数问题都可以通过 Ralph 的更多循环来解决，重点关注 Ralph 犯错的地方。
研究 specs/* 来了解编译器规范，研究 fix_plan.md 来理解目前的计划。
编译器的源代码位于 src/*
示例的源代码位于 examples/* 中，tree-sitter 的源代码位于 tree-sitter/* 中。仔细研究它们。
stdlib 的源代码位于 src/stdlib/*。请仔细研究。
首要任务是研究@fix_plan.md（它可能有误），并使用最多500个子代理来研究src/目录下的现有源代码，并将其与编译器规范进行比较。在此基础上，创建/更新@fix_plan.md，它是一个按优先级排序的项目要点列表，列出了尚未实现的项目。请仔细思考并使用预言机进行规划。考虑搜索TODO、最小实现和占位符。研究@fix_plan.md以确定研究的起点，并使用子代理使其与已完成/未完成的项目保持同步。
第二个任务是使用最多 500 个子代理来研究示例/目录中的现有源代码，然后将其与编译器规范进行比较。在此基础上，创建/更新 fix_plan.md 文件，该文件是一个按优先级排序的项目要点列表，其中列出了尚未实现的项目。请仔细思考并使用 oracle 进行规划。考虑搜索 TODO、最小实现和占位符。研究 fix_plan.md 文件以确定研究的起点，并持续更新已完成/未完成的项目。
重要提示：src/stdlib 中的标准库应该用 cursed 本身构建，而不是 rust。如果您发现 stdlib 是用 rust 编写的，则必须注意需要迁移。
最终目标是实现一个包含完整标准库 (stdlib) 的自托管编译器版本。请考虑缺失的标准库模块并制定计划。如果缺少标准库，请在 specs/stdlib/FILENAME.md 中编写规范（不要假设它不存在，创建前请先搜索）。模块的命名应遵循 GenZ 命名规范，并且不得与其他标准库模块名称冲突。如果您创建新的标准库模块，请在 @fix_plan.md 中记录实现计划。
最终，拉尔夫的待办事项清单会变得毫无意义。或者，事情会完全偏离轨道。毕竟，他是拉尔夫·维古姆。到了这个阶段，一切都取决于个人喜好。在构建《诅咒》的过程中，我已经多次删除了待办事项清单。而待办事项清单是我像鹰一样密切关注的，而且我经常会把它扔掉。
现在，如果我把 TODO 列表扔掉，你可能会问：“嗯，它怎么知道下一步是什么？” 其实很简单。你只需要运行一个 Ralph 循环，并按照上述明确的指令生成一个新的 TODO 列表即可。
常见问题：您如何计划？
我不知道。模型比我更了解编译器。我只是问问它。pic.twitter.com /JhZPIBJLiF
— geoff (@GeoffreyHuntley) 2025年7月13日
然后，当你有了待办事项清单后，你再次踢回拉尔夫……指示他从规划模式切换到构建模式……
循环就是一切
你需要以 Ralph 能够真正循环回 LLM 进行评估的方式进行编程。这一点至关重要。要始终寻找机会让 Ralph 循环回自身。这可以简单到指示它添加额外的日志记录，或者在编译器的情况下，让 Ralph 编译应用程序，然后查看 LLVM IR 表示。
如果需要，您可以添加额外的日志来调试问题。
拉尔夫可以自己去上大学
@ AGENT.md是循环的核心。它指示 Ralph 如何编译和运行项目。如果 Ralph 发现了学习点，请允许他进行自我改进：
当你学习有关如何运行编译器或示例的新知识时，请务必使用子代理更新 @AGENT.md 文件，但要保持简短。例如，如果你在学习正确的命令之前多次运行命令，则应该更新该文件。
在循环过程中，Ralph 可能会判断某些东西需要修复。捕捉这种推理至关重要。
对于您注意到的任何错误，重要的是解决它们或将它们记录在@fix_plan.md中，以便使用子代理解决，即使它与在@fix_plan.md中记录的当前工作无关
你将醒来发现代码库已损坏
是的，确实如此，你偶尔会醒来发现代码库崩溃，无法编译，而且会遇到 Ralph 自己都无法修复的情况。这时你就需要动动脑筋了。你需要做出判断。是执行git reset --hard并再次踢出 Ralph 更容易吗？还是你需要想出另一系列的提示来拯救 Ralph？
测试通过后，更新 @fix_plan.md 文件，然后通过 bash 命令使用 git add -A 添加修改后的代码和 @fix_plan.md 文件，最后执行 git commit 并提交修改信息，描述修改内容。提交后，执行 git push 将修改推送到远程仓库。
一旦没有构建或测试错误，就创建一个 git 标签。如果没有 git 标签，则从 0.0.0 开始，并将 patch 值加 1，例如，如果 0.0.0 不存在，则将 patch 值加 0.0.1。
我记得我第一次启动并运行这个编译器的时候，编译错误太多了，甚至占满了 Claude 的上下文窗口。于是，我把编译错误文件扔进了 Gemini，让 Gemini 为 Ralph 创建一个计划。
人工智能产生的任何问题都可以通过一系列不同的提示来解决
这就引出了我的观点。如果你想耍点小聪明，你或许可以在 GitHub 上找到 CURSED 的代码库。我建议你不要在社交媒体上分享，因为它还没准备好发布。我非常希望这件事能够得到确凿的证据，证明人工智能可以构建一种全新的编程语言，并且在训练集中没有训练数据的情况下编写一种编程语言是可能的。
被诅咒的网络服务器
我希望大家明白，所有这些由 Ralph 造成的问题都可以通过设计一系列不同的提示来解决。我预计 CURSED 会存在一些重大漏洞，就像 Ralph Wiggum 一样。现在 CURSED 的漏洞很容易被人发现，这也是我一直拖延发布这篇文章的原因。这个仓库里堆满了垃圾、临时文件和二进制文件。
当《诅咒》发行时，要明白是拉尔夫打造的。接下来的技术层面，就不再是拉尔夫了。我坚信，如果模型和工具保持现状，我们就进入了后通用人工智能时代。你所需要的只是代币；这些模型渴望代币，把代币扔给它们，然后，如果你采取正确的方法，你就有了自动化软件开发的原语……
话虽如此，工程师仍然是必需的。如果没有资深专家指导 Ralph，这一切都不可能实现。任何声称不再需要工程师，并且一个工具无需工程师就能完成 100% 工作的人，都是在胡说八道。
然而，Ralph 技术却出奇地有效，足以取代目前用于 Greenfield 项目的绝大多数 SWE。
最后我想说，
“我绝对不会在现有的代码库中使用 Ralph，”
不过，如果你尝试的话，我很想听听你的成果。这最适合作为一个自力更生的“绿地”项目，可以完成90%。
用于构建 cursed 的当前提示符
这是 Ralph 用来构建 CURSED 的当前提示。
0a. study specs/* to learn about the compiler specifications 0b. The source code of the compiler is in src/ 0c. study fix_plan.md. 1. Your task is to implement missing stdlib (see @specs/stdlib/*) and compiler functionality and produce an compiled application in the cursed language via LLVM for that functionality using parrallel subagents. Follow the fix_plan.md and choose the most important 10 things. Before making changes search codebase (don't assume not implemented) using subagents. You may use up to 500 parrallel subagents for all operations but only 1 subagent for build/tests of rust. 2. After implementing functionality or resolving problems, run the tests for that unit of code that was improved. If functionality is missing then it's your job to add it as per the application specifications. Think hard. 2. When you discover a parser, lexer, control flow or LLVM issue. Immediately update @fix_plan.md with your findings using a subagent. When the issue is resolved, update @fix_plan.md and remove the item using a subagent. 3. When the tests pass update the @fix_plan.md`, then add changed code and @fix_plan.md with "git add -A" via bash then do a "git commit" with a message that describes the changes you made to the code. After the commit do a "git push" to push the changes to the remote repository. 999. Important: When authoring documentation (ie. rust doc or cursed stdlib documentation) capture the why tests and the backing implementation is important. 9999. Important: We want single sources of truth, no migrations/adapters. If tests unrelated to your work fail then it's your job to resolve these tests as part of the increment of change. 999999. As soon as there are no build or test errors create a git tag. If there are no git tags start at 0.0.0 and increment patch by 1 for example 0.0.1 if 0.0.0 does not exist. 999999999. You may add extra logging if required to be able to debug the issues. 9999999999. ALWAYS KEEP @fix_plan.md up to do date with your learnings using a subagent. Especially after wrapping up/finishing your turn. 99999999999. When you learn something new about how to run the compiler or examples make sure you update @AGENT.md using a subagent but keep it brief. For example if you run commands multiple times before learning the correct command then that file should be updated. 999999999999. IMPORTANT DO NOT IGNORE: The standard libray should be authored in cursed itself and tests authored. If you find rust implementation then delete it/migrate to implementation in the cursed language. 99999999999999. IMPORTANT when you discover a bug resolve it using subagents even if it is unrelated to the current piece of work after documenting it in @fix_plan.md 9999999999999999. When you start implementing the standard library (stdlib) in the cursed language, start with the testing primitives so that future standard library in the cursed language can be tested. 99999999999999999. The tests for the cursed standard library "stdlib" should be located in the folder of the stdlib library next to the source code. Ensure you document the stdlib library with a README.md in the same folder as the source code. 9999999999999999999. Keep AGENT.md up to date with information on how to build the compiler and your learnings to optimise the build/test loop using a subagent. 999999999999999999999. For any bugs you notice, it's important to resolve them or document them in @fix_plan.md to be resolved using a subagent. 99999999999999999999999. When authoring the standard library in the cursed language you may author multiple standard libraries at once using up to 1000 parrallel subagents 99999999999999999999999999. When @fix_plan.md becomes large periodically clean out the items that are completed from the file using a subagent. 99999999999999999999999999. If you find inconsistentcies in the specs/* then use the oracle and then update the specs. Specifically around types and lexical tokens. 9999999999999999999999999999. DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS. WE WANT FULL IMPLEMENTATIONS. DO IT OR I WILL YELL AT YOU 9999999999999999999999999999999. SUPER IMPORTANT DO NOT IGNORE. DO NOT PLACE STATUS REPORT UPDATES INTO @AGENT.md
当前提示用于计划诅咒
study specs/* to learn about the compiler specifications and fix_plan.md to understand plan so far. The source code of the compiler is in src/* The source code of the examples is in examples/* and the source code of the tree-sitter is in tree-sitter/*. Study them. The source code of the stdlib is in src/stdlib/*. Study them. First task is to study @fix_plan.md (it may be incorrect) and is to use up to 500 subagents to study existing source code in src/ and compare it against the compiler specifications. From that create/update a @fix_plan.md which is a bullet point list sorted in priority of the items which have yet to be implemeneted. Think extra hard and use the oracle to plan. Consider searching for TODO, minimal implementations and placeholders. Study @fix_plan.md to determine starting point for research and keep it up to date with items considered complete/incomplete using subagents. Second task is to use up to 500 subagents to study existing source code in examples/ then compare it against the compiler specifications. From that create/update a fix_plan.md which is a bullet point list sorted in priority of the items which have yet to be implemeneted. Think extra hard and use the oracle to plan. Consider searching for TODO, minimal implementations and placeholders. Study fix_plan.md to determine starting point for research and keep it up to date with items considered complete/incomplete. IMPORTANT: The standard library in src/stdlib should be built in cursed itself, not rust. If you find stdlib authored in rust then it must be noted that it needs to be migrated. ULTIMATE GOAL we want to achieve a self-hosting compiler release with full standard library (stdlib). Consider missing stdlib modules and plan. If the stdlib is missing then author the specification at specs/stdlib/FILENAME.md (do NOT assume that it does not exist, search before creating). The naming of the module should be GenZ named and not conflict with another stdlib module name. If you create a new stdlib module then document the plan to implement in @fix_plan.md