使用 Ralph Wiggum 进行 AI 编码的 11 条建议

如果你正在使用 Claude Code、Copilot CLI、OpenCode 或 Codex 等 AI 编码命令行工具，这篇文章就是为你准备的。

大多数开发者以交互方式使用这些工具：交给它一项任务、观察它工作，并在偏离方向时介入。这就是“人在回路”（HITL）编码。

不过，现在出现了一种名为 Ralph Wiggum 的新方法。Ralph 会循环运行你的 AI 编码 CLI，让它自主处理任务列表。你负责定义需要完成什么，Ralph 负责弄清怎样完成，并持续运行到任务结束。换句话说，这是一种长时间运行、自主且无人监督的 AFK 编码方式。

本文不是快速入门教程。如果你想尽快运行起来，请阅读《Ralph 入门指南》。

11 条建议

1. Ralph 就是一个循环

过去一年左右，AI 编码经历了几个明显阶段。先简要定义一下：

氛围编程是让 AI 编写代码，却不进行真正检查。你只是跟着 AI 的“感觉”走，不加审视地接受建议。速度很快，但代码质量会受到影响。

规划是要求 AI 在编码前先制定计划。在 Claude Code 中，可以进入计划模式，让 AI 先探索代码库并形成计划，再开始写代码。质量会有所提高，但工作规模仍受单个上下文窗口限制。

多阶段计划把大型功能拆成多个阶段，每个阶段在独立上下文窗口中处理。你需要为每个阶段编写不同提示词，例如先“实现数据库模式”，再“添加 API 端点”，最后“构建 UI”。这种方式更容易扩展，但需要人类持续参与，为每个阶段编写提示词。

Ralph 简化了整个过程。你不再为每个阶段编写新提示词，而是循环运行同一个提示词：

# ralph.sh
# Usage: ./ralph.sh <iterations>

set -e

if [ -z "$1" ]; then
  echo "Usage: $0 <iterations>"
  exit 1
fi

# For each iteration, run Claude Code with the following prompt.
# This prompt is basic, we'll expand it later.
for ((i=1; i<=$1; i++)); do
  result=$(docker sandbox run claude -p \
"@some-plan-file.md @progress.txt \
1. Decide which task to work on next. \
This should be the one YOU decide has the highest priority, \
- not necessarily the first in the list. \
2. Check any feedback loops, such as types and tests. \
3. Append your progress to the progress.txt file. \
4. Make a git commit of that feature. \
ONLY WORK ON A SINGLE FEATURE. \
If, while implementing the feature, you notice that all work \
is complete, output <promise>COMPLETE</promise>. \
")

  echo "$result"

  if [[ "$result" == *"<promise>COMPLETE</promise>"* ]]; then
    echo "PRD complete, exiting."
    exit 0
  fi
done

每次迭代都会：

1. 查看计划文件，了解还需要完成什么
2. 查看进度文件，了解已经完成什么
3. 决定下一步做什么
4. 探索代码库
5. 实现功能
6. 运行反馈循环（类型检查、Lint 和测试）
7. 提交代码

这里最关键的改进是：由智能体选择任务，而不是由你选择。

使用多阶段计划时，每个阶段开始都要由人类编写新提示词。使用 Ralph 时，智能体会从 PRD 中自行选择下一项工作。你定义最终状态，Ralph 负责抵达那里。

我曾用 Ralph 为 AI Hero CLI 补充测试，也用它为课程视频管理器构建功能。还有人用它创建了完整的编程语言。

2. 先从 HITL 开始，再转为 AFK

Ralph 有两种运行方式：

对于 HITL Ralph，可以准备一个只运行一次迭代的 ralph-once.sh。你观察它的全部操作，并在需要时介入。

对于 AFK Ralph，务必限制迭代次数。随机系统中的无限循环十分危险。小任务我通常设置 5–10 次迭代，大任务则设置 30–50 次。

