企业官网建设流程全解析

1. 为什么“三层架构”是理解大模型应用的万能钥匙

很多人第一次接触大模型应用开发时，会被各种新名词砸晕：RAG、Agent、Function Calling、思维链、提示词工程、微调、向量数据库……每一个词背后都有一整套教程和工具链，学完一圈下来，脑子里的感觉就是“东西太多了，根本记不住”。

但如果你把市面上所有大模型应用案例摊开来看，会发现一个反直觉的事实：它们本质上都在做同一件事——控制输入什么，以及处理输出怎么用。中间那个“模型本身”，反而是最不需要你操心的部分。你不需要训练它，不需要理解注意力机制的每一个矩阵乘法，你只需要知道它是一个“输入文本、输出文本”的黑盒。

这就是我所说的“三层架构”：

• 第一层：输入层——你往模型里塞什么。包括系统提示词、用户问题、检索到的文档片段、历史对话、工具描述、少样本示例等。
• 第二层：模型层——模型本身的能力边界。包括上下文窗口大小、推理能力、指令遵循能力、知识截止日期、多模态支持等。
• 第三层：输出层——你怎么处理模型吐出来的东西。包括解析结构化输出、调用外部工具、校验事实性、格式化展示、多轮迭代等。

这三层里，模型层是“给定条件”，你改不了（除非微调，但那是另一回事）。真正决定一个应用好不好用的，是输入层和输出层的设计。换句话说，所有AI新花样，本质上都是在“输入什么”和“输出怎么处理”上做文章。

我举个例子你就明白了。假设你要做一个“合同审查助手”。输入层要做的事是：把合同文本切块、检索相关法条、拼接成提示词、告诉模型“你是一个资深法务”。输出层要做的事是：让模型按JSON格式输出风险点、对每个风险点标注严重程度、如果模型说“不确定”就触发人工复核。模型层呢？你选一个上下文窗口够大、中文理解够好的模型就行。整个系统的复杂度，90%在输入和输出两端。

这篇文章就是要把这三层拆开揉碎，告诉你每一层里有哪些关键决策点、常见的坑在哪里、以及怎么用最小的成本做出最稳的效果。不管你是刚入门的新手，还是已经做过几个Demo的老手，这套框架都能帮你把脑子里零散的知识点串成一条线。

2. 输入层：决定模型上限的隐形战场

2.1 系统提示词不是“写作文”，而是“定规矩”

很多人写系统提示词的习惯是：写一大段话，把能想到的要求全塞进去，觉得写得越多模型越听话。实测下来，这种做法往往适得其反。模型在长提示词里会“迷失”，前面说的规则到后面就忘了，或者被后面的指令覆盖掉。

我自己的经验是：系统提示词要像写API文档一样写，而不是像写散文一样写。什么意思？API文档的特点是：结构清晰、每条规则独立、有明确的输入输出定义、边界条件写清楚。系统提示词也应该这样。

一个可复用的系统提示词模板长这样：

# 角色 你是一个[具体角色]，负责[具体任务]。 # 能力边界 - 你可以做：[列出允许的操作] - 你不能做：[列出禁止的操作] - 遇到不确定的情况：[定义兜底行为] # 输出格式 [明确定义输出的结构，最好给一个示例] # 约束条件 - [约束1] - [约束2]

这个模板的好处是：模型在处理时，会把每个部分当成独立的指令块来对待，不会互相干扰。而且当你需要调整时，你知道改哪个部分，不用重写整个提示词。

还有一个细节：把最重要的规则放在最前面和最后面。这是基于模型注意力分布的经验——中间部分的内容容易被“稀释”。如果你有一条绝对不能违反的规则（比如“不得编造法条编号”），把它放在系统提示词的第一句和最后一句各说一遍。

2.2 上下文窗口的“黄金分割点”

上下文窗口大小是模型层的硬指标，但怎么用满这个窗口，是输入层的艺术。我见过太多人把整个知识库往提示词里塞，结果模型反而变笨了。原因很简单：信息过载会导致注意力分散。

我的做法是：把上下文窗口分成几个功能区，每个区有明确的预算。

