企业官网建设流程全解析

最近好多朋友跑来问我，说现在AI的花样实在太多了——今天出一个能画图的，明天出一个能写代码的，后天又冒出一个能自己调用工具干活的。看着热闹，但总觉得雾里看花，不知道这些新玩法背后到底是什么逻辑。其实把大模型相关的技术拆开来看，本质上就一层窗户纸：所有的所谓「新花样」，基本都围着「输入什么」和「输出怎么处理」这两件事打转。

我用一个三层架构的视角，把这堆东西归了归类。这个拆法不是教科书里的标准分层，是我自己在实际落地项目、接API、调优、排查问题过程中，慢慢琢磨出来的一个特别实用的理解框架。今天彻底掰开揉碎了讲一遍，希望能帮你把脑子里那团关于大模型的乱麻，理出一条清晰的线。

1. 三层架构先搭起来：模型内核、交互会话、应用编排

很多人一上来就盯着模型参数、排行榜、微调技巧，这些当然重要，但都属于「模型内核」这一层。真正让你觉得AI变聪明了、能干事了、好用了的，往往是外面那两层在起作用。我习惯把整个大模型应用拆成三个层次：模型内核层、交互会话层、应用编排层。

1.1 第一层：模型内核层——底层的「智力核心」

这一层就是通常说的基座大模型本身。不管是开源社区里下载的权重，还是通过API调用的大模型服务（比如各类国内大模型平台的接口），本质上都是一个巨大的神经网络参数集合。这一层回答的问题是：给定一段文字（或者图片、音频），下一个最可能出现的文字是什么。就这么朴素，所有炫酷的智能感都源于这种高级的「接龙」能力。

这一层的特点是：做一次推理，需要大量算力，响应速度受限于模型参数量、推理框架优化程度、GPU性能。在大规模应用里，这一层你基本不碰——你碰的是模型产出的结果，而不是模型内部的权重。如果非要动这一层，那就是微调、继续预训练、蒸馏压缩那些重活了，属于专业团队才搞的事。

1.2 第二层：交互会话层——你「喂养」什么，它「拉」出什么

第二层是绝大多数开发者和创作者每天打交道的地方。这一层决定了你喂给模型的上下文是什么、以及如何把模型吐出来的原始文本转化成对用户有意义的信息。我这句话信息量很大，拆开看就有两个方向：

输入方向：提示词工程、上下文工程、向量检索（RAG）、系统提示词、多模态输入（图片+文字）、结构化参数输入（JSON Schema）……这些技术本质上都在做同一件事——把你要问的问题、要用的背景资料、要约束的格式，用一种模型最容易理解的方式组织好，塞进它的输入通道里。同样一个开源模型，有人拿去只能聊天，有人拿去能写合同、做分析报告，差别就在输入组织能力上。

输出方向：流式输出（SSE）、格式化输出（JSON Mode）、思维链（让模型先想后说）、工具调用（让模型输出一个特定的动作指令）……这些技术都在做另一件事——把模型原始的token流，变成用户能快速理解、程序能便捷解析、下游能自动执行的格式。模型输出一千字的思考过程没人想看，你告诉它「最后只输出JSON，不包含其他文字」，它就能规规矩矩给你吐出结构化数据。

1.3 第三层：应用编排层——把「模型」变成「产品」

第三层才是用户真正感知到的「AI应用」。这一层用代码把多轮对话、工具调用、状态管理、权限控制、业务逻辑串起来，让模型不再是孤零零的一个对话框，而是一个能干活、能出错、能纠错的智能体（Agent）。比如让AI查天气、订机票、写文档、发邮件，背后其实都是应用编排层在多轮调用交互会话层的能力。

为什么要这样分层？因为每一层的复杂度和迭代节奏完全不同。模型内核层更新缓慢（几个月出一版），交互会话层调整频繁（每个项目都要不停地调试提示词与输出解析），应用编排层则是没完没了（跟业务需求强绑定）。把这三个层拆开看，你就能明白为什么大模型行业会有那么多「工程化」的岗位和工具——因为绝大部分的创新和优化空间，都集中在中间层和上层。

2. 输入侧拆解：所有聪明的回答，都源于讲究的提问

