大模型应用开发实战指南：从Token、提示词到RAG全流程

"大模型应用开发"这两年已经从新鲜词变成了刚需技能。我身边不少团队其实早就把模型接口调通了，但做出来的东西离"能用"总差一口气：回答空泛、格式不稳定、多问几轮就失忆、一涉及业务细节就开始乱编。这篇指南想把这些问题从根源到解法一次讲透，从最基础的概念一路讲到可落地的工程实践，内容覆盖面比较全，我建议你先收藏再慢慢看，照着一步步做，至少能帮你少走一个月的弯路。

适合的人群很宽：刚接触大模型的开发者、想给团队做内部工具的效率工程师、以及需要跟技术团队对齐认知的产品经理。你不需要会训练模型，也不需要懂复杂的数学公式，只要会基本的 Python，能理解"规则 + 上下文 + 外部数据"这套思路，就能跟上后面的所有实操。文章里的代码都能直接改着用，模型服务选哪家都行，核心方法论不会过时。

1. 先搞清楚：大模型应用开发到底在做什么

1.1 大模型是什么，不是什么

大模型的本质是一个"根据前文预测下一个词"的统计模型。你给它一段文字，它根据训练时学到的规律，一个词一个词地往后生成。听起来简单，但当模型规模达到千亿参数级别、训练语料几乎覆盖了人类知识文本之后，"预测下一个词"这件事事实上表现出了很强的推理、总结、改写、代码生成能力。

但这里有一个必须纠正的认知：大模型不是数据库，也不是搜索引擎。它不是"查"出来的答案，而是"编"出来的答案。它不知道自己的知识截止到什么时候，也不知道它说出的某句话到底来自训练数据还是临时发挥。理解这一点，是后面所有工程实践的地基——你永远不会信任一个会一本正经编造答案的组件，除非你给它加上外部约束。

很多新手上来就踩这个坑：拿私有业务问题去问模型，发现模型答得头头是道，拿去做演示，结果一个关键数据是错的。这就是没搞清楚模型的"记忆"和"编造"之间的界限。通俗地说，模型像一个读了很多书但没经历过你业务的人，你问它常识它能答，问它你们公司内部的流程政策，它就只能靠猜。

1.2 应用开发者的真实工作内容

不少人以为大模型应用开发就是"调 API"。实际上，调通 API 只是最简单的一步，大概只占整个工作量的两成。剩下的八成是：设计提示词让输出可控、管理对话上下文、把业务数据接进模型、处理错误和异常、控制成本和延迟、建立评测回归机制。

我打一个比方：大模型像一个能力很强但性格不稳定的实习生。它知识面广、反应快，但容易忘事、会胡编、不守格式。应用开发者的工作，就是给这个实习生配一整套工作流程——告诉他岗位职责（系统提示词）、给他参考资料（RAG）、给他表单模板（结构化输出）、给他审核环节（校验与兜底）。你做的所有工程手段，本质上都是在给这个"实习生"做约束和补位。

想清楚这一点，你对"大模型应用开发"的定义就不会跑偏。它不是写几个魔法咒语让 AI 帮你干活，而是设计一套人机协作流水线：哪些步骤交给模型，哪些步骤固定代码，哪些步骤需要人工兜底，边界划清楚，产品才稳。

1.3 这门技术能用在哪些地方

从影响范围看，大模型应用开发已经渗透到了几乎所有软件方向。最典型的几类：客服对话机器人、企业知识库问答、文档处理与信息抽取、内容生成助手、代码辅助工具、数据分析的自然语言入口。每个方向里模型只负责一部分智能，其余靠工程把它焊接到业务流程上。

这也意味着，学会了这套方法，你的可迁移能力很强。今天是给客服做个应答机器人，明天可能是给运营做个周报生成器，后天可能是给研发做个代码审查助手。底层都是同一套：理解需求、设计提示词、管好上下文、接好数据、控制成本和质量。方向可以换，能力底色不变。

2. 入门前必须吃透的五个核心概念

2.1 Token：一切能力与开销的计量单位

Token 是大模型处理文本的基本单位。它不是一个字也不是一个词，而是一个"文本片段"。中文里一个 Token 大约对应半个到一个汉字，英文里一个 Token 大约对应四分之三个单词。你可以简单理解成：模型看到的文本是被切成一小块一小块去处理的。

