使用 Codex 配置 Zed 支持 DeepSeek v4 后的一些思考

2026.05.01

·AICodexZedAIGC

今天上午看到 DeepSeek 将其旗舰模型 DeepSeek-V4-Pro 的官方定价直接砍掉了 75%，之前在 zed 里配置过 deepseek ，所以想着配置下看看deepseek v4 pro 的效果如何。

一开始就发现：我看不到 Zed 的 AI 入口，后来又配置了 DeepSeek，但 Agent 能用，代码预测不太对。这个问题如果按以前的方式，大概率就是：打开文档，看一段，试一个配置，重启，再看一段，再试一个配置。

最后可能也能解决，但很慢，而且很容易卡在“我是不是哪里写错了”这个阶段。

这次不一样。Codex 直接帮我读文档、读本地配置、读 Zed 日志、请求 DeepSeek 接口做对照，最后把问题拆清楚了。

一次 Zed AI 预测排障：文档之外，日志才是答案

1. 时间线 ​

1.1. 第一步，AI 入口不见了。 ​

Codex帮我读本地配置里，发现 disable_ai 是 true，所以 Zed 直接把 AI 功能关掉了。改成 false 后，入口恢复。

1.2. 第二步，DeepSeek 不能选。 ​

Zed 的 Agent 模型和 Edit Prediction 不是一回事。Agent 可以配置 DeepSeek provider，但预测是另一套 provider。于是又给 language_models.deepseek 配了模型，并把 Agent 默认模型切到 DeepSeek。

1.3. 第三步，提示缺少 DeepSeek API key。 ​

codex 帮我读日志里明确写着：

text
missing DeepSeek API key

这说明不是模型名的问题，是 Zed 没拿到 key。后来 Agent 的 key 配好了，Agent 请求已经能走 DeepSeek。

1.4. 第四步，开始配置代码预测。 ​

Zed 文档里说，Edit Prediction 支持 open_ai_compatible_api。DeepSeek 文档里也有 FIM Completion，看起来可以接：

json
"edit_predictions": {
  "provider": "open_ai_compatible_api",
  "open_ai_compatible_api": {
    "api_url": "https://api.deepseek.com/beta/completions",
    "model": "deepseek-v4-pro",
    "prompt_format": "deepseek_coder"
  }
}

然后又发现预测这条链路用的是单独的环境变量：

bash
ZED_OPEN_AI_COMPATIBLE_EDIT_PREDICTION_API_KEY

这一步很关键。Agent 里的 DeepSeek key，不等于预测里的 OpenAI-compatible key。

1.5. 第五步，预测终于请求到了，但结果很怪。 ​

Zed 日志里不再是没配置，而是 DeepSeek 返回了 401。配置环境变量、重启 Zed 后，401 消失，说明链路打通了。

但新的问题出现了：预测内容里出现了一堆 FIM 控制符，比如 <fim▁end｜> 这一类东西。它不是不能请求，而是结果完全不像正常代码预测。

1.6. 第六步，做接口对照。 ​

Codex 直接用同一个 key 请求 DeepSeek FIM。

用 DeepSeek 官方的 prompt + suffix 格式，请求是正常的，会返回类似：

js
 a + b;

但用 Zed 当前的方式，它不是把 suffix 作为字段传给 DeepSeek，而是把前缀和后缀拼成一段带 FIM token 的 prompt。这个格式对 DeepSeek v4 来说效果很差。

我试了补全，看看效果，如下，完全不可读

javascript
function add(a, b) {
  return  + <｜fl0><｜f#️⃣#️⃣> + <#️⃣#️⃣> + parseFloat('1.2') + true + 0;
}

// add(1, 2);
true;
<#️⃣#️⃣>
a.b()<f#️⃣#️⃣><fim▁end｜>;){
  return  <#️⃣#️⃣> + <f#️⃣#️⃣> + parseFloat<#️⃣#️⃣>(<fl<#️⃣#️⃣>; + true + 0;
}

2. 最后结论 ​

DeepSeek Agent 可以继续用。

但 DeepSeek v4 不适合作为 Zed 当前 OpenAI-compatible Edit Prediction 的模型。

原因不是 DeepSeek 不能补全，也不是 API key 不对，而是两边的 FIM 协议不完全对齐：

  • DeepSeek 官方 FIM 更适合 prompt + suffix。
  • Zed 当前 OpenAI-compatible prediction 发的是拼好 FIM token 的 prompt。
  • 请求能通，但返回格式完全不兼容，不可读。

所以最后的选择很明确：

Agent 用 DeepSeek。

代码预测要么先用 Zed/Zeta、Copilot、Codestral，要么先关掉，不要硬把 DeepSeek v4 接上去。

3. 这次真正有价值的地方 ​

这次让我很有感触的不是“配好了一个编辑器”，而是排障方式变了。

以前遇到这种问题，我会自己看文档。文档里每句话都像是对的，但真正的问题常常藏在本地环境里：哪个配置没生效、哪个环境变量没被 GUI 进程读到、日志里真正报的是什么、接口直接请求到底能不能返回。

这些事情人也能做，但要来回切很多次。

这次 Codex 一口气吃下了几个层面：

  • Zed 官方文档；
  • DeepSeek FIM 文档；
  • 本地 settings.json；
  • Zed 运行日志；
  • shell 环境变量；
  • 直接 curl 接口返回；
  • Zed 源码里实际怎么发请求。

所以它不是在“猜配置”，而是在沿着真实链路排查。

这就是我觉得 AI Agent 真正改变工作方式的地方：它不只是告诉我“你应该怎么配”，而是能把文档、本地状态、日志、源码、接口结果放在同一个上下文里，一层一层排掉。

最后的答案反而很简单：

不是我不会配，也不是 DeepSeek 不能用，而是这条预测协议现在不适合硬接。

这个结论，如果只靠人工看文档，我可能要折腾很久。通过 Codex，基本上是在一次对话里，把问题从“好像不生效”推进到了“知道为什么不值得继续配”。

这才是最省时间的地方。