DeepSeek V3 两周使用总结

qaz

2024 年 12 月 26 日，杭州深度求索人工智能基础技术研究有限公司发布 DeepSeek-V3 大模型。官方宣称：（1）基于自研的 MoE 模型和 671B 参数，在 14.8T token 上进行了预训练；（2）多项评测成绩超越了 Qwen2.5 - 72B 和 Llama - 3.1 - 405B 等其他开源模型，在性能上与世界顶尖的闭源模型 GPT-4o 以及 Claude-3.5-Sonnet 不分伯仲。个人自 2025 年 1 月 3 日开始试用，至今两周零两天，以下是使用过程中的心得体会与经验总结，仅供参考。
DeepSeek V3 免费使用地址：https://chat.deepseek.com/
一、先说结论

以下结论仅针对免费使用版（非开源版）：
（1）优点：整体回答效果优于 GPT-4o（GPT-4o 温度设置为 0.8，下同）。
（2）不足：给出错误答案的概率高于 GPT-4o。
（3）适用范围：相比 GPT-4o，DeepSeek V3 更适合用于解答开放式问题。对于较为具体的细节问题，两者各有优势，GPT-4o 更保守且更可靠，DeepSeek 广度和维度更高但也更容易出错。建议根据实际需求选用或两者参照使用。
（4）个人选择：目前在日常工作中，开放性问题以 DeepSeek V3 为主、GPT4-o 为辅；细节问题则对照两者使用，且仍以 DeepSeek V3 的回答为主并二次验证。
二、使用过程

1. 一天尝鲜试用 - 确实不错

1 月 3 日周五，在上班路上刷阮一峰的 科技爱好者周刊（第 332 期）：西蒙·威利森的年终总结，梁文锋的访谈。看到阮大师分享及推荐了 DeepSeek V3，而后在朋友圈也看到一些推荐和分享。当天是周五，组内有新技术探索安排，于是我抱着好奇、尝鲜、怀疑和谨慎的态度测试了一下，看看 DeepSeek V3 是否真如宣传所说那么好？
我承认刚开始我是怀疑的，以为又是个嘴炮，毕竟类似的事情遇到不少，前几天刚被 Logback 坑了，Logback 官方自称其性能远高于 Log4j2，实际上只是在某个时间点（2021 年），在特定配置和特定版本下的极限测试结果，且其测试基准不符合实际生产环境需求，比如将 FileAppender 的 immediateFlush 设置为 false，所以无实际指导性意义。时至今日，两者真实性能已截然不同，在当前最新版本和相同配置下，两者性能总体相当，甚至在部分场景下 Logback 性能反而不如 Log4j2，向作者反馈后，他仍旧选择了沉默，更别说同步更新或撤销Logback 性能说明文档。
由于之前有多次类似工作，积累了不少 CASE，于是选取了其中部分典型的研发 CASE，以 GPT-4o 为基准，快速测试及验证。
当时的结果及初步结论如下：
（1）DeepSeek V3 在研发技术方面的回答效果略好于 GPT-4o，得分为 106.5 分（以 GPT-4o 为基线，总分为 100 分）。
（2）官方文档比较简陋，WEB 页面功能少，设计和交互体验一般。
（3）部分问答结果感觉是在 GPT-4 基础之上做了升华和补充，有些怀疑其使用了 GPT-4 的训练数据。网络上也有类似的声音：DeepSeek 把自己误认成了 ChatGPT？分析人士称，或用了 GPT 生成文本做训练数据。
部分测试 CASE 如下：
编号问题DeepSeek V3 回答评分（GPT-4o 为 10 分）1以下内容是否包含敏感信息：XXX92Ingress 中可以配置超时时间为 30ms 么73Java 中使用 Thread.sleep() 设置等待时间可能有误差么114微服务架构有哪些组成部分？在 Java 中有哪些实现方案，应该如何选型？115ts 中如何避免滥用 any 类型126wrk2 解决了 wrk 哪些不足117Maven enforce 插件解决什么问题？有哪些功能？128Java 中如何评估一个方法的性能？129js 中如何获取用户网络情况？10.510基于 snowflake 算法，使用 Java 实现分布式 id10说明： 以上 CASE 仅供参考，评分结果依赖个人主观评价。由于大语言模型先天存在幻觉问题，无法保证答案及其效果的可重复性。
2. 一周进阶使用 - 缺点很致命

尝鲜后，感觉 DeepSeek V3 确实不错，远超预期。不过心中仍有所保留，国产大模型（含商业版）各个都说自己不亚于 GPT-4，但实际使用来看，暂时还没有综合实力比 GPT-4 强的产品。此外，既然 DeepSeek V3 效果比 GPT-4o 好，是否应该将其作为我日常工作的第一 LLM？我不可能长时间将同一问题，同时向 GPT-4o 和 DeepSeek 发问，而后细看两者回答，最后再取长补短。所以本阶段我将日常工作中遇到的各类问题，同时向 DeepSeek V3 和 GPT-4o 提问，通过对比两者效果，以帮助我更客观和更全面地判断两者优劣，便于我未来二选一。
使用总结：
（1）DeepSeek V3 的问答效果波动性较大，不靠谱的概率较高，好的时候比 GPT-4 好不少，差的时候则各种瞎说。
举例三个明显坑爹的回答：
（1）RandomAccessFile 竟然使用了内存映射文件的技术？事实当然不是

