Claude 要求身份验证了，开源模型能顶上吗？一周实测告诉你答案

上周打开 Claude 准备写代码，突然弹出来一个验证页面——要我上传身份证照片。我当时就愣住了。用了快两年 Claude，第一次遇到这种事。

后来才知道，Anthropic 从 6 月中旬开始全面推身份验证，用的是一个叫 Persona 的第三方服务。不验证？某些功能直接用不了。更狠的是，验证完还有人被封号的。

HN 上那个帖子直接 777 分，评论区炸了。有人说"这是大模型的 Linux 时刻"，有人说"赶紧切开源模型"。我自己也慌了一阵——毕竟 Claude Code 是我每天写代码的主力工具，突然不让用了怎么办？

所以我花了一周时间，认真测试了几个主流开源模型在编程场景下的真实表现。结论先说：开源模型已经能顶上 80% 的场景了，但剩下那 20% 的差距，你得知道自己在牺牲什么。

为什么 Anthropic 要搞身份验证

先说背景。Anthropic 官方的说法是"负责任地使用强大技术，从知道谁在用开始"。翻译成人话就是：有人在用 Claude 搞事情，他们得管管了。

具体是什么事情呢？大概率是这几类：

• 大规模自动化爬取/生成垃圾内容
• 绕过安全限制搞恶意用途
• 企业合规要求（尤其是 EU AI Act 的压力）

不管理由多么正当，对普通开发者来说就是多了一道门槛。你得交出身份证照片，交给一个你大概率没听说过的第三方公司。隐私担忧是实实在在的。

更让人不安的是，有人反馈验证完还是被封号了。Anthropic 说封号理由包括"安全违规"，但具体什么是违规，定义模糊得很。

这让我想起当年 GitHub Copilot 刚出来的时候，也有人说"代码都在微软手里，不安全"。当时大家觉得是杞人忧天，现在看来，依赖单一闭源服务的风险确实存在。一个政策变更就能让你的核心工作流停摆。

说白了，这就是"供应商锁定"的老问题。以前是被 AWS 锁定，现在是被 Anthropic 锁定。形式不一样，本质一样。

HN 上有一篇热度很高的文章（246 分），作者 Andrew Marble 说他正在从 Claude 切到开源模型。他的类比很有意思：以前用 Linux 是有职业风险的，因为兼容性差、软件生态不行。但现在 Linux 已经不是什么牺牲了。开源模型也是一样——差距在缩小，而且"你下载的权重不会被收回"。

开源模型现在到底什么水平

先说结论：2026 年中的开源模型，跟闭源模型的差距已经从"没法用"缩小到了"偶尔差点意思"。

我重点测了三个模型：

DeepSeek V4：之前写过文章，用它接 Claude Code 跑了一周。编码能力很强，尤其是 Python 和 TypeScript，基本上日常开发没问题。缺点是上下文窗口比 Claude 小，长文件处理偶尔会丢信息。还有就是中文回复有时候会突然蹦出英文来，得手动切。

Qwen 3 系列：阿里的模型，从 0.6B 到 235B 都有。我主要用了 30B 和 235B 两个版本。30B 本地跑得动（24G 显存够了），速度不错，写简单代码可以。235B 需要 API 调用，编码质量跟 DeepSeek V4 差不多，但在复杂推理上稍弱。

GLM-5.2：智谱最新的模型，MIT 协议开源。有人拿它跟 Claude Opus 4.8 正面对决——从零写一个 WebGL 3D 平台游戏。结果 GLM-5.2 花了 1 小时 10 分钟，Opus 只用了 33 分半。但 GLM-5.2 只花了 5.39 美元，Opus 估算要 21.92 美元。四分之一的价格，两倍的时间，这个 trade-off 对个人开发者来说其实可以接受。

价格对比很说明问题：

• Claude Opus 4.8：输入 $5/百万token，输出 $25/百万token
• GLM-5.2：输入 $1.4/百万token，输出 $4.4/百万token
• DeepSeek V4：输入 $0.27/百万token，输出 $1.1/百万token（缓存命中更低）

DeepSeek 的价格只有 Opus 的二十分之一。如果你每天大量用 AI 编程，光是 API 费用一个月就能省几百块。

除了这三个主力选手，还有几个值得关注的开源模型：

