企业官网建设流程全解析

生成式AI这批浪潮喊了两年多，但我发现身边不少团队的用法还停留在“让大模型写个周报”的层面。直到自己完整地做了一个基于生成式AI的智能应用从零到上线的全过程，才真正理解为什么业内把它称作一次范式转移：它不是在原来的AI能力上多接一个接口，而是把“智能应用”的定义方式彻底换了。今天这篇就以个人实操视角，聊聊生成式AI到底如何重新定义智能应用，以及想落地这类项目时，哪些环节最容易被忽视、哪些坑我替你先踩过。

1. 生成式AI的本质变化：从“识别工具”到“创造引擎”

1.1 旧范式下的智能应用长什么样

先花两分钟把传统智能应用的底裤扒开看。过去几年，大家嘴里说的智能应用，本质上是“识别”和“推荐”。在线购物平台根据你的浏览行为推商品，短视频平台根据停留时长推内容，客服系统根据关键词匹配回答模板，风控系统根据历史特征打风险分。这些场景的共同点是：它们都在做分类、回归、排序这三大件事。

你给模型一个结构化输入，模型在主流的固定标签集合里挑一个输出。比如输入一笔交易记录，输出“正常”或“可疑”；输入一张图片，输出“猫”或“狗”。哪怕深度学习已经把准确率推得很高，这个应用的逻辑骨架仍然是“查字典”——从训练数据已经定义好的模式里找一个最可能的答案。

所以你会看到，老一代智能应用有个很明显的天花板：它永远不会主动说“我不知道”，也不会拖着长音说“让我重新考虑一下”。推荐系统列出十个商品就是它的全部能力，你不能追问“你凭什么觉得我会喜欢第三个”，它没法解释，因为判别模型天生就不带解释链路。

1.2 生成式AI带来的三个底层变化

生成式AI把上面这套逻辑整个翻了个面。最直观的是交互方式，从“表单填写”变成“自然语言对话”。用户不用再在预设条件里勾来勾去，直接用一句话表达需求，模型自己理解意图、拆分任务、组织答案。这一步看着简单，实际上把产品的使用门槛砍掉了一大截。

第二个变化是任务类型，从“识别归类”变成了“内容生产”。写一篇行业分析报告、生成一套UI设计稿、把一段口播稿转成完整的短视频脚本、甚至根据几个关键词产出一个可运行的代码文件。这些以前需要人去逐字逐句完成的工作，现在变成了一次模型调用。你在产品里接入了生成式AI，本质上就是把“内容生产”封装成了一个可调用的函数。

第三个变化藏在系统架构里：以前加一个新功能，意味着要写新的接口、新的规则、新的参数配置；现在更多时候，你是在提示词层面做组合，配合模型已有的推理能力，几十分钟就能搭出一个新能力。这种从“硬编码”到“软组装”的转变，是很多团队一开始感知不到、但越到后来越震撼的差异。

拿个生活化的类比说：传统AI应用更像自动售货机，你投币、选择、掉出固定商品，货架上有什么你就拿什么；生成式AI应用更像你带了一个实习助理，你交代一个模糊目标，他会主动问你两三个问题确认方向，然后自己查资料、出草稿、按你的意见返工。这个助理不一定每次都对，但他能做的事情边界比自动售货机宽太多了。

1.3 范式转移的核心表现：开发重心的转移

所谓范式转移，不是功能的数量变多，而是整个工作流的关键路径变了。传统AI项目，团队花时间最多的地方是数据标注、特征工程、模型结构设计与超参数调优。你花三个月准备一份高质量标注数据，再花两个月调模型，最后部署上线。整个流程里，业务人员基本插不上手，全程是算法工程师在推。

生成式AI项目里，工作重心滑向了另一侧：任务拆解、上下文构造、工具编排、评估反馈。业务人员可以用自然语言描述期望流程，“我希望用户问完问题后，系统先搜索内部资料，再带上参考资料生成答案”，这本身就是最原始的需求文档，开发人员的工作是把这句话翻译成程序结构、提示词模板和工具调用链。

