DeepSeek‑V4 Preview：1M 上下文到底怎么用才爽？

你有没有遇到过这种崩溃场景：

• 领导甩你一个 300 页 PDF：“十分钟给我要点 + 风险点”
• 代码仓库一大坨：“帮我找出性能瓶颈，顺便写优化建议”
• 客服/运营对话记录几十万字：“总结客户痛点，列出可落地的改进项”

过去大模型经常卡在“上下文不够、塞不下”。现在 DeepSeek‑V4 Preview 把 1M 上下文拉到台面上，而且是开源路线。🎯

这篇就按“能照做”的方式写：选型、网页怎么用、API 怎么接、长上下文提示词怎么写、常见坑怎么躲。

版本怎么选：Pro vs Flash（别纠结，按任务来）

官方这次给了两条线：

• DeepSeek‑V4‑Pro：总参数 1.6T / 激活 49B。定位是“强推理、强复杂度”。
• DeepSeek‑V4‑Flash：总参数 284B / 激活 13B。定位是“更快、更省、更适合日常高频”。

你直接照这个选：

• 你要做 复杂推理、方案对比、长链路分析、技术架构评审 → Pro
• 你要做 批量总结、信息抽取、分类打标、快速问答、跑很多次的任务 → Flash

一句话：Flash 负责把你从加班里救出来，Pro 负责把你从“结论不靠谱”里救出来。

网页端实操：Expert Mode / Instant Mode 怎么用

入口：chat.deepseek.com

你会看到两种模式（名字可能会随产品更新微调）：

• Instant Mode：偏“秒回”。适合短问答、快速改写、即时总结。
• Expert Mode：更像“认真干活”。适合复杂任务、长文档处理、需要格式化输出的活。

一个好用的工作流（强烈建议抄走）

把任务拆成三段：目标 → 约束 → 输出格式。

你可以直接用下面这套模板：

你现在是我的{角色/岗位}。
目标：{你想要的最终结果}
材料：我会分段粘贴，直到我说“材料结束”。
要求：
- 只基于材料，不要脑补
- 不确定的地方标注“待确认”
- 输出用 Markdown
输出结构：
- 3 行摘要
- 关键结论（列表）
- 风险/争议点（列表）
- 下一步建议（按优先级）

场景例子：长文档总结

把 PDF/会议纪要/合同条款复制进去，粘贴多次也行。等你说“材料结束”，它再开始输出。1M 上下文的优势就在这：你不用每次删删减减。

1M 上下文的正确打开方式：不是“塞满”，是“塞得有层次”

很多人以为上下文变长=无脑把东西全丢进去。

结果就是：模型确实读了，但输出像一锅粥。

更稳的做法是：给材料加“目录”和“锚点”。

推荐格式：给每段材料加 ID

[DocA-01] ……
[DocA-02] ……
[Email-03] ……
[Log-04] ……

然后你在提问里要求它引用：

回答时必须标注引用来源，比如（DocA-02）。
如果无法从材料找到依据，写“材料未覆盖”。

这一步能让输出质量直接上一个档次，而且方便你复核。

API 怎么接：一份“可改就能跑”的通用模板

原始信息里提到 API 已更新可用。不同团队的 SDK/网关封装不一样，你拿到官方文档后，把下面几个点对上就行：

• base_url（网关地址）
• model（Pro / Flash 对应的模型名）
• token（鉴权）
• max_tokens（输出长度）
• 上下文策略（超长输入时，是否要自己做分块/摘要）

Python（requests）模板

import os
import requests

API_BASE = os.getenv("DEEPSEEK_API_BASE")  # 例如：https://xxx
API_KEY = os.getenv("DEEPSEEK_API_KEY")
MODEL = os.getenv("DEEPSEEK_MODEL", "DeepSeek-V4-Flash")

payload = {
    "model": MODEL,
    "messages": [
        {"role": "system", "content": "你是严谨的技术助理，引用依据，别脑补。"},
        {"role": "user", "content": "把我接下来粘贴的材料总结成：3行摘要+风险点+行动项。"}
    ],
    # 这里的字段名以官方文档为准：有的叫 max_tokens / output_tokens
    "max_tokens": 1200,
    "temperature": 0.2
}

resp = requests.post(
    f"{API_BASE}/chat/completions",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=120
)

resp.raise_for_status()
print(resp.json())

什么时候该用 Pro，什么时候该用 Flash（API 侧）

• 你在做 评审、归因、复杂决策：默认 Pro，temperature 低一点（0~0.3），让它稳。
• 你在做 批处理抽取：默认 Flash，temperature 更低（0~0.2），一致性更好，也更省。

开源权重怎么玩：别冲动，先看你机器扛不扛得住

官方给了两类资源：

• Tech Report（技术报告）
• Open Weights（开源权重，HuggingFace）

链接在原始信息里：

• 技术报告：huggingface.co/deepseek-ai/...
• 开源权重合集：huggingface.co/collections/...

现实建议：

• 你只是要“用起来、产出快” → 直接用网页端或 API。
• 你要做“私有化、内网、合规、可控” → 再考虑权重。

开源权重体积通常很大，显存、CPU 内存、磁盘都得算清楚。别一上来就“我在笔记本上本地跑 1.6T”，那基本是在跟自己过不去。😅

直接可用的提示词：3 个高频场景

场景 1：长文档提炼（会议纪要/PDF/PRD）

你是我的项目助理。
材料会很长，我会分段粘贴，直到我说“材料结束”。
输出：
- 3行摘要
- 决策清单（谁/做什么/截止时间）
- 风险点（影响×概率×应对）
- 未决问题（需要谁补充什么信息）
规则：只基于材料，引用段落ID。

场景 2：代码仓库审查（长上下文优势很明显）

你是资深代码审查员。
我会粘贴多段代码和说明，直到“材料结束”。
请输出：
- 5个最高优先级问题（每个：位置ID/问题/影响/修复建议）
- 性能瓶颈猜测（标注依据）
- 可落地的重构路线（按周拆分）
要求：不要泛泛而谈，建议要具体到函数/模块。

场景 3：客服对话/工单挖需求

你是产品经理。
我会粘贴对话记录，直到“材料结束”。
你要做：
- 用户痛点Top10（每条给原话证据ID）
- 需求机会（按影响范围排序）
- 可执行改动（每条：改什么/怎么验证/预期指标）
限制：不要编故事，没有证据就写“未出现”。

避坑清单（这些坑很常见）

• 把一堆材料直接糊上去：没有段落 ID，没有引用规则，输出必然飘。
• 要求太多又不给输出格式：模型会“每样来一点”，看着像写了很多，实用价值很低。
• 长上下文里混入无关内容：比如你把聊天记录、草稿、旧版本方案全塞进去。模型会被噪音带歪。
• 温度开太高：长文档任务追求稳定，temperature 低一点更像“靠谱同事”。
• 不做复核闭环：让它给引用 ID，你抽查 3~5 条关键结论，效率比你从头读快太多。

你可以马上开始的 10 分钟小练习

• 找一份长 PDF（合同/方案/论文都行）
• 手动加 20 个段落 ID（复制粘贴时顺手加）
• 用 Expert Mode 跑“摘要 + 风险 + 行动项”
• 抽查 5 条引用

如果这套跑顺了，你会明显感觉：长上下文不是噱头，是能把一堆碎活一次性做干净。

想继续进阶的话，你下一步就该做两件事：

• 把“段落 ID + 引用输出”变成团队统一模板
• API 接起来做批处理：自动总结、自动抽取、自动归档