输入侧是大模型应用里最容易被低估的部分。很多人觉得，不就是打字提问吗，有什么讲究的？实际做下来，输入侧的差异能直接决定一个AI功能的成败。我把输入侧分成四个模块来讲。

2.1 提示词工程：把模糊需求翻译成模型指令

提示词工程的核心，不是「写一段漂亮的咒语」，而是把用户的意图拆解成模型能够严格遵循的步骤和约束。举个例子，如果只是说「帮我写个活动策划」，模型会给你一个泛泛的八股文。但如果你在提示词里加上：

• 明确身份定位：「你是拥有十年线下活动运营经验的主理人」
• 指定输出框架：「按目标人群、活动主题、预算分配、时间线、风险预案五个板块输出」
• 加入约束条件：「预算不超过50万，目标人群为25-35岁城市白领」
• 指定格式要求：「每个板块内使用小标题和列表，总字数控制在2000字以内」

模型输出的质量瞬间就上了一个台阶。这背后的原因在于：大模型的预测逻辑是概率分布，约束条件越多、越具体，它在可能性空间里游走时就越容易命中你想要的那条路径。

实操心得有一条很重要：提示词里不要用否定句。比如「不要写得啰嗦」，模型反而会在「啰嗦」这个词附近打转；改成「请用简洁的短句，每点不超过五行」，效果会好得多。我试过很多次，凡是带「不要」的约束，大概率会向反方向跑偏。

2.2 上下文工程：给模型配一个「可检索的工作记忆」

上下文工程比提示词工程更进一步。提示词解决的是「怎么问」，上下文工程解决的是「喂什么背景材料」。

这里就不得不提RAG（检索增强生成）了。它的核心逻辑很简单：当模型不知道或记不牢某个具体信息时（比如你的公司内部制度、某份行业报告数据、某本书的细节），先从向量数据库中检索出相关片段，拼接到提示词里，再让模型基于这些片段回答问题。

这个概念听上去很学术，落地起来也不复杂：先把文档切片，用嵌入模型转成向量，存入向量数据库；用户提问时，把问题也转成向量，做相似度检索，取Top K片段；把问题和片段一起发给大模型生成答案。

实际部署时最坑的地方在查准率。向量检索不是万能的，它经常把「语义相似」但「不是用户要问的内容」的片段捞出来。我踩过的坑是：某次做内部规章制度问答，员工问「年假可以累积吗」，向量数据库返回的是「婚假规定」——因为两者在「假期」语义上相近。后来我在检索前加了一层关键词过滤，把制度分类标签作为硬性条件，再向量检索，准确率才有了质的提升。

2.3 多模态与结构输入：不再局限于「打字的对话框」

现在的模型普遍支持图片、音频、甚至视频输入。这意味着输入侧不再是一段纯文本提示词，而是多模态信息的混合体。比如让模型看一张电路图并解释工作原理，或者在对话里插入一份PDF截图，让它提取关键字段。

做这类应用时有几个小细节值得留意。图片分辨率过低的输入，模型识别精度会大幅下降，建议在输入端约束最小尺寸并做好压缩；上传文档类图片时，提前做方向矫正和裁剪，能让OCR识别的准确率高很多；如果模型API支持图片URL与base64两种传法，按理说base64更稳，避免走网络传输时出现图片加载失败。

结构输入也是输入侧的一大趋势。很多API支持用户传一个JSON Schema，告诉模型输出的数据应该长什么样。这其实就把提示词工程中的「约束」给编程化了，模型不用去理解自然语言里绕来绕去的约束描述，直接按照结构定义生成。

2.4 输入侧的隐患：全局系统提示词的「权力」太大

我做实际项目时发现一个很有代表性的问题：系统提示词写得太死，会把用户的输入空间锁死。比如给客服AI设定了一套极为严格的话术逻辑，它连用户随口问「你们公司规模多大」都无法回答。这不是模型笨，而是你的输入侧给它加了一层层「思想钢印」。

所以我建议在设置系统提示词时，把「强制规则」和「建议规则」分开写。前者如「必须使用礼貌用语」「不得编造信息」，是硬约束；后者如「可以适当推荐相似商品」「语气可以更亲切」，给模型留一点自由发挥的余地。这样既能保证产品的底线质量，也保留了大模型的灵活优势。