Token 之所以重要，有三个原因。第一，几乎所有计费都按 Token 计算，输入和输出分别计费，你发的提示词和你收到的回答都要花钱。第二，模型的能力上限按 Token 计算，一次能"记住"多少东西取决于上下文窗口大小。第三，Token 数量直接影响响应速度——让模型读一万字再回答，肯定比读一百字回答慢得多。

我建议你从第一天就养成估算 Token 的习惯。一个粗略经验值：中文一页 A4 纸约 1500 到 2000 字，对应约 2000 到 3000 个 Token。如果设计上下文窗口为 8K，意味着你一次请求里能发给模型的所有内容——系统提示词、历史对话、用户当前输入、工具返回结果——加起来不能超过这个量。

2.2 上下文窗口：应用设计的隐形边界

上下文窗口是模型一次请求里能看到的全部文本长度。它不是"训练数据量"，而是"本次对话的记忆容量"。一个 32K 窗口的模型，意味着它一次最多能"看到"约几万字的材料。

上下文窗口决定了两件事：一是你的应用能处理多复杂的问题，二是你必须做多少上下文管理工作。窗口越大价格越贵，而且从统计规律看，模型对长文本中部的关注度会衰减——你塞给它 3 万字材料，它很可能记得开头和结尾，但忘了中间某个关键细节。

所以成熟的工程实践里，很少有人把全部历史无脑塞给模型。大家会做摘要、做裁剪、做检索——只把当前这一步最需要的内容装进窗口。记住一句话：上下文窗口不是用来装满的，而是用来预算和管理的。

提示：这句话值得贴在你工位上——上下文窗口是预算，不是仓库。把有限的窗口留给当前最需要模型的那些内容。

2.3 Prompt：你与大模型之间唯一的接口

Prompt（提示词）是你写给模型的指令。它可以是简单的"把下面这段文字翻译成英文"，也可以是一个几百字的系统设定，包含角色、语气、规则、示例、输出格式。模型的所有行为差异，本质上都来自提示词差异。

我经常跟团队说：提示词就是新时代的需求文档。你写不清楚，模型就做不对。写得太宽泛，模型就自由发挥；写得太死板，模型就失去灵活性。好的提示词是"清晰的规则加必要的自由度"。

关于提示词的写法，后面专门有一节展开。这里先记住一条最核心的规律：模型是按字面意思理解的。它不会自动补全你没说的要求，也不会自动理解你心里想的"应该是这样吧"。所有要求，都要落到字面上，不能指望它意会。

2.4 温度与采样参数：控制"脑洞"大小的旋钮

调用模型时你会看到一堆参数，其中最重要的两个是 Temperature 和 Top-p。它们控制模型在生成下一个词时的随机程度。

Temperature 越低，模型越倾向于选概率最高的词，输出越确定、越保守；Temperature 越高，模型越倾向于选概率不是最高但有变化的词，输出越多样、越有"创意"。Top-p 是另一个控制随机性的旋钮，它限制模型只在累计概率达到某个阈值的候选词里做选择。

我的经验值如下：

注意，这两个参数只影响输出的"风格"，不影响模型的知识边界。你用高温让它更"有创意"，它该胡编的时候照样胡编。

2.5 幻觉：必须时刻保持的"不信任感"

幻觉指模型生成的内容与事实不符，但语气却非常肯定。这是大模型最让人头疼的特性，也是所有严肃应用必须优先处理的风险。

为什么会产生幻觉？因为模型本质是词的概率分布，它优化的是"下一句话看起来顺不顺"，不是"是不是事实"。当某个问题不在它的知识范围内，或者训练数据本身有冲突时，它不会说"我不知道"，而是会基于语言习惯编一个最像样的答案。

应对幻觉没有银弹，但有组合拳：一是把关键事实交给外部来源，不要指望模型自己知道（这就是后面要讲的 RAG）；二是要求模型在不确定时明确说"不知道"；三是对高风险场景做输出校验和兜底；四是定期做抽样审查。以后听到任何"我们模型没有幻觉"的宣传，当笑话听就好。

3. 从零搭建开发环境与完成第一次调用

3.1 本机环境准备

开始之前，你只需要三样东西：Python 3.9 以上环境、一个代码编辑器、一个可以联网的环境。绝大多数大模型服务平台都提供 Python SDK，安装基本就是一行 pip。

建议你新建一个虚拟环境，避免依赖冲突：

