企业官网建设流程全解析

大模型三层架构拆解：所有 AI 新花样，只在「输入什么 / 输出怎么处理」

最近很多人问我：大模型每天都能冒出新玩法，今天做智能客服，明天做报告生成，后天又搞了个自动写代码工具，这些到底是怎么做到的？是模型又升级了？其实大部分时候，模型根本没变。你看到的那些让人眼前一亮的“AI 新花样”，绝大多数是在模型的入口和出口下功夫。我做了几年大模型应用开发，习惯把所有工作拆成三层：输入处理层、模型内核层、输出处理层。搞懂这三层，你就不再需要追着热点跑，因为所有花活，本质上只是在回答两个问题：你给模型喂了什么？你从模型吐出来的东西里做了什么？

这篇文章适合正在做 AI 应用、或者想把大模型真正用起来的人，不管你是产品经理还是开发者，都能从中找到一套思考框架。我会从原理讲到实操，最后给一些踩过坑的经验，保证你看完能拿着这套思路去拆解任何 AI 产品。

1. 先建一张框架图：大模型的三层架构到底是什么

很多人把大模型理解成一个巨大的黑盒子：输入一句话，输出一句话，中间全是神经网络。这个理解没错，但对做应用的人来说，太粗了。真正需要分清的是：哪些东西是模型负责的，哪些东西是你负责的。我的划分方式很简单：输入层、内核层、输出层。

1.1 我习惯把模型拆成“入口、内核、出口”三层

入口层（输入处理）指的是在模型真正计算之前，你为这次调用准备的所有内容。包括提示词怎么写、上下文怎么拼、历史对话怎么组织、外部文档怎么检索进来、用户的问题怎么被重新表述。这一层完全由你控制，模型本身不参与。

内核层（模型推理）指的是模型内部的参数和计算过程。对于大多数应用开发者来说，这层就是 API。你发过去一段拼接好的文本，模型基于预训练和微调学到的能力，计算出一个概率分布，然后从这个分布里采样生成文字。这个过程你无法干预（除非你做微调或蒸馏，那是另一个层级的工作）。

出口层（输出处理）指的是模型吐出来原始文本之后，你做的所有事儿。包括解析 JSON、提取字段、过滤敏感词、把结果重新排版、把一段话拆成结构化数据、把输出的文字喂给另一个系统执行动作。很多产品真正体现体验差异的地方，就在这一层。

1.2 三层架构的核心逻辑：一切应用创新都在输入和输出的加工上

为什么说“所有 AI 新花样”都和输入输出有关？因为模型内核的变化非常慢。你用的模型可能几个月甚至一年才升级一次，但应用每天都在变。同一个模型，你可以让它做客服、做翻译、做 SQL 生成、做角色扮演，靠的完全是不同的输入构造和输出解析。

我举个夸张的例子：同样一个通用模型，给它一段“你现在是数据库专家，只输出 SQL”的输入，再把用户自然语言问题附在后面，它就能变成 SQL 生成器。然后你在输出层加上一个正则校验，发现它生成了“SELECT * FROM users”就直接执行，如果生成了错误的命令就重新生成。整个过程，模型内核一点没动，但产品形态完全变了。这就是三层架构的意义：把变化留给输入输出，把稳定留给内核。理解了这一点，你再去看任何 AI 产品时，就会自动去想：它到底在入口做了哪些加工？在出口做了哪些整理？内部是不是还是那个通用模型？

2. 输入层：决定模型“听懂了什么”

输入层是最容易被低估的部分。很多人觉得写提示词就是“把话说清楚”，其实不是。模型不是人，它没有“理解”能力，它只是在做概率预测。你给它一段文本，它会根据统计规律续写最可能的下一段。所以输入的构造方式，直接决定了续写方向。

2.1 提示词不是咒语，是上下文管理

传统软件是有状态的，你定义好变量和函数，程序按逻辑执行。大模型不一样，它每次调用都是“无状态”的——你给什么，它回什么，它不记得你之前说了什么（除非你把历史都塞进去）。因此，提示词的核心作用就是：你想让模型从哪个概率空间里采样，就把相关语料放在它的上下文里。