这个分配不是绝对的，但核心原则是：检索知识区不能超过一半。超过一半，模型就会变成“复读机”，只会从文档里抄，不会推理。我试过把检索区压到30%，把省下来的空间给少样本示例，结果模型输出的结构化程度明显提升。

还有一个实操技巧：在检索知识区的每个片段前加一个“来源标签”。比如：

[来源：产品手册v2.3，第4章] 退货政策：自签收之日起7天内可无理由退货... [来源：客服培训材料，2024版] 退货流程：用户需先在小程序提交申请...

这个标签的作用是让模型知道“这段话是从哪来的”，当它需要引用时，可以准确标注来源。没有这个标签，模型会把所有检索内容当成“自己知道的知识”，输出时就不带出处了。

2.3 少样本示例：质量比数量重要十倍

少样本示例（Few-shot Examples）是输入层里性价比最高的工具。但很多人用错了方向：他们放10个示例，每个示例都是随便写的。结果模型学到的不是“任务模式”，而是“示例里的噪声”。

我的原则是：2-3个精挑细选的示例，胜过10个凑数的。每个示例要满足三个条件：

1. 覆盖一个典型场景：不要选边缘案例，选最常见的输入类型。
2. 展示完整的输入输出对：包括输入文本和期望的输出格式。
3. 包含一个“困难案例”：比如输入有歧义时，模型应该怎么处理。

举个例子，如果你在做“情感分类”任务，示例可以这样设计：

示例1（典型正面）： 输入：这个产品用起来很顺手，续航也够用。 输出：{"sentiment": "positive", "confidence": 0.9, "reason": "明确表达满意"} 示例2（典型负面）： 输入：收到货就坏了，客服还不理人。 输出：{"sentiment": "negative", "confidence": 0.95, "reason": "质量问题+服务问题"} 示例3（困难案例-混合情感）： 输入：东西不错，但物流太慢了。 输出：{"sentiment": "mixed", "confidence": 0.7, "reason": "产品正面，物流负面"}

注意第三个示例：它教模型在遇到混合情感时，不要强行二选一，而是输出“mixed”。这个规则如果你只用文字描述，模型可能记不住；但用一个示例展示，模型就能学会。

还有一个坑：示例的顺序会影响结果。模型有“近因效应”，最后一个示例对输出的影响最大。所以如果你希望模型偏向某种输出风格，把最符合你期望的示例放在最后。

2.4 检索增强生成（RAG）的输入层陷阱

RAG是现在最火的应用模式，但很多人只关注“怎么检索”，忽略了“检索到的东西怎么放进提示词”。这里有两个常见的坑：

坑一：检索片段直接拼接，没有去重和排序。如果检索返回5个片段，其中3个讲的是同一件事，模型会收到重复信息，导致输出冗余。我的做法是：先对检索结果做一次聚类，把相似度高于0.9的片段合并，然后按与问题的相关度排序，只取前3-4个。

坑二：检索片段没有“边界标记”。如果直接把片段拼在一起，模型分不清哪里是文档A的结尾、哪里是文档B的开头。我习惯用XML标签包裹每个片段：

<document id="1" source="产品手册"> 退货政策：自签收之日起7天内可无理由退货... </document> <document id="2" source="客服培训"> 退货流程：用户需先在小程序提交申请... </document>

XML标签的好处是模型对结构化标记很敏感，能准确识别每个片段的边界。而且当模型需要引用时，可以直接说“根据文档1”，方便你后续做溯源。

3. 模型层：选型不是选“最强”，而是选“最合适”

3.1 上下文窗口、推理能力、成本的不可能三角

选模型时，所有人都会面临一个三角困境：上下文窗口大、推理能力强、成本低，这三者不可能同时满足。你必须根据场景做取舍。

我整理了一个决策表，帮你快速定位：

这个表的关键洞察是：没有“最好”的模型，只有“最适合当前任务”的模型。我见过一个团队用最贵的推理模型做简单的文本分类，成本翻了20倍，效果只提升了2%。这就是典型的选型错配。

还有一个实操建议：不要只用一个模型。很多生产系统会做“模型路由”：简单任务走轻量模型，复杂任务走推理模型。比如用户问“今天天气怎么样”，没必要调用推理模型；用户问“帮我分析这份财报的潜在风险”，才需要上重武器。路由逻辑可以基于问题长度、关键词、或者一个轻量分类器来判断。

