企业官网建设流程全解析

1. 先想清楚：AI技术栈为什么需要"五层结构"

这几年AI领域的爆发式发展有目共睹，从大模型刷榜到各类AI应用落地，行业里几乎每天都有新东西冒出来。但我在实际带项目、做技术选型的时候发现一个很尴尬的问题：很多团队和个人开发者，手里工具一堆、模型一堆，真正要搭一个能上线、能迭代、能赚钱的AI应用时，却不知道从哪里下手。

"AI五层结构"这个概念，算是我在多次项目复盘后总结出的一套技术栈分层方法。它不是某个官方标准，而是把AI应用从底层到顶层拆成五个层次：算力基础设施层、模型与算法层、框架与工具链层、应用与交互层、业务与产品层。每一层干每一层的活，层与层之间通过标准接口衔接，上层不关心下层的实现细节，下层不为上层的业务逻辑买单。

为什么要做这种分层？有一个特别直观的类比：你去盖一栋楼，不可能把钢筋、水泥、水管、电线、家具全部混在一起浇筑。你一定是先打地基，再搭框架，然后走管线，再装修，最后摆家具。每一道工序有明确的交付标准和验收条件，出了问题也能精准定位到是哪个环节的责任。AI技术栈其实也一样，模型选型出问题，你不需要去翻代码；应用层逻辑出问题，你也不必重新训练模型。

这篇文章我会把这五层结构逐一拆开讲，包括每一层具体包含什么、选型时怎么思考、我在实操中踩过哪些坑，以及每一层目前主流的工具和方案是什么。如果你正在规划一个AI项目，或者想把现在混乱的AI代码库重新整理一遍，这篇文章应该能给你一个比较完整的参考框架。

2. 第一层：算力基础设施——整个体系的"地基"

2.1 这一层到底在解决什么问题

算力基础设施层是整个AI技术栈最底下的部分，包含GPU/CPU服务器、云资源、存储、网络带宽以及底层的运行环境（比如CUDA、Docker、Kubernetes等）。没有这一层，上面的一切都是空中楼阁。

很多人会忽视这一层的重要性，觉得不就是买台服务器嘛。但实际上，AI项目的算力基础设施决策，往往会影响到后续几个月甚至几年的开发效率和成本结构。举几个我在实际项目中遇到的问题：

一是显存不够。训练或者部署一个大模型时，模型权重、中间激活值、优化器状态全都要吃显存。比如一个7B参数的模型，FP16精度下光权重就是14GB，再加上推理时的KV Cache、临时张量，一张24GB的消费级显卡跑起来非常勉强。这还只是推理，如果要微调，激活值和梯度会成倍增加。

二是I/O瓶颈。很多人只盯着GPU的算力，忽略了数据读取和模型加载的I/O速度。实测下来，如果从机械硬盘加载一个13B的模型文件，光等模型载入就要好几分钟，而如果用NVMe固态并配好内存缓存，十几秒就能搞定。

三是弹性扩缩容。业务量是有波峰波谷的，白天用户多、晚上用户少。如果用的是固定物理机，要么在高峰时性能不够，要么在低峰时白白浪费算力。用容器化加自动伸缩可以省下不少成本，但这也要求底层基础设施足够标准化。

2.2 算力选型：云上还是自建

算力选型主要看三个方面：预算、规模、以及对数据隐私的要求。

对于个人开发者或者小团队，我建议优先考虑云GPU方案。目前主流云厂商都提供了按小时甚至按秒计费的GPU实例，比如腾讯云、阿里云、AutoDL等都有比较灵活的方案。以我常用的配置为例：单卡A100 80G或者H800，跑13B以下的开源模型推理完全够用，部署成本相比自建物理机要低很多。

对于数据敏感或长期大规模训练的场景，自建机房或托管IDC更划算。这里有一个简单的计算思路：如果一台8卡A100服务器的年租赁费用高于三年总折旧加电费运维成本，并且你的GPU利用率能稳定在60%以上，那自建物理机更划算；反之，用云节点更灵活。

模型推理的显存计算公式可以提前记一下：

显存需求 ≈ 模型参数量 × 每参数字节数 × 系数

