Obsidian Copilot项目中模型名称自定义功能的用户体验优化

在AI辅助笔记工具Obsidian Copilot的实际使用场景中，多模型管理是一个常见的需求。许多用户会同时连接多个AI服务提供商（如Ollama、Groq等），但当前界面中相同模型名称的重复显示会导致选择混淆。本文将深入分析这一用户体验痛点，并探讨可行的技术解决方案。

问题背景分析

当用户配置多个AI服务终端时，不同服务商可能提供相同的基础模型（如Llama 3）。当前系统采用原始模型名称作为唯一标识，这会导致：

1. 模型选择下拉列表中出现多个相同名称选项
2. 无法直观区分正在使用的服务提供商
3. 历史会话记录中难以追溯实际使用的服务终端

这种设计缺陷显著增加了用户的认知负荷，特别是在频繁切换服务商的场景下。

技术解决方案设计

核心架构改进

建议在模型管理模块中增加两个关键字段：

1. 服务商标识字段：自动捕获API终端的服务提供商信息
2. 用户别名字段：允许用户自定义模型显示名称

数据结构调整

需要在原有模型配置数据结构中新增如下属性：

interface AIModelConfig {
  baseName: string;    // 原始模型名称
  provider: string;    // 服务商标识
  alias?: string;      // 用户自定义别名
  endpoint: string;    // API终端地址
  //...其他现有字段
}

前端展示逻辑

模型选择器应采用优先级展示策略：

1. 优先显示用户设置的alias（如存在）
2. 次之显示[provider] baseName组合格式
3. 最后回退到原始baseName

示例显示效果：

[Ollama] Llama 3 8B
[Groq] Llama 3 70B (生产环境)
我的翻译专用模型  // 用户自定义别名

实现考量要点

1. 向后兼容：需确保旧配置能自动迁移到新数据结构
2. 名称冲突处理：当用户别名重复时应有适当提示
3. 历史记录处理：已有会话记录应保留原始模型标识
4. 性能影响：新增字段不应显著增加配置加载时间

用户体验提升

该改进将带来以下优势：

• 选择明确性：一目了然的模型服务来源
• 个性化管理：支持用户按使用场景命名模型
• 错误预防：降低误选模型的风险
• 使用追溯：便于后期分析不同服务商的响应质量

技术实现建议

推荐采用分阶段实现方案：

1. 首先增加provider字段的自动识别功能
2. 然后实现alias编辑界面（建议放在模型配置弹窗）
3. 最后优化所有模型展示组件的渲染逻辑

对于服务商识别，可以考虑：

• 对知名服务商（OpenAI、Anthropic等）使用预设标识
• 通过API终点的域名特征进行自动推断
• 保留手动覆盖选项

该优化虽然看似是界面微调，但对提升多模型工作流效率具有重要意义，是增强专业用户黏性的有效手段。