企业官网建设流程全解析

先说一个我最近特别深的感触：AI全栈开发，绝对不是“会调API + 会写前端 + 会写后端”那么简单的三件套。它更像是一条横跨需求拆解、模型选型、RAG搭建、Agent编排、模型部署、效果评估和线上监控的完整链路。你可以在某一段上深耕，但如果你想把一个AI应用从想法真正落到生产环境，每一段都得趟一遍。这篇文章我想以“AI全栈开发最佳实践”为主线，把我从几个真实项目里沉淀下来的方法、参数和踩坑记录完整拆给你看。不管你是正在转型的Web开发、刚上手的AI应用开发，还是已经在做AI Agent但总觉得工程化缺口气的团队，这篇应该都能给你一些直接能用的东西。

1. 先搞清楚：AI时代的“全栈开发”到底多了什么

我先说个观察。过去我们聊全栈开发，默认是“前端 + 后端 + 数据库 + 部署运维”，一个人能把MVVM页面、RESTful接口、MySQL索引、Nginx反向代理这些串起来，就算很能打了。但到了AI应用这个阶段，事情变了。

传统的全栈技能仍然是底盘，但在它之上新长出来一层东西：你要懂模型能力边界，知道什么任务该用多大参数的模型；你要会做提示词工程，但不只是写几句好话让模型听话；你要搭RAG流程，涉及文档切分、向量召回、重排序；你要设计Agent的工具调用和权限边界；你还得处理模型部署、推理加速、限流降级、成本监控。这一整套，才是AI全栈开发的全貌。

我见过不少团队，代码写得很干净，但一接大模型就懵：要么是拿到需求直接写prompt，上线后被用户问几句就露馅；要么是把模型部署在GPU裸奔，没有QPS概念，一压测就超时；要么是Agent的工具调用没有任何限制，模型一个幻觉就调了不该调的接口。这些问题的根源，都是只看到了AI全栈里某一个亮点，没有把整条链路当成一个系统来设计。

所以我把AI全栈开发的实践路径拆成四个核心模块来聊：

• 需求侧：判断什么该用模型、什么不该用模型
• 应用侧：提示词、RAG、Agent编排的工程化落地
• 部署侧：模型推理、AI Infra和成本控制
• 质量侧：测试、监控和持续迭代

下面每一块我都会给出具体步骤、参数参考以及我实际踩过的坑。这篇文章不会讲怎么从零训练一个模型，那是一个更重的领域，AI全栈开发的核心场景是把现成的模型能力转化成稳定的产品。

2. 需求拆解与选型：不是所有问题都要上大模型

我见过最贵的浪费，就是把GPT级别的模型用在一个“if/else”就能解决的问题上。有一次一个业务方找我，说要做一个“智能合同审核”，要求大模型判断合同里有没有“付款条款”。我看了他们已有的合同格式，发现所有付款条款都有固定标题，用正则匹配就能搞定，准确率100%，而且延迟是零。后来我们只在前端加了一个规则引擎，整个项目从两周缩到半天。

这不是段子，而是AI全栈开发里最容易被忽略的一个环节：需求拆解。你要先回答一个问题——这个任务的核心是“理解并生成”，还是“检索并匹配”？

我自己的决策框架是这样的：

在确认“确实需要大模型”之后，才轮到模型选型。这里有三条路径：

1. 商业模型API：开发最快，效果通常最好，适合验证期和中小流量产品。按token付费，功能迭代快，多模态、长上下文这些能力接上就能用。
2. 开源模型私有化部署：适合数据不能出域、隐私要求高、需要深度定制或者长期token消耗非常大的场景。
3. 开源模型 + 云托管推理平台：相当于API的无服务器版本，没有自建GPU的运维成本，又保留了一定的模型自由度。

选型时我一般会列一个对比维度，用真实业务数据来测，而不是只看跑分：