其中，FP16精度时每参数2字节，INT8量化后每参数1字节，INT4量化后每参数0.5字节。系数通常在1.2~1.5之间，用于覆盖KV Cache、临时计算图和框架开销。比如一个7B参数的模型，FP16部署最低显存约 7×2×1.2 = 16.8GB，考虑到实际运行余量，建议用24GB以上的卡。

我在实际项目里还有一个心得：如果只是做推理部署，优先考虑量化后的模型。用GPTQ或AWQ量化到INT4，7B模型显存占用能压到5~6GB，推理速度反而因为显存带宽瓶颈降低而有所提升。很多开源模型在INT4量化下的精度损失不到1%，对业务影响几乎可以忽略。

2.3 部署环境：容器化是底线

不管你用云还是自建，我都强烈建议从第一天开始就用Docker容器化部署。AI项目的环境依赖太复杂了，Python版本、CUDA版本、cuDNN版本、PyTorch版本，任何一个不匹配都可能跑不起来。容器化之后，你可以把一套验证过的环境完整打包，换机器部署时直接拉起，不再重演"在我电脑上是好的"这种尴尬。

更进一步的方案是Kubernetes集群管理。当你有多个模型服务、需要自动扩缩容或者做灰度发布时，K8s的价值会非常明显。但要注意，K8s的学习和维护成本不低，如果项目规模不大，用Docker Compose配合简单的负载均衡就足够了，不必一上来就上K8s。

3. 第二层：模型与算法——技术栈的"发动机"

3.1 模型选型的核心逻辑

模型层是整个AI技术栈中最核心的部分，也是目前行业变化最快的一层。GPT、Claude、Gemini等闭源模型持续迭代，Llama、Qwen、DeepSeek、GLM等开源模型也在快速跟进。选模型不是越强越好，而是越合适越好。

我一般会从这几个维度来评估模型选型：

• 任务类型：是文本生成、代码补全、对话问答、多模态理解，还是Agent规划？不同模型在不同任务上的表现差异很大。
• 参数量级和资源约束：7B、13B、70B还是更大？这直接决定你需要多少算力资源。
• 响应延迟要求：实时的Agent交互可能需要低于1.5秒的响应，这要求模型推理速度足够快，量化或小模型往往是更好的选择。
• 数据安全和隐私要求：如果你的业务数据不允许出域，就只能选择可以私有化部署的开源模型。
• 成本模型：按Token计费的闭源API，在频繁调用场景下成本积累很快；开源模型自部署前期投入高，但边际成本低。

我在实际项目中的默认选择是：优先用国内的开源模型，比如Qwen系列的72B版本或者DeepSeek系模型。原因无他——中文能力强、上下文够长、社区生态活跃，关键是私有化部署没有合规和成本顾虑。如果业务对英文生成有更高要求，再考虑引入Llama系列或者直接调闭源API。

3.2 微调、RAG还是Prompt Engineering

确定模型之后，紧接着的问题就是：怎么让它适配自己的业务？目前主流的路径有三条：微调（Fine-tuning）、检索增强生成（RAG）、以及提示词工程（Prompt Engineering）。这三条路线不是互斥的，而是可以组合使用。

对于大多数业务场景，我建议先做好提示词工程和RAG。原因很现实：微调需要高质量、大规模的领域数据，还要投入GPU训练资源和运维精力，做不好还可能让模型出现灾难性遗忘。而RAG的思路是"模型负责生成，检索负责知识"，把最新、最准确的业务知识放到向量数据库里，用户提问时先检索出相关内容，再把内容拼进上下文里交给模型生成答案。

我做过一个企业知识库问答系统，初始版本就是纯提示词工程加RAG。我们把几千篇企业制度文档切分、向量化后存入向量数据库，查询时召回TopK相关片段，再配合提示词模板让模型基于检索结果回答。这个方案上线后准确率在90%以上，而且文档更新时只需要重新入库，不需要动模型，维护成本非常低。

那什么时候才应该做微调呢？我总结下来是三类场景：一是模型的输出格式有强约束需求（比如必须输出特定JSON结构）；二是模型需要掌握专属的术语体系和逻辑规则（比如医疗诊断、法律条文）；三是业务数据量足够大且标注质量可控。如果这三条都不满足，微调大概率不是最优解。

