企业官网建设流程全解析

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

1.1 从一个常见困惑说起

这两年AI圈的新概念几乎是以周为单位往外冒。今天某个团队发布了新的智能体框架，明天又有人搞出了新的记忆机制，后天满屏都是某个推理增强方案。很多做开发的朋友跟我聊起来都有一个共同的感受：东西太多，学不过来，而且越看越迷糊，感觉每个新东西都是一套独立的体系。

但我自己折腾了这么久，从最早写提示词，到后来搭检索增强，再到现在做多步骤的任务编排，慢慢发现一个事情：这些看起来五花八门的新玩法，拆到根子上，其实都在解决同一类问题，而且它们的位置基本都能归到三个层次里去。

这个三层架构不是我发明的什么理论，而是我在实际做项目的过程中，反复踩坑之后总结出来的一套理解框架。它的核心逻辑特别简单：不管外面的花样怎么变，你只需要问两个问题——输入给模型的是什么？模型的输出你又是怎么处理的？把这两个问题想清楚，再配合中间模型本身的能力边界，基本上任何一个新方案你都能快速定位它在干什么。

1.2 三层架构的具体划分

我先把这三层摆出来，后面再逐层展开。

第一层是输入层。这一层管的是：你往模型里塞什么东西。包括你的提示词怎么写、要不要附带参考资料、要不要加历史对话、要不要把外部数据检索进来、要不要做多轮的任务拆解。所有跟“喂什么给模型”相关的工作，都归在这一层。

第二层是模型层。这一层是模型本身的能力，包括它的参数规模、训练数据、推理能力、上下文窗口大小、是否经过特定方向的微调。这一层对大多数应用开发者来说，能动的空间其实不大，但你必须清楚它的边界在哪里，因为你的输入设计和输出处理都得围着这个边界来。

第三层是输出层。这一层管的是：模型吐出来的东西，你怎么接、怎么验、怎么用。包括输出格式的约束、结果的校验和纠错、多步结果的拼接、工具调用的解析、最终呈现给用户之前的后处理。所有跟“拿到输出之后干什么”相关的工作，都在这一层。

你可能会问，那智能体、工作流、记忆系统这些热门概念放哪儿？答案是：它们不是单独的一层，而是横跨这三层的组合方案。一个智能体，它的规划能力体现在输入层（怎么把任务拆解成模型能处理的输入），它的执行能力体现在输出层（怎么把模型的输出变成实际的工具调用），而它能不能跑得动，取决于模型层的能力够不够。这么一看，是不是清晰多了？

1.3 为什么这个框架值得掌握

我举个实际的例子。之前有个朋友跟我说他想做一个自动写周报的工具，问我该用什么框架。我问他：你的输入是什么？他说就是把这一周的工作记录丢进去。我又问：输出你打算怎么处理？他说直接让模型写出来就行。我说那你根本不需要什么复杂框架，把工作记录整理干净，写一个结构清晰的提示词，直接调模型就够了。

后来他又说想加一个功能：自动从项目管理工具里拉取任务状态。这时候输入层就变了，你需要做数据获取和格式转换。再后来他说想让周报自动发给主管，那输出层就变了，你需要做格式校验和发送动作的编排。你看，每加一个需求，你都能清楚地知道它落在哪一层，需要动什么，不需要动什么。这就是这个框架的实用价值——它帮你做技术决策，帮你判断一个新技术跟你有没有关系。

2. 输入层：决定模型上限的关键战场

2.1 输入层到底包含哪些东西

很多人一提到输入，第一反应就是“提示词”。提示词当然重要，但它只是输入层的一部分。我把输入层拆成四个组成部分，你可以对照看看自己平时有没有漏掉哪块。

第一部分是任务指令。就是你让模型干什么。这部分看起来简单，但实际写起来坑很多。指令是否清晰、是否包含足够的约束条件、是否说明了输出期望，直接决定了模型能不能理解你的意图。

第二部分是上下文信息。包括历史对话、背景资料、领域知识、示例样本。这部分是很多人忽略的重灾区。你给模型的信息够不够、准不准、有没有冗余，直接影响输出质量。

第三部分是数据格式。同样的内容，你用不同的方式组织，模型的理解效果可能差很远。结构化的表格、分段的文本、带标签的字段，各有各的适用场景。