3. 输出侧处理：从流式打印到结构化落地的完整链路

输出侧在我看来是最体现工程能力的一层。模型生成的是token，但用户看到的是文字、表格、按钮、图表；程序接收到的是JSON、函数调用指令、状态码。把这些打通，需要一套完整的输出处理链路。

3.1 流式输出（SSE）：让用户感觉「快」的技术魔法

大模型推理一个长答案通常要几秒甚至几十秒，如果等它全部生成完再一次性显示，用户的耐心早就耗光了。所以实际应用里基本都用SSE（Server-Sent Events，服务端推送事件）实现打字机效果——模型每生成一个token，服务器就通过HTTP长连接实时推给前端。

技术原理不复杂：传统HTTP请求是一问一答，服务器处理完才返回；SSE则允许服务器建立连接后源源不断地推送数据流，直到结束。大模型服务商一般都会提供流式接口，返回的数据是「data: {生成的那段增量文字}」这种格式，前端在EventSource或者fetch的ReadableStream里逐段解析。

这里有个非常关键的细节：SSE连接的文件描述符和并发连接数限制。我踩过一次生产事故，用户高峰期时Nginx默认的worker_connections被占满，导致部分用户页面一直转圈。后来调整了Nginx的proxy_buffering设置为off，让SSE数据不经过缓冲层直接透传，同时调大了连接超时时间，问题才缓解。做流式输出，一定要改掉Nginx对长连接的超时默认配置。

前端还有一个坑：fetch接口的流式读取，很多人以为用response.text()可以拿到全量数据再解析，那就等于舍弃了流式优势。必须用response.body.getReader()逐块读，再通过TextDecoder解码字符串，按行切分处理SSE格式。

3.2 中断机制（Abort）：用户点了「停止」，到底发生了什么

流式输出的另一面，是如何支持用户随时打断。大模型回答太长，用户不想等；或者发现AI跑偏了，想马上终止重新提问。这时前端就需要向服务器发出取消请求的指令。

实现方式有两条路线。前端fetch里使用AbortController，用户在界面上点击「停止生成」按钮时触发controller.abort()，浏览器就会断开当前请求。但注意：这只断开了浏览器到服务器的连接，服务器那边可能还在请大模型继续推理——因为模型生成是异步的，后端的SSE循环可能尚未感知连接已断开。如果不做处理，模型token还在继续生成，白白浪费算力。

根治办法是在后端把流式生成和请求上下文绑定：当客户端断开连接时，通过context取消信号通知大模型调用方（比如OpenAI SDK里的abort参数），及时终止生成。我自己实践时，是把SSE的ResponseWriter包装了一层，检测到客户端断连（ctx.Done()）后主动调用一次模型的cancel接口，这样能显著降低无用token消耗，实测在高频调用场景能省下20%左右的成本。

3.3 结构化输出与函数调用：让模型从「说人话」变成「干实事」

流式输出解决了「快」的问题，而结构化输出解决了「准」的问题。很多业务场景根本不需要模型输出完整句子，只需要它返回一个JSON对象，比如：

• 意图识别：{"intent": "查天气", "city": "北京", "date": "2025-06-01"}
• 信息抽取：{"name": "张三", "phone": "138xxxx", "company": "某某科技"}
• 内容审核：{"risk_level": 0, "risk_types": [], "summary": "无风险内容"}

现代的模型接口普遍支持JSON Mode，你在输入侧用JSON Schema定义好输出字段、类型、枚举值，模型就会按照这个结构生成。但你以为这样就万事大吉了吗？不是的。实践中经常遇到：

JSON解析失败。模型偶尔会在JSON前后多输出一段解释性文字，哪怕你明确说「只输出JSON」。稳妥方案是：拿到输出后先做一次清洗，提取第一个{到最后一个}之间的子串，再做JSON.parse；如果解析失败，再补一次带错误提示的重试请求。

字段值不符合枚举约束。比如定义了status只能是"success"或"error"，模型偏给你输出"successful"。办法是在解析后加校验，不合法就用规则映射表处理，实在不行走人工兜底。永远不要把模型的输出当成绝对可靠的输入去用，这点放在生产环境尤其重要。