bash复制python -m venv llm_env
source llm_env/bin/activate  # Windows 上执行 llm_env\Scripts\activate
pip install requests          # 或者安装你选定的服务商 SDK

如果服务商有官方 SDK，优先用官方 SDK，因为它封装好了重试、流式响应、错误处理。没有的话直接用 HTTP 请求也能调，目前各家大模型服务的接口大多兼容同一套 Chat Completions 风格，事实上的行业标准已经形成了，换平台学习成本很低。

3.2 模型服务怎么选

市面上的大模型服务大致分三类。

第一类是通用对话模型 API，按 Token 计费，开箱即用，适合绝大多数应用。选择时重点看三个指标：上下文窗口大小、价格、知识截止时间。

第二类是开源模型的自托管方案。如果你有 GPU 资源，或者对数据隐私要求极高，可以部署开源权重模型。优点是数据不出内网、按照自己的算力控制成本；缺点是部署运维有成本、需要调优，效果通常比头部商用模型稍逊。

第三类是垂直领域模型或特定能力模型，比如专门做代码的、专门做翻译的。除非需求非常明确，否则第一类模型配合提示词工程基本能覆盖大多数场景。

我的建议是：做原型阶段不要纠结选型，挑一个生态成熟、文档齐全的通用模型服务，先把流程跑通。真正上线时再根据实测效果和成本数据做对比。很多团队死在选型纠结上——花了一个月对比参数，一个功能都没做出来。

3.3 第一次 API 调用：一个完整可运行的例子

下面是最简单的一个调用示例，把其中的 API 地址、模型名、密钥替换成你实际使用的平台信息即可：

python复制from llm_sdk import Client

client = Client(
    api_key="你的密钥",
    base_url="https://api.example.com/v1",
)

response = client.chat.completions.create(
    model="your-model",
    messages=[
        {"role": "system", "content": "你是一个简洁的助手，回答不超过50个字。"},
        {"role": "user", "content": "用一句话解释什么是大模型。"},
    ],
    temperature=0.3,
)

print(response.choices[0].message.content)

运行以后你会得到一个回答。它可能算不上惊艳，但你的第一个大模型应用已经跑通了。

这里有三个细节值得注意。第一，API 密钥不要硬编码在代码里，用环境变量保存：export API_KEY=你的密钥，代码里用 os.getenv("API_KEY") 读取。第二，temperature=0.3 表示我尽量让回答保守稳定，因为"解释概念"这个任务不需要创意。第三，注意 messages 列表的结构——system 和 user 两种角色，这已经是最简单的提示词工程了。

4. 构建一个能对话的应用：多轮会话与上下文管理

4.1 为什么单轮对话远远不够

大多数真实应用不是"问一句答一句"，而是连续对话。用户会追问、会修正、会补充背景。如果你每次只把用户当前这句话发给模型，模型就会失忆——它完全不知道用户前面说过什么。

大模型 API 本身是无状态的。它不记得任何历史，每次调用都是全新的。所谓多轮对话，其实是你把聊天记录作为内容的一部分重新发给模型。理解了这一点，你就理解了会话管理的全部——历史不是模型帮你存的，是你在应用层自己维护的。

这个认知很重要，因为它直接决定了你的架构设计。你需要自己设计历史存储方案：存内存里、存数据库里、还是存 Redis 里；需要自己决定保留多少轮；需要自己处理并发时历史串号的问题。这些模型都不帮你做。

4.2 会话历史的组织方式

最简单的做法是维护一个 messages 列表，每次请求时把完整列表带上：

python复制messages = [
    {"role": "system", "content": "你是产品顾问，说话专业但不啰嗦。"},
    {"role": "user", "content": "我在做一个人力资源管理系统，帮我起三个模块名。"},
    {"role": "assistant", "content": "好的，以下三个方向供参考：组织架构管理、招聘流程跟踪、绩效评估中心。"},
]

# 用户追加新问题
messages.append({"role": "user", "content": "能详细说一下绩效评估中心的表单字段吗？"})

response = client.chat.completions.create(
    model="your-model",
    messages=messages,
    temperature=0.5,
)

注意 roles 的语义：system 是系统设定，user 是用户输入，assistant 是模型之前的回答。你把"模型说过什么"也放进 messages，是为了让模型在下一轮生成时知道"我之前已经说过这些话了"，从而保持对话的一致性。如果省略 assistant 历史，用户前面问过什么、你答过什么，模型一概不知，对话就会变得前言不搭后语。

