编写单元测试时，最令人头疼的是什么？AI大模型往往直接输出一段代码，结果要么无法直接使用，要么测试跑不通。根本原因在于——它并不清楚被测方法的具体签名、边界条件究竟是什么、是否需要Mock外部依赖。今天这篇文章从实战角度出发，详细讲解如何让豆包在生成测试代码之前主动追问关键信息，而不是一上来就“硬写”。

首先需要明确三个前置要素：①被测方法的完整签名（包括类名、方法名、参数类型）；②预期行为边界（比如空参、异常输入如何处理）；③是否依赖外部服务（是否需要Mock处理）。当前项目基于Spring Boot 3.2 + Mockito 5，被测对象是@Service组件。请注意，不要问“方法的用途是什么”这类模糊问题——如果不明确告知方法具体做什么，你根本无法判断负数这类边界场景是否需要覆盖。

要打破AI默认“直接输出”的惯性，关键在于设计一套行之有效的提问模板。

用结构化提问模板触发追问机制

在提示词开头直接明确要求：“先提问，再生成”，并且限定首轮只允许提出3个问题。豆包对数字约束非常敏感——如果不说清楚数量上限，它大概率会跳过追问环节，直接开始写代码。

推荐的具体输入模板如下：

【请先向我提出最多3个关键问题，确认清楚后再生成JUnit 5风格的单元测试代码。问题需聚焦：①被测方法签名（含类名、方法名、参数类型）；②预期行为边界（如空参/异常输入如何处理）；③是否依赖外部服务（需Mock）】

这句话必须完整粘贴。如果遗漏“最多3个”或者“确认清楚后再生成”中的任意一个要素，豆包很可能立即开始编写测试代码，不再进行追问。

用具体技术栈锚定追问方向

方法一：指定框架+版本+典型场景

在提问模板后面紧跟上技术上下文，例如：“当前项目使用Spring Boot 3.2 + Mockito 5，被测类是@Service组件。”一旦豆包识别到Spring Boot与Mockito的组合，它会自动追问“是否需要验证@MockBean注入”或者“是否需@WebMvcTest切片测试”——这些才是真正贴合技术栈的实际问题。

方法二：给出错误示例反向约束

额外追加一句：“不要问‘方法功能是什么’这类模糊问题——如果我不告诉你方法用途，你无法判断输入参数是否要覆盖负数场景。”这句话能有效抑制豆包提出空泛问题的倾向，迫使其聚焦于可验证的技术细节。

拦截默认响应的强制手段

如果上述方法仍然无法阻止豆包直接输出代码，而它的第一条回复不是问题而是代码，该怎么办？

第一步：立即中断当前对话。

第二步：重新开启一个新对话，输入更强势的指令：“停止生成任何代码。现在只做一件事：列出3个必须由我确认才能写测试的问题。每个问题后标注‘（必答）’。”

第三步：等待豆包返回带有（必答）标记的问题列表，逐个回答后，再追加一句：“以上已确认，现在生成完整测试代码。”

【如果首次回复不是问题列表，直接放弃当前对话。重新开对话的成本远低于调试错误测试】