围绕 DeepSeek API 的模型差异、参数配置、成本控制与教学场景落地，给出可执行的选型与调用策略。 DeepSeek API 以兼容 OpenAI 的接口和较少的模型名称降低了接入门槛，但模型选择并不是把模型名替换一下那么简单。deepseek-chat 与 deepseek-reasoner 在推理深度、延迟、参数支持和计费结构上差异明显，教学答疑、作业批改、代码辅导等场景对准确率和响应速度的要求也不同。下面从模型矩阵、调用参数、成本并发、教学提示词与安全四个方面展开，帮助开发者和 AI 指导老师建立稳定的选型与使用流程。
1. 模型矩阵与能力边界
DeepSeek API 当前最常用的是 deepseek-chat 和 deepseek-reasoner。deepseek-chat 对应非思考模式的通用模型，适合常规对话、摘要、分类、信息抽取、RAG 答案生成、代码补全和结构化输出。它支持 function calling、JSON output、FIM 等能力，响应延迟较低，适合高频交互。deepseek-reasoner 对应思考模式，会在返回 content 之前生成 reasoning_content，用于数学推导、复杂代码调试、多步规划、约束满足和需要严密分析的题目。它不擅长也不需要所有任务，若用 reasoner 处理简单分类，会带来额外延迟和 token 消耗。
模型选择应先判断任务是否依赖显式推理链。如果学生问“什么是梯度下降”，chat 模型配合清晰提示词即可；如果学生提交一段报错代码，要求定位并发死锁并给出修复方案，reasoner 更合适。还需要看参数兼容性：deepseek-chat 支持 temperature、top_p、frequency_penalty、presence_penalty、response_format、tools 等；deepseek-reasoner 对采样参数支持有限，通常不支持 function calling 和 JSON output，设置 temperature 等可能不生效。因此在需要工具调用的教学系统里，chat 承担路由、检索、格式化，reasoner 承担难题分析，形成双模型流水线。
能力边界还包括上下文与输出。两者通常提供 64K 上下文，但长上下文不等于无限记忆。超过一定长度后，关键信息容易被稀释，成本和延迟也上升。教学场景中的课程大纲、错题记录、学生画像可以压缩成结构化摘要，而不是每轮全量传入。对于需要展示解题过程的任务，reasoner 的 reasoning_content 可作为教师端参考，但不建议直接暴露给低龄学生，以免思路跳跃造成理解负担。选型时应建立小规模评测集，用准确率、延迟、成本三项指标做对比，而不是凭感觉选择。
2. 调用参数与上下文管理
DeepSeek API 兼容 OpenAI 的 chat completions 接口，base_url 可设为 ，也可使用 /v1 路径保持 SDK 兼容。请求体中的 model 填 deepseek-chat 或 deepseek-reasoner，messages 按 system、user、assistant 组织。对 chat 模型，temperature 控制随机性，代码、数学、数据抽取建议 0 到 0.3，创意写作可到 1.0 以上；max_tokens 限制输出长度，默认通常为 4096，最大约 8192，设置过小会导致答案截断。stream 参数用于流式输出，教学问答前端应优先开启，以降低首字等待感。response_format 可要求 json_object，便于把批改结果写入数据库。
上下文管理是稳定性的关键。多轮对话不要无限追加历史，可以保留 system 指令、最近若干轮对话和一份滚动摘要。RAG 场景中，先检索再拼接文档片段，片段要带来源编号，并要求模型只依据给定材料回答。DeepSeek 的上下文缓存对相同前缀有优化，固定 system prompt、固定格式说明、把课程资料放在消息前面，能提高缓存命中率并降低输入计费。若每轮都把变化内容放在最前面，缓存命中会变差。对长文档，采用分段摘要再汇总的两阶段流程，比一次性塞入 64K 更稳定。
错误处理同样属于参数管理。API 可能返回 429 限流、500 服务错误或超时，生产环境应设置指数退避重试、请求超时和降级策略。流式响应要处理中断和拼接，非流式响应要校验 JSON 是否可解析。对 deepseek-reasoner，返回结构中包含 reasoning_content 和 content，前端只展示 content 时要在服务端过滤推理内容；若需要记录分析过程，应单独存储并做脱敏。消息角色要严格一致，工具调用结果需以 tool 角色回传，避免把函数结果混进用户文本导致模型误判。把这些参数和流程模板化，才能让教学应用在不同班级、不同学科中复用。
3. 成本、性能与并发策略
DeepSeek API 按输入和输出 token 计费，缓存命中的输入价格通常远低于未命中，输出 token 单价又高于输入。这意味着省钱的重点不只是换便宜模型，还包括压缩输入、控制输出和提升缓存命中。deepseek-chat 适合大批量简单任务，deepseek-reasoner 适合少量高难度任务，两者混用往往比全部用 reasoner 更经济。以 AI 指导老师场景为例，每天数万次“知识点解释”“错因归类”可以交给 chat；只有编程竞赛题、复杂物理推导、长篇作文深度点评才调用 reasoner。若把简单问答也交给 reasoner，延迟和账单都会明显上升。
性能指标要看首 token 延迟、总延迟、吞吐和错误率。chat 模型通常首 token 更快，适合实时聊天；reasoner 需要先生成推理内容，首 token 延迟更高，适合异步批改或带进度提示的界面。并发策略上，账户会有 RPM 和 TPM 限制，具体额度随账户等级和官方政策变化。生产系统应使用队列削峰，把批处理任务放在低峰期，实时请求设置优先级。遇到限流时，先重试再降级，例如 reasoner 超时后改用 chat 加“请分步骤但简洁回答”的提示词。对成本敏感的应用，可以记录每次请求的模型、输入输出 token、缓存命中量和耗时，按天聚合，找出异常调用。
A/B 测试是选型闭环的一部分。准备 100 到 300 条真实教学问题，覆盖概念解释、计算题、代码调试、作文批改、敏感内容拒绝等类型，分别用 chat 和 reasoner 跑同一套提示词，人工或自动评分。若 chat 在简单题上准确率接近 reasoner，就无需升级；若 reasoner 在复杂题上显著更好，再按路由规则调用。还可以对同一问题比较不同 max_tokens、temperature 和上下文策略，找到质量与成本的平衡点。对于高并发教学平台，建议把模型调用封装成内部网关，统一鉴权、限流、重试、缓存和审计，避免各业务线直接散调 API 导致成本失控。
4. 教学场景的提示词与安全落地
AI 指导老师的提示词应包含角色、教学目标、约束、输入材料、输出格式和示例。对 chat 模型，可以要求返回 JSON，字段包括知识点、错误类型、建议练习、参考答案，便于学习系统自动归档。对 reasoner 模型，提示词应聚焦问题本身，要求它先分析条件、再给出步骤、最后给结论，但不要强求 JSON，因为其结构化输出支持有限。常见做法是让 reasoner 产出详细分析，再让 chat 把分析改写成学生能看懂的反馈和 JSON。函数调用可用于查询课程表、题库、成绩和日历，chat 模型承担工具路由，reasoner 只在需要深度推理时介入。
RAG 是教学场景的重要支撑。把教材、讲义、错题本切块并建立向量索引，用户提问后先检索相关片段，再让模型基于片段回答，并要求引用来源。这样可以减少幻觉，也方便教师核查。提示词中要明确“若材料中没有答案，请说明无法确定，不要编造”。对于数学和编程题，可以要求模型给出可验证的中间步骤，但最终答案仍需教师或自动测试校验。安全方面，要过滤个人隐私、考试作弊请求和不当内容，学生数据在传输和存储中应加密，日志脱敏。对未成年人场景，应避免直接展示 raw reasoning_content，必要时由教师端查看。
评估和迭代决定落地效果。建立覆盖不同学科、不同难度、不同题型的测试集，每次更换模型版本或提示词后重新跑分。关注三类指标：答案正确率、解释可读性、拒绝不当请求的准确率。对 reasoner 的输出，可以检查推理链是否出现循环、事实错误或过度自信；对 chat 的输出，可以检查格式稳定性和引用完整性。教学系统还应提供反馈入口，让学生标记“没看懂”“答案有误”，这些数据回流后用于优化检索和提示词。模型选择不是一次性决策，而是随着课程内容、用户规模和官方 API 更新持续调整的过程。
