ralph

Product images

About

从 Tab 到 Agent，我们走了多远？ 最近几年 AI 的发展可谓是十分迅猛。 Tab 时代：GitHub Copilot 横空出世，我们第一次感受到 AI 补全代码的魔力。按下 Tab，代码即可自动补全。 Chat 时代：Cursor、Windsurf 让我们可以和 AI 对话。"帮我写一个登录功能"，它真的能写出来。 Agent 时代：Claude Code、Codex、OpenCode... AI 不再只是回答问题，它开始主动思考、规划、执行。 真正上手体验过的用户都知道，"古法编程"和"Vibe 编程"的效率差距有多大。毫不夸张地说，原先一个星期才能完成的需求，现在一句话 + 一杯咖啡的时间，Agent 就能帮你搞定。 但我一直在想：这真的是 AI 的极限吗？ 还记得那个昙花一现的 Devin 吗？它承诺能独立完成整个项目，却最终没能兑现。一年多过去了，我有没有可能实现一个？哪怕只是最简单的 MVP？ 站在巨人的肩膀上 在动手之前，我们需要先研究一个最近很火的项目 Ralph 。它的核心思路很简洁： 把需求写成 PRD → 拆成 User Stories → 让 AI 循环执行每个 Story → 直到全部完成 PRD → Stories → AI Loop → Done 这个想法很棒。每次迭代都是一个全新的 AI 实例，上下文干净；通过 prd.json 和 progress.txt 保持记忆；一个 Story 一个 Story 地推进，直到所有任务完成。 但我用了一段时间后，发现了几个问题： 1. PRD 从哪来？ Ralph 假设你已经有一份写好的 PRD，但从零开始的项目呢？ 2. 架构谁来定？ 技术选型、系统设计，这些 PRD 写完之前就要决定的事情呢？ 3. AI 不会的技术怎么办？ 如果 Story 涉及 AI 不熟悉的库，它可能会写出过时或错误的代码 4. 多个方案怎么选？ 如果有好几种实现方式，AI 凭什么选其中一个？ 5. 谁来监督 AI？ 如果它跑偏了，陷入死循环，或者写出灾难性代码，怎么办？ 这些问题，让我决定在 Ralph 的基础上，做更多的思考和扩展。 我新建了一个文件夹 几天前的一个午后，我停下手中的活，创建了一个空目录。 我开始思考：在 PRD 之前，还需要什么？ 我敲下了第一个词——「愿景」。 什么是愿景？我认为愿景是两个"为什么"： 为什么需要它？ 为什么应该是它？ 我把这叫做价值对齐。就像人类做项目一样，如果你不知道为什么要做，你就不知道该做成什么样。 从愿景到路线图：补全 PRD 之前的环节 有了愿景之后，我继续问自己：然后呢？ 我想起了自己做项目的流程。拿到需求后，我会先做什么？ 架构设计。 选用什么技术栈？数据库用什么？前端框架用哪个？这些决策会影响整个项目的走向。 于是我加入了第二个阶段——「架构」。 但仅有架构还不够。一个大项目不可能只有一个 PRD，需要拆分成多个阶段。 我加入了第三个阶段——「路线图」。 把项目分解成里程碑，每个里程碑包含若干个 PRD，每个 PRD 再交给 Ralph 的执行循环去处理。 这时候，一个完整的工作流在我脑海中成型： 原版 Ralph ↓ Vision → Architecture → Roadmap → [PRD → Execute] 愿景 → 架构 → 路线图 → [PRD → 执行循环] ↑ 这部分借鉴 Ralph 在 Ralph 的执行引擎之上，我补全了项目启动阶段的三个环节。 看起来完整了？不，问题才刚刚开始。 当 AI 遇到不会的东西 在测试执行阶段时，我遇到了第一个难题： 如果 AI 遇到了它不熟悉的技术怎么办？ 比如，PRD 要求使用某个库实现特定功能，但 AI 的训练数据里可能只有过时的版本信息。它会不会用错误的 API？会不会写出过时的代码？ 传统的做法是告诉 AI："去查文档"。但这远远不够。 我在 Ralph 的执行循环中，加入了一个「研究阶段」。 在实现每个 Story 之前，系统会先检查：这个任务涉及哪些技术？有没有需要研究的课题？ 如果有，AI 会： 1. 拉取最新的库源码（不是文档，是源码！） 2. 阅读关键模块，理解真正的实现方式 3. 查阅官方文档和最佳实践 4. 生成研究报告，记录发现和建议 只有研究完成后，才进入实现阶段。 这让我想到了一个更深的问题：如果研究结果显示原计划不可行呢？ 于是我又加入了 「计划审查」 阶段。研究之后，系统会评估： 原来的 Story 设计合理吗？ 需不需要调整验收标准？ 是否要拆分或合并任务？ 现在，执行阶段从 Ralph 原来的简单循环，变成了一个四步循环： 原版 Ralph: Pick Story → Implement → Check → Next ↓ 改进后 Research → Plan Review → Implement → Quality Review 研究 → 审查计划 → 实现 → 质量审查 AI 不再是盲目执行，而是先研究、再计划、后实现。 当你不知道哪条路是对的 设计到这里，我遇到了第二个难题： 如果有多个技术方案，AI 怎么选择？ 比如做认证系统，JWT、Session、OAuth 都可以。AI 凭什么选其中一个？拍脑袋吗？ 我的答案是： 全都试一遍。 我设计了一个 「并行探索」 机制： 当面临重大技术决策时，系统会： 1. 为每个方案创建独立的 Git Worktree（工作区） 2. 并行运行多个 AI Agent，各自实现一个方案 3. 每个 Agent 完成后，生成探索报告：实现了什么、优点、缺点、打分 4. 再派出 3 个评估 Agent，独立评审所有方案 5. 最后综合推荐，选择最优方案并合并 方案 A ──→ Agent A 实现 ──→ 报告 A ─┐ 方案 B ──→ Agent B 实现 ──→ 报告 B ─┼──→ 评估团队 ──→ 最优方案 方案 C ──→ Agent C 实现 ──→ 报告 C ─┘ 这不是理论上的"比较"，而是真刀真枪地实现一遍再比较。 只有亲自走过每条路，才知道哪条路最好走。 谁来监督 AI？ 系统越来越完善，但我心里一直有个隐忧： 如果 AI 跑偏了怎么办？ 它可能陷入死循环、可能写出灾难性的代码、可能把整个项目带向错误的方向。而且它是自动运行的，等你发现问题可能已经太晚了。 我需要一个监督机制。 但让人来监督？这违背了"自主"的初衷，并且也无法实现7x24小时不间断运行。 让另一个 AI 来监督？那谁来监督监督者？ 我想了很久，最后想到了一个有点疯狂的方案： 建立一个「上帝组委会」。 这是一个独立于执行层的监督机构，由三个 AI 成员组成：Alpha、Beta、Gamma。 它们： 不参与代码编写，只负责观察和监督 定期自动唤醒（2-8 小时随机间隔），巡视项目状态 遇到异常立即响应：检测到错误、测试失败、进程卡死时紧急介入 重大决策需要共识：终止进程、回滚代码、删除功能等操作，需要 2/3 成员投票通过 它们拥有最高权限： 暂停所有执行 回滚任意提交 修改任意代码 终止任意进程 修复系统问题 这不是我拍脑袋想的，而是借鉴了： 分布式系统的共识机制 公司治理中的监事会 AI 安全领域的多 Agent 审查 我给它起名叫 「God Committee」 ——上帝组委会。 ┌─────────────────────────────────────────────────┐ │ GOD COMMITTEE（上帝组委会） │ │ ┌───────┐ ┌───────┐ ┌───────┐ │ │ │ Alpha │───│ Beta │───│ Gamma │ │ │ └───────┘ └───────┘ └───────┘ │ │ │ │ │ │ │ └────────┬────────────┘ │ │ ↓ │ │ 观察 · 讨论 · 干预 │ └─────────────────────────────────────────────────┘ ↓ 监督 ┌─────────────────────────────────────────────────┐ │ 执行层（Execution Layer） │ │ Orchestrator → Execution Engine → Skills │ └─────────────────────────────────────────────────┘ 让一切透明可追溯 还有一个问题：AI 做决策的过程，人类看得懂吗？ 如果 AI 只是默默干活，出了问题我们无从排查；即使成功了，我们也不知道它为什么成功。 于是我加入了 「可观测性」 机制。 AI 的每一个决策、每一次思考、每一个选择，都会被记录下来： markdown 2026-01-30 14:30:00 | Task: PRD-003 | Phase: Research 我在思考 我正在研究认证策略。愿景里提到要"简单快速"， 传统的用户名密码可能会增加摩擦... 决策点 考虑中: 传统邮箱密码 考虑中: Magic Link（无密码） 考虑中: 仅 OAuth 最终选择: Magic Link + OAuth 备选 原因: 符合"简单"目标，减少密码疲劳 下一步 研究邮件服务商（Resend、SendGrid）的免费额度... 这些日志不是给 AI 看的，是给人类看的。 你可以随时打开 logs/ai-thoughts.md，看到 AI 完整的思考过程。它为什么选了这个方案、它担心什么、它不确定什么——一切透明。 Aha Loop：我在 Ralph 基础上做了什么？ 我把这个扩展后的系统叫做 Aha Loop。 为什么叫这个名字？因为我希望 AI 在每次循环中都能获得 "Aha" 时刻 ——通过研究获得理解，通过探索获得最优解，而不是盲目执行。 总结一下，相比原版 Ralph，Aha Loop 增加了这些东西： | 原版 Ralph | Aha Loop 扩展 | |------------|---------------| | 从 PRD 开始 | 增加了 Vision → Architecture → Roadmap 三个前置阶段 | | 直接执行 Story | 增加了 Research（研究）和 Plan Review（计划审查）阶段 | | 单一执行路径 | 增加了并行探索机制（Git Worktree + 多 Agent 评估） | | 无监督 | 增加了 God Committee 独立监督层 | | 结果导向 | 增加了完整的可观测性日志系统 | 如果说原版 Ralph 是一个执行引擎，那 Aha Loop 做的事情是给它加上了大脑（规划层）和眼睛（监督层）。 实战：一段话，一个 API 网关 系统设计完成后，我决定用一个真实项目来检验它。 我只给了 AI 这样一段话作为愿景： 我需要实现一个 AI（LLM）网关。现在市面上主要的大模型厂商包括 OpenAI、Anthropic、Google 等，他们各家在 API 接口的实现上都不相同。OpenAI 有早期的 v1/chat/completions 和现在的 v1/responses，Anthropic 有 v1/messages，Google 的更加繁琐。每家的请求接口、响应结构也都不一样，也有流式和非流式之分，千奇百怪。 我想实现一个方案：是否可以实现一个 AI 网关，支持格式 X、Y、Z，给定一个上游 A，无论上游 A 是什么类型的格式，用户永远能通过任意 X、Y、Z 格式的请求与之进行交互，并且响应也是用户预期的 X、Y、Z 格式。 并且由于不同的上游对 X、Y、Z 格式支持的可能并不完善——比如上游 A，虽然它官方是支持 X 格式的请求和响应的，但由于实现有所差异，导致实际请求和响应与标准有些差异——我们是否能让用户通过最小量的配置去实现兼容，或者通过支持扩展插件的形式支持用户扩展？ 就这么一段话。 没有详细的技术规格，没有 API 文档，没有架构图。 然后，我按下了回车键。 结果如何？ 说实话，我自己都有点惊讶。 1. 愿景分析：这个阶段是是手动在Claude Code里面使用 Vision Builder Skill 来构建，他能准确的识别出这是一个"协议转换网关"项目，核心问题是"多协议兼容" 2. 架构设计：依旧是手动在Claude Code里面使用 Architect Skill来构建，我们了 Rust 作为开发语言（性能考虑+方便check），设计了协议层、转换层、上游层的分层架构 3. 路线图规划：依旧是手动在Claude Code里面使用 Roadmap Skill来构建拆分成了多个里程碑，从基础框架到协议支持，再到流式处理 5. 逐个实现：从这个阶段开始全部都是由AI独立操作，一个 Story 一个 Story 地完成，包括： OpenAI Chat Completions 协议支持 OpenAI Responses 协议支持 Anthropic Messages 协议支持 流式响应处理 协议之间的相互转换 配置系统 错误处理 最终，它交付了一个接近可用的 AI 网关系统。 为什么说"接近"，是因为确实还有一些问题： √ 核心功能已经实现 √ 多协议转换可以工作 √ 流式和非流式都支持 X 还有几个 bug 需要修复 X 插件系统没有实现（这是愿景里提到的扩展能力） 距离一个真正"生产可用"的产品，大概还差几个 bug 的修复工作。 但重点是：从一段模糊的需求描述，到一个基本可用的系统——这个过程是 AI 自主完成的。 一个有趣的发现 在项目完成后，我去检查系统日志时发现了一个意外： 上帝组委会从头到尾都没有正常运行。 因为监督层的脚本有一些BUG，导致三位"上帝"一直在沉睡，从未被唤醒过。 也就是说，整个 AI-Gateway 项目的开发过程中，实际上没有任何监督介入。 也就是说： 第一，这说明 Aha Loop 的核心执行流程（Vision → Architecture → Roadmap → Execute）已经足够稳定，即使没有监督层，也能跑出一个基本可用的结果。 第二，这也说明监督机制确实是必要的——如果上帝组委会正常工作，也许那几个 bug 早就被发现并修复了。 这是一个意外的"消融实验"：移除监督层后，Aha Loop 依然能工作，但确实会遗漏一些问题。 Aha Loop 是什么？ Aha Loop 是一个基于 Ralph 思想扩展的全自主 AI 开发系统。 它的完整架构是这样的： 用户: "我想做一个 AI 网关..." │ ▼ ┌───────────────┐ │ Vision Builder │ 交互式问答，构建愿景 ← Aha Loop └───────────────┘ │ ▼ ┌───────────────┐ │ Vision Skill │ 分析愿景，提取需求 ← Aha Loop └───────────────┘ │ ▼ ┌───────────────┐ │ Architect │ 研究技术，选择架构 ← Aha Loop └───────────────┘ │ ▼ ┌───────────────┐ │ Roadmap │ 规划里程碑和 PRD ← Aha Loop └───────────────┘ │ ▼ ┌────────────────────┐ │ PRD Execution Loop │ │ ┌──────────────┐ │ │ │ Research │ │ 研究技术 ← Aha Loop │ │ Plan Review │ │ 审查计划 ← Aha Loop │ │ Implement │ │ 编写代码（Ralph 核心） │ │ Quality Check│ │ 质量审查 │ └──────────────┘ │ └────────────────────┘ │ God Committee 全程监督（理论上） ← Aha Loop │ ▼ PROJECT COMPLETE 这是几张 Cursor 绘制的图片。 架构图 流程图 上帝组委会工作机理图 核心理念： | 原则 | 含义 | |------|------| | 无限资源 | 不限制 AI 的计算、网络、存储 | | 永不放弃 | 遇到问题自动重试、自动修复 | | 研究先行 | 不懂就学，学会再做 | | 多路并行 | 不确定就都试，试完再选 | | 独立监督 | 上帝组委会全程护航（下次一定） | | 完全透明 | 所有决策可追溯 | 回到最初的问题 AI 能独立完成一个从 0 到 1 的产品吗？ 基于这次实验，我的答案是：基本能，但还不完美。 它能做到： 从一段模糊的需求出发，自主规划整个项目 研究它不熟悉的技术，学习后再实现 生成结构清晰、可维护的代码 处理大部分常规场景 它还做不到： 100% 没有 bug（还是需要人类兜底） 完全理解复杂的边界情况 实现所有设想的功能（比如插件系统就被遗漏了） 但这已经远超我最初的预期。 一段话 → 一个基本可用的 API 网关 这不再是 Demo，不再是玩具。这是一个真实的、可以继续迭代的项目。 最后 如果你对这个想法感兴趣，欢迎来看看源码，或者跟我交流你的想法。 也许未来，我们每个人都能拥有一个 AI 团队：有人负责编码、有人负责研究、有人负责监督——而你，只需要告诉它们你的愿景。 这一天，只会比你我想象的更近。 相关链接： Aha Loop : GitHub AI-Gateway: GitHub 参考项目: snarktank/ralph

Discovery history

1. 阮一峰周刊·用户投稿

   Feb 1, 2026 · 1 observations