模型目录通常会从一个简单表格开始：名称、上下文长度、价格、支持能力。这个阶段的问题不大，因为模型数量有限，用户还能手动比较。
但当目录里开始出现几十上百个模型后，表格就会迅速失效。用户看到的信息更多了，决策却更慢。
这类失效并不是因为表格形式天然不好，而是因为模型选择这件事本身已经变复杂了。过去用户面对的是“哪个模型更强”，现在面对的是“哪个模型在当前预算、延迟、模态能力、稳定性和接入限制下更适合这项工作”。当决策变量变多，目录页就不能继续停留在资料展示层。
我们先回答一个问题：用户来目录页到底是为了什么
在 Cloubic 里，模型目录不是资料库，而是决策入口。用户通常带着明确目的来：
- 找到某个任务最合适的模型。
- 对比不同供应商下同类模型的差异。
- 确认某个模型是否支持文本、图像、音频或视频能力。
- 判断自己当前的调用场景，是否值得切换到另一个模型组合。
这意味着目录页的重点不该是“信息全”，而应该是“筛选快、判断快、切换快”。
目录设计的三个原则
1. 把高频决策信息前置
价格、模态、上下文、提供商和可用区域，是用户最常筛选的信息。这些信息必须直接出现在卡片或首屏表格中，而不是藏进详情页。
2. 不让命名系统成为认知负担
很多模型名字很长，而且不同供应商对同一模型的命名也不一致。如果目录只是原样展示，用户会被迫自己建立映射关系。
所以我们会做统一命名、别名归并和 provider 标签，让用户先理解能力，再理解来源。
3. 保留“立即行动”的出口
目录不是终点。用户一旦完成判断，应该可以快速复制模型 ID、查看接入方式，或者直接进入调用流程。
没有动作出口的目录，只是更漂亮的数据库视图。
信息架构必须先服务决策，再服务增长
很多 Catalog 产品失败，不是因为数据不够，而是因为信息架构把“存储视角”直接暴露给了用户。后端怎么建模，并不等于前端应该怎么呈现。一个真正面向决策的模型目录，至少要区分三层信息：
- 首屏判断信息：价格区间、模态能力、上下文、速度感知、稳定性标签。
- 比较信息：同家族模型差异、同能力模型差异、不同 provider 的封装差异。
- 深度信息：版本说明、兼容性、计费细节、调用限制、变更记录。
如果这三层混在一起，用户就会在大量细节中迷路。我们后来逐步把首屏内容压缩到“足够完成第一次判断”，把细节放进展开区、对比视图和独立说明页，这样用户决策明显更快。
Catalog 不只是列数据，还要提供判断框架
很多人认为模型目录的职责是“告诉用户有什么”。但在 AI 产品里，仅仅知道“有什么”远远不够，用户更需要的是“我该怎么选”。因此我们在目录里会刻意提供一些判断辅助，而不是假装完全中立。
这类辅助可以包括：
- 任务导向标签，例如“适合实时对话”“适合批量生成”“适合复杂分析”。
- 风险提示，例如“价格波动大”“区域可用性有限”“函数调用能力存在差异”。
- 推荐组合，例如为不同阶段团队给出默认起步方案。
- 对比入口，让用户围绕具体任务而不是围绕参数名展开比较。
这种设计并不是替用户做决定，而是减少他们建立判断框架的成本。目录页一旦能承担这部分工作，用户从浏览到接入的转化会明显更高。
新鲜度和可信度，比“参数全面”更重要
模型信息的另一个难点，是变化太快。价格调整、上下文更新、能力补齐、区域开放和弃用公告都可能在很短时间内发生。如果 Catalog 不能反映信息新鲜度，再完整的数据也会失去参考价值。
所以我们会格外关注两件事：一是信息来源是否可追溯，二是信息更新时间是否可见。对于用户来说，看到“最后更新时间”和“来自哪个 provider 或内部校验流程”，往往比多几个字段更能建立信任。因为目录做得再华丽，只要有几次信息失准，用户就会回到搜索引擎和文档站自己判断。
增长阶段要提前处理三类扩张问题
目录页上线后，最容易被忽略的一点是：它会随着模型数量持续膨胀。所以一开始就要考虑扩展性，而不是只做当前规模下最好看的一版。
我们在做这类页面时，会优先处理三类扩张问题：
- 筛选维度扩张。今天只有价格和模态，明天可能就要加区域、稳定性、函数调用、推理能力和计费模式。
- 展示密度扩张。桌面端能铺开很多信息，但移动端必须保持核心判断不丢失。
- 家族关系扩张。相同模型家族、相同能力层级、相同 provider 封装之间，需要有清晰的聚合关系。
如果目录一开始没有为这些扩张留接口，后面再补往往会越补越乱，最后只能重做。
目录要嵌进产品流程，而不是孤立存在
另一个常见误区，是把 Catalog 当作单独页面来设计。实际上，模型目录的价值只有在它能顺畅接进其他产品动作时才会被放大。比如：
- 在目录里直接复制模型 ID 或 SDK 参数。
- 从目录页跳到 Playground、调用面板或价格计算器。
- 在模型详情里看到最近调用表现或组织默认策略。
- 从错误日志和成本报表里反向跳回模型详情做判断。
当 Catalog 成为这些动作的中间节点，它就不再只是“看信息”的地方，而是整个开发体验的一部分。
我们最后总结出的运营原则
做久了之后，我们反而更清楚一件事：Catalog 不是一次性设计成果，而是一项持续运营的产品资产。真正需要维护的不只是页面，而是背后的分类方法、命名规范、推荐逻辑和数据同步机制。
因此我们会把目录运营看成一套长期纪律：
- 新模型进入前，先明确它服务的任务定位。
- 模型信息更新时，优先更新影响决策的关键字段。
- 页面设计迭代时，以缩短选择路径为第一目标。
- 推荐文案和标签体系保持克制，避免把目录做成营销页。
结语
模型目录做得好，本质上是在缩短用户从“知道模型存在”到“敢于用它”的距离。它不是一个参数仓库，而是一套帮助用户完成技术决策的界面系统。
这也是我们持续迭代 Catalog 的原因。它不是一个展示页面，而是整个平台开发体验的一部分。只有当目录真正服务于判断、接入和后续运营，模型数量的增长才不会反过来拖慢用户决策。