Llama 4 Maverick：Meta 的最新开源模型，400B 参数但用了 MoE 架构（专家混合），实际推理时只激活一部分参数，所以速度比你想象的快。编码能力跟 DeepSeek V4 差不多，但英文场景更强。适合做英文技术文档生成或者英文代码审查。

Mistral Large 2：法国 Mistral 公司的旗舰模型，123B 参数。特点是欧洲隐私合规做得好，如果你的数据有 GDPR 要求，这个模型值得考虑。编码能力中上，但在复杂推理上比 DeepSeek 和 GLM 弱一些。

Qwen 3 235B：阿里的大模型，MoE 架构，实际激活 22B 参数。中文能力是所有开源模型里最强的，编码也不错。缺点是 API 只有阿里云能用，第三方接入不太方便。

这几个模型的 benchmark 对比（编码相关）：

• SWE-Bench（解决真实 GitHub Issue）：DeepSeek V4 约 55%，GLM-5.2 约 52%，Qwen 3 235B 约 48%
• HumanEval（Python 函数生成）：DeepSeek V4 约 92%，GLM-5.2 约 90%，Qwen 3 235B 约 88%
• LiveCodeBench（实时编程竞赛）：GLM-5.2 约 87%，DeepSeek V4 约 85%

注意这些 benchmark 是模型官方或第三方机构测的，实际使用体验可能有差异。benchmark 高不代表实际好用——Claude 在某些 benchmark 上不是最高分，但实际编程体验确实是最好的。

实际用起来是什么感觉

光看价格和 benchmark 没用，实际干活才知道行不行。我模拟了几个常见场景来测试：

场景一：写一个完整的 FastAPI 后端

让模型从零开始写一个带用户认证、数据库 CRUD 的 FastAPI 项目。这个任务考验的是项目结构理解和代码组织能力。

Claude Opus 给出的代码结构清晰，该有的都有，连 pytest 测试都写好了。DeepSeek V4 的代码也能跑，但目录结构稍微乱一点，测试写得比较敷衍。GLM-5.2 介于两者之间。

差距不大，大概 10% 左右。如果你自己有经验，稍微调整一下就好。

有一次用 DeepSeek 写认证模块，它把 JWT 的过期时间设成了 30 天——这在生产环境是不能用的。Claude 会默认给你一个更合理的值（比如 1 小时），或者至少提醒你要根据场景调整。这种"安全意识"上的差距，是开源模型需要补的课。

场景二：Debug 一个复杂的类型错误

给一个有 TypeScript 泛型嵌套错误的文件，让模型定位并修复。这个任务考验推理能力。

Claude 基本上一次就找到问题了，解释也清楚。DeepSeek 找到了问题但第一次修错了，第二轮才搞定。GLM-5.2 类似，需要两轮。

这个场景下差距明显一些。Claude 的"理解力"确实更强，尤其是面对复杂类型系统的时候。它能准确理解你想要的泛型约束，而 DeepSeek 有时候会给你一个"能编译但语义不对"的修复。

场景三：重构一个 2000 行的遗留代码

给一个真实的旧项目，要求拆分模块、添加类型、改善可读性。这个任务考验上下文理解和长文件处理。

这是差距最大的场景。Claude 能在一次对话中处理完整个文件，保持一致性。DeepSeek 处理到一半就开始"忘记"前面的改动，导致前后不一致。比如前面把 user 变量改成了 userData，后面又用会了 user，导致运行时错误。

GLM-5.2 也有类似问题，但比 DeepSeek 好一点——它至少会在修改前提醒你"这个改动可能影响其他地方"。

长上下文处理确实是开源模型的软肋。虽然 DeepSeek 宣称支持 128K 上下文，但实际有效长度远没那么长。我的经验是超过 15K token 的文件，DeepSeek 就开始不稳定了。

场景四：写单元测试

让模型为一个已有的工具函数写完整的单元测试，包括边界情况。

这个场景下开源模型表现意外地好。DeepSeek 写的测试覆盖面跟 Claude 差不多，甚至有时候还会多想几个边界情况。可能是因为写测试相对"机械"，不需要太多创造性推理。

GLM-5.2 在这个场景下也很稳。我让它为一个日期处理函数写测试，它连闰年、时区切换、夏令时这些边界都考虑到了。

所以如果你主要需求是"帮我写测试"，开源模型完全够用，不需要花那个钱用 Claude。

场景五：解释一段复杂代码

