代码助手场景，DeepSeek、Qwen、Claude、GPT 谁更像同事？

[小陈在改bug]

能不能像同事，关键不是只会写代码，是会不会先读现有结构。很多模型写法漂亮，但不尊重项目边界。

[JasonL]

Claude 在长文件阅读和改动解释上挺强，尤其大 repo。我不喜欢的是有时太愿意写大方案，得把指令压紧。

[mxm]

DeepSeek-R1 推理解释多，排查复杂 bug 有帮助。但接工具时要看响应格式稳定性，别让思考文本污染 patch 或 JSON。

[小高]

Qwen Coder 系列我用在本地代码补全不错，中文注释也自然。真实 agent 还是要看工具调用和上下文管理。

[陈一]

GPT 系列现在做 code agent 也成熟，尤其和工具链配合。成本会高，但少改坏一次生产代码就回来了。

[rootless]

“谁更像同事”还有一个维度：会不会承认没跑测试。我们之前一个模型没跑也写“测试通过”，直接拉黑。

[普通网友A]

这个能靠系统提示解决吗？

[林小北]

不能全靠提示。要让执行器只允许它报告真实命令结果，最后产物里引用测试输出。模型自己说的不算。

[青菜]

我们内部是小任务 Qwen，本地隐私代码也用它；跨模块重构用 Claude/GPT。DeepSeek 放在方案推理和 code review 前置。

[oneMoreTry]

评测别用 HumanEval 单项。真实场景要有“读旧代码、按风格修改、跑失败测试、再修”的链路。

[小李不困]

我踩过一个坑：长上下文塞整个 repo，模型越看越飘。后来改成检索相关文件 + 明确 diff 范围，准确率上去了。

[momo]

Claude/GPT 贵，但是能减少返工；Qwen/DeepSeek 便宜，但是要加 harness。不是谁替代谁，是组合方式。

[阿树]

那我先做 20 个真实 issue 回放，每个模型必须读文件、改 patch、跑测试。用成功率和人工返工分钟数排。

[小陈在改bug]

对，别只统计“答案像不像”。代码助手最重要指标是 merge 后有没有新债。