企业官网建设流程全解析

“大模型应用开发，是不是就是每天调调API、抄一抄Prompt？”这是我最近被问得最多的问题。问的人里有传统后端、前端、测试，也有刚毕业准备入行的大学生。作为从传统业务系统转到大模型方向、在一线做了快两年应用开发的人，我想借这个标题把这件事彻底讲清楚：大模型应用开发到底做什么，需要会哪些技术，以及一个普通人怎么一步步走过来。这篇文章不是我整理出来的知识点，而是我踩过坑之后的复盘，希望能帮你把脑子里那些模糊概念换成一张能直接照着走的地图。

1. 先搞清楚边界：大模型应用开发不是在调API

1.1 和算法工程师的区别：不炼丹，但要懂火候

很多新人第一个困惑就是：大模型应用开发和算法工程师有什么区别？算法工程师的核心工作是训练模型、调参、改进模型结构，他们的战场在训练集群和实验记录里，一句话概括是“造发动机”。而大模型应用开发者的战场在产品里，任务是把这台发动机装进一辆能上路的车，还要保证油表、刹车、导航都正常工作。

这意味着你不需要会从零预训练一个大模型，也不需要精通反向传播推导，但你需要理解模型的基本脾气：它擅长什么、不擅长什么、什么情况下会胡说八道。打个比方，算法工程师知道发动机气缸的燃烧原理，而你要知道的是“这辆车的发动机在什么转速下最省油、什么路况容易熄火以及怎么保养”。

日常工作中，算法团队会给出一个底座模型，应用开发团队在这个底座之上搭建业务逻辑。所以你的核心能力不是创造模型，而是驾驭模型。很多团队招人时会写“熟悉Transformer原理优先”，但真到了工作里，会用、会调、会修错，比会推导公式重要得多。

1.2 和传统前后端开发的区别：既要会接，也要会想

那么它和传统软件开发的区别又是什么？传统开发里，一个功能的行为是确定的：输入一个用户ID，查询数据库，返回用户信息，输出的格式可以预先定义。但大模型应用的行为是不确定的：同一个Prompt扔进去，不同时候可能给出不同答案；同一个问题换一种问法，结果可能天差地别。

所以大模型应用开发者不能只写“能跑”的代码，还要写“在不确定环境下能兜底”的代码。我以前做权限系统时，接口返回失败就是失败，逻辑非常确定；现在做AI客服，模型可能给出一个看似正确实则错误的答案，我得在系统层面加拦截、校验、降级方案。这是思维方式上最大的转变——从逻辑确定性思维，转向概率性思维。

1.3 一个典型的日常：都在忙些什么

拆开日常工作来看，大概有五类事情：

• 第一类是和业务方确认需求边界，判断哪些环节适合用大模型，哪些用传统规则或者小模型更划算。
• 第二类是设计Prompt、搭RAG流程、调试工具调用逻辑，这是主菜。
• 第三类是开发服务端接口，把模型输出包装成稳定可用的业务能力，涉及并发、缓存、限流等常规后端工作。
• 第四类是搭评测集、跑离线评测、看线上日志，持续追踪模型效果。
• 第五类是写文档、做汇报、同步进度。这比重不低，尤其需要向不懂技术的老板解释“为什么这里还需要一个人工确认环节”。

如果你是那种只喜欢闷头写代码、完全不爱沟通的人，这个岗位会比传统开发难受一些，因为它本质上是连接业务和技术的桥梁角色。

2. 技术栈全景：从一条API到一套系统

2.1 最底层：模型接入与API调用

技术栈可以从下往上看。最底层是模型接入，形式一般有两种：调用别人训练好的API，或者私有化部署开源模型。API方式最省事，不用管算力，按token付费即可；私有化部署则要处理显存、推理框架、并发调度等问题，适合对数据隐私要求高的场景。

这个层面你需要掌握的东西不算深，但很杂：HTTP调用和鉴权方式、流式输出处理、超时与重试机制、token的计费规则、模型版本管理。举个例子，你以为一次对话只调用一次模型？不一定。一个复杂的Agent任务里，模型可能被调用十几次，每一次还带工具结果重新拼上下文，成本就是这么悄悄涨上去的。这些都是底层API调用的细节，但直接影响成本和稳定性。