举个例子。你只输入“给我写一篇博客”，模型可能给出任何主题、任何风格的文本。但如果你输入：

你是一位技术博主，擅长用通俗语言解释复杂概念。请给我写一篇博客，主题是“大模型的注意力机制”，目标读者是完全不懂 AI 的普通用户，字数 800 字。要求先讲一个生活化比喻，再解释原理，最后给出一个简单案例。

模型续写出来的内容就会非常不一样。不是模型变聪明了，而是你通过输入，把它的预测空间从“所有中文文本”缩小到了“技术博客风格的文本”。所以我常说：提示词的本质是上下文管理，而不是魔法咒语。理解了这句话，你就知道为什么“提示词工程”要不断迭代——因为你在控制模型的采样空间。

2.2 输入层的高级玩法：检索增强与记忆注入

上下文管理再往前走一步，就是检索增强生成（RAG）。RAG 的本质，是在模型回答之前，先把相关信息从外部知识库里检索出来，拼到输入里。为什么这么干？因为模型的内部知识是有限的，它不知道你公司内部文档、你的数据库记录、最新新闻。你不可能每问一个问题就把整个知识库塞给模型，只能根据用户问题，把最相关的几段内容检索出来，放进输入。

具体流程是：用户提问 -> 把问题向量化 -> 在向量数据库里找到相似文档 -> 把文档片段和问题一起作为输入发给模型 -> 模型基于给定文档回答。这一整套动作，全部发生在输入层。我实测下来，RAG 比反复让模型“记住”某个事实要可靠得多，原因是模型没有任何真正意义上的记忆，你喂给它什么，它就只能用什么。

和 RAG 类似的还有“记忆注入”，比如在每轮对话前，先把你之前记录的用户偏好拼进输入：

历史信息：用户小张，偏好简洁回复，不喜欢表情符号，上次咨询过退款政策。 当前问题：发票怎么开？

这样模型自然会在回答时带上小张喜欢的风格。你说这是模型有记忆吗？不是，是输入层替模型“装”了一个记忆。

2.3 输入层实操要点：结构化输入、角色设定、示例引导

输入层做得好的团队，会把提示词当成代码来维护。我自己常用的几个技巧：

第一，结构化输入比大白话可靠。把背景信息、指令、约束分块，用清晰的标记区分。比如：

[系统] 你是一个合同审核助手。 [材料] {合同原文} [任务] 请找出合同中的风险条款，并用中文列出。 [要求] 每条风险给出严重程度（高/中/低）和建议修改方式。

这样模型更容易按照你期望的结构输出，也方便程序去解析。

第二，少样本示例（Few-shot）永远比单纯描述好使。如果你希望模型输出固定格式，不要只写“按以下格式输出”，直接给它两个真实例子更好。比如：

输入：明天北京天气如何？ 输出：{"城市": "北京", "查询": "天气", "日期": "明天"} 输入：帮订一张周五从上海到成都的机票。 输出：{"出发": "上海", "到达": "成都", "日期": "周五", "类型": "机票"}

模型看到模式后，会模仿模式。这种能力很神奇，你不需要解释“键是什么、值是什么”，它自己会从例子里学。

第三，别忽视输入长度的限制。上下文窗口是有限的，输入越长，模型的响应质量和速度都会受影响。如果把整个知识库都塞进去，模型可能会被噪音干扰。我之前做某项目时，一开始把所有销售话术都放进输入，模型回答质量反而变差，因为关键信息被其他内容淹没了。后来改成先检索、再拼接，效果立刻好了。输入层的核心能力，是判断什么该给模型看，什么不该给。这比“怎么把话说得漂亮”重要得多。

3. 输出层：决定模型“说得好不好”

模型吐出来的是一段原始文本，但产品需要的往往是干净、可解析、可执行的东西。输出层做的，就是把这段自由文本“驯化”成真正可用的结果。很多开发者只关注提示词，却忽略了输出层同样需要精心设计。

3.1 解码参数：温度、Top-P、Max Tokens 的真实影响

在输出层，最基础的控制是解码参数。温度（temperature）控制随机性：温度越低，概率越高的词被选中，输出越确定；温度越高，越可能选到生僻词，输出越有创造性。Top-P 也类似，它控制采样时只考虑累积概率到达某个阈值的词。Max Tokens 限制输出长度。