第四部分是任务拆解策略。一个复杂任务，你是直接丢给模型一步到位，还是拆成多个子任务分步处理？这个决策属于输入层的设计范畴，而且往往是决定项目成败的关键。

2.2 提示词工程的核心不是“话术”而是“信息结构”

市面上很多讲提示词的内容，喜欢教你一些所谓的“魔法咒语”，比如“你是一个世界顶级的专家”“请一步一步思考”之类的。这些东西有没有用？有一点用，但作用被严重夸大了。我自己的经验是，提示词的效果，八成取决于你提供的信息结构，两成才取决于你的措辞。

什么叫信息结构？我举个具体的对比。假设你要让模型帮你做一份竞品分析。

一种写法是：“请帮我分析一下这几个竞品的优劣势。”然后附上一堆杂乱的资料。

另一种写法是：“我需要你从以下四个维度分析竞品：功能覆盖度、定价策略、目标用户群、技术架构差异。每个维度请给出对比表格，并标注信息来源。以下是竞品资料，按公司分列，每家公司包含产品文档和用户评价两部分。”

第二种写法为什么效果好？因为它把任务的结构说清楚了——分析维度是什么、输出形式是什么、信息怎么组织。模型不需要猜你的意图，它只需要在你给定的框架里填充内容。这就是信息结构的力量，它把模型从“猜谜”变成了“填空”。

2.3 上下文管理：少即是多

做检索增强的朋友经常遇到一个问题：检索回来的内容太多，塞进模型之后反而效果变差。这个现象背后有一个很朴素的道理——模型的注意力是有限的资源，你塞的东西越多，每个东西分到的注意力就越少。

我自己的做法是，在上下文管理上遵循三个原则。

第一个原则是相关性优先于数量。宁可只给三段高度相关的内容，也不要给十段沾边的内容。检索的时候把相似度阈值调高一点，召回数量调少一点，效果往往反而更好。

第二个原则是结构清晰优先于信息完整。如果检索回来的内容是一大段没有结构的文本，我会先做一步整理，把它拆成带标题的小节，或者提取成关键点列表。这一步多花的时间，在模型输出质量上会加倍还回来。

第三个原则是动态裁剪。不是每次都要把全部上下文塞进去。根据当前任务的需要，只保留相关的部分。比如用户问的是售后政策，那产品介绍那部分上下文就可以暂时不放。

实操心得：我一般会在上下文的最前面放一段“导航信息”，用一两句话说明后面每部分内容是什么。这就像给模型一张地图，让它知道该去哪里找什么。这个技巧在多文档场景下效果特别明显。

2.4 任务拆解的粒度怎么把握

任务拆解是输入层里最考验经验的部分。拆得太粗，模型一步搞不定；拆得太细，步骤之间来回传递信息反而容易出错。那到底怎么把握这个度？

我的判断标准是这样的：如果一步任务里包含两个以上需要“判断”的环节，就应该考虑拆开。举个例子，“读取用户邮件，判断紧急程度，然后决定是否转发给主管”——这里面有两个判断点：判断紧急程度、判断是否转发。这种就适合拆成两步，第一步只做紧急程度分类，第二步根据分类结果决定转发动作。

但也不是越细越好。我曾经把一个文本摘要任务拆成了“提取关键句、合并关键句、润色合并结果”三步，结果发现合并那一步经常丢信息，反而不如让模型一步完成摘要。后来我总结：拆解的目的是降低单步的认知负担，如果拆完之后每一步都太简单，信息在步骤间传递的损耗可能超过拆解带来的收益。

2.5 输入层的常见误区

第一个误区是把模型当搜索引擎用。有些人写提示词就是丢一个关键词进去，期望模型自己理解全部背景。这在简单任务上勉强能用，但稍微复杂一点就会翻车。模型不是读心术，你不说清楚，它就按自己的理解来。

第二个误区是信息过载。跟上面相反，有些人恨不得把所有相关资料都塞进去，觉得信息越多越好。实际上，无关信息会稀释关键信息的权重，让模型抓不住重点。

第三个误区是忽视格式的力量。同样的内容，用Markdown表格呈现和用纯文本段落呈现，模型的提取准确率可能差百分之二三十。这不是玄学，是因为结构化格式本身就携带了语义信息。

