市面上的 AI 产品每天都有新花样，今天这个能读图，明天那个能写代码，后天又来一个能自己上网查资料回你话。如果你只站在用户视角看，会觉得大模型简直在坐火箭。但如果你亲手搭过几个应用，把模型从 API 里接出来、连上自己的业务系统，会慢慢发现一个不太被人提起的真相：底层那个模型，其实一直没怎么大动，翻来覆去变的一直是“输入什么”和“输出怎么处理”这两件事。

我这几年做过不少 AI 相关的项目，从最早的玩具级聊天机器人，到后来真正跑在业务里的文档理解、报表分析工具，折腾下来最大的收获不是学会了某个框架，而是脑子里形成了一张特别朴素的地图——大模型应用的三层架构。这张地图帮我省了无数冤枉钱，也让我在遇到效果不好的时候，知道该往哪儿调，而不是瞎换模型。

这篇文章不聊论文，也不贴复杂的数学公式，就从一个干过活的从业者角度，把这三层架构彻底拆开，讲讲每一层到底在解决什么问题，以及为什么所有你看到的 AI 新花样，本质上都只是在这三层里的“输入”和“输出”两端做文章。

1. 三层架构的本质：模型是死的，流程是活的

1.1 先给大模型应用画一张地图

所谓三层架构，我的理解是这样的。

最底下是基座模型层，就是那个在数据中心里跑着的、训练好的大模型本身。它决定了智能的上限，比如知识储备够不够、推理能力行不行、能不能写复杂代码。但这一层在你做应用的时候，通常是动不了的，你只能通过 API 去调用它，或者最多在它之上做点微调。

再往上是输入处理层。模型不接收你的原始问题，它只接收 token 序列。所以用户说的话、你的业务数据、你要让它参考的文档，都得在这一层被翻译、整理、拼装成一段它能看懂、也愿意好好回答的文字。这层干得好不好，直接决定模型能不能理解你的真实意图。

最上面是输出处理层。模型吐出来的是一段文字，但你的业务系统需要的可能是一个 JSON 对象、一段可执行的 SQL、一个按钮的操作指令。这层要负责把模型的“自由发挥”变成“稳定交付”，拦住格式错误、内容幻觉、答非所问这些乱七八糟的问题。

这三层的关系，我用一个日常例子来类比。你去餐厅吃饭，厨师相当于基座模型，他的手艺决定了菜的上限。但你点菜的时候怎么描述口味偏好——是“少放辣”还是“多放蒜”，这就是输入处理。菜端上来之后，服务员要帮你确认是不是你点的这道菜，要不要换盘子、加热、加汤，这就是输出处理。同样一个厨师，你描述得越清楚，上菜的流程越严谨，最后吃到的体验就差得远。

1.2 为什么说模型本体其实没那么爱“变”

我在项目里最常遇到的一个情况就是：效果不行，第一反应是“是不是模型太弱了，得换一个更大的”。但很多次排查完发现，问题根本不在模型这一层。

举一个给我印象很深的例子。当时做某跨平台系统，需要从一堆 PDF 合同里提取关键字段，比如合同编号、甲方名称、签约日期。最初用通用大模型直接问，返回的结果时好时坏，有时候字段名都对不上，有时候日期格式一会儿是“2023年5月1日”，一会儿是“2023-05-01”。当时第一反应确实是换更强的模型，但试了一圈发现，更强的模型也有类似问题，只是概率稍微低一点。

后来沉下心来调输入，把 PDF 里的 OCR 文本做清洗，把字段定义写进提示词，给几个标准示例，再把输出格式要求得非常具体。结果同样的模型，准确率肉眼可见地涨了一大截。再往后，在输出端加了 JSON Schema 校验和二次修正逻辑，才算真正稳定下来。

这个经历给我一个特别深的烙印：基座模型的能力当然重要，但在实际工程里，它更像是硬件条件，而输入输出这两层才是你能真正发挥主观能动性的软件系统。市面上那些让人眼前一亮的新花样，绝大多数不是靠换了一个多么惊天动地的模型，而是靠把输入输出玩出了花。

2. “输入什么”：决定 AI 能力上限的关键战场

2.1 输入处理的核心：把意图翻译成模型最擅长的话

