Docs · App Dev Guide

大模型应用开发

从 Prompt 工程到 AI Agent，一站式覆盖大模型应用开发全链路 —— 让你能在 1 周内跑出生产级 MVP。

Prompt · 指令模型 vs 推理模型

大模型应用开发里，模型不再只是「选一个最强的」。更常见的做法是按任务路由：快任务用低延迟模型，复杂任务用推理模型，图片/语音任务用多模态模型，批量任务用低成本模型。

这一章不追逐某个固定模型名，而是教你判断：这个任务该用哪类模型，以及 prompt 应该怎么写。

四类常见模型

类型典型能力适合任务Prompt 风格
指令模型对话、总结、抽取、改写、普通代码客服、内容生成、RAG 回答、简单工具调用指令清晰、上下文充分、格式明确
推理模型数学、复杂代码、长程规划、逻辑推断复杂分析、算法、疑难排错、关键决策少规定步骤，给目标、约束和验收标准
多模态模型图像、表格、音频、视频理解PDF 图表、截图问答、语音助手、视觉质检说明输入对象、关注区域、输出结构
低成本/小模型分类、路由、改写、召回前处理意图识别、query rewrite、是否需要检索短 prompt、强 schema、低 token

生产系统通常会组合这些模型，而不是让一个模型包打天下。

指令模型的 Prompt 写法

指令模型默认擅长听清楚任务并稳定输出。你要做的是把任务边界讲明白。

你是资深 Python 工程师。
      
      任务：审查下面代码的安全风险。
      
      关注点：
      1. SQL 注入
      2. Secret 硬编码
      3. 不安全的文件读写
      4. 第三方依赖风险
      
      输出格式：
      - 用 Markdown 表格
      - 每条问题包含：风险等级、位置、原因、修复建议
      
      代码：
      {code}

适合场景：

  • 普通问答、客服、摘要、翻译
  • 信息抽取、分类、结构化输出
  • RAG 基于材料回答
  • 简单 Function Call 决策

推理模型的 Prompt 写法

推理模型已经会在内部做更深的搜索和权衡。不要把每一步推理路径写死，否则可能限制模型。

反模式：

你必须先列出 10 个原因，再逐个证明，再用第三步的结论推导第四步...

更推荐：

定位这个并发 bug 的根因。
      
      已知现象：
      - 只有高并发下出现
      - 日志显示偶发重复扣款
      - 数据库使用乐观锁
      
      要求：
      - 给出最可能的 3 个根因
      - 每个根因说明验证方法
      - 最后给出优先排查顺序

适合场景：

  • 多步逻辑推理
  • 复杂代码 review
  • 算法设计与性能权衡
  • 规划类任务
  • 高风险决策前的分析

多模态模型的 Prompt 写法

多模态任务的关键不是「请看图」，而是告诉模型看哪里、输出什么。

分析这张系统架构图。
      
      重点：
      1. 识别所有服务节点
      2. 找出数据流向
      3. 标注可能的单点故障
      4. 用 Mermaid 输出架构关系
      
      不要描述颜色和装饰元素，除非它们承载架构信息。

适合场景：

  • PDF 图表解析
  • 网页截图审查
  • UI 走查
  • 票据、表格、合同图片理解
  • 语音和实时交互

小模型的价值

小模型不是「弱模型」，而是系统里的低成本组件。很多任务不需要强推理：

任务推荐用法
意图分类小模型 + 固定 label schema
Query 改写小模型生成 2-3 个候选查询
是否需要检索小模型判断 yes/no
安全预检小模型先做粗筛，高风险再升级
路由小模型决定下一步用 RAG、工具还是人工

把这些轻任务交给小模型，通常能显著降低成本和延迟。

模型路由模式

一个常见生产架构：

def route_task(task):
          if task.has_image or task.has_audio:
              return "multimodal"
          if task.requires_deep_reasoning:
              return "reasoning"
          if task.is_classification_or_routing:
              return "small"
          return "instruct"

实际系统里，这个路由可以由规则、小模型或混合策略完成。

选择模型的 7 个维度

维度要问的问题
质量这个任务真正的错误代价是什么？
延迟用户能等 1 秒、10 秒，还是可以异步处理？
成本单次调用成本和日调用量相乘是否可接受？
上下文需要 8K、128K、1M，还是应该改用 RAG？
工具能力是否稳定支持 Function Call、并行工具、结构化输出？
多模态是否需要读图、听音频、看视频、操作界面？
合规数据能否出境？是否需要私有化或本地模型？

不要写死价格和型号

模型名、上下文长度、价格、限速都会变。文档和代码里建议这样做：

LLM_MODEL=...
      REASONING_MODEL=...
      SMALL_MODEL=...
      EMBEDDING_MODEL=...
model = os.getenv("LLM_MODEL")
      reasoning_model = os.getenv("REASONING_MODEL")

在团队文档里保留一个「模型选型快照」即可，标清更新时间和来源链接。教程正文只讲选型原则。

什么时候升级到推理模型

先问 4 个问题：

  1. 普通指令模型是否已经失败，并且失败原因是推理不足？
  2. 任务是否需要多步权衡，而不是简单读材料或改写？
  3. 更高延迟和成本是否被业务价值覆盖？
  4. 评测集是否能证明升级后真的变好？

如果答案不是明确的 yes，先优化上下文、schema、RAG 和工具结果，再考虑换推理模型。

总结

场景默认选择
客服、摘要、RAG 问答指令模型
数学、复杂代码、疑难分析推理模型
图片、表格、语音、截图多模态模型
分类、路由、改写、预检小模型
大规模批处理低成本模型 + Batch

经验法则：先用便宜、快、稳定的模型跑通闭环；只有评测证明需要时，再升级到更强模型。

下一节：Prompt 工程化 —— 把 prompt、schema、评测集都当代码管理。