用场景来说：你让模型做信息抽取、判断、生成 SQL，温度设成 0 或者 0.2 最合适，因为你需要稳定答案。你让模型写营销文案、写故事、做头脑风暴，温度设成 0.7 到 0.9 更合适。有些产品为了追求千篇一律的“稳定感”，把所有场景都设成低温，结果就是文案干巴巴、创意完全出不来。输出参数不是固定值，而是产品形态的一部分。

我在实际项目中还会配合“重复惩罚”等参数来减少复读机现象。但请注意，这些参数是输出层的“粗调”。真正让输出质量产生质变的，是后面的结构化处理和解析。

3.2 结构化输出和后处理：把自由文本变成可用产品

这里是我最想强调的一点：模型的输出不是产品的终点，而是半成品。做应用时，几乎没有人直接展示模型的原始输出，而是会做大量后处理。

举例来说，你想让模型从一篇文章里提取出“公司名、金额、日期”。你可以要求模型输出 JSON：

请从文本中提取信息，并严格按照以下 JSON 格式返回： {"公司名称": "", "合同金额": "", "签署日期": ""}

但模型偶尔会在 JSON 前后附带解释性文字，或者 JSON 本身非法（缺少逗号、多余引号）。如果你直接把字符串丢给json.loads()，大概率报错。这时候输出层的价值就来了：你要么用正则从响应中截出 JSON 片段，要么用更宽容的解析器去容错。更稳妥的方案是在提示词里再做一层“保险丝”，比如加上一句“只输出 JSON，不要输出任何其他内容”，然后在代码里保留解析失败的补救逻辑。

再进一步，如果模型输出的是 Markdown 表格或列表，你可以用程序把它转换成 HTML、Word、PDF。很多“AI 生成 PPT”“AI 生成报告”类产品，本质上就是模型负责生成文字和结构，程序负责渲染成文件格式。输出层的想象力远比你想的大。

3.3 输出层常见应用：流式输出、函数调用、安全过滤

流式输出（Stream）是很影响体验的功能。模型不是一次生成完整答案，而是逐个 token（或小块）返回。你可以把它比喻成打字机效果。实现流式的好处是：用户不用等 5 秒才能看到第一个字，而是 0.5 秒后就开始看到内容。对聊天产品来说，这个感知差异极大。不过流式也带来新问题：因为内容是逐步到达的，你没法一次性对完整输出做后处理。所以很多产品会做“边生成边缓冲”的方案，先展示，等全部完成后在后台再做修正和标记。

函数调用（Function Calling / Tool Use）是输出层的另一种高级玩法。它让模型在生成文本时，同时选择是否调用某个函数，并输出符合函数签名的结构化参数。举个例子：

可用函数：get_weather(city, date) 用户输入：北京明天冷吗？ 模型输出：调用函数 get_weather(city="北京", date="明天")

这种方式让模型不只是“说话”，还能“做事”。你的程序收到模型输出的函数名和参数后，去调用天气 API，再把结果反馈给模型，让模型生成最终回答。整套链路里，模型内核没变，完全靠输入层的“函数定义”和输出层的“函数解析”实现了智能助手的能力。

还有一个不能忘的是安全过滤。模型可能输出攻击性内容、幻觉数据或者不合适的词汇。输出层可以加关键词过滤、敏感信息脱敏、内容审核接口。这不是为了限制模型，而是为了让产品合规、稳健。

4. 中间层：模型内核的“不变”与“微变”

很多人在输入输出上折腾半天后，会遇到一个瓶颈：模型本身的某种能力确实没有，怎么办？这时候才轮到中间层——模型内核——上场。但动手之前，你得先搞清楚什么情况该动内核，什么情况不该动。

4.1 为什么说模型层基本是“黑盒”

对于使用 API 的人来说，模型内核是一套固定的权重参数。你发请求，它推理。除了供应商偶尔更新版本，你没有任何办法直接改变这个黑盒。它的优点就是通用：什么都会一点；缺点也是通用：什么都不太专精。比如你用通用模型做法律文档审核，它可能对专业术语的理解不够准确。但你很少因此就直接去微调模型，因为成本高、周期长、维护麻烦。