2.2 中间层：Prompt工程、RAG与工具调用

中间层是大模型应用开发的核心，也是最有技术含金量的部分。先看Prompt工程。很多人觉得Prompt就是“给模型写一段话”，实际上它是一门结构化学问。一个生产级的Prompt通常包含角色设定、任务说明、输入格式、输出格式、边界约束、示例，甚至还要做few-shot。调试Prompt的时候，我需要像写测试用例一样维护版本，每次改动都记录对比结果，因为同一个Prompt在模型升级后效果可能明显变化。

再看RAG（检索增强生成）。RAG解决的是模型“不知道最新事实”和“幻觉”问题。经典套路是：把知识库切块、向量化，存入向量数据库，用户提问时先检索相关内容，再把这些内容塞进Prompt交给模型回答。这个链路看着简单，真正调好特别难：文档怎么切、向量模型怎么选、检索结果怎么排序、怎么把检索内容压缩到合适长度，每一项都能单独写一篇长文。我后面会讲实践参数，这里先记住一个结论：RAG是必选项，不是加分项，因为企业应用几乎都是私有知识场景，模型没训练过这些数据。

工具调用（Function Calling）则是让模型学会使用外部系统。比如模型判断需要查天气时，不是凭空编一个结果，而是输出一个“调用查询天气接口”的结构化指令，由程序执行后再把真实结果返回给模型。这个能力是Agent（智能体）的基础，也是现在大模型应用最有想象空间的部分。

2.3 上层：Agent、评测与可观测性

再往上，是Agent相关的编排逻辑。Agent和单次问答式应用的区别在于，它把任务拆成多步执行。比如“帮我订一张明天去上海的机票”这个指令，Agent需要规划出“查航班、比价、选航班、提交订单”等步骤，中间还可能遇到需要用户确认的节点。开发时就要处理好任务分解、记忆管理、工具选择、失败恢复这些问题。坦白讲，Agent目前在生产环境里远没有PPT里那么神，很多情况还会陷入循环，但这是最值得投入的方向。

评测体系也是技术栈里权重很高的一块。模型输出没标准答案，怎么判断好不好？做法是建设一个评测集，包含几百到几千条典型问题，每条预先标注预期标准，然后批量跑模型、用打分模型或规则自动评估。评测不是上线前做一次就完了，而是每次改Prompt、换模型、改检索策略后都要重跑，确保效果没有回退。

最后是整个系统的可观测性。大模型应用比传统应用的排查链路更长：用户输入经过检索、拼接、模型推理、输出，任何一个环节出问题，表现在用户侧都可能是答案质量下降。所以我建议一定要把每次请求的关键信息保存下来：原始输入、检索到的文档、最终Prompt、模型输出、耗时和token消耗。出问题的时候，把这些数据翻出来回放，才能定位到底是谁的锅。

2.4 辅助设施：向量数据库、缓存与数据管线

配套设施里，向量数据库是RAG的刚需。现在可选方案很多，有专门的向量数据库，也有传统数据库自带的向量检索插件。我的经验是，数据量在百万级以下时，很多方案性能差距没想象中大，我建议优先选择团队已经熟悉、运维成本低的方案，不要为了追新而引入一个完全没有经验的新组件。

缓存也很关键。大模型接口有延迟，还有费用，高频重复问题完全可以用缓存解决。简单做法是以“问题+检索结果”的哈希值为key，把模型输出缓存一段时间，但要注意缓存命中后用户可能得不到最新信息，所以适合对时效性要求不高的场景。

数据管线关注的是知识库的更新。企业里的文档、FAQ是持续变化的，中间层必须有定时任务去拉取新文档、做切块和向量化，并且能识别失效内容。这块属于不太起眼、但生产环境最容易被忽略的脏活累活，很多项目上线后才意识到知识库不更新，整个系统效果会越来越差。

