[Bug] Manually added DeepSeek provider shares the same API key as the built-in DeepSeek model

[tigerfsh]

Environment: dsh --version → 0.2.1-alpha.2

Summary:
When adding a model provider and selecting DeepSeek, the manually added DeepSeek model shares the same API key as the built-in DeepSeek model.

Steps to reproduce:

1. dsh --version → 0.2.1-alpha.2
2. Add Model Provider → select DeepSeek
3. Enter an API key for the manually added model
4. Check the built-in DeepSeek model's API key

Expected:
The manually added DeepSeek model and the built-in one should each have their own independent API key.

Actual:
They share one API key. In practice they're used interchangeably, so editing one also changes the other — meaning one of the two models is always unusable.

Impact:
Can't use both the built-in and the manually added DeepSeek model at the same time.

[PerryLink]

这个不是 bug，是凭据引用同名的必然结果。原因一句话就能说清：你手工加的那条路由派生的引用名，和内置那条用的是同一个字符串。

为什么一定撞

手工卡片的引用名是按路由名算出来的。packages/client/ui-settings-models/src/client/store.ts:125-127：

export function deriveKeyRef(provider: string): string {
  return `${provider.toUpperCase().replace(/[^A-Z0-9]+/g, '_')}_API_KEY`
}

你那条路由叫 deepseek，于是派生出 DEEPSEEK_API_KEY。

再看内置那条：packages/llm/llm-deepseek-api-key/src/config.ts:16 → apiKeyEnv: z.string().role('credential-ref').default('DEEPSEEK_API_KEY').volatile()。

两边逐字同名。 而 credentials 的解析是按引用名走的（packages/credentials/credentials/src/index.ts:154-170 那两类键空间，resolve(ref) 只认 ref），key 从来不按 provider 分段。所以它们指向的是同一个槽位——你在任一处改，另一处自然就跟着变。

有一处你可能没意识到

内置那条路由的名字其实不叫 deepseek，叫 deepseek-official（packages/llm/llm-deepseek-api-key/src/index.ts:15 → const PROVIDER = 'deepseek-official'）。

历史上 deepseek 这个名字让给了 pi-ai catalog 的聚合条目（.agents/notes/archived/architecture/2026-07-30-web-config-plane.md:22 记了这次改名）。你手工路由沿用了 deepseek，才会撞名。 换个名字就不会撞。

立刻能用的两种改法

改引用名：把那条 provider profile 的 apiKeyEnv 改成另一个合法名字，比如 DEEPSEEK_MANUAL_API_KEY，再在那一行填 key。引用名的格式要求是 /^[A-Za-z_][A-Za-z0-9_]*$/（credentials/src/index.ts:19），普通标识符都行。这样两边各存各的。

改路由名：把它改成例如 deepseek-alt，派生引用自动变成 DEEPSEEK_ALT_API_KEY，效果一样，还顺带解决了命名混淆。

（顺带说一句，deepseek-account 那条账号/订阅路由不参与这个派生——store.ts:241 对它有特判。所以你说的"内置 DeepSeek"如果指的是账号路由，那就是另一回事了，方便的话确认一下。）

一点建议

我不建议按"每个 provider 应该有独立 key"来提，因为同一个端点配多条路由、共用一把 key 是正当用法，强制隔离反而会挡掉它。

如果你想提改进，可以考虑这个小点：手工卡片在派生出的引用名与已有路由重名时给个提示，或者自动去重（packages/client/ui-settings-models/src/client/CustomProviderCard.tsx:156 附近就是算 keyRef 的地方）。这比改语义轻得多，也不影响现有行为。

另外文档侧也值得补一句：Models 页现在没有说明"派生引用 = <路由名>_API_KEY，路由同名即共用 key"。这个坑大概不止你一个人踩。

边界

我核的是 origin/master = 571902028a（2026-10-14）上引用派生（deriveKeyRef）与引用解析两侧，逐行对过。

你写的版本 0.2.1-alpha.2 有效，不用改。另外我没有实测你在界面上看到的具体表现（比如"编辑一个会改变另一个"到底是什么交互），上面是代码层面的机制；如果实际症状和这个机制对不上，把操作步骤贴出来我再看。

[tigerfsh]

改引用名，问题已解决，不过现在的解决方案对普通用户（不懂编程）不友好。再次感谢及时答复