更尴尬的是，模型内部到底怎么“思考”的，连研究者也很难完全解释。你问它“2+2 等于几”，它能答出来；但你问它“为什么这个逻辑不对”，它可能洋洋洒洒解释一大堆，实际上还是错的。这就是黑盒属性。我们能做的，就是通过输入输出两层，把模型的潜力压榨出来。

4.2 微调、LoRA与RAG的关系：什么时候才需要动模型

先明确一个原则：能在输入层解决的问题，就不要动模型。想让模型知道某件事实？用 RAG，把事实写进输入。想让模型模仿某种语气？在提示词里给例子。想让模型总是输出特定格式？用少样本提示词。这些方法零成本、可迭代、可回滚。只有在以下场景，才考虑微调：

• 你需要模型持续稳定地模仿某种特定文风或任务，而提示词太长、太贵；
• 你需要模型掌握输入层无法描述的行业缩写、专有术语和规则；
• 你需要降低推理成本，想用一个更小的模型达到原本通用大模型的效果。

LoRA（低秩适配）是现在最流行的微调方式。它不动原模型的全部参数，只训练一小部分适配器，成本低。比如你有一个法律问答场景，你可以用一批“问题-标准答案”数据训练 LoRA，让模型更懂术语。但即使如此，我仍然建议先从 RAG 加提示词开始。因为微调之后，模型可能“学坏”——在训练数据不足时，它可能记住噪声，泛化能力下降。RAG 则不会污染模型本身的权重。

还有一个常见误区：把 RAG 和微调对立起来。实际上它们可以配合使用。RAG 负责给模型“查资料”，微调负责教模型“怎么按你的口味写”。比如我先用 RAG 检索出产品相关条款，再用微调后的模型以特定格式总结出来。两者分工明确，效果远好于单用某一种。

5. 实战拆解：同一个模型如何做出不同应用

理论讲多了容易飘，我必须带你看三个具体场景，演示三层架构如何落地。这三个场景我都实际做过，讲清楚每一步是在哪一层做的、为什么。

5.1 场景A：让模型从“聊天”变成“结构化信息抽取”

目标：用户输入一段自然语言，比如“帮我约明天下午三点和张总开会”，程序要解析出结构化日历信息：标题、时间、参与人。模型内核只是通用对话模型。

输入层构造：

[系统] 你是一个日程助手。从用户话术中提取结构化信息。 [可用字段] 标题、开始时间、结束时间、参与人。 [规则说明] 时间格式使用YYYY-MM-DD HH:MM；如果缺少结束时间，默认开始时间后1小时；如果缺少参与人，填写“未指定”。 [示例] 用户：帮我订周五晚上七点和李总吃饭 输出：{"标题":"和李总吃饭","开始时间":"周五 19:00","结束时间":"周五 20:00","参与人":"李总"} [待解析内容] 帮我约明天下午三点和张总开会

输出层处理：

模型返回一段 JSON 文本，但偶尔会在 JSON 外加上“好的，我已经提取了以下信息：”之类的前缀。我在代码里先截取第一个{到最后一个}之间的内容，再尝试解析。解析成功后，还要做时区归一化：“明天”不能直接进数据库，得在程序里计算成具体日期，这一步也是输出层。最终程序把解析后的 JSON 写入日历 API。

整个过程模型内核完全没变，但你得到的是一个好用的“短信语义解析器”。

5.2 场景B：让模型从“单轮对话”变成“多步工具调用”

目标：做一个能帮用户查天气、订酒店的客服机器人。光靠单轮问答不行，必须支持多步动作。

输入层构造：

在提示词里给模型声明可用工具：

[可用工具] search_flight(出发地, 目的地, 日期) search_hotel(城市, 入住日期, 离店日期) book_flight(航班号) [规则] 当用户请求涉及以上功能时，必须输出 JSON：{"tool": "函数名", "params": {参数}}。如果缺少必要参数，先向用户询问。

用户说：“我周五要去上海，帮我看看航班。”模型输出{"tool": "search_flight", "params": {"出发地": "北京", "目的地": "上海", "日期": "周五"}}。

输出层处理：

