企业官网建设流程全解析

1. 大模型三层架构到底在拆什么

先把结论摆在前面：我接触过的所有大模型应用，不管包装成什么形态——聊天助手、知识库问答、代码补全、文档解析、Agent 工作流——剥到最里面，都逃不出三层结构。基础模型层负责“它本来会什么”，输入构造层负责“我这次让它看到什么”，输出处理层负责“它吐出来的东西怎么变成能用的结果”。

很多人一上来就纠结选哪个模型、要不要微调、用哪个框架，其实方向就偏了。模型本身的能力边界，在绝大多数业务场景里并不是瓶颈。真正决定一个 AI 应用好不好用的，是后面两层：你喂进去的东西对不对，你接出来的东西稳不稳。

我见过太多团队，花大力气做模型选型对比，跑了一堆 benchmark，最后上线效果一塌糊涂。回头一查，问题出在提示词里塞了一堆无关上下文，或者模型返回的 JSON 格式稍微变了一下，下游解析直接崩了。这些都不是模型的问题，是架构的问题。

所以这篇东西，我想把这三层彻底拆开讲清楚。每一层该做什么、不该做什么、常见的坑在哪、怎么用最小的成本把效果拉起来。适合正在做 AI 应用开发的工程师、技术负责人，也适合刚入门想搞清楚全貌的朋友。不需要你懂 Transformer 的注意力机制，但你需要理解每一层的职责边界。

一句话概括三层分工：基础模型决定上限，输入构造决定下限，输出处理决定稳定性。

2. 基础模型层：选型不是选最强，是选最合适

2.1 基础模型到底提供了什么

基础模型层是整个架构的地基。它提供的是通用的语言理解与生成能力——你给它一段文本，它能续写、能总结、能翻译、能推理。但这个能力是“通用”的，不是“专用”的。它不知道你的业务规则，不知道你的数据格式，不知道你的用户是谁。

我经常用一个类比来解释：基础模型就像一个刚毕业的名校高材生，智商很高，学习能力很强，但对你公司的业务一无所知。你可以直接让他干活，但他大概率会按照自己的理解来，结果可能对也可能不对。你也可以先给他做培训（微调），或者每次派活的时候把背景资料准备齐全（输入构造），或者在他交活之后找人审核修改（输出处理）。

基础模型层的关键参数就那么几个：参数量、上下文窗口、推理成本、响应延迟、是否支持函数调用、是否支持结构化输出。这几个参数直接决定了你后面两层能做到什么程度。

2.2 选型时真正该看的几个维度

市面上的模型太多了，每隔几周就有新的出来。但选型的时候，不要被各种榜单迷惑。我自己的经验是看这几个维度：

上下文窗口决定你能一次性喂多少信息。做知识库问答，窗口小了根本不够用；做简单分类任务，窗口大小无所谓。但要注意，很多模型标称支持 128K 甚至 1M 的上下文，实际有效利用的往往只有前面一部分，中间的内容容易被“遗忘”。这是注意力机制的特性决定的，不是 bug。

结构化输出能力决定你输出处理层的工作量。有些模型对 JSON 格式的遵循度很高，你让它输出 JSON 它就老老实实输出 JSON；有些模型你千叮咛万嘱咐，它还是会在 JSON 外面加一段“好的，以下是结果：”。这个差异在实际工程中影响巨大。

推理成本与延迟决定你的应用能不能规模化。我算过一笔账：如果一个请求平均消耗 2000 个 token，按某些模型的价格，一万次调用就是几十到几百块不等。如果你的应用日活上万，这个成本必须提前算清楚。

是否支持微调决定你能不能把领域知识固化进去。但说实话，大多数场景不需要微调。提示词工程能解决的问题，不要用微调去解决，因为微调的维护成本高得多。

2.3 微调不是万能药，什么时候才该动它