3. 模型层：你必须尊重的能力边界

3.1 模型层为什么是“不可变层”

在应用开发的角度看，模型层是你最不能随意改动的一层。你可以选择用哪个模型，但你没法改变一个给定模型的能力上限。这就像你开车，你可以选一辆好车，但你不能让一辆家用轿车跑出赛车的速度。

但这不意味着模型层不重要。恰恰相反，你必须非常清楚你所用的模型，它的能力边界在哪里，然后让你的输入设计和输出处理去适配这个边界。这是整个三层架构里最需要务实精神的地方。

3.2 上下文窗口：不只是“能塞多少字”

上下文窗口是模型层最直观的一个参数。但很多人对它的理解停留在“能塞多少token”这个层面，这就太浅了。

上下文窗口真正重要的是有效注意力范围。什么意思？就是虽然模型号称能处理十万token的输入，但在实际使用中，信息放在不同位置，被模型注意到的概率是不一样的。通常来说，开头和结尾的信息更容易被注意到，中间部分容易被忽略。这个现象在很多模型上都有体现。

所以我在实际项目中，从来不把上下文窗口用满。一般用到百分之六七十就差不多了，而且关键信息一定放在开头或结尾。中间部分放次要的参考材料，即使模型没完全注意到，影响也可控。

3.3 推理能力：什么时候需要“慢思考”

现在很多模型都支持某种形式的推理增强，就是在给出最终答案之前，先输出一段思考过程。这个能力在什么场景下值得用？

我的经验是：需要多步逻辑推理、数学计算、或者需要排除干扰信息的任务，推理增强的收益最明显。比如复杂的条件判断、多约束的规划问题、需要交叉验证的事实核查。

但如果是简单的信息提取、格式转换、文本润色这类任务，推理增强反而可能带来副作用——模型想太多了，把简单问题复杂化，甚至过度解读你的意图。

注意事项：推理增强模式下，模型的输出会包含思考过程，这会消耗额外的token和时间。如果你的应用对响应速度有要求，或者按token计费，需要把这个成本算进去。

3.4 知识边界：模型不知道的事情怎么办

每个模型都有知识截止日期，而且模型的知识覆盖也是有偏向的。有些领域它很熟，有些领域它可能一知半解。这个边界你必须心里有数。

处理知识边界的问题，无非两条路。一条是把外部知识通过输入层喂进去，这就是检索增强的思路。另一条是通过输出层的校验机制，把模型可能出错的地方兜住。

我自己的做法是，对于事实性强的任务，永远不信任模型的“记忆”，而是通过输入层提供权威资料。模型在输入层有据可依的时候，输出质量会稳定很多。而对于创意性、生成性的任务，反而可以放手让模型发挥，不需要给太多约束。

3.5 模型选型：不是越贵越好

模型选型是模型层最实际的决策。我的原则是：用够用的最便宜的模型。

什么叫够用？就是在这个任务上，它的输出质量能达到你的验收标准。很多任务其实不需要最顶级的模型，一个中等规模的模型加上好的输入设计，效果可能比顶级模型配烂提示词还要好。

我一般会做一个小规模的对比测试：拿二十到五十个典型样本，用两三个不同档位的模型跑一遍，人工评估输出质量。如果便宜模型能达到贵模型百分之九十的效果，而成本只有十分之一，那毫无疑问选便宜的。省下来的成本可以投入到输入层的优化上，那个地方的投入产出比往往更高。

4. 输出层：最被低估的价值洼地

4.1 输出层为什么重要

如果说输入层决定了模型能发挥出多少能力，那输出层决定了这些能力能不能变成实际可用的结果。我见过太多项目，输入设计得不错，模型也选得合适，但输出层处理得很粗糙，最后做出来的东西就是差一口气。

输出层要解决的问题包括：模型输出的格式对不对、内容有没有错误、多个步骤的输出怎么衔接、最终结果怎么呈现给用户或者传给下游系统。这些工作看起来琐碎，但它们是产品能不能用的分水岭。

4.2 输出格式约束的几种手段

约束模型输出格式，最常用的手段有三种。

第一种是在提示词里明确说明格式要求。比如“请以JSON格式输出，包含以下字段：title、summary、tags”。这种方式最简单，但可靠性一般，模型有时候会加一些额外的解释文字，破坏格式。

