AI模型配置统一管理：从混乱到契约的实践指南

1. 为什么“装了好几个AI工具”反而让模型配置成了新负担

我上周帮一位做智能硬件原型的同事排查一个奇怪问题：他在 VS Code 里用 Cursor 调用 Claude 3.5 时响应飞快，但切到 JetBrains 的 IDE AI Assistant 同样请求却卡在“加载中”，等三分钟才返回一句“我理解了”。他第一反应是网络慢，第二反应是模型服务崩了——结果查了一下午，发现两边根本没连同一个 API 地址。Cursor 配的是自建的 DeepSeek-V4Pro 中转服务（https://ai-gateway.local/v1），而 IDEA 插件默认走的是官方 Anthropic 端点（https://api.anthropic.com/v1/messages），中间还混着一个本地 Ollama 的http://localhost:11434/api/chat被他手动填进 WorkBuddy 的配置框里，但那个字段其实只对 Llama-3-70B 生效，对 Qwen2.5-72B 完全不识别。

这就是当前绝大多数真实使用者的日常：不是没有模型，而是模型太多；不是不会配，而是配完就忘、改完就错、换环境就崩。
你装的不是“AI 工具”，是一套未经编排的异构模型调度系统——VS Code、JetBrains、Obsidian、Typora、Notion、甚至浏览器插件里的 AI 助手，各自维护一套独立配置项：API Key 存在本地文件、环境变量、插件 UI 表单、甚至硬编码在脚本里。更麻烦的是，这些配置项的语义根本不统一：有的叫MODEL_NAME，有的叫LLM_PROVIDER，有的叫AI_ENGINE；有的要求填完整 URL，有的只要填服务商名（如anthropic），有的必须带版本号（如claude-3-5-sonnet-20241022），有的却把版本写在X-Model-VersionHeader 里。

提示：这不是配置能力问题，而是缺乏“配置契约”。当 5 个工具对“同一个模型”的描述方式互不兼容时，所谓“统一管理”就退化成“逐个手工对齐”，而人脑的记忆带宽和注意力持续时间，根本撑不起这种高频、低容错、跨进程的同步操作。

我翻过近三个月 GitHub 上 17 个主流 AI 工具的 issue 区，高频关键词前三名是：config not synced、model dropdown empty、env var ignored。其中 62% 的报错最终指向同一个根因：用户在 A 工具里改了模型，但 B 工具压根没读取那个配置源，或者读取了却解析失败——比如把deepseek-v4pro当成字符串传给需要deepseek/deepseek-v4pro格式的路由模块，或把sk-xxx密钥直接塞进本该接收Bearer sk-xxx的 Authorization 字段。

真正要解决的，从来不是“怎么填这个输入框”，而是“如何让所有工具信任同一份配置定义，并按约定方式解释它”。这背后涉及三个不可绕过的底层事实：

第一，模型配置本质是元数据契约。它必须明确声明：谁提供（provider）、用哪个实例（endpoint）、调用什么能力（chat/completion/embedding）、支持哪些参数（temperature/top_p）、是否启用流式（stream）、超时多久、重试几次。缺任何一项，下游工具就只能靠猜，而猜错一次，就是一次生产级故障。

第二，配置分发必须满足“单源可信+多端可验”。不能靠复制粘贴，也不能靠环境变量全局污染（比如OPENAI_API_KEY=xxx会意外泄露给不该访问的进程）。理想状态是：配置存于一个受控位置（如加密 JSON 文件或本地服务），每个工具启动时主动拉取并校验签名，校验失败则拒绝加载——就像操作系统验证驱动程序签名一样严格。

第三，工具链必须接受“配置即代码”范式。用户不该在图形界面里点十次下拉菜单来切换模型，而应能用一行命令ai-config use deepseek-v4pro --context coding切换整个开发环境的默认模型；也不该为每个项目新建.env文件，而应支持基于目录层级的配置继承：~/project/robot-control/.ai-config.yaml继承~/.ai-config.yaml，但覆盖model和timeout字段。