函数调用（Function Calling）本质上也是结构化输出的升级版：模型返回的不是普通JSON，而是一个「请调用某个函数、参数是XXX」的指令。应用编排层解析这个指令，去执行实际代码（查数据库、调天气接口、发邮件），再把结果返回给模型组织成自然语言。Agent自主决策的底层逻辑就建立在这个机制上。

3.4 多模态输出：图文混排与结果渲染

输出侧不仅是文本和JSON。现在大模型支持生成图片（通过调用图片生成模型）、语音（通过TTS转语音），甚至生成可交互的HTML页面。做AI报告助手时，很多产品会引导模型输出Markdown格式，前端渲染成漂亮的卡片、表格、图表。

这里要特别注意渲染安全性。如果模型输出包含HTML代码，你直接通过v-html或dangerouslySetInnerHTML渲染，会带来XSS（跨站脚本攻击）风险。稍微懂行的人都知道：模型生成的代码同样可能是恶意代码（比如提示词注入）。对模型输出做合规检测和白名单过滤，是必须做的一道工序。

4. 微调、Agent与传统架构：三层体系只是「骨架」，工程化才是「血肉」

写到这里，肯定有朋友会问：那微调呢？Agent呢？这些热词和三层架构怎么对应？答案很简单：微调改变的是一层模型内核，Agent则同时用到三层。

4.1 微调的定位：不是在「输入输出」上打补丁，而是改「思维方式」

微调本质上是在修改模型内核层的参数分布，让模型在特定任务上「重新学习」概率分布。但很多人把微调和提示词工程搞混了：能用提示词解决的事情，压根没必要微调。提示词就像你给一个见多识广的顾问详细交代了背景、要求、格式，他按你的规矩办；微调则像把这个顾问送去参加专门的培训班，让他天生就懂这一行的行话和禁忌。

微调的适用场景有清晰的边界：模型的输出风格必须完全一致（比如品牌调性）；基础模型对专业术语的理解能力严重不足（比如医疗、法律、代码）；数据隐私要求极高（无法通过API传参暴露给第三方）。如果只是一般性的格式要求、内容偏好、少量示例，别轻易动微调，量大成本高不说，还容易引入灾难性遗忘——模型会记住新知识，同时忘掉一部分旧能力。

4.2 传统三层架构与大模型三层架构的类比

后台系统常说的MVC三层架构（控制器、服务、数据库）和物联网三层架构（感知、传输、应用），本质思想与我讲的这套大模型三层架构完全一致：隔离复杂度、明确边界、独立演进。大模型三层架构里的模型内核层对应后台系统的数据库层（底层能力），交互会话层对应服务层（业务逻辑与数据处理），应用编排层对应表现层（用户交互与流程控制）。理解了这一层类比，你会发现大模型的工程化并不是什么全新领域，很多后端架构经验照样能用。

4.3 Agent的定义与实现拆解：三层架构协同的典型场景

Agent（智能体）是目前最火的概念。用三层架构去拆解，一个能自主完成任务的Agent通常需要：

• 模型内核层：提供推理能力
• 交互会话层：维护对话历史、调用工具函数、格式化输出
• 应用编排层：定义执行流程（任务规划→工具选择→结果验证→决策下一步）

实际在做Agent时最难的并不是模型能力，而是状态管理和错误恢复。Agent在连续执行多步操作时，任何一步返回异常，整个链路就可能失控。我的方案是每一步都强制模型输出一个结构化日志（包括当前目标、已执行步骤、工具返回结果、下一步计划），这样既方便用户追溯，也方便系统在出错时定位问题并重试。

5. 从真实项目中提炼的常见问题与排查方法

讲了一大堆理论，最后来点实战经验。我把做AI应用这大半年踩坑的典型问题整理成一份速查表，按频率排序，排名靠后的可能冷门但遇到了会很头大。

5.1 高频问题速查表

5.2 一次令我一晚上没睡好的排查实录

之前做客服机器人时遇到过一桩怪事：白天一切正常，一到晚上九点后回答质量直线下降，用户问东它答西，而且响应速度也慢了不少。一开始怀疑是服务器性能瓶颈，但监控上CPU、内存都挺正常。后来查日志才发现，晚高峰时段用户问的问题特别刁钻复杂，上下文长度剧增，输入侧拼接的RAG片段加历史记录已经把上下文窗口挤爆了，模型只能勉强在碎片信息里瞎猜。