程序解析出函数名和参数后，调用真实航班查询 API。拿到结果后，再把它拼进输入层，发送第二轮请求：

[已有航班结果] CA123 北京-上海 09:00-11:00，票价1200元。 [用户问题] 那订这班吧。

模型基于给定的航班结果，输出{"tool": "book_flight", "params": {"航班号": "CA123"}}。程序再次调用订票 API。这个循环在输入层和输出层之间多次往返，模型的“多步能力”其实是你通过程序支持出来的。你说它是 AI 智能？我更愿意说，是架构流程智能。

5.3 场景C：让模型从“生成文本”变成“生成图像/语音的指令”

目标：用户说“给我画一只在月球上打篮球的猫”，程序最终要调用另一个图像生成模型。大语言模型本身不会画图，但它可以生成绘图模型的提示词。

输入层构造：

[系统] 你是一个提示词翻译器。把用户的自然语言描述，转换成适合图像模型的英文提示词，要求包含主体、场景、风格、光影等关键信息。 [用户输入] 一只猫在月球上打篮球

模型输出类似A cute cat playing basketball on the moon, outer space background, cinematic lighting, 8k resolution。这就是一个典型的输出层“再加工”案例：你把模型生成的提示词直接传给图像生成 API，就能得到图片。同样，如果你想让模型生成语音播报，也可以在输入层指定“把下面文本转成口语化播报稿”，输出层再调用 TTS。本质上，大语言模型成了“多模态任务的编排中枢”，而它自己只做了一件事：根据输入输出文本。

6. 常见问题与避坑技巧

做输入输出处理这几年，我踩过不少坑。挑几个最常见的，做成速查表，希望你少走弯路。

6.1 输入太长被截断怎么办

问题表现：模型回答时明显丢失了输入末尾的信息，甚至直接复述输入开头的内容。原因很简单：上下文窗口有限，输入超过限制就会被截断。解决办法不是盲目压缩，而是做优先级排序。把最关键的内容放在输入的开头和结尾，因为模型对这两个位置的注意力较强；把容易丢失的中段放历史记录或次要资料。如果资料实在太多，先用 RAG 检索出最相关的片段，而不是全部塞进去。还要注意观察 token 消耗，很多产品上线后成本飙升，就是因为每次请求都携带了大量无用上下文。

6.2 输出乱码、JSON解析失败怎么办

模型输出不是程序约定，它是概率生成，所以“偶尔不守规矩”是常态。我之前做某个项目，模型返回的 JSON 里出现了换行符和中文标点，导致json.loads直接崩溃。解决方法分几层：第一层是格式约定，在提示词里明确“输出必须是纯 JSON，不要 markdown，不要注释”；第二层是后处理，用正则剥离多余前缀后缀，或者写一个容错解析器，把单引号换成双引号、去掉尾随逗号；第三层是失败重试，如果解析失败，把“你刚才的输出格式不符合要求，请重新输出”拼在历史后面，再请求一次。后面这种办法实测非常有效。

6.3 模型“能力不够”时，先别急着微调

几乎所有新人都会犯的一个错：模型表现不好，第一反应是“模型太笨，换更大的模型或者微调”。但仔细排查后会发现，90% 的情况是输入没写好，或者输出后处理没兜住。比如模型不会做数学题，可能是你输入的题目格式不对；模型无法回答某领域问题，可能是你没给它相关上下文；模型输出格式老变，可能是你少给了示例。我的建议流程是：先优化提示词，再加上少样本例子，然后考虑 RAG，最后才是微调。每一步都能在 10 分钟内验证，而微调动辄要准备数据、训练、评估，成本和风险高一个量级。在模型内核上做文章，永远是最后一张牌。

我个人最深的体会是：大模型应用的工程难点，从来不在“模型有多聪明”，而在于你愿不愿意在输入和输出两条路上把它伺候好。输入决定了它的上限，输出决定了产品的下限。你把这两层的细节打磨好，哪怕用的模型再普通，也能做出体验不错的产品。下次看到一个刷屏的 AI 应用，不妨按三层架构拆一下，你会突然发现，很多炫酷效果背后的原理，真的就一句话：把输入包装好，把输出处理好，剩下的，全是工程。