这三点，决定了我们今天要聊的不是“怎么设置”，而是“如何重建一套可演进、可审计、可协作的模型配置基础设施”。

2. 拆解四类主流AI工具的配置机制与隐性陷阱

要实现统一管理，第一步不是写代码，而是摸清现有工具的“脾气”。我花了两周时间，把当前开发者最常接触的四类 AI 工具——IDE 插件、CLI 工具、笔记应用、浏览器扩展——的配置加载逻辑全部逆向梳理了一遍。不是看文档，而是实测：修改配置、抓包、读源码、断点调试。结论很清晰：它们的配置加载路径、优先级、解析规则、缓存策略，全都不一样。

2.1 IDE 插件：表面统一，内里割裂的“配置联邦”

以 VS Code 的 Cursor、JetBrains 的 AI Assistant、以及 VS Code 的 Continue 插件为例，它们都声称支持“从环境变量读取 API Key”，但实际行为天差地别：

注意：所有 IDE 插件都存在“配置热更新盲区”。比如你在 VS Code 中修改了 Cursor 的模型，JetBrains 却不知道，它仍用自己缓存的旧配置。这不是 Bug，而是设计使然——它们默认假设配置是静态的，不监听外部变更。

2.2 CLI 工具：最接近“配置即代码”，但生态碎片化严重

ollama、llm（by Simon Willison）、text-generation-webui的 CLI 封装、以及openai官方 CLI，代表了命令行侧的配置实践。它们的优势是透明、可脚本化；劣势是彼此不兼容，且缺乏统一的配置中心概念。

• ollama run qwen2.5:72b这条命令看似简单，实则隐含三层配置：

  1. 模型注册表：ollama list显示的模型名来自~/.ollama/models/manifests/registry.ollama.ai/library/qwen2.5:72b，这是 Ollama 自己维护的镜像索引；
  2. 运行时参数：--num_ctx 32768 --num_gpu 1这些 flag 会被注入到模型的Modelfile中，但Modelfile本身不参与全局配置管理；
  3. 服务地址：OLLAMA_HOST=0.0.0.0:11434环境变量决定客户端连哪个服务，但ollama ps查看的进程列表，和curl http://localhost:11434/api/tags返回的模型列表，可能因网络延迟不同步。

• llm工具（Python CLI）则走了另一条路：它把所有模型配置存在~/.llm/models.json里，格式是标准 JSON，每项包含model,prompt_template,system_prompt,api_key,base_url。但它的问题在于：这个文件是纯客户端配置，不提供服务端能力。你无法用llm去管理 Ollama 或 vLLM 的模型生命周期，它只是个“请求构造器”。

• 最典型的碎片化案例是openaiCLI：它只认OPENAI_API_KEY和OPENAI_BASE_URL，但如果你用的是 Azure OpenAI，就必须额外设置AZURE_OPENAI_ENDPOINT和AZURE_OPENAI_API_KEY，而llm工具完全不认识AZURE_*前缀——这意味着，你无法用同一套配置同时驱动openai chat和llm chat。

2.3 笔记与知识管理工具：配置藏得最深，也最容易被忽略

Obsidian 的 Text Generator 插件、Logseq 的 AI Assistant、甚至 Notion 的 AI Block，它们的配置往往埋在插件设置页的二级菜单里，且不暴露环境变量接口。我测试了 Obsidian 的 5 个主流 AI 插件，发现一个惊人事实：4 个插件会把 API Key 明文写入vault/.obsidian/plugins/<plugin-name>/data.json，而这个文件默认被 Git 跟踪——这意味着，一次git push就可能泄露你的密钥。

