今天闲来无事（x），正好折腾一下，虽然明天有的忙了。
首先来个图：
几个小时前 我写了这个【木子狸的指北指南】01 Octopus 的部署与使用 和这个【木子狸的指北指南】02 CLIProxyAPI
然后又看到了 AmpCode 食用指南：搭配 CLIProxyAPI 实现自定义模型自由 这个帖子。突然就想折腾了。
在配置 CLI Proxy API 连接到 AmpCode 的时候，我发现，模型的映射要么就是要改 Yaml 文件，要么就还得输入完整的模型名称进行对应。
那么是否有一种好一点的方法只配置一次，然后可以进行快速动态的修改呢？
由于 Octopus 的模型可以自定义分组，同时这个分组还可以通过正则表达式进行快速筛选。我们只需添加各家的模型提供商到 Octopus 然后再通过自动的正则表达式进行分组。
我们可以得到 三个不同的分组
- Opus4.5 我称为高级模型
- Sonnet4.5 我称为中级模型
- GPT5.2 我称为普通模型
这里只是简单分以下类，有时候GPT的效果比Opus好 不能一概而论
其实我这里不应该按照模型名字进行映射。而是应该按照能力。
- high
- medium
- low
这样进行匹配，当新出了一个模型后，我们就可以依照模型的能力，在 Octopus 里面使用正则表达式进行聚合，同时也降低了单独的API提供商失效的风险。
工程实践中的依赖倒置原则
我们要明确的是，高层模块——我们的AI CLI/AI客户端，不应该依赖低层模块的具体实现(这里是AI的名称名称)，我们应该依赖抽象分级。
在这里我就想说，你们那些模型厂商，模型的命名都是什么鬼东西 
这种解耦方式，可以让我们隔离具体细节带来的影响。
然后 从 Octopus 还可以专门分出一个用于聊天的服务 API，然后一个 API key 就可以获取到所有的模型了。
通过添加和引入中间层，我们减少了用户使用AI时的模型切换，负载均衡还有故障转移的复杂度。
这样使用 Octopus 进行聚合时，所有的模型用量都会聚合到此处，也可以更好的看到个人的使用数据。
这也是我在 【木子狸的Vibe Coding随笔】01 从《人月神话》谈起 提到的透明度。
还有一个好处就是，所有的服务都在我的 VPS 上，即使电脑出现问题，我们也只需要配置最简单的部分，比如仅仅填个key啥的。
再来扯一下 Vibe Coding
也就是说在 Vibe Coding 的时候，我们可以摒弃硬编码，通过命令 AI 使用正则表达式或者你设计的一组规则，来形成一套松耦合和高可用的代码。
要知道唯一不变的就是变化本身。模型厂商的名字会变、API会变、价格会变，但“能力分级”这个抽象相对稳定。在开发有关于 AI 的软件时，架构需要能应对未来。
毕竟谁能想到 openai 的命名 从很好的 GPT2 GPT3 到了现在一堆稀烂的命名呢。
如果有更好的想法可以聊一下，而且 CLIProxyAPI 的好处也不止如此。我也才刚玩没一下。