DeepSeek V4-Pro 与 V4-Flash 怎么选？从 DeepSWE 62.7% 到 100 万上下文

DeepSeek V4-Pro 与 V4-Flash 怎么选？从 DeepSWE 62.7% 到 100 万上下文

2026 年 8 月 13 日，距 V4-Flash 发布不到半个月，DeepSeek 直接端出了 V4-Pro 正式版：DeepSWE 编程基准从预览版的 12.8% 飙到 62.7%，一口气支持 100 万 Token 上下文，同一天还开源了 Harness。Pro 和 Flash 到底差多少？日常开发该用哪个？DeepSWE 上 Pro 是 Flash 的多少倍？这篇把选型逻辑一次讲清楚。

一、先对齐两个型号的定位

注意一个关键事实：V4-Pro 的 62.7% 是「正式版」成绩，预览版只有 12.8%——同一个型号、同一套基准，从预览到正式，分数翻了近 5 倍。这说明什么？后训练（post-training）在最后阶段的投入，对 Agent 能力的影响是数量级的。

二、DeepSWE 62.7% 是什么水平

DeepSWE 测试的是「AI 解决真实软件工程问题的能力」：给定真实仓库 + 失败用例，看 Agent 能否独立修复。

几个解读角度：

1. 模型后训练红利巨大：预览 12.8 → 正式 62.7，这 49.9 个百分点的跃升，主要靠的是训练投入，而不是架构改动；
2. 执行层不可忽视：官方跑分用的是自家 Harness 极简模式（只留 shell + 文件编辑两个工具），这说明「模型 + 最小执行层」的组合已经很强；
3. 60%+ 意味着「能解决真实问题」：在真实仓库场景下能修好六成 issue，已经是生产可用级别的能力。

三、100 万 Token 上下文意味着什么

V4-Pro 支持 100 万 Token 上下文，这个数字要放到场景里理解：

100 万意味着：Agent 可以「一次装下」一个完整的中大型仓库，不用频繁加载、不用上下文压缩，直接看到全局再动手。

如果做代码评审、全库重构、跨模块调试，这是质的改变——之前要分模块喂，现在可以整库喂。

四、所以：日常开发该用哪个？

选 V4-Flash 的场景

• 日常问答、写单点函数、改小 bug
• 低延迟交互（聊天式辅助）
• Token 预算敏感的批量任务
• 不需要深度推理链条的场景

选 V4-Pro 的场景

• 复杂重构、跨模块调试
• 整库代码评审
• Agent 长任务（配合 Harness，一次预演完整流程）
• DeepSWE 类工程问题（真实修 bug）
• 需要 100 万上下文的「整库上下文」场景

行业里有个不那么正式的共识：Flash 是「快问快答」，Pro 是「接活干活」。前者适合你自己写代码时插一脚，后者适合「把活外包给 Agent 做」。

五、结合 Harness 的选型组合拳

既然官方跑分都在 Harness 上，选型就应该带着 Harness 一起想：

省钱视角（接第 6/7 篇）：日常用 Flash + PTC + 低谷时段，只在真正需要工程级推理时切 Pro。这样你能拿到 Pro 的能力兜底，又不会整天烧 Pro 的单价。

六、一个诚实的提醒

DeepSWE 62.7% 听起来很强，但有几点要说清楚：

1. 62.7% 是基准子集成绩，不是「所有真实问题」的通过率；
2. 快速迭代还在继续：8 月还在猛发力，说明 V4 系列还会有动作；
3. 跑分是模型 + 执行层的综合：你在别的 harness 上跑 Pro，得分大概率不同（第 3 篇讲过，同样模型换 harness 差 7 倍成本、分数也不同）；
4. Flash 与 Pro 的能力差会随任务变：简单任务差距小，复杂任务差距会拉大——不要用简单问题的表现去推断复杂任务。

七、小结：一张决策表收尾

DeepSeek 这一轮的节奏很明确：Flash 打底、Pro 攻坚、Harness 配执行、API 峰谷定价管成本——一套「模型 + 框架 + 定价」的完整战阵。选型不再只是「选个模型」，而是「选一套打法」。