3. 走一遍真实业务：从需求到上线的完整流程

3.1 第一步：先判断“该不该用大模型”

接需求后第一件事不是画架构图，而是做判断：这个问题需要用大模型吗？我见过最典型的反面案例，是想用大模型做“根据手机号查用户订单”，这明显是SQL的事，偏要绕一大圈，结果又慢又不准。适合用大模型的需求，通常有几个特征：输入是自然语言、问题开放、答案没有唯一标准、需要理解和归纳。比如客服问答、文档总结、舆情分析、智能招聘筛选。反之，如果输入字段固定、逻辑明确、要求零容忍准确率，那就用传统代码解决。

这个判断为什么重要？因为大模型不是万能的，它的强项是语义理解，弱项是精确计算和严格逻辑。强行把不合适的场景塞给大模型，后面等你的就是无穷无尽的找补。做应用开发的人，价值一半体现在“知道什么不该做大模型”上。

3.2 第二步：模型选型与成本估算

确认问题适合做之后，进入选型阶段。选型的核心权衡是效果、成本、数据隐私、延迟四个维度。外部API通常效果最好、上手最快，但按量付费、数据出域，敏感业务不能用；私有化部署的模型可控性强，但需要算力资源，效果可能比头部API稍弱。实务中很多团队采取混合策略：敏感数据走私有模型，公共问题走外部API，关键路径上再加一层判断路由。

成本估算一定要在开发前做。我见过太多项目，开发时用的是小模型样例数据，一上线发现模型调用量翻了几十倍，账单也翻了几十倍。这里有个简单估算公式：单次请求成本 ≈ 输入tokens数 × 输入单价 + 输出tokens数 × 输出单价。比如一个客服场景，每次请求平均输入3000 tokens、输出500 tokens，假设输入单价每百万token 3元、输出每百万token 15元，单次成本约为0.009+0.0075=0.0165元。如果每天10万次请求，每月成本就是0.0165 × 100000 × 30 = 49500元。这个数字在立项时必须写进方案，否则后面财务审批会很被动。

3.3 第三步：RAG的切块、检索与参数选择

选定模型后开始搭RAG流程，第一个要面对的是切块（chunking）。切块没有万能参数，但很现实的起点是：普通技术文档、FAQ类短文本，块大小为200到400字，重叠为20到50字；长文报告类，可以按标题层级先做段落切分，再对长段落做二次切分。逻辑优先于固定长度：先按文档结构切，切出来的块如果还太长，再按句号、换行做硬切，这样检索到的内容语义更完整。

检索参数里，最常用的两个是召回数量topK和相似度阈值。我在客服问答场景里常用topK=3到5，相似度阈值设在0.3到0.5之间。但注意，这类数据库返回的是向量相似度，不同向量模型的分数分布差异很大，阈值不能照搬，必须拿一批真实问题跑一遍，看看命中分布再定。另外，单一向量检索不够，我的习惯是叠加关键词检索，用混合检索的方式做第一轮召回，再用重排序模型把两条路子召回的结果重新排序，效果会比单路检索明显提升。

3.4 第四步：Prompt编写与输出约束

RAG只是把“食材”备齐了，Prompt决定模型怎么“做菜”。生产环境的Prompt设计有一个固定套路：先讲角色和任务，再交代背景材料，然后说明用户问题，最后严卡输出格式。我常用的模板大致是：

你是某业务的资深客服专家。请基于以下资料回答用户问题。 资料： {检索到的知识片段} 用户问题：{问题} 要求： 1. 只根据资料回答，资料中没有的信息，请明确说明“资料中未提及”。 2. 不要编造数据、价格、规则。 3. 回答控制在3条要点以内，使用简洁中文。

这里有两个关键操作。第一，“只根据资料回答”这种约束并不能百分之百防幻觉，但能大幅降低概率，同时给系统留出校验空间；第二，输出格式必须给到足够细致，不要只说“用JSON输出”，最好连字段名、枚举值都列清楚，这样下游解析才稳定。还有个小技巧：如果模型经常输出多余的口水话，可以在Prompt末尾加一句“直接输出结果，不要解释”，实测能省不少token。

