ask_followup_question

ask_followup_question 工具通过提出具体问题来收集完成任务所需的额外信息，从而实现交互式沟通。

参数

该工具接受以下参数：

question (必填): 向用户提出的具体问题
follow_up (可选): 包含 2-4 个建议答案的列表，帮助引导用户回答，每个建议用 <suggest> 标签包裹

功能

该工具在 Kilo Code 和用户之间创建了一个对话界面，当遇到模糊不清或决策点时，可以用于收集澄清信息、额外细节或用户偏好。每个问题可以包含建议的响应，以简化交互。

使用场景

当原始请求中缺少关键信息时
当 Kilo Code 需要在多个有效的实现方法之间做出选择时
当需要技术细节或偏好才能继续时
当 Kilo Code 遇到需要解决的模糊不清的情况时
当额外的上下文会显著提高解决方案质量时

主要特性

提供结构化的方式来收集特定信息，而不会中断工作流程
包含建议答案以减少用户输入并引导响应
在交互过程中维护对话历史和上下文
支持包含图片和代码片段的响应
在所有模式下都可用，作为"始终可用"的工具集的一部分
支持用户直接指导实现决策
使用 <answer> 标签格式化响应，以区分常规对话
成功使用时重置连续错误计数器

限制

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

工作原理

当调用 ask_followup_question 工具时，它会遵循以下流程：

参数验证: 验证必需的 question 参数并检查可选建议
- 确保提供了问题文本
- 使用 fast-xml-parser 库从 follow_up 参数中解析任何建议答案
- 即使只有一个建议，也将建议规范化为数组格式

JSON 转换: 将 XML 结构转换为标准化的 JSON 格式以供 UI 显示

{
  question: "用户的问题在这里",
  suggest: [
    { answer: "建议 1" },
    { answer: "建议 2" }
  ]
}

UI 集成:
- 通过 ask("followup", ...) 方法将 JSON 结构传递给 UI 层
- 在界面中向用户显示可选的建议按钮
- 创建选择或输入响应的交互式体验
响应收集与处理:
- 捕获用户文本输入和响应中包含的任何图片
- 在返回给助手时用 <answer> 标签包裹用户响应
- 保留用户响应中包含的任何图片
- 通过将响应添加到历史记录中来维护对话上下文
- 在工具成功使用时重置连续错误计数器
错误处理:
- 使用计数器跟踪连续错误
- 在工具成功使用时重置计数器
- 提供特定的错误消息：
  - 对于缺少参数："缺少必需的参数 'question'"
  - 对于 XML 解析："无法解析操作：[错误消息]"
  - 对于无效格式："操作 xml 格式无效"
- 包含防止在缺少必需参数时执行工具的安全措施
- 发生错误时增加连续错误计数

工作流程

问题-回答周期遵循以下顺序：

信息差距识别: Kilo Code 识别出继续所需缺少的信息
具体问题创建: Kilo Code 形成一个明确的、有针对性的问题
建议开发: Kilo Code 创建相关的建议答案（可选但推荐）
工具调用: 助手使用问题和可选建议调用工具
UI 呈现: 问题和建议作为交互元素显示给用户
用户响应: 用户选择建议或提供自定义答案
消息处理: 系统处理部分和完整的消息
- 对于流式响应，在到达时处理每个块
- 对于完整消息，一次性处理整个响应
- 无论消息分块如何，都保持状态一致性
响应处理: 系统用 <answer> 标签包裹响应并保留图片
上下文集成: 响应被添加到对话历史中
任务继续: Kilo Code 使用新信息继续任务

使用示例

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

响应格式

当用户回答问题时，响应会用 <answer> 标签进行格式化，以提高清晰度和一致性。这种格式有助于将用户的回答与其他对话元素明确区分开来。

示例响应格式：

<answer>
使用 Tailwind CSS 进行实用优先的样式设计，具有最大的灵活性
</answer>

响应格式的关键特征：

用 <answer> 标签包裹
保留原始响应的格式
如果响应中包含图片，则保留图片
返回完整文本，即使是长响应

使用示例

询问实现偏好：

<ask_followup_question>
<question>你希望这个 Web 应用程序采用哪种样式方法？</question>
<follow_up>
<suggest>使用 Bootstrap 进行快速开发，具有一致的组件</suggest>
<suggest>使用 Tailwind CSS 进行实用优先的样式设计，具有最大的灵活性</suggest>
<suggest>使用自定义样式的原生 CSS，以获得完全控制和最小依赖</suggest>
</follow_up>
</ask_followup_question>

请求技术澄清：

<ask_followup_question>
<question>这个应用程序应该使用什么数据库来存储用户数据？</question>
<follow_up>
<suggest>MongoDB 用于灵活的模式和基于文档的存储</suggest>
<suggest>PostgreSQL 用于具有强一致性保证的关系数据</suggest>
<suggest>Firebase 用于实时更新和简化的后端管理</suggest>
<suggest>SQLite 用于轻量级本地存储，无需外部依赖</suggest>
</follow_up>
</ask_followup_question>

解决需求中的模糊性：

<ask_followup_question>
<question>应用程序应如何处理用户认证？</question>
<follow_up>
<suggest>实施带账户验证的电子邮件/密码认证</suggest>
<suggest>使用社交登录提供商（Google、GitHub 等）快速注册</suggest>
<suggest>同时实施电子邮件/密码和社交登录选项</suggest>
</follow_up>
</ask_followup_question>

参数​

功能​

使用场景​

主要特性​

限制​

工作原理​

工作流程​

使用示例​

响应格式​

使用示例​

参数

功能

使用场景

主要特性

限制

工作原理

工作流程

使用示例

响应格式

使用示例