大模型这个圈子待久了你会发现一个现象各家发布的“新能力”看着一个比一个花哨可真把那些Demo拆开底层模型没换训练方式没变变的只是“喂进去的内容怎么组织”和“吐出来的结果怎么使用”。这句话说重一点几乎所有 AI 应用侧的新花样本质上都是在「输入什么」和「输出怎么处理」这两端上做文章。这套三层架构的思路我做项目用了大半年越用越觉得值得好好写一篇。这篇文章把这三层拆开聊底座能力层、输入编排层、输出处理层。不涉及训练和微调只看应用落地。适合刚接触大模型开发的工程师也适合那些已经调了一堆 prompt 但总觉得效果不稳定的同学。读完你会发现很多“灵光一现”的玩法背后都是同一套逻辑。1. 三层架构到底在拆什么——先别急着背概念1.1 一次普通调用背后的旅程我先带你走一遍大模型应用中最常见的一次调用流程。假设你在做一个客服问答系统用户问了一句“我上个月的账单为什么多了二十块”。这句话到达后端之后实际被处理成了一段比这句话长得多、结构也复杂得多的文本通常包含系统指令、历史对话、检索到的账单规则、用户问题原文最后拼成完整的请求送到模型推理接口。模型推理完成后返回的也不是一段“答案”而是一连串 token附带各自概率。你的代码要收下这串 token把它拼接成文本再丢给一个解析方法提取出“用户要的东西”甚至还要判断是否要调用一个查账接口。整条链路走下来你会发现模型只参与了中间那一小段吃进拼接好的文本吐出原始 token。这个视角特别重要。它把大模型应用拆成了一个熟悉的架构输入侧负责“给它什么”模型本身负责“理解与生成”输出侧负责“拿生成结果怎么办”。我习惯把这三块叫底座能力层、输入编排层、输出处理层。项目里几乎所有有意思的迭代都发生在第一层和第三层。1.2 三层各自的边界底座能力层是模型发布那一刻就定死的部分。比如它有没有数学推理能力代码能力强不强中文表达是否自然能支持多长的上下文。这部分你换不了只能在选型时做权衡。选一个强模型后续输入输出处理会轻松很多选一个弱模型你就必须在输入和输出两端用更多工程手段去补。输入编排层指的是你在把问题交给模型之前做的所有加工。写系统提示词、拼接历史对话、加入检索到的参考资料、给出 few-shot 示例、把工具说明塞进去都属于这一层。这里做的事情本质上是“控制模型的信息边界”告诉它任务是什么能用到哪些材料回答时要注意什么。输出处理层指你拿到原始输出之后做的所有工作。设置解码参数温度、top_p、max_tokens要求模型输出 JSON解析它的返回结果判断是否触发工具调用把调用结果再次塞回输入甚至设计 Agent 循环让它多次思考后再给结果这些都是输出侧的事。1.3 为什么这个拆分有用很多开发者的痛苦在于“我给提示词写了八百字效果还是不行。”拆成三层之后你会立刻发现问题可能根本不在提示词上。你的 context 里塞了一堆不相关的文档模型自然被带偏你的输出解析脚本只处理了“完美 JSON”模型一旦多输出一个标记整个流程就崩了。这些都不是“再写两句话”能解决的。这个架构还有一个直接好处排查问题时你能快速定位故障发生在哪一层。效果差先看输入侧有没有给足信息效果飘先看输出侧解码参数和结构化约束上下文长了反而乱先看底座能力层的窗口是不是真的适合这个场景。下面两章我会把输入和输出这两端分别拆细这也是整个架构里最值得花时间的地方。2. 输入端怎么玩把“信息边界”管好2.1 提示词本质上是“给地图”不是“改大脑”你先要建立一个基本认知提示词不会提高模型的真实智力水平它只是把模型已有的能力引导到正确方向。这就像你给一个本地人指路你说得再详细他也不可能突然变成一个建筑工程师但你能帮他绕过那条最容易走错的路口。所以在设计输入时我习惯先问几个问题模型需要知道哪些事实才能回答这个问题哪些信息加了反而会造成干扰任务边界是“直接答”还是“先查再答”输出格式有没有硬性要求把这三个问题想清楚再动手写提示词成功率比上来就编一大段人设话术高得多。比如在事实问答场景里一个可靠的系统提示词框架是这样先说明自己是什么系统再告诉模型“只基于参考资料回答”然后明确“如果资料里没有就直接说不知道”最后附上输出格式要求。这四件事做好比写三百字“你是一个博学多才的助手”管用得多。2.2 context 窗口是输入侧最值钱的资源大模型在推理时能看到的全部信息就是你塞进上下文的内容。很多人的误区是“窗口越大越好那我把所有文档都丢进去”。实测下来上下文过长模型对中部信息的注意力会下降回答质量不升反降。你可以在项目里做一个小实验同样一个问题分别用“全文检索塞正文”和“只塞相关片段”两种方式跑后者往往明显更稳。原因很简单模型需要聚焦在关键证据上而不是在几十页无关内容里自己找重点。所以不要把 context 当硬盘用它应该被当成“作战室里的白板”只放这次任务需要用到的材料。2.3 RAG 的本质是在输入端“定点投喂”RAG检索增强生成这几年很火拆到三层架构里它其实完全活在输入编排层。你先把知识库切成小块用户提问后用向量检索找出最相关的几块再把这些块连同问题一起拼进 context。模型本身没有新增任何知识它只是在回答时“开卷考试”看到你投喂的材料。我做资料问答助手的经验是检索质量比生成质量更影响最终效果。你辛辛苦苦把提示词清得很干净结果召回的片段根本不对那模型再强也白搭。chunk 切多长、用哪种向量模型、要不要加重排这些才是 RAG 场景下真正的胜负手。当你发现回答“总是少了点关键信息”时别急着改 prompt先去查召回结果。2.4 few-shot 是“给格式样板”但小心副作用少样本示例在输入侧的作用不是教模型新知识而是告诉它“回答长什么样”。模型对格式有极强的模仿能力给它两个合规示例它大概率会照着这个格式走。这是最便宜的格式化手段。不过这事有副作用。示例里的语言风格会被模型学走示例太长会挤占上下文空间示例太特殊还会把模型“带偏”到那个特例里。我的习惯是示例数量控制在两到三个每个尽量短覆盖常见但不同的情况而不是贴一个冗长的标准答案让模型去背。说到底输入端的设计原则永远是“精确、克制、够用”。3. 输出端怎么玩从“一串 token”到“能用的结果”3.1 解码参数决定了模型“胆子”有多大模型返回的是概率分布而你设置的解码参数直接决定它敢不敢“冒险”。温度就是最典型的开关温度接近 0模型基本只会选概率最高的 token回答稳定、可预测性强适合事实问答、信息抽取温度调到 0.7 以上模型会开始选一些概率没那么高的词回答更有创意但也会天马行空。你可以在同一个提示词下做对照产科问答系统把温度调到 0.1连续问十个问题答案几乎不重样且稳定调到 0.9同一个问题可能给出风格完全不同的几版回答。写营销文案则反过来温度太低生成的内容像在念说明书。所以调参的第一课不是“背参数表”而是先想清楚你要的是“偶尔惊人”还是“始终可靠”。top_p 是第二位玩家它控制的是“从累计概率多少的候选词里采样”。我用的时候一般只调两者之一很少同时大改不然很难解释效果变化到底是哪个参数的功劳。3.2 结构化输出让模型对机器“说人话”普通聊天场景里模型直接吐一段散文没问题但系统要处理它就得让它按约定好的格式输出。最常见的做法是叫模型只输出一个 JSON 对象并且字段名称、类型事先约定。工程上我会在系统提示词里放一段 schema 说明有时甚至直接给模型一个“参考 JSON 结构”的模板。但模型不是数据库它偶尔会“手滑”多输出一个逗号、漏掉一个引号、或者忍不住在 JSON 外面包一个json 代码块。这类问题如果只靠提示词永远治不干净。更稳的做法是在代码里加一层“宽容解析”先尝试直接 parse失败后把json 标签剥掉再 parse再失败就用正则把可疑区域抠出来修复。这层兜底逻辑能把结构化输出的稳定率从九成拉到九成九。3.3 CoT 要不要开得看业务接不接受“碎碎念”思维链CoT让模型在给出结论前先展示推理步骤很多复杂任务在这个模式下准确率明显提升。原因是它强制模型把“中间结果”写出来相当于把黑盒推理拆成了一段可检查的逻辑链。但代价也很具体输出变长、响应变慢、费用变高而且有些模型在“想太多”之后反而会过度怀疑自己。我常用的折中方案是告诉模型“先自己思考但只在最终回复里输出结论和关键理由不要输出完整推理过程。”这样既拿到了 CoT 的准确率红利又不会让用户等半天看模型内心戏。3.4 工具调用输出端真正的“放大器”如果说前几项还是在文本范围内做文章工具调用则让输出直接“变成动作”。模型不需要真的去执行什么它只在输出端生成一个结构化指令函数名、参数列表。代码收到这个指令后自己去调外部 API、读写数据库、执行计算再把结果塞回输入侧让模型基于新信息继续回答。这个闭环是 Agent 的核心拆开看就是“输入-输出-再输入”。你会发现问题又回到了两层输入侧要写清楚工具是什么、什么时候用、参数怎么填输出侧要可靠地解析模型选择的函数名和参数。我在实战中的关键体验是把工具描述写得像给新人看的说明文档模型调用工具的准确率会明显提升。很多人反复强调“你必须使用工具”但模型真正需要的是知道这个工具能干什么、每个参数代表什么。4. 一个完整项目的调参实录三层架构的实战组合4.1 模拟项目做一个资料问答小助手为了让这套东西更落地我给你看一个我最近做的模拟项目 X一个面向内部资料库的问答助手用户用自然语言查制度、查流程、查历史记录。最初版本非常简单把用户问题直接发给模型让它凭感觉回答。结果是效果完全不可控有时候答得很准有时候一本正经地编制度条款。我没有一味加提示词而是用三层架构重新梳理了一遍底座层面确认模型窗口不适合一次性吞全部制度文档输入层面接入了检索模块只投喂相关片段输出层面要求纯 JSON 返回字段里明确标注“答案、引用章节、置信度”。一个下午改完效果明显换了副面孔。4.2 输入端我具体做了什么我先写了一段系统提示词只保留三部分角色限定为“资料库问答助手”硬性规则“只能依据参考资料回答没有依据就回复不知道”输出必须是一个 JSON。然后我接入了检索链路。制度文档按章节切块每块控制在几百字以内用户提问后先召回最相关的三到五块再把这些块拼到提示词里。相比之下最初版本把整个 PDF 的纯文本塞进去的做法既慢又容易串味。再补一招把规则里的几个高频措辞做成 few-shot 模板。这个动作不是为了教模型制度内容而是告诉它“遇到有冲突的说法时以最新修订版本为准”这种输出风格。整个过程下来输入侧的结构已经非常清晰后面所有优化都是在这个地基上做增量。4.3 输出端我调了哪些参数输出侧的改动比输入侧更直接。第一件事温度从默认值调到 0.2因为我要的是稳定事实回答不是创意写作。测试下来同一个问题连续问五次答案主体基本一致偶尔出现的措辞差异也不会影响后续解析。第二件事是强制 JSON 输出。我在提示词里附了返回格式说明并且在代码里做了宽容解析。实测没有加解析兜底前偶尔会出现“多一个逗号”导致整个链路失败的情况加了兜底后解析失败率基本归零。第三件事是对“不知道”场景的兜底。模型如果回答不了我让它输出 confidence 字段为低前端拿到后自动展示“资料库中未找到相关内容”而不是硬着头皮瞎编。这一步把幻觉问题从“晚点被用户骂”变成了“提前被系统拦住”。4.4 最终效果和数据对比改完这套组合拳之后我做了个小范围评测。参考数据集里准备了五十个问题包括二十个有标准答案的、二十个资料库没覆盖的、十个存在相似条款容易混淆的。改版前标准答案准确率大约六成未覆盖问题的“硬编率”接近一半用户体验很差。改版后标准答案准确率提高到九成未覆盖问题的拒绝率提升到九成以上相似条款的区分能力也明显改善。这个项目最打动我的不是某个单一技巧而是三层架构带来的可解释性每次效果波动我都能立刻判断是哪一层出了问题而不是像以前一样病急乱投医。5. 常见问题与排查心得速查5.1 输出格式漂移怎么修现象要求输出 JSON偶尔多出几行解释文字或者字段名换了个叫法。排查思路先看温度是不是偏高温度越低越容易遵守格式要求。再看 few-shot 示例是不是统一用了 target 字段而系统提示词里写的是 result这种不一致很容易让模型犯迷糊。最后确认解析层有没有容错最好保留一份成功样本作为 golden test。我的解法把 schema 直接写在提示词里并附一个真实输出的示例。这比反复强调“不要输出多余内容”更有效。5.2 改了提示词但效果没变为什么这是很多人最常踩的坑。你的修改很可能根本没体现在模型看见的内容里缓存命中导致请求压根没变化或者你改的是 system prompt 但代码里实际拼的是老模板。先查日志原文确认模型真实收到的输入是什么样的再做判断。如果输入确实是新的但效果依旧那问题大概率不在提示词层面。去检查检索链路、知识库内容、输出解析逻辑。5.3 工具调用失败的排查链工具调用失败一定要按顺序排查模型有没有输出正确的函数名参数名和参数类型是否匹配 schema代码里有没有把 assistant 的输出误当成 user 的内容工具返回结果有没有正确塞回上下文大部分失败原因都是“参数类型不匹配”或“返回结果没有回填”而不是模型本身太笨。我给团队定的规矩是工具描述必须包含参数示例、类型说明、使用场景。实测这个习惯能大幅降低调用失败率。5.4 上下文太长导致回答变差症状塞入的资料越多回答反而越差。原因通常有两个一是模型对超长上下文的注意力确实有衰减尤其对中间部分的内容关注度更低二是塞入了大量无关信息模型被噪声干扰不知道应该依据哪一段。解法不是无脑扩大窗口而是提高检索精度、限制投喂片段数量、按相关度排序。把最相关的信息放在开头和结尾模型会更“看得到”。上下文管理是输入侧的基本功值得花精力做好。5.5 个人经验三层架构让“智能系统”可维护用了三层架构一段时间后我做项目的状态变化很大。以前所有问题都诉诸“改提示词”现在会先分诊是底座能力不够、输入没给够支撑还是输出处理不兼容。大部分问题在输入和输出两层就能解决底座要换模型的情况反而是少数。建议你把当前项目画成一张链路图标清楚每一层做了什么后续每次调优都带着“我在改哪一层”的意识少走弯路。最后分享一个小习惯每次调完输入或输出至少保留一份变更前后的对比记录。这个习惯会在两周后救你一命。