“大模型微调”这个词现在太热了，好像不做微调就不算做 AI。但我实际的经验是：百分之八十的场景，提示词工程加输出校验就能解决，不需要微调。

微调真正适用的场景是：你需要模型学会一种固定的输出风格或格式，而且这种格式很难用提示词描述清楚；或者你需要模型掌握大量领域专有知识，而这些知识无法通过检索的方式注入；或者你需要降低推理成本，用一个小模型微调后替代大模型。

微调的方式现在也很多，全量微调、LoRA、QLoRA 等等。LoRA 是最常用的，因为它只需要训练很少的参数，对显存要求低，效果也不错。但微调有一个容易被忽视的问题：灾难性遗忘。模型在学会新任务的同时，可能会忘掉原来的通用能力。所以微调后的模型，一定要做全面的回归测试。

我的建议：先把输入构造层和输出处理层做到极致，如果效果还不够，再考虑微调。顺序反了，你会浪费大量时间和算力。

3. 输入构造层：决定模型表现的关键战场

3.1 提示词工程的本质是什么

输入构造层，说白了就是决定模型在生成回复之前，它的“视野”里有什么。这包括系统提示词、用户输入、历史对话、检索到的知识、工具描述等等。所有这些拼在一起，构成了模型的完整输入。

很多人把提示词工程理解成“写一段神奇的话让模型变聪明”，这是误解。提示词工程的本质是信息管理——在有限的上下文窗口里，放入最相关、最清晰、最无歧义的信息。

我见过一个典型的失败案例：一个客服问答系统，把整个产品手册（几万字）塞进系统提示词，然后让模型回答用户问题。结果模型要么答非所问，要么把不同产品的信息混在一起。问题不在于模型不行，在于输入构造层偷懒了——应该先检索出最相关的几段，再喂给模型。

3.2 系统提示词怎么写才有效

系统提示词是输入构造层里最重要的部分。它定义了模型的角色、任务边界、输出格式、行为准则。我写系统提示词一般遵循这几个原则：

角色定义要具体。不要写“你是一个有用的助手”，要写“你是一个专门处理电商退换货问题的客服专员，你只能回答与退换货政策相关的问题，其他问题一律引导用户联系人工客服”。越具体，模型的行为越可控。

输出格式要明确。如果你需要 JSON，就把 JSON 的 schema 写出来，最好给一个示例。如果你需要 Markdown，就说明哪些字段用加粗、哪些用列表。模型对格式的遵循度，很大程度上取决于你描述得够不够清楚。

边界情况要覆盖。用户问了你不该回答的问题怎么办？检索不到相关信息怎么办？用户输入了乱码怎么办？这些都要在系统提示词里提前定义好处理方式。

少用否定句。你告诉模型“不要做什么”，它反而容易去做。更好的方式是告诉它“应该做什么”。比如不要写“不要编造信息”，而是写“如果信息不足，请回复‘根据现有资料无法回答该问题’”。

3.3 上下文工程：比提示词更重要的能力

“大模型提示词工程与上下文工程”这个词最近很火，我觉得上下文工程才是更准确的描述。因为实际工作中，写提示词只占一小部分时间，大部分时间花在决定什么信息该放进上下文、什么信息不该放、怎么放。

上下文工程的核心是检索与排序。你需要从各种数据源（数据库、文档、API）中找出与当前请求最相关的信息，然后按照重要性排序，放入上下文窗口。这里有几个实操要点：

分块策略很关键。文档不能整篇塞进去，要切成合适大小的块。块太大，噪声多；块太小，信息不完整。我一般用 200-500 字作为一个块，块之间保留一定的重叠，避免关键信息被切断。

检索要混合多种方式。纯向量检索适合语义匹配，但对精确的关键词匹配效果不好。我通常用向量检索加关键词检索的混合方案，再做一个重排序，效果比单一方式好很多。

上下文要控制长度。不是塞得越多越好。研究表明，上下文过长时，模型对中间部分的注意力会下降。所以要把最重要的信息放在开头或结尾，中间放次要信息。