4.3 Token 预算与上下文裁剪策略

对话超过一定轮数，messages 列表会超出上下文窗口。这时候必须做裁剪。常见策略有三种。

第一种是滑动窗口：只保留最近的 N 轮对话，更早的直接丢弃。简单粗暴，但会丢失早期信息，适合会话较短的应用。

第二种是摘要压缩：当对话超过阈值，调用模型把前面的内容总结成一段摘要，然后只保留摘要加最近几轮。我实测下来这是性价比最高的方案，既保住了关键信息，又能把 Token 压得住。

第三种是关键信息抽取：从对话中抽出用户的核心需求、偏好、待办事项等结构化字段存起来，每次请求时带上这些字段。适合客服、私人助理这类需要长期记忆的应用。

我自己做系统时的经验是：先估算单轮对话的平均 Token 消耗，再设定一个对话轮数阈值，达到阈值就触发压缩。不要等到报"超出上下文窗口"错误才去处理，那时候用户已经感知到卡顿和失忆了。

4.4 一个最小可用的对话机器人

把上面这些串起来，一个带简单裁剪的对话机器人核心逻辑如下：

python复制MAX_HISTORY = 10  # 最多保留最近10条消息

def build_messages(system_prompt, history, user_input):
    messages = [{"role": "system", "content": system_prompt}]
    recent = history[-MAX_HISTORY:]
    messages.extend(recent)
    messages.append({"role": "user", "content": user_input})
    return messages

# 每次用户发消息时
history = []  # 由你维护，可存内存或数据库
user_input = "你好，请介绍一下你的功能"
messages = build_messages("你是HR助教机器人，回答简洁专业。", history, user_input)
response = client.chat.completions.create(model="your-model", messages=messages)
history.append({"role": "user", "content": user_input})
history.append({"role": "assistant", "content": response.choices[0].message.content})

到这一步，你已经有一个"能聊天、有有限记忆"的应用了。接下来要解决更高级的问题：怎么让回答更可控、更专业、更贴近业务。这就进入提示词工程了。

5. 让模型按你的规则输出：提示词工程实战

5.1 系统提示词：给模型定人设与边界

系统提示词是 messages 里 role 为 system 的那条，负责定义模型的整体行为。一个有效的系统提示词通常包含：角色定义、任务目标、行为规则、输出格式、边界约束。

给你一个可以直接改用的模板：

code复制你是[角色]，服务于[业务场景]。
你的任务是[核心任务描述]。
行为准则：
1. 回答必须基于给定的资料，不编造事实。
2. 当信息不足时，明确说"根据现有资料无法回答"。
3. 语气[正式/亲切/专业]，篇幅控制在[XX]字以内。
4. 每次回答结束后，可以主动追问一个澄清问题。
输出格式：[具体格式，如"先给结论，再给理由，最后给建议"]。

写系统提示词最容易犯的错是只给角色不给规则。只写"你是客服助手"，模型确实会扮演客服，但不知道要不要控制长度、能不能编数据、输出用什么结构。规则越具体，行为越可控。

5.2 少样本示例：用例子代替规则

很多人写提示词爱用大段形容词："你要给出非常详细、专业、有价值的回答。"我实测这种抽象要求的生效程度远不如给一两个示例。示例（few-shot）是让模型快速理解你到底要什么的最直接手段。

举个例子，你想让模型把用户反馈分类：

code复制请将用户反馈分类为：功能建议、缺陷报告、体验吐槽、好评。
示例1：
用户说："下载速度太慢了，能不能加个加速功能。"
分类：功能建议
示例2：
用户说："点击保存按钮后页面卡死了。"
分类：缺陷报告
现在分类下面这条：
用户说："界面配色很好看，但希望字体能大一点。"
分类：

模型看到示例后，输出的稳定性和格式正确率会提升很多。这个技巧在信息抽取、分类、格式化生成场景里几乎是必用的。而且示例最好不要跟真实业务数据混在一起，否则有泄露业务字段的风险。

5.3 结构化输出：JSON 与函数调用

应用开发中最常见的需求，是让模型输出结构化数据而不是散文。比如从订单留言里提取客户姓名、商品名称、问题类型。直接让模型"输出 JSON"经常会遇到格式不稳定——偶尔多一句解释、偶尔少一个括号。

两个比较稳的方案。