这个重心的转移，导致团队结构也在变。算法工程师以前是绝对的核心，现在更多扮演“集成者”的角色，真正高频产出的是懂业务、会做提示词工程、能设计评估方案的人。项目迭代节奏也从“按周训练模型”变成“按小时调整提示词”，反馈循环短到令人惊讶。我第一次体会到这个差距，是在某个模拟项目X里：需求方上午提了个新功能，我用了一下午改提示词、接一个新工具，傍晚就能给他演示可用版本。放在以前的判别式应用流程里，这个需求可能要排到下个月。

2. 智能应用技术底座：模型选型、RAG与Agent怎么搭

2.1 模型服务选型的四个维度

决定做生成式AI应用，第一个逃不开的问题是用哪个模型。我见过很多团队一上来就想去接参数最大的那个商用模型，结果成本报表出来人傻了。选型别只看榜单分数，我自己的经验是盯四个维度：效果标杆、成本结构、延迟表现、可控性。

效果标杆看的是典型任务上的表现，比如中文理解准确性、代码生成通过率、长文档总结能力。成本结构要算清楚按token计费的模式下，平均一次对话要花多少钱，这个要根据你们真实业务场景的输入输出长度来估算。延迟表现分首字延迟和总生成时间，有些场景要求两秒内必有响应，那就得在模型大小和量化级别上做取舍。可控性则包括部署方式、数据是否离开本地、更新频率、厂商的服务稳定性。

实际操作中我的建议是：先别陷入“参数越大越聪明”的迷信。很多商用大模型的API能力完全够用，重点是把链路跑通，验证业务价值。等确认方向可行之后，再回头做性能优化。真到了需要私有化部署、对数据安全有硬性要求的场景，再考虑某开源底座模型做微调或直接部署，那属于后一阶段的事。我在第一个生成式应用原型里就吃了这个亏：一开始就追求最强效果，选了大参数模型，结果每次请求的延迟和账单都让人焦虑，后来换成性价比更高的中小参数模型，居然也稳稳扛住了核心场景。

2.2 上下文管理与RAG：让模型“看见”你的业务数据

模型本身是“博而不精”的，它的训练数据截止到某一时间点，也没有你公司内部的文档和知识。所以几乎所有的企业级智能应用，都会用到RAG架构：检索增强生成。

它的核心思路不复杂：用户提问后，系统不是直接把问题丢给模型，而是先在自己的知识库里做检索，找到最相关的几段资料，然后把“问题 + 资料”一起拼进提示词，让模型基于这些资料生成答案。这样既绕开了模型知识陈旧的问题，又能把回答范围限制在允许的语料内。

但实操里有很多细节。文档切片不是简单按字符数切，按固定长度切容易把一句话拦腰折断，召回时语义就不完整了。比较好的做法是结合文档本身的标题层级结构来定切片边界，比如按一级标题分块，块内再按段落拆，相邻切片之间留几十个字的token重叠，防止关键信息正好落在边界处被切散。

向量化环节，embedding模型的选择会影响召回质量，建议多换几个模型在你们的真实语料上离线评测一下召回效果。召回阶段，不要一上来就只靠向量相似度，可以叠加一层基于关键词的检索做融合召回。我自己在某个某图像处理Demo的配套问答应用里试过：纯向量的Top3准确率大概七成，加上关键词融合后，能提到八成五以上。最后还可以加一个重排模型，把粗召回的结果精排一下再进提示词，这一步对最终答案质量的影响非常明显。

2.3 Agent与工具调用：从被动问答到主动执行

当智能应用不满足于“答话”，还要“办事”时，就要引入Agent机制。一件事比如“帮我查一下上个月的销售数据，分析环比变化，并生成一段汇报摘要”，这涉及查数据库、做计算、写文字三个动作，单靠一次模型调用完成不了。