3.3 模型评估——很多团队欠下的债

模型层最容易忽略的是评估环节。很多团队把模型接进来、跑通demo就上线了，结果到真实场景中就各种翻车。我建议在项目一开始就建立一套评估集和评估标准，用一组固定的测试问题来度量模型每次迭代的效果。

评估维度可以参考这几个方面：回答准确率（是否正确）、相关性（是否回答了用户的提问）、完整性（是否遗漏关键信息）、格式合规性（JSON输出是否能被直接解析）、目标指令跟随度。每个维度按1~5分打分，多个测试样本取平均值。迭代模型版本时，用同一批测试集跑分对比，选型就有据可依了。

4. 第三层：框架与工具链——连接模型和应用的"高速公路"

4.1 从裸调API到Agent框架

模型层之上是框架与工具链层。早期开发AI应用，说白了就是用HTTP请求调API，把用户输入拼进Prompt，拿到输出再拼回界面。这种做法在简单的问答场景下够用，但随着应用复杂度提升，尤其是引入Agent、多步骤规划、外部工具调用等场景后，纯手写代码的效率就太低了。

这里就轮到各种框架出场了。目前比较主流的有LangChain、LlamaIndex、Spring AI、AutoGen、Dify等，各有各的侧重点：

• LangChain：老牌Agent编排框架，组件生态丰富，适合复杂的链路设计和工具调用。但抽象层级多，调试起来需要耐心。
• LlamaIndex：更侧重于数据连接和RAG流程，处理文档索引、检索、重排等环节非常顺手。
• Spring AI：如果你是Java技术栈，这个框架值得关注。它是Spring生态官方的AI接入方案，抽象了一套对接大模型的统一接口，对Java开发者非常友好。我在一个企业内部工具项目里用它对接了大模型API，原本要写很多胶水代码，用Spring AI后代码量缩减了一半以上。
• Dify：开源的应用开发平台，可视化编排工作流，适合快速做产品MVP，也支持接入私有模型。
• AutoGen：微软出品的多Agent对话框架，适合Agent之间协作、互相交流来完成任务。

框架选型我有一条经验和大家分享：不要迷信框架，框架是工具不是目的。如果你的场景只是单轮问答加简单检索，直接用HTTP请求调用API，代码反而更清爽；如果需要复杂的Agent规划和多工具协同，再引入框架不迟。

4.2 RAG链路的核心组件

RAG链路是当前AI应用的主流范式，其核心组件我梳理一下：

• 文档解析和清洗：把PDF、Word、HTML等格式的文档解析成纯文本，去除页眉页脚、目录、水印等噪音。这一步最容易被低估，但实际效果影响很大，垃圾进垃圾出。
• 切分策略：文档切分长度和重叠度直接影响召回效果。我常用的经验值是：按512~1024个Token切分，切分之间保留64~128个Token的重叠，避免语义被打断。
• 向量化Embedding模型：把文本转换成向量，用的时候计算余弦相似度。国产方案推荐BGE-M3，多语言效果好，对中文特别友好，而且支持长文档。
• 向量数据库：用于存储和检索向量。可选方案有Milvus、Qdrant、Chroma、pgvector等。数据量不大（百万级向量以内）用pgvector就好，可以复用PostgreSQL；数据量大再考虑Milvus或Qdrant。
• 重排序：初次召回Top50，再通过重排序模型（比如BGE-Reranker）精排到Top5-10，可以明显提升问答质量。

4.3 代码生成与AI编程工具

模型层和框架层之外，还有一个容易被忽略的工具层角色——AI编程工具。从热词里可以看出，"AI编程""AI编程工具""AI coding"关键词热度非常高。这一层本质上是利用大模型的能力辅助人类开发。

目前我用得比较多的是GitHub Copilot、Cursor以及Qwen Code系列的本地代码模型。实测下来，AI编程工具在以下几类场景中提升效率非常明显：写单元测试和常规CRUD代码、根据注释生成函数实现、正则表达式和脚本编写、SQL查询生成等。