方案一：在提示词里给出明确的 JSON 模板和约束，比如"只输出 JSON，不要任何解释，字段缺失时填 null"。

方案二：使用函数调用能力（Function Calling）。这是目前最推荐的方式——你预先定义好一个函数的参数结构，模型在需要时会输出一个调用指令，参数完全按 JSON Schema 生成，格式由平台保证。你的代码负责真正执行这个函数，并把结果回传给模型做下一步处理。

python复制tools = [{
    "type": "function",
    "function": {
        "name": "search_product",
        "description": "按关键词搜索商品并返回库存与价格",
        "parameters": {
            "type": "object",
            "properties": {
                "keyword": {"type": "string", "description": "商品关键词"},
                "limit": {"type": "integer", "description": "返回数量"}
            },
            "required": ["keyword"]
        }
    }
}]

注意：函数调用返回的是模型"表达意图"的参数对象，真正去查询数据库、调用外部接口的动作必须由你自己的代码完成。模型不执行任何函数，它只是告诉你"应该调用哪个函数、用哪些参数"。

函数调用把"模型输出自由文本"升级为"模型发出可执行指令"，这是构建 Agent 类应用的核心机制。后面做自动查天气、订餐、查库存的助手，都靠这个能力。

5.4 实用提示词模板速查

几个高频场景的提示词骨架整理如下，可以直接复制改：

• 文本总结：将以下内容压缩为[N]条要点，每条不超过[XX]字，保留关键数字和结论：\n{原文}
• 信息抽取：从下面的文本中提取[字段列表]，以JSON格式输出，字段缺失时填null。\n{文本}
• 改写风格：把下面的内容改写成[轻松/专业/有说服力]的风格，保留原意，不增减信息。\n{内容}
• 代码解释：解释以下代码的作用，指出潜在的性能问题和安全隐患，用中文回答：\n{代码}

有一个贯穿所有模板的原则：能用结构化指令，就不用形容词描述。把"要好一点"换成"不超过50字""结论先行""每条列表前加序号"，输出质量立刻上一个台阶。语言模型的训练过程决定了它对具体、可验证的表达更敏感，你给它的约束越可检查，它的表现就越听话。

6. 让应用懂业务：知识库问答与 RAG 实操

6.1 为什么需要 RAG：从记忆容量说起

大部分人做的第一个正经应用是智能客服或企业知识库问答，想让模型基于公司文档回答问题。但这里有个天然矛盾：模型的训练数据里没有你的内部文档，它不可能自动知道你的产品规格、售后政策、内部流程。

RAG（Retrieval-Augmented Generation，检索增强生成）解决的就是这个问题。思路一句话就能说清：你不是让模型凭记忆回答，而是先从一个你自己维护的资料库里检索出相关片段，把片段连同用户问题一起发给模型，让模型"看资料作答"。

打个比方，RAG 等于考试时给模型配了一本可以翻的参考资料，而提示词工程是教它怎么用笔。两者配合，才是功能完整的应用。

6.2 RAG 整体流程拆解

一个典型的 RAG 流程分五个阶段：文档加载、文本切分、向量化、检索召回、生成回答。

文档加载解决数据从哪来——PDF、Word、网页、数据库都可以作为来源。文本切分解决一段多长合适——切太长检索不精准，切太短语义不完整。向量化是把文本转成数学向量——语义相似的内容在向量空间里距离近。检索召回是用户提问时，在向量空间里找最相近的几段。生成回答则是把检索结果拼进提示词，让模型基于材料作答。

前三个阶段是离线准备，文档更新时重做一次即可；后两个阶段是在线推理，每次用户提问都要执行。这个结构天然适合工程化：离线部分用定时任务，在线部分要重点控制延迟。

6.3 文档切分与向量化的细节

切分是 RAG 里最容易被低估的一步。我见过不少项目，检索效果差，怀疑是模型不行、算法不行，查到最后发现是切分策略太粗。

切分的基本单位通常有两种：按固定字符数切（比如每 500 字一段，带 100 字重叠），或者按语义结构切（比如按 Markdown 标题、PDF 的自然段落、代码文件的函数块切）。我的经验是：固定长度切分够用，但一定要加重叠——第一段结尾被腰斩的那句话，第二段开头要能看到，语义才不容易断掉。

