简介这份资料来自北京大学DeepSeek系列研讨讲座聚焦提示词工程与产业落地应用面向程序员、教师、科研人员、管理人员等希望通过自然语言交互提升工作质量的从业者无需专业技术背景即可掌握核心路径。内容从DeepSeek-R1的能力跃升切入梳理开源、低成本、国产化三大优势剖析模型推理可视化的价值并澄清常见提示词误读帮助读者建立正确使用框架。文档还系统给出三种直接使用方式、私有化部署方案以及提示词技巧覆盖官方API、第三方通道与本地部署并针对公文写作、教学设计、数据分析、编程开发、医疗保健等场景提供真实案例与操作演示便于不同领域用户按需借鉴。资源为单个PDF文件压缩包大小18.66MB适合离线阅读和反复查阅。目前已有311人学习适合希望将大模型思维真正融入日常工作与生活的专业人群。1. DeepSeek 提示词工程为什么值得单独拿出来讲推理模型的回答方式不一样把“北京大学-DeepSeek 提示词工程和产业应用”这个主题落到实践层面核心就一句话DeepSeek 的推理模型和普通聊天模型在提示词的写法上根本不是一回事。很多人拿着 ChatGPT 时代积累的提示词经验直接套到 DeepSeek 推理模型上结果发现模型“变笨了”——指令写得越细、步骤给得越多输出反而越不稳定。这篇内容围绕提示词工程和推理模型的产业应用展开适合正在做 API 接入、Agent 编排、私有化部署的工程师帮你看清推理模型的提示词该按什么逻辑写、参数怎么设、落地时坑在哪。2. 推理模型与聊天模型的提示词差异系统提示词、上下文工程与 few-shot 的不同用法2.1 为什么“一步步思考”对 DeepSeek 推理模型反而是负优化聊天模型比如 DeepSeek 的非推理版本、GPT-4o 这类没有内置的推理过程用户必须在提示词里显式给出思维链比如“请一步一步分析”“先列出约束条件再写代码”模型才会沿着这条路径组织回答。提示词工程里最经典的一招就是给步骤、要推理过程这在聊天模型上确实有效。但 DeepSeek 的推理模型deepseek-reasoner 这类在架构上就内置了隐藏思维链。模型在给出最终答案之前会自己完成一段内部的推理过程这段过程在 API 返回里对应 reasoning_content 字段。也就是说模型不需要你教它怎么思考它本来就会“思考”很长时间。这时候你再在提示词里写“请一步一步思考”会发生两件坏事提示词里的思维链指令会占掉上下文窗口和输出预算挤压模型真正用来做推理的空间。模型会把你的指令当作一种“思考风格”去模仿而不是当作任务要求。如果你给的步骤和它内部的推理方式不一致它反而会被带偏出现大量无意义的重复和过度分析。我做过一次对比测试同一道代码排查题一组提示词写“请逐步分析这段代码的问题”另一组只写“找出这段代码的问题并给出修复方案”。结果显示加了逐步分析指令的那组reasoning_content 明显变长但最终答案里的修复建议反而更保守、更不敢下结论。原因是模型把精力花在了“表演思考过程”上而不是解决任务本身。所以对 DeepSeek 推理模型第一步提示词改造就是把“教它怎么思考”这类指令全部删掉。你只需要告诉它任务目标、输入材料、输出约束剩下的推理过程让模型自己完成。2.2 推理模型提示词的三个原则给目标、给约束、少给步骤给推理模型写提示词我总结成三个原则给目标、给约束、少给步骤。这正好和聊天模型的提示词写法相反。给目标是指明确告诉模型“你要交付什么”。比如“把这段 Python 代码从 requests 迁移到 httpx 并保持异常处理逻辑一致”这是目标。不要写“先看导入语句然后看请求函数再对比异常处理……”这类过程性描述。目标写得越具体模型的推理越有方向感。给约束是指设定边界条件包括输出格式、禁止事项、信息不足时的处理方式。这个对推理模型特别重要因为它的推理链很长容易在中间引入假设。比如你可以写“只依据输入材料回答”“如果材料不足以判断直接说信息不足不要编造”“最终输出用 JSON 格式包含 conclusion 和 evidence 两个字段”。这些约束会把模型的长推理链关在一个安全范围内。少给步骤并不是完全不写步骤而是指不要给“思考步骤”。如果你需要模型按特定流程产出比如先出结论再出依据你可以在输出格式里定义顺序但不要把它写成“第一步思考什么、第二步对比什么”。推理模型对这类指令的理解方式和聊天模型不同它会把步骤当成任务约束之一而不是装配线。这里还有一个常见误用few-shot 示例。聊天模型时代给两三个完整的“问题-推理-答案”示例能明显提升效果。但推理模型本身就会推理你再给一堆带思维链的示例等于让它在多条推理路径之间选一条来模仿反而降低泛化性。我在实际项目里的做法是如果要给示例只给“输入→最终输出”的配对不给中间推理过程。这样既能让模型理解输出格式又不会干扰它内部的推理风格。2.3 系统提示词与上下文工程的分工系统提示词只定边界上下文里放证据现在很多团队已经开始区分“提示词工程”和“上下文工程”了。提示词工程管的是指令的组织方式上下文工程管的是把什么内容放进上下文、放多少。DeepSeek 推理模型对这两件事的敏感度都比聊天模型更高。系统提示词System Prompt的作用应该是“定边界”而不是“教做事”。我一般会在系统提示词里放三类内容角色定位你是谁、在什么业务场景下工作。输出约束格式、长度、禁止事项。兜底规则信息不足怎么处理、遇到越权问题怎么回应。不要往系统提示词里塞大量业务背景和参考案例。因为系统提示词里的内容会被模型当作最高优先级指令塞得越多对推理的干扰越大。上下文里放的是任务相关的证据材料。比如你在做一个工单分类系统系统提示词只写“你是工单分类助手只输出分类结果和置信度”上下文里放工单内容、历史相似工单、分类字典。这样模型在推理时注意力集中在证据上而不是被系统提示词里的长文本分散。上下文工程里最需要注意的一点是长上下文不等于更强的理解力。DeepSeek 推理模型在上下文特别长、内容特别杂的情况下反而会比短上下文表现差。原因是推理模型需要从大量信息中筛选关键证据上下文越长筛选成本越高误判概率越大。我见过一个典型翻车案例把完整的 30 页产品文档全部塞进上下文让推理模型做需求分析结果模型把文档里一条废弃的旧规则当成当前规则做出了完全错误的判断。后来改成先做文档切片、把相关章节抽出来再喂给模型效果立刻正常了。这里有一个判断标准如果任务需要的证据在上下文中占比超过 30%就属于“上下文过载”需要先做信息抽取把核心材料压缩到上下文里而不是无脑全塞。维度聊天模型推理模型思维链指令有效能提升推理质量无效甚至有害模型自带推理few-shot 示例给完整示例效果好只给输入-输出配对不要给推理过程系统提示词可以写得详细指导性强只定边界内容越少越好上下文长度容忍度高长上下文也能工作容忍度低需要做上下文工程输出格式约束重要但不敏感非常重要推理链长容易偏温度参数可调范围大不推荐调低靠提示词控制3. 用 DeepSeek API 落地推理模型最小调用、提示词模板与关键参数3.1 最小可用调用deepseek-reasoner 的请求与返回结构实际接入 DeepSeek 推理模型最常用的方式是通过 OpenAI 兼容接口调用 API。DeepSeek 官方的 API 端点提供了 deepseek-reasoner 这个模型名面向的就是推理模型。先看一个最小可用的 Python 调用from openai import OpenAI client OpenAI( api_keysk-your-api-key, # 替换为自己的 key base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: system, content: 你是一个代码审查助手只指出可能导致线上事故的问题。}, {role: user, content: 这段代码有什么问题\n\ndef fetch_user(url):\n resp requests.get(url, timeout5)\n return resp.json()\n} ], max_tokens8192, temperature0.6, streamFalse ) # 输出最终答案 print(resp.choices[0].message.content) # reasoning_content 是内部推理过程的摘要不要喂回后续请求 print(resp.choices[0].message.reasoning_content)这段代码的关键处理点有三个。第一个是 max_tokens这是一个特别容易踩的参数。推理模型的回答分两部分内部推理的 reasoning_content 和最终的 answer两部分都消耗输出 token。如果你把 max_tokens 设得太小比如 512推理链长一点就直接被截断最终答案可能完全没生成出来API 返回里只有 reasoning_content。我一般建议把 max_tokens 设到 8192 以上或者按业务需求估算最终答案的最大长度乘以 2给推理过程留出余量。第二个是 temperature。对聊天模型调低 temperature 可以让输出更确定但对推理模型不推荐把温度压得很低比如 0.2 以下。推理模型的思考过程本身需要一定的随机性来探索不同的推理路径温度过低会导致推理路径单一反而更容易在复杂任务上犯错。我一般保持默认或者设置在 0.6 左右想要更稳定的输出优先靠提示词约束而不是压温度。第三个是 reasoning_content 的处理。这个字段返回的是模型内部推理的内容可以用来做调试、追踪模型的思考过程但不要把 reasoning_content 作为后续请求的输入也不要把不同请求的 reasoning_content 拼接后重新喂给模型。它本质上是模型推理过程的副产品不是结构化的业务数据。3.2 提示词模板按“任务-输入-约束-输出格式”四段组织给推理模型写提示词我习惯固定用四段式模板任务、输入材料、约束、输出格式。用代码模板固化下来团队内所有人都按同一套结构写便于调试和复用。prompt_template 任务 {task} 输入材料 {context} 约束 1. 只依据输入材料回答不要引入材料中不存在的假设。 2. 如果材料不足以得出可靠结论直接回答“信息不足”。 3. 不要复述题目直接给出结果。 输出格式 - conclusion: 一句话结论 - evidence: 材料中支持结论的原文摘录 - next_actions: 建议的下一步操作最多三条 这个模板的每段都有明确作用。任务段描述要做什么输入材料段放证据约束段管边界输出格式段规定交付物的结构。推理模型拿到这个模板时会把主要推理精力放在“输入材料与任务之间的逻辑关系”上而不是猜测你要什么格式的输出。一个实践经验约束段里最好写“不要复述题目”或“不要重复输入材料”。推理模型的推理链太长时容易出现“先把问题复述一遍再开始推理”的现象浪费 token 不算还会让最终答案显得拖沓。加上这条约束能明显缩短无效输出。四段式模板还有一个好处是方便切换模型。当业务需求比较简单时把约束段和输出格式段稍微简化同样一个模板可以切到 deepseek-chat聊天模型上跑成本更低、首字延迟更低。做个简单判断任务如果是一次性抽取、格式转换、关键词匹配用聊天模型如果是代码排障、多材料综合分析、复杂决策、工具调用规划用推理模型。两种模型共用一个模板结构只是约束的严格程度不同这样切换成本很低。3.3 本地部署推理模型vLLM 命令与显存预算API 调用适合快速验证但很多企业内部要求数据不出内网或者要对推理链路做深度定制这时会考虑本地部署 DeepSeek 推理模型。常见做法是用 vLLM 跑蒸馏版模型比如 DeepSeek-R1-Distill-Qwen-7B在单张消费级显卡上就能跑起来。vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name my-deepseek-r1 \ --gpu-memory-utilization 0.92 \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --enable-prefix-caching这里几个参数值得解释一下。gpu-memory-utilization 控制显存占用比例。设到 0.92 意味着给模型权重和 KV Cache 留出 92% 的显存剩下 8% 留给操作系统和其他进程。如果你机器上还跑着别的服务建议降到 0.8 以下否则启动时可能直接 OOM。max-model-len 是最大上下文长度。这个参数直接决定显存压力因为它会影响 KV Cache 的预分配大小。8192 是 7B 蒸馏版比较稳妥的起步值能覆盖大部分业务场景。如果你硬要設到 32000单卡 24GB 会很吃紧首字延迟TTFT会明显上升因为 prefill 阶段的计算量变大了。enable-prefix-caching 对多轮对话和相似请求帮助很大。它会把重复的 prompt 前缀缓存起来第二次请求到来时跳过一部分 prefill 计算。在 Agent 场景里系统提示词通常是固定不变的这个参数能显著降低延迟。本地部署还有一个容易忽略的点推理模型的 TTFT 比聊天模型长得多。因为模型要先跑完一大段内部推理才会开始输出最终答案。API 调用时还能用流式输出缓解感知但本地部署时如果业务方对首字延迟有硬性要求比如网关超时设了 3 秒推理模型可能根本过不了关。我们在内网部署时实测过同样一段中等复杂度的代码分析聊天模型的首字延迟在 0.8 秒左右推理模型到了 4 到 6 秒。这种场景下要么调整业务上的超时阈值要么在前端做“正在分析中”的异步反馈不能把聊天模型时代的延迟预期直接套过来。在 Jetson Orin 这类边缘设备上部署 7B 级推理模型也可以跑但速度主要取决于内存带宽而不是算力。Orin 64GB 版本的内存带宽大约 200GB/s 级别跑 7B 量化模型的生成速度会在个位数 token/s 左右适合离线批处理如果要做实时交互体验会非常吃力。4. 产业落地的三种接入形态Agent 编排、工具调用与办公入口4.1 Agent 编排deepseek harness 思路多技能共享推理后端如何组织提示词现在业界常说的 deepseek harness不是某个官方插件而是一种 Agent 编排思路多个技能skill或子智能体共享同一个 DeepSeek 推理后端通过一个调度层来决定请求交给哪个技能处理。这种模式的常见问题是技能之间的提示词互相污染以及上下文在多个 Agent 之间被无意义地传递。我在做 Agent 编排时最核心的一条原则是每个技能必须有独立的系统提示词不能共用一份全局提示词。全局提示词只描述总目标和安全边界技能级提示词才描述具体做法。因为推理模型会非常严格地遵循系统提示词如果全局提示词里写了“你是客服助手”技能 A 是代码生成技能 B 是工单分类两个技能都会受到“客服助手”这个角色设定的干扰。一个最小可用的 harness 调度层逻辑上大致是这样def route_request(request_text, available_skills): # 1. 用轻量模型做意图分类不占推理模型资源 intent classify_intent(request_text) # 2. 挑选技能注入该技能独立的系统提示词 skill available_skills[intent] messages [ {role: system, content: skill.system_prompt}, {role: user, content: request_text} ] # 3. 把请求交给推理模型执行 resp call_reasoner(messages) return resp这里的意图分类我建议用一个便宜快速的小模型来完成不要让推理模型去做“决定交给哪个技能”这件事。推理模型的强项是执行复杂任务而不是做路由判断。路由判断用聊天模型或规则匹配就够了省成本也避免推理模型在多个技能之间犹豫。编排层的第二个经验是控制上下文共享。多个技能共用一个会话时每个技能的中间推理结果不应该自动追加到下一轮请求里。推理模型的 reasoning_content 本身就不适合作为共享记忆如果把它传给下一个技能等于把上一个任务的思维过程混进新任务会让新任务的推理链出现偏移。正确的做法是技能 A 的最终输出经过结构化提取后才作为技能 B 的输入材料。4.2 工具调用为什么报 “tool calls need immediate results” 以及如何回填 messages把 DeepSeek 接入到现有的 OpenAI 兼容工具链比如 Codex 接入 DeepSeek、或自己开发的 Agent 框架时最常见的一个报错是 messages tool calls need immediate results。这个错误出现的原因是 messages 协议没有按 OpenAI 的工具调用规范回填。工具调用的正确流程是第一轮请求发给模型模型返回 assistant 消息里面带 tool_calls 字段每个 tool_call 有一个唯一的 tool_call_id你执行完本地工具后需要把工具结果作为一条 roletool 的消息追加到 messages 里并且带上对应的 tool_call_id然后再发起下一轮请求。容易翻车的地方有两个。第一个是把工具结果直接作为 roleuser 消息塞回去没有用 tool 角色第二个是回填时丢失了 tool_call_id或者 tool_call_id 和 assistant 消息里的对不上。这两种情况都会触发 immediate results 类报错。下面这段代码演示正确的回填方式# 第一轮请求 resp client.chat.completions.create( modeldeepseek-reasoner, messagesmessages, toolstools_definition ) assistant_msg resp.choices[0].message messages.append(assistant_msg) # 先把 assistant 消息连同 tool_calls 追加进去 if assistant_msg.tool_calls: for tool_call in assistant_msg.tool_calls: # 本地执行工具函数 result run_local_function(tool_call.function.name, json.loads(tool_call.function.arguments)) # 工具结果必须用 tool 角色回填并且带上同一个 tool_call_id messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 带着完整 messages 发第二轮让模型基于工具结果继续推理 final_resp client.chat.completions.create( modeldeepseek-reasoner, messagesmessages )这里最容易被忽略的一步是assistant 消息必须在工具结果回填之前追加进去。如果只追加了 tool 消息而漏掉了 assistant 消息协议校验会认为工具结果没有对应的调用请求也会报同样的错。另一个和推理模型相关的坑DeepSeek 推理模型在工具调用回合中推理链会变得特别长。第一轮请求到返回 tool_calls 的时间往往比聊天模型慢不少。如果 Agent 框架里有硬性的超时限制这个环节最容易挂。需要在框架层面把工具调用类的请求超时时间调大或者改为异步轮询模式。4.3 接入 Codex / 企业微信入口适配思路与异步返回把 DeepSeek 接入现有的开发者工具或办公入口最近讨论得特别多比如 Codex 接入 DeepSeek、企业微信接入 DeepSeek 这类需求。这些场景的核心不是模型本身而是提示词适配和交互模式改造。以 Codex 这类编码 Agent 为例它本身有自己的一套提示词体系和工具协议。接入 DeepSeek 时需要额外补一条约束性系统提示词内容大致是“你是编码助手严格按系统工具协议返回结果不要输出与工具协议无关的解释文字”。因为推理模型在回答时会自带一大段推理过程如果这段推理被 Codex 的解析器误当成工具指令会出现调用错乱。把思维链输出在协议层过滤掉只保留 final answer 里的结构化内容参与解析是更稳妥的做法。企业微信这类办公入口的核心问题则是异步返回。推理模型 TTFT 长如果企业微信机器人是同步调用用户在群里发一条消息后要等好几秒才有回应体验很差。常见的做法是把流程改成用户消息进来机器人先回一条“正在分析中”然后把请求丢进任务队列推理模型跑完后再通过企业微信的主动推送接口把结果发到群里。这里的提示词也需要为异步场景做调整。因为用户看不到模型的推理过程最终答案必须自带完整的上下文引用。我一般会在输出格式里加一条“回答开头用一句话说明你处理了什么任务结尾列出关键依据”这样用户在拿到延迟响应时不需要回翻聊天记录就能理解结果。办公入口场景还有一个容易被忽视的代价问题企业微信里用户发送的消息质量参差不齐很多是口语化的零散输入。直接用推理模型处理这些低质量输入既慢又贵。更经济的设计是先用聊天模型做一次消息规整把口语转成结构化任务描述再决定要不要交给推理模型。这个前置步骤的成本几乎可以忽略但能让推理模型的准确率明显提升。5. 避坑DeepSeek 推理模型接入业务时最常踩的 5 个坑现象 1加了“不要思考、直接回答”指令后回答质量反而大幅下降这是一个很容易撞上的坑。有些团队为了省 token、降延迟在系统提示词里写“不要分析直接给我答案”希望推理模型跳过思考过程。但 DeepSeek 推理模型的推理能力是内置的不是靠提示词触发的。你让它“不要思考”它反而会在“要不要思考”这件事上反复权衡输出变得犹豫、不确定。原因推理模型的架构决定了它一定会做内部推理。提示词里的“不要思考”和模型的内在机制冲突系统提示词优先级又很高模型会尝试抑制自己的推理链结果两边打架。解决删掉这类指令。如果业务确实需要低延迟不要用提示词去压制推理模型而是换掉模型改用 deepseek-chat 这类聊天模型。模型选型解决延迟问题提示词只负责表达业务需求。现象 2API 只返回 reasoning_content没有最终答案这是 max_tokens 设置不当的典型表现。推理模型的实际输出 reasoning_content answer 两部分。max_tokens 只够推理链消费最终答案还没来得及生成就被截断了。原因对推理模型的 token 消耗预估不足沿用了聊天模型时代“max_tokens512 够用”的经验。解决把 max_tokens 提到 8192 以上复杂任务可以按“最终答案预估长度 × 2”预留。调试阶段可以用 streamTrue 先看返回内容判断截断点是在推理过程还是最终答案。现象 3塞入大量文档后推理模型开始引用不存在的规则上下文过长、内容过杂时推理模型会出现“虚假事实引用”——引用了上下文里不存在的版本或规则。这个坑在 RAG 场景特别常见。原因推理模型在长上下文中做信息筛选时注意力会被高频出现的词汇带走容易把相似但不相关的内容当成依据。上下文里内容越杂这种混淆越严重。解决不要整篇塞文档。先做切片、摘要、关键词抽提只把相关片段放进上下文。还可以在提示词里加一条“如果引用规则必须同时给出出处编号”这样模型在引用时会更加谨慎出错后也方便审计。现象 4工具调用一直报 messages tool calls need immediate results这个报错在接入 OpenAI 兼容工具链时非常高频。表面上看是协议错误实际是 messages 回填顺序或者角色用错了。原因最常见的是把工具结果作为 user 消息回填或者漏掉了助手返回的 tool_calls 消息还有 tool_call_id 不匹配。解决严格按“assistant 消息含 tool_calls→ tool 结果消息带 tool_call_id→ 新一轮请求”的顺序组织 messages。调试时把 messages 逐条打印出来检查角色和 id。现象 5本地用 7B 蒸馏模型跑产业场景效果和 API 满血版差一大截本地部署蒸馏版推理模型跑代码生成和数学题确实有模有样但一到复杂的业务分析、长文档理解效果断崖式下跌。团队容易误以为“推理模型本地部署效果都不行”实际上是模型规模的问题。原因蒸馏版模型继承的是满血模型的推理风格但参数量摆在那复杂任务的推理深度、知识广度都跟不上。7B 模型做固定领域任务效果尚可泛化能力远远不够。解决按任务复杂度分档部署。高复杂度任务走 API 满血模型固定领域、高频重复的任务用本地小模型。上线前用 50 条真实业务样本做一轮人工评测如果准确率达不到业务要求不要强行用本地模型优先考虑 API 或者更大规模的量化模型。6. 先用 50 条真实样本验证值不值得全面铺开评估指标与个人习惯6.1 评估框架不只看准确率还要看 TTFT 和成本推理模型在产业场景铺开之前我建议先做一个最小验证而不是直接全量替换。验证的核心是三个维度业务准确率、首字延迟 TTFT、单次成本。准确率不是看模型觉得自己回答得怎么样而是用业务方提供的标准答案做比对。比如工单分类任务准备 50 条已经标注好分类的历史工单让推理模型跑一遍统计分类准确率。这个数字低于 90% 的话先不要谈什么 Agent 编排、上下文工程先把提示词调好再说。TTFT首字延迟直接决定用户体验。推理模型的 TTFT 通常比聊天模型长 3 到 5 倍如果你的业务链路有同步等待场景这个指标必须在验证阶段实测不能只看别人的 benchmark。成本是最后一项但最容易算错。推理模型的成本不是看 API 每百万 token 的单价而是看实际消费一次请求的输入 token 加上输出 token 的总量。推理链长导致输出 token 翻倍实际单次成本可能是聊天模型的几倍。验证阶段把 50 条样本的实际 token 消耗全部记录下来算一个平均单次成本。# 验证脚本的最小记录结构 records [] for case in test_cases: resp call_reasoner(case.prompt) records.append({ case_id: case.id, ttft_ms: resp.first_token_ms, # 首字延迟 total_ms: resp.total_ms, # 总耗时 prompt_tokens: resp.usage.prompt_tokens, completion_tokens: resp.usage.completion_tokens, answer_ok: judge(case.expected, resp.answer) # 业务判定 }) # 统计口径准确率、平均 TTFT、平均成本 accuracy sum(r[answer_ok] for r in records) / len(records) avg_ttft sum(r[ttft_ms] for r in records) / len(records) avg_cost sum( r[prompt_tokens] * prompt_price r[completion_tokens] * completion_price for r in records ) / len(records)判断标准很简单准确率达标、TTFT 在业务可接受范围内、单次成本能算得过账三个条件同时满足才值得铺开。6.2 两种模型切换的保守做法与个人习惯如果你验证下来推理模型的效果不错但成本和延迟压力大有个折中的做法按任务难度路由。简单任务走聊天模型复杂任务走推理模型。路由判断可以由聊天模型来做开销极低。我经历过两个业务工单分类这种任务聊天模型的准确率已经到 92%推理模型到 94%但成本差 4 倍最后选型反而回归聊天模型而代码审查这种任务聊天模型只能抓表面语法问题推理模型能发现并发隐患和边界条件问题这种任务哪怕贵一点也必须上推理模型。我现在的个人习惯是每接一个项目第一周不写任何业务代码只搭一套评测集和评测脚本。评测集里既有正常样本也要故意放几条超出常规的边界样本看模型会不会翻车。这套评测集不追求数量50 条左右就够但必须是真实业务数据不能拿公开数据集凑数。数据集准备好之后花半天时间把聊天模型和推理模型各跑一遍用数据决定选型而不是靠感觉。这个习惯帮我避掉了不少坑。有一次我发现推理模型在代码审查场景准确率很高但把同样的提示词切到聊天模型时效果差得离谱于是顺势做了模型路由而不是统一替换。如果一开始就全量铺开推理模型预算撑不住系统也扛不住延迟。先验证再铺开是我做过的最划算的一件事希望帮到你。本文还有配套的精品资源点击获取