历史对话要压缩。多轮对话场景下，历史记录会越来越长。我的做法是保留最近几轮完整对话，更早的对话做摘要压缩。摘要的质量直接影响后续对话的连贯性。

3.4 一个完整的输入构造流程

让我用一个实际场景来串一下。假设你在做一个“基于企业知识库的智能问答”应用，用户问：“我们公司的年假政策是怎样的？”

输入构造层要做的事情：

1. 意图识别：判断这是一个政策查询类问题，不是闲聊，不是代码问题。
2. 查询改写：把“年假政策”扩展成“年假 休假 假期 政策 规定 员工手册”，提高检索命中率。
3. 检索：从知识库中找出最相关的文档块，比如员工手册中关于休假的章节。
4. 重排序：对检索结果按相关性排序，取前 3-5 个块。
5. 上下文组装：系统提示词（角色定义+输出格式）+ 检索到的文档块 + 用户问题。
6. 长度检查：确保总 token 数不超过模型窗口的 80%，留出生成空间。

这一套流程下来，模型拿到的输入是干净、相关、结构化的，回答质量自然就上去了。

实操心得：输入构造层做得好，小模型也能有大模型的效果；输入构造层做得差，大模型也救不了你。

4. 输出处理层：从“能生成”到“能使用”的最后一公里

4.1 为什么输出处理层最容易被忽视

大部分教程和文章都在讲怎么选模型、怎么写提示词，很少有人认真讲输出处理。但实际工程中，输出处理层决定了你的应用能不能稳定运行。

模型返回的是一段文本，但你的下游系统需要的是结构化的数据。这中间的转换过程，就是输出处理层要解决的问题。如果这一步没做好，模型偶尔返回一个格式不对的结果，整个流程就断了。

我踩过的最大的坑就是：早期做的一个应用，直接拿模型返回的文本去解析 JSON，没有做任何校验和容错。结果上线第一天，模型返回了一个带 markdown 代码块标记的 JSON，解析直接报错，整个服务挂了。从那以后，我对输出处理层的重视程度提到了最高。

4.2 结构化输出的几种实现方式

让模型输出结构化数据，有几种不同的思路，各有优劣：

纯提示词约束是最简单的方式，在系统提示词里写清楚格式要求，让模型自己遵循。优点是实现简单，缺点是稳定性差，模型偶尔会“忘记”格式要求。

函数调用是更可靠的方式。你定义一个函数签名，模型会按照签名返回参数。这种方式对格式的约束更强，但需要模型支持函数调用能力。

JSON Schema 约束是介于两者之间的方案。你提供一个 JSON Schema，模型按照 Schema 生成输出。有些模型和框架支持这种模式，效果比纯提示词好。

后处理解析是最后的兜底。不管模型返回什么，你都用正则或解析器去提取需要的信息。这种方式最灵活，但也最脆弱。

我的实际做法是组合使用：优先用函数调用或 JSON Schema，同时在提示词里强调格式要求，最后再加一层后处理解析做兜底。三层防护下来，稳定性基本没问题。

4.3 输出校验与容错机制

输出处理层必须包含校验和容错。校验是检查模型返回的内容是否符合预期，容错是在不符合预期时怎么处理。

校验的维度包括：格式校验（是不是合法的 JSON）、字段校验（必需的字段有没有缺失）、类型校验（字段类型对不对）、业务校验（值是否在合理范围内）。

容错策略有几种：重试是最简单的，让模型重新生成一次；修复是尝试自动修正格式问题，比如补全缺失的括号；降级是返回一个默认值或错误提示，保证流程不中断；人工介入是把问题案例记录下来，后续人工处理。

我一般会设置一个重试次数上限，比如 3 次。3 次都失败，就走降级逻辑。同时把所有失败案例记录下来，定期分析原因，优化提示词或调整模型参数。

