这两年做AI应用最大的感受是模型能力早就不是瓶颈了真正卡住大家的是“怎么把一个想法稳稳当当做成一个能用的产品”。尤其现在大家都在聊 vibe coding——用自然语言堆功能、让AI把代码一把梭出来demo阶段确实爽但一涉及登录、计费、多轮对话、数据持久化、线上部署帮你写代码的AI也会跟着你一起翻车。这就像买了台顶级跑车油门一踩确实猛可没有靠谱的底盘和刹车你根本不敢上高速。我做AI全栈开发踩了大概半年的坑才慢慢摸出一套自己的最佳实践。这篇文章不聊理论直接把我现在做AI应用的标准流程、技术选型思路、踩坑记录拿出来分享。核心就一句话先跑通端到端再谈优化先让AI做得了事再要求它做得好。无论你是想从vibe coding进阶到正经工程化还是已经在做Agent应用但总在细节上翻车这篇都能给你一些可复用的参考。1. 从 vibe coding 到工程化落地差的是什么1.1 先搞清楚 vibe coding 的边界vibe coding 这个词火起来不是没道理。我也热衷于打开聊天框把需求描述成一段自然语言看AI噼里啪啦把代码吐出来。但用着用着你就会发现AI帮你写的代码有个共性局部漂亮全局混乱。它可能很擅长帮你写一个单页组件、一个请求封装、一个爬虫脚本但一旦这个项目的文件超过二三十个AI就开始“失忆”了——一会儿忘了鉴权怎么设计的一会儿不知道你前端在调哪个接口字段改完这里崩那里。问题不在于AI不够聪明而在于vibe coding默认的协作方式太弱了。你只是在“对话”不是在“开发”。真正的开发是有结构的是需要上下文持续对齐的是需要约定接口、管理依赖、留好扩展点的。所以我现在的做法是vibe coding 用来写局部、做原型、解算法工程化交给一套固定的脚手架和流程。AI负责干活我负责搭结构和验收。1.2 一套适合AI开发的落地框架harness × SDD我在实践里逐渐形成了一套自己的工作流可以简单称之为harness约束框架× SDD规范驱动开发。harness给AI设定清晰的约束边界包括技术栈固定、目录结构固定、接口规范固定、提交节点固定。AI只能在约束范围内发挥不能随意引入它喜欢的库和模式。SDDSpec-Driven Development先写规格说明再写实现。每个功能模块先让AI按规格输出接口定义、数据模型、边界条件确认无误后再生成代码。这套组合拳的逻辑很简单限制AI的自由度反而能提高它的产出质量。因为大模型最擅长的是“在给定格式里生成内容”而不是“替你做架构决策”。你让它自由发挥它就自由地给你造一堆技术债你把决策都做好它反而能精准执行。现在项目里所有新功能都走这个流程先写spec文档再给AI参考文档和代码上下文让它产出实现方案我来评审方案然后才让它动代码。实测下来代码返工率降了不止一半。2. 技术选型解析哪些组件值得用真金白银去换2.1 大模型接入层为什么先统一走 OpenAI 兼容协议做AI全栈第一件要决定的事就是怎么接大模型。现在市面上模型太多了OpenAI、Anthropic、国产开源模型、各种API服务商每家协议都有细微差别。如果业务代码里直接写各家SDK后面每一次换模型都像一次外科手术。我现在的做法是自建一个模型网关层所有模型统一暴露成 OpenAI 风格接口。不光是省钱省时间的问题更重要的是业务方可替换性。今天业务量小用便宜的国产模型明天上线大客户要切GPT级别的能力网关层改个配置就行业务代码一个字不用动。如果是团队小、不太想自己建网关的也可以直接用现成方案。我会推荐先看看 LiteLLM Proxy它就是一个把各种模型统一成OpenAI协议的标准工具。你用它对接本地任何模型服务业务侧还是同一套代码。我自己是在项目早期先上了 LiteLLM等后面要加缓存、限流、租户隔离等企业功能时再逐步替换成自研网关。这个路线对中小团队很友好前期不用重复造轮子。2.2 开发框架与编排Spring AI、LangChain 还是自研Agent接入层定了之后第二步是选开发框架。这里我的经验是如果你的项目核心是CRUD偶尔调用模型那直接用Spring AI或官方SDK就够了别上重框架。只有当你需要做多工具调用、多步推理、流程编排时Agent框架才真正派上用场。我做过一次对比一个简单的客服问答功能用Spring AI可以直接把对话历史和知识库检索逻辑写在一个Service里非常清爽。但如果要做一个会查订单、会退款、会发短信的Agent那手写状态机和工具调度就纯属自虐了。这个时候我更倾向用 LangChain 4jJava生态或者 Python 生态里的 LangGraph它们把ReAct循环、工具注册、状态持久化都帮你封装好了。不过依赖框架并不意味着把逻辑全交给框架。我一般只把框架当作编排引擎核心业务逻辑还是写在自家的Service层里工具的入参出参都定义成强类型。这样框架升级、替换成本都可控。2.3 数据层向量库和业务库各回各家很多AI应用绕不开知识库检索也就是RAG。这里有一个我从血泪里总结出的原则业务数据放业务数据库检索数据放向量库别混在一起。比如一个产品FAQ系统原始问题、答案、点击量这些放PostgreSQL切分好的文本块和向量放 pgvector 或 Milvus。查询的时候先向量检索拿到候选块再回到业务库做权限过滤、排序、聚合。这套结构的好处是权限模型清晰而且向量库里存的东西坏了随时可以重建不会影响主数据的完整性。选向量库的时候如果项目初期数据量在百万级以内pgvector 完全够用少维护一个组件。数据量再大、并发再高再考虑独立的Milvus或专门的向量数据库服务。别一上来就堆一堆中间件AI应用烂掉的通常都不是模型而是被基础设施拖死的。3. 实操过程从0搭一个AI全栈小产品3.1 案例选择与需求拆解光说不练假把式我拿一个最近做的“AI PPT大纲生成助手”作为完整例子带你把整个流程走一遍。这个产品不大但涵盖了AI全栈开发的典型要素输入一个主题AI生成PPT大纲和每页要点前端可以编辑、预览、导出后台会记录生成历史。需求拆解之后核心模块就四个前端页面输入主题、展示大纲、编辑点后端服务接收前端请求、调用模型、返回结构化内容Agent编排层负责把“生成大纲”拆成“生成主题解析”、“按章节生成要点”、“生成演讲备注”三个子任务也承担一定的质量检查数据存储用户生成记录、内容缓存这个拆法看起来平平无奇但它决定了后面每一层都好做。很多人做AI项目失败是因为需求没拆透就开始调prompt结果需求一变prompt、代码、数据结构全都要跟着动。3.2 从spec到代码先定接口再写逻辑按照我前面说的SDD流程我没有直接让AI写代码而是先定义了后端接口格式。比如生成大纲的接口POST /api/outline/generate Request: { topic: AI全栈开发最佳实践, style: 技术分享, pages: 12 } Response: { outline_id: xxx, title: AI全栈开发最佳实践, sections: [ { title: 为什么需要工程化, points: [..., ...], speaker_notes: ... } ] }这个接口定义很重要因为它同时约束了前端渲染、后端模型解析、数据库存储三件事。等接口文档写好才让AI按照“FastAPI SQLAlchemy OpenAI SDK”的技术栈去实现后端再让AI按照“React Tailwind”去实现前端页面。因为边界明确两端可以并行开工而且AI写出来的代码基本能对上。3.3 Agent编排的落地工具、状态与流程控制大纲生成看起来只是一次模型调用但实际写的时候会发现一次性让模型输出12页大纲到后面几页经常开始重复和偏离主题。所以我把它改成了Agent式流程先生成目录骨架再一章节一章节地完善内容最后让模型“自检”一遍看有没有遗漏或矛盾。这里我用的是LangGraph流程节点大致是生成目录节点planner每章生成要点节点writer循环调用整体审校与修正节点reviewer每个节点都定义了输入输出的Schema工具只做一个——把章节结构写入临时状态。Agent的循环控制是最容易出问题的不加max_iterations模型可能会因为某一步输出不合法而无限重试。我在配置里强制限制最大循环次数超过次数直接把已生成的部分返回而不是报错给用户。3.4 关键参数的选择逻辑Agent里用到的核心参数大多不是随便拍的我分享一下现在的参考值模型选择目录生成用推理强一点的模型比如gpt-4o级别章节扩写用性价比高的模型比如deepseek或gpt-4o-mini级别。前后成本差好几倍但体验差异不大。temperature做创意类内容生成建议0.7到0.9做事实类内容或需要稳定输出的场景降到0.2。大纲生成属于偏结构化的创意我取0.7。max_tokens根据输出结构估算单章节内容大概需要800到1200 token我把上限设成1500避免模型中途截断。截断这个问题特别坑如果输出被截断JSON解析必挂宁可上限设大点。重试机制调用模型时带上指数退避重试默认3次第一次失败等2秒第二次等4秒第三次等8秒。这个是应对大模型API偶发超时的标准姿势。3.5 部署与上线别让部署变成最后一根稻草代码写完了部署阶段也有几个固定动作。我正在用的是Docker Compose来编排整个应用前端Nginx容器、后端服务容器、PostgreSQL容器。模型API的Key通过环境变量注入不写进代码里。上线前有几件事我每次都会检查CORS配置前端域名必须白名单化否则浏览器直接拦截请求超时时间后端调用大模型的接口耗时长前端请求超时时间要调到60秒以上并且用流式输出提升体验日志与监控模型请求的耗时、token用量、错误码全部打日志方便之后做成本分析内容检查AI生成内容在返回给用户前会过一次基础的内容过滤规则敏感词和明显违规文本直接拦截这是底线不能省我这套小节流程走下来一个全栈AI应用基本上固定2到3天就能从0到上线。速度比传统开发快非常多但前提是结构和参数都提前定好。4. 常见问题与排查技巧实录4.1 AI输出格式不稳定JSON解析总是崩这是最经典的问题几乎每个做AI应用的都会遇到。模型今天乖乖输出JSON明天可能就在代码块里包一层json标记后天又在JSON后面多了一句“以上就是大纲”。我的解决方案分三层用结构化输出能力或函数调用如果用的模型支持JSON Schema约束直接开启结构化输出让模型输出天然符合格式解析容错解析前先剥离markdown代码块标记JSON解析失败时用正则掐头去尾再试一次还不行就重试一次模型调用兜底重试重试时提示模型“上次输出格式不符合要求请严格按JSON格式输出”把之前的输出片段拼进新Prompt里模型通常会自己修正这套组合拳之后JSON解析失败率基本能降到1%以内。4.2 上下文越长效果越差费用也越高很多AI应用做着做着就发现多轮对话历史越积越长模型响应变慢、费用上升偶尔还突然“失忆”之前说过的话。这是上下文管理没做好。我现在固定做法是只保留最近N轮的对话记录默认6轮更早的做摘要长文档检索时只携带命中的片段不把完整文档塞进Prompt给输入历史设置token上限超过后自动裁剪最早的内容费用控制方面我还会给频繁相同的Question加一层缓存比如FAQ类问题命中缓存直接返回既省钱又提速。这个在网关层实现最方便也是我前面说为什么要搞统一模型网关的原因之一。4.3 Agent进入死循环或工具越权用Agent的都知道多步推理看着高级但有时候模型就是会钻牛角尖。比如给模型的工具是“搜索订单”它搜不到订单时可能反复尝试变种搜索词甚至尝试调用一个不存在的“查看全部订单”工具——这时候如果没有约束整个流程就废了。我的处理每个工具调用都设超时和最大重试数Agent整体设最大迭代步数到了就强制终止返回当前结果和状态工具权限最小化Agent只能用分配好的工具不能动态生成工具或执行任意代码另外实际项目里我会给Agent设一个“安全兜底工具”当Agent自己判断完成不了时可以直接调用“转人工”而不是硬编。这个设计在很多客服/问答场景下特别重要用户体验会好很多。4.4 常见问题速查表现象原因排查方向解决方案模型输出JSON解析失败输出被截断/混入多余内容查看原始响应完整文本结构化输出剥离标记重试流式输出前端卡顿SSE处理不当/超时设置过短抓包看响应是否中断调大超时时间处理断线重连多轮对话后效果变差上下文过长/历史污染统计token消耗裁剪历史做摘要限制轮数Agent反复调用同一工具工具设计不合理/缺少退出条件看调用日志最大步数限制失败终止条件生成内容包含敏感信息模型新材料无过滤抓取线上返回内容增加内容过滤服务和人工审核线上效果和本地不一致版本差异/参数不一致对比prompt和参数统一prompt版本和模型版本管理这份速查表我现在贴在项目文档首页每次线上出问题先对着表排除一轮大多数问题都能在一小时内定位到根因。5. 经验沉淀与长期优化建议5.1 把Prompt和代码一样管理起来我最开始做AI开发的时候prompt随手写在业务代码里后面改起来想死的心都有。现在我把prompt全部抽出来放到独立的目录里每个prompt文件都有版本号、作用域、模型适配信息。代码里的占位符对应各自的变量prompt的改动走代码评审。这样做的好处特别明显升级模型时可以直接对比不同版本prompt在评测集上的表现出了问题也能快速定位到是哪次prompt变更导致的。5.2 建立自己的评测集AI应用最怕的不是功能bug而是“这次改了prompt不知道哪些场景变差了”。我现在每个项目都会维护一个小的评测集大概50条左右覆盖正常输入、边界输入、负面输入。每次改prompt、换模型就用评测集跑一遍人工扫一眼结果。虽然这个过程听起来很原始但在没有专门评测工具之前这已经能拦住绝大多数回归问题。等团队大了、场景多了再考虑用自动评估框架和版本回放机制。5.3 成本与性能的长期平衡做AI应用成本是个始终绕不开的话题。我现在的经验是不要等账单爆了才想起优化从一开始就做好分层简单任务用便宜模型复杂任务用贵模型相同请求加缓存长文本任务先压缩再送入模型合理控制输出长度模型收费通常按token算多一个字都是钱另外流式输出除了提升体验也能降低“用户等待焦虑”这两件事其实是同一个优化方向。我自己在上线第一个AI应用时因为没用流式每回要等十几秒才出结果数据惨不忍睹。后来改成SSE流式输出用户停留时长直接翻了一倍。最后想说的做了这么多AI全栈项目我最深的体会是AI再强也只是把你的执行速度放大了放大之前该想清楚的事还是得想清楚。需求定义、接口设计、边界约束、安全底线这些工程基本功一个都不能少。反过来只要你把这些基础打牢AI真的能让你一个人干出一个团队的量。如果你正准备从vibe coding进入正经的AI全栈开发我的建议很简单先按这篇文章的框架搭一个最小可运行的产品别贪功能先跑通整个链路然后再一步步把Agent、RAG、成本优化这些东西加进去。等你跑通两三个完整项目之后再回头看你就会发现自己已经形成了一套属于你自己的最佳实践了。