模型听不懂“帮我弄一下那个合同呗”，它需要的是清晰、结构化、有上下文的任务描述。输入处理层干的事，本质上就是翻译。

我常用的做法是把输入拆成几个固定的模块来拼装：

• 角色设定：告诉模型它是谁。比如“你是资深合同审核专家”，这比直接说“帮我看看合同”效果好得多，因为角色会激活模型在训练时见过的对应领域语料。
• 任务指令：明确说要做什么。要说“提取以下字段并输出 JSON”，而不是“分析合同”。
• 背景信息：必要的外部上下文，比如合同类型、业务场景、特殊要求。没有背景，模型就只能瞎猜。
• 示例：一两组输入输出的样例，告诉模型你期望的“标准答案”长什么样。这一招对稳定格式特别管用。

这套拼装逻辑看起来简单，但真正做起来有很多细节。比如指令别贪多，一次给模型塞十个要求，它往往每个都做不好；示例要挑典型的，别用边缘情况当示例，否则模型会被带偏。

另外还有一个很容易踩的坑：上下文污染。刚做某图像处理 Demo 的时候，我随手把一段与问题无关的技术博客全文塞进提示词里，结果模型生成的答案老往那个博客的话题上偏。后来想明白了，模型对输入里的信息没有“重要性过滤”机制，你塞了 100 行背景，它就默认这 100 行都重要。输入处理的一个重要原则是：删掉一切不必要的 token，只留下与任务强相关的信息。

2.2 把更大世界“塞进输入”：RAG 与长上下文技术

模型的知识有截止日期，你问它最近一周发生的行业动态，它大概率答不上来。解决这个问题，业界最主流的方式不是重新训练模型，而是检索增强生成（RAG），本质上就是：在把问题交给模型之前，先从你自己的知识库里检索出相关文档片段，拼到输入里，让模型“带着资料”回答问题。

做 RAG 也不是想象中那么简单，我把自己的实践过程拆给你看。

第一步是索引构建：把文档切块、做向量化、存进向量数据库。切块大小是个需要反复试的参数，切得太小语义不完整，切得太大则检索精度下降。我当时做某跨平台系统的时候，试过 256、512、1024 几个档位，发现 512 左右对于技术文档和制度文件是比较好用的起点，再根据实际检索结果微调。

第二步是检索召回：用用户的查询去向量数据库里找最相似的片段。这里有个反直觉的细节，很多人以为召回 5 个片段就够了，但实际做下来，如果你的知识库很大、问题又复杂，至少建议试到 10 到 15 个，然后用重排模型（reranker）把相关性最高的几个挑出来。不重排和重排的差距，在实际问答体验上非常明显。

第三步是拼接上下文：把召回出来的片段按相关度排序，塞进输入里。这里要特别提醒一句，文档片段之间可能有互相矛盾的内容。我遇到过知识库里两篇文档对同一个流程的说法不一样，模型就不知道该怎么办了。后来加入了一个小技巧：在拼接的时候告诉模型“以下资料可能存在冲突，请优先采用与问题最直接相关的内容”，情况才好转。

说句实在话，长上下文模型出来之后，很多人觉得 RAG 要死了——反正模型能记住几十万字，直接把整个知识库塞进去不就行了吗？但实际跑过你会发现，塞得越多，模型注意力越分散，回答的准确率和稳定性反而下滑。在可预见的未来，RAG 这种“要什么给什么”的输入构建方式，都比“全都塞给你”更实用。

2.3 多模态输入：把图片语音翻译成模型认识的 token

这两年大模型支持多模态，你可以直接发一张截图给它，问它图里写了什么。表面上看是模型变强了，从“纯文本模型”变成了“多模态模型”，但从三层架构的视角看，它在产品层的本质是输入处理层的变化：图片先被编码器处理，转成模型能理解的 token 序列，然后再拼到原本的输入流里，模型本体照样做它最擅长的“读 token、预测下一个 token”这件事。

这个视角对工程实现有实际指导意义。我做过一个票据识别的小项目，一开始直接把整张发票图片丢给模型，让它输出金额、日期、发票号。结果发现，背景复杂、印章遮挡严重的大图识别效果很差，模型容易把印章上的文字也识别出来当成正文。