• 上下文长度需求：如果你的业务需要读完一整份50页的合同，API模型会舒服很多；开源模型的上下文虽然也在拉长，但长文本下的召回率和生成稳定性还要实测
• 延迟要求：交互式Agent可能需要5秒内返回，离线批量分析可以接受60秒
• 成本结构：API按token计费，自托管要考虑GPU折旧、电力、运维人力
• 数据合规：哪些内容绝对不能发给第三方API

这里我强烈建议一个动作：不要拿着需求说明书去选型，而是先抽取10条最典型的真实输入，用两三个候选模型跑一遍，手工评估输出质量、延迟和token开销。这个过程我们叫spike，基本半天到一天时间，能帮你省掉后面数周的返工。

3. 从原型到工程化：AI应用开发的完整链路

选完模型之后，很多人会直接冲进prompt调试，但我建议先把应用的输入输出接口定清楚。这一步做不好，后面换模型、调参数全乱套。

3.1 先定义接口，再定义prompt

我做的第一个AI项目，上来就写了一段又长又花哨的prompt，结果前端、后端、模型三层接口全是人肉约定。后来才发现，AI应用的接口设计比普通CRUD更重要，因为模型输出是开放式的，必须有明确的协议来约束。

我的做法是：先定义外部API的请求和响应结构，再倒推prompt需要输出什么格式。比如做一个文档问答助手，响应结构大概是：

{ "answer": "根据合同第3条，付款周期为30天。", "sources": [ { "doc_id": "contract_2024_001", "chunk_id": 15, "page": 3, "text": "乙方应在验收完成后30天内支付全款。" } ], "confidence": "high" }

有了这个契约，prompt里就可以明确要求：“必须输出JSON对象，格式为{answer, sources, confidence}，如果无法回答，answer字段必须为‘无法从文档中获知’。”这样下游解析稳定，不会出现模型自由发挥的情况。

3.2 提示词工程的“结构化复利”

很多提示词教程都在教“怎么写得更像人话”，但工程上的提示词其实是半结构化的配置文件。我习惯把提示词拆成五个板块：角色、任务目标、输入上下文、输出约束、示例。尤其是示例，几个few-shot往往比长篇规则有效得多。

这里有个我踩过的坑：示例必须覆盖“边界情况”。比如你想让模型知道“找不到答案时直接承认”，你就要在示例里故意放两条查不到的内容，而不是只给它看标准答案。否则模型倾向于编造，这是我们做知识库问答时最头疼的“幻觉”问题之一。

3.3 RAG链路：别只做“向量化 + 相似度检索”

文档问答类应用基本都会上RAG，但RAG的坑比想象多。一个标准的RAG链路是：

1. 文档加载
2. 文本切分
3. 向量化
4. 召回
5. 排序/重排
6. 组装上下文
7. 生成回答

很多Demo只做到“切分 -> 向量化 -> topK召回”，就以为完事了。实际上召回质量受两大因素影响：切分策略和重排策略。

切分参数：我最常用的参数是chunk_size=512，chunk_overlap=100，但这只是起点。如果文档是技术手册，小节之间语义跳跃大，建议按标题结构切分；如果是合同条款，按“条”切分远好于固定字符数。切分后的每一块，最好保留文档元数据（来源、页码、标题路径），这样后面能做到可溯源的引用。

向量化模型：开源常见的embedding模型足够应对中文场景，但要注意它的最大输入长度。有些模型最长只有512个token，超过会被截断，你的chunk切再合理也没用。

重排：召回后别直接把topK塞给大模型，先过一道重排模型效果会稳定很多。重做的时候把初召回数量加大（比如召回20条，重排后取前5条），能显著减少噪声。