给一段用了高级设计模式的代码（比如装饰器链、元类、高阶函数组合），让模型解释它的作用和原理。

Claude 的解释最清楚，会用类比和图示来帮你理解。DeepSeek 的解释能用但比较干，像是在念文档。GLM-5.2 介于两者之间。

这个差距主要体现在"教学能力"上。Claude 更像一个好老师，DeepSeek 更像一个参考手册。如果你是学习场景，Claude 更好；如果你只是需要快速了解代码在干什么，DeepSeek 够了。

场景六：生成 SQL 查询

让模型根据自然语言描述生成复杂的 SQL 查询，包括多表 JOIN、子查询、窗口函数。

这个场景下 DeepSeek V4 表现很好，甚至比 Claude 有一点优势——它对 SQL 语法的掌握很扎实，生成的查询通常可以直接跑。GLM-5.2 也还行，但偶尔会在窗口函数的 PARTITION BY 子句上犯错。

我觉得这可能是因为 SQL 是比较"规则化"的语言，不像自然语言那么多歧义。开源模型在规则明确的任务上表现普遍不错。

场景七：写正则表达式

让模型根据需求写正则表达式，包括复杂的嵌套匹配和前后断言。

所有模型都能写基本的正则，但复杂的正则（比如匹配嵌套括号、多行注释）只有 Claude 能一次写对。DeepSeek 给的正则经常有 edge case 漏洞，你得自己测试补充。

说实话，正则这种东西我现在不怎么让 AI 写了——写出来还得自己验证，不如直接用 regex101 边写边测。

踩坑记录：我遇到的那些离谱问题

用开源模型跑了一周，踩了不少坑。有些是模型本身的 bug，有些是配置问题，这里统一说说。

坑一：DeepSeek 的 JSON 模式不稳定

让 DeepSeek 以 JSON 格式返回结果，大概有 10% 的概率它会返回不合法的 JSON——比如最后一个元素后面多一个逗号，或者字符串里有没转义的引号。这个问题在 Claude 上几乎不会发生。

解决办法：在 prompt 里加一句"请确保返回合法的 JSON"，能降低出错概率，但不能完全消除。最稳妥的做法是在代码里加 JSON 解析的 try-catch。

坑二：GLM-5.2 的 API 偶尔超时

通过 OpenRouter 调用 GLM-5.2，大概有 5% 的请求会超时（超过 60 秒没响应）。直接调智谱官方 API 好一些，但偶尔也会遇到。

解决办法：在代码里加重试逻辑。Aider 和 Cursor 内置了重试机制，所以实际使用中影响不大。但如果你自己写脚本调 API，一定要加 retry。

坑三：Qwen 3 的中文分词问题

Qwen 3 在处理中英混合文本时偶尔会把中文词拆错。比如"FastAPI 框架"可能会被拆成"Fast" + "API" + "框" + "架"，导致补全结果里出现奇怪的断句。

这个问题在 Ollama 本地跑的时候更明显，可能跟量化精度有关。API 版本好一些。

坑四：模型切换后的上下文丢失

在 Aider 里切换模型（比如从 DeepSeek 切到 Claude），之前的对话上下文不会保留。新模型不知道你之前讨论了什么，你得重新描述问题。

Claude Code 没有这个问题，因为它本身就是单模型。但如果你用 Aider 的多模型特性，要注意这个坑。

坑五：DeepSeek 的缓存命中率波动大

DeepSeek 有 prompt 缓存机制，重复的前缀可以享受折扣价。但实际使用中缓存命中率很不稳定——有时候一天能命中 80%，有时候只有 20%。可能跟他们的服务器负载有关。

这意味着你不能完全按照官方定价来预算成本，实际费用可能比理论值高 30-50%。

一套完整的混合使用工作流

说了这么多，最后分享一下我现在实际在用的工作流。这套方案用了一个月，感觉效率和成本的平衡点找得还不错。

日常开发流程：

1. 新建文件、写简单函数 → 用 Cursor + DeepSeek V4（Tab 补全）
2. 写单元测试 → 用 DeepSeek V4（质量够用，价格便宜）
3. Debug 复杂问题 → 切 Claude Opus（推理能力强）
4. 重构大文件 → 切 Claude Opus（上下文处理好）
5. 写文档和注释 → 用 DeepSeek V4（足够了）
6. 代码审查 → 用 GLM-5.2（价格适中，质量不错）

