向经过模式校验的模型目录添加AI提供商和模型

## 完成前运行仓库自带的校验器和构建命令 更改目录数据前，先检查仓库中记录的验证、构建和开发命令。使用受影响工作区对应的软件包专用命令，以及项目已经选定的运行时。 - 将目录更改视为完成前，先运行规范的配置验证器。 - 仅当任务需要构建时，才构建受影响的界面或软件包。 - 如果仓库没有专用测试框架，不要臆造测试命令；应使用仓库实际提供的验证与构建关卡。 - 除非任务明确要求，否则不要启动开发服务器。 在保留仓库要求的每个关卡的同时，使验证范围与改动的软件包相称。 ## 从模式推导TypeScript类型，不重复手写 将严格验证模式作为唯一依据。不要维护并行接口，而应从这些模式推导TypeScript类型；当现行模式采用严格模式时，拒绝未知字段。 - 遵循仓库既定的模块格式和本地导入扩展名规则。 - 必要时导出公共API契约的接口，但验证后数据的类型应从导出的模式常量推导，不要重复定义模式形状。 - 对值、函数、类型和模式使用规定的命名约定；有意不使用的值应采用仓库的下划线约定。 - 优先使用返回结构化错误的安全解析；如果错误契约支持，应保留根本原因。 - 在比较和排序中明确处理`undefined`；如果能保留预期语义，则使用可选链和空值合并运算符。 - 文件操作使用`async`/`await`和异步迭代；如果仓库以此为标准，还应使用运行时原生的glob、文件和写入API。 不要在手写类型中重复模式事实，也不要用未经检查的类型转换绕过结构化验证。 ## 在单体仓库中负责目录数据的包里修改 编辑前，先确定核心验证、用户界面和可部署函数分别归哪个工作区所有。将目录源文件保留在其规范目录中，并在使用它们的软件包内进行更改。 - 保持核心生成、静态界面产物和已部署函数代码之间已声明的关系。 - 在各工作区软件包之间保持运行时和模块选择一致。 - 先验证受影响的软件包；只有当改动的契约跨越该边界时，才执行跨软件包构建。 - 不要仅为了简化一次贡献而转移配置的归属。 应按职责泛化架构决策，而不是依赖特定托管厂商、框架或目录名称。 ## 新提供商必须附带适配主题的标志，有可靠来源时添加同步模块 将必需的提供商资源视为合并阻断项。每个新提供商都必须在其自有目录中包含符合要求的矢量徽标。 - 使用可缩放的矢量格式，填充或描边采用能适应主题的`currentColor`，并优先使用正方形`viewBox`。 - 不要使用无法同时适应浅色和深色主题的固定尺寸或硬编码颜色。 - 当权威API或目录能够填充必需数据，或者能够可靠识别其已不再提供的条目时，添加同步模块。 - 如果信息单薄或不完整的来源无法填充必需字段，也无法作为权威依据判断应停止提供哪些条目，则保持手工维护。 当来源足够完整时，同步模块是一项强烈建议；没有权威来源时，它不是阻断项。绝不能根据无法证明目录完整性的来源，自动停止提供条目。 ## 从基础模型继承共享信息，不复制 如果存在规范的模型元数据条目，提供商专用记录必须通过仓库的基础引用机制，从中继承与提供商无关的事实。不要在记录内重复写入共享事实。 - 仅当不存在匹配的规范元数据条目时，才使用完整的内联定义。 - 要求每个`base_model`引用都能解析到真实存在的元数据文件。 - 价格、提供商标识、实验状态、推理控制、交错行为和生命周期状态等提供商专用值，应在需要时保留在提供商记录中。 - 确保解析后的结果包含合并后的事实，但不包含只用于生成过程的`base_model`或`base_model_omit`指令。 继承应减少重复，但不能隐藏确实因提供商而异的值。 ## 只按提供商API实际提供的方式声明推理设置 任何标记为推理模型的记录，都必须声明反映提供商实际API能力面的`reasoning_options`。 - 使用模式要求的精确选项类型表示已验证的开关、预算或其他控制。 - 如果提供商使用特殊的请求形状，应在附近的TOML注释中写明准确的API请求语法。 - 记录预算控制中经过验证的最小值和最大值；不要根据其他提供商推测限制。 - 如果模型能够推理，却没有向用户提供任何已验证的控制方式，则使用`reasoning_options = []`。 不要仅因模型支持推理就臆造开关。目录必须区分推理能力与可控制的推理行为。 ## 继承模型数据时深度合并对象、整体替换数组 严格按照仓库的解析契约实现元数据继承。 - 对上限和模态等普通对象进行深度合并。 - 数组和原始值由子项的值整体替换。 - 子项省略的任何提供商字段都应继承。 - 合并后再应用`base_model_omit`，忽略不存在的路径，并清理因此变为空的祖先对象。 - 如果引用的基础元数据文件不存在，则验证失败。 为数组替换、对象深度合并、省略路径和空对象清理添加聚焦的测试覆盖。绝不能假设对象、数组和原始值采用相同的合并方式。 ## 从文件名取模型ID，并按核实过的地区价格记录 如果仓库契约规定从文件名推导标识符，就必须这样做；绝不能在数据文件中重复写入自动注入的标识符。保留提供商特有的命名语法，包括带日期的后缀、最新别名、区域前缀、版本标签和分隔符。 使用现行严格模式，区分必需的可读元数据、必需的能力布尔值、必需的成本/上限/模态对象，以及可选的系列、知识、温度、结构化结果或生命周期字段。拒绝多余字段，不要默默接受。 当上下文超过200K时，使用模式中的嵌套成本对象表示阈值价格。不要假设常见的缓存读写比例10%/125%也适用于明确记录为30%/375%的区域变体；应编码已验证的提供商和区域行为。 ## 把来源引用放在同步后不会丢失的位置 更改数据的贡献应引用权威定价页面、模型文档或API参考。缺少引用不会自动构成阻断项，但需要更严格的审查和独立验证。 如果同步流程会解析并重新序列化目录文件，应将来源引用和理由放在首个键之前的文件头注释块中。如果同步流程会丢弃其他注释，就不要把需要长期保留的注释放在区段之间或单个键的上方。 将注释位置视为持久性约束，而不是外观偏好。确认下一次同步运行仍会保留以后审查数据所需的每个来源。 ## 审查目录变更时区分阻断问题与建议 审查时应区分硬性阻断项与建议。缺少必需资源、基础引用无效、缺少必需的推理控制、违反模式或验证失败时，必须阻止接受；建议添加的同步模块或来源引用，应根据文档中规定的强度判断。 完成前： - 运行规范的目录验证器； - 仅在需要时构建受影响的软件包； - 确认必需资源、继承、推理控制、命名、价格和生命周期字段； - 验证引用能在同步后保留； - 检查最终差异中是否有无关或重复数据。 报告运行了哪些检查、哪些检查被有意排除在范围之外，以及仍未解决的建议。不要把建议说成阻断项，也不要把阻断项弱化为建议。