但AI编程也有明显的坑：AI生成的代码看似正确，实则可能存在边界条件遗漏或逻辑漏洞。我的习惯是：AI生成的代码必须经过Code Review和现有测试用例验证才能合入主分支。尤其是涉及资金、数据安全等核心逻辑时，绝不能直接信任AI输出。

5. 第四层：应用与交互——从模型能力到用户价值

5.1 AI应用的产品形态分类

上面三层解决的是"模型怎么跑起来"的问题，到了应用与交互层，关心的是"模型怎么被用户用起来"。

目前的AI应用产品形态大概可以分成几类：对话式应用（ChatBot）、Agent应用（自主完成多步任务）、内容生成工具（AI绘画、AI漫剧、AI短剧、AI视频）、辅助创作工具（AI写作、降AI率工具）、嵌入式AI功能（页面上的智能搜索、智能客服）。

对话式应用是目前最主流也最好上手的形态。核心是管理好对话上下文、系统提示词和用户消息的区分。我做一个企业客服机器人的时候，在提示词里固定了角色设定、回答风格、可参考的知识库引导和兜底话术，实测下来用户满意度提升了30%以上。

Agent应用的区别在于它会主动规划和执行任务，比如"帮我查一下这个行业近三年的市场规模，并写一份分析报告"。实现方式可以用ReAct模式或Plan-and-Execute模式，模型先生成行动计划，再逐步执行工具调用。也可以直接用Coze、Dify等平台的可视化Agent编排，降低开发门槛。

5.2 交互设计中的AI特有注意事项

AI应用的交互设计和传统软件有不少差异。我这几年总结出几条经验：

一是响应速度的体验设计。大模型推理在顶尖GPU上也要几百毫秒甚至几秒，不能像普通API请求那样等结果回来再显示。实践中常用流式输出（流式输出），让用户看到文字一个字一个字地生成，配合"正在思考"的动效，体验会好很多。实测下来，同样2秒的响应时间，有流式输出方案的用户跳出率远低于无流式方案。

二是上下文长度的管理。大模型的上下文窗口是有限的（常见的从8K到256K不等），而且上下文越长，推理延迟和费用越高。为了避免"聊着聊着就忘了前面说过什么"，需要自己做上下文管理：截断早期对话、用摘要压缩历史、或者只保留与当前轮次相关的片段。

三是无限制条件下的边界约束。从热词中可以看到，"无限制AI""无审核AI"这类词搜索量很大，但我要提醒大家：这里说的"限制"应该是产品定位层面的差异化，而不是突破价值观和合规底线。在真实的AI应用设计中，内容安全始终是底线，过滤机制和系统提示词约束必不可少。任何一个有责任感的开发者在做AI产品时，都应该把这个问题放在最优先的位置考虑。

5.3 AI应用的后端架构

AI应用的后端架构相比传统后端多了一个核心代理层：用户请求先到达业务服务，业务服务再调用模型服务并管理上下文。我常用的架构模式是：

• 接入层：API网关负责鉴权、限流、日志记录。
• 业务服务层：处理具体业务逻辑、会话管理、用户状态。
• AI编排层：调用模型API、管理提示词模板、执行RAG检索、编排Agent流程。
• 模型服务层：可能是外部API，也可能是自部署的推理服务。
• 数据层：业务数据库、向量数据库、缓存（Redis）。

这样分层的好处是每层可以独立扩展，模型服务访问量大了就多起几个实例；编排层状态多了可以做水平扩容；接入层的限流也可以在模型服务过载时保护系统。

6. 第五层：业务与产品——技术价值的最终出口

6.1 商业模式设计

模型能力再强，最后还是要落到业务层面回答一个问题：这个AI应用凭什么让用户付费？

目前主流的商业模式有这几种：按订阅收费（按月或按年）、按使用量收费（按Token或按调用次数）、按服务收费（定制化交付）、以及按分成模式（嵌入到实际业务场景，比如电商AI导购按转化成交提成）。

一个比较现实的经验是：纯模型API转卖的模式利润空间非常薄，因为上游模型API定价随时可能降。真正有定价权的是在你自己的业务场景中利用AI创造了明确增量价值的场景。举个例子，做AI客服系统，用户愿意付费不是因为客服接入了大模型，而是因为人工客服的人力成本降了50%。AI是手段，降本是效果，用户为效果付费。