快捷键配置（Cursor）：

在 Cursor 的 keybindings.json 里配置模型切换快捷键：

{

  "key": "ctrl+shift+1",

  "command": "cursor.setModel",

  "args": {"model": "deepseek-chat"}

},

{

  "key": "ctrl+shift+2",

  "command": "cursor.setModel",

  "args": {"model": "claude-opus-4-8"}

}

这样你可以在写代码的过程中快速切换模型，不需要打开设置页面。

Aider 的 Architect Mode：

Aider 有个很实用的"architect mode"——先让一个强模型（比如 Claude）做规划，再让一个便宜模型（比如 DeepSeek）执行。这样既能保证方案质量，又能省 token 费用。

# 先用 Claude 做规划

aider --model claude-opus-4-8 --architect

# 再用 DeepSeek 执行

aider --model deepseek/deepseek-chat --apply

这个模式特别适合大型重构任务——Claude 出方案，DeepSeek 干活。

如果你决定试试开源模型，配置其实不复杂。主流的 AI 编程工具都支持自定义 API 端点。

方案一：Aider + DeepSeek V4

Aider 是一个开源的终端 AI 编程助手，支持几乎所有主流模型。它的体验跟 Claude Code 类似，但更灵活。

# 安装 Aider

pip install aider-install

aider-install

# 用 DeepSeek V4

aider --model deepseek/deepseek-chat --api-key sk-xxx

# 用 GLM-5.2（通过 OpenRouter）

aider --model openrouter/zhipu/glm-5.2

Aider 的好处是它会自动管理 git 提交，每次 AI 改完代码都会帮你 commit，方便回滚。还支持"architect mode"——先让一个强模型做规划，再让另一个模型执行。

方案二：Cursor / Windsurf 切换 API

在 Cursor 的设置里，你可以把模型 API 改成 DeepSeek 或 OpenRouter：

Settings → Models → Add Model

API Base URL: https://api.deepseek.com/v1

API Key: sk-xxx

Model: deepseek-chat

改完之后，Cursor 的 Tab 补全、Chat、Composer 都会用新模型。体验上跟用 Claude 差不多，就是响应速度可能会慢一点（DeepSeek 的服务器偶尔会排队）。

Windsurf 的配置方式类似，在 Settings → Model Provider 里改就行。

方案三：本地运行（Qwen 3 30B）

如果你有 24G 显存的显卡（比如 4090 或者 3090），可以用 Ollama 跑 Qwen 3 30B：

# 安装 Ollama

curl -fsSL https://ollama.com/install.sh | sh

# 下载模型（大概 20GB）

ollama pull qwen3:30b

# 启动服务（默认端口 11434）

ollama serve

然后在 Cursor 或 Aider 里把 API 端点指向 http://localhost:11434 就行。

本地跑的好处是完全离线，数据不出你的机器。缺点是速度慢——30B 模型在 4090 上大概每秒生成 30-40 个 token，比 API 差不少。而且 24G 显存只能跑量化版本（Q4_K_M），精度会打折扣。

如果你显存不够，可以试试 Qwen 3 8B，8G 显存就能跑。但编码质量跟 30B 差距明显，只能做简单补全。

方案四：OpenRouter 统一接入

OpenRouter 是一个模型聚合平台，一个 API key 就能调用几十个模型。好处是切换模型只改一个参数，坏处是多了一层中间商，延迟会高一点。

import openai

client = openai.OpenAI(

    base_url="https://openrouter.ai/api/v1",

    api_key="sk-or-xxx"

)

# 切换模型只改这个参数

response = client.chat.completions.create(

    model="deepseek/deepseek-chat",  # 或 "zhipu/glm-5.2"

    messages=[{"role": "user", "content": "帮我写一个快排"}]

)

OpenRouter 的价格通常比直接调 API 贵 10-20%，但胜在方便。如果你经常需要在不同模型间切换，这是最省事的方案。

成本账：一个月到底能省多少

假设你每天用 AI 编程 4 小时，平均每次对话消耗 5 万 token（输入+输出），一天大概 20 次对话。

用 Claude Opus：

• 每天 100 万 token，约 50 万输入 + 50 万输出
• 输入费用：$5 × 0.5 = $2.5
• 输出费用：$25 × 0.5 = $12.5
• 每天 $15，一个月 $450

用 DeepSeek V4：