第二种是使用结构化输出功能。现在很多模型API都支持指定输出格式，比如JSON Schema。这种方式可靠性高很多，但需要API支持，而且对复杂嵌套结构的支持程度不一。

第三种是后处理解析。不管模型输出什么，你都在代码层面做一层解析和清洗。比如用正则表达式提取JSON部分，或者用解析器容错处理。这种方式最灵活，但需要写额外的代码。

我自己的组合策略是：提示词里说清楚格式要求，能用结构化输出就用，最后再加一层后处理兜底。三层防护下来，格式问题基本能控制在可接受的范围内。

4.3 输出校验：怎么判断模型有没有胡说

输出校验是输出层最核心也最难的部分。模型输出的内容，你怎么知道它是对的？

对于事实性内容，我的做法是交叉验证。如果模型输出了一个事实陈述，我会让它同时输出信息来源，然后跟输入层提供的资料做比对。如果找不到来源，或者来源跟输出对不上，就标记为待人工确认。

对于逻辑性内容，我会做一致性检查。比如模型输出了一个分析结论，我会检查这个结论跟它前面列出的论据是否一致，有没有自相矛盾的地方。

对于格式性内容，那就用程序化校验。JSON能不能解析、必填字段有没有缺失、数值范围对不对，这些都可以用代码自动检查。

实操心得：我一般会在输出层设置一个“置信度标记”机制。让模型在输出每个关键结论时，附带一个高/中/低的置信度标记。高置信度的直接采用，中置信度的做抽查，低置信度的必须人工审核。这个机制能大幅降低人工审核的工作量。

4.4 多步输出的拼接与传递

当一个任务被拆成多步之后，步骤之间的输出传递就成了一个关键问题。我踩过的坑主要集中在这几个方面。

第一个坑是信息丢失。第一步输出了五个要点，传到第二步的时候可能只剩三个了。解决办法是在传递时做显式的字段映射，确保每个要点都有对应的传递通道。

第二个坑是格式不一致。第一步输出的是列表，第二步期望的是表格，中间就需要做转换。我的做法是在每一步的输出规范里，明确定义输出格式，并且让下一步的输入规范跟它对齐。

第三个坑是错误累积。第一步的一个小错误，传到第三步可能被放大成大问题。解决办法是在每一步都加校验，发现错误及时回退或者修正，不要让错误往下传。

4.5 输出层的后处理技巧

后处理是输出层的最后一道防线。我常用的后处理手段包括：去除模型添加的冗余解释文字、统一术语表达、修正明显的格式问题、补充缺失的标点符号、调整输出长度到合适范围。

这些操作看起来简单，但积累起来对最终体验的影响很大。用户不会关心你的模型多厉害，他们只关心拿到手的结果好不好用。后处理就是让结果变得好用的那一步。

5. 三层架构在实际项目中的拆解演练

5.1 案例一：智能客服问答系统

假设你要做一个智能客服系统，用户提问，系统给出回答。我们用三层架构来拆解。

输入层要做的事情：把用户问题做意图分类，根据意图检索对应的知识库内容，把检索结果和用户问题一起组织成提示词。这里的关键决策是检索策略——用关键词检索还是语义检索，召回多少条，怎么排序。

模型层要做的事情：选择一个在问答任务上表现稳定的模型，确认它的上下文窗口能容纳检索结果加对话历史，确认它的知识截止日期不会影响常见问题的回答。

输出层要做的事情：校验回答是否引用了知识库内容，检查有没有编造信息的迹象，把回答格式化成统一的样式，如果置信度低就转人工。

你看，一个客服系统拆下来，每一层的工作都很清楚。当你想优化这个系统的时候，你也可以定位到具体是哪一层的问题。回答不准确，可能是输入层的检索没做好；回答太慢，可能是模型层选了太大的模型；回答格式乱，那是输出层没处理好。

5.2 案例二：自动化报告生成

再来看一个报告生成的场景。输入是一堆数据和分析要求，输出是一份结构化的报告。

输入层：把原始数据整理成模型能理解的格式，把报告的结构要求写清楚，把分析框架和关键指标定义好。如果数据量很大，还需要做分块处理，决定哪些数据放在哪个部分。

