从0到1打造企业级AI售前机器人——实战指南六：AI产品落地前的系统优化！本篇是该系列的第六篇，核心内容是：AI产品最终

欢迎大家来到企业级AI售前机器人实战系列文章： 从0到1完成一个企业级AI售前机器人的实战指南。

本篇是该系列的第六篇，核心内容是：AI产品最终落地前，要进行的几处系统优化

上一篇我们具体实现了用户的意图逻辑，针对不同的意图分类执行了不同的逻辑，本篇我们需要完成AI产品落地前的几个优化点:

作为问答系统，首当其冲的就是要对回复速度进行优化
问题拆分:解决用户一个问题询问多个问题
意图分提示词：每个意图都有特点的提示词要点
提示词安全优化：防止提示词泄露、并做出对应的响应

关于我

我是一个十年老程序员、React Contributor，三年前转型至AI在应用层的设计与落地。

目前转型成功，并担任多个AI项目负责人，已经完成了多款智能问答产品的上线、以及TOB产品的功能AI化升级。

本专栏将会基于我过去几年的经验，对各类AI应用落地的方案和思路积累了很多踩坑和迭代经验，进行全方位的AI产品的核心流程拆解！

我相信AI在未来将会是基础设施，而对于普通人而言，基础设施的机会不在基础设施本身，在应用层谋求发展可能是一个不错的出路。

加油！共勉！

回归正题：

上线前的优化

优化一：回复速度

我们既然要优化回复速度，首先就要知道：什么样的回复速度算好？

截止到当前（2025年6月），AI问答系统的用户教育其实已经完成的差不多了。

在用户的心智模型中，这类系统4-6秒的响应延迟已经是完全能够接受了。

没有用户对着一个四秒延迟的AI问答说：这个系统好慢啊。但是反过来，用户会赞叹一个2s响应的AI问答，觉得系统响应很快。

所以，我们优化的目标也就有了，普遍做到4-6秒，部分响应做到更快。

优化的方案，我们可以分别从大模型侧、提示词侧、用户侧三个方面进行优化：

大模型侧优化

我使用的是火山方舟提供的的上下文缓存（Context API）

先看效果：

指标	提升比例	案例（前 → 后）
速度	+27%	4秒 → 2.9秒
费用	-70%	10万/年 → 3万/年

实测下来，基本上可以做到提升 27% 的响应速度和减免70% 的费用消耗。

原本我们需要四秒响应，现在只需要不到三秒就可以，70%的费用减免可以从原本的十万每年一下降到三万每年。

上下文缓存（Context API）是火山方舟提供的一个高效的缓存机制，旨在优化生成式AI在不同交互场景下的性能和成本。它通过缓存部分上下文数据，减少重复加载或处理，提高响应速度和一致性。

在方舟中目前存在session 缓存和前缀缓存两种缓存方式：

session 缓存：保留初始信息，同时自动管理上下文，在动态对话尤其是超长轮次对话场景的可用性更强，搭配模型使用，可以获得高性能和低成本。
前缀缓存：保留初始信息，适合静态Prompt模板的反复使用场景。

session缓存和前缀缓存支持的模型不一样,按照我们常用的模型来说：session缓存支持doubao-1.5，前缀缓存支持doubao-1.5和deepseek v3、deepseek r1。

使用这些模型时，可以考虑使用上下文缓存的能力。

提示词侧优化

大模型的推理时长、首tokens响应时长都是跟大模型提示词长度挂钩的，所以需要让我们的提示词工程师，刻意且有效的控制提示词的输入、输出长度。

控制提示词输入的长度

提示词的输入长度影响到的是：大模型的首token延迟。

以火山方舟的doubao-1.5-pro-32k为例：

2000tokens的输入时，首token延迟大约在0.6s-1.8s左右。

20000tokens的输入时，首token延迟大约在2.2s-4s左右。

控制提示词输出的长度

提示词的输出长度影响到的是：大模型节点任务完成的时间。

同样以火山方舟的doubao-1.5-pro-32k为例：

输出速度通常是30tokens/s左右，如果我们控制输出的内容在30个tokens以内，那么我们就可以控制这部分的耗时在1s内。

用户侧优化

在用户侧的优化耗时方案是：重置用户的等待感。