这里的关键技术是函数调用。模型不直接生成最终回答，而是先分析用户意图，输出一个结构化指令：“调用销售数据查询函数，参数是时间范围；再调用统计函数，计算环比；最后基于结果生成摘要”。应用层拿到这个指令后，按顺序把真实数据取回来，传回模型，再由模型生成最终答案。

写函数调用时我有三个心得。第一，函数描述一定要具体，比如说明“这个函数只接受yyyy-MM-dd格式”，模型才不会传入乱七八糟的格式。第二，函数返回数据尽量精简，减少token消耗，只传必需字段。第三，容错设计要做足，模型可能调用不存在的函数名，或者参数越界，这些都要在应用层兜住。

还要说一句：不是所有场景都值得上Agent。固定流程比自由Agent稳得多。比如客服场景，用户问题归类后走固定分支，比让Agent自由发挥更容易控制。自由Agent适合任务边界模糊、自主性要求高的场景，但你要有心理准备，它的不可预测性会带来更多排查成本。我自己遇到过一个典型情况：一个自由编排的Agent在多轮对话里反复调用同一个工具，结果产生了重复费用。后来加了调用次数上限和循环检测，问题才解决。

3. 实操复盘：用生成式AI做智能应用的六个关键环节

3.1 从需求到边界：先做减法再做加法

动手写这个应用之前，我花了整整两天做需求收敛。最初业务方提的需求是“做一个企业智能助理，什么都能答”，这等于什么都没说。我们坐下来把高频问题列了一个清单，最后发现真实需求集中在三类：内部制度知识问答、文档内容总结、固定格式的报表生成。

这个收敛过程至关重要。三类问题对应完全不同的技术策略：知识问答需要RAG配合引用溯源；文档总结需要处理长文本输入，可能要做分段处理再汇总；报表生成则需要输出严格的结构化字段，甚至要调模板。混在一个应用里，不能用一套提示词解决所有问题。所以最后我把它拆成了三个子会话场景，各自独立的提示词和参数配置。

3.2 提示词模板与上下文构造

提示词是这个应用的“业务逻辑层”。绝大部分的输出质量差异，不来自模型选型，而来自提示词设计的差异。我最常用的一套模板结构是五段式：

【系统角色】你是企业内部知识助手。仅基于提供的资料回答问题，不要使用资料之外的信息。 【任务目标】根据用户提问，从给定资料中提取要点并组织答案。如资料不足以回答，请明确说明。 【资料段落】以下是从内部知识库检索到的相关文档片段，请以此为准: {retrieved_context} 【输出格式】答案先给结论，再列依据，依据后附资料编号引用。当资料不足时，输出“根据现有资料无法完整回答此问题”。 【推理要求】请先判断问题意图，再逐条核对资料，最后组织语言。如发现问题有多层含义，可向用户澄清。

注意几个细节：系统角色一定要写明“基于提供的资料”，这是防幻觉的第一道闸；输出格式要尽量结构化，方便用户阅读也方便后续做解析；推理要求是在引导模型展示思考过程，虽然会多耗一点token，但换来的是稳定性的显著提升。

上下文构造还有一个工程化的问题：同样的系统提示词，不要每次都在前端拼一遍，而是固化在后端作为公共参数。检索到的资料段落要根据上下文窗口大小做动态裁剪，超出长度就得做压缩或截断，不能一股脑全塞。

3.3 参数选择：温度、TopP、max_tokens不是随便填的

模型服务商提供的参数里，大部分人理解最深的是temperature温度，但具体业务里要怎么调，很多人没想清楚。低温（0到0.3）适合事实问答、代码生成、报表输出，模型会更保守更准确；中温（0.4到0.7）适合文案改写、摘要生成，既有逻辑又有灵活性；高温（0.8以上）适合创意文案、头脑风暴，但代价是正确性下降。