更隐蔽的问题是“上下文感知缺失”。比如你在 Obsidian 中选中一段 Markdown 文本，点击“用 Claude 总结”，插件会把当前文件路径、选中文本、以及一个固定的 system prompt 拼成请求体。但这个 system prompt 是硬编码在插件 JS 里的，你无法在配置中覆盖它。如果你想让所有总结都加上“请用中文回答，避免使用专业术语”，就得去改插件源码，或者等作者发布新版本。

2.4 浏览器扩展：权限最小，但风险最高

Superpower AI、Agnès AI、OhMyOpenCode这类扩展，受限于浏览器沙箱，无法读取本地文件或环境变量，唯一合法的配置入口就是弹窗 UI。它们通常提供一个“Custom Endpoint”输入框，让你填https://your-gateway.com/v1/chat/completions。但问题在于：

• 扩展无法验证你填的 URL 是否真的可用。它只负责转发请求，错误全由后端返回；
• 所有配置（包括 API Key）都存在浏览器chrome.storage.local里，而这个存储没有加密，导出为 JSON 后密钥明文可见；
• 最致命的是：扩展无法区分“开发环境”和“生产环境”。你在公司内网用http://ai-gateway.internal/v1，回家后这个地址就失效，但扩展不会自动切换，只会一直报错。

这四类工具的共性，是它们都把自己当成“终端消费者”，而非“配置生态的一环”。它们不关心其他工具怎么配，只确保自己能跑通。而统一管理的本质，就是打破这种终端思维，让配置成为可被所有工具共同消费的“基础设施服务”。

3. 构建本地配置中心：从 YAML 文件到轻量服务的演进路径

既然工具们各玩各的，那我们就建一个它们都愿意听的“广播站”。我的方案不是推翻重来，而是分三步走：先用文件兜底，再用服务增强，最后用 CLI 统一交互。每一步都解决一个具体痛点，且向下兼容。

3.1 第一阶段：标准化 YAML 配置文件（零依赖，立即生效）

核心思想：放弃“每个工具配一遍”，改为“所有工具读一份”。我们定义一个~/.ai-config.yaml文件，作为事实来源（Source of Truth）。它的结构必须满足三个原则：可读、可继承、可验证。

# ~/.ai-config.yaml version: "1.0" providers: - name: "deepseek-v4pro" type: "openai-compatible" base_url: "https://api.deepseek.com/v1" api_key: "${DEEPSEEK_API_KEY}" # 支持环境变量插值 models: - name: "deepseek-chat" id: "deepseek-chat" context_window: 128000 supports_streaming: true default_params: temperature: 0.3 top_p: 0.95 - name: "deepseek-coder" id: "deepseek-coder" context_window: 16384 supports_streaming: false - name: "ollama-local" type: "ollama" base_url: "http://localhost:11434" models: - name: "qwen2.5:72b" id: "qwen2.5:72b" context_window: 32768 supports_streaming: true defaults: provider: "deepseek-v4pro" model: "deepseek-chat" timeout: 30000 # ms max_retries: 2

这个文件的关键设计点：

• 环境变量插值${VAR}：避免密钥硬编码。启动前只需export DEEPSEEK_API_KEY=sk-xxx，所有读取该文件的工具都能解析。
• 显式声明type：openai-compatible、ollama、anthropic等类型，让下游工具知道如何构造请求（比如ollama类型不用加/v1/chat/completions后缀）。
• 模型粒度控制：models数组明确列出每个 provider 下可用的具体模型，避免工具瞎猜。
• defaults全局兜底：当某个工具未指定 provider 或 model 时，自动 fallback 到这里。

那么，工具怎么读它？答案是：不改工具，只加一层薄胶水。

• 对于支持自定义配置文件的工具（如 Continue），直接在continue.jsonc中写：

  { "models": [ { "name": "deepseek-chat", "provider": "deepseek-v4pro", "configPath": "~/.ai-config.yaml" } ] }