3.5 第五步：评测集建设与上线监控

开发完不要急着上线，先建评测集。我建议把评测集分为三部分：核心场景集，大概100到300条，覆盖高频问题，每条都做了答案要点标注；边界与恶意输入集，大概50到100条，包括无答案问题、重复提问、诱导性提问；回归集，用于每次改动后跑全量，确保老问题不回退。预算有限的项目，哪怕是50条，也足够暴露大部分问题。

上线之后，很多团队就松懈了，这是要命的。模型会升级，知识库会变化，用户提问的分布也会随时间漂移。我的做法是，每天都跑一遍核心场景集，同时把线上日志里的badcase打标，每周汇总一次，挑出影响面最大的10个问题去修。判断修得好不好的方法很简单：同一个badcase修复前和修复后各跑5次，看是不是稳定改善。修Prompt也好、调检索也好，没有前后对比就相当于盲改，这是在自欺欺人。

4. 避坑实录：大模型应用最容易翻车的五个点

4.1 幻觉不是Bug，是特性，必须有兜底

很多人第一次做AI应用，看到模型编造答案就慌，以为是自己的Prompt写得不够好。我要泼一盆冷水：幻觉是生成式模型的固有属性，不能靠Prompt完全消灭。你要做的是设计兜底机制。我在一个问答系统里，对模型输出做了两类兜底：一是内容层面的，如果模型输出的关键实体和知识库原文没有相关性，就拦截并返回“未找到相关信息”；二是流程层面的，如果模型自评置信度低，就转人工或给出客服联系方式。想彻底消除幻觉？以我目前经验来看不现实，但让幻觉的伤害可控，这是明确能做到的。

4.2 上下文越长不等于越聪明

模型号称支持很长的上下文，实际表现却会随长度下降，这个坑每天都有不少人踩。你为了让它“记住所有内容”，塞进去几十页文档，结果它反而被中间信息带偏。我的经验是：上下文里的信息密度比长度更重要。优先做到“只放相关的、放最简洁的”，给模型的材料能少则少。这不仅是效果问题，也是成本和延迟问题，输入token数直接决定响应速度和账单数字。把几千字的文档精简成几百字要点，或者用RAG先检索再截断，效果和速度都会改善。

4.3 一套Prompt走天下，后面改到怀疑人生

很多项目早期只有一两个场景，Prompt随便写没问题。但随着场景增多，会出现一个现象：改A场景的Prompt，B场景效果变差了。这是因为不同场景共享了同一个Prompt，互相干扰。解决办法是拆分。做到每个场景一个独立Prompt模板，再配一套公共约束。我在一个项目里把Prompt目录建成了这样：common/system、qa/faq、summary/default、agent/planner，每类独立版本管理，谁都不干扰谁。刚开始会稍微多点文件，但后面迭代会轻松得多。

4.4 离线指标好，线上体验却翻车

评测集跑出来的准确率90%，很多团队就自信上线了，结果用户反馈“答非所问”。原因在于，评测集是静态的，它不代表用户真实的输入分布。用户可能用语不规范、问题带情绪、甚至有错别字，这些在评测集里基本不会出现。解决思路是“评测集只有一半”，把线上badcase持续回流到评测集里。上线不是终点，而是评测集生长的起点。我每月都会把线上收集的问题按类型整理，挑出新模式补进评测集，让评测集越来越贴近真实流量。

4.5 只盯着回答质量，忽略了延迟与成本

回答再准，如果延迟5秒、成本高到亏损，业务依然跑不起来。大模型应用的三个指标——准、快、便宜——是三角约束。现实项目里，特别是实时客服场景，用户能接受的响应时间大概在2到3秒以内，超过这个时间流失率明显上升。所以我在方案阶段就会算延迟预算：检索大概100毫秒，模型推理大概1到2秒，中间层处理大概几十毫秒，整体得控制在合理范围。如果模型推理太慢，优先考虑换小模型、减Prompt长度、加缓存，不要只想着调大模型。省钱也是效果的一部分。