向量化的核心是嵌入模型的选择。它能把任何文本映射成几百维的向量。选嵌入模型时，建议直接在你自己的领域文档上跑一轮检索测试，看召回质量，不要只信排行榜分数。中文场景尤其要注意：很多开源嵌入模型英文效果不错，中文效果却一般，务必用真实的中文语料做测评。

6.4 检索质量与结果重排

检索召回不是"找最相似的一段"就结束了。用户一个复杂问题，可能需要整合文档里多个位置的信息。工程上常见的做法是召回 Top-K（比如取 8 到 10 段），然后做两轮筛选。

第一轮叫相关度过滤：用相似度得分和阈值，把明显不相关的段落去掉。第二轮叫重排：用一个专门的排序模型对召回结果重新排序，这一步通常比向量相似度准确得多。重排模型一般更贵、更慢，但因为只对几十条候选排序，总耗时可控。

如果你刚入门，可以先不做重排，用向量召回 Top-5 就能跑通。等发现效果瓶颈了，再加重排。工程上最忌讳一上来就堆组件——连基础链路都没调好，加再多的模块只会让问题更难排查。

6.5 一个极简 RAG 流程的实现思路

完整代码会比较长，这里给出核心流程的伪代码，你可以对照自己选用的框架实现：

python复制# 离线准备
docs = load_documents("你的文档目录")                        # 加载 PDF/Word/网页
chunks = split_text(docs, chunk_size=500, overlap=100)      # 切分
vectors = embed_model.encode(chunks)                        # 向量化
index = build_index(vectors)                                # 建索引，存到向量数据库

# 在线查询
def answer_question(question):
    q_vec = embed_model.encode([question])                   # 用户问题向量化
    candidates = index.search(q_vec, top_k=8)               # 检索最相似的8段
    context = "\n\n".join(chunks[i] for i in candidates)
    prompt = f"""
    请根据以下资料回答问题。如果资料中没有答案，请明确说"资料中未找到相关信息"。
    资料：
    {context}
    问题：{question}
    """
    return client.chat.completions.create(model="your-model", messages=[
        {"role": "user", "content": prompt}
    ])

注意生成回答的提示词里，我特意加了"资料中没有答案就明说"的约束——这是对抗幻觉的第一道防线。资料和问题是拼接在一个 prompt 里的，所以前文讲的 Token 预算在这里同样适用：上下文窗口有限的模型，就要控制喂进去的资料长度，宁可少喂也要求准。

7. 上线前必须重视的问题与排查实录

大模型应用上线前，我强烈建议先把下面这张速查表逐条过一遍。这些都是真实项目里反复出现的问题，每一个都能让线上体验翻车：

下面展开讲每个问题的排查细节。

7.1 输出格式不稳定

现象：明明让模型输出 JSON，它非要先来一句"好的，根据您的要求……"再输出；或者少了逗号、多了注释。

排查顺序：先看提示词里有没有显式给出 JSON 模板和"只输出 JSON，不要任何解释"的硬约束；再看有没有用函数调用兜底；最后在代码侧做容错解析，解析失败就让模型重新生成一次。

我的习惯是三层兜底：提示词约束第一层、函数调用第二层、代码解析与重试第三层。只要第三层在，格式错误对用户不可见——他只会看到一次"稍等一下，我再确认一次"。

7.2 回答空洞、像正确的废话

现象：模型说了很多，但没有任何有效信息。"我们需要加强管理、优化流程、提升效率"这类话谁都会说，用户要的是具体方案。

原因多半是提示词没有要求具体，也没有给输出结构。解决办法很直接：在提示词里加硬性约束，比如"回答必须包含具体步骤或例子""禁止使用空泛形容词""每个观点必须对应一个可执行动作"。如果还不够，给一个"好回答 vs 坏回答"的对比示例，让模型明确知道要哪种。很多人觉得模型笨，其实是你没把要求说到位。

7.3 Token 消耗与成本失控

现象：应用上线后账单飞涨。最常见的两个原因：一是把完整历史对话无脑全量发给模型，每轮 Token 越滚越大；二是检索召回的文档片段太多，动辄喂进去几千 Token 的资料。

控制成本的手段按性价比排序：第一，裁剪历史并做摘要，能把对话成本降一半以上；第二，限制检索结果的字符总量，召回 8 段每段 500 字和召回 3 段每段 300 字，效果差距没那么大，成本差一倍；第三，低风险场景用更便宜的模型；第四，加结果缓存，相同或相似的问题直接走缓存，不做模型调用。实测一套组合下来，成本能压到原来的三分之一。