后来调整了输入处理方式：先用传统的图像处理把票据区域裁切出来、做旋转矫正、增强对比度，再将处理后的图片交给大模型。同样的模型，准确率一下子提升了不少。这说明多模态输入也要讲究预处理，不是把原图扔过去就完事。

另外还有一个值得记住的经验：多模态输入尽量配合文字指令使用。你发一张图、打一句“总结图中关键信息，并以列表输出”，远远好过只发一张图。因为模型在处理视觉 token 和文字 token 的融合时，文字指令起到了“引导注意力”的作用，告诉它该重点看哪里。

3. “输出怎么处理”：从会说话到会做事的临门一脚

3.1 结构化输出：别让模型自由发挥格式

做应用的人最怕什么？最怕模型输出“好用但格式不对”——内容明明都对，就是没法直接喂给程序解析。比如让模型输出 JSON，它给你在前后加了 Markdown 代码块标记；让模型输出日期，它一会儿用中文一会儿用数字；让模型输出一个函数调用，它把函数名改了还理直气壮。

输出处理层的第一道工序，就是打破模型的“自由发挥”，逼它按标准格式交作业。

我常用的手段有几种，按可靠性从高到低排：一种是使用模型服务商提供的结构化输出或函数调用能力，模型在生成时就受 JSON Schema 约束，token 采样时就在按合法结构生成，这是最稳的。第二种是在提示词里给出严格的输出格式说明，并提供一个示例，让模型模仿，这类方法简单但稳定性稍差。第三种是在代码里做后处理，用正则、JSON 解析库把模型输出里的“杂质”剔除，尽量抢救可用内容。

我推荐的做法是“前端约束为主、后端兜底为辅”。前端约束能从根本上降低格式错误的概率，后端兜底则是最后一道保险，防止偶发错误直接打挂整个流程。一次典型的错误处理流程可能是这样：先用解析器尝试解析模型输出，成功了就直接用；解析失败，就执行修复逻辑，比如去掉多余符号、补充缺失的引号；还不行，就重试一次让模型重新生成，并附上上次的错误信息让它自己纠错。

3.2 从文本生成到任务执行：让模型“动手干活”

如果说结构化输出是让模型“好好说话”，那 Agent 机制就是让模型“动手干活”。近年来大模型应用最能让人产生“哇塞”感觉的，几乎都是这种类型：你让 AI 帮你查天气，它真的去调天气接口；你让它统计报表，它真的去执行 SQL；你让它完成一个多步骤的调研任务，它会自己规划、写代码、调工具、修正错误。

从三层架构来看，Agent 的本质是输出处理的复杂化。模型的输出不再只是一段给你看的话，而是一个“指令序列”：可能是一个工具调用的参数，可能是下一步行动的规划文本，也可能是需要注入到某个服务里的请求。系统读取模型的输出，解析出意图，执行对应工具，把结果再作为新输入回传给模型，形成一个循环。

我在实践里充分体会到一个关键点：别让模型在每一步都自由决定所有事。一开始做 Agent 的时候，我给了它十几个工具，它经常选错、卡住。后来改成“工作流为主、模型决策为辅”的思路：先定义好主流程，明确每一步该调用什么工具，模型只需要负责在关键节点做选择和填充参数。这样既保留了 Agent 的灵活性，又规避了不可控性。比如做某跨平台系统里的“自动客服工单助手”，用户描述问题后，模型先判断工单类型，再提取关键信息，然后决定是否升级人工。整个流程是提前设计好的，模型的输出只是驱动这架机器往前进的指令。

3.3 输出校验与兜底：拦住幻觉，屏蔽垃圾

模型生成的内容不能“无脑信任”，这一点我认为是做 AI 应用的人必须刻在骨子里的。模型输出天然带有概率性，同一个问题你问两次，答案可能不完全一样；当你问它一个知识盲区时，它可能一本正经地编出一个看起来毫无破绽的答案。这就是所谓的幻觉。

输出处理层要做的，不是彻底消灭幻觉——这不现实，而是建立一套拦截机制，让幻觉在落到业务系统之前就被发现和修正。

我惯用的做法是分层校验：