模型层：报告生成通常需要较强的语言组织能力，所以要选一个生成质量好的模型。同时要注意，如果报告很长，可能需要分段生成再拼接，这就涉及到模型层和输出层的配合。

输出层：把分段生成的报告拼接起来，检查各部分之间的衔接是否流畅，校验数据引用是否准确，统一格式和术语，最后输出成目标格式。

这个案例里特别值得注意的是分段生成的拼接问题。我的经验是，在分段生成时，每一段都要带上前后文的摘要信息，这样拼接起来才不会断裂。这个摘要信息属于输入层的设计，但它是为了输出层的拼接服务的。三层之间不是孤立的，而是相互配合的。

5.3 案例三：多轮对话助手

多轮对话的复杂度比单轮问答高一个量级，因为多了历史对话的管理。

输入层：决定保留多少轮历史对话，怎么压缩历史信息，怎么处理话题切换。我的做法是保留最近三到五轮的完整对话，更早的对话做摘要压缩。话题切换时，把旧话题的摘要放在上下文里，但降低它的权重。

模型层：多轮对话对模型的指令遵循能力要求比较高，因为它需要同时处理当前问题和历史上下文。选模型的时候要特别测试它在多轮场景下的表现。

输出层：检查回答是否跟历史对话矛盾，是否重复了之前已经说过的内容，是否需要主动追问澄清。多轮对话里，输出层的一个重要作用是维护对话状态，确保每一轮的回答都在正确的轨道上。

5.4 三层架构的通用拆解模板

把上面的案例抽象一下，我总结了一个通用的拆解模板，你在遇到任何AI新方案的时候都可以套用。

拿到一个新方案，你就问三个问题：它在输入层做了什么？它对模型层有什么要求？它在输出层怎么处理？三个问题回答完，这个方案的本质你就抓住了。

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

6.1 输出质量不稳定的排查思路

输出质量忽好忽坏，是最常见的问题。我的排查顺序是这样的。

先查输入层。把出问题的case和正常的case拿出来对比，看输入有什么差异。常见的原因包括：输入信息缺失、格式不一致、上下文太长导致关键信息被淹没。

再查模型层。确认模型版本有没有变化，API有没有更新，参数设置有没有被改动。有时候模型服务端的更新会导致输出风格变化，这个你控制不了，但你要能快速定位到。

最后查输出层。看后处理逻辑有没有bug，校验规则是不是太严或者太松，拼接逻辑有没有问题。

排查技巧：我一般会维护一个“回归测试集”，包含二十到三十个典型case。每次改动之后跑一遍，看输出质量有没有退化。这个习惯帮我省了很多事后救火的时间。

6.2 模型“不听话”怎么办

模型不按你的要求输出，通常有三个原因。

第一个原因是指令不够明确。你以为你说清楚了，但模型的理解跟你的预期有偏差。解决办法是把指令写得更具体，最好给出示例。

第二个原因是指令之间有冲突。比如你既要求“简洁”又要求“详细”，模型就无所适从。检查一下你的提示词里有没有自相矛盾的要求。

第三个原因是模型能力不够。有些复杂指令，小模型确实理解不了。这时候要么换模型，要么把任务拆简单一点。

6.3 成本控制的实操方法

成本控制要从三层同时入手。

输入层：精简上下文，去掉不必要的信息，用更短的提示词达到同样的效果。检索的时候控制召回数量，不要动不动就召回几十条。

模型层：选够用的模型，不要盲目追求顶级。简单任务用便宜模型，复杂任务才用贵模型。批量任务可以异步处理，利用非高峰时段的优惠。

输出层：控制输出长度，不需要长篇大论的地方就限制字数。后处理尽量用规则而不用模型，规则的成本几乎为零。

6.4 常见问题速查表

6.5 我踩过的几个典型坑

第一个坑是过度依赖模型的自解释。早期我做输出校验的时候，喜欢让模型自己解释为什么给出这个答案。后来发现，模型的解释往往是事后编的，跟它实际的推理过程不一定一致。所以现在我只把模型的自解释当作参考，不作为校验依据。

第二个坑是忽视输入的顺序。同样的内容，换个顺序放，输出质量可能差很多。关键信息放前面还是放后面，示例放在指令之前还是之后，这些细节都需要实际测试。