4.4 流式输出的处理技巧

现在很多应用都用流式输出，让用户看到文字一个字一个字蹦出来，体验更好。但流式输出给输出处理层带来了新的挑战：你拿到的是不完整的文本片段，怎么处理？

我的做法是分层处理。对于展示给用户看的内容，直接流式输出，不做复杂处理。对于需要结构化解析的内容，等流式结束后再统一处理。如果必须在流式过程中解析，那就需要维护一个缓冲区，每次收到新片段就尝试解析，解析成功就触发后续逻辑。

流式输出还有一个坑：函数调用的参数是分片到达的。你不能收到第一个片段就去解析参数，要等所有片段都到齐了再解析。这个在实现的时候要特别注意。

5. 三层架构在实际项目中的配合方式

5.1 一个完整的 AI 应用请求生命周期

让我用一个完整的例子把三层串起来。假设你在做一个“智能合同审查”应用，用户上传一份合同，系统自动识别风险条款并给出修改建议。

输入构造层要做的事情：解析合同文件，提取文本；把合同按条款切分；对每个条款，构造一个提示词，包含审查规则、输出格式要求、条款内容。

基础模型层接收提示词，生成审查结果。这里模型的选择很关键，合同审查需要较强的推理能力和领域知识，小模型可能搞不定。

输出处理层接收模型返回的文本，解析成结构化的风险项列表，每项包含风险等级、风险描述、修改建议。然后把这些结果汇总，生成审查报告。

整个流程中，三层各司其职。输入构造层决定了模型能看到什么，基础模型层决定了能生成什么，输出处理层决定了最终能交付什么。

5.2 不同场景下三层的权重分配

三层架构不是平均用力的，不同场景下重点不同：

知识库问答：输入构造层最重要。检索质量直接决定回答质量。模型用中等规模的就行，输出处理相对简单。

代码生成：基础模型层最重要。代码能力强的模型和弱的模型差距巨大。输入构造层相对标准化，输出处理主要是代码格式化和语法检查。

数据抽取：输出处理层最重要。从非结构化文本中抽取结构化信息，格式稳定性是关键。模型需要支持结构化输出，输入构造层要做良好的分块和标注。

Agent 工作流：三层都很重要。输入构造层要管理工具描述和对话历史，基础模型层要支持函数调用和多步推理，输出处理层要解析工具调用参数并处理执行结果。

5.3 成本与效果的平衡策略

做 AI 应用，成本和效果永远是一对矛盾。我的平衡策略是分层降级：

对于简单任务，用小模型加精心构造的输入，效果够用，成本低。对于复杂任务，用大模型加完整的输入构造和输出处理，保证效果。对于中等任务，可以用小模型先试，效果不够再升级到大模型。

具体实现上，可以做一个路由层，根据请求的复杂度自动选择模型。复杂度判断可以基于规则（比如输入长度、问题类型），也可以用一个轻量级分类模型来判断。

另一个策略是缓存。很多请求是重复的或相似的，缓存结果可以大幅降低成本。缓存的粒度可以是完整的请求-响应对，也可以是中间结果（比如检索结果）。

6. 常见问题与排查技巧实录

6.1 模型不按格式输出怎么办

这是最高频的问题。模型返回的 JSON 多了 markdown 标记，或者字段名拼错了，或者该用数组的地方用了字符串。

排查思路：先检查提示词里的格式描述是否足够清晰，有没有给示例。然后检查模型是否支持结构化输出，如果支持就开启。最后加一层后处理解析做兜底。

我的经验是：给示例比给描述有效。与其写“请输出 JSON 格式”，不如直接给一个完整的 JSON 示例。模型对示例的遵循度远高于对描述的理解。

6.2 检索不到相关内容怎么处理

知识库问答场景下，用户问了一个知识库里没有的问题，模型可能会编造答案。这是很危险的行为。