八、价格账：Flash 和 Pro 到底差多少钱

选型的核心变量之一是成本。以 2026 年 8 月 17 日生效的峰谷定价为基准，算一笔透明的账。

单价对比（每百万 Token）

三个真实场景的开销估算

场景一：日常问答（单次 2k 上下文、无缓存）

• Flash：几乎可以忽略不计；
• Pro 高峰：是 Flash 的数倍，但绝对值仍然低。

结论：日常高频交互，Flash 是压倒性优势——单价差 + 数量大，双杀。

场景二：Agent 长任务（30 轮工具调用、累计 200k 上下文、90% 缓存命中）

• Flash：极低（缓存命中 + 便宜单价）；
• Pro 高峰：中高；
• Pro 低谷：中等。

结论：长任务靠的是缓存命中率，模型选谁反而其次——把会话管理做好（复用 session_id），Flash 也能把长任务跑得便宜；追求修复率才值得上 Pro。

场景三：DeepSWE 式工程修复（单任务 50k+ Token、几乎无缓存复用）

• Flash：单价便宜但成功率低，失败的任务要重跑；
• Pro 高峰：单次贵，但成功率 62.7%，一次过的概率大。

结论：成功率本身就是成本。修 10 个 bug，Flash 失败 6 个重跑，总成本可能比 Pro 还高。工程修复场景，把「失败重试成本」算进去再选。

一句话成本心法

简单任务用 Flash（贵在量大，Flash 便宜）；复杂任务用 Pro（贵在失败，Pro 一次过）；批量任务挪低谷（贵在时段，低谷半价）；长任务靠缓存（贵在重复，复用 session）。

四个「贵在哪」对应四条省钱策略，组合起来就是一套完整的成本控制系统。

九、补充：从预览到正式，62.7% 是怎么练出来的

很多人对「12.8% → 62.7%」的跃升感到不可思议，这里拆解一下这背后通常是什么在起作用（基于公开信息与行业常识的合理推断）。

第一步：Agent 化训练数据

预览版到正式版之间，最核心的变化大概率是后训练数据结构的调整——把「单轮问答」的训练样本，重构成「思考-调用工具-看到结果-继续行动」的完整轨迹。模型见的「活」多了，干活的自然就熟练。

第二步：工具调用对齐强化

DeepSWE 这类基准考验的不是「懂不懂」，而是「会不会一步步干到结果」。训练时加入大量「多轮工具调用 + 失败恢复」样本，模型才能学会在 grep 结果不理想时换策略，而不是死磕。

第三步：长上下文稳定性

100 万 Token 上下文不是「塞得下」就完事，关键是塞得下还要记得住——在长上下文里不丢关键信息、不混乱角色，是工程修复能力的隐形基础。Pro 在这块的投入，直接反映在跨文件修复的成功率上。

这给选型什么启发？

1. 别拿预览版成绩做长期判断：模型在快速迭代，今天不行的明天可能就行；
2. 关注「训练后 vs 正式版」的差距：如果某个模型预览到正式提升巨大，说明它正处于高速成长期，值得持续跟进；
3. 用基准但别只用基准：DeepSWE 62.7% 是「模型 + Harness 极简模式」的成绩，你在自己工作流里的真实表现，永远是最终裁判。

模型的能力在涨，框架的生态在长，定价的机制在变——唯一不变的是你要有一套自己的评估方法。把这篇的方法存下来，每次新模型发布，都跑一遍自己的基准集，比任何榜单都可靠。

十、补充：常见误区与纠偏

误区一：「100 万上下文 = 把整个公司代码库都塞进去」

上下文窗口大不代表你应该全塞进去。原因有三：

1. 成本：上下文越长，每次请求的 Token 成本越高，长上下文的边际收益递减；
2. 注意力稀释：关键信息淹没在海量代码里，反而降低修复准确率（「长上下文遗忘」是真实存在的现象）；
3. 检索更划算：100 万窗口的正确用法是配合检索——先 grep/语义搜索定位相关文件，再把相关片段送进上下文，而不是全库倒进去。