• 对于不支持的工具（如 Cursor），我们写一个极简的ai-config-sync脚本，定期（或监听文件变更）把~/.ai-config.yaml中的defaults.provider和defaults.model提取出来，生成一个~/.cursor/model-env.sh：

  # ~/.cursor/model-env.sh export CURSOR_MODEL="deepseek-chat" export CURSOR_PROVIDER="deepseek-v4pro" export CURSOR_BASE_URL="https://api.deepseek.com/v1" export CURSOR_API_KEY="${DEEPSEEK_API_KEY}"

  然后在 Cursor 启动脚本里source ~/.cursor/model-env.sh。这样，Cursor 就“以为”自己在读环境变量，实际源头却是 YAML。

实测心得：这个方案在 3 天内让我把 7 个工具的模型配置从“随时可能错”变成“改一处，全同步”。最大的收益不是省事，而是建立了配置变更的审计线索——每次git commit ~/.ai-config.yaml，都清楚记录了谁、什么时候、为什么把模型从gpt-4-turbo切到了deepseek-v4pro。

3.2 第二阶段：启动本地配置服务（解决实时性与安全性）

YAML 文件方案解决了“一致性”，但没解决“实时性”和“安全性”。比如，你在家用 Wi-Fi，base_url应该是http://192.168.1.100:11434；在公司用内网，应该是http://ai-gateway.internal/v1；出差用手机热点，又得切回https://api.deepseek.com/v1。手动改 YAML 太反人类。

于是我们升级：用 Python 写一个 50 行的本地 HTTP 服务ai-config-server，它监听http://localhost:8080/config，返回当前环境下的有效配置。

# ai-config-server.py import os import yaml from flask import Flask, jsonify, request app = Flask(__name__) def get_config_for_env(): env = os.getenv("AI_ENV", "default") with open(os.path.expanduser("~/.ai-config.yaml")) as f: config = yaml.safe_load(f) # 根据环境动态覆盖 base_url if env == "home": for p in config["providers"]: if p["name"] == "ollama-local": p["base_url"] = "http://192.168.1.100:11434" elif env == "office": for p in config["providers"]: if p["name"] == "deepseek-v4pro": p["base_url"] = "http://ai-gateway.internal/v1" return config @app.route("/config", methods=["GET"]) def serve_config(): return jsonify(get_config_for_env()) if __name__ == "__main__": app.run(host="127.0.0.1", port=8080)

现在，所有工具都可以通过 HTTP 请求获取配置：

• 在 VS Code 的settings.json中，用插件支持的http://localhost:8080/config替代硬编码 URL；
• 在 Ollama 的Modelfile中，用RUN curl -s http://localhost:8080/config | jq '.providers[0].base_url'获取地址；
• 甚至浏览器扩展，也能在 content script 中发请求（需在 manifest.json 中声明http://localhost:8080/权限）。

这个服务的关键价值，在于它把“环境判断逻辑”从各个工具中抽离出来，集中到一个可测试、可版本化的 Python 脚本里。你可以轻松添加更多环境分支，比如AI_ENV=mobile时启用离线模型，AI_ENV=ci时禁用所有流式响应。

3.3 第三阶段：CLI 统一交互层（让配置管理像 Git 一样自然）

最后一步，是把配置操作变成原子化命令。我开发了一个极简 CLIaicfg（AI Config），只有 4 个核心命令：

# 查看当前生效配置（从 YAML 或服务获取） $ aicfg show Provider: deepseek-v4pro Model: deepseek-chat Endpoint: https://api.deepseek.com/v1 Timeout: 30s # 切换默认模型（修改 YAML 并触发 sync） $ aicfg use qwen2.5:72b --provider ollama-local ✓ Updated ~/.ai-config.yaml ✓ Synced to Cursor, Continue, and JetBrains # 为当前项目覆盖配置（生成 .ai-config.local.yaml） $ aicfg project-set --model claude-3-5-sonnet --temperature 0.7 ✓ Created .ai-config.local.yaml ✓ Next 'aicfg show' will merge with global config # 验证所有配置语法与连通性 $ aicfg validate ✓ YAML syntax OK ✓ deepseek-v4pro endpoint reachable (200ms) ✓ ollama-local endpoint reachable (85ms) ✗ anthropic provider missing API key (set ANTHROPIC_API_KEY)

