Lzh on GitHub

ask_followup_question

了解如何在 Roo Code 中使用 `ask_followup_question` 工具进行交互式通信，以收集澄清和用户偏好。

ask_followup_question 工具通过提出具体问题来启用交互式通信，以收集有效完成任务所需的额外信息。

参数

该工具接受以下参数：

  • question (必需)：要向用户提出的具体问题
  • follow_up (可选)：2-4 个建议答案的列表，每个都在 <suggest> 标签内，以帮助引导用户响应

功能

该工具在 Roo 和用户之间创建一个对话界面，以便在遇到歧义或决策点时，收集澄清、额外细节或用户偏好。每个问题都可以包含建议回复，以简化交互。

使用时机

  • 原始请求中缺少关键信息时
  • 当 Roo 需要在多种有效的实现方法中进行选择时
  • 当需要技术细节或偏好才能继续时
  • 当 Roo 遇到需要解决的歧义时
  • 当额外的上下文可以显著提高解决方案质量时

主要功能

  • 提供一种结构化方式来收集特定信息，而不会中断工作流程
  • 包含建议答案以减少用户打字并引导回复
  • 跨交互维护对话历史和上下文
  • 支持包含图像和代码片段的回复
  • 作为“始终可用”工具集的一部分，在所有模式下都可用
  • 启用关于实现决策的直接用户指导
  • 使用 <answer> 标签格式化回复，以将它们与常规对话区分开来
  • 成功使用后重置连续错误计数器

局限性

  • 每次使用工具仅限于询问一个具体问题
  • 在 UI 中将建议作为可选项呈现
  • 无法强制结构化回复——用户仍然可以自由回复
  • 过度使用会减慢任务完成速度并造成碎片化的体验
  • 建议答案必须是完整的，没有需要用户编辑的占位符
  • 没有内置的用户回复验证
  • 不包含强制特定答案格式的机制

工作原理

当 ask_followup_question 工具被调用时，它遵循此过程：

  1. 参数验证：验证必需的 question 参数并检查可选的建议
  • 确保提供了问题文本。
  • 使用 fast-xml-parser 库从 follow_up 参数中解析任何建议答案。
  • 即使只有一个建议，也会将建议标准化为数组格式。
  1. JSON 转换：将 XML 结构转换为用于 UI 显示的标准化 JSON 格式
{
  question: "User's question here",
  suggest: [
    { answer: "Suggestion 1" },
    { answer: "Suggestion 2" }
  ]
}
  1. UI 集成：
  • 通过 ask("followup", ...) 方法将 JSON 结构传递给 UI 层。
  • 在界面中向用户显示可选择的建议按钮。
  • 创建一个用于选择或输入回复的交互式体验。
  1. 回复收集和处理：
  • 捕获用户文本输入和回复中包含的任何图像。
  • 在返回给助手时，将用户回复包装在 <answer> 标签中。
  • 保留用户回复中包含的任何图像。
  • 通过将回复添加到历史记录来维护对话上下文。
  • 成功使用工具后重置连续错误计数器。
  1. 错误处理：
  • 使用计数器跟踪连续错误。
  • 成功使用工具后重置计数器。
  • 提供具体的错误消息：
    • 对于缺少参数：“缺少必需参数 'question'”。
    • 对于 XML 解析：“解析操作失败：错误消息”。
    • 对于无效格式：“无效的操作 xml 格式”。
  • 包含防止在缺少必需参数时执行工具的保护措施。
  • 发生错误时增加连续错误计数。

工作流序列

问答循环遵循此序列：

  1. 信息缺口识别：Roo 识别继续进行所需的缺失信息。
  2. 具体问题创建：Roo 制定一个清晰、有针对性的问题。
  3. 建议开发：Roo 创建相关的建议答案（可选但推荐）。
  4. 工具调用：助手调用带有问题和可选建议的工具。
  5. UI 呈现：问题和建议作为交互式元素显示给用户。
  6. 用户回复：用户选择一个建议或提供自定义答案。
  7. 消息处理：系统处理部分和完整的消息
  • 对于流式传输的回复，在块到达时进行处理。
  • 对于完整的消息，一次处理整个回复。
  • 无论消息分块如何，都保持状态一致性。
  1. 回复处理：系统将回复包装在 <answer> 标签中并保留图像。
  2. 上下文集成：回复被添加到对话历史中。
  3. 任务继续：Roo 使用新信息继续执行任务。

使用示例

  • 在开发 Web 应用程序时，Roo 可能会询问首选的样式框架（Bootstrap、Tailwind、自定义 CSS）。
  • 在创建 API 时，Roo 可能会询问身份验证方法（JWT、OAuth、API 密钥）。
  • 在重构代码时，Roo 可能会询问是优先考虑性能还是可读性。
  • 在设置数据库时，Roo 可能会询问具体的模式设计偏好。
  • 在创建自定义功能时，Roo 可能会询问具体的行为预期。
  • 在排除错误时，Roo 可能会询问具体的环境细节。

回复格式

当用户回复一个问题时，回复会被格式化为带有 <answer> 标签，以提高清晰度和一致性。这种格式有助于将用户的答案与其他对话元素清晰地区分开来。

示例回复格式：

<answer>
  Use Tailwind CSS for utility-first styling with maximum flexibility
</answer>

回复格式的关键特征：

  • 被 <answer> 标签包围。
  • 保留原始回复的格式。
  • 如果回复中包含图像，则保留图像。
  • 返回完整的文本，即使是长回复。

使用示例

询问实现偏好：

<ask_followup_question>
<question>Which styling approach would you prefer for this web application?</question>
<follow_up>
<suggest>Use Bootstrap for rapid development with consistent components</suggest>
<suggest>Use Tailwind CSS for utility-first styling with maximum flexibility</suggest>
<suggest>Use vanilla CSS with custom styling for complete control and minimal dependencies</suggest>
</follow_up>
</ask_followup_question>

请求技术澄清：

<ask_followup_question>
<question>What database should this application use for storing user data?</question>
<follow_up>
<suggest>MongoDB for flexible schema and document-based storage</suggest>
<suggest>PostgreSQL for relational data with strong consistency guarantees</suggest>
<suggest>Firebase for real-time updates and simplified backend management</suggest>
<suggest>SQLite for lightweight local storage without external dependencies</suggest>
</follow_up>
</ask_followup_question>

解决需求中的歧义：

<ask_followup_question>
<question>How should the application handle user authentication?</question>
<follow_up>
<suggest>Implement email/password authentication with account verification</suggest>
<suggest>Use social login providers (Google, GitHub, etc.) for quick signup</suggest>
<suggest>Implement both email/password and social login options</suggest>
</follow_up>
</ask_followup_question>