结论：100 万是「能力上限」不是「使用建议」。用它处理「确实需要全貌」的场景（架构评审、跨模块重构），日常任务该检索还是检索。

误区二：「Flash 便宜，所以全用 Flash 最省钱」

这是本文反复强调的坑：便宜是总成本概念，不是单价概念。工程修复场景里，Flash 的低成功率意味着失败重跑、人工兜底，总成本可能反而高于 Pro。选型前先问：我的任务是「成功一次就赚」还是「失败要重来」？

误区三：「DeepSWE 62.7% = 我的开发效率提升 62.7%」

基准分衡量的是「特定任务集上的修复成功率」，不是「整体开发效率」。你的真实收益取决于：任务类型匹配度、工作流配合、人工审查成本。用基准选模型，用真实验证效果。

一张最终决策卡

预算紧张 + 简单任务  → Flash（走量）
质量优先 + 复杂任务  → Pro（一次过）
批量 + 可延迟        → 低谷时段 + Flash/PTC
长任务 + 高复用      → 复用 session + 缓存优先

选型不是一次性的，要建立「季度评估」习惯

模型版本迭代极快（Flash 到 Pro 只隔了两周），定价也会变（峰谷定价就是例子）。建议每季度做一次三件事：

1. 跑基准集：用你自己的任务集（不是别人榜单）对比 Flash / Pro 的通过率与成本；
2. 核对定价：确认峰谷时段、缓存价是否变化，重新计算你的主力场景成本；
3. 检查框架：Harness 这类执行层更新后，你的配置是否需要跟进（新插件、新模式）。

保持这个节奏，选型就不是「拍脑袋」，而是可迭代的系统。

最后一张总表：全场景选型速查

这张表可以直接贴进团队 Wiki 作为默认选型规范，遇到特殊场景再单独评估。最后再提醒一句：模型选型是「工程决策」而不是「信仰决策」——别因为某个跑分高就无脑切换，也别因为用顺手了就不敢换。把数据跑出来，让数字说话。

附：三种典型开发者的推荐配置

独立开发者（预算敏感）：日常问答/补函数用 Flash，复杂重构临时切 Pro，批量任务挪低谷时段 + PTC 模式。核心是「Flash 兜底、Pro 攻坚、低谷省钱」。

团队主力（质量优先）：代码评审、架构设计、Agent 长任务全程 Pro，善用 100 万上下文整库喂入，用 Harness 管理执行层。核心是「能力优先，成本靠跑法找补」。

平台方（看重可控）：前置分发层按任务难度路由到 Flash/Pro，统一系统提示词最大化缓存命中，夜间批量走低谷。核心是「模型分层 + 跑法优化 = 单位成本最低」。

三套配置的共同结论：选型不是单选，是路由。让每个模型只干它最划算的活，比纠结「用哪个」重要得多。

附：选型决策树（一图速查）

遇到「V4-Flash 还是 V4-Pro」时，按下面四步走，基本能直接落到结论：

第一步，先看场景类型。日常问答、单点补函数、小修小补归为「轻任务」，直接选 Flash；复杂重构、全库评审、Agent 长任务归为「重任务」，进入下一步。

第二步，再看成本预算。预算紧、任务量大的，优先 Flash + 低谷时段 + PTC 模式；预算可接受、质量优先的，进入第三步。

第三步，看上下文长度。需要 10 万 Token 以上乃至整库上下文，只有 Pro 的 100 万窗口能承接；标准上下文即可满足，回到「能否接受失败重跑」的判断。

第四步，看成功率要求。失败一次代价高、需要一次过的工程修复，选 Pro，把 62.7% 的 DeepSWE 能力当兜底；失败可低成本重试的，选 Flash 更省。

一句话结论：轻任务走量选 Flash，重任务攻坚选 Pro，批量任务挪低谷，长任务靠缓存复用。

标签：#DeepSeek #V4-Pro #V4-Flash #模型选型 #大模型