HITL Ralph 很像结对编程。你与 AI 一起工作，在代码生成过程中同步审查。你可以实时引导方向、参与实现，并共享对项目的理解。

这也是学习 Ralph 的最佳方式。你可以理解它具体会做什么、不断改进提示词，并在完全放手前建立信心。

当提示词足够可靠后，AFK Ralph 才会真正释放杠杆效应。让它开始运行，自己去做别的事，完成后再回来。

我做了一个小型 CLI，Ralph 完成时会通过 WhatsApp 通知我。这样可以大幅减少上下文切换，让我全身心投入另一项任务。我的循环通常持续 30–45 分钟，有时也会运行数小时。

采用过程很简单：

1. 先使用 HITL 学习并完善提示词
2. 提示词值得信任后，再切换到 AFK
3. 回来后审查提交记录

3. 明确工作范围

让 Ralph 开始运行前，必须先定义“完成”究竟是什么样。这意味着从制定步骤计划，转向收集和明确需求。你不再规定每一步怎样做，而是描述期望的最终状态，让智能体自己找出抵达方式。

定义范围的几种形式

可以用多种形式为 Ralph 定义范围：

• 一份 Markdown 用户故事列表
• GitHub issue 或 Linear 任务（后文会继续说明）
• 使用 beads

我很喜欢的一种方法来自 Anthropic 对长时间运行智能体的研究。他们把 PRD 条目组织成 JSON，并加入 passes 字段：

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": [
    "Click the 'New Chat' button",
    "Verify a new conversation is created",
    "Check that chat area shows welcome state"
  ],
  "passes": false
}

完成条目后，Ralph 会把 passes 标记为 true。这样，PRD 既定义范围，也跟踪进度；它是一份持续变化的 TODO 列表，而不是瀑布式文档。

为什么范围很重要

你并非必须提供结构化 TODO 列表。也可以只给 Ralph 一个模糊任务，例如“改进这个代码库”，然后让它自行跟踪进度。

但任务越模糊，风险越高。Ralph 可能永远循环下去，不断发现新的改进；也可能走捷径，在你认为工作尚未完成时就宣布胜利：

我曾让 Ralph 提高 AI Hero CLI 的测试覆盖率。仓库中有一些标记为内部、但实际上仍会面向用户的命令（我自己就在用）。我希望所有内容都有测试。

三次迭代后，Ralph 报告：“所有面向用户的命令都已完成。”但它完全跳过了内部命令，自行判断它们不面向用户，并把它们标记为不计入覆盖率。

解决方法是什么？准确写明希望覆盖哪些内容：

运行途中调整 PRD

这种方法有一个好处：Ralph 运行期间仍可随时调整。

• 已经实现但结果不对？把 passes 改回 false，补充说明，再次运行。
• 缺少某项功能？即使循环正在进行，也可以新增 PRD 条目。

你并不是在编辑一份线性的多阶段计划，而是在描述一个新的最终状态。Ralph 会设法抵达那里。

只要范围和停止条件足够明确，Ralph 就会知道何时输出 <promise>COMPLETE</promise>。

亲自试一试

为下一个功能使用计划模式并创建 prd.json 文件。可以使用以下提示词生成结构化 PRD 条目：

Convert my feature requirements into structured PRD items.
Each item should have: category, description, steps to verify, and passes: false.
Format as JSON. Be specific about acceptance criteria.

4. 跟踪 Ralph 的进度

我运行的每个 Ralph 循环都会生成 progress.txt，并直接提交到仓库。这个做法受到 Anthropic 关于长时间运行智能体运行框架文章的启发。

它解决了一个核心难题：AI 智能体就像极其聪明、却会在任务之间忘掉一切的专家。每个新上下文窗口都从零开始。没有进度文件，Ralph 就必须重新探索整个仓库，才能理解当前状态。

进度文件可以直接跳过这轮重复探索。Ralph 读取文件、了解已完成内容后，就能立即进入下一项任务。

