Validator-first 完成门禁
不是“有提交就算成功”，而是必须由验证结果明确放行。
适合真实工程任务的 Issue 驱动编排器
让 Ralph 替你写代码，你只管睡觉。
Ralph 会把 GitHub Issue 变成有计划、有验证、可审查的 Pull Request。它不是一条长 prompt 硬做到底，而是更接近工程编排器，特别适合大任务、长流程和需要审计的仓库协作。
GitHub Issue / 飞书命令
Ralph 先生成执行计划
Ralph 执行一个可运行子任务
Ralph 做验证
Ralph 更新同一个 Draft PR
验证通过 → 关闭 Issue
Issue → PR
不是长 prompt 编码，而是更严格的工程执行闭环
单次推进一个子任务
每次 workflow 只推进一个明确、可运行的步骤
GitHub 作为真相源
Issue、评论和 PR 全程可审计，不脱离仓库状态
为什么是 Ralph
适合比“友好 LLM 单轮输出”更复杂、更长、更需要可靠性的任务
Ralph 的核心不是生成代码，而是控制执行节奏：先规划，再一次只执行一个可运行子任务，保存状态，持续更新同一个 PR，最后由验证结果决定任务是否真正完成。
增量编排执行
把复杂任务拆成可连续推进的步骤，降低一次性重构失控的概率。
Draft PR 优先
工作尽早可见，但不会提前假装任务已经真正完成。
跨仓库可用
中心部署可以调度其他代码仓，并保留原始 issue 的路由与反馈。
飞书入口
团队可以在聊天里创建、审批、拒绝和跟踪任务，同时保持 GitHub 为执行真相源。
天然有状态
子任务与执行快照可以跨 workflow 持续存在，而不是散落在日志里。
工作流
一个更接近工程现实的 Issue 驱动自动化闭环
创建 Issue 或发送飞书命令
明确目标、要求、限制和验收标准，让任务可以被可靠地规划。
生成执行计划
复杂任务会自动拆分为更可执行的子任务，必要时等待人工审批。
执行一个可运行子任务
每次运行都做一个可以自证合理的步骤，而不是试图一次完成整个项目。
验证、更新 PR、继续推进
同一个 Draft PR 持续演化，直到验证通过并满足关闭 issue 的条件。
用户 / 团队
GitHub Issue / 飞书
GitHub Actions
规划器 → 执行 → 验证 → PR
对比
真正改变的是：你不再把“生成了代码”误认为“工程已经完成”
方式
常见问题
Ralph 的做法
一次性长 prompt 编码 Agent
任务一大就丢结构、丢上下文或失控
先规划，再一次只执行一个可运行子任务
纯触发型 issue bot
能启动任务，但缺少持续状态记忆
在多次 workflow 之间持久化子任务和执行状态
聊天优先编码流程
容易和仓库真实状态脱节
始终以 GitHub issue 和 PR 为真相源
没有门禁的代码生成
“生成了代码”容易被误判成“任务完成”
只有验证通过才算真正完成
快速开始
不需要额外搭一整套平台，也能让 Ralph 跑起来
1. 安装到你的仓库
git clone https://github.com/YOUR_GITHUB_USER/ralph.git /tmp/ralph
cd YOUR_PROJECT
/tmp/ralph/scripts/setup.sh2. 配置凭据
Secrets:
RALPH_API_KEY
RALPH_GITHUB_TOKEN
Variables:
RALPH_API_BASE_URL
RALPH_API_MODEL
RALPH_LANG=zh-CN3. 开始触发任务
/ralph
目标：重做首页
要求：现代风格，响应式布局
限制：保持当前技术栈
验收：移动端正常，无控制台报错适用场景
Ralph 最适合这些需要“可靠推进”而不是“单轮输出”的任务
夜间自动交付功能
白天写好 issue，晚上自动执行，早上直接看 Draft PR 和验证结果。
大任务和重构
把高风险变更拆成可连续推进的步骤，降低一次性改动失控的风险。
团队聊天驱动研发
飞书里发起和控制任务，所有执行痕迹仍然回到 GitHub 仓库里。
跨仓库自动化
中心 Ralph 部署可以调度其他仓库，同时保留清晰的任务路由和反馈链路。
文档入口
官网负责快速理解，详细接入和配置仍然在仓库文档里
网站更适合快速介绍 Ralph 是什么、适合什么场景；真正落地接入时，还是建议直接进入 README、 中文文档、飞书文档和架构说明。
README
英文版总览、架构、执行模型和安装方式。
打开 READMEREADME_CN
中文版安装、概念说明、工作流和使用建议。
打开 README_CN飞书与架构
查看飞书接入方式、路由机制和整体编排设计说明。
打开飞书文档