从“能跑”到“能挣钱”AI 应用开发生产落地实践指南先说说一个现象这两年我见过太多团队Demo 阶段风光无限一到生产环境就抓瞎。RAG 问答在测试集上答得头头是道上线后被业务部门拿真实数据一怼就翻车Agent 工作流在演示时行云流水并发一上来就超时、幻觉、token 烧钱。如果你正准备把一个 AI 应用从实验原型推向真实业务场景或者已经在生产环境里被各种诡异问题折磨那这篇文章就是写给你看的。这篇文章不是什么理论科普而是基于我实际踩坑、填坑的经验总结。我尽量把思路、选型、步骤和坑点串成一条能直接抄作业的主线覆盖 RAG、Agent、提示词工程、本地部署、性能优化、成本控制这几个生产落地绕不开的环节。后端的同学、全栈工程师、准备面试 AI 应用开发岗位的朋友都能从里面找到一些有价值的东西。1. 先把思路理顺生产级 AI 应用和 Demo 的本质区别1.1 为什么 80% 的 AI 应用死在从 Demo 到生产的路上很多团队做 AI 应用最开始的路径都差不多拿一个大模型 API写个提示词做出一个看起来很聪明的聊天框然后给领导演示。演示效果确实惊艳因为负责人挑的都是模型擅长的题目。但到了生产环境问题就接踵而至——数据量涨了一个数量级、响应时间从 1 秒变成 15 秒、模型开始胡编乱造、账单一天比一天吓人。这里面的核心矛盾是 Demo 只关心“能不能跑起来”生产关心的是“能不能稳定、可控、低成本地跑起来”。差距不是一星半点。拿我做过的一个客户资料问答系统举个例子。POC 阶段我用一个 PDF 做演示检索快、回答准客户当场就点头了。等到真正落地时客户那边的知识库是三千多份文档有 PDF、有 Word、有扫描件还有几十张格式完全不一样的 Excel 表格。检索准确率骤降回答开始答非所问模型还经常把 A 客户的数据说成 B 客户的。这时候你才发现提示词写得再好也救不了底层的检索质量。这个案例后面我会反复拿出来说因为它基本覆盖了生产落地的所有典型问题。生产级 AI 应用本质上是一个软件系统工程。大模型只是其中的一个组件你还需要处理好数据管道、检索策略、缓存、限流、权限控制、监控告警、成本核算这一整套链路。如果你只把注意力放在模型选择上那后面大概率会被细节淹没。1.2 技术选型的底层逻辑大模型 API、本地部署还是混合架构大模型应用开发的第一步就是选模型部署方式。我的建议是先别急着本地部署先算账。本地部署大模型的好处是数据不出内网、单次调用成本可控、不依赖外部服务。但坏处也很明显——你需要 GPU 服务器需要运维团队需要应对模型迭代带来的重新部署还得自己处理并发和推理优化。我见过一个团队为了“数据安全”买了四张卡本地跑开源模型结果业务量根本跑不满卡片利用率不到 10%而人员成本、机房成本是 API 调用的好几倍。反过来全部走大模型 API省心但也要考虑几个变量数据出境是否符合合规要求、单次请求的网络延迟你能否接受、长期跑下来 token 费用是否可控。比较现实的做法是混合架构——核心业务和高频场景走 API数据敏感的模块走本地部署低频的复杂任务按需切换模型。具体到模型选择上我现在的原则是“按任务分模型”。简单分类、抽取和格式化输出用小参数模型就够便宜又响应快。需要深度推理、长上下文理解的复杂任务再上大模型。前面说的客户问答系统我后来就是分了两条链路普通咨询走轻量模型涉及多文档交叉推理的高阶问题才走重型模型。成本直接降了约 40%用户体验反而更稳定。如果你要做本地部署还有一个建议一定要先确认你的推理框架。现在主流的选择是 vLLM 和 Ollama前者适合高并发生产环境吞吐量高后者适合开发和轻量场景部署简单。别一上来就图省事用 Ollama 撑生产环境并发一高就会因为缺少连续批处理优化而吃大亏。我详细踩过这个坑后面会展开说。1.3 架构设计从“提示词 模型”的玩具架构到工程化架构面向生产的 AI 应用架构上至少要有这几层接入层负责处理请求校验、用户鉴权、限流和路由。不能让业务请求直接打到模型上否则一个失控循环就能把你整月预算烧光。数据处理层负责文档解析、清洗、切分、向量化以及后续的数据回流和更新。检索与增强层负责混合检索、重排、上下文组装。这一层是 RAG 应用的核心竞争力。模型推理与 Agent 调度层负责调用大模型、编排工具、管理多轮对话状态。服务与监控层负责灰度发布、日志追踪、指标采集、成本核算和告警。把这几层想清楚了再去看那些热搜词里的“大模型应用开发学习路线”你的学习重点会更清晰——你不是在学怎么调一个 API而是在学怎么搭一个系统。2. 核心细节拆解把 RAG、Agent 和提示词工程真正搞懂2.1 RAG 链路从数据清洗到召回重排的完整闭环RAG 是目前企业级 AI 应用的主流形态但好多团队把 RAG 等同于“文件上传后扔进向量数据库”。如果你的知识库只有几十页 PDF这么做确实可以。但数据量一旦上来检索质量就会断崖式下跌。先讲文档解析。PDF 有好几种类型文本型 PDF、扫描型 PDF、还有带复杂表格的 PDF。文本型 PDF 直接用解析器就能拿到文字但扫描型就得接 OCR表格型最折磨人——直接按文本提取表格结构会乱成一团后续做检索时 semantic 信息损失非常大。我目前的处理方式是针对不同文档类型路由到不同的解析器文本型的用常规解析扫描件走 OCR 服务表格型的先把表格区域检测出来转成 Markdown 格式再入库。这一层做好了检索效果的上限就确定了。再讲切分策略。切分的大小直接影响检索质量——切太大一块内容涵盖多个主题向量表示不聚焦召回结果容易跑偏切太小语义信息不完整检索到的内容往往残缺不全。我建议的通用方案是固定 chunk_size 为 500 到 800 个 tokenoverlap 设 100 到 150 个 token。同时结合文档本身的标题层级先按标题分块再把超长的块按 token 截断这样能兼顾结构语义和长度控制。参数的选择不是拍脑袋是有计算逻辑的。比如你的 embedding 模型是 1024 维从理论上说每一维能携带的信息量有限所以一个 chunk 至少要包含足够的 token 才能形成有区分度的向量。反过来如果 chunk 太大向量平均池化后特征会被稀释。我的经验是 500 token 到 800 token 是一个比较稳的区间再配合标题结构切块基本的检索准确率就不会太差。向量化这一块国内团队常用的是通用文本向量模型比如 BGE 系列或者 M3E也有直接用 OpenAI 的 text-embedding-3。选型的时候要关注三个指标检索效果可以用 MTEB 榜单做参考、向量维度直接关系到存储成本和检索速度、中文适配度。很多国外模型在中文长文档上的表现一言难尽这个必须用你自己的数据集做评测不能只看榜单。接下来是召回和重排。很多人把 TopK 设成 4 或者 5然后直接把结果拼进上下文。但生产环境下前几个召回块未必就是最相关的。我的做法是“宽召回 精细重排”先用向量检索召回 20 到 30 个候选块再用交叉编码器cross-encoder做一次重排取前 5 个拼上下文。重排这一步会多花几十毫秒但效果提升非常明显。我实测过在专业领域的 FAQ 问答中加了重排之后准确率能提升 10 到 15 个百分点。这一套流程跑通之后你才算真正把 RAG 的链路打通了。2.2 不要把 Agent 做成玩具工作流和工具调用的工程化AI Agent 现在的热度很高但很多团队做 Agent 就只是给模型加一个 system prompt说“你可以调用如下工具”然后期待模型自己搞定一切。这基本是在赌博——模型可能把工具参数传错可能在一个失败的循环里反复横跳可能在不用调用工具的时候乱调还可能因为一个幻觉的中间结果导致最终答案完全跑偏。工程化的 Agent要解决两个核心问题可控性和可观测性。先说可控性。在设计 Agent 工作流时我的建议是“最小权限 必要审批”。给模型的工具接口要严格限制参数和权限边界。涉及资金操作、数据删除、外部发送消息这类高风险动作必须在工作流里加入人工审核节点不能把最终决定权交给模型。举个例子我在做一个周报自动生成 Agent 时模型可以调用“查询工时”“拉取任务列表”“生成周报草稿”这些工具但“发送周报邮件”这个动作我强制要求跳转到人工确认页面。用户确认之后才真正发出。这样既保持了自动化体验又杜绝了不可控风险。再讲可观测性。Agent 的推理路径一旦多轮调用中间过程就很难调试。不把中间每一步的输入输出记录下来你根本无法知道它为什么最终答错。当时有个排查案例某个 Agent 在生成 SQL 时传了一个不存在的表名给工具导致后面的查询步骤全部失败。如果没有日志我可能得猜半天。现在我的做法是Agent 的每一次 tool call 都必须记录 tool 名称、入参、出参、耗时和调用顺序同时把完整的思考轨迹存到日志系统。这样出问题时能一键回放整个推理链路。还有一个常见的工程问题是“死循环”。模型在调用一个写文件工具时可能会因为文件路径一直冲突陷入反复重试的循环。硬编码的循环上限建议设 3 到 5 层同时加超时熔断超过时间直接返回“当前任务较复杂需要人工介入”。2.3 提示词工程的三个层次与防幻觉设计AI 应用开发面试题里提示词工程几乎是必考项。但面试题考的多是单轮提示词的写法而生产环境的提示词工程核心目标是稳定和可维护。第一层是结构化模板。把 system prompt 拆成几个固定板块角色定义、任务背景、输入格式、输出约束、知识依据、兜底话术。每块用固定的中文标识符隔开方便后续维护和自动注入。注意不要把所有逻辑塞进一大段文字里模型对这种长文本的表征能力其实一般结构化指令的效果通常更好。第二层是输出约束。除了让模型“用 JSON 格式输出”我还建议给出一个可校验的 schema 和示例。比如{ answer: 对用户问题的直接回答, evidence: [引用的文档ID列表], confidence: 0.0-1.0, need_human: true/false }配合一个 Pydantic 或 Java 的校验类对模型输出做二次校验不满足 schema 就重试一次再不行就走兜底流程。这一招能拦下不少坏输出。第三层是防幻觉设计。核心思路就一句话让模型的回答“有据可依”。在 prompt 里明确要求模型只能基于给定的知识块作答如果知识块中没有相关信息必须回答“根据现有资料无法回答”而不是强行编造。同时要求模型在输出中标注答案引用的来源 ID这样用户或系统可以追溯。很多人以为这样限制了模型的“自由度”但生产环境里我们需要的就是这种可控的自由度。3. 实操过程从零搭一套可落地的知识库问答系统3.1 技术栈选择与项目结构技术栈的选型除了要满足业务需求还要考虑团队的学习成本和社区的活跃度。我这边做个技术选型方案偏向工程团队快速上手后端框架Spring AI Alibaba。这框架在 Java 生态里算是对大模型接入封装得比较全的支持 ChatClient、结构化输出、向量存储抽象近期社区热度也很高。快速前端验证Python Dash。Dash 用纯 Python 就能写出一个带输入框、下拉框、聊天记录展示的页面特别适合后端团队快速验证效果。我自己用它实现过一个有侧边栏的知识库演示页半小时左右就能搭起一个简单的原型。向量数据库先选轻量的 Chroma 或者 Milvus。如果知识库在百万级向量以下先用 Chroma 就能跑到不错的效果大规模高并发再上 Milvus。Embedding 和重排模型文本向量模型加一个交叉编码器重排模型。项目结构可以这样规划ai-knowledge-app/ ├── backend/ # Spring AI Alibaba 后端 │ ├── src/main/java/ │ │ ├── controller/ # 对外接口 │ │ ├── service/ # 业务逻辑 │ │ ├── rag/ # RAG 链路 │ │ └── agent/ # Agent 工具定义与编排 ├── frontend/ # Dash 快速验证前端 ├── data/ # 原始文档和知识库 ├── scripts/ # 数据处理和导入脚本 └── docker-compose.yml # 本地部署编排强调一下这是生产环境的骨架实际落地时还要加上配置中心、日志采集和监控面板这里先不展开。3.2 核心实现用 Spring AI Alibaba 接入大模型与 RAG 流程先看后端接入的骨架代码Configuration public class LlmConfig { Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder .defaultSystem(你是一个严谨的知识库问答助手只能基于提供的内容回答。) .defaultOptions(ChatOptions.builder() .withTemperature(0.2) .withMaxTokens(800) .build()) .build(); } }温度temperature的设置是一个关键点。做知识库问答时我们追求的是确定性和准确性温度调高反而会引入不必要的随机性。0.1 到 0.3 是知识问答场景比较稳的区间。如果做创意写作才需要往 0.7 以上调。再看 RAG 的检索增强部分public class RagService { private final VectorStore vectorStore; private final ChatClient chatClient; public String answer(String userQuestion) { // 1. 向量检索 var candidates vectorStore.similaritySearch( SearchRequest.builder() .query(userQuestion) .topK(20) .build()); // 2. 重排这里省略具体调用按分数取前5个 ListDocument topDocs rerank(userQuestion, candidates, 5); // 3. 拼上下文并按结构化 schema 输出 String context topDocs.stream() .map(doc - 文档ID: doc.getId() \n doc.getText()) .collect(Collectors.joining(\n\n)); return chatClient.prompt() .user(userQuestion) .system(以下是知识库内容\n context) .call() .content(); } }这段代码看起来简单但有几个细节值得展开。首先是检索的 TopK你肯定不能直接把 20 个文档全塞进上下文那会浪费 token、干扰模型注意力。所以我先取 20 个候选者再用重排模型精细打分最后只保留 5 个高质量块喂给模型。这个“宽召回、窄输入”的策略是 RAG 生产落地的标配。其次是结构化输出。上面的示例为了简洁直接取了 content但生产环境建议让模型输出带引用的 JSON 结构方便后端做校验和溯源。我通常会在 prompt 里显式要求输出 JSON并附带一个“无法回答时必须输出 need_human: true”的兜底规则。3.3 本地部署配置与成本预算前面讲过生产环境可以用混合架构。如果数据敏感度要求高需要本地部署那一定要先做硬件规划和验证。先讲显存估算这个有比较直观的计算方式。以 7B 参数的开源模型为例FP16 精度下模型权重约占 14GB 显存推理时还需要 KV Cache 等额外开销通常再留出 4 到 6GB。所以一张 24GB 显存的 GPU比如 3090 或 4090可以勉强跑推理但并发一高就会 OOM。如果你要部署 13B 甚至更大参数模型至少需要两张主流显卡或更大显存的卡。如果是高并发生产环境我建议用 vLLM 做连续批处理吞吐量会比原生推理提升不少。再给一个简单的本地部署配置方案参考场景模型规模推荐配置部署方式开发测试7B 以下单张 24GB 显存卡Ollama小规模生产7B~13B单张 48GB 或双卡vLLM中大规模生产13B 以上多卡 高速互联vLLM 分布式推理成本测算也不能马虎。假设每天有 1 万次提问每次输入输出加起来消耗约 3000 个 token一天的 token 消耗就是 3000 万。按 API 的价格算一天可能几十到上百美元一个月就上万人民币。本地部署则是一次性硬件投入加上电费、运维人力。算下来超过一定调用量后本地部署确实更划算但这个“平衡点”你要先算清楚别一上来就无脑走某一条路。3.4 前端快速验证用 Python Dash 搭一个简易演示界面如果你是一个后端团队不想为第一版演示页面专门配置前端环境Dash 是一个非常合适的选择。它的核心思路是用 Python 描述 UI 组件和回调函数服务端渲染浏览器端展示。一个最简单的聊天对话框大概是这样的import dash from dash import dcc, html, Input, Output, State import requests app dash.Dash(__name__) app.layout html.Div([ html.H3(知识库问答演示), dcc.Input(idquestion, typetext, placeholder请输入问题), html.Button(提问, idask-btn), html.Div(idanswer, style{marginTop: 20px, whiteSpace: pre-wrap}) ]) app.callback( Output(answer, children), Input(ask-btn, n_clicks), State(question, value) ) def ask_question(n_clicks, question): if not question: return resp requests.post(http://localhost:8080/api/ask, json{question: question}) return resp.json().get(answer, 无回答) if __name__ __main__: app.run(debugTrue, port8050)这一个文件就能跑起来。真正做产品时前端还是建议用 React 或 Vue 重写但前期验证业务效果、跑用户测评Dash 基本上是无脑省事的选择。这也契合了热搜词里“pythondash快速web应用开发”的使用场景——不追求豪华 UI快速把链路打通、验证业务价值。4. 生产环境避坑指北我把踩过的坑都写在这里4.1 响应延迟高、并发上不去先查链路哪一环慢了生产环境最典型的症状是接口变慢。很多人上来就怀疑模型推理慢但我吃过亏之后现在都是先看全链路 trace。请求进入后可能卡在四个环节网络传输、向量检索、重排模型、LLM 推理。举一个实际案例。有一个知识库问答服务用户反馈响应时好时坏平均延迟从 3 秒飙到 8 秒。我最初以为是模型并发受限但查了监控后发现是向量数据库在文档量从 10 万涨到 50 万之后索引没做增量重建导致检索耗时从 30 毫秒暴涨到 1.5 秒。优化索引重建策略后延迟立刻回落到正常水平。这个教训说明排查延迟问题不能凭感觉必须有全链路 trace 和指标。并发上不去也很常见。模型推理并发和显存强相关如果用 vLLM 做了连续批处理并发可以提升好几倍。另外对于内容相同或相似的问题加一层缓存能省下大量重复的模型开销。我一般用语义缓存——先对问题做 embedding再用向量检索去缓存命中相似度超过 0.9 就复用历史回答。实测下来热门问题的缓存命中率能到 20% 到 30%成本优化效果极其明显。4.2 模型答非所问、幻觉严重十有八九是检索质量的问题幻觉是 RAG 应用最让人头疼的问题。但根据我的经验大模型本身“编造”的占比其实没有想象中高更多的情况是检索返回的内容不对模型被错误信息“带偏”了。排查思路分三步。第一步在同一个 prompt 下人工抽查检索结果的准确性。如果前 5 个检索结果里有一半以上跟问题无关问题出在检索而不是模型。第二步检查切分和向量化。有一段法律文书语义相近的内容分布在不同章节切分后主题分散即使有相关块也排不到前几名。优化方式是把切分和标题结构结合起来在块与块之间做一定程度的邻接合并。第三步确认 TopK 和重排是否生效。如果候选集召回宽度不够相关块可能根本没进候选列表再加重排也没用。说到幻觉还要留意 prompt 层面的逻辑冲突。如果知识库里没有任何相关信息但模型基于自己的先验知识强行作答那本质上还是指令约束不够硬。我现在的兜底语句已经升级成“如果检索到的知识库内容与用户问题不直接相关请直接回复‘当前知识库未覆盖该问题建议联系人工客服’不要引用知识库中的无关内容。”4.3 上下文窗口溢出与 token 成本失控上下文窗口溢出的原因很简单——用户在多轮对话中不断提问历史消息加上检索内容很快就逼近模型的上下文上限。应对方式有三个层面截断、压缩、改写。截断最简单直接丢弃最早的历史消息。压缩是用 less 重要的信息替换掉长上下文比如把历史消息总结成一句摘要再拼回去。改写是针对检索结果的——把候选块做一次精简去掉重复段落保留核心信息再喂给模型。在生产项目里我常用的一种做法是维护一个“会话滑动窗口”。保留最近 4 轮对话原文更早的对话在每轮结束时异步调用轻量模型总结成摘要。这样既不用把全部历史塞进上下文也不容易丢失关键信息。token 成本失控的另一个重要原因是工具调用和 Agent 循环。一个 Agent 任务如果循环 5 到 8 次每次都要传全量上下文token 消耗是指数级上升的。所以Agent 的每一轮tool call后要主动裁剪掉不再需要的中间结果只保留必要信息。简单来说永远不要让模型看到它不需要的信息。4.4 安全与权限多租户场景下的数据隔离在多租户系统中A 客户询问 B 客户数据的场景是绝对不能发生的。这需要在 RAG 的检索阶段做权限过滤而不是在回答阶段拦截。一般做法是在向量数据库的每条文档记录上打上租户 ID 标签。查询时先从当前用户上下文推出租户 ID作为向量检索的必定过滤条件。以 Milvus 为例这通常通过 Partition Key 或布尔过滤表达式来实现SearchRequest.builder() .query(question) .topK(20) .filter(tenant_id customer_A) .build();这里的关键是权限过滤必须在检索阶段完成。如果你先做无差别检索再在提示词里叮嘱“你是 A 用户的助手不要看 B 的数据”那是拦不住的——模型即便不直接引用 B 的数据检索结果也可能已经被污染了。同时针对文件上传类应用还要做文件级权限的校验。简单说用户能检索到的内容必须是他有权限访问的内容。这个前置校验基准应该在数据入库时就明确而不是在请求时临时判断。4.5 内容安全红线与合规底线AI 应用上线前内容安全必须过审。这里说的不只是行业审核还包括你自己的业务安全策略。对不同来源的用户输入和模型输出都要做一轮内容风控识别并拦截违法违规、暴力、歧视或高风险内容。我在生产中一般加一道轻量敏感词和语义倾向检测层对输出内容做二次校验。模型答出来的内容即使技术上正确如果触及业务规制的“不可答范围”也必须走拦截或降级话术。这是 AI 应用在公开场景上线的底线。别觉得多一道检测是多此一举真出了事损失不是一个模块能挽回的。5. 上线后的事情评估、监控与持续优化5.1 离线评估与线上监控缺一不可很多团队把系统上线当作项目结束这其实是最大的错觉——AI 应用的项目生命周期上线才算真正开始。上线前必须先建立一套离线评估数据集。挑几类有代表性的问题比如简单事实问答、跨文档推理、否定表达、术语解释等每个问题准备好标准答案和对应文档范围然后评测 RAG 问答效果。指标可以用 RAGAS 的几项忠实性faithfulness、答案相关性answer relevancy、上下文精度context precision。在迭代时每改一次切分方式、embedding 模型或 prompt 模板都拿这套数据集回归一遍防止“修了东墙倒了西墙”。上线后监控又是另一套东西。必须记录以下指标调用量、错误率、平均响应时间、P95 延迟token 消耗和费用分布模型输出为空、超时、校验失败的比例检索无结果或低置信度的比例用户主观反馈、点赞点踩数据置信度阈值是一个非常实用的策略。模型输出中带 confidence 字段当置信度低于 0.5 时前端自动附加“该答案可能存在不确定性请人工复核”的提示。当低于 0.3 时甚至可以直接转入工单系统让业务专员介入。这套机制能显著提升用户信任感减少“AI 胡说八道”的负面口碑。5.2 数据回流让知识库和提示词持续进化AI 应用的持续优化最关键的是建立数据回流机制。每个用户的“不认可”反馈、每个转人工工单、每次低置信度回答都值得沉淀下来成为下一轮迭代的养料。实际操作中我会把用户的负反馈问题拉出来重新跑一遍检索链路看是否是检索环节丢了正确的文档块还是模型理解有偏差。如果是检索问题就调整切分策略或重排权重如果是模型问题就优化提示词、加 few-shot 示例。当某个类型的问题积累到一定量时才考虑用微调fine-tuning来解决。但注意能用提示词和检索解决的问题就不要轻易上微调——微调的迭代周期长、成本高、效果不稳定比如一个法律条款专业术语类问题通过提示词加术语表就能解决就没必要微调。关于微调和提示词的取舍再展开说一点。微调适合的场景是模型的输出格式和风格有固定要求、或者说需要学习特定领域的专业表达方式。但微调不能解决“模型不知道”的问题它不能为模型注入事实知识。所以“先 RAG 补充知识、再提示词约束行为、最后微调适配表达”这个先后顺序不要搞反了。5.3 聊聊这套体系还能怎么扩展这套知识库问答的工程化体系本质上是一个通用能力平台。往后扩展的方向非常多把单轮问答升级为多轮对话把“回答问题”升级为“执行任务”把知识库问答升级为业务系统的智能助理。每一步扩展都会引入新的工程挑战但底层的数据管道、检索策略、权限控制、监控体系、成本控制这套思路是可以复用的。比如把 RAG 能力嵌入 CRM 系统业务人员直接在客户详情页问一句“之前这个客户对我们的报价有什么反馈”系统自动检索并给出带引用的答复。技术架构不变只是把交互入口换了一下。再比如用 Agent 做一个单据自动审批助手调取订单、库存、财务数据生成审批建议最终由人工一键确认。这背后的工具调用、人工审核节点、日志回放我们在前面已经很扎实地实践过了。最后分享一点个人的体会如果你刚起步不要想着一步到位把所有生产级能力都堆上去。先把一条完整的链路跑通——文档解析、切分、向量化、检索、重排、大模型生成这是地基。地基稳了再往上面叠加 Agent、缓存、监控、权限这些工程能力。我见过太多团队地基都没打牢就急着研究高深的智能体编排和模型微调最后上线时被最基础的检索质量击穿。回想做那些项目的日子真正让我觉得“落地了”的时刻不是某个炫酷功能的演示效果而是系统稳定跑了几个月、成本控制住了、用户愿意每天都用。AI 应用开发模型能力是上限工程能力是下限。想在生产环境里拿到结果就得多花时间在下限上下功夫。