进度文件应包含什么

内容应保持简单、精炼：

• 本次会话完成的任务
• 作出了哪些决策，以及原因
• 遇到的阻塞问题
• 修改过的文件

还可以记录刚刚完成的 PRD 条目、所有架构决策，以及留给下一次迭代的说明。

为什么提交记录很重要

Ralph 应在每项功能完成后提交代码。这样，后续迭代可以获得：

• 清晰展示变更内容的 Git 日志
• 通过 git diff 与之前工作进行比较的能力
• 出现问题时可以回滚的节点

进度文件与 Git 历史结合后，Ralph 无需消耗 Token 重新探索，也能获得完整上下文。

清理

不要永久保留 progress.txt。冲刺完成后就把它删除。它只服务于当前会话，并不是永久文档。

亲自试一试

在 Ralph 提示词中加入进度跟踪要求：

After completing each task, append to progress.txt:
- Task completed and PRD item reference
- Key decisions made and reasoning
- Files changed
- Any blockers or notes for next iteration
Keep entries concise. Sacrifice grammar for the sake of concision. This file helps future iterations skip exploration.

5. 使用反馈循环

Ralph 能否成功取决于反馈循环。提供的反馈循环越多，它生成的代码质量就越高。

反馈循环的类型

最佳设置应当在所有检查通过前阻止提交。只要测试仍然报红，Ralph 就不能宣布胜利。

为什么反馈循环很重要

优秀程序员不信任自己写的代码，也不信任外部库，尤其不信任同事。他们会建立自动化流程和检查机制，验证最终交付的内容。

这种谦逊会带来更好的软件，对 AI 智能体同样如此。

本文中的每条建议也都适用于人类开发者。反馈循环、小步前进、明确范围并不是 AI 专属技巧，而只是良好的工程实践。Ralph 让这些原则变得不可妥协。

亲自试一试

在 Ralph 提示词中明确加入反馈循环要求：

Before committing, run ALL feedback loops:
1. TypeScript: npm run typecheck (must pass with no errors)
2. Tests: npm run test (must pass)
3. Lint: npm run lint (must pass)
Do NOT commit if any feedback loop fails. Fix issues first.

6. 小步前进

获得反馈的速度，就是你的最高速度。永远不要跑到车灯照亮的范围之外。

人类进行大型重构时，可能一次吞下很大一块工作并一路做下去，让测试、类型检查和 Lint 连续数小时保持报错。把工作拆成更小部分，可以收紧反馈循环，在收到反馈前少走一段路。

Ralph 也遵循同样规律，而且还有额外限制：上下文窗口容量有限，内容越接近上限，LLM 的表现越差。这称为上下文腐化——运行得越久，输出越笨。

其中的取舍

每次 Ralph 迭代都有启动成本。它必须选择任务、探索仓库并收集上下文，这些 Token 每轮都要重新消耗。

如果正在进行大型重构，你当然不希望 Ralph 每次迭代只重命名一个变量。但需要注意：

• 任务越大，反馈越不频繁
• 上下文越多，代码质量越低
• 任务越小，质量越高，但进度越慢

控制 PRD 条目的大小

对于 AFK Ralph，应让 PRD 条目保持较小。既然你不在旁边观察，就更需要智能体维持最佳状态。

对于 HITL Ralph，可以把条目稍微放大，以便更快看到进展；即便如此，也应倾向于小任务。

一个重构条目可以简单到：“修改一个函数的参数，并确认测试和类型检查通过。”

应在提示词中指导 Ralph 控制步长。我的倾向是小步前进，代码质量优先于速度——尤其在 AFK 模式下，反正速度也没那么重要。

亲自试一试

在 Ralph 提示词中加入步长指导：

Keep changes small and focused:
- One logical change per commit
- If a task feels too large, break it into subtasks
- Prefer multiple small commits over one large commit
- Run feedback loops after each change, not at the end
Quality over speed. Small steps compound into big progress.

