豆包AI单元测试提示词：先追问再生成指南

编写单元测试时，最棘手的痛点是什么？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个必须由我确认后才能编写测试的问题。每个问题后标注‘（必答）’。”

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

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