max_tokens同样容易踩坑。我遇到过好几次生成被截断的情况，用户问到需要写长文或写详细分析报告时，默认的max_tokens不够，后半段被硬生生砍掉了，用户还以为是系统Bug。合理的做法是根据业务场景各自设置，问答类短任务给256到512，总结类任务给1024到2048，创作类任务给4096以上。

还有两个不常被提到的参数：频率惩罚和存在惩罚。频率惩罚会降低模型重复相同词的概率，适合防复读机；存在惩罚会鼓励模型讨论更多新话题。一般问答应用里这两个参数默认给0就行，真正需要调的场景不多。

3.4 流式输出、缓存与反馈闭环

生成式应用的交互体验，很大程度上取决于是否做了流式输出。用传统的HTTP请求等全部生成完再返回，用户等上好几秒没反馈，体验非常差。接入SSE流式协议后，模型每生成一小段文字就推送到前端，用户能看到文字一个字一个字冒出来，心理上的等待感完全不一样。

缓存是省钱利器。相同或相似的用户问题，直接命中缓存返回历史答案，连模型都不用调。我在系统里做了一个语义缓存：每次请求进来，先用embedding把问题向量化，跟缓存里的历史问题算相似度，相似度超过0.95的就直接取缓存答案。实测下来，在一个访问量集中的内部场景里，缓存命中率接近三成，每个月省下来的token费用相当可观。

反馈闭环容易被忽略。生成式应用没有精确的准确率指标，你需要自己给输出建一条“质量反馈通路”。最常见的做法是给用户提供点赞、点踩、复制、收藏等按钮。点踩记录下来的badcase要定期捞出来看，一批一批修正。我在某跨平台系统里加了这个功能后，每周都能从badcase里发现一两个需要调整提示词或补充知识库的案例，这比什么都靠人工抽查高效得多。

3.5 评估指标：别只盯着“感觉还行”

这个项目让我自己最吃亏的地方，是没有早一点把评测体系搭起来。生成式应用不像判别式模型那样有天然的准确率，你能看到的就是“答得还行”和“有点离谱”。靠人工抽几眼判断，随着功能越加越多，回归问题就出现了：改一个提示词，把这个场景修好了，另一个场景又坏了。

后来我花了比较大力气建了一个评估数据集：把内部真实高频问题收集起来，人工写好标准答案，做成100条左右的评估样例。每次改完提示词或流程，跑一遍这100条，让模型做裁判给自己打分，低于及格分的逐条人工看过再决定是否上线。这个过程成本不低，但属于必须投入的“基础设施”。一个没有评估体系的生成式应用，就像没有测速仪的车，跑得快不快全凭感觉，翻车了才知道。

3.6 部署运维：关注这三个指标就够了

生成式应用部署上线后，运维层面我建议盯三类指标：调用成功率、响应延迟分位数、token成本趋势。调用成功率要拆开看是在哪个环节失败的——是检索失败、模型超时、还是输出解析出错。延迟看P95而不是平均值，平均值被少数慢请求拉高，P95才能体现真实用户体验。token成本趋势按天记录，跟业务量比对，如果业务量没涨、成本涨了，大概率是提示词无意中泄露了大量上下文，或者是模型开始无限递归调用工具了。这三个指标设好告警，剩下的问题基本都能在用户投诉之前暴露出来。

4. 生成式应用避坑实录：幻觉、成本、失忆与评估

4.1 幻觉问题：不可能消灭，但能围堵

幻觉是所有生成式应用绕不开的坎。模型本质是概率生成器，它会在信息不足的时候脑补出看起来很合理、实际上不存在的内容。为什么会有？因为训练目标就是最大化下一个词的概率，不是验证事实。

处理幻觉我总结了一套“围堵”打法。第一层，检索兜底：所有事实型回答都必须走RAG，不依赖模型自己的记忆。第二层，证据约束：提示词里强制要求答案附引用，找不到对应资料的题目宁可说不知道。第三层，输出限制：把温度调到0到0.2之间，关闭一切开放式发挥的空间。这三层叠完，幻觉的出现率能显著下降，但不会降到零，所以系统设计上还要留一条“不确定”的退路，在关键性回答上让答案带上一句“建议人工复核”。

