本文基于HumanLayer联合创始人Dexter Horthy的演讲，提取其对RPI（研究-计划-实现）方法论的核心反思。关键教训包括：必须遵守模型的“指令预算”（约150-200条上限）；应放弃阅读冗长计划，转而深入审查生成的代码；避免依赖“魔法词语”来控制模型行为；以及将单一大型提示拆分为多个少于40条指令的专注提示。这些反思直接指向了构建更可靠、更可控的Claude Code工作流的根本方法。

Dexter Horthy 的 RPI 方法论反思：研究-计划-实现的教训与改进 #

HumanLayer联合创始人Dexter Horthy在MLOps社区的演讲中，对风靡一时的RPI（研究-计划-实现）方法论进行了坦诚的复盘。他的反思并非否定RPI的价值，而是直面了在大规模推广中暴露出的问题，并提出了具体的改进方案。这些经验对于任何使用Claude Code构建结构化工作流的团队都极具参考价值。

从RPI到CRISPY：为何需要方法论演进？ #

RPI最初的设计是让一个“巨型提示”承载整个研究、计划和实现的过程。Dexter指出，这种单体提示包含高达85条甚至更多的指令。然而，一个残酷的现实是：前沿LLM可靠遵循指令的数量存在上限。他引用的研究表明，这个上限大约在150到200条指令之间。

当你的CLAUDE.md、系统提示、工具描述以及MCP配置所占用的指令数，与你宏大的工作流指令数叠加时，模型很可能无法完整遵循所有步骤。结果就是，预设的关键交互步骤（如向用户提出设计问题）被跳过，模型直接生成了未经对齐的方案。

因此，改进的核心思路是控制流。不要试图用提示来引导复杂的逻辑分支，而是应该利用真正的编程控制结构（如if语句）来路由任务，让每个子任务都由一个更小、更专注的提示来处理。这引出了CRISPY工作流：将庞大的RPI拆分为问题 (Questions)、研究 (Research)、设计 (Design)、结构大纲 (Structure Outline)、计划 (Plan)、实现 (Implement) 和提拉请求 (Pull Request) 等阶段。每个阶段的提示都少于40条指令，确保了极高的指令遵循率。

三个关键教训与Claude Code实践启示 #

1. 指令预算：像管理内存一样管理你的提示 #

“指令预算”是一个至关重要的概念。它提醒我们，模型的注意力是有限资源。在Claude Code中，这意味着：

• 简化CLAUDE.md：避免冗长的描述。只保留最核心的架构规则、命令和模式。可以将其视为项目的精要指南，而非百科全书。
• 拆分工作流：与其设计一个/ultraplan命令来处理所有事情，不如将其拆分为/research、/design、/create-plan等更小的命令或子代理。每个命令专注于单一职责，指令数少，效果更好。
• 警惕“上下文沼泽”：过多的MCP服务器、技能描述或历史对话都会消耗指令预算，导致模型在核心编码任务上表现不佳。定期清理上下文，或使用/compact命令手动压缩，但要注意压缩可能丢失关键细节。

2. 不要读计划，去读代码：对齐发生在更早的阶段 #

Dexter坦承，早期建议“仔细阅读计划文件”是错误的。千行计划与千行代码的工作量相当，且计划在实现时常常“存在惊喜”。更关键的是，在阅读庞大计划上花费时间，其杠杆率很低。

改进方案是将对齐工作前置到两个更短、更聚焦的文档中：

• 设计讨论 (Design Discussion)：约200行的Markdown文档。它迫使模型“头脑风暴”出所有它发现的事实、它认为的方案、以及它不理解的问题。这是人类与智能体在“去哪里”这个根本问题上进行对齐的机会。你可以像进行脑外科手术一样，在这里纠正模型发现的错误模式。
• 结构大纲 (Structure Outline)：类似于“C语言头文件”，只描述功能的签名和顺序，而非具体实现。这让你能审查任务的分解方式（是垂直切片还是容易出错的水平切片？），并提前规划测试点。

对于Claude Code的实践：这意味着真正的代码审查（Code Review）应该聚焦于生成的代码本身。在实现阶段，可以配置一个专门的代码审查子代理来检查代码质量，而不是反复纠结于计划文件。设计讨论和结构大纲则应作为轻量级的PR文档，供团队在开始编码前快速对齐。

3. 告别“魔法词语”与研究的客观性 #

“魔法词语”问题是指，用户必须通过特定的提示词（如“与我来回讨论，从你的问题开始”）才能触发模型的预期行为。这暴露了提示工程的脆弱性。一个设计良好的工具不应依赖于用户无意中说出的“咒语”。

在RPI的研究阶段，为了获得客观的事实（而非带有偏见的观点），一个巧妙的技术是在研究上下文中隐藏原始需求单（Ticket）。即使用一个上下文窗口根据Ticket生成研究问题，然后在一个全新的、对具体需求一无所知的上下文窗口中，仅根据问题去扫描代码库并输出事实。这确保了研究结果是纯粹的“代码真相”。

对Claude Code技能（Skills）的启示：设计技能时，应确保其行为由技能文件本身清晰定义，而非依赖用户在调用时加入额外引导。例如，一个用于提取API端点的技能，其定义文件应明确其扫描范围和输出格式，确保每次调用都稳定、可靠。

总结：从追求速度到追求可靠的杠杆 #

Dexter的反思总结出一个核心目标：追求高杠杆率的工作，而非单纯的速度。将10倍速度与低质量（Slop）结合，长远看是低杠杆的。而通过精心设计的、分阶段的、指令预算可控的工作流，实现2-3倍的速度提升，并保持接近人工的质量，才是可持续的、高杠杆的策略。

这些教训直接映射到Claude Code的最佳实践：利用子代理和命令实现控制流分离，通过CLAUDE.md和技能定义精简的指令集，并始终将“人类在环”的审核点设置在最关键的位置——设计对齐与最终代码。构建你自己的CRISPY式工作流，或许是让你的Claude Code使用从“玩票”走向“专业工程”的关键一步。

FAQ #

Q: 如何为我的Claude Code工作流设计“指令预算”？ A: 一个实用的方法是检查你的CLAUDE.md文件、任何长篇的技能或命令定义文件。确保每个提示（包括系统上下文、工具说明）的核心指令总数不超过150条。将大型任务拆分为多个由子代理或独立命令处理的阶段，每个阶段的提示指令数应少于40条。

Q: “不要读计划去读代码”的建议，是否意味着计划阶段不重要？ A: 完全不是。计划阶段（现在被拆分为设计讨论和结构大纲）变得更加关键和高效。它从一份需要深入解读的“实施蓝图”，转变为一个用于快速对齐和纠错的“对话式设计文档”。你需要在生成大量代码前，确保与团队（和模型）就方向达成一致，而这个阶段正是做这件事的最佳时机。