大家用开源编程模型写生产代码时，真的敢直接信任它的重构建议吗？

核心业务我绝不敢直接粘，都是让它给思路自己再写一遍。建议先让它写单测，跑通再改实现，稳很多。

我跟你感受差不多，工具脚本随便让它写，核心业务逻辑真不敢直接粘。我现在是让它先输出单测用例，跑通了再考虑合并实现，但就算这样也得自己再过一遍事务和边界。本地模型对上下文理解还是浅，尤其是老项目里那些隐藏的副作用，它根本看不出来。反正就当个提速的草稿机，最终review不能省。

我一般只让它写单测和工具类，核心业务方法体不敢直接粘。之前试过先让它生成实现再让它写测试，结果它写的测试迁就自己实现，边界照样漏。现在改成先手写接口和单测，再让它填实现，跑不过就重来，心里踏实不少。

我拿Qwen2.5-Coder干过类似的事，不过是在一个Python的订单状态机模块上。它的重构建议确实漂亮，把一堆if-else拍成了策略模式，但有个状态转换漏了回滚逻辑，测试直接挂。后来我就定了个规矩：它生成的代码只当草稿，绝不让它碰事务、并发、缓存这些地方。你那个懒加载的NPE太典型了，模型对JPA的fetch策略理解经常是纸上谈兵，它知道概念但不知道你项目里实际配了啥。我现在是让它先写测试用例再写实现，但测试也得我自己审一遍，不然它连测试都给你漏边界。核心业务逻辑我基本只让它做提取方法、改命名这种机械活，稍微带点业务语义的它就容易自作聪明。说实话，把它当个记忆力超好的实习生就行，能帮你省打字时间，但签字画押的事还得自己来。