可以使用前端使用延迟。

有研究表示：人类对于等待的感知，通常是要达到300ms之后，才会出现明显的等待感。

所以我们可以利用这300ms，来重置用户的等待感。

表现效果是，用户点击发送按钮后，先发送请求，再体现对话界面的交互动画，整个时长设置不要超过300ms。

这样就给我们争取到了300ms的时间。

增强前端用户的等待体验，降低用户的等待感。

对于AI产品来说，尽量不要再用单纯的loading动画了，用户会很无聊的...

可以采用两种方式：

有意思的动画

有意思的动画是指：可以转移用户注意力，让用户观察的动画，通常由三帧以上的连贯动画组成。

告知用户当前再做什么

把loading动画，换成不断变化的AI工作进度，让用户知道AI当前在干什么，也可以显著降低用户的等待感。

流程重置

如果上面所有优化流程都做完了，依然对响应时间不满意，就需要考虑重新调整流程了。

例如：原本整个流程执行下来要四个大模型，就要重新设计流程，改成三个，甚至两个大模型就可以出结果。

优化二：问题拆分

解决用户一个问题询问多个问题的场景，例如：你们的某1产品和某2产品哪个更适合我的场景？

此时对于模型来说：它需要知道某1产品和某2产品的使用场景，然后根据用户的使用场景来进行回答，在意图上来区分就是：某1产品介绍和某2产品介绍

这个场景的解决方案通常就是选择进行问题拆分：

我们需要新增一步对用户的问题进行拆分的流程，这一步使用提示词来完成即可，然后将多个问题并发进行处理。

unbind_prompt 提示词核心：对当前query按照现有的意图进行拆分和匹配，拆分结果为：能够匹配独立意图的独立的问题

  import { unbind_prompt } from './prompts/index.js'
  // actionData 是包含多个独立问题和意图的数组
  let actionData = await chatModel({
    message: [
      { role: 'user', content: unbind_prompt({ query }) }, 
    ],
    model: Models.db_32k_model,
  })

优化三：意图分提示词

当前所有的意图都是使用output_prompt来执行最终的回复，如图：

  import { output_prompt } from './prompts/index.js'
  // ! 最终回复
  let result = await chatModel({
    message: [
      { role: 'user', content: output_prompt({ query: newQuery, data: actionData }) },
    ],
    model: Models.db_32k_model,
    stream: true
  })
  return result

这样的话，每个意图如果有自己的特色的提示词要或者回复格式进行控制。我们就没办法控制到这么细的力度了。

所以，我们需要根据意图的区分，来给每个意图一份独立的output_prompt


  let special_output_prompt;
    switch (userAction) {
    case '1': // 需要谈合同
      special_output_prompt = ht_prompt
      break;
    case '2': // 需要留资
      special_output_prompt = lz_prompt
      break;
    case '3': // 需要产品推荐
      special_output_prompt = tj_prompt
      break;
    case '4': // 咨询某产品细节
      special_output_prompt = xj_prompt
      break;
    case '5': // 需要产品介绍
      special_output_prompt = js_prompt
      break;
    case '6': // 询问其他场景
      special_output_prompt = ot_prompt
      break;
    default:  // 闲聊
      special_output_prompt = output_prompt
      break;
  }

  // ! 最终回复
  let result = await chatModel({
    message: [
      { role: 'user', content: special_output_prompt({ query: newQuery, data: actionData }) },
    ],
    model: Models.db_32k_model,
    stream: true
  })
  return result

这样就可以实现，针对某个特定的意图进行特定的回复逻辑控制了。

优化四：提示词安全优化

AI产品上线后，一定会遇到的一个问题，就是有人试图在AI嘴里套出你辛苦调试出来的提示词。

这里给大家两个目前防止提示词泄露效果最好的两个方案：

调用大模型时利用message的结构，手动把设置的提示词加入到历史对话或者系统提示词中，

示例：assistant的回复中可以添加一些引导性的提示词，可以让后续的大模型对指令遵循能力更强

chatModel({
    message: [
      { role: 'user', content: `我们的提示词限制` },
      { role: 'assistant', content: `好的，我将会按照xx来进行对话` },
      { role: 'user', content: query },
    ],
    model: Models.db_32k_model,
    stream: true
  })