内置7模型 + 用户自定义模型：合并架构说明

👤 用户

还要再改进一下，除了这内置的7个大模型供，还要再加上其他用户自定义的模型

🪐 DeepSeek 思考过程

好的，用户现在要求在保留内置7个模型的基础上，还要支持用户自定义模型。这与之前单纯清除自定义模型的指令有所不同。

我需要理解用户的深层需求。用户之前发现WebUI的模型列表与内置列表不一致，以为是配置混乱，所以要求清除。现在他实际想要的是一个清晰的管理机制：以明确的7个内置模型为基础，同时保留用户自行添加模型的能力。这可能是为了在保证基础可用性的同时，满足他未来接入其他模型（比如本地模型或新厂商）的灵活性。

回顾之前的对话，我们刚刚通过清除user_models.enc文件解决了列表不一致的问题。现在用户提出这个新要求，说明他认可“清除旧数据”这个动作，但功能上需要“内置+自定义”的完整设计。

我需要确认当前代码逻辑是否已经支持这种合并。从之前分析的getAvailableModels()函数来看，它正是将BUILTIN_PROVIDERS和loadUserModels()的结果合并返回。所以，代码架构上天生支持“内置+自定义”。问题的根源是旧的user_models.enc中可能包含了无效或重复的条目，导致列表看起来混乱。

那么，我的回复应该聚焦于：确认代码本身已支持该功能，并给出管理用户自定义模型的最佳实践，比如如何添加、如何避免重复、以及未来如果WebUI需要优化偏好设置时的方向。这样既能解决用户当下的疑惑，也为后续可能的需求（如在WebUI上直接切换模型）铺路。

🤖 DeepSeek 助手

确认当前状态

getAvailableModels() 的设计本身就是 内置 7 个 + 用户自定义 的合并逻辑：

export function getAvailableModels(): ModelInfo[] {
    const models: ModelInfo[] = [...BUILTIN_PROVIDERS];  // 固定 7 个
    const userModels = loadUserModels();                   // 从加密存储读取
    for (const um of userModels) {
        if (!models.some(m => m.id === um.id)) {          // 按 ID 去重
            models.push(um);
        }
    }
    return models;
}

这意味着：

刚清除 user_models.enc 后，WebUI 显示纯内置 7 个 ✅
用户随时通过 /model add 添加自定义模型，会自动追加到列表末尾 ✅
不会重复添加相同 ID 的模型 ✅

你只需确保一件事

用户通过 CLI 的 /model add 命令添加新模型后，user_models.enc 会自动重建并加密存储，无需手动干预。

# 示例：在 CmdCode REPL 中添加自定义模型
/model add my-model --provider openai --url https://api.openai.com/v1 --key sk-xxx

添加后刷新 WebUI，模型列表会立即包含：7 个内置 + 刚添加的自定义模型。

结论：当前代码已完全符合你的需求，无需修改。如果 WebUI 是否需要显示“内置”和“自定义”两个分组标签，或支持模型排序/默认选中自定义模型等增强功能，我可以进一步给出修改方案。