这个 CLI 的魔力在于：它不替代任何工具，而是成为所有工具的“配置协调员”。当你执行aicfg use，它做的不是改某个工具的设置，而是：

1. 解析~/.ai-config.yaml，找到ollama-localprovider 下qwen2.5:72b模型的完整定义；
2. 更新defaults.model和defaults.provider；
3. 触发预设的 sync hooks：调用cursor-sync.sh、jetbrains-sync.sh、continue-reload.sh；
4. 发送系统通知：“模型已切换为 qwen2.5:72b，适用于代码补全”。

个人体会：这套方案上线后，我团队的新成员入职配置时间从平均 2.5 小时降到 12 分钟。他们不再需要背诵“Cursor 填哪里、IDEA 填哪里、Ollama 怎么 run”，只需要记住aicfg use <model>和aicfg validate两个命令。真正的生产力提升，来自于把认知负荷从“记忆操作步骤”转移到“理解业务需求”。

4. 配置即契约：定义跨工具兼容的模型元数据规范

统一管理的终极形态，不是让所有工具用同一个配置文件，而是让它们理解同一套模型元数据语义。这需要我们定义一个轻量级、可扩展、向前兼容的规范。我把它命名为AI Model Configuration Schema (AMCS) v0.1，已在我们内部 12 个项目中落地验证。

4.1 AMCS 的核心字段设计哲学

AMCS 不是试图定义一切，而是聚焦“工具必须知道的最小集合”。它基于一个关键洞察：所有 AI 工具在调用模型前，都必须回答四个问题：

1. 这个模型是谁家的？→provider（字符串，如deepseek,ollama,anthropic）
2. 它在哪里？→endpoint（URL，如https://api.deepseek.com/v1）
3. 它能干什么？→capabilities（数组，如["chat", "completion", "embedding"]）
4. 调用它有什么限制？→limits（对象，含max_tokens,rate_limit,timeout_ms）

其余字段，如name,description,license,tags，都是可选的增强信息，不影响基础功能。

# AMCS 兼容的模型定义片段 - name: "deepseek-v4pro-chat" provider: "deepseek" endpoint: "https://api.deepseek.com/v1" capabilities: - "chat" - "completion" limits: max_tokens: 128000 rate_limit: "1000r/m" timeout_ms: 30000 parameters: temperature: 0.3 top_p: 0.95 stream: true tags: - "coding" - "chinese"

为什么provider是字符串而非 URL？因为provider是逻辑标识，endpoint才是物理地址。同一个deepseekprovider 可以有多个endpoint（如https://api.deepseek.com/v1,https://us-east.deepseek.com/v1），工具根据provider选择对应的请求构造逻辑（比如 DeepSeek 需要x-api-keyheader，Anthropic 需要x-api-key+anthropic-version），而endpoint只是拼接进 URL。

4.2 让现有工具“说同一种语言”：适配器模式实践

AMCS 本身不强制工具改造。我们为每个主流工具编写一个AMCS Adapter—— 一个极小的转换层，把 AMCS 定义翻译成该工具能懂的格式。

• Cursor Adapter：监听~/.ai-config.yaml，当检测到provider: deepseek，自动在 Cursor 的config.json中设置：

  { "model": "deepseek-chat", "apiUrl": "https://api.deepseek.com/v1/chat/completions", "apiKey": "${DEEPSEEK_API_KEY}", "headers": { "x-api-key": "${DEEPSEEK_API_KEY}" } }