4.2 成本失控：每一分token都要算清楚

生成式应用的成本是动态的，同一个功能，用户多问一句，上下文里多带了一段长文档，账单就悄悄涨了。我做过一个统计，在一个信息查询类应用里，因为上下文里塞了太多检索资料，单次请求的中位成本比预期高了一倍多。

控制成本从两头抓。输入侧，做上下文裁剪，凡是跟当前问题无关的历史消息一律不进上下文；检索结果只保留最高的前3到5段，不贪多。输出侧，限制max_tokens，能用短答案解决的就不放水；开缓存，特别是语义缓存；对可异步处理的批量任务，用批量接口而不是实时接口，单价能压下来不少。再有一个不显眼但很重要的：定期检查提示词模板，有没有在迭代过程中悄悄变长。我的经验是，提示词每迭代一版，成本都会跟着涨，隔一段时间就要做一次精简。

4.3 上下文失忆：长对话为什么总“掉线”

多轮对话里最经典的场面：用户第五轮问“这个方案你刚不是说过了吗”，系统一脸茫然。原因很朴素：上下文窗口有限，模型只能看到最近的若干token，太早的信息被挤掉了。

工程上常用的方案是会话摘要。每隔几轮，把前面的对话压缩成一段摘要，替换掉原文，保留关键信息，腾出空间给新的对话。还有更精细的做法是把对话里出现的结构化信息单独抽出来维护，比如用户提到过的项目名、时间范围、偏好条件，放到一个“会话变量池”里，每次构造提示词时把它们带进去，而不是依赖模型自己记忆。

这里有个权衡：会话摘要做得好，用户无缝衔接；做得不好，模型会把摘要当成唯一事实来源，反而丢失了细节。所以我建议摘要要分层：普通信息一段话带过，关键结论保留原文痕迹。

4.4 评估与回归：给“玄学”装上仪表盘

生成式应用最大的工程挑战，是它的输出不可枚举。你说不准一个用户问题会得到多少种不同的答案，也无法用简单的断言去跑自动化测试。

我的做法是分级评估。第一级，规则自动化：能拆解成确定性规则的问题，比如“有没有引用”“格式是否符合要求”“长度是否在范围内”，全部交给脚本检查。第二级，模型评估：对答案的质量、相关度、完整度做打分，用大模型来当裁判。模型裁判会有一致性问题，但胜在速度快，能起到筛选作用。第三级，人工抽查：每天随机抽一天的高频问题，人工过一遍，防的都是规则和模型裁判都发现不了的深层问题。这三层叠起来，迭代的胆子才敢大一点。

还有一个容易被忽略的经验：保存历史最佳版本。每次提示词调整后，如果评测指标上涨，把当时的提示词版本和评测结果一起存档。这个习惯在项目后期特别有用，因为改回退版本时不需要“考古”。

5. 个人体会与下一步扩展

做这个生成式智能应用，最深的一个体会是：大模型就像一个能力极强但极度需要框架约束的执行者。你把它当百科全书用，它会一本正经地编故事；你给它搭好检索、设定好边界、配好工具、建好评测，它就能变成稳定可靠的生产力工具。整个项目的重心，最终都落到了“约束”二字上。

最后再分享一个小技巧：每次版本上线之前，拿这周新收集的badcase跑一遍提示词的新老对比，把修正效果数字记录下来。我自己用这个方法连续优化了六轮，每次都能看到明确的指标变化，而不是凭感觉说“好像变好了”。后续如果还想扩展，可以往更复杂的Agent编排方向发展，比如多角色协作、跨系统任务流，但每一步都必须带着评测走。范式转移说得再热闹，落不了地的都是空话。