1. 项目概述一个能“闭环”的AI编码代理工作流如果你用过市面上那些号称能自动编程的AI代理大概率经历过这样的挫败感你满怀期待地丢给它一个需求它吭哧吭哧干了两三个任务然后要么开始“神游”写出来的代码和你最初的要求南辕北辙要么干脆“暴毙”整个会话无声无息地中断留下一堆半成品和问号。你只能重启会话把需求再复述一遍祈祷这次它能坚持久一点。这种体验与其说是“智能代理”不如说是在抽奖。openclaw-build就是为了终结这种抽奖体验而生的。它不是一个单一的AI模型而是一套完整的、自托管的工程化工作流。它的核心思想很简单把一次性的、脆弱的、长会话的AI编码拆解成可审计、可中断、可恢复的标准化流程。从你提出一个想法到最终代码落地整个过程被清晰地划分为“需求澄清”和“构建执行”两个阶段中间设置了关键的人工审批节点确保AI始终行驶在你设定的轨道上。简单来说它的工作流是这样的你告诉AI“我想做个XX功能”。AI不会立刻开干而是先化身“产品经理”对你进行访谈澄清模糊点并输出一份详细的PRD产品需求文档让你审批。你点头后它才进入“工程师”模式将PRD拆解成一个个具体的、可检查的任务在一个受控的“构建循环”中逐个攻克直到所有任务被打上勾。整个过程有重试机制、有上下文记忆、有完成通知就像一个纪律严明的数字团队在为你工作。2. 核心设计理念与架构拆解2.1 为什么传统AI代理会“跑偏”或“崩溃”要理解openclaw-build的价值得先看看它要解决什么问题。当前AI编码代理的失败模式非常典型上下文漂移在长会话中AI的“记忆”会逐渐模糊或累积无关信息导致后续生成偏离最初目标。会话中断不可恢复一旦网络波动、API限制或进程意外退出整个会话状态丢失必须从头开始。任务状态丢失在多轮交互中哪些任务完成了哪些失败了缺乏清晰的、持久化的记录。缺乏验证与审批AI直接开始编码没有经过需求确认和方案评审容易产出不符合预期的“垃圾代码”。openclaw-build的架构正是针对这些痛点设计的。它不是一个魔法黑盒而是一个显式状态机。PRD文件是“宪法”任务清单是“待办事项”Git提交记录和项目内存文件是“工作日志”。每个构建循环都是短会话读取日志和内存来恢复上下文执行完一个任务就提交、记录然后优雅退出。下一个循环再干净地启动接着干。2.2 双阶段流程与审批门控这是openclaw-build最核心的管控机制确保了“人”始终在决策环内。第一阶段需求澄清与PRD生成当你发出“spec this”或“build me X”的指令后AI会启动一个访谈流程。它首先会复述你的需求确保理解无误。接着它会提出3到7个关键性的澄清问题通常以选择题形式这些问题可能涉及技术选型、边界条件、性能要求等。基于你的回答AI会草拟一个技术架构或实现计划并提交给你审批。这是第一个审批门控。只有你批准了这个计划AI才会动笔撰写详细的PRD.md文件。文件写完后AI会再次呈现给你这是第二个审批门控。只有你确认PRD无误流程才会进入下一阶段。这两个“闸门”从根本上杜绝了AI在错误方向上浪费token和时间。第二阶段基于PRD的自动化构建循环这个阶段的主角是ralphyPRD驱动的构建循环运行器。它读取已批准的PRD.md文件将其中的任务清单格式为- [ ] 任务描述作为输入。每个构建迭代由ralphy发起的一次AI调用只专注于完成一个或一组任务。迭代结束后结果通过Git提交固化学习心得被追加到项目专用的.ralphy/progress.txt内存文件中。然后ralphy会启动下一个迭代读取最新的Git历史和内存文件精准地“接棒”继续工作。所有任务完成后构建循环自动终止。2.3 核心组件与工具链选型openclaw-build巧妙地组合了多个现有工具形成了一个有机整体OpenClaw作为底层运行时和事件系统。它负责处理与各种通信渠道CLI, WhatsApp, Telegram等的交互并发布系统事件如任务完成通知。Ralphy核心执行引擎。它是一个命令行工具专门负责解析PRD、管理任务状态、调用指定的AI模型执行编码任务。它的--prd参数是指定任务来源的关键。AI 引擎后端支持多种模型根据任务类型灵活选择。Codex擅长后端逻辑、算法、API设计。在ralphy中通过--codex标志调用其推理强度可通过配置文件~/.codex/config.toml中的model_reasoning_efforthigh参数持久化设置。Claude Code在UI设计、前端布局、代码风格审美上表现更佳。通过--claude标志调用。重要Claude的推理强度 (--effort high) 必须在每次调用时显式指定无法持久化配置遗漏会导致性能降级。Sonnet成本更敏感场景下的选择能力均衡。Tmux用于管理长时间运行的、可分离的会话。这使得构建循环可以在后台稳定运行即使你关闭了终端窗口。Git Worktrees实现并行任务执行的关键。ralphy的--parallel模式会为每个并发任务创建独立的Git工作树避免文件冲突实现真正的并行开发。注意工具链的版本兼容性很重要。Node.js需要18版本bash是脚本基础。在安装前最好先检查现有环境避免因版本问题导致奇怪的错误。3. 从零开始的完整部署与配置实操3.1 环境准备与前置依赖安装假设我们在一台干净的Ubuntu 22.04服务器或开发机上开始。首先确保系统已更新并安装基础编译工具。sudo apt update sudo apt upgrade -y sudo apt install -y curl git build-essential接下来按顺序安装核心依赖安装Node.js 18ralphy和其工具链基于Node.js。# 使用NodeSource仓库安装LTS版本 curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs node --version # 应输出 v18.x 或更高安装Tmux用于会话管理。sudo apt install -y tmux安装并配置OpenClaw这是整个系统的“神经系统”。# 运行官方安装脚本 curl -fsSL https://openclaw.ai/install.sh | bash # 安装完成后按照提示进行初始化配置和渠道如CLI的接入。 # 通常需要获取API密钥并进行身份验证。 openclaw onboard请务必保管好配置过程中生成的密钥和令牌。安装AI引擎CLI并认证根据你的偏好和API访问权限选择安装Codex或Claude的CLI工具。这里以Codex为例假设你已有访问权限# 安装Codex CLI (具体命令请参考其官方文档此处为示例) pip install codex-cli # 进行身份验证 codex auth login # 验证安装 codex --version对于Claude你需要安装Anthropic的官方CLI或兼容工具并完成类似的认证。3.2 安装 openclaw-build 与 ralphy前置条件满足后安装就变得非常简单。# 一键安装 openclaw-build 及其脚本 curl -fsSL https://raw.githubusercontent.com/bkochavy/openclaw-build/main/install.sh | bash这个脚本会克隆仓库设置必要的路径并可能安装一些辅助脚本。接下来安装核心执行器ralphy# 通过npm全局安装ralphy-cli npm install -g ralphy-cli # 验证安装 ralphy --help3.3 项目初始化与第一个工作流体验现在让我们创建一个全新的项目来体验整个流程。假设我们要构建一个简单的“用户待办事项API”。创建项目目录并初始化Gitmkdir my-todo-api cd my-todo-api git init启动需求澄清阶段通过你配置好的OpenClaw渠道比如CLI向你的AI代理发送指令。/spec build a RESTful API for a personal todo list with user authentication注意具体触发指令取决于你的OpenClaw配置可能是“spec this”也可能是一个自定义命令。参与AI访谈AI会开始提问例如“认证方式采用JWT还是Session”“待办事项需要支持标签和分类吗”“API需要分页和过滤功能吗” 你需要像面对产品经理一样回答这些问题。审批计划与PRDAI会基于你的回答生成一个技术方案如使用Node.js Express MongoDB定义核心接口。你批准后它会生成PRD.md文件。务必仔细审查这个文件特别是其中的“Verification Commands”部分它定义了如何测试每个任务。确认无误后批准进入构建阶段。手动启动构建循环批准后AI通常会尝试自动启动构建。我们也可以手动启动以便观察细节# 首先为该项目初始化ralphy配置添加上下文记忆规则 ralphy --init # 然后启动构建循环。假设我们使用Codex引擎。 ralphy --codex --verbose --prd PRD.md -- -c model_reasoning_efforthigh此时ralphy会读取PRD.md中的第一个未完成任务- [ ]调用Codex来执行生成代码运行验证命令如果通过则标记任务为完成- [x]并创建一个Git提交。观察后台运行使用Tmux对于长时间运行的任务建议在Tmux会话中启动以便分离。# 创建一个名为“build-todo”的分离Tmux会话来运行ralphy tmux new -s build-todo -d cd /path/to/my-todo-api ralphy --codex --verbose --prd PRD.md -- -c model_reasoning_effort\high\ # 稍后可以附着到该会话查看进度 tmux attach -t build-todo # 或者从外部查看日志 tmux capture-pane -t build-todo -p | tail -504. 高级工作流与实战技巧4.1 并行执行与资源管理当PRD中的任务彼此独立时可以使用并行执行来大幅提速。ralphy通过Git worktrees实现这一点。ralphy --codex --parallel --max-parallel 2 --verbose --prd PRD.md -- -c model_reasoning_efforthigh这条命令会创建最多2个并行的Git工作树同时处理两个任务。注意事项冲突风险并行任务不应修改同一组文件。在规划PRD时应有意识地将任务拆分为正交的模块。资源消耗每个并行任务都会占用一个AI API调用和本地计算资源。请根据你的API速率限制和机器性能设置--max-parallel。调试复杂性当多个任务同时输出日志时问题排查会更困难。建议在稳定运行后再开启并行。4.2 无人值守AFK运行的安全策略让AI代理在夜间或你离开时自动运行很有吸引力但必须设置安全护栏防止其陷入死循环或疯狂消耗token。关键参数--max-iterations这个参数为一次构建循环设置硬性的迭代次数上限。设置原则是任务数量的1.5到2倍。例如你的PRD有10个任务可以设置为15到20次迭代。这给了AI足够的重试机会又避免了无限循环。# 安全的AFK运行命令示例 ralphy --codex --max-iterations 20 --verbose --prd PRD.md -- -c model_reasoning_efforthigh配合监控守护进程openclaw-build项目中的监控脚本需要额外配置可以监视Tmux会话状态在任务完成或卡住时通过你设定的渠道如Telegram发送通知实现真正的无人值守。4.3 跨模型审查与质量提升利用不同AI模型的优势进行交叉审查是提升代码质量的有效手段。一个常见的模式是“Codex编写Claude审查”。主构建使用Codex因为其在逻辑正确性上通常更可靠。阶段性引入Claude审查在完成一组功能后让Claude审查代码风格、UI组件或可能存在的不优雅实现。# 假设Codex已经完成了部分提交现在让Claude审查最近10个提交 ralphy --claude --verbose -- --effort high Review the code changes in the last 10 git commits of this repository. Focus on code style, potential bugs in the API endpoints, and readability. Output your findings to a file named CODE_REVIEW.md.根据审查结果进行修复可以将Claude生成的审查意见作为新的PRD任务再次交给Codex去修复。ralphy --codex --verbose --prd CODE_REVIEW_FIXES.md -- -c model_reasoning_efforthigh这种“多模型陪审团”机制能显著减少单一模型的盲点。4.4 复杂项目的三阶段管道对于全栈应用可以将其分解为三个顺序执行的子PRD分别利用不同引擎的优势前端PRD (FRONTEND-PRD.md)使用--claude引擎。任务包括组件设计、页面布局、样式编写、交互逻辑等。后端PRD (BACKEND-PRD.md)使用--codex引擎。任务包括数据库模型、API接口、业务逻辑、身份验证等。集成PRD (INTEGRATION-PRD.md)使用--codex引擎。任务包括连接前后端API、配置部署环境、编写端到端测试等。执行时按顺序运行三个构建循环并确保每个阶段完成后将产出的代码合并到主分支作为下一阶段的起点。4.5 与GitHub Issues深度集成openclaw-build可以直接从GitHub Issue中读取任务并将进度同步回去非常适合在团队协作中使用。# 处理某个GitHub仓库中所有带有“ralph”标签的issue ralphy --codex --github owner/repo --github-label ralph --verbose -- -c model_reasoning_efforthigh # 处理特定的issue编号并将生成的PRD同步到issue正文 ralphy --codex --github owner/repo --sync-issue 42 --verbose -- -c model_reasoning_efforthigh这个功能将AI代理无缝嵌入到了标准的GitHub工作流中使得任务分配和进度跟踪对团队其他成员完全透明。5. 故障排查与效能优化指南5.1 常见问题与解决方案速查表在实际操作中你可能会遇到以下典型问题问题现象可能原因排查步骤与解决方案Agent立即退出无输出1. AI引擎CLI认证过期或失败。2.--prd指定的文件路径错误或为空。1. 检查认证codex auth status或claude --version重新登录。2. 检查~/.codex/log/codex-tui.log查看详细错误。3. 使用ralphy --dry-run --prd PRD.md预览任务确认PRD能被正确解析。任务计数不对PRD.md文件中存在格式错误的复选框。1. 运行PRD预检脚本见下文。2. 确保任务项是顶格的- [ ]前面不能有空格嵌套。3. 使用rg -c ^- \[ \] PRD.md精确统计。--prd参数似乎被忽略参数位置错误。ralphy的标志必须放在分隔符--之前。错误ralphy --codex -- -c model_reasoning_efforthigh --prd PRD.md正确ralphy --codex --prd PRD.md -- -c model_reasoning_efforthigh并行任务出现合并冲突多个并行任务修改了同一个文件的相近区域。1. 在PRD规划阶段使用parallel_group在YAML配置中显式声明互斥的任务组。2. 降低--max-parallel数量。3. 事后手动解决冲突然后重新运行相关任务。Claude引擎产出质量突然下降遗漏了--effort high参数。Claude无法持久化配置此参数。务必在每次调用Claude时在分隔符--之后显式加上--effort high。例如ralphy --claude --prd PRD.md -- --effort high端口已被占用错误前一个测试服务器进程未正常退出。在PRD的早期任务中添加清理命令- [ ] Kill any process using port 3000:lsof -ti:3000 | xargs kill -95.2 PRD文件预检脚本在每次启动构建循环前手动或自动运行以下检查可以避免许多低级错误#!/bin/bash # preflight_check.sh PRD_FILE$1 if [ ! -f $PRD_FILE ]; then echo [ERROR] PRD file not found: $PRD_FILE exit 1 fi # 检查是否存在有效的顶级任务 if ! grep -q ^- \[ \] $PRD_FILE; then echo [ERROR] No valid top-level tasks found (format: - [ ] ...) exit 1 fi # 检查是否存在格式错误的已完成复选框不应出现 if grep -q ^- \[\][^ ] $PRD_FILE; then echo [ERROR] Malformed checkbox found (likely missing space). Use - [ ] for open, - [x] for closed. exit 1 fi # 检查是否存在嵌套的复选框ralphy可能不支持 if grep -q ^[[:space:]]- \[ \] $PRD_FILE; then echo [WARNING] Nested checkboxes detected. ralphy may not parse these correctly. Consider flattening your task list. # 这里可以选择exit 1或只是警告 fi echo [OK] PRD preflight check passed for: $PRD_FILE5.3 会话管理与状态监控使用Tmux进行会话管理是标准做法。这里提供一套实用的命令组合# 1. 在特定socket下创建并分离运行构建会话便于多用户或脚本管理 TMUX_SOCKET~/.tmux/build_socket SESSION_NAMEtodo-api-build REPO_PATH/path/to/my-todo-api tmux -S $TMUX_SOCKET new -d -s $SESSION_NAME cd $REPO_PATH ralphy --codex --verbose --prd PRD.md -- -c model_reasoning_effort\high\; EXIT_CODE\$?; echo Session finished with exit code: \$EXIT_CODE; openclaw system event --text Build session $SESSION_NAME exited with code \$EXIT_CODE --mode now; # 2. 列出所有活跃的构建会话 tmux -S $TMUX_SOCKET list-sessions # 3. 实时查看某个会话的最新输出类似tail -f tmux -S $TMUX_SOCKET attach -t $SESSION_NAME # 或者只捕获最后50行 tmux -S $TMUX_SOCKET capture-pane -t $SESSION_NAME -p | tail -50 # 4. 优雅终止会话发送Ctrl-C允许AI完成当前任务 tmux -S $TMUX_SOCKET send-keys -t $SESSION_NAME C-c # 强制终止会话 tmux -S $TMUX_SOCKET kill-session -t $SESSION_NAME5.4 性能调优与成本控制迭代长度控制在PRD中确保每个- [ ]任务粒度适中目标在3-5分钟内完成。过大的任务会导致单次API调用时间过长、成本高且容易出错过小的任务则会产生过多的上下文切换开销。模型选择策略原型与探索使用--sonnet成本最低。关键业务逻辑使用--codex追求正确性。UI/UX与代码美化使用--claude -- --effort high。利用项目内存.ralphy/progress.txt文件是黄金。确保AI在每次迭代后都有效地将“学到了什么”、“遇到了什么坑”记录进去。一个内容丰富的progress文件能极大减少后续迭代的重复探索和错误。设置验证命令PRD中的## Verification Commands章节至关重要。为每个任务或每组相关任务定义明确的、可自动运行的验证命令如npm test、go build、pylint。这是保证代码质量的自动化守门员。6. 模板化与标准化提升效率的关键openclaw-build的强大之处在于其可重复性。通过创建和使用模板你可以将成功的项目模式固化下来。6.1 PRD模板 (loops/templates/PRD.md.template)不要每次都从零开始写PRD。根据项目类型如“Express.js REST API”、“React Component Library”、“Python CLI Tool”创建模板。模板应包含标准化的章节结构概述、技术栈、API设计、数据库模型、测试策略。预置的验证命令如针对Node项目的npm run test:ci。任务拆分的通用模式如“初始化项目”、“实现核心Model”、“编写API路由”、“添加单元测试”、“配置CI/CD”。6.2 AI代理指令模板loops/templates/AGENTS.md.template和loops/templates/CLAUDE.md.template是为AI本身准备的“工作说明书”。你可以在这里定制代码风格规范缩进、命名约定、注释要求。文件组织规范项目目录结构应该怎样。特定框架的约定例如对于React项目要求使用函数组件和Hooks。安全与最佳实践例如“永远不要将API密钥硬编码在代码中”“所有用户输入必须经过验证”。在项目初始化时通过ralphy --add-rule将这些规则注入到项目的.ralphy/config.yaml中AI在后续的所有迭代中都会遵守这些规则从而保证项目代码风格的一致性。6.3 一个实战案例快速启动一个React Node.js全栈项目假设你经常需要搭建类似的全栈应用可以创建一套组合模板prd-templates/fullstack-react-node.md一个标准的全栈PRD模板包含前后端分离的任务清单。agent-rules/fullstack.yaml包含针对React和Node.js的特定编码规则。一个启动脚本bootstrap.sh#!/bin/bash PROJECT_NAME$1 mkdir $PROJECT_NAME cd $PROJECT_NAME git init # 复制PRD模板并替换项目名 cp /path/to/templates/fullstack-react-node.md ./PRD.md sed -i s/{{PROJECT_NAME}}/$PROJECT_NAME/g ./PRD.md # 初始化ralphy并添加规则 ralphy --init ralphy --add-rule $(cat /path/to/rules/fullstack.yaml) echo Project $PROJECT_NAME initialized. Review and approve the PRD.md, then run ralphy --codex --prd PRD.md to start.通过这种模板化、脚本化的方式你将openclaw-build从一个工具升级为一套属于你自己的、高效的“数字产品生产线”。它不再仅仅是执行任务而是在你定义的规范和最佳实践下可预测、可重复地生产出高质量的代码模块。这套工作流最深刻的体会是它把AI从一种“灵感火花”变成了一个“可靠工匠”。你不再需要担心它中途跑偏或突然罢工因为流程本身内置了纠错和续命的机制。花时间精心设计你的PRD模板和代理规则其回报远大于在单个项目上手动微调AI指令。当一切就绪后启动一个复杂项目就像下达一个精确的指令然后看着这台精密的机器一步步将其构建出来这种感觉才是人机协作应有的样子。