DeepSeek V4 来了：Flash / Pro 怎么选才不亏

看到 DeepSeek V4 的更新点，我的第一反应是：终于把工程党天天要用的能力补齐了。写业务、做自动化、搞 Agent，少了 JSON、工具调用这种能力，真的是“能跑但难用”。

这篇就按你能直接照抄照用的方式来讲：两种型号差在哪、每个能力怎么落地、提示词怎么写更稳、以及钱怎么算最清楚。

版本型号：Flash vs Pro，别纠结，按场景切

DeepSeek V4 现在有两个型号：

• Flash：更便宜，更适合高频调用、批量任务、日志清洗、结构化提取、简单问答。
• Pro：更贵，适合更复杂的推理、更长的输出、更严谨的结构化任务、工具链编排。

你可以这么理解：

• 你要的是“吞吐量 + 成本压到地板”，选 Flash ✅
• 你要的是“稳定质量 + 输出更强”，选 Pro ✅

能力清单：这次补的都是硬菜 🍖

V4 这次主打支持很全面，重点是四个：

• JSON 输出：让模型直接吐结构化结果，省掉你一堆正则和兜底解析。
• 工具调用（Tool Calling）：模型能按 schema 生成参数，你的程序拿到参数就能调用函数/接口。
• 对话前缀续写：你可以把“开头”给模型，让它沿着你设定的语气/结构继续写。
• FIM 补全（Fill-in-the-Middle）：写代码/改文案特别舒服，把前后文给它，让它补中间。

接下来每个都给你可执行的写法。

JSON 输出：别再让模型“尽量用 JSON”…直接强约束

适用场景

• 从用户输入里抽取字段：姓名、电话、地址、意向、时间
• 把一段文本转成结构化数据：标题/要点/风险/行动项
• 把客服对话整理成工单

推荐提示词（能直接用）

目标：让模型只输出 JSON，别夹带解释、别加 markdown。

你是一个信息抽取器。
把用户输入整理成严格 JSON。
要求：
- 只输出 JSON，不要输出任何额外文字
- 字段缺失就返回 null
- 不要输出 markdown 代码块

字段：
{
  "name": string|null,
  "phone": string|null,
  "city": string|null,
  "need": string|null
}

用户输入：
“我叫王磊，人在杭州，想做一个简历优化，电话 138xxxx8888”

小技巧

• 你要的是“机器可读”，就别给模型太多自由发挥空间。
• schema 写清楚，null 策略写清楚，解析成功率会明显上去。

常见翻车点（避坑清单）

• 模型输出带注释/多余文字：提示词里必须写“只输出 JSON”。
• 字段拼错：字段名写在提示词最上面，别让它“自创”。

工具调用：让模型出参数，你的程序来执行

工具调用最爽的点是：模型不需要“直接做事”，它负责把意图变成可调用的参数。

典型场景

• 订票/查订单/查天气/查库存
• CRM 里新建客户
• 触发你自己的自动化脚本

你需要准备什么

• 一个函数（或接口）
• 一个参数 schema（告诉模型参数长什么样）

示例：查天气工具（伪代码风格，按你用的 SDK 改）

{
  "tools": [
    {
      "name": "get_weather",
      "description": "查询指定城市天气",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {"type": "string", "description": "城市名"},
          "date": {"type": "string", "description": "日期，如 2026-04-24"}
        },
        "required": ["city"]
      }
    }
  ]
}

用户问：

明天上海下雨吗？

理想情况模型会返回类似：

{
  "tool_call": {
    "name": "get_weather",
    "arguments": {
      "city": "上海",
      "date": "2026-04-25"
    }
  }
}

你的程序拿到 arguments 就能直接调真实天气接口。

工具调用最容易踩的坑

• 参数类型不稳：该是 number 就写 number，别让它用字符串糊弄。
• required 没写：模型会“猜”，然后你后端报错。
• 工具太多：一口气给十几个工具，模型选错概率会上升。按业务分组，按需加载。