• 同样的 token 量
• 输入费用：$0.27 × 0.5 = $0.135
• 输出费用：$1.1 × 0.5 = $0.55
• 每天 $0.685，一个月 $20.5

用 GLM-5.2：

• 输入费用：$1.4 × 0.5 = $0.7
• 输出费用：$4.4 × 0.5 = $2.2
• 每天 $2.9，一个月 $87

差距一目了然。DeepSeek 一个月只要 20 美元，Claude 要 450 美元。即使加上偶尔需要用 Claude 补充的场景，总成本也能控制在 50 美元以内。

当然，这个计算假设你全用 API。如果你用 Claude Pro 订阅（$20/月），情况又不一样——订阅制的好处是无限量使用（有速率限制），坏处是被绑在 Anthropic 的生态里。

我现在的混合方案是：Claude Pro 订阅 $20 + DeepSeek API $20 + 偶尔用 OpenRouter $10 = 每月 $50 左右。比之前全用 API 的 $450 省了将近 90%。

开源模型的真正短板

说了这么多开源模型的好，也得说说它们的不足。这些差距是真实存在的，不是靠调参能解决的。

1. 多模态能力

Claude Opus 能看截图、分析 UI、理解图表。GLM-5.2 是纯文本模型，看不了图。DeepSeek V4 有多模态版本但能力跟 Claude 差距明显。

如果你的工作流涉及"截图问 AI"（比如让 AI 看报错截图、分析设计稿），开源模型暂时替代不了。我自己经常用 Claude 截图看报错信息，这个功能确实方便。

2. Agent 模式下的稳定性

Claude Code 的 Agent 模式可以连续跑几十分钟，自动规划、执行、验证。开源模型在长任务链上容易跑偏——不是能力不够，是"注意力"不够集中。

Sakana AI 刚发布的 Fugu 系统很有意思——它不是一个模型，而是用多个模型协作来完成复杂任务。Fugu Ultra 在 SWE-Bench Pro 上拿了 73.7 分，超过 Opus 4.8 的 69.2 分。这说明"模型协作"可能比"单一更强模型"更有效。

这个思路也适用于个人开发者：你可以用 DeepSeek 做初稿，再用 Claude 做 review 和修复。两个模型各取所长，效果可能比单用一个更好。

3. 工具调用的可靠性

Claude 对 function calling 的理解很到位，参数传递几乎不出错。开源模型在这方面偶尔会犯低级错误——参数类型搞错、必填字段漏掉、JSON 格式不规范。

这个差距在用 MCP 服务器的时候尤其明显。我试过用 DeepSeek V4 跑 Hermes Agent，大概有 15% 的工具调用会失败，Claude 的失败率不到 2%。

具体表现是：DeepSeek 有时候会把整数参数传成字符串，或者在调用工具时忘记传必填字段。这些错误不会导致程序崩溃，但会导致你需要手动修正，打断工作流。

4. 长上下文的实际有效长度

虽然各家都宣称支持 128K 甚至 1M 上下文，但实际使用中，开源模型在超过 32K token 后质量下降明显。Claude 的 200K 上下文在 150K 以内都比较稳定。

如果你的项目经常需要处理大文件（比如一个 5000 行的配置文件），开源模型可能会"忘掉"前面的内容。我实测过：让 DeepSeek 处理一个 3000 行的 TypeScript 文件，到后面它会重复定义前面已经定义过的变量。

5. 中文回复的一致性

DeepSeek 有个很烦人的问题：中文对话中会突然蹦出英文句子。不是整段英文，而是夹杂在中文回复里的一两个英文句子。你得手动让它切回来。

GLM-5.2 在这方面好很多，中文回复比较稳定。Qwen 3 也还行。但整体来说，中文场景下开源模型的体验不如 Claude 流畅。

一个实用的迁移策略

如果你决定从 Claude 迁移到开源模型，不要一刀切。我建议分三步走：

第一步（第一周）：在 Cursor 或 Aider 里配置 DeepSeek API，用它处理简单的编码任务（写函数、写测试、格式化代码）。继续用 Claude 处理复杂任务。

第二步（第二周）：逐步扩大 DeepSeek 的使用范围。试试让它处理中等复杂度的任务（重构小模块、写 API 接口）。遇到它搞不定的，切回 Claude。

第三步（第三周以后）：找到你自己的"分界线"。哪些任务用 DeepSeek 就够了，哪些必须用 Claude。把这个分界线固化下来，形成你自己的工作流。