给一个可以直接抄的查询侧骨架，用OpenAI兼容接口接本地服务：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="EMPTY" ) def rerank(query: str, documents: list[str], top_k: int = 5): # 这里可以接一个rerank服务的HTTP接口 resp = requests.post("http://localhost:8890/rerank", json={ "query": query, "documents": documents, "top_k": top_k }) results = resp.json() return [doc["index"] for doc in results["results"]] def answer(query: str, top_k_docs: list[dict]): context = "\n\n".join([ f"[{i}](来源:{doc['source']}) {doc['text']}" for i, doc in enumerate(top_k_docs) ]) prompt = f"""你是企业内部知识库助手。请严格根据下方资料回答问题。 如果资料中没有答案，请直接说“无法从现有文档中获知答案”，不要编造。 资料： {context} 问题： {query} 请以JSON格式输出：{{"answer": "...", "sources": [...]}}""" resp = client.chat.completions.create( model="qwen2.5-14b-instruct", messages=[{"role": "user", "content": prompt}], temperature=0.2, max_tokens=512, response_format={"type": "json_object"} ) return resp.choices[0].message.content

这里有几个工程细节：

• temperature=0.2是为了让问答任务尽量稳定，而不是让模型更有“创意”
• response_format={"type": "json_object"}，很多开源模型也支持JSON约束输出，能极大降低解析报错率
• 上下文里保留“来源”字段，模型才会在sources里带上出处

3.4 Agent编排：工具调用的边界比能力更重要

如果说RAG是AI应用的“知识层”，那么Agent就是“行动层”。AI Agent的爆火不是没有原因的，它让模型从“回答问题”走向“完成任务”。但Agent的工程化，难点不在怎么让模型调用工具，而在怎么让模型“安全地”调用工具。

我做Agent项目时的配置顺序是：

1. 列出任务可能需要的工具清单
2. 为每个工具编写严格的JSON Schema声明
3. 明确每个工具的权限级别
4. 设定调用上限和人工确认节点

给一个工具声明示例：

{ "type": "function", "function": { "name": "send_email", "description": "发送邮件给指定收件人。仅允许发送给公司内部员工。", "parameters": { "type": "object", "properties": { "to": { "type": "string", "pattern": "^[a-zA-Z0-9._%+-]+@company.com$", "description": "收件人邮箱，必须为公司内部邮箱" }, "subject": {"type": "string", "maxLength": 100}, "content": {"type": "string", "maxLength": 2000} }, "required": ["to", "subject", "content"] } } }

注意description里直接写了“仅允许发送给公司内部员工”，配合正则校验，相当于在prompt层面和代码层面做了双重约束。Agent应用永远不要只依赖模型“听不听话”，而是在工具API侧做彻底的权限校验。

另外，我给所有Agent应用都加了“步骤上限”，默认最多5轮工具调用循环。防止模型在某些任务里进入死循环，token像水一样烧掉。

3.5 工作流编排：什么时候串行，什么时候并行

有些AI应用是单次请求，比如“请总结这份合同”；有些则是多阶段任务，比如“先拉取数据，再生成图表，再发送报告”。后者需要工作流编排。

我个人的原则是：能编排就别让Agent自由发挥。Agent适合工具选择多、决策路径不固定的场景；如果业务流程固定，比如“上传文件 -> 解析 -> 审核 -> 反馈”，就用传统的工作流引擎把每一段串起来，在关键节点调用LLM能力，而不是把整个流程控制权交给模型。这样定位问题也容易得多——哪一步挂了，看日志就知道，不需要让模型去“复盘”自己刚才干了什么。

4. 模型部署与AI Infra：把模型真正跑起来的那点事

模型部署是AI全栈开发和传统Web开发差异最大的一块。很多后端老手第一次碰到“显存不够”“并发一高就OOM”时，都会懵。这一节我重点讲推理部署、显存估算和成本控制。

4.1 先算清楚显存，再决定买什么卡

很多人第一反应就是“上最好的GPU”，但实际上不同规格的模型对显存的需求差异非常大。估算公式很简单：模型权重大小 ≈ 参数量(10亿) × 精度字节数。

我整理了一个常用的参考表：

如果是个人开发机跑7B、14B模型，用4bit量化可以大幅降低显存占用。比如14B模型4bit量化后权重只有8GB左右，一张24GB的卡就能跑起来，效果损失在可接受范围内。我的经验：对话、写作类任务，4bit量化影响比较小；代码生成、数学推理类任务，会明显感到输出质量下降。

