一：模型¶
概述¶
本节介绍 OSH 实验相关场景中常用的大语言模型，包括其特点与适用情境。
1.1 统一接入：OpenRouter 作为“模型路由层”¶
课程实践中建议把 OpenRouter 当成统一模型入口：同一套 API/Key 管理多家模型、按任务切换能力层级、便于控制成本与复现配置（记录使用的模型/版本/上下文长度/价格档位等）。
- 官网：https://openrouter.ai/
- Quickstart：https://openrouter.ai/docs/quickstart
- API Reference：https://openrouter.ai/docs/api/reference/overview
- Models 指南：https://openrouter.ai/docs/guides/overview/models
1.2 分层选型：按任务挑模型，而不是“一个模型跑到底”¶
建议把 OSH 实验里的 AI 工作分成三类，并绑定不同的模型能力偏好（示例中提到的 MiniMax M2.5 在 OpenRouter 上可查到上下文长度等信息，适合用作“长上下文阅读层”的例子）：
| 任务类型 | 典型输出 | 需要的能力 | 推荐模型特征（而非品牌） |
|---|---|---|---|
| 阅读 / 总结 / 设计 | 设计方案、模块说明、风险清单 | 长上下文、稳定摘要、结构化输出 | 长上下文（例如 196k 级别的MiniMax M2.5） |
| 写代码 / 改内核 / 写 patch | 可审阅的 diff、可运行的测试 | 强工程能力、强代码习惯、可执行修改 | SWE bench 强/代码生成强，对 C/Rust/Kernel 生态友好 |
| 解释 / 证明 / 推导 | 可验证结论、反例、边界条件 | 强推理、严谨性、可检查性 | Reasoning 偏强，要求给出可验证结论与依据 |
1.3 课程建议：把“可复现配置”当作提交的一部分¶
为便于助教复现与同学互相审阅，建议在实验记录中至少包含：
- 模型信息：模型名（含提供方/路由层标识）、版本/日期（若可得）
- 任务分层：本次任务属于阅读/实现/证明哪一类
- 关键提示词/约束：例如“只能输出 patch 代码”, “必须给出测试计划”, “必须附 trace 证据”等
（具体流程与合规要求见 规范 一节中 的 PIP 三段式与“允许但需可审计”。）
1.4 主流模型¶
本节不固定绑定某一家模型清单（模型更迭快），而是建议同学优先用 OpenRouter 的模型页信息做选择与记录：发布时间、上下文长度、价格、基准，以及在你任务上的实际效果（是否能生成可编译 patch、是否能把测试跑通、是否能给出可复现证据链）。