关键是不要有心理负担——用开源模型不是"降级"，是"合理分配资源"。就像你不会用 Photoshop 去截一张图一样，简单任务用便宜工具，复杂任务用强工具。

开源模型的隐私和安全考量

选择开源模型不只是价格问题，还有隐私和安全的考量。

数据主权：用 Claude API，你的代码和对话数据都会经过 Anthropic 的服务器。虽然他们承诺不用于训练，但你没法验证。用本地模型（比如 Ollama 跑 Qwen 3），数据完全不出你的机器。

合规要求：如果你在做企业项目，可能有数据不出境的要求。用国内的 API（DeepSeek、智谱）至少数据在国内。用 Claude 的话数据要去美国，有些行业是不允许的。

审计需求：有些项目需要对 AI 生成的代码做审计追溯。本地模型的好处是所有的输入输出你都有完整日志，API 调用的话你得信任服务提供商的日志策略。

瑞士最近发布的 Apertus 模型很有意思——它是一个完全开源的基础模型，训练数据、代码、权重、对齐方法全部公开。连训练数据里的个人隐私信息都做了脱敏处理。这种"完全透明"的模型在企业合规场景下很有吸引力。

不过 Apertus 目前只有 8B 和 70B 两个版本，编码能力跟 DeepSeek V4 差距还比较大。先关注着，后面版本可能会越来越好。

后续展望

开源模型的迭代速度很快。DeepSeek V4 比 V3 强了一大截，Qwen 3 比 Qwen 2 也是质的飞跃。按这个速度，半年后开源模型可能就能覆盖 95% 的编程场景了。

另外值得关注的是"模型协作"的方向。Sakana Fugu 证明了多个中等模型协作可以超过单一强模型。这个思路如果普及开来，"用哪个模型"的问题可能会变成"怎么组合模型"的问题。

还有就是本地部署的成本在下降。以前跑 70B 模型需要 A100，现在 4090 跑量化版本就能用。等 5090 出来，本地跑 100B+ 模型可能就不是梦了。

另外一个趋势是"模型即服务"的分化。以后可能不是一个模型打天下，而是不同模型各司其职——快的模型做补全，强的模型做推理，便宜的模型做批量处理。就像你不会用同一个工具做所有事情一样。

常见问题

Q：开源模型能完全替代 Claude 吗？

现在还不能。大概能覆盖 80% 的场景，剩下 20%（复杂推理、长上下文、多模态）Claude 还是明显更强。但如果你的预算有限，或者对隐私有要求，开源模型是很好的选择。

Q：我应该选哪个开源模型？

如果你主要写 Python/TypeScript → DeepSeek V4（性价比最高） 如果你需要中文能力 → Qwen 3 235B 或 GLM-5.2 如果你有隐私要求 → 本地跑 Qwen 3 30B（Ollama） 如果你预算充足想要最好体验 → GLM-5.2（质量最接近 Claude）

Q：开源模型的安全性怎么样？

开源模型的"安全性"取决于你怎么用。如果你跑本地，数据完全在你手里，比用任何 API 都安全。如果用第三方 API（OpenRouter、Together AI 等），安全性跟用 Claude 差不多——都得信任服务提供商。

Q：切换模型会影响我的工作流吗？

会有一定影响，主要是学习成本。不同模型对 prompt 的响应方式不一样，你可能需要调整你的提示词。但主流工具（Cursor、Aider）都在做模型适配，切换成本在降低。

Q：开源模型的代码有没有版权风险？

目前主流开源模型（DeepSeek、Qwen、Llama）都是 MIT 或 Apache 2.0 协议，生成的代码没有版权限制。但如果你用的是训练数据有争议的模型（比如早期的 Copilot），可能需要注意一下。现在的模型在这方面都比较规范了。

后面我打算写一篇详细的 Aider + DeepSeek V4 配置教程，包括怎么配 MCP 服务器、怎么优化 prompt 效果。

最后再补充一点：不管用什么模型，最重要的还是你自己的技术能力。AI 编程工具再强，也只是工具。如果你连基本的代码审查能力都没有，用 Claude 还是 DeepSeek 都一样会写出有 bug 的代码。

工具是帮你提效的，不是帮你写代码的。这个心态摆正了，用什么模型都不会差。

有啥问题评论区聊。