1. 技术选型为什么我不再纠结“用哪个大模型”最近一年多我一直在做AI应用类项目从最早的聊天机器人demo到后来的客服系统、内容生产工具、电商商品助手踩了不少坑。今天想和你聊聊AI全栈开发这件事。先解释一下“AI全栈开发”是什么意思。传统全栈开发指的是前端、后端、数据库、部署运维全都能搞定而AI全栈开发在这个基础上又加了一层——你还要能搞定大模型接入、Prompt提示词设计、向量检索、Agent编排、模型评估、成本控制等AI特有的环节。换句话说一个人或一个小团队要从零把一个AI产品做上线、做稳定、做得可用。这篇文章不是教科书而是我实际做项目时的完整复盘。如果你正准备入局AI应用开发或者已经在做但总觉得哪里不对劲这篇文章应该能帮你省掉不少试错成本。先说技术选型。很多人一上来就在纠结“用GPT还是Claude还是国产模型”“用LangChain还是Spring AI”“用Dify还是Coze”我的经验是90%的场景下模型选择不重要架构选择才重要。1.1 大模型选型的真实决策依据我现在的选型逻辑是这样的按优先级从高到低排数据合规与部署方式。如果项目对数据有严格的隐私要求比如企业内部知识库、金融医疗类应用必须考虑私有化部署或私有云API那么国内开源模型如Qwen系列、DeepSeek系列比境外闭源模型更稳妥。这个不是我个人的偏好而是项目能不能落地的硬条件。上下文窗口长度。如果你的场景需要喂给模型大量的“参考资料”比如长文档问答、合同审查那么上下文窗口Context Window就是核心参数。不是128K就万事大吉了关键要看长上下文下的“有效注意力”——很多模型标称128K但这到几十K之后中间部分内容的召回质量明显下降。工具调用Function Calling的稳定性。做Agent类应用模型能不能稳定地按格式输出“工具调用指令”决定了你的Agent开发体验。这一步我用过一个非常客观的测试方法准备20个包含嵌套参数的工具调用场景让模型逐个调用统计失败率。实测下来不同模型在这一项的差距比通用对话能力大得多。成本与吞吐。如果做的是高频C端应用token成本直接决定商业模式。我习惯用一个简单的计算模型单次会话平均消耗token数 x 平均日活 x 30天 月度成本。这个数字在选型阶段就必须算清楚而不是等上线后看账单。1.2 开发框架的“少即是多”原则关于开发框架我先泼一盆冷水不要为了用框架而用框架。我见过太多项目业务逻辑还不到200行就引了LangChain全家桶抽象类套装卸类出个Bug找半天不知道问题在哪。我自己在第一代聊天机器人项目里就吃过这个亏——某个自定义Agent行为L1层覆盖了L0层的Prompt我排查了整整两天。现在我的做法是分三层薄封装层只用框架的模型调用、消息封装、工具调用协议解析等基础能力这部分的封装价值是实打实的。业务编排层自己写。Agent的每一步做什么、什么条件下调哪个工具、出错怎么兜底这些必须掌握在自己手里不能交给框架帮你“自动决定”。基础设施层向量数据库、缓存、队列、可观测性用成熟的商业产品或开源项目不自己造轮子。如果你用的是Java技术栈Spring AI现在已经比较成熟了它的设计比LangChain克制很多更适合企业级项目如果你用Python我建议直接读OpenAI/Anthropic/通义等官方SDK再配上自己写的编排逻辑而不是一上来就套大型Agent框架。LlamaIndex则适合知识库类项目它的检索管线确实做得精细。1.3 为什么“最佳实践”不是一套固定配方说到“最佳实践”我得说句实话不存在一套放之四海而皆准的方案。今天网上搜到的“AI全栈开发最佳实践模板”基本都是一些大厂项目的总结你可以参考但绝不能照抄。我总结过一套自己的实践框架只有四个问题你的用户在哪里卡住了帮助用户完成什么任务你的AI要替用户做哪些判断哪些环节需要大模型智能哪些环节出错是致命的异常兜底优先级系统的数据从哪里来、又沉淀到哪里去数据闭环把这四个问题想清楚再去选技术方案起码能避免“技术选型脱离业务”这个全栈开发最大的坑。2. 一个AI应用的完整架构从聊天框到生产系统做AI应用最容易犯的错误是把“调用一次大模型”当成“做了一个AI产品”。真实的AI全栈应用远不止一个聊天框那么简单。我画过很多次架构图最后沉淀出来的核心模块基本是固定的。虽然我不能画图但可以给你完整描述一遍这个架构你照着就能搭。2.1 六层架构缺一不可我把一个生产级AI应用分成六层第一层接入层网关。负责用户鉴权、限流、并发控制。很多人忽略这层直接调模型API出了问题查半天才发现是并发把后端打崩了。第二层会话管理层。管理多轮会话状态、上下文窗口裁剪、历史记录持久化。这层是“用户体验”的关键很多AI应用给人感觉“像失忆”就是这层没做好。第三层业务编排层。这是AI应用的“大脑”决定了大模型在这一轮对话中要执行什么任务、走什么流程、调什么工具。我自己写的一般是一个状态机加路由逻辑。第四层模型接入层。统一封装各家模型API做到上层无感切换模型。配置中心保存模型名称、温度、max_tokens等参数。第五层增强检索层。连接向量数据库、搜索引擎、业务数据库做RAG检索增强生成让模型能回答私有知识问题。这里面又包含文档解析、切片Chunking、嵌入Embedding、检索重排等子模块。第六层数据沉淀层。记录用户行为、AI回答、反馈数据这些数据最终会回流到模型微调和Prompt优化中形成数据闭环。这六层不是每个项目都要齐全但它是一个成熟的参照系。你可以根据项目阶段做减法但心里要清楚“砍掉的是哪一层”以及后续补回来要付出什么代价。2.2 会话状态管理的魔鬼细节会话状态管理是AI应用最容易翻车的地方而且翻得无声无息。我做过一个客服系统用户对话到第8轮的时候模型开始胡言乱语。排查半天原因是我们的上下文窗口策略是“把最近10轮对话全部塞进Prompt”而客服场景的每轮对话特别长加上一个超大的系统提示词直接把模型的有效注意力窗口塞满了。后来我改用了一套组合策略轮次截断保留最近的6~8轮对话更早的内容做摘要压缩。Token预算分配按比例分配Token系统提示词20%当前请求内容30%历史对话摘要30%工具结果格式约束20%。这比例可以调但心里要有数。说完即忘机制对于已经完成的任务比如“查询订单状态并展示”下一轮对话就不再保留完整的工具调用JSON只保留“用户已查询订单A”这个事实摘要。这套策略上线后长会话的稳定性提升非常明显。如果你的应用也是多轮对话产品建议认真设计这一层。2.3 向量数据库选型不是只有一种答案RAG依赖的向量数据库选择余地其实很大。我的建议是数据量小于100万条单机部署用sqlite-vss或Chroma就行完全够用。别一上来就上分布式运维成本会吃掉你的开发时间。数据量在百万到千万级需要高并发上Milvus或Qdrant。Milvus功能全适合复杂过滤Qdrant性能好API设计舒服。已经在用Elasticsearch直接用ES的kNN检索能力不用额外引入新组件。很多团队为了一个向量库单独搭了一套集群纯属多余。PostgreSQL用户pgvector是性价比之王100万条以内没有压力而且能和业务数据放在同一个库里做事务。另一个常被忽略的点是向量检索不是唯一检索方式更不是最适合的检索方式。我做了大量对比实验纯向量检索的命中率大约在70%左右但是加上BM25关键词召回再做结果融合RAG Fusion命中率能到90%以上。所以我的实践是走“双路召回重排”的架构而不是把宝全压在向量上。3. 核心模块实操RAG、Agent、工具调用的落地细节如果说架构是骨架那RAG、Agent、工具调用就是AI应用的血肉。下面这三个模块是我在多个项目里反复打磨过的踩过的坑多到能写一本书这里挑最关键的说。3.1 RAG为什么需要三层优化RAG检索增强生成的基本流程大家都懂文档切片 → 向量化 → 语义检索 → 拼Prompt → 生成回答。但这套流程在真实场景中效果往往不理想用户问“我们的年假政策是什么”这样简单的问题都可能答非所问。问题出在三个地方对应的解法我也一并给出第一层切片策略优化。很多教程教你“500字一切重叠50字”这在大模型文档解析里根本不够用。我现在的做法是按文档结构切Markdown的多级标题、HTML的段落标签、PDF的标题层级都是天然的分隔符。每个切片尽量语义完整宁可长一点也不要切到半截。如果文档里是表格强烈建议转成Markdown表格或文字描述后再切片纯文本按字符切会丢失表格语义。第二层检索召回优化。向量检索的缺陷是只认语义不认关键词。最常见的一个坑用户说“工资”你向量库里的是“薪酬”虽然语义相近但向量召回的效果并不稳定特别是当你的嵌入模型训练语料不含行业术语时。我现在的标准做法是混合检索向量检索召回语义相近 关键词检索保证术语精确命中 重排模型对两种结果打分融合。重排模型我常用BGE-reranker系列效果比纯相似度融合好20%以上。第三层生成策略优化。拿到检索结果也别急着全塞给模型。我先对文档片段做个预处理过滤低相关度的片段、去重、按逻辑排序并给每段标注来源让模型自己判断“应该引用哪段”。Prompt里明确写“以下内容是检索到的参考资料如果参考资料中没有对应答案请直说不知道不要编造。”就这么简单一句话能显著降低胡编乱造的比例。这里特别提一句RAG不是做完检索就行它更像一个数据工程问题。你做文档处理的时间应该不低于整体开发时间的一半——解析各种格式的文档、清洗脏数据、处理扫描件OCR、维护版本更新这些活儿比调模型API繁琐得多但RAG效果的上限恰恰是由这些底层数据决定的。3.2 Agent让模型学会“用工具”Agent智能体是现在AI应用里最火的概念之一但很多人把它理解复杂了。我自己的定义很简单Agent 模型 工具 循环。模型负责理解意图工具负责执行动作循环负责反复“思考-行动-观察结果”。基于这个定义落地Agent开发只需要做三件事1. 定义好工具列表Tools。每个工具就是一个函数有名字、有描述、有参数Schema。这里的关键是“描述要写得足够详细且语义明确”。比如一个查询天气的工具描述写成“根据城市名和日期查询天气情况”不如写成“当用户需要了解未来的天气情况、气温、降水概率时调用此工具查询。参数city为城市中文名date格式为YYYY-MM-DD。”2. 设计好调用循环。最简单的循环就是把用户问题 工具列表 历史记录发给模型 → 模型判断是否需要调用工具 → 如果调用则执行工具并返回结果 → 把结果作为新消息再发给模型 → 循环直到模型不再需要调用工具。这个循环看起来简单但有几个必须处理的细节最大循环次数限制我默认设5轮防止模型在一个问题上反复横跳。超过就强制返回“我尝试了多次还没能完成请您换个方式描述”。工具结果截断工具返回的结果可能很大几万字直接塞进历史记录会把上下文撑爆。我的做法是截断到2000字以内并提示“以下为截断后的工具返回结果”。报错信息格式化工具执行失败时不要只返回一个空值或异常堆栈。我会统一封装成“工具调用失败错误原因XX请在回答中向用户说明并建议重试”。3. 给Agent设计“人格”和边界。这步最容易被忽视。你的Agent要知道自己是谁、能做什么、不能做什么。比如我的客服Agent系统提示词里写明了“你是XX公司的智能客服你可以查询订单、处理退换货、回答常见问题。你不能提供医疗建议、不能承诺赔偿金额遇到投诉请转接人工。”这个所谓的“人格”设置不只是让回答更有温度更是控制风险的边界。3.3 工具调用的工程化封装工具调用是Agent和外部世界交互的桥梁但它同时也是最容易出错、最让开发头疼的地方。我经历过的典型问题模型生成的参数格式不合法、参数名拼错了、枚举值不在给定范围内、日期格式写成了“明天”而不是“2025-04-12”……这些都真实发生过。现在的解决方案是这样一套防御体系请求校验前置模型返回工具调用后先用JSON Schema做一次格式校验不合规就重新让模型生成并附带错误信息。这比把垃圾参数直接传给业务函数再返回一个模糊异常要优雅得多。参数容错归一化日期、金额、城市名称这类高频参数写一套解析器。比如用户说“明天”就解析成具体的日期说“北京”就归一化成“北京市”。这一层在传给业务函数之前做。全部工具异步化涉及网络请求的工具查天气、查库存、调外部API必须异步执行避免阻塞整个Agent循环。审计日志每一次工具调用、入参、出参、耗时、成功与否都必须有日志记录。否则Agent行为异常时你连排查的抓手都没有。4. 模型输出不稳定一套能被評估和測試的工程体系AI全栈开发和传统软件开发最大的区别就是传统开发有确定的输入输出AI应用没有。你不能靠“代码逻辑正确”来保证质量因为模型的输出本身是概率性的。这就是为什么AI应用测试如此重要又如此难做。4.1 建立自己的评测集这是我们第一步就应该做的事在写第一行业务代码之前我就应该建议你建评测集。这个没什么门槛就是收集50~200个真实用户可能会问的问题以及每个问题对应的期望回答要点。评测集分三类金标测试集有标准答案的问题用来评测正确率。比如“退货流程是什么”期望回答里必须包含“7天无理由”“联系在线客服”“原路退款”等要点。对抗测试集用户容易“刁难”的问题比如问不存在的商品、故意表述模糊、包含错别字。用来评测模型的拒答能力。这类测试不需要标准答案重点看模型是否“不懂装懂”。边界测试集涉及安全、隐私、敏感词、诱导性问题确保AI不越界。每次上线新Prompt、换模型、调整RAG策略都要跑一遍这套评测集对比通过率。没有这个基准你的AI应用改进就是“盲人摸象”。4.2 用Prompt评估矩阵量化Prompt质量Prompt调优是一门玄学但也可以用工程化的办法管理。我有一个Prompt评估矩阵分五个维度打分每项1-5分维度含义我的检查清单完整性指令是否覆盖了所有该说的有没有设置角色有没有说明输出格式有没有定义边界条件一致性指令内部是否逻辑自洽前后措辞有没有矛盾约束是否可能互斥可测性Prompt能否确定地被评估输出格式有没有明确规范评判标准是什么抗干扰性面对无关/有害输入的表现用户乱说时会不会被带偏会不会忽略系统指令可维护性后续修改成本高低是否集中管理有没有版本记录我通常的做法是一个Prompt至少要达到四项4分以上才放上线。如果完整性或可测性低于3分硬上线的话后续肯定出问题。4.3 测试框架为AI应用写自动化测试现在市面上已经有不少AI应用测试框架比如DeepEval、Promptfoo这类开源工具它们的思路很一致跑评测集、跑断言、输出报告、集成为CI流水线。我的经验是不要等全部搭好再跑先跑起来哪怕只有10个测试用例也比完全没有强。我的测试套件一般长这样Python生态# evaluator.py 是简化版的演示代码实际项目建议直接用深拷贝封装 from deepeval import assert_test from deepeval.test_case import LLMTestCase from deepeval.metrics import AnswerRelevancyMetric, FaithfulnessMetric def test_answer_relevancy(): test_case LLMTestCase( input退货流程是什么, actual_output您可以在收到商品后7天内联系在线客服申请退货审核通过后原路退款……, retrieval_context[7天无理由退货请联系在线客服办理, 退货审核通过后退款将在3-5个工作日内原路退回] ) metric AnswerRelevancyMetric(threshold0.7) assert_test(test_case, [metric])不过有一点要提醒你这类自动评估框架也有自身的局限性比如评估模型的判断未必100%准确特别是当回答涉及“创造性内容”时自动评分很容易误判。我的做法是自动评估 人工抽检相结合自动评估跑通全量每周抽检50条高低分样本人工看一遍把误差反馈回评估Prompt。4.4 评估AI测试工程师的新思维如果你的团队已经有测试工程师我觉得很有必要聊一下AI应用测试和传统测试的思维差异传统测试写的是“断言”——这个接口应该返回什么字段名是什么值是多少。AI应用测试写的是“期望”——回答应该包含哪些要点格式是否符合要求语气是否合规是否引用了正确的知识来源。我建议测试团队建立这么一种习惯单独验证AI工作链路的每个环节。比如RAG场景测试的不是最终答案而是“检索结果Top5里有没有包含正确文档”。最终答案可以模糊但检索命中率是确定的指标。把不可预期的最终输出拆成一个个可预期的中间环节指标这是AI应用测试的核心方法论。5. 部署上线与成本控制别让“AI”成为吞金兽AI应用部署上线前有两个问题必须先想明白一你的模型在哪跑二每个月要烧多少钱5.1 模型部署的三种姿势方案A调用云端API。适合快速迭代、C端访问量不高的项目。优点是不用管GPU、不用做弹性伸缩缺点是单次调用成本高、有网络延迟、数据可能不落本地。方案B私有化部署开源模型。建议用vLLM或llama.cpp做推理加速。适合数据敏感、调用量大、单次调用成本敏感的企业项目。部署时需要注意量化精度一般用INT8或INT4效果损失可控并发吞吐vLLM的Continuous Batching能显著提高吞吐但显存占用也更复杂GPU型号编码类任务对显存带宽敏感推理类任务对显存容量敏感。方案C混合部署。简单问题走开源小模型复杂推理走云端大模型。我做过一个电商导购助手商品分类这种常规任务本地跑Qwen-7B复杂对比推荐走云端千亿级模型整体成本省了60%以上。5.2 控制成本的五个“省钱技巧”Prompt压缩每次调用前先算一下Prompt里的Token数把历史记录做摘要、把不必要的示例删除。Token就是钱这句话每天默念三遍。缓存机制对于知识库问答等高重复率的场景设置语义缓存。用户问过的问题相似的Query直接返回缓存结果不再调用模型。在电商客服场景里我实测缓存命中率能到25%。模型分级不要所有请求都用同一个大模型。语义分类、意图识别、信息抽取这些任务用7B~14B的小模型就够只有需要生成复杂内容、深度推理时才调大模型。批量处理非实时场景比如离线内容总结、数据分析报表用批量API价格通常是实时的50%左右。设置预算警报在云厂商或模型服务商的账户里配好限额和警报。AI项目的成本是线性增长的用户量一上来账单非常吓人。我的经验是设立“日预算/月预算”并在达到80%时人工审核。5.3 可观测性AI应用也需要监控传统应用监控关注QPS、CPU、内存、错误率AI应用除此之外还要关注这几项Token消耗按用户、按功能、按时段统计token消耗。首Token延迟Time to First Token用户发出请求到收到第一个Token的时间直接影响体验。这个值在流式输出场景尤其重要。单次调用耗时模型生成速度、工具调用耗时、RAG检索耗时要全链路追踪。安全/质量事件检测到模型输出违规内容、拒绝回答率、用户反馈负面占比等。模型退化监控同一个Prompt模型的输出质量会不会随着第三方模型的调整而下降比如GPT-4在2025年之后更新过多次同一prompt的输出质量就不一样了。所以我会定期重跑评测集一旦发现核心指标下降就要考虑固定模型版本或切换API。这些指标建议都接上日志和看板Grafana、Prometheus、ELK、SkyWalking都可以。别等用户投诉了再去找日志那时候你已经失去了“用户因何触发问题”的上下文。6. 团队协作与工程规范AI项目为什么更需要“规矩”最后聊一下团队协作和工程规范。说句实话很多AI项目不是技术不行才挂掉的而是死于“没有规矩”。6.1 Prompt的版本管理代码有Git版本管理Prompt也要有。Prompt是AI应用的核心逻辑但它是“文本文件”很容易被随手改了导致线上行为突变却不自知。我的管理方案是Prompt统一存到单独的配置文件或数据库存储用版本号管理。改动必须走Merge Request Code Review流程。线上每发一版Prompt都要绑定一个评测集的评测结果。这本来是用来管代码的但用在Prompt上效果一样好。6.2 模型上下线的灰度发布换模型是我眼见过踩坑最多的操作——新的大模型发布后台改了API版本上线当天准确率大跳水。现在的规范是新模型必须先在评测集上跑一遍确定不差于当前线上模型才允许灰度。灰度流程是5%流量 → 20%流量 → 50%流量 → 全量每一步观察一个完整的业务周期通常是一天。如果发现某类问题情感分析差、工具调用失败率升高立即回滚。6.3 AI应用也需要CI/CDAI应用的CI/CD管线持续集成/持续交付比传统应用多两个环节CI阶段跑代码生成测试、单测之外还要跑一遍AI评测集。Prompt有改动、RAG配置有改动都要跑。CD阶段除了构建镜像、滚动发布要额外把Prompt新版本作为发布产物的一部分做标签和回滚版本关联。我现在的做法是CI里设置“AI评测通过率 90%”作为合入主分支的门禁。虽然跑一遍评测集要几分钟但对比线上翻车后的修复成本这几分钟非常值得。6.4 数据闭环与模型迭代最后说一条比较重要、但经常被忽略的事AI应用上线只是开始数据闭环才是核心竞争力。每次用户与AI的交互不管是成功、失败、还是用户主动点了“不赞同”都要沉淀下来。我见过一个特别好的做法产品里加了“这段回答是否有帮助”的点赞/点踩按钮点踩的数据直接进数据库人工定期分析——用户为什么点踩是答非所问、编造事实、方向不对这些负样本就是Prompt优化、模型微调最珍贵的养料。配合这套闭环每个月定期做一次Prompt优化和评测集扩充模型的效果才会像滚雪球一样越滚越好而不是上线即巅峰。7. 避坑清单我踩过的那些“AI全栈开发”的坑最后分享一个我在多个项目里反复踩坑之后沉淀出来的清单。建议你保存下来每次发版前核对一遍。场景类坑知识库内容更新了但向量库没同步更新用户问新政策,AI还在答旧政策。解决方案对知识库做版本管理更新时自动触发文档解析和向量化流水线。用户的问题里带了口语化表达比如“你们那个能退吗”检索匹配不到任何文档RAG召回为空。解决方案加一轮Query改写先把口语转成书面语义再检索。多轮对话中用户说“那第二个呢”模型把“那第二个”当成了完整问题。解决方案增加语义补全策略结合历史内容把指代补全成具体问题。工程类坑Python环境的依赖冲突。AI项目依赖特别多PyTorch、Transformers、LangChain、向量库客户端版本稍微不对就大面积报错。解决方案项目必须容器化开发或者用Poetry/uv管理依赖并锁定版本。GPU显存溢出。推理服务在并发高的时候显存经常OOM。解决方案部署前压测设置并发上限超过就排队或降级到小模型。回调地狱。Agent工具执行过程中每个工具都要做超时、重试、熔断。我见过一个项目外部API超时后Agent卡死用户等了一个小时没回复。产品类坑用户不知道你的AI能做什么。AI交互要有“引导提示”主页放几个常见问题入口比让用户凭空想问题体验好太多。对AI的错误零容忍。AI不可能100%正确产品设计就要有“纠错机制”——用户点踩之后能不能快速转人工“AAI回答仅供参考”的提示能不上线就不上线因为它只能撇清责任不能提升信任。这份清单不完整也不可能完整。AI应用开发最大的特点就是“每天都有新的坑”。但大方向是对的把不确定性变成确定性把概率问题变成工程问题。我在实际做项目的过程中慢慢体会到一件事AI全栈开发看起来难在“AI”二字实际比拼的依然是工程基本功。模型能力正在快速收敛、同质化API大家都差不多真正拉开差距的是工程细节——数据怎么管、Prompt怎么迭代、评估怎么做、成本怎么控、用户体验怎么打磨。这套体系打扎实了不管底层模型怎么换你都能第一时间做出可用的好产品。如果这篇文章能让你少踩一个坑那我这半天就没白写。也欢迎你有了自己的实战经验后跟我分享你的“最佳实践”——AI领域没有标准答案但集合了很多人的实践之后大家都会走得更稳。