3.2 温度参数：不是“创意开关”，而是“分布调节器”

温度（Temperature）是模型层最被误解的参数。很多人把它当成“创意开关”：温度高=有创意，温度低=保守。这个理解只对了一半。

从原理上说，温度调节的是模型输出概率分布的“平滑程度”。温度趋近0时，模型总是选概率最高的那个词，输出最确定；温度升高时，低概率词也有机会被选中，输出更多样。

但这里有个关键细节：温度不是线性影响创造力的。在0到0.5之间，温度主要影响“确定性”；在0.5到1.0之间，才开始影响“多样性”；超过1.0，输出会变得混乱甚至语法错误。

我的经验值是：

• 事实性任务（问答、摘要、翻译）：温度0-0.3
• 结构化输出（JSON、表格）：温度0-0.2
• 创意写作（文案、故事）：温度0.7-0.9
• 头脑风暴（生成多个方案）：温度0.9-1.0

还有一个坑：温度和其他参数会互相影响。比如Top-p（核采样）和温度一起用时，效果不是简单叠加。如果你设了温度0.8，又把Top-p设成0.5，实际多样性会比你预期的低。我的建议是：只调一个参数，另一个保持默认。通常调温度就够了。

3.3 模型的知识截止日期：一个容易被忽略的“隐形边界”

每个模型都有知识截止日期，意思是它训练数据只到某个时间点。这个日期之后发生的事情，模型不知道。但问题是：模型不会主动告诉你“我不知道”。它会用已有的知识去“编”一个看起来合理的答案。

这个坑在时效性强的场景里特别致命。比如你问“最新的XX政策是什么”，模型可能会把两年前的旧政策改个日期就给你。如果你不核实，直接用了，后果可能很严重。

我的应对策略是：在系统提示词里明确写“如果问题涉及[具体时间范围]之后的事件，请回答‘我需要最新信息，建议查询权威来源’”。同时，在输出层加一个校验步骤：如果模型输出里包含具体日期、数字、政策名称，触发人工复核或二次检索。

还有一个技巧：把“知识截止日期”写进系统提示词。比如：“你的知识截止到2024年6月。如果用户询问此日期之后的事件，请明确告知你可能没有最新信息。” 这样模型在遇到边界情况时，会主动“举手”，而不是硬编。

4. 输出层：从“能说会道”到“能干活”的关键一跃

4.1 结构化输出：让模型说“机器能懂的话”

模型默认输出的是自然语言，但下游系统需要的是结构化数据。把自然语言转成JSON、XML、表格，是输出层最基础也最重要的任务。

很多人用“请输出JSON格式”这种指令，然后祈祷模型听话。实测下来，成功率大概70%。剩下30%的情况，模型会加一句“好的，以下是JSON：”，或者在JSON外面包一层解释文字。

我的做法是：用“模式约束”代替“格式请求”。具体来说，在系统提示词里定义一个严格的输出模式，并给出一个“反例”：

# 输出格式 你必须输出一个合法的JSON对象，不要包含任何其他文字。 JSON结构如下： { "answer": "string", "confidence": 0.0-1.0, "sources": ["string"] } # 错误示例（不要这样输出） 好的，以下是JSON： { "answer": "..." }

这个“错误示例”很关键。模型看到“不要这样输出”之后，会主动避免在JSON前后加解释文字。我实测下来，加了错误示例后，结构化输出的成功率从70%提升到了95%以上。

还有一个进阶技巧：用“输出解析器”做二次校验。即使模型输出了JSON，也可能有语法错误（比如多了个逗号）。在代码里加一个try-catch，解析失败时自动重试或降级处理。这个成本很低，但能避免很多线上事故。

4.2 工具调用：让模型从“说”到“做”

工具调用（Function Calling）是输出层最强大的能力。模型不再只是生成文本，而是可以触发外部操作：查数据库、发邮件、调API、控制设备。

但工具调用的坑也最多。我见过最常见的错误是：工具描述写得太模糊。比如一个“查询天气”的工具，描述只写“查询天气”。模型不知道这个工具需要什么参数、返回什么格式、适用于什么场景。

正确的工具描述应该包含：