4.2 推理服务：用vLLM或Ollama，别再写裸推理脚本了

我见过有人直接用Transformers写模型推理，不过对于生产环境，有几个高并发问题：一个请求一个请求排队，GPU利用率上不去，也不能处理批量调度。后来我全换成了vLLM，它是目前比较成熟的开源推理服务框架，支持Continuous Batching、PagedAttention、与OpenAI兼容的API接口，接入成本很低。

启动方式大概是这样：

vllm serve qwen2.5-14b-instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --served-model-name qwen2.5-14b-instruct

启动之后，应用侧就直接用OpenAI SDK把base_url指到这台机器的http://localhost:8000/v1，前面给出的完整链路就能接上了。

--gpu-memory-utilization 0.9这个参数也是我踩坑之后才注意到的。默认值会让模型只预留很少的KV Cache空间，并发一高就报显存不足。后来我调到0.85到0.9之间，相同显存下吞吐能提升不少。

4.3 API网关、限流和成本控制

模型服务上线后，还要过“API网关”这一关。如果应用同时接了多个模型服务（比如一个负责对话、一个负责向量化、一个负责重排），它们各自的负载和限流策略又不一样，直接用原始服务地址对外部暴露非常危险。

我的做法是在模型服务前面加一层统一网关，负责四件事：

1. 统一鉴权：外部请求只认网关的AK/SK，不直接碰模型服务
2. 限流降级：按用户、按接口维度配置QPS和并发限制
3. 缓存：对于相同或近似请求，可以做语义缓存，命中后直接返回此前结果，能省不少token
4. 灰度切换：新模型版本上线时，先切5%流量观察，有问题再回滚

成本方面，我有两个习惯：一是每次请求都记录token消耗，按用户、按功能模块汇总，这样每天能看清钱烧在哪；二是对常见问题做“静态答案缓存”，答案更新频率低的问题没必要每次都调用模型。

需要重点提醒的是：模型服务是状态相关的服务，和普通Web服务的健康检查逻辑不太一样。不能只看进程活没活着，还要看显存是否被打满、平均首token延迟是否漂移。我一般是每分钟检查一次/metrics，超过阈值就摘掉节点并发告警。

5. AI应用的测试、监控与持续迭代

很多团队的AI应用上线后，第一版效果不错，第二周就变差了。这不是模型“变笨了”，而是缺少了一套针对AI应用的质量保障体系。

5.1 LLM应用测试和传统测试的差异

传统后端测试断言很明确：输入A，输出B，校验B是否等于B。但大模型的输出是开放式、概率性的，你没法断言“模型这句话一定对”。所以AI应用的测试体系要分两层：一层测工程逻辑，一层测模型效果。

5.2 离线评估集：AI应用质量的压舱石

我强烈建议，从项目第一天起就建一个评估集。不需要很大，50条高质量样本就能发挥巨大作用。每一条样本长这样：

{ "query": "合同里的付款周期是多久？", "expected_points": ["验收完成后30天"], "expected_sources": ["contract_2024_001"], "difficulty": "easy" }

之后每次改prompt、换模型、调切分参数，都拿这套评估集跑一遍，用脚本比对模型输出里是否包含expected_points中的关键点，以及sources是否对得上。这种自动化回归能拦住绝大多数“改好了A问题，带崩了B问题”的情况。

我还用过一种更细的评估方式：让模型当裁判，用另一个模型给输出打分。但注意，这种“LLM-as-a-judge”只适合做初筛，关键业务还是得过人工这一关。

5.3 线上监控：盯住这几个指标就够了

线上监控不需要一开始就铺很大，我认为核心指标就这些：

• 请求成功率：模型服务本身挂了还是网关限流了
• 首token延迟 / 完整响应时间：首token延迟更能反映用户体感
• 空回复率 / 拒答率：如果“无法回答”的比例异常升高，可能是RAG召回全面失效
• 平均每请求token数：突然暴涨，往往意味着提示词上下文拼接有问题
• 用户反馈：在对话流里加入“有帮助 / 无帮助”按钮，成本低，数据价值极高