• 规则校验：如果输出里有日期、金额、编号这类信息，用正则或字典去核对格式是否合法。格式都不对，内容越“像那么回事”越危险。
• 逻辑校验：如果输出的内容需要与输入文档或检索资料一致，就做摘要一致性比对，把生成内容和引用片段都向量化，算一个相似度。相似度太低，就说明模型可能跑偏了。
• 二次生成校验：把模型这次的输出当作输入，再问一遍另一角度的问题，比对两次答案的一致性。比如一个总结任务，可以让模型分别从“提取要点”和“回答用户问题”两个方向生成，出现矛盾就重跑。

这套校验体系听上去很重，但落到代码里其实就是一堆 if-else 加几个向量比对调用。对于一个要认真在业务里跑起来的项目，这一层省不得。

4. “新花样”的本质：把输入输出玩出新高度

4.1 梳理 4 类常见 AI 花活的真实发力点

把视角拉回到行业里那些引起讨论的 AI 新功能、新产品，你会发现它们几乎都能用输入输出这两层来定位发力点。

第一类是“长上下文记忆”。以前模型记住不了多少内容，对话超过上下文窗口就忘事。新做法是无限扩展窗口，甚至把整本小说、整个代码仓库塞进上下文。这本质上是输入处理层的升级——从“挑着喂”变成“全量喂”。好处是你不用担心丢信息，坏处是成本高、注意力分散，这背后还有不少可在工程上优化的点。

第二类是“AI 智能体”（Agent）。它火起来的原因，是应用从“只能聊天”变成了“能干活”。前面我已经说过了，这本质上是输出处理层的升级——把模型输出当作可执行的指令，而不只是展示文本。工具调用、任务规划、自我反思，都是在围绕输出做文章。

第三类是“多模态理解与生成”。模型能看图说话、能生成图片、能听语音指令。从应用架构视角看，输入侧是图像、音频如何被编码并拼装进模型，输出侧是模型如何生成图像、音频 token 并解码成可用的媒体文件。它确实拓宽了输入输出的形态，但整体上依然没跳出三层架构的框架。

第四类是“代码解释器”这类执行能力。模型生成一段 Python 代码，系统拿去跑，再把运行结果返给模型，由它解读结果、决定下一步。这也是输出处理层的典型场景：输出变成程序代码，系统执行程序，再把新结果作为输入接上。如果拆开来看，你会发现它们使用的底层模型往往没有质的变化，真正的工程功夫全在两端。

4.2 为什么说模型层反而最“保守”

我说模型层“保守”，不是说模型技术没有进步，而是说在商业应用层，模型往往不是最大的瓶颈。大多数应用团队拿到的模型能力已经足够强了，真正让产品显得“聪明”或“蠢”的，是产品团队怎么设计和控制输入输出。

举个例子，同样用同一款大模型接口，A 产品做出来像呆板的问答机，B 产品做出来像贴心的助理。背后差的不是模型，而是 B 产品在输入里做了精细的角色设定、历史记忆、知识检索，在输出里做了人工风格的润色、结构化拆解、多轮校验。这就像同一块大理石，普通工匠和大师雕出来完全是两个东西。

所以我一直建议团队把精力分配重点放在输入输出两端：先把输入处理做到位，再强化输出校验，最后才轮到考虑要不要换更强的模型。这个顺序反了，往往事倍功半。

4.3 输入输出不是孤立的，它们是循环的

拆开讲了三层架构，但实际上好的 AI 应用里，输入和输出是不断循环的。模型生成一段输出，系统解析后执行得到一个结果，这个结果又作为新的输入拼接回去，模型再生成下一段输出。这个循环运转得好不好，直接决定了 Agent 这类应用能不能真的用起来。

实践中有个让我印象很深的细节：第一版做 Agent 的时候，我每次把工具返回的原始 JSON 直接塞回输入里，结果模型经常被冗长的工具响应干扰，下一步动作判断经常不对。后来我把工具返回结果先做一层摘要和格式化，再把这种“干净版”结果送入输入。同样的模型，决策准确率立刻上来了。

这说明，输出处理层的结果要符合输入处理层的“清洁标准”，两个环节需要配合设计。如果把它们割裂开看，就很容易出现单看每一层都挺正常、合在一起却总是出错的怪现象。

5. 效果不好时别急着换模型，先查输入输出这几处

5.1 一条好用的排查链路

在实际项目里，我最常被问到的问题就是：效果差，到底该怎么调？我把自己的排查链路整理成了一张速查表，分享出来给大家参考。

