大家用开源代码模型写生产代码时，真的敢直接跑吗？

胶水代码随便跑，核心业务逻辑我都是手写，RAG喂上下文试过，效果一般还费劲。

生成的东西也就当个高级补全用，敢直接合生产代码的心是真大，异步坑太多了。

我基本只敢让它写胶水代码和测试桩，涉及ORM和事务的逻辑还是自己手写靠谱。之前试过把公司核心库做成RAG喂给它，效果确实比裸模型强不少，但上下文一长就乱，而且维护索引挺费劲的。你提到那种“看起来对”的错，我怀疑是模型在训练数据里见过类似结构但没真正理解你的业务约束，补全本质是概率预测。

说实话我跟你情况差不多，32B本地跑起来看着挺美，但一碰真实业务就露馅。我现在的做法是拿它当高级自动补全用，只让它写那种跟现有代码库交互最少的纯函数或者DTO转换，但凡涉及ORM、事务或者异步上下文，我连生成的骨架都要从头捋一遍，因为踩过太多次“看起来对”的坑了。

关于RAG喂公司代码库，我试过一阵子，效果得看你怎么切分和检索。如果只是把整个仓库塞进去，模型经常抓到一堆不相关的旧接口，反而比通用模式更误导。但如果你能按模块或者按业务链路做索引，并且把关键状态机的定义单独抽出来当上下文，生成的代码跟现有风格的贴合度确实高不少，至少不会再把异步生成器当列表用了。

不过还有个隐藏问题，就算上下文对了，模型对“隐性约定”的理解还是差口气，比如我们项目里某个service方法必须手动关连接，这种写在注释里的潜规则它大概率忽略。所以我现在最务实的工作流是：让模型出初稿，然后我重点检查所有涉及副作用和资源释放的部分，再跑一遍完整的集成测试，不敢直接信。

另外你说的漏事务提交，我怀疑跟训练数据里很多示例代码为了简洁省略了commit有关系，这个靠RAG也难根治，只能靠测试兜底。你有没有试过给模型喂几个你们项目里“正确写法”的few-shot示例？我体感比单纯给描述管用。

只敢用来写测试和边缘胶水逻辑，核心业务还是得自己盯。RAG喂公司代码库确实有用，但检索质量不行照样白搭。

我们组现在就是拿它写测试和胶水代码，业务逻辑顶多当个草稿，改完还得自己逐行过。RAG试过，把内部SDK和常见调用模式索引进去后确实少犯低级错误，但检索质量很关键，切得不好反而带偏。感觉现阶段最实际的用法是让它补全有明确契约的片段，复杂状态流转还是得人盯着，不敢直接合。

我们组从去年开始就在生产项目里用Qwen2.5-Coder 32B配合Continue，说“敢直接跑”那肯定是不敢的。简单函数和测试桩确实能省不少时间，但凡是牵扯到项目里的ORM调用、事务边界、异步上下文管理这些，模型基本就是在猜——它见过太多通用模式，但对你项目里那套封装完全没概念，漏commit、把async with当同步用这种错太常见了。我们的做法是补全结果只当草稿，必须过review，而且写业务逻辑的人自己得先想清楚，不能指望模型替你设计状态流转。胶水代码和测试用例倒是可以直接用得多，那块容错高、跑挂了大不了重写。RAG我们试过一版，把公司核心库的代码和接口文档切块喂进去，效果确实比裸模型强不少，尤其是它开始能正确调用内部工具类了，但检索质量很吃切分策略，切太碎丢上下文，切太粗又塞不进窗口。现在还在调，暂时没敢让它碰核心链路，更多是辅助理解老代码。你们那边RAG用的是向量库还是混合检索？我总觉得纯向量对代码这种结构化东西召回不太稳。