（2）FileAppender 竟然不支持无 GC 模式，MemoryMappedFileAppender 竟然支持文件滚定？事实与之相反

（3）RandomAccessFile 中 immediateFlush 默认值竟然是 false？实际上 immediateFlush 默认值是 true

3. 一周深度使用 - 选对场景避短扬长

经上阶段使用后，由于 DeepSeek V3 的缺点（给出错误答案的概率高于 GPT-4o）很致命，一度让我想放弃。然而，它的优点（整体回答效果优于 GPT-4o）又让我十分不舍，比如在尝鲜阶段测试 CASE 中的“ts 中如何避免滥用 any 类型”问题上，DeepSeek V3 的回答是迄今为止我见过的最好的，没有之一。相比坑爹的回答，优秀案例比例更高。所以在本阶段，继续使用 DeepSeek V3，希望能总结其特点，找到合适的适用场景，从而最大化地发挥它的优势。
经过一周使用后，个人认为：DeepSeek V3 更适合用于解答开放式问题。对于较为具体的细节问题，两者各有优势，GPT-4o 更保守且更可靠，DeepSeek 广度和维度更高但也更容易出错。建议用户根据实际需求选用，或两者参照使用。
三、总结与建议

（1）从个人使用来看，DeepSeek V3 效果确实很好，还能免费使用，NB。期望 DeepSeek V3 能越做越好，能优先支持自定义 BOT。
（2）个人建议在日常工作中，开放性问题可以以 DeepSeek V3 为主、GPT4-o 为辅；细节问题则对照两者使用，以 DeepSeek V3 的回答为主，并进行二次验证。
四、附优秀案例 - DeepSeek V3 关于“ts 中如何避免滥用 any 类型”问题的解答

在 TypeScript 中，any 类型是一种“逃逸舱”，它可以绕过类型检查，但过度使用 any 会削弱 TypeScript 的类型安全性。为了避免使用 any，可以采取以下策略：
1. 明确类型

始终为变量、函数参数和返回值指定明确的类型，而不是使用 any。
示例：
// 不推荐function processData(data: any) {    // ...}// 推荐function processData(data: { id: number; name: string }) {    // ...}2. 使用联合类型

当某个值可能是多种类型时，使用联合类型（|）而不是 any。
示例：
// 不推荐let value: any;// 推荐let value: string | number;3. 使用类型别名或接口

对于复杂的数据结构，使用类型别名（type）或接口（interface）定义类型。
示例：
// 不推荐function getUser(user: any) {    // ...}// 推荐interface User {    id: number;    name: string;    email: string;}function getUser(user: User) {    // ...}4. 使用泛型

当函数或类需要处理多种类型时，使用泛型（Generic）而不是 any。
示例：
// 不推荐function identity(value: any): any {    return value;}// 推荐function identity<T>(value: T): T {    return value;}5. 使用类型断言

如果明确知道某个值的类型，可以使用类型断言（as）而不是 any。
示例：
let value: unknown = "Hello, TypeScript";// 不推荐let length = (value as any).length;// 推荐let length = (value as string).length;<hr>6. 使用 unknown 类型

当类型不确定时，使用 unknown 类型而不是 any。unknown 是类型安全的，因为它要求在使用前进行类型检查。
示例：
// 不推荐function processValue(value: any) {    // ...}// 推荐function processValue(value: unknown) {    if (typeof value === "string") {        console.log(value.toUpperCase());    } else if (typeof value === "number") {        console.log(value.toFixed(2));    }}7. 使用类型守卫

通过类型守卫（Type Guard）缩小 unknown 或联合类型的范围。
示例：
function isString(value: unknown): value is string {    return typeof value === "string";}function processValue(value: unknown) {    if (isString(value)) {        console.log(value.toUpperCase());    }}8. 使用工具类型

TypeScript 提供了许多工具类型（Utility Types），可以帮助避免 any。
示例：
// 使用 Partial<T> 表示部分属性可选interface User {    id: number;    name: string;    email: string;}function updateUser(user: Partial<User>) {    // ...}9. 启用严格模式

在 tsconfig.json 中启用严格模式，可以避免隐式的 any。
示例：
{  "compilerOptions": {    "strict": true  }}严格模式包括以下选项：

• noImplicitAny：禁止隐式的 any 类型。
  
• strictNullChecks：确保变量不能为 null 或 undefined。
  
• strictFunctionTypes：确保函数参数类型严格匹配。
  
• 等等。
  

10. 使用第三方库的类型定义

如果使用第三方库，确保安装了对应的类型定义文件（@types 包）。
示例：
npm install --save lodashnpm install --save-dev @types/lodash11. 逐步替换 any

如果项目中已经存在大量 any，可以逐步替换：

• 使用 eslint 或 tslint 禁止使用 any。
  
• 逐步为每个 any 添加明确的类型。
  

12. 使用 never 类型

对于不可能存在的值，使用 never 类型。
示例：
function throwError(message: string): never {    throw new Error(message);}总结

避免使用 any 是编写高质量 TypeScript 代码的关键。通过明确类型、使用联合类型、泛型、类型断言、unknown 类型、类型守卫和工具类型，可以显著提高代码的类型安全性和可维护性。同时，启用严格模式和逐步替换 any 也是有效的策略。