interview-and-create-plan

访谈并制定计划

强大的循环离不开强大的计划。Ralph RLM 循环每次尝试都会花费大量时间和金钱，而且每个工作进程都将 PLAN.md 视为比聊天记录更权威的依据。这项技能会制定这样的计划：一份经得起考验、易于执行的 PLAN.md，供循环据此运行——计划由你和用户共同制定，而不是凭空猜测。

输出是位于当前计划目录中的编写完成的 PLAN.md（运行 opencode-ralph-rlm plan-path 可获取准确位置——在命名计划布局中，它位于 .ralph-rlm/plans/<active>/PLAN.md；在旧版模式中，它位于仓库根目录）。文件一旦存在（且不再包含引导占位内容），start_loop 就会跳过重新引导，直接基于该文件启动第 1 次尝试。

不要急着动笔。访谈和设计讨论才是重点。先就目标和方案达成一致，再开始写任何内容。

流程

1. 理解

确保你理解当前情况，以及用户的真实需求。

• 如果你还不了解代码库的当前状态，就先探索仓库。
• 如果项目提供了领域术语表或词汇表，请使用其中的术语，并在整个过程中保持一致。
• 不断访谈用户，深入讨论计划或设计。目标是在编写任何代码之前，对想法进行压力测试。

访谈技巧

• 质疑术语的既有用法。 如果用户使用的术语与现有说法冲突，立即指出来。“你的词汇表将‘取消’定义为 X，但你似乎指的是 Y——究竟是哪一种？”
• 明确含糊的表述。 如果用户使用了模糊或含义过多的术语，提出一个精确的规范术语。“你说的是‘账户’——指的是 Customer 还是 User？两者并不相同。”
• 讨论具体场景。 讨论领域关系时，用具体场景进行压力测试。构造边界案例，促使用户明确概念之间的界限。
• 对照代码。 用户说明某项功能的工作方式时，检查代码是否一致。如果发现矛盾，就指出来：“你的代码会取消整个 Order，但你刚才说可以部分取消——哪种说法才对？”
• 讨论领域本身——词语的基本含义、计划涉及的类型和基本类型、它们之间的交互、不变量及其影响。
• 提出并说明假设。 明确隐含的假设，并复述给用户确认，包括对领域、现有代码的行为、数据形状、外部系统以及“完成”标准的假设。未说出口的假设会带来隐性风险；当用户对某件事不置可否时，明确指出你们共同采用的假设，并询问它是否成立。注明哪些假设有把握，哪些只是推测。
• 询问成功标准。 成功是什么样的？最终目标是什么？如何判断工作已完成？（这将成为完成定义，并应与循环的 verify.command 保持一致。）

2. 勾勒方案

勾勒出你将在哪里测试该功能，以及这些测试的边界。

• 优先使用现有边界，而不是创建新的边界。尽可能选择最高层级的边界。
• 如果需要新增边界，尽可能在最高层级提出。
• 跨代码库的边界越少越好——理想情况下只有一个。

向用户展示可能的解决方案，征求其审阅和指导——尤其是关于交互方式、成功标准、不变量、重要的具体技术决策以及 API 设计偏好。

确保能够清楚说明目标和拟议的解决方案，并确认用户同意这些内容。

展示总体方案，包括解决方案、里程碑和决策，让用户理解并达成一致。

不要包含具体文件路径或代码片段。 它们很快就会过时，循环会重新探索并找到所需内容。描述整体方案和意图，不要提及行号。

3. 制定计划

完成探索和讨论后，编写计划。

• 先说明高层目标和领域信息。
• 接着按步骤列出计划：里程碑、未决问题、成功标准、不变量、资源、用户的决定／引述、阻碍因素，以及重要备注／细节。
• 确保计划滴水不漏，易于遵循和实施。

将计划写入循环读取 PLAN.md 的路径。不要假定该路径位于仓库根目录——在命名计划布局中，文件位于 .ralph-rlm/plans/<active>/PLAN.md。运行以下命令以获取准确路径：

opencode-ralph-rlm plan-path

将 PLAN.md 写入该路径。保留循环所需的标题，至少包括 ## Goal、## Definition of Done 和 ## Milestones，并根据需要添加 ## Assumptions、## Open Questions、## Invariants、## Decisions 和 ## Notes。

在 ## Assumptions 中明确说明计划所依据的假设——包括已确认和未确认的假设，以便没有聊天记录的新工作者也能了解这些前提。对于任何尚未验证且会影响关键工作的假设（例如“API 返回 X”“此函数没有副作用”“该表已建立索引”），应添加一个早期里程碑，先测试／验证该假设——快速探查胜过多次尝试后才发现假设有误。依赖一切工作的未确认假设，是循环面临的最大风险。

4. 验证命令（循环的停止条件）

ralph.json 中的 verify.command 是循环判断工作是否完成的唯一依据——每次尝试后都会运行该命令，退出码为 0 即表示成功。计划的质量取决于此命令，因此应与用户共同认真制定：

• 命令必须实际测试目标，而不是仅执行 exit 0、空操作，或无论功能是否实现都能通过的构建。确保它与完成定义相符。
• 命令必须具有确定性，且运行速度合理（每次尝试都会执行）。
• 尤其重要的是，它应该在工作完成前立即失败——运行命令并确认基线测试未通过。如果命令已经通过，循环就会立即“成功”，什么也不做。

在 ralph.json 中设置该命令（例如 "verify": { "command": ["npm","test"], "cwd": "." }——要串联多个步骤时，请使用 ["bash","-c","…"]），然后运行一次，确认它因正确的原因失败。持续完善命令，直到它真正能判断“已完成”。

5. 评审

与用户一起评审计划：细节、具体内容、顺序和成功标准。

持续迭代，直到用户满意。将意见分歧视为访谈尚未结束的信号——返回并进一步完善。

6. 编写最终计划

编写最终经双方确认的 PLAN.md（写入 opencode-ralph-rlm plan-path 指定的位置）。

• 确认文件中不再包含引导占位文本。
• 确认完成定义与 ralph.json 的 verify.command 一致——该命令是循环判断是否“完成”的唯一依据。
• 告知用户计划已就绪：切换到 ralph-rlm/supervisor 模型，并发送“go”（或“start the loop”）。监督器会检测到已编写的计划，并在不覆盖计划的情况下启动第 1 次尝试。

移交给循环

此处生成	使用方
PLAN.md（目标、完成定义、里程碑、不变量）	每次工作者尝试——优先于聊天记录
双方确认的成功标准	应与 ralph.json 中的 verify.command 一致
未决问题／决定	监督器和工作者；解决后通过 update_plan 更新

RLM_INSTRUCTIONS.md（工作者操作手册）由循环的引导流程创建，与 PLAN.md 分开。应在 PLAN.md 中说明要构建什么；在 RLM_INSTRUCTIONS.md 中说明工作者应如何操作。