5. 成长路线：三个月入门，一年能独当一面

5.1 第一阶段：把API用到烂熟，建立手感

入门阶段最好别碰Agent，也别一上来就折腾微调，先把最基础的能力练出肌肉记忆。找一个大模型API或者本地部署一个小模型，写脚本做三件事：第一，调通流式输出，理解流式和非流式的区别；第二，学会处理超时、重试、限流和错误码；第三，设计几组Prompt，观察模型在不同温度参数下的输出差异。这个阶段大概需要两到四周，目标是闭着眼都能写出一段结构完整、靠谱的调用代码，并能解释每个参数为什么这么设置。

这个阶段最容易犯的错误是沉迷于各种框架的封装。我不是反对框架，而是反对在不懂底层机制时盲目套用。我见过有的人用框架搭了一个聊天机器人，出了错完全无法排查，因为他连最基本的模型调用是怎么传参数、怎么拿结果都不清楚。先把底层打通，再上框架，顺序不能反。

5.2 第二阶段：完整做通一个RAG业务闭环

入门后最值得投入的项目，是做一个真正能用起来的RAG问答系统。你可以自己造一个知识库，比如把一些技术文档或公司规章整理成几百个纯文本文件，然后完整实现“切块→向量化→检索→重排→拼接→生成→反馈收集”全套流程。做这个项目时，重点观察几个关键变量对效果的影响：切块大小、topK数值、相似度阈值、不同向量模型、不同Prompt写法。把每一组实验记录下来，形成自己的参数手感。

为什么强调这个阶段靠RAG而不是Agent？因为RAG涵盖了应用开发的核心基本功：理解文本、处理向量、协调多个组件、评估效果。Agent比RAG复杂太多，如果RAG都没调明白就急着做Agent，大概率是“跑起来一个demo，撑不起一个业务”。我认识的过来人，基本都是从扎实的RAG项目起步的。

5.3 第三阶段：能设计Agent和评测体系，才算进阶

到第三阶段，你已经能独立交付一个RAG业务了。这时可以往Agent方向探索。先做最简单的单工具Agent：给模型一个查询接口，让它学会在需要时调用接口而不是直接编答案。然后增加多工具、做任务规划、加记忆管理。进阶的标志不是你调通了一个Agent框架，而是你能说清楚“什么任务适合Agent、什么任务不适合、Agent在什么情况下会死循环”，并知道怎么加兜底让它从循环里跳出来。

与此同时，评测体系建设能力也是进阶的分水岭。初级开发者会问“怎么把回答调准”，高级开发者会去搭“能自动告诉我们准不准”的体系。从写评测集到设计自动评测流程，到监控线上效果波动，这套工程化能力往往比单点的Prompt技巧更值钱。因为业务越大，越需要体系来保证效果的稳定，而不是靠某个人的临场发挥。

5.4 几条很现实的建议

最后给正在观望的朋友几条实在建议。第一，别等学完再动手，大模型领域的知识更新太快，等学完就过时了，动手做一个具体项目，才是最高效的学习方式。第二，别被“30天精通Agent”之类的速成内容带偏节奏，那些内容看着热闹，但基本没有生产环境的真实细节，拿来做入门认知可以，拿来做项目依据不行。第三，技术之外多练“翻译能力”，把业务方的模糊需求翻译成可执行的技术方案，这是这个岗位的核心竞争力之一，而且越到后面越值钱。第四，养成记录实验的习惯，每次改动的前后效果对比都记下来，它会成为你进步最快的阶梯。第五，保持对底层的敬畏，今天再炫的Agent框架，底层也还是token的输入输出，理解这一点，你对各种新概念就不会轻易焦虑。

我在实际带人时发现，能走得更远的往往不是一开始最懂模型的候选人，而是愿意在一个完整项目里把所有环节都碰一遍、遇到问题能自己排查到根因的人。如果你正打算进入这个方向，从今天起选一个身边真实存在的小场景，搭一个端到端的应用，这一小步会比你看一百篇科普文章都有用。