对话前缀续写：把“开头模板”交给模型，风格立刻统一

这个能力特别适合做：

• 批量生成同风格文案（朋友圈、短视频脚本、商品卖点）
• 续写你已经写了一半的内容
• 让模型沿用你的写作口吻

实用写法：你写开头，模型接着写

你要续写下面这段文字，保持同样的语气、节奏、段落长度。
只输出续写内容，不要复述前文。

前缀：
“这次我踩坑了。
我以为把提示词写长点就更稳，结果模型开始胡扯。
真正有用的做法是把输出格式锁死……”

小提醒

• 前缀越像“你真实会写的东西”，续写越像你。
• 如果你想让它沿用固定结构（比如每段 2 句、每段结尾加行动建议），把规则写死。

FIM 补全：写代码/改文案的神技，把中间那段交给模型

FIM（Fill-in-the-Middle）适合这种尴尬场景：

• 你代码写到一半，知道前后逻辑，中间那段懒得敲
• 你文案开头结尾定了，中间需要补论据/过渡

通用用法（不依赖特殊 token）

你可以直接把需求说清楚：

请补全中间缺失的内容。
要求：风格和上下文一致。

前文：
function calcPrice(inputTokens, outputTokens, inPrice, outPrice) {

后文：
  return cost;
}

模型就会把中间逻辑补出来。

有的平台会提供专门的 FIM 参数或标记符号；你用哪个 SDK 就按它的文档字段来填，核心思路不变：给前后文，让它补中间。

价格：Flash / Pro 怎么算钱，一眼就会

你关心的就是“输入多少钱、输出多少钱”。V4 的价格是：

Flash

• 输入：¥0.2 / 每百万
• 输出：¥1 / 每百万

Pro

• 输入：¥1 / 每百万
• 输出：¥12 / 每百万

还有一个关键信息：

• 100 万上下文的价格，输出会翻一倍（也就是输出更贵）

费用速算公式

• 输入费用 = 输入量(百万单位) × 输入单价
• 输出费用 = 输出量(百万单位) × 输出单价

真实场景举例（让你心里有数）

你做一个“结构化提取”接口：

• 每次输入 50,000
• 每次输出 2,000

用 Flash：

• 输入：0.05 × 0.2 = ¥0.01
• 输出：0.002 × 1 = ¥0.002
• 合计约 ¥0.012/次

同样任务用 Pro：

• 输入：0.05 × 1 = ¥0.05
• 输出：0.002 × 12 = ¥0.024
• 合计约 ¥0.074/次

差距很直观：任务简单、量大，Flash 更香；任务复杂、出错成本高，Pro 更稳。

选型建议：按“错误成本”来决定

你可以拿这张清单做决定：

• Flash 更适合

  • 批量清洗、摘要、分类、标签
  • 简单结构化 JSON（字段少、容错高）
  • 日常高频问答、内容改写

• Pro 更适合

  • 复杂工具链（多个工具、参数多、需要更强的判断）
  • 长输出、长上下文任务
  • 结构化结果特别关键（出错就要你半夜爬起来修）

我自己的经验是：

• 默认用 Flash 跑通流程
• 在关键节点切 Pro 做兜底（比如最终输出、关键决策、工具调用前的校验）

省钱省心，两头都拿到 😄

稳定性的关键：把“输出”当成产品接口来设计

想让 V4 真正好用，别把它当聊天机器人。

把输出当接口：

• 输出字段固定
• 出错策略固定（缺失就 null、校验失败就返回 error 字段）
• 工具参数有 schema

你会发现：模型瞬间从“玄学”变成“工程可控”。

如果你愿意，我也可以按你的业务场景（比如：客服工单、简历解析、商品入库、自动写日报）给你配一套可直接上线的提示词模板 + 工具 schema。你告诉我输入长什么样、你希望输出长什么样就行。