Pro 和 Flash 到底怎么选？全用 Pro 太贵，全用 Flash 怕质量不行。这篇就来聊聊如何用「Pro 规划 + Flash 执行 + Pro 审查」的混合工作流，在不牺牲代码质量的前提下，把 API 费用砍掉一半以上。
一、定价对比
先看钱。以下是 DeepSeek 官方 API 定价（2026 年 6 月，折扣后）：
| 模型 | 输入价格 / 1M tokens | 输出价格 / 1M tokens | 相对成本 |
|---|---|---|---|
| V4 Flash | $0.14（≈1 元） | $.28（≈2 元） | 基准 1x |
| V4 Pro | \undefined.87（≈6 元） | 约 3x |
常见坑： 不要因为折扣期便宜就所有任务全用 Pro。编码任务中 60-80% 的 token 消耗在执行层（代码生成和编辑），这部分用 Flash 是成本优化的主战场。
二、Pro 和 Flash 的本质差异
网上最常见的误区是把 Pro 和 Flash 看作「强 vs 弱」。实际上，两者的差异更适合用「角色分工」来理解。
| 维度 | V4 Pro | V4 Flash |
|---|---|---|
| 参数规模 | 1.6T（MoE） | 284B（13B 激活） |
| 核心优势 | 深度推理、架构决策、复杂调试 | 快速执行、高性价比、批量操作 |
| 响应速度 | 较慢（深度思考耗时） | 快（秒级输出） |
| 适合角色 | 规划者 / 顾问 | 执行者 |
| 最大弱点 | 对简单任务「过度思考」，输出冗长 | 模糊指令产生模糊输出，需明确 Prompt |
| 单文件编码质量 | 与 Flash 差距小到难以分辨 | 接近 Pro 水平 |
| 多文件联动/架构 | 显著优于 Flash | 可能遗漏边界情况和跨文件依赖 |
代码质量关键发现（来自 ofox.ai 实测）：
在单文件、边界清晰的编码任务上，Pro 和 Flash 的质量差距小到大多数团队分辨不出来。Flash 能稳定完成 LeetCode 中等难度题目，可重构千行老项目代码且逻辑无误。
核心解析： Flash 在「打字型」任务（生成代码、写函数、修改文件）上已经足够好，Pro 的 12 倍溢价应该花在「判断型」任务（拆需求、定方案、查根因、审质量）上，而不是花在输出代码上。
三、混合工作流：三阶段分工
推荐的混合工作流将一次编码任务拆为三个阶段，每个阶段使用最合适的模型。
3.1 阶段一：规划（Pro）
做什么： 分析需求 → 拆解任务 → 输出执行方案。
为什么用 Pro： 规划阶段需要理解上下文、识别边界条件、评估技术风险，这是 Pro 的强项。Flash 在此阶段容易遗漏关键约束。
Prompt 示例：
分析这个认证流程的竞态条件，提出修复策略和具体步骤。
需要考虑：token 刷新并发、session 过期、数据库事务隔离级别。3.2 阶段二：执行（Flash）
做什么： 按规划方案编写代码、修改文件、重构、批量操作。
为什么用 Flash： 这是 token 消耗最大的环节（占总 token 的 60-80%），用 Flash 成本仅为 Pro 的 1/12。且 Flash 在明确指令下执行质量与 Pro 差距极小。
Prompt 示例：
按计划实现修复：在 auth.py 的 token 刷新处加互斥锁，
更新 test_auth.py 覆盖并发访问场景。关键规则： Flash 需要明确具体的指令，模糊指令会产生模糊输出。将 Pro 规划阶段的输出直接作为 Flash 的输入，是最佳衔接方式。
3.3 阶段三：审查（Pro）
做什么： 审查 Flash 生成的代码，检查边界条件、安全性、跨文件一致性。
为什么用 Pro： 审查的 token 消耗远小于执行（通常只审查 diff 部分），用 Pro 做质量兜底，增加的成本有限但质量提升显著。
审查重点：
- 跨文件依赖是否完整（Flash 的弱项）
- 边界条件处理（空值、异常、并发）
- 安全性（注入、权限、密钥硬编码）
- 与已有代码风格一致性
本工作流的执行流程（拆解版）：
- 需求输入：用户提出编码需求
- Pro 规划：分析需求，拆解为具体任务列表，输出执行方案
- Flash 执行：按任务列表逐项编写/修改代码
- Pro 审查：检查生成的代码 diff，标注问题
- 修复闭环：如有问题，Flash 按审查意见修复，再经 Pro 快速复查
审查通过，构建清单与代码一致：
| 检查项 | 状态 | 说明 |
|---|---|---|
types/index.ts |
✅ | 纯类型定义，无运行时逻辑 |
FlashcardReading.ts |
✅ | 管理类 + 弹窗函数独立文件 |
index.ts |
✅ | 从 ./FlashcardReading 导入 |
floatingBox 导入 |
✅ | 从 ../../flashcardReading/FlashcardReading 导入 |
useCardNavigation |
✅ | 已删除，0 处引用 |
useI18n 模板用法 |
✅ | 模板用 t.xxx（Vue 自动解包），脚本用 t.value.xxx |
CardList.vue |
✅ | 已修复双括号 |
SCSS _variables.scss |
✅ | @forward 全路径为 ../../../_variables.scss（3 级） |
SCSS index.scss |
✅ | @use + @forward 'variables' |
| SCSS partials | ✅ | _typing/_dialog/_statistics 均 @use 'variables' as * |
| 命名冲突 | ✅ | 局部变量（$fc-*）与全局变量（$brand-*）无冲突 |
上次构建已成功启动运行中，所有一致性检查通过。
四、网上实践案例对比
以下是 2026 年 4-6 月期间，多位开发者的实测数据汇总：
| 来源 | 方案 | 效果 | 成本变化 |
|---|---|---|---|
| Toy (2026-05-13) | Pro 规划/设计 + Flash 编码执行 | 日常开发体验无明显下降 | 日费用从 40 元降至 10-15 元，降低约 70% |
| BSWEN/Cowrie (2026-05-26) | Pro 规划 + Flash 实施 | Flash 覆盖 80% 日常任务 | 未给具体倍数，但指出 Pro 过度思考浪费大量 token |
| CSDN 实测 (2026-05-06) | 90% Flash + 10% Pro | Flash 生成千行脚本秒级完成 | Flash 成本为 Pro 的 1/3 |
| KnightLi (2026-05-15) | 大模型判断 + 小模型执行理论 | 执行层 token 消耗落在低成本模型 | 理论框架，未给具体数字 |
| ofox.ai (2026-05-09) | 单文件任务 Flash，多文件任务 Pro | 单文件编码质量差距难以分辨 | Pro 价格是 Flash 的 12 倍 |
共同结论： 所有实践者一致认为------「日常开发用 Flash，复杂问题切 Pro」是最优策略。BSWEN 特别强调：「两种模型单独使用都不如组合使用效果好。」
五、成本量化估算
假设一个典型编码任务的 token 消耗分布如下：
| 环节 | token 占比 | 使用模型 | 成本权重（相对 Flash） |
|---|---|---|---|
| 规划/拆任务 | 10% | Pro | 10% × 12 = 120 |
| 代码执行 | 70% | Flash | 70% × 1 = 70 |
| 审查 | 20% | Pro | 20% × 12 = 240 |
| 混合方案总计 | 430 |
三种方案的相对成本对比：
| 方案 | 成本权重 | 相对比例 | 适用场景 |
|---|---|---|---|
| 全 Pro | 1200 | 100%（基准） | 复杂架构、深度调试 |
| 混合方案（Pro+Flash+Pro） | 430 | 36% （省 64%） | 日常开发主力方案 |
| 纯 Flash | 100 | 8%（省 92%） | 简单任务、脚本、格式化 |
核心解析： 混合方案的成本是全 Pro 的 36%，即节省约 64% 的 API 费用。如果折扣期结束后 Pro 恢复原价（12 倍 Flash），节省比例将进一步升至约 70%+。
划重点： 审查环节虽然用 Pro，但 token 消耗量远小于执行环节（审查 diff 通常只有几十到几百行代码），因此增加的绝对成本有限。这笔溢价换的是代码质量的安全垫，性价比极高。
六、分场景选择策略
不是所有任务都需要走完整的三阶段。根据任务复杂度，建议三档方案：
方案一：轻量模式（日常任务，覆盖 80% 场景）
流程： Pro 规划 → Flash 执行 → Flash 自审
适用： 单文件编码、CRUD 接口、简单重构、配置文件修改、脚本编写
为什么够用： Flash 在单文件场景的质量已接近 Pro，自审即可覆盖基本问题。
方案二：标准模式（重要功能，覆盖 15% 场景）
流程： Pro 规划 → Flash 执行 → Pro 审查
适用： 跨模块功能、涉及安全/权限的代码、数据库 schema 变更、对外 API
为什么需要 Pro 审查： 涉及跨文件依赖和安全性，Flash 可能遗漏边界条件。
方案三：深度模式（复杂架构，覆盖 5% 场景）
流程： Pro 全流程（规划 + 执行 + 审查）
适用： 系统架构设计、复杂 Bug 调试（竞态条件、内存泄漏）、陌生代码库理解
为什么不用 Flash： 这类任务的核心价值在推理和判断，不在代码输出速度。让 Flash 碰架构决策反而会引入风险。
七、注意事项与常见坑
常见坑：
- 所有任务都用 Pro --- BSWEN 实测：简单任务上 Pro 反而更慢且质量可能更差，Pro 的「过度思考」会质疑正确方案、输出冗长解释，干扰开发节奏
- 复杂架构决策用 Flash --- Flash 回答快但会遗漏边界情况和长期影响，架构选型必须 Pro
- 不调整 Prompt 风格 --- Pro 需要上下文引导推理（「思考为什么...考虑...」），Flash 需要具体指令直接执行（「在 X 文件 Y 行做 Z 操作」）
- 审查变成重写 --- Pro 审查应关注问题标注，而非重新生成代码。审查发现问题后应由 Flash 按意见修复
模型 Prompt 风格对照：
| Pro 风格 | Flash 风格 | |
|---|---|---|
| Prompt 示例 | 「思考这个测试为什么会间歇性失败，考虑时序、状态和并发。」 | 「在 test_login.py 第 42 行前加 wait_for_selector 调用解决时序问题。」 |
| 关键特征 | 引导推理、开放分析 | 明确指令、具体操作 |
八、总结
混合工作流的本质不是「用便宜模型替代贵模型」，而是重新设计 AI 编程流程------让 Pro 负责它擅长的「判断」，让 Flash 负责它擅长的「执行」，两者各司其职。
核心收益：
- 成本：节省 60-70% 的 API 费用
- 质量：单文件编码质量无明显下降，Pro 审查兜底保障关键场景
- 效率：Flash 响应快，避免了 Pro 对简单任务的过度思考
最后： 未来的 AI 编程差距不在谁调用了最强模型，而在谁能用同样的 token 撬动更多真实产出。Pro + Flash 的分工方案不是省钱技巧，而是 Token Efficiency 的工程实践------把每一分钱的 token 都花在正确的地方。