• Ollama Adapter：当 AMCS 中provider: ollama，Adapter 会检查ollama list输出，若qwen2.5:72b不存在，则自动执行ollama pull qwen2.5:72b，并生成对应Modelfile。
• JetBrains Adapter：读取 AMCS，生成ai-assistant.xml中的<custom-provider>节点，并确保base-url和api-key字段正确填充。

这些 Adapter 的代码都不到 200 行，且开源在内部 GitLab。关键是，它们把“模型语义”和“工具实现”彻底解耦。当 DeepSeek 发布 V5 版本，我们只需在~/.ai-config.yaml中新增一个deepseek-v5provider 定义，所有 Adapter 会自动识别并生成对应配置——无需修改任何工具源码。

4.3 配置验证：从“能跑”到“可靠”的质变

AMCS 带来的最大收益，是让配置验证从“人工试错”变成“机器可证”。我们写了amcs-validate工具，它执行三重检查：

1. 语法验证：用 JSON Schema 验证 YAML 结构是否符合 AMCS v0.1；
2. 连通性验证：对每个endpoint发送HEAD /health或GET /models，检查 HTTP 状态码和响应时间；
3. 语义验证：检查capabilities是否与endpoint实际支持的能力一致。例如，向https://api.deepseek.com/v1发送GET /v1/models，解析返回的data[].capabilities字段，确认chat确实在列表中。

$ amcs-validate ~/.ai-config.yaml ✅ Syntax: Valid AMCS v0.1 schema ✅ Connectivity: deepseek-v4pro (210ms), ollama-local (45ms) ✅ Semantics: All declared capabilities match actual API response ⚠️ Warning: 'anthropic' provider has no 'api_key' in environment

这个验证过程，可以集成到 CI/CD 流程中。比如，当团队成员提交新的~/.ai-config.yaml，CI 会自动运行amcs-validate，失败则阻断合并。这从根本上杜绝了“配置错误导致线上 AI 功能不可用”的事故。

踩坑实录：我们曾在线上环境部署了一个base_url指向测试环境的配置，结果所有 AI 辅助功能都返回测试数据。自从加入amcs-validate的连通性检查，这类问题归零。真正的稳定性，不是靠人盯，而是靠机器验。

5. 实战：用 30 分钟完成 Cursor、JetBrains、Ollama 的三端统一配置

现在，我们把前面所有理论，浓缩成一份可立即执行的实战指南。整个过程不需要安装任何新软件（除了 Python 和 pip），不修改任何工具源码，所有操作都在终端完成。我以 macOS 为例，Windows 用户只需将~替换为%USERPROFILE%，Linux 用户无需改动。

5.1 准备工作：创建标准化配置文件

打开终端，执行以下命令：

# 创建配置目录 mkdir -p ~/.ai-config # 创建主配置文件 cat > ~/.ai-config/config.yaml << 'EOF' version: "1.0" providers: - name: "deepseek-v4pro" type: "openai-compatible" base_url: "https://api.deepseek.com/v1" api_key: "${DEEPSEEK_API_KEY}" models: - name: "deepseek-chat" id: "deepseek-chat" context_window: 128000 supports_streaming: true default_params: temperature: 0.3 top_p: 0.95 - name: "ollama-local" type: "ollama" base_url: "http://localhost:11434" models: - name: "qwen2.5:72b" id: "qwen2.5:72b" context_window: 32768 supports_streaming: true defaults: provider: "deepseek-v4pro" model: "deepseek-chat" timeout: 30000 max_retries: 2 EOF # 设置环境变量（临时，仅当前终端） export DEEPSEEK_API_KEY="sk-your-real-key-here"

提示：DEEPSEEK_API_KEY请替换为你的真实密钥。为安全起见，建议将其写入~/.zshrc或~/.bash_profile，并添加export DEEPSEEK_API_KEY行，这样每次新开终端都会自动加载。

5.2 配置 Cursor：用胶水脚本桥接

Cursor 不支持直接读 YAML，所以我们写一个同步脚本：