7. 优先处理高风险任务

Ralph 会自行选择任务。如果没有明确指导，它通常会选择列表中的第一项，或看起来最容易实现的内容。

这与人类行为如出一辙。开发者都喜欢快速取得成果，但经验丰富的工程师知道，应先解决困难部分，免得大量简单工作把你埋进技术债务。

技术尖峰与集成

优先进行技术尖峰，探索那些结果尚不确定的事情。按端到端方式构建功能，而不是逐层搭建，并尽早集成。

如果多个模块需要协同工作，应让 Ralph 先把它们集成起来。不要等到冲刺结束才发现它们根本无法配合。

高风险任务使用 HITL

高风险任务需要更多人类参与。早期架构决策应使用 HITL Ralph，因为这些任务生成的代码会长期保留，其中任何捷径都会向整个项目层层传导。

等基础稳固后再使用 AFK Ralph。架构经过验证、高风险集成能够工作后，就可以让 Ralph 无人监督地处理风险较低的任务。

亲自试一试

在 Ralph 提示词中加入优先级指导：

When choosing the next task, prioritize in this order:
1. Architectural decisions and core abstractions
2. Integration points between modules
3. Unknown unknowns and spike work
4. Standard features and implementation
5. Polish, cleanup, and quick wins
Fail fast on risky work. Save easy wins for later.

8. 明确定义软件质量

仓库之间并不相同。大量代码只是原型，例如演示、短期实验或客户提案。不同仓库对质量的要求也不同。

智能体并不知道自己身处哪类仓库，也不知道这是可丢弃原型，还是需要维护多年的生产代码。你必须明确告诉它。

需要明确传达什么

可以把这些要求写进 AGENTS.md、技能，或直接写入提示词。

代码库的事实更有分量

你的指令会与代码库争夺影响力。Ralph 探索仓库时会看到两个事实来源：你要求它怎样做，以及仓库实际上怎样做。前者只有几行指令，后者却是数千行证据。

你可以在提示词中写“绝不使用 any 类型”。但如果 Ralph 在现有代码中到处看到 any，它会效仿代码库，而不是遵守指令。

智能体会放大自己看到的东西。糟糕代码会产生更糟糕的代码，低质量测试会形成不可靠的反馈循环。

这就是软件熵，也就是代码库随时间逐渐恶化的趋势。Ralph 会加速这一过程。人类一天可能只提交一两次，Ralph 却能在数小时内堆入几十次提交。如果这些提交质量很低，熵会迅速复利增长。

这意味着你需要：

• 在放手让 Ralph 运行前，先保持代码库整洁
• 使用反馈循环（Lint、类型检查和测试）强制执行标准
• 让质量要求明确且可见

亲自试一试

在 AGENTS.md 或 Ralph 提示词中加入质量要求：

This codebase will outlive you. Every shortcut you take becomes
someone else's burden. Every hack compounds into technical debt
that slows the whole team down.

You are not just writing code. You are shaping the future of this
project. The patterns you establish will be copied. The corners
you cut will be cut again.

Fight entropy. Leave the codebase better than you found it.

9. 使用 Docker 沙箱

AFK Ralph 需要编辑文件、运行命令和提交代码的权限。那要怎样阻止它执行 rm -rf ~？你已经离开键盘，无法及时介入。

Docker 沙箱是最简单的解决方案：

docker sandbox run claude

它会在容器中运行 Claude Code，只挂载当前目录，不暴露其他内容。Ralph 可以编辑项目文件并提交代码，却无法触碰主目录、SSH 密钥或系统文件。

代价是全局 AGENTS.md 和用户技能不会被加载。对大多数 Ralph 循环来说，这并无大碍。

对于 HITL Ralph，沙箱是可选的，因为你正在旁边观察。对于 AFK Ralph，尤其是整夜运行的循环，沙箱则是防止智能体失控的必要保险。

