用途：当答案会实质性改变最终构建结果时，主动提出澄清性问题。适用于实现路径不明确、缺少关键上下文、可能具有破坏性的操作、范围模糊、需求冲突或存在技术取舍的情况。
主要能力：识别应提问或不应提问的时机；提供结构化提问模板，先说明已理解与分析的上下文，再给出2-5个具体选项及简要取舍，最后直接提问，必要时可主动提出采用合理默认方案。采用渐进式披露，逐层提问，而非一次抛出所有问题。
使用方式：先确认理解，例如“我发现你的 API 端点并看到你在使用 Express……”，随后列出具体方案（如全局中间件、包装函数、自定义错误类），再询问“哪种方式更符合你的需求？”；对不太关键的决策可提议默认选项并允许对方调整。收到答复后确认选择、立即继续执行，并在后续类似选择中延续其偏好。
适用场景：模糊的实现选择、缺失的关键信息（数据库类型、部署平台、凭据管理）、可能被危险解读的请求（“清理文件”是删除还是归档）、模糊术语（重构、优化、改进）、相互冲突的目标、依据优先级不同的技术权衡。
限制：请求清晰无歧义、可从代码库或项目上下文推断答案、问题不会实质影响实现、属于标准工程实践时，不应提问。避免过度澄清、只问“你是什么意思”这类过于模糊的问题，也不要在收到答案后再次询问是否继续。核心原则是：只在答案会实质性改变构建结果时提问，目标是避免做错东西，而不是为提问而提问。