DeepSeek 适合代码还是适合推理

[abc_1024]

DeepSeek 到底更适合写代码还是做推理？我看大家说法不一样。

[陈一]

它两个方向都有模型和场景，但要分任务。代码补全、bug 分析、复杂推理、中文问答不是同一个评测。

[小吴]

我们用 DeepSeek 做过代码审查，发现它能抓一部分明显问题，但对项目上下文依赖很大。

[Grace]

代码能力不只是生成函数。还包括读仓库、理解约束、跑测试、解释失败。模型只是链路一环。

[abc_1024]

那用它做 agent 会不会强？

[阿航]

Agent 强不强还看工具、上下文管理、权限和反馈循环。模型推理强，不代表会自动工程化。

[半截薯条]

我喜欢 DeepSeek 的性价比，但也遇到过“解释很顺，结论错”的情况。

[林小北]

所以代码任务要接真实验证。能跑测试就跑测试，不能只看回答像不像。

[普通网友A]

推理模型是不是都慢？

[melo]

通常会更贵或更慢一点，因为推理过程更长。生产里要决定哪些问题值得走推理模型。

[nora]

还有数据问题。代码仓库能不能发到云 API，要先确认。

[小蓝]

我们想做代码问答，不自动改代码。

[陈一]

那先做只读模式：检索文件、回答引用路径、让用户确认。别一开始就自动提交。

[abc_1024]

评测集该怎么做？

[Grace]

取真实 issue、历史 bug、代码风格约束、禁止事项。让它回答“该改哪里”和“为什么”，再人工判。

[小吴]

代码模型别在 demo 里看，放到旧 bug 上看。