10. 想获得能力，就要付费

我经常被问到：“这要花多少钱？”让 AFK Ralph 整夜运行，岂不是很容易积累巨额账单？

我不太愿意给出财务建议，尤其不愿对低收入国家的读者这样做。不过，Ralph 完全可以按照你愿意承担的预算进行配置。

HITL 依然值得

即使完全不运行 AFK Ralph，HITL Ralph 相比多阶段规划仍有明显优势。反复运行同一个提示词，比为每个阶段分别指定提示词轻松得多。

我使用 Anthropic 的 5x Max 套餐，每月大约 90 英镑。我运行过几次 AFK Ralph，但大多数使用仍然是 HITL。

为什么不用本地模型？

我认为，目前可以在笔记本电脑上运行的开源模型还不足以胜任 Ralph。它们需要强大的 GPU，输出质量也尚未达到要求。在 AI 编码领域，想获得这种能力，就必须付出成本。

黄金时代

不过，这件事需要放到更大的背景中看。未来几年仍是一个黄金时代：你可以借助 AI 以超越人类的速度完成近乎魔法般的工作，但市场仍按人类劳动水平支付报酬。市场尚未适应人人都能使用极其强大的 AI 编码工具这一事实。

是的，你必须付费。但只要愿意主动争取，回报也确实存在。

11. 打造你自己的 Ralph

Ralph 本质上只是一个循环。正因为简单，它几乎可以无限配置。下面是一些把它改造成自己版本的方法：

替换任务来源

本文示例使用本地 prd.json，但 Ralph 可以从任何地方获取任务：

核心洞见不变：任务由智能体选择，而不是由你选择。你只是改变了任务列表的存放位置。

改变输出方式

每次 Ralph 迭代不一定直接提交到主分支，也可以：

• 创建分支并发起 PR
• 为现有 issue 添加评论
• 更新变更日志或发布说明

当积压列表中有许多需要转化为 PR 的 issue 时，这种方式非常有用。Ralph 负责分诊、实现并发起 PR，你准备好后再进行审查。

其他循环类型

Ralph 并不只能处理功能积压列表。下面是我正在尝试的几种循环：

测试覆盖率循环：让 Ralph 读取覆盖率指标。它会查找未覆盖代码、编写测试并持续迭代，直到达到目标覆盖率。我用这种方法把 AI Hero CLI 的覆盖率从 16% 提升到 100%。

重复代码循环：把 Ralph 接入 jscpd 查找重复代码。Ralph 会识别克隆片段、重构为共享工具，并报告具体变更。

Lint 循环：把 Lint 错误交给 Ralph。它会逐一修复，并在迭代之间重新运行 Linter 验证每项修复。

熵减循环：Ralph 扫描代码坏味道，例如未使用的导出、死代码和不一致模式，并逐项清理。这是在逆转软件熵。

任何可以描述为“查看仓库、改进某项内容、报告发现”的任务，都适合 Ralph 模式。循环本身不变，改变的只有提示词。

亲自试一试

可以尝试以下替代循环提示词：

# Test Coverage Loop
@coverage-report.txt
Find uncovered lines in the coverage report.
Write tests for the most critical uncovered code paths.
Run coverage again and update coverage-report.txt.
Target: 80% coverage minimum.

# Linting Loop
Run: npm run lint
Fix ONE linting error at a time.
Run lint again to verify the fix.
Repeat until no errors remain.

# Entropy Loop
Scan for code smells: unused exports, dead code, inconsistent patterns.
Fix ONE issue per iteration.
Document what you changed in progress.txt.

我很期待看到你自己的 Ralph Wiggum——抠着鼻子、飞出窗户、吃着浆糊，同时还在交付代码。

想进一步了解 Ralph？我会在通讯中发布更多自主 AI 编码内容。订阅后，新文章发布时你就会收到通知。