第三个坑是一次性改太多变量。优化的时候同时改了提示词、换了模型、调了参数，结果输出变好了，但你不知道是哪个改动起的作用。每次只改一个变量，这是做优化的铁律。

第四个坑是不做回归测试。改完觉得效果好就上线了，结果之前能正常处理的case反而挂了。维护一个测试集，每次改动都跑一遍，这个习惯能帮你避免很多尴尬。

7. 三层架构视角下的新方案速判法

7.1 遇到新概念时的三问法

现在你再看一个新出的AI方案，可以按这三个问题快速判断它跟你有没有关系。

第一问：它在输入层做了什么？是新的提示词技巧，还是新的检索方式，还是新的上下文管理策略？如果是，那它影响的是你喂给模型的信息质量和结构。

第二问：它对模型层有什么要求？是需要特定能力的模型，还是对上下文窗口有要求，还是需要微调？如果是，那你要评估自己用的模型能不能满足。

第三问：它在输出层怎么处理？是新的格式约束方式，还是新的校验机制，还是新的结果拼接方法？如果是，那它影响的是你拿到输出之后的工作流程。

三个问题回答完，这个方案的价值和适用性你就心里有数了。

7.2 哪些新花样其实只是输入层的包装

市面上很多所谓的“新框架”，拆开看其实就是输入层的提示词模板加上一些流程控制。它们把常见的任务拆解模式固化成了代码，让你不用每次重新设计。这类方案的价值在于省事，但如果你理解了输入层的原理，完全可以自己搭一个更适合自己业务的版本。

判断方法很简单：如果这个方案的核心是“怎么组织输入”，那它就是输入层的东西。它不改变模型的能力，只是让模型更容易发挥。

7.3 哪些创新真正发生在模型层

真正发生在模型层的创新，是那些改变了模型本身能力边界的东西。比如新的训练方法让模型推理能力更强，新的架构让上下文窗口更大，新的对齐技术让模型更听话。这些创新是底层的，它们会同时影响输入层和输出层的设计空间。

作为应用开发者，你不需要自己去做模型层的创新，但你需要关注模型层的进展，因为它会改变你的输入输出设计的最优解。比如上下文窗口变大了，你的检索策略可能就要调整；推理能力变强了，你的任务拆解粒度可能就可以放粗。

7.4 输出层的创新最容易被忽视但最实用

输出层的创新往往不那么引人注目，但实际价值很高。比如更好的结构化输出解析、更智能的置信度评估、更流畅的多步拼接。这些东西不改变模型能力，但能让模型能力更好地落地。

我自己的体会是，在输出层投入的每一分精力，回报都是直接的。因为输出层直接面向用户或者下游系统，这里的改进用户能直接感知到。

8. 我个人的一些实操体会

8.1 先把输入层吃透再动别的

如果你刚开始做AI应用，我的建议是先把输入层吃透。提示词怎么写、上下文怎么管、任务怎么拆，这些基本功练好了，你会发现很多问题根本不需要复杂框架就能解决。我见过太多人一上来就搞多智能体、搞复杂工作流，结果基础提示词都没写明白，最后项目一团糟。

8.2 模型层要务实，不要追新

模型层的选择要务实。新模型出来了，先看它解决什么问题，再看你的场景需不需要。不要因为一个新模型分数高就盲目切换，切换模型是有成本的——你的提示词可能要重调，输出格式可能要重新适配，这些隐性成本往往被低估。

8.3 输出层值得你花最多时间

如果让我在三层里选一个最值得投入的，我会选输出层。因为输入层的优化有上限，模型层的选择空间有限，而输出层的优化空间几乎是无限的。而且输出层的改进直接提升用户体验，是最容易被感知到的价值。

8.4 三层要联动看，不要孤立优化

最后一点，三层是一个整体。输入层的改动可能影响输出层的处理逻辑，模型层的切换可能需要输入层重新适配。做优化的时候要有全局视角，不要只盯着一个地方改。我一般会画一个简单的三层图，把每个改动标注在对应的层上，这样能清楚地看到改动的影响范围。

这个三层架构的框架，我用了快两年了，从最开始做简单问答，到后来做复杂的多步骤任务编排，它一直能帮我快速定位问题、做技术决策。希望它对你也有用。如果你在实际项目中遇到了什么三层框架解释不了的情况，那可能是一个值得深入研究的点，欢迎一起探讨。