上周我接手了一个老项目——一个 monorepo 里塞了 6 个子包、光 src 目录就有 1200+ 个 .tsx 文件的 React 后台系统。之前用 Claude Sonnet 4.6 在 Cursor 里做代码理解，上下文窗口不够用，经常问到一半它就"失忆"了，改着改着给我把另一个模块的类型定义搞丢。正好 DeepSeek 放出了 V4-Pro，号称百万 token 上下文，我就花了两天时间在 Cursor 里配好跑了一轮。结论是：读大 codebase 这个场景，V4-Pro 的长上下文确实能打，但有几个坑你不提前知道会浪费很多时间。
这篇文章把我从配置到实测的完整过程写出来，Cursor 的 settings.json 怎么改、base_url 怎么填、实际读代码效果怎么样，全部贴出来。
先说结论
| 维度 | DeepSeek-V4-Pro | Claude Sonnet 4.6 | GPT-5.5 |
|---|---|---|---|
| 有效上下文长度 | ~100 万 token | ~20 万 token | ~25.6 万 token |
| 读 1200 文件 monorepo | ✅ 能追踪跨包引用 | ❌ 超过 800 文件开始丢信息 | ⚠️ 勉强，尾部质量下降 |
| 前端代码理解 | 强，JSX/TSX 解析准确 | 最强，细节把控好 | 强，但偶尔幻觉 |
| 响应速度（首 token） | ~1.2s | ~0.8s | ~0.6s |
| 价格（百万输入 token） | 便宜 | 贵 3-4 倍 | 贵 2-3 倍 |
| 适用场景 | 大项目全局理解、重构 | 精细修改、代码 | 通用开发 |
一句话：需要"通读整个项目再回答"的任务给 V4-Pro，需要"改好这 3 个文件"的任务给 Claude。
环境准备
我的开发环境：
- macOS Sonoma 14.5
- Cursor 0.48.x（2026 年 6 月最新版）
- Node.js 22 LTS
- 项目：React 18 + TypeScript 5.4 + pnpm monorepo，共 ~18 万行代码
你需要准备：
- Cursor 最新版（确保支持自定义模型配置）
- 一个能调用 DeepSeek-V4-Pro 的 API Key
- 你的大型前端项目（小项目体感不明显，建议 500+ 文件以上的试）
方案一：Cursor Settings UI 配置（适合大多数人）
打开 Cursor → Settings → Models，往下翻到 OpenAI API Key 那一栏。
这里有第一个坑：Cursor 原生不支持 DeepSeek 作为 Provider。你不能像选 OpenAI 或 Anthropic 那样直接下拉选，得走 "OpenAI Compatible" 的方式。
步骤：
- 打开 Settings → Models
- 滚到底部，找到 "Add model"
- Model name 填：
deepseek-v4-pro - 勾选 "OpenAI Compatible"
然后在 Override OpenAI Base URL 里填你的 API 地址。我一开始填的 DeepSeek 官方地址，延迟波动比较大，后来换成了聚合接口，稳定多了：
https://api.ofox.ai/v1
API Key 填你在对应平台拿到的 Key，保存。
这时候在 Cursor 的模型选择器里就能看到 deepseek-v4-pro 了。
方案二：直接改 settings.json（我推荐这个）
UI 配置有个问题——有时候 Cursor 更新后会重置你的自定义模型配置。我被坑过一次，升级完发现模型列表里 V4-Pro 没了，又得重新加。
直接改配置文件更靠谱。
按 Cmd + Shift + P，输入 Open User Settings (JSON)，在 settings.json 里加上：
{
"cursor.aiModels": [
{
"name": "deepseek-v4-pro",
"provider": "openai-compatible",
"apiKey": "sk-your-api-key-here",
"baseUrl": "https://api.ofox.ai/v1",
"model": "deepseek-v4-pro",
"contextLength": 1000000,
"maxTokens": 8192,
"temperature": 0.3
}
],
"cursor.defaultModel": "deepseek-v4-pro",
"cursor.chat.contextLength": "long"
}
几个参数解释一下：
contextLength: 1000000：告诉 Cursor 这个模型支持 100 万 token 上下文，Cursor 会据此决定往 prompt 里塞多少文件内容maxTokens: 8192：单次回复最大长度，V4-Pro 最大支持 16K 输出，但我建议先设 8K，太长容易跑偏temperature: 0.3：读代码理解类任务建议低温度，别让它发挥创意
保存后重启 Cursor，在聊天窗口左上角切换模型，应该能看到 deepseek-v4-pro。
graph LR
A[Cursor IDE] -->|settings.json 配置| B[OpenAI Compatible 协议]
B -->|base_url: api.ofox.ai/v1| C[ofox 聚合网关]
C -->|路由| D[DeepSeek-V4-Pro]
C -->|备选| E[Claude Sonnet 4.6]
C -->|备选| F[GPT-5.5]
D -->|百万上下文| G[读取整个 monorepo]
实测：拿 1200 文件的 React monorepo 跑一轮
配好之后我做了几组测试，记录一下真实体验。
测试 1：全局依赖关系梳理
Prompt：
请分析这个 monorepo 的包依赖关系，列出每个子包的职责、
对外暴露的核心 API，以及子包之间的调用链路。
重点标注循环依赖。
我用 @codebase 把整个项目喂进去。
V4-Pro 的表现：大概等了 8 秒出第一个 token（长上下文首次推理确实慢），然后花了约 45 秒输出了一份相当完整的分析。6 个子包的职责描述基本准确，而且真的找出了 @app/utils 和 @app/hooks 之间的一个循环引用——这个我自己之前都没注意到。
Claude Sonnet 4.6 对照组：因为上下文塞不下全部文件，Cursor 做了截断，最后 Claude 只分析了 4 个包，另外 2 个压根没提到。
测试 2：跨文件重构建议
Prompt：
我想把所有子包里散落的 API 请求逻辑统一收到 @app/api 包里。
请分析当前所有直接调用 fetch/axios 的文件，
给出迁移方案和优先级排序。
这个任务需要扫描所有文件找 fetch 和 axios 调用，V4-Pro 找到了 47 处，我用 grep -r 验证了一下，实际是 52 处。漏掉的 5 处里有 3 处是写在 eval() 字符串里的（说实话这代码写得确实离谱），2 处是用了项目自封装的 request 函数但没 import axios。
准确率 90%，对于"读完整个项目再回答"这种任务来说，已经很能打了。
测试 3：单文件精细修改
这个测试是故意的——我让 V4-Pro 改一个 200 行的 React 组件，加一个 loading 状态。
说实话，这种小任务 V4-Pro 反而不如 Claude。它给的代码能跑，但 TypeScript 类型写得比较粗糙，有两处用了 any。同样的任务 Claude Sonnet 4.6 给出的代码类型完整，还顺手帮我把一个 useEffect 的依赖数组修好了。
所以我现在的工作流是混用的：全局理解和大范围重构用 V4-Pro，精细修改切回 Claude。
踩坑记录
坑 1：contextLength 没设对，白瞎了百万上下文
最蠢的一个坑。我一开始没在 settings.json 里写 contextLength，Cursor 默认按 128K 处理，结果喂进去的文件被大幅截断，V4-Pro 的回答质量跟 Claude 差不多——我还纳闷说好的百万上下文呢？
后来翻 Cursor 的 GitHub Issues 才发现，必须显式声明 contextLength，Cursor 才会按照这个长度去组装 prompt。
坑 2：首次推理巨慢，别以为是挂了
百万上下文的代价就是首 token 延迟高。我第一次跑全项目扫描的时候等了 12 秒没反应，以为请求挂了，取消重发了 3 次，白白浪费了 token。
正常现象：喂入文件越多，首 token 等待越久。我的 1200 文件项目大概要 6-12 秒，如果你的项目更大，20 秒也别慌。
坑 3：.cursorrules 要针对性调整
如果你之前写了 .cursorrules 文件，里面可能有类似"回答要简洁"的指令。这在短上下文模型上没问题，但在 V4-Pro 的百万上下文场景下，你反而希望它回答得详细一些——它能看到更多代码，简洁回答会丢掉很多有价值的分析。
我现在的 .cursorrules 针对 V4-Pro 加了一段：
当使用 deepseek-v4-pro 模型时：
- 分析代码时请尽可能覆盖所有相关文件
- 给出重构建议时列出所有受影响的文件路径
- 不要省略跨包的依赖关系分析
坑 4：Streaming 偶尔断流
这个问题不确定是 Cursor 的锅还是网络的锅。长回复（超过 4000 token）的时候偶尔会断一下再续上，体感像是卡了。我后来把 maxTokens 从 16384 降到 8192，断流频率明显降低了。如果你也遇到这个问题，先试试降 maxTokens。
成本粗算
跑了一周，我大概统计了一下用量：
| 任务类型 | 日均调用次数 | 平均输入 token | 平均输出 token | 日成本（约） |
|---|---|---|---|---|
| 全局代码分析 | 3-5 次 | ~50 万 | ~3000 | ¥8-15 |
| 跨文件重构 | 5-8 次 | ~20 万 | ~2000 | ¥5-10 |
| 单文件修改（切 Claude） | 15-20 次 | ~5000 | ~1500 | ¥3-5 |
一天下来大概 ¥15-30，一个月 ¥500 左右。比纯用 Claude 便宜不少，因为 V4-Pro 的定价本身就低，大任务用它一次搞定，不用反复追问。
小结
DeepSeek-V4-Pro 在 Cursor 里的最佳使用场景很明确：大型项目的全局理解和跨文件分析。百万上下文不是噱头，在 1000+ 文件的前端 monorepo 里确实能感知到和 20 万上下文模型的差距。
但它不是万能的。精细的单文件修改、TypeScript 类型推导这些活儿，Claude Sonnet 4.6 依然更靠谱。我现在就是两个模型混着用，Cursor 切模型也就是点一下的事。
配置上最关键的就两点：settings.json 里 contextLength 必须显式写 100 万，base_url 用一个稳定的聚合接口（我用的 ofox.ai，一个 API Key 能同时调 DeepSeek、Claude、GPT-5.5，切模型不用换 Key，省得来回折腾鉴权）。
搞定这两点，剩下的就是根据你的项目调 .cursorrules 了。有问题评论区聊。
