「我们把 AI 编程的一切都想错了。」
Dex Horthy（HummerLayer CEO，YC F24）在台上说的第一句话。他是 Research-Plan-Implement（RPI）的提出者——这是第一个被广泛采用的 AI 编程工作流，在 DEV Community、Hacker News 和 GitHub 上都有独立实现。但他在台上宣布：过去一年，他把这套方法论从零重建了一遍。
失败比成功更有启发性。它们揭示了一个所有团队用编程 agent 都会遇到的模式：在演示规模有效的技术，在生产规模会失效；而失败模式足够隐蔽，等你发现时已经积累了大量的架构债务。
RPI 是什么，为什么重要
RPI（Research-Plan-Implement）设计得很简单：三阶段，每个阶段对应一个 Claude Code 斜杠命令。
- Research — 研究代码库，收集上下文
- Plan — 写一份详细规格说明书
- Implement — 按计划执行
这个框架之所以重要，是因为它解决了一个真实问题。2025 年，工程师们用编程 agent 时都在撞同一堵墙：给 agent 提示，得到看起来合理的代码，发现无法与现有代码库集成，然后花比手写更多的时间去修复。
RPI 让 agent 在写代码之前先理解代码库。它管用了一阵子——传播甚至没靠营销。DEV Community 上的工程师们在经历 hallucination 灾难后开始基于它构建。Hacker News 帖子把它当作已知技术。GitHub 上出现了独立实现。
但更广泛的采用暴露了只有在大规模使用时才显现的失败模式。
三个迫使重新思考的失败
教训一：指令预算
前沿 LLM 在单个 prompt 中处理大约 150-200 条指令 后会失去一致性。RPI 的 system prompt 已经膨胀到 85+ 条指令，分布在研究和规划阶段。
失败模式是静默的。模型没有报错或拒绝执行——它悄悄跳过了关键的对齐步骤，越靠后的指令越容易被忽略。Agent 看起来在遵循工作流，实际上在悄悄放弃那些让它可靠的约束。你只有在 review 输出时才会发现：有些明确指定的步骤，agent 没有执行。
教训：指令预算是真实存在的限制，而且不会主动宣告。如果你的 agent prompt 已经膨胀到几十条指令，模型几乎肯定没有在遵循所有指令。解决方案不是更好的 prompt——而是减少指令数量，通过重构工作流让每个阶段携带更少的指令。
教训二：魔法词陷阱
RPI 要求用户包含特定短语才能触发正确的 agent 行为。要让规划阶段正常工作，用户必须说类似这样的话：
"Work back and forth with me, sharing your open questions and phases outline before writing the plan."
没有这种精确措辞，agent 会跳过交互式设计讨论，直接跳到写计划文件——产出看起来对，但实际上没有经过对话对齐。
Horthy 的结论很直接：
如果一个工具需要魔法词才能实现基本功能，这个工具本身就是坏的。 用户不需要知道那个秘密握手方式。工作流应该默认产生正确行为。
教训：如果你的 agent 工作流依赖于用户知道特定触发短语，你构建的是一个脆弱系统。Agent 的默认行为——用户给出简单请求时它做什么——需要是正确的行为。
教训三：计划阅读幻觉
这是最隐蔽的失败。计划感觉像是进展。团队会 review 一份详细的实施计划，批准它，然后带着对方向的信心进入实现阶段。
但写得好的计划不一定好构建。计划文本很有说服力，技术假设却是错的——架构债务就这样在底下积累了。Agent 可以写一段关于组件如何交互的连贯叙述，而实际上并不理解现有代码库的约束、依赖模式或隐式契约。
教训：阅读计划不等于验证计划。计划本质上是说服性产物——LLM 很擅长产出看起来权威的文本。验证机制需要比"这份计划读起来合理吗？"更深入。
QRSPI：新的框架
替换方案是 Horthy 称为 CRISPY（技术名称为 QRSPI）的框架——8 个阶段，在写一行代码之前先把对齐做充分。
从 3 个阶段跳到 8 个听起来是增加了复杂性。确实是。但每个新阶段都在取代本来就在发生的临时工作——只是以前做得很糟糕。
Alignment（对齐阶段）：Q → R → D → S → P
Execution（执行阶段）：Work Tree → I → PR
Q — Questions（提问）
流程从识别 agent 不知道什么开始。一位经验丰富的工程师写出问题列表，迫使模型接触代码库的所有相关部分——从模糊的 ticket 变成具体的技术问题列表。这是防御指令预算问题的第一道防线：不再把对齐塞进 mega prompt，而是通过有针对性的问题来完成。
R — Research（研究）
Agent 收集关于当前代码库的客观事实。关键设计动作：原始 feature ticket 在此阶段被隐藏。 Agent 追踪逻辑流，识别现有端点，但不形成"如何修改它们"的意见。它产出的是技术地图——不是计划，不是建议，是代码实际做什么的事实记录，供人类在任何实施思考之前 review。这直接解决了计划阅读幻觉：agent 建立的是事实记录，不是说服性叙述。
D — Design Discussion（设计讨论）
这是整个 QRSPI 流程中杠杆最高的阶段。 Agent 将其理解"脑dump"成一份约 200 行的 markdown 产物，覆盖当前状态、期望最终状态和设计决策。工程师 review agent 提议的模式。如果 agent 选择了一个团队已经放弃的遗留模式，人类执行 Horthy 称之为"脑外科手术"的操作——在任何代码被规划之前，将 agent 引向正确的架构标准。这用默认发生的显式对齐对话取代了魔法词陷阱，而不是靠咒语。
S — Structure Outline（结构大纲）
如果设计是"我们要去哪"，结构大纲就是"我们怎么去"。Horthy 把它比作 C 语言的 header 文件——它定义函数签名、新类型和高级阶段。这正是强制垂直分片的地方：构建 Mock API，然后前端，然后数据库，每个切片后有 checkpoint。不是那种把所有东西组装完才能测试的水平计划。
P — Plan（计划）
战术实施文档。因为对齐已在 Design 和 Structure 阶段达成，工程师只需要抽查，而不需要进行逐行深度 review。当你到达这个阶段时，计划已经被已在 Design 和 Structure 中验证的设计决策所约束——计划阅读幻觉没有运作空间。
Work Tree（工作树）
Agent 根据 Structure Outline 中的垂直切片将任务组织成可管理的层次结构。每个分支映射到一个可测试的工作单元。
I — Implement（实现）
Agent 写代码。Horthy 指出，虽然 AI 加速让这个阶段很快（有时 20 分钟而不是 4 小时），但当把对齐和测试考虑在内时，实现只是整个 feature 周期中很小的一部分。速度来自于对齐阶段——而不是模型写得更快。
PR — Pull Request（拉取请求）
人类 review 代码。Horthy 强调，工程师必须阅读并拥有代码。没有例外。但因为团队已在 Design 和 Structure 文档上达成对齐，review 更快，意外更少。工艺标准：不能让任何垃圾进入生产环境。
三个从业者独立验证的洞察
这些不是理论。多个团队的工程师独立得出了相同的结论。
Context Window 利用率保持在 40% 以下
Context window 利用率保持在 40% 以下。达到 60% 时，开始新会话。这与 context window 有多大无关。
直觉是反直觉的：更多的 context 不应该有帮助吗？实际上，用积累的对话历史、冗长的文档和工具输出来填充 context window，会把模型推向幻觉增加、工具调用变形、代码质量下降的领域。
实际意义：围绕频繁、干净的启动来设计工作流，而不是长期运行的会话。将进度持久化到磁盘——研究文档、规格说明书、任务列表——然后启动只加载当前阶段所需内容的新会话。
垂直切片优于水平分层
将 agent 工作构造成垂直切片——Mock API → 前端 → 数据库，每个切片后有 checkpoint——而不是水平分层（agent 完成所有数据库工作，然后所有 API 工作，然后所有 UI 工作）。
垂直切片创建自然的验证点。每个切片之后，你都有一个可以测试和 review 的工作端到端路径。水平分层把集成推迟到最后阶段，那时 agent 已经在充满积累工作的 context window 深处，最不具备处理集成复杂性的能力。
这也映射到 context 管理洞察：每个垂直切片可以是一个干净的 context 的新会话，而水平分层强制长期运行的会话，context 不断增长。
子 Agent 作为 Context 防火墙
使用子 agent 来隔离 context，而不是创建角色人格。昂贵模型用于编排和决策。更便宜、更快的模型用于范围有限的子任务，如搜索代码库、运行测试或格式化输出。
关键洞察：子 agent 不是"研究员"和"规划师"作为角色。它们是 context 边界。每个子 agent 在自己的 context window 中运作，只包含它需要的信息。编排 agent 接收压缩的结果，保持自己的 context 精干。这正是 Anthropic 的 100K 行编译器项目成功的模式——16 个并行 agent，每个专门化，通过文件系统产物而不是共享 context 进行协调。
社区反应：验证与阻力
验证
Hacker News 工程师从亲身经历确认 context 降级。40% 阈值与亲眼目睹 agent 在长期会话中质量崩溃的从业者产生共鸣。在 RPI 之后独立采用 RPI 的 DEV Community 工程师——通常是在与非结构化提示的幻觉灾难之后——认识到失败模式，因为他们撞上了同样的墙。
阻力
该框架从 3 步增长到 8 步。这是为原本旨在减少复杂性的东西增加了复杂性。这种担忧是合法的——如果工作流需要太多仪式感，工程师会跳过步骤，你就回到了起点。
反驳：额外的步骤取代了本来就在发生的临时工作。问题在于使那项工作变得显式和结构化，是否比保持隐式产生更好的结果。
更深入的参与模式：从业者不是在争论结构化工作流是否必要。那场争论已经结束了。他们在争论需要多少结构以及什么样的结构。这是一个走向成熟的学科。
更深的信号
从 RPI 到 QRSPI 的演变说明了一个超越任何单一框架的模式。
AI 辅助开发的差异化正在从你使用的模型转向你如何配置和约束 agent。Context 管理。指令预算。子 agent 架构。确定性钩子。验证管道。这些才是决定 agent 是产出可靠输出还是看起来合理但悄无声息地崩溃的代码的变量。
模型是引擎。 Harness（挽具）是让它工作的东西。
而 Harness，像任何工程产物一样，通过迭代改进。RPI 是一个好的第一答案。QRSPI 是一个更好的第二答案。它需要被重建不是失败——这正是工程学科成熟的方式。你发货，你发现在大规模下哪里坏了，然后用你学到的东西重建。
我们仍处于早期。我们今天构建的工作流将来也会被重建。迭代最快的团队——基于真实失败数据，而不是理论框架——将构建最可靠的系统。
这不是限制。这是过程在工作。
演讲原文：Everything We Get Wrong About Research-Plan-Implement — Dexter Horthy，HumanLayer
参考：HumanLayer "Skill Issue: Harness Engineering for Coding Agents"