解决方案是在输入构造层加一个相关性阈值。检索结果的相关性分数低于阈值时，不把结果喂给模型，而是直接返回“未找到相关信息”。同时，在系统提示词里明确告诉模型：如果上下文信息不足，必须回复“根据现有资料无法回答”。

6.3 多轮对话中模型“忘记”之前的内容

这是上下文窗口限制导致的。对话轮次多了，早期内容被挤出窗口，模型自然就“忘记”了。

解决方案是对话摘要。当对话轮次超过一定数量时，把早期的对话压缩成一段摘要，放在上下文的开头。摘要要保留关键信息：用户的需求、已经确认的事实、达成的共识。

摘要的生成可以用模型来做，也可以用规则提取。我一般用模型生成摘要，因为质量更好，但要注意摘要本身也会消耗 token。

6.4 模型响应速度慢怎么优化

响应速度受多个因素影响：模型大小、输入长度、输出长度、网络延迟、服务端负载。

优化方向：减少输入长度，去掉不必要的信息；减少输出长度，让模型简洁回答；使用流式输出，让用户先看到部分结果；选择合适的模型，不是所有任务都需要最大的模型；做好缓存，重复请求直接返回缓存结果。

6.5 几个我踩过的坑

坑一：系统提示词太长。我曾经写了一个两千字的系统提示词，结果模型对后面的指令遵循度明显下降。后来精简到五百字以内，效果反而更好。提示词要精炼，每句话都要有明确目的。

坑二：忽略 token 计数。早期没有做 token 计数，有一次用户输入特别长，加上检索结果，直接超了模型窗口，请求报错。后来加了 token 计数和截断逻辑，再也没出过这个问题。

坑三：没有做输出长度限制。模型有时候会“话痨”，生成很长的内容。后来在参数里设置了 max_tokens，同时在提示词里要求简洁回答，输出长度可控了。

坑四：微调后没有做回归测试。有一次微调了一个模型，专门优化某个任务的输出格式，结果通用对话能力下降了很多。后来建立了回归测试集，每次微调后都跑一遍，确保没有退化。

这些坑的共同点是：都不是模型本身的问题，而是架构设计的问题。三层架构的每一层都要认真对待，不能偷懒。

7. 从三层架构看 AI 应用开发的演进方向

7.1 输入构造层的自动化趋势

现在输入构造层还有很多手工活：手工写提示词、手工调检索参数、手工设计分块策略。未来的趋势是自动化——自动优化提示词、自动调整检索策略、自动学习最佳的分块方式。

已经有一些工具在做这方面的事情，比如自动提示词优化、自动检索增强生成（RAG）调参。但完全自动化还有距离，目前还是需要人工介入。

7.2 输出处理层的标准化趋势

输出处理层现在很碎片化，每个项目都有自己的解析逻辑。未来可能会出现标准化的输出协议，模型按照协议返回，下游按照协议解析，减少中间的转换成本。

函数调用和 JSON Schema 已经是这个方向的雏形。随着模型能力的提升，结构化输出的可靠性会越来越高，输出处理层的复杂度会逐渐降低。

7.3 三层架构的边界在模糊

随着模型能力的发展，三层的边界在变得模糊。比如，一些新的模型支持“工具使用”，可以在生成过程中调用外部 API，这模糊了输入构造层和输出处理层的边界。再比如，一些框架把检索、生成、后处理打包成一个整体，三层被封装在框架内部。

但不管怎么封装，三层的逻辑依然存在。理解这三层，就理解了 AI 应用的本质。工具和框架会变，但“输入什么、模型生成什么、输出怎么处理”这个核心逻辑不会变。

我在实际项目中的体会是：不要被各种新概念带偏，回到三层架构来思考问题，很多困惑就迎刃而解了。模型选型纠结的时候，想想输入构造层能不能弥补；输出不稳定的时候，想想是不是校验和容错没做好。三层架构不是理论，是实实在在的工程指南。