Appearance
DeepSeek V4 支持 1M 上下文，但长上下文不是“把所有资料都塞进去”。正确做法是先筛选、再分块、再摘要、再让模型回答。长上下文适合长文档分析、代码库理解和 Agent 工作流，但要控制重复输入和输出长度，否则成本和稳定性都会变差。
DeepSeek 长上下文怎么用
DeepSeek V4 的一个重要卖点是 1M 上下文。很多人看到这个数字，会自然想到：那我是不是可以把所有文档、聊天记录、代码库都塞进去？
不建议这么用。
长上下文的价值，是让模型能处理更完整的材料；不是让你放弃信息筛选。
1M 上下文适合什么
| 场景 | 是否适合 | 建议 |
|---|---|---|
| 长文档总结 | 适合 | 先分章节，再汇总 |
| 合同、报告、论文分析 | 适合 | 要求引用段落或位置 |
| 代码库理解 | 适合 | 先给目录和关键文件 |
| Agent 多轮任务 | 适合 | 保留关键状态，压缩历史 |
| 短文本分类 | 不需要 | 用短上下文即可 |
| 简单翻译 | 不需要 | 不要为小任务塞长背景 |
长上下文不是每个任务都需要。简单任务用短输入更快、更便宜、更稳定。
错误用法：什么都塞进去
最常见的错误是：
text
把整个项目、所有日志、所有聊天记录、所有文档一次性发给模型。这样有三个问题。
第一，成本高。输入越长，token 越多，调用成本越高。
第二，注意力被稀释。无关内容太多，模型更难抓住重点。
第三，结果不可控。模型可能引用不重要的段落，或者被旧信息干扰。
1M 上下文解决的是“放不下”的问题，不解决“不会筛选”的问题。
推荐流程：筛选、分块、摘要、回答
长文档任务建议用四步：
text
筛选相关材料
-> 按章节或文件分块
-> 每块提取要点
-> 汇总后回答最终问题比如你要分析一份 200 页报告，不要直接问“这份报告讲了什么”。更好的问法是：
text
请按章节提取这份报告中和“成本控制”有关的内容。
每章输出：
1. 关键结论
2. 支撑数据
3. 风险或限制
4. 原文位置先把材料变成结构化中间结果，再让模型做最终总结。
代码库场景怎么用
代码库尤其不能一股脑塞进去。更好的顺序是：
- 先给目录树。
- 说明你要解决的问题。
- 让模型判断可能相关的文件。
- 再提供这些文件内容。
- 最后让模型给修改建议或补丁。
示例：
text
这是项目目录树。我的问题是：登录后偶尔跳回登录页。
请先判断最可能相关的文件，不要直接给结论。模型指出文件后，再把关键文件贴进去。这样比直接塞整个仓库更省，也更准。
多轮对话要压缩历史
Agent 和多轮对话最容易无限膨胀。每轮都把完整历史传回去，成本会越来越高，模型也会越来越容易被旧信息干扰。
更好的做法是保留三类信息：
- 当前目标。
- 已做决策。
- 仍然相关的事实和约束。
可以把旧历史压缩成：
text
当前任务：修复支付回调重复入账。
已确认事实：
1. 回调接口可能被支付平台重试。
2. 数据库没有唯一幂等键。
3. 用户不希望修改订单表结构。
下一步：检查 payment_log 表是否能承载幂等记录。这比保留 30 轮完整对话更适合继续工作。
长上下文和缓存
DeepSeek API 的价格会区分缓存命中和未命中。长上下文任务里，固定前缀越稳定，越容易利用缓存思路降低成本。
可以稳定复用的内容：
- system prompt
- 输出格式要求
- 固定业务规则
- 固定工具描述
- 长文档中不变的前置材料
每次都变的用户问题、临时日志、无关历史，不要放进固定前缀。
更多成本控制可以看：DeepSeek API 怎么省钱。
常见问题
Q: 1M 上下文是不是越长越好？
A: 不是。上下文越长，成本越高，干扰也越多。只放和当前问题相关的材料。
Q: 长文档应该一次性总结，还是分块？
A: 重要文档建议分块。先提取每块要点，再做总摘要，结果更稳定，也方便检查遗漏。
Q: 代码库能不能整仓库丢给 DeepSeek？
A: 技术上可能能放更多，但工程上不推荐。先给目录和问题，让模型判断相关文件，再提供文件内容。