这个表格不是标准答案，但它代表了我在实际项目中反复使用的一个有效次序：从最容易改的输入开始，一层一层向下排查。因为输入和输出层的修改成本低、见效快，而换模型或者做微调的成本高、周期长，总要放在最后考虑。

5.2 一个实操避坑清单

结合我自己踩过和帮别人处理过的问题，再分享几条特别实用的避坑建议。

第一，改输入前先记录基线效果。很多人调 Prompt 全凭感觉，改完觉得“好像好了一点”，但因为没有数据支撑，根本不知道是好是坏。我的建议是每次调整先在固定测试集上跑一遍，记录成功率、格式错误率等指标，再动手改。哪怕只是一张表格，也比纯感觉强得多。

第二，一次只改一个变量。如果你同时在提示词里加了历史对话、改了示例、换了检索 top-k 数量，一旦效果变化，你很难知道是哪个变化起的作用。我在工作中已经养成习惯，一次只调整一个点，跑 5 到 10 组样例，确认影响之后再动下一个。

第三，别迷信“更强的基座模型”。很多时候换个更大的模型确实有改善，但改善幅度可能远低于你优化输入输出之后的效果。而且模型越大，单次调用成本和延迟越高，产品体验不一定变好。先花几天把输入输出折腾明白，再判断模型要不要换，这个建议值得被听见。

第四，日志里必须埋点输入输出。我在做某客服工单系统的时候，早期线上效果出了问题完全没法定位，因为日志里只记了用户问题和最终回复，中间的检索内容、提示词拼装结果、模型原始输出全都没记。后来补上了完整的链路日志，每个环节都记录下来，一旦出问题就能回放是哪一步出了岔子。这一步越早做越好。

第五，警惕多轮对话里的上下文污染。多轮场景下，历史消息会不断拼进输入，几轮之后输入里尽是旧信息，模型很容易被旧信息带偏。我建议在拼装输入时，不是把所有历史消息原样拼上，而是做一个“关键信息摘要”放在前面，再附带最近几轮的完整消息。这样既保留了上下文，又减轻了注意力分散的问题。

6. 这套思维对我的改变：一种看穿 AI 产品套路的方法论

最后聊点心得体会。说实话，三层架构这套框架最初我是在某个交流会上听一位前辈提到的，当时只觉得“嗯，有点道理”，并没有多震撼。真正让我信服的，是在之后几个项目里反复验证：只要遇到 AI 相关的问题，我几乎都能用这套框架去归因、去定位、去思考解法。它成了我看待大模型应用的一种基本思维方式。

这套思维帮我省了很多“瞎忙”。以前遇到模型效果差，我会本能地想去试新模型，或者盲目堆提示词。现在我的反应更理性和系统化：先问输入侧是否出了问题，再问输出侧有没有做足加工，最后才评估模型本身是不是真正的瓶颈。而且，这套思维在看别人的产品时也特别好用——当一个新 AI 产品刷屏时，我不会因为“哇好神奇”就完事，而是会刻意去推测：它的输入侧是怎么设计的？输出侧做了哪些加工？这种推测经常能帮我看穿产品背后的真实工程含量，也让我自己知道哪里值得学。

另外一点很重要的体会是，三层架构里的“输入”和“输出”是相对概念，边界会随着应用复杂度而变化。在一个简单问答场景里，输入处理可能就是写段提示词；但在一个复杂的 Agent 场景里，工具的返回结果也是输入，中间模型的规划文本也是输出。真正的高手能做到在这个循环里灵活切换视角，随时知道自己在处理的是哪一层。

我见过不少团队，投入了大量资源做微调，效果提升却不明显，因为他们的输入和输出处理太粗糙，模型能力被工程短板限制了。反过来，也有团队模型并不新，但把输入输出做到了极致，产品体验出色，用户根本不在乎背后是什么模型。我自己现在做任何 AI 项目，都会先画出这张三层图，标清楚每一层要做什么、做到什么程度、用什么指标验收，然后再动代码。这个小习惯，帮我避免了无数返工。

希望这篇拆解对你有用。如果你正在做 AI 应用，或者正准备入坑，不妨也试着把手上项目按这三层整理一遍，往往会有豁然开朗的感觉。哪一层的坑都可以随时找我聊，踩过的坑多了，自然就能绕开了。