市面上的 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 应用或者正准备入坑不妨也试着把手上项目按这三层整理一遍往往会有豁然开朗的感觉。哪一层的坑都可以随时找我聊踩过的坑多了自然就能绕开了。