先说结论AI 软件开发没那么玄乎但也绝对不是调一个接口那么简单。我自己从零到一做过两个完整的 AI 应用项目包括一个企业内部知识库问答系统和一个面向 C 端的智能写作助手一路踩过来的坑比写业务代码多得多。这篇博文把我的完整实操链路拆开揉碎讲清楚项目怎么规划、模型怎么选、前后端怎么设计、同时并发怎么控、上线后又该盯哪些指标。适合准备做 AI 应用但不知道从哪里下手的人也适合已经写了不少 CRUD、想系统梳理一遍全链路的开发者。我把整个环节拆成五块全链路的理解、技术选型的取舍、核心功能从 0 到 1 的实现、测试部署上线的关键动作、以及实战问题排查。每块内容都可能直接决定你的项目是 Demo 还是真能稳定跑下去尤其最后一部分都是常规文档里不会写的真实教训。1. 全链路到底要搞定哪些环节很多人以为 AI 软件开发的链路就是从大模型接口拿结果再加个页面展示。真做起来才发现接口只是最中间的一小段。链路前半段是“怎么把用户需求变成模型能理解、能高质量回答的输入”后半段是“模型给的输出怎么变成稳定可靠的产品功能”。前后两头比中间要复杂得多。1.1 怎么理解“全链路”以我当时做的知识库问答系统为例。表面功能很简单用户提问系统基于内部知识库给出答案。但这背后需要完成的事情包括用户问题的预处理问法是否完整、需不需要纠错、需不需要识别意图。知识库的构建文档格式五花八门PDF、Word、Markdown、扫描件怎么清洗、切片、向量化。检索逻辑开发里叫 RAG检索增强生成怎么从知识库里快速找到高相关的片段。提示词工程把检索结果与用户问题组织成模型的输入同时约束模型回答风格、长度、引用来源。流式输出模型生成一个字返一个字前端怎么接收、解析、展示中间还有断连、超时、乱码问题。成本与速度控制每次请求要花多少钱、用户最多等几秒需要做缓存、限流、并发控制。上线后的可观测性每条回答是基于哪些资料生成的、用户满意不满意、模型有没有出现幻觉。你看原本以为一个接口搞定的事实际拆出来有七八个模块。真正理解全链路就是把这条链路的每个环节都有意识地去设计而不是等项目跑起来再补窟窿。这也回答了“为什么有些 AI 项目在本地跑得很好一上线就崩”的问题。本地验证只看回答质量线上要看的是回答质量、系统稳定性、成本、并发四件事的平衡。你不可能只解决一个问题而忽略另外三个。1.2 链路里最容易被低估的三件事第一件是数据处理。很多 AI 项目的质量上限不在模型在数据。知识库里的文档如果本身就是口语化、无结构、互相矛盾的再强的模型也说不出好答案。数据清洗、去重、格式归一化这些脏活累话占掉整个项目至少 30% 的时间但绝大部分教程不会提。第二件是产品的交互设计。AI 应用的交互和传统软件不一样。用户不会精确描述问题会省略主语、用简称、甚至一句“那个不行”就发过来了。系统能不能承接住这种不完整的输入决定了用户愿不愿意继续用。也就是说你需要设计“追问、澄清、推荐问题”这些 AI 特有的交互流程。第三件是评估机制。传统软件跑通了就是跑通了AI 应用即使跑通了你也不知道它回答得到底好不好。你得建立一套评估集准备一批典型问题记录标准答案每次版本迭代后拿去跑看回答质量的提升和下降。没有这套机制你连“改版本改坏了”都不知道。这三件事没有一件是模型层的但它们才真正区分了“做出来的东西能落地”和“做个玩具”。2. 技术选型所有方案都有代价AI 软件开发的选型决策比传统项目多了一个“智能”维度模型选型、向量库选型、Agent 框架要不要上每一个选择都意味着不同的维护成本和能力边界。我的经验是先明确自己要解决的问题再用最务实的方案去解决不要追新。2.1 模型接入是选择题不是填空题模型接入不是一个填空题不是“必须用某个模型”或者“必须本地部署”。真正的问题是你的应用场景需要模型具备什么能力你能接受多大的延迟和成本。我按场景分类推荐这样比较直观场景类型推荐方向核心考虑通用对话、文案生成商用 API质量高、稳定、免运维私有数据问答RAG商用 API 好的检索关键在于检索而不在模型数据不能出内网本地部署开源模型安全合规优先高频短任务分类、抽取小模型或专用模型速度快、成本低复杂推理、代码大参数量模型能力上限决定体验我自己做企业知识库项目时最开始尝试过本地部署。结果发现硬件成本先不谈光是模型迭代、量化、推理优化就持续占用人手。后来切换到商用 API 加上一个独立的检索服务稳定性和开发速度明显提升。这就是一个典型决策本地化部署是手段不是目的。有另一个坑是模型切换。不要在代码里写死某个模型要做成可配置的。这样后续模型版本升级或者供应商调整你只需要改配置不用改代码。我当时抽象了一个统一的模型调用层只暴露几个方法底层接哪家模型都不影响上层逻辑。2.2 架构里必须提前定的几个组件做 AI 应用有几个组件一旦上线后再引入改动成本会非常大。我建议在原型阶段就把它们定下来。提示词管理系统。实践中你会发现提示词迭代非常频繁。今天调整语气明天加个约束后天又要适配新模型。如果提示词都写死在代码里每次修改都要发版。正确做法是把提示词模板放到配置中心或数据库里支持在线修改和版本回滚。知识库存储方案。如果做 RAG 应用你要决定用什么向量数据库。从开发效率看用成熟的向量数据库最省心数据量不大时先用传统数据库自带的能力甚至内存计算都够用。不用一上来就搭分布式检索集群那是数据量大到一定程度才需要考虑的事。会话上下文管理。AI 应用是有“记忆”的你需要决定记忆哪些信息、存多久、怎么截断。每次把完整历史都丢给模型费用和延迟都爆炸。合理的做法是记录用户核心意图、最近几轮对话、必要的状态变量拼成结构化的上下文。这些东西选型的时候看着不起眼真正开始写业务代码时就成了约束。先定好省得后面返工。3. 从 0 到 1 搭建核心链路这一块我以自己做过的智能写作助手项目为例把核心链路从用户输入到最终展示完整走一遍。整体分四步账号与接口层、知识处理层如果有、大模型接入层、前端展示层。每一步都有可以直接抄的代码和配置。3.1 先搭建稳定的“接入层”进入具体业务前先把接入层做好。这层包括用户身份认证、接口鉴权、计费与限流。AI 接口不像普通接口单次调用成本可能是普通接口的几十倍你不可能让用户无限次调用。我当时用服务端统一封装模型调用客户端不直接接触模型 API。所有请求先经过自己的后端后端做用户身份校验、内容安全审核、调用频率控制再做模型接口转发。服务端封装的好处很明显可以统一加缓存、统一记录日志、统一控制成本模型密钥也不会暴露到前端。一个关键细节是超时控制。模型接口的响应时间波动很大高峰期可能要几十秒。后端必须给模型请求设置合理的超时时间同时给前端出口设置一个更长的容忍时间避免网关层直接断开。我遇到过前端请求发出去之后后端等模型结果等了 30 秒结果前端网关只给 20 秒超时用户永远看到失败。排查半天才发现是两层超时配置不一致。3.2 知识库构建这一步不能省做知识库问答时很多人拿到文档就直接往向量库里面塞。这是错误做法。文档处理要经过完整的链路解析、清洗、切片、向量化、索引。以 PDF 为例。直接用文本抽取工具拿出来的内容经常是乱的表格会乱掉、多栏文本会串行。我的做法是先做版面分析把文档的标题、段落、表格位置识别出来丢弃不必要的页眉页脚再按语义边界做切片。切片是决定检索质量的核心操作。切得太大检索回来的片段主题不集中模型会被无关信息干扰切得太小上下文信息不完整模型只能看到零碎片段。我的经验是普通文档切片大小控制在 500~800 字左右。标题和正文要一起切进去保证切片有独立的语义。交叉重叠切片相邻切片之间保留 50~100 字的重叠避免语义被截断。表格数据不要硬切单独处理成文本说明或结构化键值对。向量化的时候用 embedding 模型把文本转成向量。这里有个细节文本和查询要使用同一个 embedding 模型否则检索效果会打折扣。我之前踩过这个坑文档用一款模型向量化查询时换了升级版本相似度计算变得很不稳定。后来统一模型问题消失了。3.3 大模型接入与流式输出落地模型接入本身不难难在让输出的呈现方式符合用户预期。传统 API 调用是等模型生成完再一次性返回但大模型生成上千字可能要十几秒用户看着空白页面干等体验极差。所以基本都要求流式输出。前端点击发送后后端拿到问题先做检索再把检索结果和提示词发给模型模型一边生成一边把内容推给后端后端再通过 SSEServer-Sent Events转发给前端。前端逐字展示用户第一反应是“这个系统正在思考”哪怕生成耗时 15 秒用户也不会觉得卡死。SSE 实现时有一个坑如果不做缓冲模型输出的每个字都会触发一次网络传输前端渲染会频繁抖动。正确做法是数据攒到一个完整句子或固定长度再推送比如每 100 毫秒或者每 30 个字符发一次。我实测过这个优化把前端渲染频率降低了 80%页面滚动明显顺畅。实现流式输出还有一个服务端问题要把模型的回复完整保存下来不能推完就丢。因为流式输出阶段前端拿到的是片段需要等全部完成后才会重新渲染整个对话如果你没有保存后端积累的完整内容用户刷新页面就会发现刚才的回复消失了。我当时的做法是后端在流式推送的同时同步写入会话数据库前端刷新后从后端接口拉取完整历史。3.4 前端联调的三个关键细节前端这块我说三个容易翻车的地方都是自己踩过的。第一是渲染 Markdown。模型输出的内容几乎都是 Markdown 格式包含标题、列表、代码块。如果前端直接当纯文本显示阅读体验会很差。需要用 Markdown 渲染组件来展示同时注意代码高亮和表格支持。这里有个细节流式输出时模型可能只输出半个代码块还没闭合直接把半截 Markdown 丢给渲染组件会报错。我的处理方案是等输出结束后统一渲染或者每次渲染前做一次语法补全。第二是中断处理。流式传输期间用户可能点击“停止生成”或切换对话。前端需要发送取消信号后端要响应取消并断开模型连接避免模型继续生成浪费 token。如果不做这个处理用户每点一次停止就烧一次钱月底账单会非常难看。第三是输入态的锁定。发送请求后输入框不能保持可编辑状态也不能允许用户连点多次发送。我见过真实事故用户网络卡顿连点了三下发送后端收到三份一样的请求三个一样的回答开始同时生成。解决方式是前端加请求锁同时后端对相同内容做去重缓存。4. 测试、部署与上线后的关键动作AI 应用上线前的测试方式和传统软件很不一样。传统软件主要测逻辑正确性和边界条件AI 应用还要测回答质量、延迟稳定性、成本消耗这些额外维度。部署也不是跑起来就行得有监控、有日志、有评估。4.1 自动化测试怎么设计我给 AI 项目建立了两层测试体系。第一层是接口逻辑测试。保证后端各个模块的输入输出符合预期。比如知识库切片服务接收一个 PDF产出的切片数量和各片长度是否落在合理范围检索服务对空查询、超长查询、特殊字符查询是否都能正常返回。这层测试用常规的测试框架就能完成关键是把它纳入持续集成每次提交代码自动跑。第二层是回答质量评估测试。准备一组评估集包含典型用户问题、标准答案要点、预期引用来源。每次迭代后跑一遍评估集用规则判断回答是否覆盖要点、是否包含来源引用。更高级一点的做法是让大模型充当裁判对回答打分。实测下来大模型评估和自己手动评估的相关性在 80% 以上完全可以作为快速回归的手段。有一个反直觉的现象评价集的问题数量不在多而在覆盖维度。我一开始放了 300 个问题跑一遍要花很多时间和钱后来精简到 60 个刻意覆盖不同提问风格、不同知识板块、不同困难程度反而能更快暴露改动带来的退化。4.2 性能优化延迟和成本怎么平衡AI 应用的延迟优化和成本优化是一对矛盾体要做的是找到平衡点。延迟方面最大的开销通常不在模型调用本身而在检索和上下文拼接。如果你的检索逻辑里包含多个环节召回、重排、过滤每个环节都有网络往返累计延迟很容易到 2 秒以上。我当时的优化做法是把检索中的重排环节从“所有结果都重排”改成“Top 前 50 重排”后 50 名的结果相关性本来就低重排收益甚微砍掉后延迟直接降了 40%。成本方面最有效的措施是缓存。用户问的问题通常会有很大一部分是重复的。我在服务端做了一层语义缓存把用户问题向量化跟最近 24 小时的问题向量做相似度比对超过阈值就直接返回缓存结果不调用模型。实测这个方案能省下 20% 左右的调用费用高峰期效果更明显。还有一个常见问题是并发抖动。模型服务的并发承载能力有限瞬时流量上来时会大量超时。解决方案是加一层请求队列用户请求先排队后端按照固定速率放行到模型服务前端展示队列状态。这样虽然用户可能多等几秒但不会出现大面积请求失败。上线后确实有用户反馈变慢了但“慢但可用”远比“快但报错”要好。4.3 部署方案与日志监控AI 应用的部署和普通应用没本质区别多出来的工作集中在三块模型服务的部署或外联管理、动态配置的下发、回答内容的审计。如果你用的是商用 API部署时只需要在环境变量里区分不同环境的 API 密钥。这里要注意密钥安全管理绝对不能把生产密钥泄露到前端或仓库里。我之前见过同事把密钥直接提交到代码仓库好在发现及时没有造成损失后来强制加了密钥扫描工具。如果你本地部署模型部署的复杂度会明显上升。推理资源要独立于业务服务避免模型推理的显存占用拖垮业务服务模型服务要支持多副本水平扩展同时做好显存和并发的关系计算。比如一张卡能同时跑 4 个推理请求那你部署 3 个副本就能支撑 12 并发再多就得扩容。日志监控方面除了常规的业务日志和性能指标AI 应用必须额外记录三样东西每一次请求的完整出入参方便出问题时候回溯模型当时看到了什么。每一条回答的耗时和 token 消耗这是成本核算的基础。用户对回答的反馈动作比如点赞、点踩、复制、删除用来评估真实满意度。我上线初期就发现反馈数据极其关键。一个回答在技术指标上没有问题但用户点了踩说明回答没有命中用户心中问的。排查后发现是语义理解偏了后来在提示词里增加了一个“识别用户问题中可能存在的歧义”的指令点踩率明显下降。这类优化靠代码 review 发现不了只能靠监控数据驱动。5. 实战踩坑实录这一部分分享几个我在实战中真正遇到、排查耗时最长的问题。每个问题都花了我不少时间写出来希望你能绕开。5.1 上下文管理导致的 Token 溢出做对话类应用时我把用户对话历史完整传给模型。一开始没问题多轮之后就慢慢变慢最后直接报错提示超出最大 Token 限制。排查后确认是上下文无限膨胀导致请求体越来越大。优化方案分三层。第一层限制对话轮数会话最长保留最近 20 轮更早的内容不再传入。第二层做上下文摘要每隔几轮对之前的对话做一次要点提取用摘要替代原始内容。第三层只传与当前问题相关的历史消息通过设置角色字段和消息 ID 过滤掉无关轮次。优化之后长对话的首字延迟从原来的 8 秒降到 2 秒以内。5.2 流式输出乱序与断连有一次上线后发现用户反馈回答内容经常缺字、顺序错乱有时候最后一大段直接消失了。初步怀疑是前端展示问题后来追查发现是后端在流式转发时发生数据竞争。多个并发请求复用了同一个缓冲变量导致内容互相穿插。修复方式是给每个请求独立的缓冲区并严格控制读取和推送的锁。断连问题则是因为模型端的发送频率与服务端读取频率不匹配服务端读取过慢时模型端认定连接失效主动断开。处理方式是把接收缓冲调大同时减慢前端的推送频率确保模型端不会因为阻塞而超时断开。5.3 相同问题短时间重复请求上线初期我发现同一条内容用户的重复点击率很高模型调用量远超预期。前面提到过这是前端没有做请求锁导致的。后来前端加了发送后按钮禁用后端又加了语义缓存双层防重复调用量立刻降下来。建议每个人都把这两层做好不要等到账单吓一跳再回头补。5.4 模型“幻觉”问题的系统性治理所谓幻觉就是模型一本正经地胡说八道。知识库问答里最常见的情况是知识库里没有答案模型却会根据自己学到的知识生成一个像模像样的回答。这在产品里是致命的用户会认为系统在编造。治理思路从两个方向同时做。一个是提示词层面强制模型“如果你没有在知识库中找到答案请直接回答不知道不要编造”。另一个是程序层面检索结果和提示词一起发送时一旦相关性得分低于某个阈值后端直接拦截不调用生成模型返回预设话术“抱歉资料库中暂未找到相关内容”。这个阈值需要根据验证集反复调整。调太严很容易误杀有效问题调太松拦截形同虚设。我还加了一层“引用来源检验”要求模型回答时必须包含来自知识库的片段编号回答末尾展示来源用户可以直接核查。幻觉不可能完全清零但通过这三层手段我当时项目的幻觉率从初版的 15% 以上降到 3% 左右已经达到可用的标准。很多人做 AI 项目的时候习惯性盯着模型参数和新技术不放但真正决定项目成败的往往是数据处理、交互细节、成本控制、可观测性这些“不性感”的环节。我把这次全链路实战写出来也是希望后来的开发者别再把时间浪费在我踩过的坑上。如果你的项目也在路上建议先把链路里的基础环节打牢再去追逐更大的模型。最后的体验差距通常不是模型决定的而是工程细节决定的。 
长河君 · 2026/10/23 5:00:37 · 阅读 1.2k AI应用开发全链路实战：从技术选型到部署避坑指南
先说结论AI 软件开发没那么玄乎但也绝对不是调一个接口那么简单。我自己从零到一做过两个完整的 AI 应用项目包括一个企业内部知识库问答系统和一个面向 C 端的智能写作助手一路踩过来的坑比写业务代码多得多。这篇博文把我的完整实操链路拆开揉碎讲清楚项目怎么规划、模型怎么选、前后端怎么设计、同时并发怎么控、上线后又该盯哪些指标。适合准备做 AI 应用但不知道从哪里下手的人也适合已经写了不少 CRUD、想系统梳理一遍全链路的开发者。我把整个环节拆成五块全链路的理解、技术选型的取舍、核心功能从 0 到 1 的实现、测试部署上线的关键动作、以及实战问题排查。每块内容都可能直接决定你的项目是 Demo 还是真能稳定跑下去尤其最后一部分都是常规文档里不会写的真实教训。1. 全链路到底要搞定哪些环节很多人以为 AI 软件开发的链路就是从大模型接口拿结果再加个页面展示。真做起来才发现接口只是最中间的一小段。链路前半段是“怎么把用户需求变成模型能理解、能高质量回答的输入”后半段是“模型给的输出怎么变成稳定可靠的产品功能”。前后两头比中间要复杂得多。1.1 怎么理解“全链路”以我当时做的知识库问答系统为例。表面功能很简单用户提问系统基于内部知识库给出答案。但这背后需要完成的事情包括用户问题的预处理问法是否完整、需不需要纠错、需不需要识别意图。知识库的构建文档格式五花八门PDF、Word、Markdown、扫描件怎么清洗、切片、向量化。检索逻辑开发里叫 RAG检索增强生成怎么从知识库里快速找到高相关的片段。提示词工程把检索结果与用户问题组织成模型的输入同时约束模型回答风格、长度、引用来源。流式输出模型生成一个字返一个字前端怎么接收、解析、展示中间还有断连、超时、乱码问题。成本与速度控制每次请求要花多少钱、用户最多等几秒需要做缓存、限流、并发控制。上线后的可观测性每条回答是基于哪些资料生成的、用户满意不满意、模型有没有出现幻觉。你看原本以为一个接口搞定的事实际拆出来有七八个模块。真正理解全链路就是把这条链路的每个环节都有意识地去设计而不是等项目跑起来再补窟窿。这也回答了“为什么有些 AI 项目在本地跑得很好一上线就崩”的问题。本地验证只看回答质量线上要看的是回答质量、系统稳定性、成本、并发四件事的平衡。你不可能只解决一个问题而忽略另外三个。1.2 链路里最容易被低估的三件事第一件是数据处理。很多 AI 项目的质量上限不在模型在数据。知识库里的文档如果本身就是口语化、无结构、互相矛盾的再强的模型也说不出好答案。数据清洗、去重、格式归一化这些脏活累话占掉整个项目至少 30% 的时间但绝大部分教程不会提。第二件是产品的交互设计。AI 应用的交互和传统软件不一样。用户不会精确描述问题会省略主语、用简称、甚至一句“那个不行”就发过来了。系统能不能承接住这种不完整的输入决定了用户愿不愿意继续用。也就是说你需要设计“追问、澄清、推荐问题”这些 AI 特有的交互流程。第三件是评估机制。传统软件跑通了就是跑通了AI 应用即使跑通了你也不知道它回答得到底好不好。你得建立一套评估集准备一批典型问题记录标准答案每次版本迭代后拿去跑看回答质量的提升和下降。没有这套机制你连“改版本改坏了”都不知道。这三件事没有一件是模型层的但它们才真正区分了“做出来的东西能落地”和“做个玩具”。2. 技术选型所有方案都有代价AI 软件开发的选型决策比传统项目多了一个“智能”维度模型选型、向量库选型、Agent 框架要不要上每一个选择都意味着不同的维护成本和能力边界。我的经验是先明确自己要解决的问题再用最务实的方案去解决不要追新。2.1 模型接入是选择题不是填空题模型接入不是一个填空题不是“必须用某个模型”或者“必须本地部署”。真正的问题是你的应用场景需要模型具备什么能力你能接受多大的延迟和成本。我按场景分类推荐这样比较直观场景类型推荐方向核心考虑通用对话、文案生成商用 API质量高、稳定、免运维私有数据问答RAG商用 API 好的检索关键在于检索而不在模型数据不能出内网本地部署开源模型安全合规优先高频短任务分类、抽取小模型或专用模型速度快、成本低复杂推理、代码大参数量模型能力上限决定体验我自己做企业知识库项目时最开始尝试过本地部署。结果发现硬件成本先不谈光是模型迭代、量化、推理优化就持续占用人手。后来切换到商用 API 加上一个独立的检索服务稳定性和开发速度明显提升。这就是一个典型决策本地化部署是手段不是目的。有另一个坑是模型切换。不要在代码里写死某个模型要做成可配置的。这样后续模型版本升级或者供应商调整你只需要改配置不用改代码。我当时抽象了一个统一的模型调用层只暴露几个方法底层接哪家模型都不影响上层逻辑。2.2 架构里必须提前定的几个组件做 AI 应用有几个组件一旦上线后再引入改动成本会非常大。我建议在原型阶段就把它们定下来。提示词管理系统。实践中你会发现提示词迭代非常频繁。今天调整语气明天加个约束后天又要适配新模型。如果提示词都写死在代码里每次修改都要发版。正确做法是把提示词模板放到配置中心或数据库里支持在线修改和版本回滚。知识库存储方案。如果做 RAG 应用你要决定用什么向量数据库。从开发效率看用成熟的向量数据库最省心数据量不大时先用传统数据库自带的能力甚至内存计算都够用。不用一上来就搭分布式检索集群那是数据量大到一定程度才需要考虑的事。会话上下文管理。AI 应用是有“记忆”的你需要决定记忆哪些信息、存多久、怎么截断。每次把完整历史都丢给模型费用和延迟都爆炸。合理的做法是记录用户核心意图、最近几轮对话、必要的状态变量拼成结构化的上下文。这些东西选型的时候看着不起眼真正开始写业务代码时就成了约束。先定好省得后面返工。3. 从 0 到 1 搭建核心链路这一块我以自己做过的智能写作助手项目为例把核心链路从用户输入到最终展示完整走一遍。整体分四步账号与接口层、知识处理层如果有、大模型接入层、前端展示层。每一步都有可以直接抄的代码和配置。3.1 先搭建稳定的“接入层”进入具体业务前先把接入层做好。这层包括用户身份认证、接口鉴权、计费与限流。AI 接口不像普通接口单次调用成本可能是普通接口的几十倍你不可能让用户无限次调用。我当时用服务端统一封装模型调用客户端不直接接触模型 API。所有请求先经过自己的后端后端做用户身份校验、内容安全审核、调用频率控制再做模型接口转发。服务端封装的好处很明显可以统一加缓存、统一记录日志、统一控制成本模型密钥也不会暴露到前端。一个关键细节是超时控制。模型接口的响应时间波动很大高峰期可能要几十秒。后端必须给模型请求设置合理的超时时间同时给前端出口设置一个更长的容忍时间避免网关层直接断开。我遇到过前端请求发出去之后后端等模型结果等了 30 秒结果前端网关只给 20 秒超时用户永远看到失败。排查半天才发现是两层超时配置不一致。3.2 知识库构建这一步不能省做知识库问答时很多人拿到文档就直接往向量库里面塞。这是错误做法。文档处理要经过完整的链路解析、清洗、切片、向量化、索引。以 PDF 为例。直接用文本抽取工具拿出来的内容经常是乱的表格会乱掉、多栏文本会串行。我的做法是先做版面分析把文档的标题、段落、表格位置识别出来丢弃不必要的页眉页脚再按语义边界做切片。切片是决定检索质量的核心操作。切得太大检索回来的片段主题不集中模型会被无关信息干扰切得太小上下文信息不完整模型只能看到零碎片段。我的经验是普通文档切片大小控制在 500~800 字左右。标题和正文要一起切进去保证切片有独立的语义。交叉重叠切片相邻切片之间保留 50~100 字的重叠避免语义被截断。表格数据不要硬切单独处理成文本说明或结构化键值对。向量化的时候用 embedding 模型把文本转成向量。这里有个细节文本和查询要使用同一个 embedding 模型否则检索效果会打折扣。我之前踩过这个坑文档用一款模型向量化查询时换了升级版本相似度计算变得很不稳定。后来统一模型问题消失了。3.3 大模型接入与流式输出落地模型接入本身不难难在让输出的呈现方式符合用户预期。传统 API 调用是等模型生成完再一次性返回但大模型生成上千字可能要十几秒用户看着空白页面干等体验极差。所以基本都要求流式输出。前端点击发送后后端拿到问题先做检索再把检索结果和提示词发给模型模型一边生成一边把内容推给后端后端再通过 SSEServer-Sent Events转发给前端。前端逐字展示用户第一反应是“这个系统正在思考”哪怕生成耗时 15 秒用户也不会觉得卡死。SSE 实现时有一个坑如果不做缓冲模型输出的每个字都会触发一次网络传输前端渲染会频繁抖动。正确做法是数据攒到一个完整句子或固定长度再推送比如每 100 毫秒或者每 30 个字符发一次。我实测过这个优化把前端渲染频率降低了 80%页面滚动明显顺畅。实现流式输出还有一个服务端问题要把模型的回复完整保存下来不能推完就丢。因为流式输出阶段前端拿到的是片段需要等全部完成后才会重新渲染整个对话如果你没有保存后端积累的完整内容用户刷新页面就会发现刚才的回复消失了。我当时的做法是后端在流式推送的同时同步写入会话数据库前端刷新后从后端接口拉取完整历史。3.4 前端联调的三个关键细节前端这块我说三个容易翻车的地方都是自己踩过的。第一是渲染 Markdown。模型输出的内容几乎都是 Markdown 格式包含标题、列表、代码块。如果前端直接当纯文本显示阅读体验会很差。需要用 Markdown 渲染组件来展示同时注意代码高亮和表格支持。这里有个细节流式输出时模型可能只输出半个代码块还没闭合直接把半截 Markdown 丢给渲染组件会报错。我的处理方案是等输出结束后统一渲染或者每次渲染前做一次语法补全。第二是中断处理。流式传输期间用户可能点击“停止生成”或切换对话。前端需要发送取消信号后端要响应取消并断开模型连接避免模型继续生成浪费 token。如果不做这个处理用户每点一次停止就烧一次钱月底账单会非常难看。第三是输入态的锁定。发送请求后输入框不能保持可编辑状态也不能允许用户连点多次发送。我见过真实事故用户网络卡顿连点了三下发送后端收到三份一样的请求三个一样的回答开始同时生成。解决方式是前端加请求锁同时后端对相同内容做去重缓存。4. 测试、部署与上线后的关键动作AI 应用上线前的测试方式和传统软件很不一样。传统软件主要测逻辑正确性和边界条件AI 应用还要测回答质量、延迟稳定性、成本消耗这些额外维度。部署也不是跑起来就行得有监控、有日志、有评估。4.1 自动化测试怎么设计我给 AI 项目建立了两层测试体系。第一层是接口逻辑测试。保证后端各个模块的输入输出符合预期。比如知识库切片服务接收一个 PDF产出的切片数量和各片长度是否落在合理范围检索服务对空查询、超长查询、特殊字符查询是否都能正常返回。这层测试用常规的测试框架就能完成关键是把它纳入持续集成每次提交代码自动跑。第二层是回答质量评估测试。准备一组评估集包含典型用户问题、标准答案要点、预期引用来源。每次迭代后跑一遍评估集用规则判断回答是否覆盖要点、是否包含来源引用。更高级一点的做法是让大模型充当裁判对回答打分。实测下来大模型评估和自己手动评估的相关性在 80% 以上完全可以作为快速回归的手段。有一个反直觉的现象评价集的问题数量不在多而在覆盖维度。我一开始放了 300 个问题跑一遍要花很多时间和钱后来精简到 60 个刻意覆盖不同提问风格、不同知识板块、不同困难程度反而能更快暴露改动带来的退化。4.2 性能优化延迟和成本怎么平衡AI 应用的延迟优化和成本优化是一对矛盾体要做的是找到平衡点。延迟方面最大的开销通常不在模型调用本身而在检索和上下文拼接。如果你的检索逻辑里包含多个环节召回、重排、过滤每个环节都有网络往返累计延迟很容易到 2 秒以上。我当时的优化做法是把检索中的重排环节从“所有结果都重排”改成“Top 前 50 重排”后 50 名的结果相关性本来就低重排收益甚微砍掉后延迟直接降了 40%。成本方面最有效的措施是缓存。用户问的问题通常会有很大一部分是重复的。我在服务端做了一层语义缓存把用户问题向量化跟最近 24 小时的问题向量做相似度比对超过阈值就直接返回缓存结果不调用模型。实测这个方案能省下 20% 左右的调用费用高峰期效果更明显。还有一个常见问题是并发抖动。模型服务的并发承载能力有限瞬时流量上来时会大量超时。解决方案是加一层请求队列用户请求先排队后端按照固定速率放行到模型服务前端展示队列状态。这样虽然用户可能多等几秒但不会出现大面积请求失败。上线后确实有用户反馈变慢了但“慢但可用”远比“快但报错”要好。4.3 部署方案与日志监控AI 应用的部署和普通应用没本质区别多出来的工作集中在三块模型服务的部署或外联管理、动态配置的下发、回答内容的审计。如果你用的是商用 API部署时只需要在环境变量里区分不同环境的 API 密钥。这里要注意密钥安全管理绝对不能把生产密钥泄露到前端或仓库里。我之前见过同事把密钥直接提交到代码仓库好在发现及时没有造成损失后来强制加了密钥扫描工具。如果你本地部署模型部署的复杂度会明显上升。推理资源要独立于业务服务避免模型推理的显存占用拖垮业务服务模型服务要支持多副本水平扩展同时做好显存和并发的关系计算。比如一张卡能同时跑 4 个推理请求那你部署 3 个副本就能支撑 12 并发再多就得扩容。日志监控方面除了常规的业务日志和性能指标AI 应用必须额外记录三样东西每一次请求的完整出入参方便出问题时候回溯模型当时看到了什么。每一条回答的耗时和 token 消耗这是成本核算的基础。用户对回答的反馈动作比如点赞、点踩、复制、删除用来评估真实满意度。我上线初期就发现反馈数据极其关键。一个回答在技术指标上没有问题但用户点了踩说明回答没有命中用户心中问的。排查后发现是语义理解偏了后来在提示词里增加了一个“识别用户问题中可能存在的歧义”的指令点踩率明显下降。这类优化靠代码 review 发现不了只能靠监控数据驱动。5. 实战踩坑实录这一部分分享几个我在实战中真正遇到、排查耗时最长的问题。每个问题都花了我不少时间写出来希望你能绕开。5.1 上下文管理导致的 Token 溢出做对话类应用时我把用户对话历史完整传给模型。一开始没问题多轮之后就慢慢变慢最后直接报错提示超出最大 Token 限制。排查后确认是上下文无限膨胀导致请求体越来越大。优化方案分三层。第一层限制对话轮数会话最长保留最近 20 轮更早的内容不再传入。第二层做上下文摘要每隔几轮对之前的对话做一次要点提取用摘要替代原始内容。第三层只传与当前问题相关的历史消息通过设置角色字段和消息 ID 过滤掉无关轮次。优化之后长对话的首字延迟从原来的 8 秒降到 2 秒以内。5.2 流式输出乱序与断连有一次上线后发现用户反馈回答内容经常缺字、顺序错乱有时候最后一大段直接消失了。初步怀疑是前端展示问题后来追查发现是后端在流式转发时发生数据竞争。多个并发请求复用了同一个缓冲变量导致内容互相穿插。修复方式是给每个请求独立的缓冲区并严格控制读取和推送的锁。断连问题则是因为模型端的发送频率与服务端读取频率不匹配服务端读取过慢时模型端认定连接失效主动断开。处理方式是把接收缓冲调大同时减慢前端的推送频率确保模型端不会因为阻塞而超时断开。5.3 相同问题短时间重复请求上线初期我发现同一条内容用户的重复点击率很高模型调用量远超预期。前面提到过这是前端没有做请求锁导致的。后来前端加了发送后按钮禁用后端又加了语义缓存双层防重复调用量立刻降下来。建议每个人都把这两层做好不要等到账单吓一跳再回头补。5.4 模型“幻觉”问题的系统性治理所谓幻觉就是模型一本正经地胡说八道。知识库问答里最常见的情况是知识库里没有答案模型却会根据自己学到的知识生成一个像模像样的回答。这在产品里是致命的用户会认为系统在编造。治理思路从两个方向同时做。一个是提示词层面强制模型“如果你没有在知识库中找到答案请直接回答不知道不要编造”。另一个是程序层面检索结果和提示词一起发送时一旦相关性得分低于某个阈值后端直接拦截不调用生成模型返回预设话术“抱歉资料库中暂未找到相关内容”。这个阈值需要根据验证集反复调整。调太严很容易误杀有效问题调太松拦截形同虚设。我还加了一层“引用来源检验”要求模型回答时必须包含来自知识库的片段编号回答末尾展示来源用户可以直接核查。幻觉不可能完全清零但通过这三层手段我当时项目的幻觉率从初版的 15% 以上降到 3% 左右已经达到可用的标准。很多人做 AI 项目的时候习惯性盯着模型参数和新技术不放但真正决定项目成败的往往是数据处理、交互细节、成本控制、可观测性这些“不性感”的环节。我把这次全链路实战写出来也是希望后来的开发者别再把时间浪费在我踩过的坑上。如果你的项目也在路上建议先把链路里的基础环节打牢再去追逐更大的模型。最后的体验差距通常不是模型决定的而是工程细节决定的。