不少朋友私信问我同一个问题现在“AI全栈开发”这个词被各种文章说到快要变味到底什么才叫 AI 全栈是会用提示词把几个接口串起来还是说要自己微调模型、部署推理环境才配叫全栈我做了几年 AI 应用落地也带团队交付过几条完整产品线我的答案是AI 全栈的本质是把自己当成一个能把“模型能力”融入现有工程体系的人而不是只会给模型写提示词的人。这篇文章不是从零教你某一门框架的教程而是把我踩过的坑、沉淀下来的选型原则和工程习惯完整梳理一遍。适合这几类人看已经开始用大模型开发应用但总觉得自己只在“拼接口”的开发者团队里负责 AI 功能落地的技术负责人以及想系统补齐 AI 工程薄弱环节的产品技术同学。我会尽量用真实项目里遇到的案例来讲少讲空洞概念多给可落地的方案。1. 先给“AI 全栈开发”画个范围你到底在做什么很多人一听全栈第一反应是前端、后端、数据库、部署都会。但在 AI 开发里全栈的范围和传统 web 开发有本质区别核心差在“不确定性”。普通代码输入相同输出几乎一定相同大模型应用同样的用户问题今天和明天可能给出完全不同的答案。1.1 从玩提示词到交付系统的分界线我见过太多“demo 很惊艳上线就完蛋”的项目。一个典型场景开发者在 Jupyter Notebook 或者某个在线 Playground 里调试提示词效果很好然后把它塞进一个 FastAPI 服务里就对外发布了。结果上线后用户问法稍微绕一点或者带着历史上下文追问一句回答就偏了。问题不在模型在于你没有为“不确定性”设计边界。传统全栈开发教我们定义接口、定义数据库表、定义页面状态所有数据流转是可预期、可测试的。到了 AI 应用里模型的输出就是不可预期的。所以 AI 全栈开发的第一课不是学 LangChain而是学会给所有不可预期的环节建“堤坝”。这个堤坝包括几个部分对模型输入的规范化、对模型输出的校验、对调用失败的兜底、对上下文超限的处理、对敏感内容的过滤。不能写一个messages.append(user_input)就完事。1.2 我梳理的 AI 全栈六层结构我给团队新人讲 AI 全栈时通常按下面六层来拆每一层都有明确的交付物第一层是交互层包括 Web 页面、小程序、桌面端或者 IM 机器人主要处理流式渲染、多轮会话、富文本和语音等交互形态。 第二层是会话与上下文层负责维护对话历史、记忆、用户画像以及把长文本做摘要压缩。这一层说白了就是传统 web 开发里的状态管理只是它管理的对象不是订单状态而是“一段持续变化的对话状态”。 第三层是模型接入层解决怎么连模型的问题是直连各家 API还是通过统一网关如何管理 Key、限流、成本如何做模型切换和降级这一层是 AI 全栈最容易被忽略但最影响稳定性的地方。 第四层是智能编排层这就是大家常说的 Agent、工作流、RAG 检索。它的职责是决定“什么时候调模型、什么时候调工具、什么时候查知识库”。 第五层是业务与数据层也就是传统后端的那些事订单、用户、支付、积分、内容管理。AI 不是悬空的它最终要融入业务数据。 第六层是治理与交付层包含测试、监控、日志、审计、安全合规。这层决定你上线后敢不敢睡觉。你能感觉到第二、三、六层缺一不可但大部分教程只讲第四层。这也是很多项目从 demo 到产品中间那道跨不过去的坎的真正原因。2. 模型接入层选型为什么我坚持用统一模型网关而不是直连你去读大模型服务商的文档他们会很亲切地给你一个 Python SDK三行代码就能调通。好多中小团队就这样开始了直连、直发。前两周一切顺利第三周业务方说“我们要再接入另一个模型的接口”你发现代码里到处散落着各家 SDK 的调用错误处理风格还不一样这个模型超时要重试三次那个模型要传temperature却要求浮点数还有个模型接口对整型非常严格。这时候你才意识到模型接入应该有一个统一层。我现在所有项目都默认接 LiteLLM 作为模型网关不只是为了转发请求而是为了三个实实在在的价值第一是切换成本趋近于零。如果你在代码里写死了一个模型品牌的方法想换另一个模型至少要改接口路径、鉴权方式、参数风格。但通过统一网关底层换了供应商你的业务代码几乎不需要动只改配置中心里的一个模型路由表。第二是审计和成本能集中统计。企业里做 AI 功能老板一定会问这个月调用花了多少钱哪个业务线消耗最大直连多家服务商的时候你要自己写统计逻辑用了统一网关请求日志、Token 统计、失败率这些信息天然集中在一处,省了我大量做报表的时间。第三是限流和降级有地方落地。没做过生产环境的人可能意识不到大模型的接口并发一高服务商侧就开始返回 429。你的服务需要有一个统一的“熔断开关”。我见过一个真实事故销售团队用 AI 写跟进邮件某个下午模型服务商波动五分钟内几百个请求全部超时销售直接炸锅。后来我们加了网关层设置了 50% 流量降级到备用模型再遇到波动用户几乎无感。我给新项目的默认建议是这样本地开发和测试可以直连模型没关系一旦进入 staging 或生产强制走统一模型网关。这不复杂但价值极高。2.1 自建推理和云端 API不要被“私有化部署”四个字绑架有不少团队在模型接入上纠结一件事要不要自己买卡部署开源模型。我的看法很现实先看你的业务规模。并发量只有每秒几次对话长度又不太长自建推理的成本远高于按量付费的云端 API。只有当你有稳定的高并发、强数据合规要求、或者定制微调需求时自建才值得。另一个常见误区是“开源模型 免费”。你算算卡、电、机房、算法工程师、运维的人力随便一个中等规模的推理服务月成本都在几万以上。而云端 API 按量付费在业务早期可能一个月只花几千。做技术选型不要被“私有化部署”这四个字绑架先算账再决定。2.2 多模型路由的降级策略怎么设计统一网关还有一个隐藏收益它让你天然具备了多模型容灾能力。我目前在生产环境使用的降级策略是三级第一级用当前效果最好的旗舰模型用于核心生成任务接受它的高成本。第二级用一个质量略低但稳定便宜的模型当旗舰模型超时或返回异常时自动切换。第三级是一个兜底规则比如返回固定话术或引导用户稍后再试确保用户不会看到空白页面。这里有一个关键细节降级不是把请求简单转发给另一个模型就完了。不同模型对提示词的理解能力有差异直接拿同一个提示词发给弱模型输出质量可能崩。我会在网关后面配一套按模型版本区分的提示词模板降级时自动切换对应的模板。这件事做好以后用户几乎感知不到底层模型换了。3. 提示词与上下文的工程化从“写一段话”到“维护一份配置”好多开发者对提示词的理解停留在“写一段话让模型听我的话”但 AI 全栈开发里的提示词本质上是一份要长期维护、会被多版本迭代、可能影响线上所有用户的配置。你想想后端一个接口的请求参数如果变了你要走评审、测试、发布流程那提示词牵一发而动全身凭什么不做同样管理3.1 提示词作为代码进 Git 仓库我现在的团队提示词全部作为项目代码的一部分进 Git 仓库。系统提示词、少样本示例、输出格式约束、风格限定都拆成独立文件而不是嵌在 Python 字符串里。原因很简单提示词会越来越长长到在代码里会污染业务逻辑提示词必须支持版本对比出问题的时候能知道“上周改了哪句话导致效果下降”。同时提示词文件里所有变量都走模板引擎渲染不允许手工拼接用户输入。比如这样system_prompt render_template(prompts/sales_email.txt, { customer_profile: profile, product_info: product, today: date })别小看这一步。直接在代码里写f你好{user_input}你是一名销售……三个月后你根本分不清哪部分是业务逻辑哪部分是可变的提示词参数。3.2 上下文管理是性能瓶颈不只是技术问题聊到上下文很多人的第一反应是“模型上下文窗口不够”。但实际项目里更大的问题是你把太多东西塞进上下文导致模型反应慢、成本高、而且容易被无关信息干扰。我给上下文管理定了一个“最小必要原则”能不放进去的尽量不放。用户的历史会话如果超过阈值先做摘要而不是把原始的五十轮聊天记录全丢进去。知识库检索只取相关的 top 5 个片段不要一次检索 50 个片段全塞进去。用户的无关属性比如注册时间、设备型号除非对生成结果有影响否则不要进上下文。有一回我们处理一个客服智能回复项目刚开始把用户的订单信息、浏览记录、历史投诉一股脑全放进提示词模型回复确实“看起来个性化”但延迟从 1 秒涨到 5 秒费用翻了三倍。后来我们改成只放与当前问题相关的订单摘要延迟回到 1.5 秒用户反馈几乎没变。这说明什么上下文不是越多越好是越准越好。3.3 输出要结构化别让模型自由发挥另一个工程化重点强制模型输出结构化内容。你调用一个“智能信息抽取”功能如果让模型随便回答一段话你的后续代码就得去解析一段自然语言那太脆弱了。我现在所有“非对话类”的生成任务都会要求模型输出符合 JSON Schema 的结果并且在代码侧用pydantic做校验校验失败自动触发一次重试或降级。比如让模型从一篇长文里提取摘要和三个关键词定义好输出结构然后接收解析。这样下游逻辑只需要处理标准字段不需要判断“模型的第几句话才是标题”。这是把不确定性转化为可控性的关键一步。4. 从 Demo 到生产智能编排不要迷信 Agent你打开任何一个 AI 社区都能看到关于 Agent 的赞美。自动规划、自动调工具、自主完成复杂任务听着非常美好。但我不客气地说一句大部分业务场景根本不需要一个完全自主的 Agent你需要的是一个可追踪的确定性工作流。4.1 什么时候用工作流什么时候才考虑 Agent我做了一个很简单的判断标准如果任务的步骤相对固定例如先查订单、再判断用户情绪、再生成回复——那么用工作流每一步都是预先定义好的可测试、可观测。如果任务是开放性的例如“帮我把这个 Excel 做成一份分析报告”你不能预先穷举所有步骤这时候才考虑让模型自主规划。团队里经常出现一个现象有人用 LangGraph 搭了一个看起来很高级的 Agent节点和条件分支有十几个最后效果不稳定还难调试。你问他为什么不用普通代码写一个if...else工作流他答不上来。过度自动化就是给自己挖坑。Agent 的价值是处理未知路径代价是难以预测。如果你的路径基本已知就直接用代码把路径写死然后把模型放在每个节点上去完成局部判断这是性价比最高的方式。4.2 工具调用是智能编排的基础设施真正复杂的 AI 应用里模型需要通过工具调用Function Calling去查数据库、调 API、执行代码。我把它称为AI 与后端世界的接缝。这个接缝最容易出错也最需要设计。我现在给工具调用定了几条硬规矩第一工具名和参数名要稳定。上线后的工具接口不要随意改名字因为改了名字模型通过提示词生成参数时命中率会明显下降。与其改工具名不如新增一个版本工具。 第二每个工具都要有清晰的描述说明这个工具是干什么的、什么时候用、什么时候不要用。模型靠这个描述来决定是否调用工具描述写得含糊模型就会乱调。 第三工具内部要做权限控制。模型能接触到的数据范围要得到控制。你让模型“查询用户订单”没问题但如果你不做行级权限隔离它可能会查询到任意用户的订单这在真实场景里是安全事故。我见过一个事故内部知识库 Agent 接了企业的文档搜索工具但工具没有做权限过滤所有员工都能通过模型间接搜索 HR 部门文档。这属于工程漏洞不是模型的责任。模型只是执行者权限控制得靠你在工具层实现。4.3 状态持久化和重试机制如果 Agent 是一次性回答不需要考虑状态但只要是多轮任务状态持久化就是绕不开的。举个例子用户说“帮我写一份周报”模型生成了草稿但你又希望用户可以在下一轮里说“把第二部分改得短一点”。这时候草稿内容必须存在某个存储里而不只是模型对话历史里的一个字符串。我用的是 Redis 或 PostgreSQL 存 session state配合一个版本号每次修改生成一个新版本。这跟普通后端的状态管理没有本质区别区别只是“状态变化由谁触发”传统应用是用户在页面点击触发Agent 应用是模型决策后调用工具触发。重试机制也要设计。模型调用可能因为网络、限流、内容安全策略等原因失败你不能让 Agent 像普通接口那样一失败就抛 500。我推荐使用指数退避重试最多三次每次间隔递增。同时给整个 Agent 执行过程设置一个总超时比如 60 秒超过就终止并返回可读的提示信息。否则一个失控的 Agent 可能在你的服务器上空转好几分钟。5. RAG 检索增强的工程化知识库不是“连个向量库就完事”几乎每个 AI 全栈项目都会遇到知识库问答需求。好多方案写得很简单把文档切成块丢进向量数据库用户提问时做相似度检索再把命中的内容塞进提示词。但实际效果往往差强人意问题出在“切块”这个环节。5.1 分块策略远比你想的重要文档怎么切直接决定了检索效果。按固定 500 字切块简单粗暴但一个完整的业务概念可能会被拆成两半导致上下文断裂。我现在的做法是优先按照文档结构切比如 Markdown 的一级标题、二级标题作为一个块的边界如果结构不明显再用固定长度切但保留一定的重叠区域比如前后各重叠 80 个字符保证语义连贯。块的长度也需要经验。太短上下文信息不足不好用太长检索套入提示词会超 Token 限制。我的经验是一般技术文档 500 到 800 字一个块比较合适。像法律合同、论文那种长段落可能需要进一步做语义句子级切分这属于进阶话题初期不必过度设计。5.2 混合检索比单向量检索靠谱纯向量检索有一个天然问题它擅长语义相似但不擅长关键词精确匹配。比如用户搜“合同编号 JX2024001”向量检索可能对数字串不敏感返回一堆合同相关的自然语言描述但用户要的偏偏就是那个编号。这时候关键是补充关键词检索。我现在用的方案是向量检索 倒排索引检索两边各取 top 10再做一次 RRF 融合排序取前面的结果作为上下文来源。这套方案不挑向量库用 Elasticsearch 或者开源的 Milvus 都能实现。实验下来对“编号查询、名称精确匹配、同义词扩展”这几类常见需求准确率提升非常明显。5.3 用评测集给 RAG 定基线RAG 系统上线后你肯定会被问效果到底怎么样这个问题如果只靠感觉回答项目经理和老板都不会满意。我的做法是准备一个评测集五十到一百条典型用户问题每条标注正确答案或应该关联的目标文档。每次修改检索策略或者拆分逻辑都在评测集上跑一遍记录召回率和命中率。为什么要做这件事因为 RAG 的知识库是持续增长的你不做回归测试可能今天改了个分块逻辑明天就有十几个问题回答得含糊不清而你自己完全没意识到。有了评测集哪怕效果不能完美量化至少你有一把尺子。6. 测试、可观测性与成本治理AI 应用能不能睡的着觉靠的是这些很多 AI 项目的测试还停留在“我手动试了十条用例看起来行”。要做成产品这个粒度远远不够。6.1 离线评测要跑在流水线上我建议 AI 应用的 CI 流程里至少要包含三类测试第一类是确定性单元测试提示词模板渲染结果、JSON 输出解析、工具调用的参数校验这些是确定性的直接写断言测试。 第二类是模拟模型测试测试环境里不真正调用大模型而是用一个返回固定内容的假模型来验证整个流程能不能跑通。这样测试跑得快、不进成本、不依赖外部服务。 第三类是回归评测选一批业务样例跑完后用模型或者规则来评判答案质量给出一个从 0 到 1 的质量分。当质量分下降超过阈值CI 直接失败提醒开发者检查提示词或上下文逻辑是否改动。你会发现第一类和第二类测试跟传统后端测试很像第三类才是 AI 特有的。但恰恰是第三类最容易在项目初期被忽略。6.2 线上监控必须能看到模型视角模型接口的请求日志和普通 HTTP 请求日志有一个很大差异你不仅要看“调用了谁、返回了什么”还要看“发了多少输入 token、返回多少输出 token、耗时多久、哪一段提示词占用的 token 最多”。我们把这类日志接进了统一监控面板。每天看几个数字单次请求平均延迟、日均成本、缓存命中率、各模型报错数。有一段时间我们发现成本飙升排查后发现是某个功能没有做结果缓存同一个问题被不同用户反复问每次都重新生成答案。后来加了语义缓存根据问题向量相似度直接返回上次结果成本直接降了 40%。成本治理是 AI 全栈开发里一个非常实在的优化方向常用的手段包括通过结果缓存减少重复生成、用小模型处理简单任务再升级到大模型兜底、对非核心任务降低模型参数规格、批量任务错峰运行等。每一条都值得在项目上线前规划好。6.3 灰度发布与快速回滚是最后的安全网AI 应用的发布跟传统应用不一样你说改了一个系统提示词但它实际上是一次模型行为的变更。你无法保证线上效果永远不低于预期所以必须留好后路。我现在常用的做法是灰度发布和配置开关。新提示词模板先让 10% 的流量试运行观测一两天看用户反馈、延迟、成本是否在可接受范围然后逐步放开。同时保留上一版可用配置一旦新模板出现问题把配置切回去全程不需要重新部署代码。这项能力并不复杂核心就是把提示词模板和模型路由做成动态配置而不是写死在代码里。但很多团队不做等到线上出了问题时只能紧急改代码发版非常被动。7. 团队协作与工作流里最容易产生摩擦的地方AI 全栈开发和传统开发有一个很大的团队协作差异传统开发的任务边界很清晰你负责订单模块我负责支付模块改代码就能定位人。AI 项目里经常出现“明明是你改了知识库文档导致我的功能回答变差了”“这个提示词是你写的现在线上出问题了你来解释”这类边界模糊的情况。7.1 给提示词建立所有权我强烈建议每个提示词模板都明确指定一个 owner。owner 负责它的效果、优化、上线和回滚。产品提了一个新需求涉及现有提示词变更不能直接自己去改应当经过 owner 的确认。变更记录走 Git 提交和评审。这套流程不是制造官僚主义而是因为提示词牵一发动全身出了问题必须有人能快速决策。7.2 配置与代码分离人工智能也要走 DevOps所有涉及模型的行为配置包括模型路由、提示词版本、知识库划分、工具开关都应该做成配置项与业务代码分离。开发环境可以随便折腾但 staging 和生产环境的配置变更要有审计。我在团队里甚至要求生产环境的模型配置变更必须记录变更人、变更时间、变更内容便于回溯。这样坚持几个月后你再也不会遇到“这个环境效果怎么跟昨天不一样”的玄学问题。7.3 我也踩过的几个真实事故讲几个我自己的教训希望大家不要再走一遍有一个项目上线第一版时用户输入框可以直接提交任意内容。有用户输入了一段精心构造的文本试图让模型“忽略之前的指令”把系统提示词泄露出来。虽然我们没有把密钥放提示词里但这种泄露尝试让我们意识到用户输入必须先做安全过滤。后来我们统一在交互层接入内容安全过滤同时对模型输出也做二次检查。另一个事故是我们在一个工具调用里让模型可以按 ID 查询用户信息忘记了在工具内部做鉴权结果测试同学用一个普通账号的 token 问模型“查询用户 12340000 的信息”模型竟然把另一个用户的信息返回了。好在这个事故发生在内测阶段没造成实际影响。但它深刻地提醒我工具层必须做权限校验。还有一个经验是流式输出容易忽略异常处理。前端拿到一个 SSE 流如果模型在中途出错断开前端必须展示一个友好的失败态而不能让页面长时间处于“一直在转圈”的状态。相关的前端超时和重连逻辑一定要先设计好。8. 从 0 到 1 再往前一步AI 功能的长期迭代其实就是数据闭环说完了工程体系最后想聊聊长期迭代。很多团队做 AI 功能上线那天就是效果最好的那天之后一路下滑。原因很简单真实的用户提问和你的测试集分布不一样用户会问出你想象不到的问题知识库也在更新产品需求也在变。如果没有数据闭环你的 AI 功能只会越来越跟实际需求脱节。我现在会在产品里默认埋点两类信息一类是用户对回答的反馈比如“有用”/“没用”按钮或者可选的评价标签另一类是把不满足预期的对话案例沉淀下来定期人工研判。这个研判不是技术活但非常重要每周花两个小时把本周低分案例过一遍分成“模型问题”“知识库缺内容”“提示词意图理解偏差”“工具调用错误”几类然后按类型排优先级去修。你会发现大部分效果问题不是模型能力不够而是缺了正确的上下文、检索到了错误的知识、或者工具没有覆盖用户高频场景。把这些坑一个个填完效果才会稳定向上。这比单纯换一个更大的模型要值钱得多。从我个人的习惯来说接到一个 AI 项目我通常先花半天把整个调用链路画出来哪些环节模型决定、哪些环节代码决定然后再写代码。这么做的原因是代码可以重构模型行为得靠数据和配置去调你的架构从一开始就得给“调”留出空间。你现在要做的不是急着去追下一个新框架而是先把模型接入层、上下文管理、评测集这三件事搭好。这三件事做好了后面加什么新能力都不会慌。
AI全栈开发实战：从提示词到生产级系统的完整工程化指南
不少朋友私信问我同一个问题现在“AI全栈开发”这个词被各种文章说到快要变味到底什么才叫 AI 全栈是会用提示词把几个接口串起来还是说要自己微调模型、部署推理环境才配叫全栈我做了几年 AI 应用落地也带团队交付过几条完整产品线我的答案是AI 全栈的本质是把自己当成一个能把“模型能力”融入现有工程体系的人而不是只会给模型写提示词的人。这篇文章不是从零教你某一门框架的教程而是把我踩过的坑、沉淀下来的选型原则和工程习惯完整梳理一遍。适合这几类人看已经开始用大模型开发应用但总觉得自己只在“拼接口”的开发者团队里负责 AI 功能落地的技术负责人以及想系统补齐 AI 工程薄弱环节的产品技术同学。我会尽量用真实项目里遇到的案例来讲少讲空洞概念多给可落地的方案。1. 先给“AI 全栈开发”画个范围你到底在做什么很多人一听全栈第一反应是前端、后端、数据库、部署都会。但在 AI 开发里全栈的范围和传统 web 开发有本质区别核心差在“不确定性”。普通代码输入相同输出几乎一定相同大模型应用同样的用户问题今天和明天可能给出完全不同的答案。1.1 从玩提示词到交付系统的分界线我见过太多“demo 很惊艳上线就完蛋”的项目。一个典型场景开发者在 Jupyter Notebook 或者某个在线 Playground 里调试提示词效果很好然后把它塞进一个 FastAPI 服务里就对外发布了。结果上线后用户问法稍微绕一点或者带着历史上下文追问一句回答就偏了。问题不在模型在于你没有为“不确定性”设计边界。传统全栈开发教我们定义接口、定义数据库表、定义页面状态所有数据流转是可预期、可测试的。到了 AI 应用里模型的输出就是不可预期的。所以 AI 全栈开发的第一课不是学 LangChain而是学会给所有不可预期的环节建“堤坝”。这个堤坝包括几个部分对模型输入的规范化、对模型输出的校验、对调用失败的兜底、对上下文超限的处理、对敏感内容的过滤。不能写一个messages.append(user_input)就完事。1.2 我梳理的 AI 全栈六层结构我给团队新人讲 AI 全栈时通常按下面六层来拆每一层都有明确的交付物第一层是交互层包括 Web 页面、小程序、桌面端或者 IM 机器人主要处理流式渲染、多轮会话、富文本和语音等交互形态。 第二层是会话与上下文层负责维护对话历史、记忆、用户画像以及把长文本做摘要压缩。这一层说白了就是传统 web 开发里的状态管理只是它管理的对象不是订单状态而是“一段持续变化的对话状态”。 第三层是模型接入层解决怎么连模型的问题是直连各家 API还是通过统一网关如何管理 Key、限流、成本如何做模型切换和降级这一层是 AI 全栈最容易被忽略但最影响稳定性的地方。 第四层是智能编排层这就是大家常说的 Agent、工作流、RAG 检索。它的职责是决定“什么时候调模型、什么时候调工具、什么时候查知识库”。 第五层是业务与数据层也就是传统后端的那些事订单、用户、支付、积分、内容管理。AI 不是悬空的它最终要融入业务数据。 第六层是治理与交付层包含测试、监控、日志、审计、安全合规。这层决定你上线后敢不敢睡觉。你能感觉到第二、三、六层缺一不可但大部分教程只讲第四层。这也是很多项目从 demo 到产品中间那道跨不过去的坎的真正原因。2. 模型接入层选型为什么我坚持用统一模型网关而不是直连你去读大模型服务商的文档他们会很亲切地给你一个 Python SDK三行代码就能调通。好多中小团队就这样开始了直连、直发。前两周一切顺利第三周业务方说“我们要再接入另一个模型的接口”你发现代码里到处散落着各家 SDK 的调用错误处理风格还不一样这个模型超时要重试三次那个模型要传temperature却要求浮点数还有个模型接口对整型非常严格。这时候你才意识到模型接入应该有一个统一层。我现在所有项目都默认接 LiteLLM 作为模型网关不只是为了转发请求而是为了三个实实在在的价值第一是切换成本趋近于零。如果你在代码里写死了一个模型品牌的方法想换另一个模型至少要改接口路径、鉴权方式、参数风格。但通过统一网关底层换了供应商你的业务代码几乎不需要动只改配置中心里的一个模型路由表。第二是审计和成本能集中统计。企业里做 AI 功能老板一定会问这个月调用花了多少钱哪个业务线消耗最大直连多家服务商的时候你要自己写统计逻辑用了统一网关请求日志、Token 统计、失败率这些信息天然集中在一处,省了我大量做报表的时间。第三是限流和降级有地方落地。没做过生产环境的人可能意识不到大模型的接口并发一高服务商侧就开始返回 429。你的服务需要有一个统一的“熔断开关”。我见过一个真实事故销售团队用 AI 写跟进邮件某个下午模型服务商波动五分钟内几百个请求全部超时销售直接炸锅。后来我们加了网关层设置了 50% 流量降级到备用模型再遇到波动用户几乎无感。我给新项目的默认建议是这样本地开发和测试可以直连模型没关系一旦进入 staging 或生产强制走统一模型网关。这不复杂但价值极高。2.1 自建推理和云端 API不要被“私有化部署”四个字绑架有不少团队在模型接入上纠结一件事要不要自己买卡部署开源模型。我的看法很现实先看你的业务规模。并发量只有每秒几次对话长度又不太长自建推理的成本远高于按量付费的云端 API。只有当你有稳定的高并发、强数据合规要求、或者定制微调需求时自建才值得。另一个常见误区是“开源模型 免费”。你算算卡、电、机房、算法工程师、运维的人力随便一个中等规模的推理服务月成本都在几万以上。而云端 API 按量付费在业务早期可能一个月只花几千。做技术选型不要被“私有化部署”这四个字绑架先算账再决定。2.2 多模型路由的降级策略怎么设计统一网关还有一个隐藏收益它让你天然具备了多模型容灾能力。我目前在生产环境使用的降级策略是三级第一级用当前效果最好的旗舰模型用于核心生成任务接受它的高成本。第二级用一个质量略低但稳定便宜的模型当旗舰模型超时或返回异常时自动切换。第三级是一个兜底规则比如返回固定话术或引导用户稍后再试确保用户不会看到空白页面。这里有一个关键细节降级不是把请求简单转发给另一个模型就完了。不同模型对提示词的理解能力有差异直接拿同一个提示词发给弱模型输出质量可能崩。我会在网关后面配一套按模型版本区分的提示词模板降级时自动切换对应的模板。这件事做好以后用户几乎感知不到底层模型换了。3. 提示词与上下文的工程化从“写一段话”到“维护一份配置”好多开发者对提示词的理解停留在“写一段话让模型听我的话”但 AI 全栈开发里的提示词本质上是一份要长期维护、会被多版本迭代、可能影响线上所有用户的配置。你想想后端一个接口的请求参数如果变了你要走评审、测试、发布流程那提示词牵一发而动全身凭什么不做同样管理3.1 提示词作为代码进 Git 仓库我现在的团队提示词全部作为项目代码的一部分进 Git 仓库。系统提示词、少样本示例、输出格式约束、风格限定都拆成独立文件而不是嵌在 Python 字符串里。原因很简单提示词会越来越长长到在代码里会污染业务逻辑提示词必须支持版本对比出问题的时候能知道“上周改了哪句话导致效果下降”。同时提示词文件里所有变量都走模板引擎渲染不允许手工拼接用户输入。比如这样system_prompt render_template(prompts/sales_email.txt, { customer_profile: profile, product_info: product, today: date })别小看这一步。直接在代码里写f你好{user_input}你是一名销售……三个月后你根本分不清哪部分是业务逻辑哪部分是可变的提示词参数。3.2 上下文管理是性能瓶颈不只是技术问题聊到上下文很多人的第一反应是“模型上下文窗口不够”。但实际项目里更大的问题是你把太多东西塞进上下文导致模型反应慢、成本高、而且容易被无关信息干扰。我给上下文管理定了一个“最小必要原则”能不放进去的尽量不放。用户的历史会话如果超过阈值先做摘要而不是把原始的五十轮聊天记录全丢进去。知识库检索只取相关的 top 5 个片段不要一次检索 50 个片段全塞进去。用户的无关属性比如注册时间、设备型号除非对生成结果有影响否则不要进上下文。有一回我们处理一个客服智能回复项目刚开始把用户的订单信息、浏览记录、历史投诉一股脑全放进提示词模型回复确实“看起来个性化”但延迟从 1 秒涨到 5 秒费用翻了三倍。后来我们改成只放与当前问题相关的订单摘要延迟回到 1.5 秒用户反馈几乎没变。这说明什么上下文不是越多越好是越准越好。3.3 输出要结构化别让模型自由发挥另一个工程化重点强制模型输出结构化内容。你调用一个“智能信息抽取”功能如果让模型随便回答一段话你的后续代码就得去解析一段自然语言那太脆弱了。我现在所有“非对话类”的生成任务都会要求模型输出符合 JSON Schema 的结果并且在代码侧用pydantic做校验校验失败自动触发一次重试或降级。比如让模型从一篇长文里提取摘要和三个关键词定义好输出结构然后接收解析。这样下游逻辑只需要处理标准字段不需要判断“模型的第几句话才是标题”。这是把不确定性转化为可控性的关键一步。4. 从 Demo 到生产智能编排不要迷信 Agent你打开任何一个 AI 社区都能看到关于 Agent 的赞美。自动规划、自动调工具、自主完成复杂任务听着非常美好。但我不客气地说一句大部分业务场景根本不需要一个完全自主的 Agent你需要的是一个可追踪的确定性工作流。4.1 什么时候用工作流什么时候才考虑 Agent我做了一个很简单的判断标准如果任务的步骤相对固定例如先查订单、再判断用户情绪、再生成回复——那么用工作流每一步都是预先定义好的可测试、可观测。如果任务是开放性的例如“帮我把这个 Excel 做成一份分析报告”你不能预先穷举所有步骤这时候才考虑让模型自主规划。团队里经常出现一个现象有人用 LangGraph 搭了一个看起来很高级的 Agent节点和条件分支有十几个最后效果不稳定还难调试。你问他为什么不用普通代码写一个if...else工作流他答不上来。过度自动化就是给自己挖坑。Agent 的价值是处理未知路径代价是难以预测。如果你的路径基本已知就直接用代码把路径写死然后把模型放在每个节点上去完成局部判断这是性价比最高的方式。4.2 工具调用是智能编排的基础设施真正复杂的 AI 应用里模型需要通过工具调用Function Calling去查数据库、调 API、执行代码。我把它称为AI 与后端世界的接缝。这个接缝最容易出错也最需要设计。我现在给工具调用定了几条硬规矩第一工具名和参数名要稳定。上线后的工具接口不要随意改名字因为改了名字模型通过提示词生成参数时命中率会明显下降。与其改工具名不如新增一个版本工具。 第二每个工具都要有清晰的描述说明这个工具是干什么的、什么时候用、什么时候不要用。模型靠这个描述来决定是否调用工具描述写得含糊模型就会乱调。 第三工具内部要做权限控制。模型能接触到的数据范围要得到控制。你让模型“查询用户订单”没问题但如果你不做行级权限隔离它可能会查询到任意用户的订单这在真实场景里是安全事故。我见过一个事故内部知识库 Agent 接了企业的文档搜索工具但工具没有做权限过滤所有员工都能通过模型间接搜索 HR 部门文档。这属于工程漏洞不是模型的责任。模型只是执行者权限控制得靠你在工具层实现。4.3 状态持久化和重试机制如果 Agent 是一次性回答不需要考虑状态但只要是多轮任务状态持久化就是绕不开的。举个例子用户说“帮我写一份周报”模型生成了草稿但你又希望用户可以在下一轮里说“把第二部分改得短一点”。这时候草稿内容必须存在某个存储里而不只是模型对话历史里的一个字符串。我用的是 Redis 或 PostgreSQL 存 session state配合一个版本号每次修改生成一个新版本。这跟普通后端的状态管理没有本质区别区别只是“状态变化由谁触发”传统应用是用户在页面点击触发Agent 应用是模型决策后调用工具触发。重试机制也要设计。模型调用可能因为网络、限流、内容安全策略等原因失败你不能让 Agent 像普通接口那样一失败就抛 500。我推荐使用指数退避重试最多三次每次间隔递增。同时给整个 Agent 执行过程设置一个总超时比如 60 秒超过就终止并返回可读的提示信息。否则一个失控的 Agent 可能在你的服务器上空转好几分钟。5. RAG 检索增强的工程化知识库不是“连个向量库就完事”几乎每个 AI 全栈项目都会遇到知识库问答需求。好多方案写得很简单把文档切成块丢进向量数据库用户提问时做相似度检索再把命中的内容塞进提示词。但实际效果往往差强人意问题出在“切块”这个环节。5.1 分块策略远比你想的重要文档怎么切直接决定了检索效果。按固定 500 字切块简单粗暴但一个完整的业务概念可能会被拆成两半导致上下文断裂。我现在的做法是优先按照文档结构切比如 Markdown 的一级标题、二级标题作为一个块的边界如果结构不明显再用固定长度切但保留一定的重叠区域比如前后各重叠 80 个字符保证语义连贯。块的长度也需要经验。太短上下文信息不足不好用太长检索套入提示词会超 Token 限制。我的经验是一般技术文档 500 到 800 字一个块比较合适。像法律合同、论文那种长段落可能需要进一步做语义句子级切分这属于进阶话题初期不必过度设计。5.2 混合检索比单向量检索靠谱纯向量检索有一个天然问题它擅长语义相似但不擅长关键词精确匹配。比如用户搜“合同编号 JX2024001”向量检索可能对数字串不敏感返回一堆合同相关的自然语言描述但用户要的偏偏就是那个编号。这时候关键是补充关键词检索。我现在用的方案是向量检索 倒排索引检索两边各取 top 10再做一次 RRF 融合排序取前面的结果作为上下文来源。这套方案不挑向量库用 Elasticsearch 或者开源的 Milvus 都能实现。实验下来对“编号查询、名称精确匹配、同义词扩展”这几类常见需求准确率提升非常明显。5.3 用评测集给 RAG 定基线RAG 系统上线后你肯定会被问效果到底怎么样这个问题如果只靠感觉回答项目经理和老板都不会满意。我的做法是准备一个评测集五十到一百条典型用户问题每条标注正确答案或应该关联的目标文档。每次修改检索策略或者拆分逻辑都在评测集上跑一遍记录召回率和命中率。为什么要做这件事因为 RAG 的知识库是持续增长的你不做回归测试可能今天改了个分块逻辑明天就有十几个问题回答得含糊不清而你自己完全没意识到。有了评测集哪怕效果不能完美量化至少你有一把尺子。6. 测试、可观测性与成本治理AI 应用能不能睡的着觉靠的是这些很多 AI 项目的测试还停留在“我手动试了十条用例看起来行”。要做成产品这个粒度远远不够。6.1 离线评测要跑在流水线上我建议 AI 应用的 CI 流程里至少要包含三类测试第一类是确定性单元测试提示词模板渲染结果、JSON 输出解析、工具调用的参数校验这些是确定性的直接写断言测试。 第二类是模拟模型测试测试环境里不真正调用大模型而是用一个返回固定内容的假模型来验证整个流程能不能跑通。这样测试跑得快、不进成本、不依赖外部服务。 第三类是回归评测选一批业务样例跑完后用模型或者规则来评判答案质量给出一个从 0 到 1 的质量分。当质量分下降超过阈值CI 直接失败提醒开发者检查提示词或上下文逻辑是否改动。你会发现第一类和第二类测试跟传统后端测试很像第三类才是 AI 特有的。但恰恰是第三类最容易在项目初期被忽略。6.2 线上监控必须能看到模型视角模型接口的请求日志和普通 HTTP 请求日志有一个很大差异你不仅要看“调用了谁、返回了什么”还要看“发了多少输入 token、返回多少输出 token、耗时多久、哪一段提示词占用的 token 最多”。我们把这类日志接进了统一监控面板。每天看几个数字单次请求平均延迟、日均成本、缓存命中率、各模型报错数。有一段时间我们发现成本飙升排查后发现是某个功能没有做结果缓存同一个问题被不同用户反复问每次都重新生成答案。后来加了语义缓存根据问题向量相似度直接返回上次结果成本直接降了 40%。成本治理是 AI 全栈开发里一个非常实在的优化方向常用的手段包括通过结果缓存减少重复生成、用小模型处理简单任务再升级到大模型兜底、对非核心任务降低模型参数规格、批量任务错峰运行等。每一条都值得在项目上线前规划好。6.3 灰度发布与快速回滚是最后的安全网AI 应用的发布跟传统应用不一样你说改了一个系统提示词但它实际上是一次模型行为的变更。你无法保证线上效果永远不低于预期所以必须留好后路。我现在常用的做法是灰度发布和配置开关。新提示词模板先让 10% 的流量试运行观测一两天看用户反馈、延迟、成本是否在可接受范围然后逐步放开。同时保留上一版可用配置一旦新模板出现问题把配置切回去全程不需要重新部署代码。这项能力并不复杂核心就是把提示词模板和模型路由做成动态配置而不是写死在代码里。但很多团队不做等到线上出了问题时只能紧急改代码发版非常被动。7. 团队协作与工作流里最容易产生摩擦的地方AI 全栈开发和传统开发有一个很大的团队协作差异传统开发的任务边界很清晰你负责订单模块我负责支付模块改代码就能定位人。AI 项目里经常出现“明明是你改了知识库文档导致我的功能回答变差了”“这个提示词是你写的现在线上出问题了你来解释”这类边界模糊的情况。7.1 给提示词建立所有权我强烈建议每个提示词模板都明确指定一个 owner。owner 负责它的效果、优化、上线和回滚。产品提了一个新需求涉及现有提示词变更不能直接自己去改应当经过 owner 的确认。变更记录走 Git 提交和评审。这套流程不是制造官僚主义而是因为提示词牵一发动全身出了问题必须有人能快速决策。7.2 配置与代码分离人工智能也要走 DevOps所有涉及模型的行为配置包括模型路由、提示词版本、知识库划分、工具开关都应该做成配置项与业务代码分离。开发环境可以随便折腾但 staging 和生产环境的配置变更要有审计。我在团队里甚至要求生产环境的模型配置变更必须记录变更人、变更时间、变更内容便于回溯。这样坚持几个月后你再也不会遇到“这个环境效果怎么跟昨天不一样”的玄学问题。7.3 我也踩过的几个真实事故讲几个我自己的教训希望大家不要再走一遍有一个项目上线第一版时用户输入框可以直接提交任意内容。有用户输入了一段精心构造的文本试图让模型“忽略之前的指令”把系统提示词泄露出来。虽然我们没有把密钥放提示词里但这种泄露尝试让我们意识到用户输入必须先做安全过滤。后来我们统一在交互层接入内容安全过滤同时对模型输出也做二次检查。另一个事故是我们在一个工具调用里让模型可以按 ID 查询用户信息忘记了在工具内部做鉴权结果测试同学用一个普通账号的 token 问模型“查询用户 12340000 的信息”模型竟然把另一个用户的信息返回了。好在这个事故发生在内测阶段没造成实际影响。但它深刻地提醒我工具层必须做权限校验。还有一个经验是流式输出容易忽略异常处理。前端拿到一个 SSE 流如果模型在中途出错断开前端必须展示一个友好的失败态而不能让页面长时间处于“一直在转圈”的状态。相关的前端超时和重连逻辑一定要先设计好。8. 从 0 到 1 再往前一步AI 功能的长期迭代其实就是数据闭环说完了工程体系最后想聊聊长期迭代。很多团队做 AI 功能上线那天就是效果最好的那天之后一路下滑。原因很简单真实的用户提问和你的测试集分布不一样用户会问出你想象不到的问题知识库也在更新产品需求也在变。如果没有数据闭环你的 AI 功能只会越来越跟实际需求脱节。我现在会在产品里默认埋点两类信息一类是用户对回答的反馈比如“有用”/“没用”按钮或者可选的评价标签另一类是把不满足预期的对话案例沉淀下来定期人工研判。这个研判不是技术活但非常重要每周花两个小时把本周低分案例过一遍分成“模型问题”“知识库缺内容”“提示词意图理解偏差”“工具调用错误”几类然后按类型排优先级去修。你会发现大部分效果问题不是模型能力不够而是缺了正确的上下文、检索到了错误的知识、或者工具没有覆盖用户高频场景。把这些坑一个个填完效果才会稳定向上。这比单纯换一个更大的模型要值钱得多。从我个人的习惯来说接到一个 AI 项目我通常先花半天把整个调用链路画出来哪些环节模型决定、哪些环节代码决定然后再写代码。这么做的原因是代码可以重构模型行为得靠数据和配置去调你的架构从一开始就得给“调”留出空间。你现在要做的不是急着去追下一个新框架而是先把模型接入层、上下文管理、评测集这三件事搭好。这三件事做好了后面加什么新能力都不会慌。