我还在日志里额外打了一个字段：retrieved_chunk_score，用来记录重排后最高分是多少。如果连续大量请求的最高分都很低，说明知识库里没有对应内容，应该触发“知识库补档”的提醒，而不是等用户来抱怨。

5.4 持续迭代的正确姿势

AI应用上线只是开始。我的迭代流程是这样的：

1. 收集线上badcase和用户反馈
2. 人工分析问题归类：是检索不到、上下文丢失、模型理解错误，还是知识库本身没有
3. 针对类别做修复：检索问题改切分/召回/重排；生成问题调prompt或换模型；知识库问题补文档
4. 每轮修复后跑离线评估集，确保没有回归
5. 灰度上线，对比线上指标

每一个循环大概1-2天，比传统开发要快很多。这是AI应用开发最需要习惯的节奏：小步快跑，持续校准。

6. 一次AI全栈项目的真实时间线复盘

最后我用一个真实项目把前面所有内容串起来。这是一个企业内部的合同问答助手，需求是：用户上传一份合同，AI需要回答关于合同条款的问题，并且答案必须能回指到合同原文。整个项目从启动到上线用了5周，人员只有我和一个兼职前端。

第1周做的是需求澄清和spike。我们把业务方给的一百多份真实合同跑了一遍，发现大部分是带标准模板的采购合同，也有少数非常规的补充协议。这个发现直接影响了切分策略：标准模板按条款切分，补充协议按段落切分。这一周我们完成了模型选型和评估集初版20条。

第2周搭RAG链路。文档上传、切分、向量化、召回、生成全流程跑通。前端只做了一个极简的聊天界面，用于内部测试。这一周踩了一个印象深刻的坑：向量化模型的输入长度是512token，我们嵌入了大量超长chunk，导致后面检索效果奇差。定位问题的过程就是看retrieved_chunk_score，发现很多查询的召回分数都很低，然后逐步排查到切分长度设置。

第3周做Agent增强。业务方提了个新需求：如果合同里有金额单价，想直接问“这批货总价多少”，系统要自动判断合同里是否有计算公式。这个需求单靠RAG做不好，因为要结合表格甚至是附件。我们给Agent加了一个“表格抽取”工具，模型在判断“直接从文本中找不到”之后调用工具，再带着结构化数据生成结论。

第4周部署上线。当时我们评估过直接接商业API和自己部署开源14B模型的成本。最后选择了自托管+量化的方案，原因是合同数据不能出域。我们在内网GPU机上用vLLM部署了量化版模型，并在前面加了一层网关做限流和计费统计。这一周的主要工作其实是压测和调参：QPS从最开始的2提升到15，首token平均延迟压到了1.5秒。

第5周做质量闭环。我们把线上badcase导出来逐条分析，发现一个规律：真正的问题大多数不在生成环节，而在召回环节——相关条款没有被检索出来。我们把初召回从10条提到20条，再引入重排模型，效果就有了明显提升。最终离线评估集上的通过率从78%提升到了93%。

这个项目走下来，我最大的感受是：AI全栈开发，真正难的不是哪个单点技术，而是整条链路的均衡。RAG做得再好，部署高并发不行；Agent写得再聪明，没有评估集兜底；提示词写得再漂亮，知识库里没有对应内容——任何一个短板都会拖垮整个应用。

最后分享两个个人习惯。第一，我始终保留着一个本地脚本，能一键把某个输入跑完“检索 -> 重排 -> 生成 -> 评分”全流程，改任何模块后都在跑一遍，让自己心里有数。第二，我每天会固定看一眼线上token消耗报表，如果某个功能召回率下降或token异常飙升，往往不是模型问题，而是上游文档或者生产环境数据变动了。保持这种“全链路敏感度”，大概就是AI全栈开发最核心的素养了。