{ "name": "get_weather", "description": "查询指定城市的当前天气。适用于用户询问天气、温度、降水等场景。不适用于查询历史天气或未来预报。", "parameters": { "city": { "type": "string", "description": "城市名称，必须是中文，如'北京'、'上海'" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "温度单位，默认celsius" } } }

注意description里的“适用于”和“不适用于”——这能帮模型判断什么时候该调用、什么时候不该调用。没有这个边界，模型可能会在用户问“明天天气”时也调用这个工具，然后返回错误结果。

还有一个关键点：工具调用的结果要“翻译”回自然语言。模型调用工具后，拿到的是JSON数据，但用户需要的是自然语言回答。这个“翻译”步骤不能省。我通常会在工具返回后，再给模型一个提示：“根据工具返回的数据，用自然语言回答用户的问题，不要直接输出JSON。”

4.3 输出校验：三道防线挡住“胡说八道”

模型会“幻觉”——编造不存在的事实、引用不存在的来源、给出错误的计算。输出层的核心任务之一，就是建立校验机制。

我的做法是三道防线：

第一道：格式校验。检查输出是否符合预期的结构（JSON是否合法、必填字段是否存在、数值是否在合理范围）。这道防线用代码就能实现，成本最低。

第二道：事实校验。如果输出包含具体事实（日期、数字、名称），用检索或规则库做交叉验证。比如模型说“根据XX法第XX条”，就去法条库里查一下这条是否存在。这道防线需要一些领域知识，但能挡住大部分严重错误。

第三道：一致性校验。让模型自己检查一遍输出。具体做法是：把原始问题和模型输出一起再喂给模型，问“这个回答是否准确？有没有遗漏或错误？” 这道防线成本最高，但能发现一些微妙的逻辑问题。

三道防线的顺序是：先格式、再事实、最后一致性。因为格式错误最容易发现，也最容易修复；事实错误需要外部知识；一致性检查最耗时，放在最后。

4.4 多轮迭代：让模型“再想想”

有时候模型第一次输出不够好，但直接重新生成又浪费。这时候可以用“迭代优化”的策略：把第一次输出作为输入，让模型改进。

具体做法是：

你之前的回答是： [第一次输出] 请检查这个回答，并做以下改进： 1. 如果缺少具体数据，补充数据 2. 如果逻辑不清晰，重新组织 3. 如果语气不合适，调整语气 输出改进后的版本。

这个技巧在写作、分析、规划类任务里特别有效。我试过让模型写产品文案，第一版平平无奇，迭代两次后质量明显提升。关键是：迭代次数不要超过3次。超过3次，模型会开始“过度优化”，把原本正确的内容改错。

还有一个变体：多视角生成。让模型从不同角色出发，生成多个版本，然后选最好的。比如“分别以技术专家、普通用户、竞争对手的视角评价这个方案”。这个方法能帮你发现盲点，但成本较高，适合重要决策场景。

5. 三层架构的实战组合：一个完整案例的拆解

5.1 场景定义：从“需求”到“三层映射”

假设我们要做一个“技术文档问答助手”。用户可以用自然语言提问，系统从一堆技术文档里找到答案，并给出出处。

这个需求拆到三层里是这样的：

• 输入层：用户问题 + 检索到的文档片段 + 系统提示词（定义角色和输出格式）
• 模型层：选一个上下文窗口够大（至少32K）、中文理解好的通用模型
• 输出层：解析JSON输出、提取答案和出处、如果置信度低则提示“建议查阅原文”

这个拆解看起来简单，但每一步都有细节。下面我按三层分别展开。

5.2 输入层的具体设计

系统提示词这样写：

# 角色 你是一个技术文档问答助手。你的任务是根据提供的文档片段，回答用户的技术问题。 # 规则 1. 只使用提供的文档片段中的信息回答，不要使用你自己的知识。 2. 如果文档片段中没有相关信息，回答“根据现有文档，我无法回答这个问题”。 3. 每个回答必须标注来源，格式为[文档ID]。 # 输出格式 { "answer": "string", "sources": ["文档ID"], "confidence": 0.0-1.0 }

检索策略：用向量检索找Top-5相关片段，然后用一个轻量模型做重排序，取Top-3。每个片段前加[文档ID]标签。