7.4 响应延迟偏高

现象：用户发一句话，要等七八秒才有回复。大模型生成是逐字输出的，回答越长越慢，这是物理限制，没法消除，但可以从几个角度优化。

第一，用流式输出，让文字一个字一个字出来，用户的感知等待时间大幅下降——这是体验提升最明显的一招，所有对话应用都强烈建议开启。第二，控制回答长度，在提示词里约束不超过 200 字，生成时间直接减半。第三，减少喂给模型的材料量。第四，高并发场景下关注服务端的队列和并发配置，必要时做多实例负载均衡。

7.5 我踩过的几个坑

第一个坑：在提示词里放了一堆范文级别的示例，结果模型变成复读机，每次都按示例的句式走，完全不会变通。后来我把示例从"完整对话"改成"半截提示 + 预期结果"，情况好多了。

第二个坑：没有做输入侧的安全检查，用户输入里带了很长的注入指令，试图绕开系统提示词。前文说了，提示词是软约束，一定要在应用层对输入做长度限制、敏感内容过滤和必要的审计，不要指望模型自己能挡住所有攻击。

第三个坑：上线前没有建立评测集。当时用二三十条测试问了感觉还行就上了，结果用户反馈翻车。后来我花了半天整理了两百条带标准答案的评测样本，每次改提示词都跑一遍，回归测试一做，质量立刻可衡量。没有评测集的大模型应用，就像没有测试用例的后端代码，迟早出事。

第四个坑：文档更新后忘了重新向量化。知识库内容改了，索引还是旧的，系统长时间给出过期信息。后来我把"文档变更触发重新切分与向量化"做成了流水线的一部分，这个问题才彻底解决。

8. 这门技能还能用在哪：场景盘点与进阶方向

8.1 典型落地场景

大模型应用开发的落地场景非常广，我在实际接触中看到最多的是这五类。

智能客服与工单分类：用 RAG 接产品文档，先做应答，回答不了再转人工，同时自动给工单打标签、分优先级。这是最容易见效也最常被提需求的方向。

内部知识库助手：把公司的制度文档、技术手册、历史决策记录都接进去，员工用自然语言提问。省的是到处找人问的时间，沉淀的是组织知识。

内容生成与加工：周报、会议纪要、营销文案、公告初稿。这类场景对确定性要求低，对效率提升感知强，适合第一个练手项目。

代码辅助与自动化测试：让模型生成单测、解释遗留代码、做 Code Review 初筛。技术团队内部推广阻力最小，收益也最直观。

数据分析的自然语言入口：用户问"上个月哪个区域的销量下滑最多"，系统自动把它转成 SQL 查询，再让模型生成解读。这类应用把大模型能力嵌到既有 BI 系统里，价值很高，但工程链路也更长。

8.2 从入门到进阶的路线建议

如果你看完这篇指南想认真做下去，我建议按四个阶段进阶，不要跳级。

阶段一：把提示词和单轮/多轮应用做熟。掌握系统提示词、少样本示例、结构化和 JSON 输出，做一个能稳定处理某类任务的小工具。

阶段二：掌握 RAG。做出一个基于自己文档的知识库问答系统，重点打磨切分、检索和提示词之间的配合。

阶段三：接触 Agent 和工具调用。用函数调用把模型接到真实系统上，让它可以查数据库、调接口、执行操作。你会开始理解"模型 + 工具 + 循环"的协作模式。

阶段四：根据业务瓶颈决定要不要碰微调、要不要自部署、要不要做更复杂的评测体系。到这一步，你已经能独立评估某个方案到底是"提示词能解决"还是"必须换模型"了。

我个人这两年做下来最大的体会是：大模型应用开发，真正难的从来不是模型本身，而是模型外面的那一圈工程。提示词要反复打磨，上下文要精细管理，检索要持续调优，评测要长期维护。把这些功夫下足了，模型版本升级、业务需求变化，你都不慌；功夫不到位，换再强的模型，做出来的东西也还是那个味。

最后分享一个小技巧：把你每一次调优的提示词、参数、实测效果都记录下来，哪怕只是存在一个 Markdown 文件里。时间长了，这就是你最有价值的私有知识库，比任何公开教程都好用。等到你要做第二个、第三个应用时，翻一翻这份记录，很多弯路根本不用再走一遍。