DeepSeek V4提供Pro和Flash两种模型，均支持思考与非思考模式、工具调用、JSON输出以及百万上下文。官方价格和并发上限存在明显差异，因此最合理的做法不是全量使用最强模型，而是按任务难度、时延和错误成本进行分层。本文给出一套从样本评测到灰度路由的完整方法。
先按错误成本而不是名称选模型
Flash适合分类、抽取、改写、客服初筛和大量结构化处理；Pro更适合复杂推理、跨文档分析、代码审查和高价值决策支持。一个任务是否升级到Pro，应看Flash的置信度、规则校验结果和失败损失，而不是简单按输入字数判断。
建立至少一百条真实样本，包含正常、边界和对抗输入。分别记录正确率、格式通过率、首字延迟、总耗时、输入输出令牌与人工复核时间。只有把人工返工成本算进去，才能得到真实的单次成功成本。
百万上下文不代表一次塞满
超长上下文适合合同库、代码仓库和连续会话，但相关信息被大量噪声包围时，答案仍可能变差。应先检索和排序，再把证据、任务说明与输出格式分区组织。对重复的系统说明和公共资料启用缓存，减少费用与等待。
文档更新后要使对应缓存失效，不能让新旧版本混用。回答中要求模型返回证据编号，并由程序检查引用是否存在。涉及金额、日期、权限和法规的结果，还要通过确定性规则或第二模型复核。
思考模式与工具调用的边界
普通抽取和改写默认使用非思考模式，只有多约束规划、复杂诊断等任务才开启思考。开启后仍需限制最大输出和总预算。工具调用必须维护白名单、参数模式和权限范围，模型不能直接获得生产数据库写权限。
对写操作采用“计划、预览、确认、执行”四步。模型先生成结构化计划，程序展示变更内容，人工确认后由独立执行器完成。这样即使模型判断错误，也不会直接修改关键数据。
迁移与灰度发布步骤
旧模型名已经进入迁移阶段，应用应把模型ID放入配置中心而非散落在代码中。先做影子流量对比，再让少量低风险请求进入新模型，观察一周后逐步提高比例。保留快速回滚开关，并记录每次请求实际使用的模型、模式和缓存命中情况。
生产路由可以先走Flash，格式校验失败、置信度低或命中高风险规则时升级Pro。不要无限重试，同一请求最多升级一次；仍不满足条件时转人工，并把样本加入评测集，形成持续改进闭环。
落地检查清单
- 用真实样本比较成功成本而非只看单价。
- 检索后再使用长上下文，并校验证据。
- 写操作使用计划、预览、确认、执行流程。
- 模型ID配置化并保留灰度与回滚。
