用Qwen2.5-Coder写单元测试总生成一堆无用mock，是我姿势不对吗？

温度0.2确实容易让模型走保守路线，我试过调到0.7之后mock明显少一些，但偶尔会跑偏。另外提示词里直接给个反面例子，比如“这种场景用sqlite内存库就行”，比单纯说“少用mock”管用得多。DeepSeek-Coder我也跑过类似任务，感觉它更倾向于先问清楚再动手，但生成代码的完整度不如Qwen。你试过把max_tokens调高到4096吗？有时候它是为了赶在截断前收尾才硬塞一堆mock。

试试把温度调到0.7，然后直接给它贴一段你手写的精简测试样例做few-shot，比纯提示词管用。

这问题我太有同感了，之前用Qwen2.5-Coder写测试也被mock淹没过。我觉得不全是prompt的锅，模型可能对“单元测试”的理解就是默认要隔离依赖，所以它倾向于把repository层整个mock掉。你试试在系统提示里直接给它一个反面例子，比如“如果数据库是sqlite内存模式，就优先用真实对象，仅在网络或外部API时才mock”，比单纯说“少用mock”具体得多。另外温度0.2确实偏保守，可以试到0.6左右，有时候多样性上来了反而会跳出那种模板化思路。至于DeepSeek-Coder，我只小规模跑过几次，感觉它在代码生成上更愿意直接操作真实对象，但有时候会忽略边界条件，两者算各有取舍。倒是想问问你有没有试过在prompt里限定“测试文件内禁止出现Mocker或patch关键字”这种硬约束，我试过效果比语义描述稳定不少。

说实话这问题我也踩过坑，qwen对mock的执念确实强，后来我干脆在prompt里直接给反面例子，比如“禁止mock repository，必须用sqlite内存模式”，效果比单纯强调要好。温度0.2可能也偏保守，我试过拉到0.6反而更愿意生成真实依赖。至于deepseek，它更倾向直接写集成测试，但偶尔会忽略边界情况，得看项目场景选吧。

温度0.2可能太低了，模型容易走保守套路，试试调到0.7再强调“先写集成测试再补mock”。

我也遇到过这问题，14B在测试生成上确实保守，尤其对db操作老想用mock兜底。后来我发现把“用sqlite内存库”作为硬性约束写进system prompt，比在任务描述里强调效果好很多。另外温度0.2可能偏低，我试过0.4，生成的测试风格会稍微大胆一点，但偶尔会飘。DeepSeek-Coder我也跑过一轮，它更倾向直接构造真实数据，不过对复杂依赖的容错率低些，容易编译报错。你vLLM部署的话，试试把max_tokens提到4096，有时候它想写完整测试但被截断就跑去mock了。

这问题我熟，当时用Qwen2.5-Coder也踩过一样的坑。感觉它默认把“测试”理解成“隔离依赖”，所以拼命mock，你干脆在prompt里直接给它看一段你想要的集成测试样例，比文字描述管用得多。另外温度0.2确实偏低，模型容易走保守套路，我试过调到0.4会稍微活泛一点，但也会偶尔抽风。DeepSeek那边我也跑过对比，它更倾向直接操作内存数据库，mock数量明显少，但偶尔会忽略边界条件，俩模型各有各的脾气。

14B就这样，换32B会好很多，或者试试在系统提示里直接写死“禁止mock数据库层”。

我试过类似情况，14B在代码生成上确实偏保守，尤其对数据库这块，它默认走mock路径，可能跟训练数据里单元测试的比例太高有关。你试试把“少用mock”改成更具体的指令，比如“必须用真实SQLite跑通增删改查”，效果会好不少。温度0.2可能也偏低了，我调到0.5左右，输出多样性会多点，没那么死板。DeepSeek-Coder我也跑过，感觉它对集成测试的理解更灵活，但生成速度慢一些，你可以拿同一个prompt对比下输出，差异挺明显的。

说实话我也遇到过这问题，后来发现光在系统提示里写“少用mock”没用，得直接在任务描述里给具体例子，比如让它参考某个已有的测试文件风格。另外温度0.2确实容易让模型走保守路线，我调到0.6以后生成的测试明显更敢用真实依赖了。至于DeepSeek-Coder，我个人感觉它更倾向于直接怼sqlite，但偶尔会忽略边界条件，两个模型各有各的坑。

试试把“少用mock”改成“禁止mock，必须用真实数据库”，温度调到0.1，效果会稳定很多。

试试在system prompt里直接塞一段你们项目的真实测试用例作为few-shot，比强调“少用mock”管用多了。

试试把sqlite示例直接写进system prompt里，比强调“少用mock”管用得多。