解决办法是我加了一道「上下文压缩」工序：每轮对话结束后，提取关键信息（用户诉求、已确认信息、待跟进事项）缓存进一个短摘要里；新对话来临时，历史消息仅保留摘要加最近两轮内容。改完后晚间回答质量立刻回升。

经验就是：大模型应用系统的瓶颈往往不在模型本身，而在你给它输送的上下文的组织方式。输出质量不过关，先别急着换模型，回去检查输入侧是不是塞了一堆没用的垃圾进去。

5.3 三层各自的监控与预警策略

工程化系统离不开监控。我对三层分别有对应的观测指标：模型内核层主要看响应时延、错误率、Token消耗；交互会话层看上下文长度分布、RAG检索命中率、JSON解析失败率、重试次数；应用编排层看业务成功转化率、并发量、资源开销。

特别要提的是Token消耗的观测。很多人只盯着大模型的API账单，却不清楚钱具体烧在哪。实测下来，长对话场景里相当比例的Token都浪费在重复拼接的系统提示词和历史记录上。通过上述的摘要压缩机制，能有效把Token消耗降下来，而且几乎没有体验损失。

6. 进阶玩法：把「输入输出」推向极致的小技巧

这篇内容已经很长，但最后我还是想单开一个篇幅，分享三个我个人测试下来效果拔群、但文档里通常不会写的小技巧，按难度从低到高排。

6.1 用「连问带答」法替代单调追问

有的任务需要模型连做几件事，比如「先判断用户情绪，再根据情绪生成回复」。直觉做法是让模型在两个步骤里分别输出，再人工拼接。但实测下来，直接让模型在一个回答里完成含中间推理但只输出最终结果的效果更好，例如这样设计输出格式：

{ "user_emotion": "frustrated", "confidence": 0.95, "reply": "非常抱歉给您带来不便，我立刻为您核实处理。" }

模型链式思考后输出结构化结果，比拆成多轮调用更稳定，响应也更省Token。当然，如果你需要向用户展示思考过程，那就得两说了。

6.2 输出解析时永远做「磨平处理」

模型输出的JSON字段值往往带有莫名其妙的空格、换行、特殊字符，直接入库或比较会翻车。我习惯在解析后做一层清洗：去首尾空格、统一换行符、过滤控制字符、去除零宽字符。这一招能解决很多诡异的匹配bug。检查下你的字符串是否裹了一层你看不见的特殊字符——这个问题困扰我很久，后来用ASCII码校验才发现。

6.3 善用「输入尺寸」约束让模型更听话

输入尺寸是热词，但我这里说的不是图片尺寸，而是输入内容的长度与结构。有实验表明，模型在接收比较短的指令时遵循度高，指令越长、越复杂，遵循度越差。所以我会把复杂的业务需求拆成多个短指令，分别放在系统提示词和用户提示词里，而不是一股脑全塞进一段长文字里。实测拆分后的可靠性和遵循度确实比一整段长文本高不少。

这是一个反直觉但很有效的小技巧：少即是多。长提示词看着内容全面，实际上是在跟模型的注意力机制作对；拆成短小清晰的指令，反而各条都能被严格执行。

最后再分享一点个人体会

从三层的视角去看，大模型行业这些年的变化，本质上就是围绕「输入什么」和「输出怎么处理」做文章：输入侧从纯文本进化到多模态、RAG、结构化约束；输出侧从流式打印到函数调用、Agent编排。模型内核本身的进展当然重要，但真正让AI从「新鲜玩具」变成「生产力工具」的，恰恰是那些默默无闻的输入输出工程。

我自己实际做AI应用这么久，最深的体会就是：别指望模型一步到位。把输入打磨到极致、把输出处理得干净利落，再复杂的业务场景也能凭借同一个模型内核支撑起来。如果下一次你又看到什么令人眼花缭乱的AI新功能，不妨拆一拆：它在输入侧做了什么改造？又在输出侧加了什么处理？拆完之后，你多半就不再觉得神秘了。