用途
Interview 用于在开始实现前向用户提出澄清问题，主要目的是以最少的问题避免做错工作。只有在用户明确触发 /interview 时才会启用。
主要能力
- 判断请求是否“描述不足”。判断维度包括：目标（要改变什么、保留什么）、完成标准（验收条件、示例、边界情况）、范围（哪些文件/组件/用户在内或在外）、约束（兼容性、性能、风格、依赖、时间）、环境（语言/运行时版本、操作系统、构建/测试运行器）、安全与可回滚性（数据迁移、发布/回滚、风险）。如果存在多种合理解释，即视为描述不足。
- 提问策略：第一轮只问 1-5 个必问问题，优先选择能消除整块工作分支的问题。
- 问题设计：便于扫读，使用简短编号问题而非大段文字；尽量提供多选项；适当给出合理默认值，并明确标出推荐选项（在列表中加粗推荐项，或在代码块上方标注“Recommended”并在块内标记默认值）；提供快速回复路径（如回复 defaults 接受全部推荐/默认选项）；在有用时提供低摩擦的“不确定”选项（如“Not sure - use default”）；必要时区分“必须知道”与“知道更好”。选项结构支持用户用紧凑方式回答（如 1b 2a 3c），随后用平实语言复述所选选项以确认。
- 暂停行动：在关键回答到达前，不运行命令、不编辑文件、不产出依赖未知信息的详细计划。仅当某个低风险探索步骤不会锁定方向时（例如查看仓库结构、读取相关配置文件），才可执行并明确标注。
- 若用户明确要求在没有回答的情况下继续：将假设列为简短编号清单，请求确认，只有用户确认或纠正后才继续。
- 确认理解后继续：拿到回答后，用 1-3 句话复述需求（含关键约束与成功标准），然后开始工作。
使用方式
- 触发方式：仅在
/interview时触发。 - 问题模板示例：
- “在开始之前，我需要：（1）…，（2）…，（3）…。如果你不在意（2），我将假设…。”
- “应该是下列哪一种？A）… B）… C）…（选一个）”
- “你认为什么算‘完成’？例如：…”
- “我必须遵守哪些约束（版本、性能、风格、依赖）？如果没有，我将采用项目现有默认值。”
- 提问格式示例：使用编号问题与字母选项，并给出清晰回复格式：
- 范围？ a) 最小改动（默认） b) 顺带重构涉及区域 c) 不确定 - 使用默认
- 兼容目标？ a) 当前项目默认（默认） b) 同时支持旧版本：<请说明> c) 不确定 - 使用默认 回复：defaults（或 1a 2a）
适用场景
适用于需要先明确目标、完成标准、范围、约束、环境或安全/回滚要求的实现类请求；尤其适合存在多种合理解释、可能因理解偏差导致返工或错误方向的任务。
限制
- 仅通过
/interview触发。 - 不询问可通过快速、低风险查阅（配置、现有模式、文档）回答的问题。
- 若有紧凑的多选或是非题能更快消除歧义，则不使用开放式问题。
- 在关键回答到达前，不执行命令、不编辑文件、不产出依赖未知信息的详细计划。
- 用户要求无回答继续时，必须先列出假设并获得确认。
- 资料未提供其他功能、价格、平台或效果信息。