少样本示例：放2个示例，一个正常回答，一个“无法回答”的情况。

5.3 模型层的参数配置

• 温度：0.1（事实性任务，要确定性）
• Top-p：默认（不调）
• 最大输出长度：500 tokens（答案不会太长）
• 停止序列：}（JSON结束符，防止模型继续生成）

5.4 输出层的处理链路

1. 解析JSON，如果失败，重试一次；再失败，返回“系统繁忙”。
2. 检查confidence字段，如果低于0.6，在答案前加“根据现有文档，信息可能不完整：”。
3. 提取sources字段，在答案末尾附上“参考文档：[ID列表]”。
4. 如果answer包含“无法回答”，记录日志，用于后续优化检索策略。

这个链路跑下来，整个系统的准确率和用户体验都比“直接问模型”好很多。关键是把每一层的职责分清楚了：输入层负责“给对信息”，模型层负责“理解信息”，输出层负责“用好信息”。

6. 那些年我踩过的三层架构坑

6.1 输入层的坑：提示词越长越好？

刚入门时，我总觉得提示词写得越详细越好。有一次做一个“会议纪要生成”的任务，我写了800字的系统提示词，把能想到的规则全塞进去了。结果模型输出反而变差了——它开始“过度解读”某些规则，把不重要的细节放大。

后来我学乖了：提示词的长度和效果不是正相关的。关键规则要精炼，示例要典型，其他细节让模型自己发挥。现在我的系统提示词通常控制在300字以内，效果反而更稳。

6.2 模型层的坑：盲目追求“最强模型”

有一段时间，我不管什么任务都用最贵的推理模型。结果发现：对于简单的文本分类任务，推理模型和轻量模型的准确率只差1%，但成本差了15倍。而且推理模型因为“想得太多”，有时候会把简单问题复杂化。

现在的做法是：先用轻量模型跑一遍，如果效果不达标，再升级模型。大部分任务其实不需要顶级模型。

6.3 输出层的坑：忽略“失败路径”

最开始做输出解析时，我只考虑了“成功解析”的情况。结果上线后，模型偶尔输出格式错误，整个系统就崩了。后来我加了完整的失败处理：解析失败→重试→降级→记录日志。这个“失败路径”的设计，比“成功路径”更重要。

还有一个坑：没有给模型“说不”的机会。如果检索不到相关信息，模型应该能说“我不知道”，而不是硬编一个答案。我在系统提示词里明确写了“如果文档中没有相关信息，回答‘无法回答’”，这个简单的规则避免了很多幻觉问题。

7. 三层架构的扩展思考：新花样到底新在哪

回到标题那句话：“所有AI新花样，只在输入什么/输出怎么处理”。现在你可以验证一下：

• RAG：新在输入层——把检索结果放进提示词。
• Agent：新在输出层——把模型的输出解析成工具调用。
• 思维链：新在输入层——在提示词里加“让我们一步步思考”。
• Function Calling：新在输出层——结构化输出+工具调用。
• 多模态：新在输入层（图片/音频输入）和输出层（图片/音频输出）。
• 微调：新在模型层——但本质还是调整“输入-输出”的映射关系。

所以当你看到一个新概念时，先问自己：它改的是输入层、模型层、还是输出层？大部分情况下，答案是输入层或输出层。模型层的变化（比如新的架构、更大的参数量）是少数。

这个框架的价值在于：它帮你把“学不完的新知识”变成了“三个固定位置的排列组合”。你不需要追每一个新名词，只需要关注：输入层有什么新工具（比如新的检索方法、新的提示词技巧），输出层有什么新玩法（比如新的解析方式、新的工具集成）。模型层？等它真的变了再说。

我在实际项目里的体会是：把三层拆清楚之后，排查问题变得容易多了。效果不好时，先看输入层——检索对不对？提示词有没有歧义？再看输出层——解析有没有问题？校验够不够？最后才考虑换模型。大部分问题其实出在输入和输出两端，模型本身很少是瓶颈。

最后分享一个小技巧：每次调整只改一层的一个变量。比如这次只改检索策略，下次只改输出格式。如果同时改多个地方，你根本不知道是哪个改动起了作用。这个原则听起来简单，但能帮你省下大量“瞎调”的时间。