6.2 测试与质量保障

AI应用的测试比传统软件要多一个维度——不仅要测功能正确性，还要测模型的输出质量。我在实际项目中推行的做法是：

• 单元测试和集成测试照常做，覆盖率不低于70%。
• 增加模型输出质量测试：用一组固定的测试用例跑提示词模板，断言输出包含预期关键词、输出JSON格式可解析。
• 上线前进行回归测试：模型升级后，用历史问题集回归验证，确保能力没有回退。
• 建立用户反馈闭环：在页面上提供"回答是否有帮助"的反馈按钮，数据回流后定期分析和优化。

6.3 运维与监控

AI应用上生产后的运维比传统服务复杂，主要体现在两处：

一是模型服务的可观测性。除了常规的CPU、内存、延迟、QPS，还要关注Token消耗、缓存命中率、上下文长度分布、模型回复长度等AI特有指标。这些数据对成本控制和效果优化至关重要。

二是数据管线稳定性。RAG链路中文档更新、向量化入库等流程如果出了问题，用户端看到的问答质量会悄然下降。需要建立数据管道监控，定时检查向量库中的文档数量和数据新鲜度。

7. 常见问题与避坑实录

7.1 模型部署阶段的坑

问题一：模型在本地测试没问题，部署到服务器后速度慢得离谱。

排查思路：先看是不是没有用GPU推理（检查CUDA是否可用），再看是否开启了量化，最后看是不是有并发请求排队。

问题二：多实例部署时经常OOM（内存溢出）。

排查思路：检查显存是否真的够用，如果不够，考虑换小模型或降低并发数。另外，模型推理框架（如vLLM）的显存使用优化比原生PyTorch要好很多，切换到vLLM后同等显存下能支撑的并发可以提升好几倍。

问题三：微调后的模型在开放域对话上变笨了。

排查思路：大概率是灾难性遗忘。解决方案是微调时混合一部分通用语料，或者降低学习率（一般建议微调学习率不超过2e-5），又或者减少微调步数。

7.2 RAG链路的坑

问题一：检索到的文档明明相关，模型却回答得不好。

排查思路：很可能是切分方式破坏了语义，导致关键信息被截断。建议尝试按段落和标题结构切分，而非固定长度切分。

问题二：检索召回率低。

排查思路：尝试混合检索策略，把向量检索和关键词检索结合，用重排序模型重新打分后再决定最终给模型的上下文。

问题三：文档更新了，但问答结果没变化。

排查思路：检查向量化入库流程是否成功执行，向量数据库中的旧数据是否被清理。很多团队在文档入库的增量同步上踩过坑。

7.3 Agent编排的坑

问题一：Agent规划任务时陷入死循环。

排查思路：需要设置最大迭代次数（比如最多执行5轮工具调用），并配一个任务终止条件（比如"获取到所需信息后立即结束"），防止失控。

问题二：Agent调工具时参数传错。

排查思路：在工具函数里增加参数校验和错误返回逻辑，Agent在收到错误信息后可以自主修正，效果比直接崩溃好得多。

8. 最后分享一点我自己的体会

这套五层结构从算力基础设施（Infra）一路讲到业务产品层，看起来像是把AI项目拆得很碎。但我在实际推进项目的过程中最大的体会恰恰是：拆分是为了更好地整合。每一层相对独立，可以让不同背景的团队成员各司其职；但每一层之间的衔接又需要有全局视野的人来把关——模型选型要考虑到量产成本，产品交互要理解模型的局限性，业务定价要反推技术方案的性价比。

另外一个特别想强调的是：AI技术的迭代速度非常快，热词榜上的东西可能几个月就过气一次。但分层思考的方法不会过时。无论底层模型换成什么，框架更新到什么版本，只要你能清晰地把"基础设施、模型能力、工具框架、应用交互、业务价值"这五层之间的关系想明白，任何新技术进来都能快速定位它属于哪一层、能解决哪一层的问题。这比追着追新模型、新工具跑要重要得多。