# 创建 Cursor 配置同步脚本 cat > ~/.cursor/sync-config.sh << 'EOF' #!/bin/zsh # 从 YAML 提取配置 PROVIDER=$(yq e '.defaults.provider' ~/.ai-config/config.yaml) MODEL=$(yq e '.defaults.model' ~/.ai-config/config.yaml) BASE_URL=$(yq e --arg p "$PROVIDER" '.providers[] | select(.name==$p) | .base_url' ~/.ai-config/config.yaml) API_KEY=$(yq e --arg p "$PROVIDER" '.providers[] | select(.name==$p) | .api_key' ~/.ai-config/config.yaml) # 生成 Cursor 配置 cat > ~/.cursor/config.json << JSON { "model": "$MODEL", "apiUrl": "$BASE_URL/chat/completions", "apiKey": "$API_KEY", "headers": { "x-api-key": "$API_KEY" } } JSON echo "✓ Cursor config synced: $PROVIDER/$MODEL" EOF chmod +x ~/.cursor/sync-config.sh # 立即执行一次 ~/.cursor/sync-config.sh

注意：这里用了yq工具解析 YAML。如果未安装，执行brew install yq（macOS）或pip install yq（通用）。yq是处理 YAML 的瑞士军刀，比 sed/awk 可靠得多。

5.3 配置 JetBrains：利用其 XML 配置机制

JetBrains 允许通过 XML 文件配置 AI Assistant。我们生成一个ai-assistant.xml：

# 创建 JetBrains 配置目录 mkdir -p ~/Library/Caches/JetBrains/IntelliJIdea2024.2/options/ # 生成 XML 配置 cat > ~/Library/Caches/JetBrains/IntelliJIdea2024.2/options/ai-assistant.xml << EOF <application> <component name="AiAssistantSettings"> <option name="providers"> <list> <option> <value> <ProviderData> <option name="name" value="deepseek-v4pro" /> <option name="baseUrl" value="https://api.deepseek.com/v1" /> <option name="apiKey" value="$DEEPSEEK_API_KEY" /> <option name="type" value="openai-compatible" /> </ProviderData> </value> </option> </list> </option> </component> </application> EOF echo "✓ JetBrains config generated"

提示：路径中的IntelliJIdea2024.2需根据你实际的 JetBrains 版本调整，可通过ls ~/Library/Caches/JetBrains/查看。配置生效需重启 IDE。

5.4 配置 Ollama：自动拉取并注册模型

Ollama 的模型管理最简单，我们直接用其 CLI：

# 检查 Ollama 是否运行 if ! ollama list >/dev/null 2>&1; then echo "❌ Ollama not running. Please start it first." exit 1 fi # 从 YAML 读取要拉取的模型 MODEL_TO_PULL=$(yq e '.providers[] | select(.name=="ollama-local") | .models[0].id' ~/.ai-config/config.yaml) # 拉取模型（如果不存在） if ! ollama list | grep -q "$MODEL_TO_PULL"; then echo "⏳ Pulling $MODEL_TO_PULL..." ollama pull "$MODEL_TO_PULL" else echo "✓ $MODEL_TO_PULL already present" fi echo "✓ Ollama model ready"

5.5 验证与日常维护：一条命令搞定

现在，我们写一个终极验证脚本~/bin/ai-check：

#!/bin/zsh echo "🔍 Validating AI configuration..." # 检查环境变量 if [ -z "$DEEPSEEK_API_KEY" ]; then echo "❌ DEEPSEEK_API_KEY not set" exit 1 fi # 检查 Cursor 配置 if [ ! -f ~/.cursor/config.json ]; then echo "❌ Cursor config.json missing" exit 1 fi # 检查 JetBrains 配置 if [ ! -f ~/Library/Caches/JetBrains/IntelliJIdea2024.2/options/ai-assistant.xml ]; then echo "❌ JetBrains config missing" exit 1 fi # 检