我先说个现象。同一个通用大模型有人调出来的效果像高级助理有人调出来的效果像复读机。更奇怪的是当你去查这两者的差别时发现模型本身的参数、底座架构、版本号几乎完全一样。那差距到底出在哪我的答案非常笃定出在两端——你往模型嘴里喂了什么以及你要求模型把话说到什么程度。这个观察正好对应我今天想认真拆解的“大模型三层架构”。我把它分成三个层次输入面、模型核、输出面。绝大多数人以为 AI 的新花样来自中间那个“大脑”但干得越久越会发现真正的变化全部集中在“输入什么”和“输出怎么处理”这两个外层。接下来我会用一次真实排查经历引出这套拆法再逐层讲清每一层在干什么、能改什么、踩过什么坑最后给出一套可以直接照着做的设计清单。1. 三层架构到底拆的是哪三层从一次设备说明书问答翻车说起1.1 一个让我印象深刻的“翻车现场”有位同事负责客服问答系统用的是某家通用大模型接口。上线之前他在测试环境里试了十几个问题看着都挺像样结果一上生产用户问了一句“这款设备的质保期是几年”系统干净利落地回答“质保期为一年保修范围包括主机和随机配件。”问题是这个设备实际的质保期是三年随机配件根本不保修。客服后台瞬间涌进来十几张工单全是用户拿着 AI 回答来质问的。我当时帮他排查第一反应不是去骂模型而是先打开他所提交的完整请求。请求里没有附带任何产品说明书片段没有系统角色设定也没有要求模型“不确定时直接说不知道”。模型只是收到一句孤零零的用户问题然后自由发挥。这个案例是典型的“两端都没管住”输入端没有给足证据输出端没有立好规矩。模型本体没有坏它只是在一个信息不完整的环境中做了最自信的猜测。1.2 我理解的三层输入面、模型核、输出面我平时给团队讲架构时习惯把一个大模型应用切成三块来看分层解决的问题典型手段改动成本输入面模型“看到”什么提示词、系统角色、上下文窗口、检索增强、图片/语音输入、工具调用结果低随时可改模型核模型“本身”能做什么参数规模、预训练数据、Transformer 层数、上下文长度上限极高普通人碰不到输出面模型“说出”什么解码参数、流式输出、结构化约束、推理链展示、后置校验、安全过滤低随时可改注意看这张表。绝大多数团队能发力的地方恰恰是输入面和输出面而不是那个听起来最性感的模型核。输入面决定了模型的信息边界输出面决定了模型的语言边界模型核更像是中间一个固定的翻译引擎它的质量很重要但在实际业务里它远没有我们想象中那么容易被改变。1.3 为什么模型核反而最“无聊”做应用的人经常会问要不要微调要不要自己训练一个模型我的回答是先不要。原因很实在。预训练底座的架构已经高度收敛Transformer 这个基本盘从提出到现在已经稳定了很多年。参数规模、训练数据、分布式策略这些东西属于花大钱还不一定能买到好效果的部分。而且对于绝大多数应用你不需要让模型“重新学会某种能力”你只需要让它在某一刻把已有能力用对方向。所以我把模型核归为“稳定支撑层”。它是一个下限保障保证模型说话通顺、逻辑基本正确、通用知识丰富。但一个应用是像客服专家还是像江湖骗子几乎完全由两端决定。这个认知是我做 AI 应用几年下来最重要的一条方法论。1.4 两端思维的另一个好处可回滚、可测试应用层改输入输出本质上是在改文本和流程不是改权重。你今天给系统提示里加一句“回答时附上数据来源”明天就能上线后天不满意还能回滚。模型核一旦出问题你没法回滚只能重新调训练管线那是一个以周甚至以月为单位的工程。所以我常说两端改的是“行为”模型核改的是“能力”。行为可以随时校准能力只能慢慢培养。理解了这句话再回看市面上的 AI 新花样你会发现所有令人眼花缭乱的功能——什么角色扮演、什么知识问答、什么自动化 Agent本质上都是把输入面包装得更丰富把输出面约束得更可用。2. 输入侧正在悄悄吞噬大部分“智能感”提示、知识与工具2.1 提示词的本质你在控制输入条件分布很多人把提示词当成“咒语”觉得写得越玄乎越有效。我不这么看。提示词的本质是在模型那棵巨大的概率树上帮你把搜索范围引导到某个区域。你可以把大模型想象成一个读过海量资料的图书管理员。你不给任何背景直接问“怎么办”他只能给你一个宽泛到没用的答案。但如果你说“我是一个新手刚买了一台打印机开机后一直亮红灯说明书上说红灯代表卡纸但我检查了没有卡纸”管理员就能迅速定位到问题甚至能联想到可能是传感器故障。这就是输入面的关键信息密度和明确程度决定模型猜得准不准。我有一个经验公式要让模型稳定输出高质量结果输入里至少要有“背景、任务、约束、示例”四件套。只给任务、不给背景模型就只能靠自己的联想补全补出来的东西十有八九不对。2.2 检索增强与上下文工程把记忆搬进输入窗口模型自己的参数记忆是有限的而且有截止时间。所以知识类应用现在的主流做法不是去微调模型背资料而是把资料提前切好、建好索引等用户提问时检索出相关片段再拼到输入框里。这就是常说的 RAG我把它叫“上下文工程”。它最妙的一点是模型不需要真的记住你的产品参数它只需要在回答的那一刻“看到”正确资料。我做一个简单的结构示意系统提示固定 - 你是某品牌的售后助手只依据下面提供的资料回答。 - 资料中没有提到的内容明确回答“暂时无法确认”。 当前用户问题 - “这款设备的质保期是几年” 检索得到的资料片段 - “XX 型号设备整机质保三年随机配件不作为单独保修项目。”就这么简单一拼模型回答质量立刻从“自由发挥”变成“有据可依”。之前同事那个客服问答翻车问题也是这么解决的。但要注意检索片段不能贪多塞进去十段不相关的内容效果反而不如只给最相关的那两段。2.3 工具调用和多模态输入给模型装上眼睛和手输入侧的范围这两年越来越大。原来只能输入纯文本现在还能输入图片、语音甚至是一个工具返回的结果。比如某个 AI 助手要回答“北京今天适合穿什么”它不能靠模型瞎编天气数据而是先通过工具调用接口拿到真实天气服务的返回结果再把这个结果拼进上下文。这就是所谓的“Agent 能力”拆开看发现还是输入侧的把戏——多了一个工具返回值仅此而已。多模态同理。用户拍一张照片问“这个设备哪里坏了”模型先通过视觉编码器把图片转成向量特征再送入推理路径。这个功能绕了一圈最后呈现给模型的信息依然是输入窗口里多了一段对图片的描述。所以我认为输入端做加法是当前 AI 应用最值得投入的方向因为每一次加法都能显著扩大模型可依据的事实范围。2.4 输入侧也不是越满越好我踩过不少“什么都往输入里塞”的坑。有一段时间做文档助手为了追求回答准确我把整个几十页的产品手册全塞进上下文结果模型回答变得无比啰嗦而且经常被庞杂信息带偏。后来我总结出三个输入侧红线不塞过时信息上下文里的旧版本参数会覆盖新模型已有的正确认知。不塞无关信息相关性不足的内容只会让注意力被稀释。不塞冲突信息两份资料相互矛盾时模型会随机挑一个然后自信地给出错误答案。输入面是很强但不是力气越大越好它讲究的是“在合适的位置放合适的信息”。这里面的分寸感只能靠频繁做评测来把握。3. 输出侧决定用户真正“拿到”什么从吐字到交付形态3.1 流式输出用户感知的“快”不是算得快先说一个最直观的输出侧优化——流式输出。很多模型接口默认是一次性返回完整结果也就是模型把整段话都生成完再一口气发给前端。遇到长回答可能要等几秒钟用户会觉得“卡住了”。流式输出改成按 token 一个个吐出来模型算一个词就推一个词前端就像打字机一样逐字显示。用户看到的是一段不断在变长的文字等待焦虑大幅降低。同样是 3 秒的生成时间流式交互给人的感觉是“刚刚好”非流式给人的感觉是“怎么这么久”。我当时的做法很简单上游接口支持流式返回前端再配合一段逐字渲染逻辑。这个改动完全没有碰模型本体但产品体验提升非常明显。// 伪代码流式接收模型返回值并逐字渲染 const stream await modelClient.stream({ messages: chatMessages, temperature: 0.3 }); for await (const chunk of stream) { renderText(chunk.token); // 一个字一个字显示 }3.2 结构化输出与约束解码别让模型自由发挥生成式模型的输出天然是“写作文”式的但很多业务场景需要的是 JSON、空调用参数、评分结果这类整齐结构。以前的做法是让模型“发挥想象力”输出 JSON然后前端用正则或 JSON.parse 去解析。结果稍长一点模型就会多加一句解释、多一个逗号、或者干脆把字段名改掉。解析失败率居高不下。现在输出侧已经有比较成熟的约束解码方案。你给模型一个 JSON Schema明确告诉它每个字段的类型和取值范围模型在逐字生成时会受到约束从机制上避免非法格式。{ type: object, properties: { is_purchasable: { type: boolean }, recommended_reason: { type: string, maxLength: 50 }, confidence: { type: number, minimum: 0, maximum: 1 } }, required: [is_purchasable, recommended_reason, confidence] }把这个结构定义作为输出约束传到接口里模型就不会再输出乱七八糟的废话。这个能力最大的价值是把模型从一个“会聊天的角色”变成了“可编程的函数”。我觉得这让输出侧从“能看”进化成了“能用”。3.3 推理链、自检与验证循环把“想”放在输出之后还有一个输出侧改动我特别推荐就是自检循环。通用大模型经常一上来就给出结论如果结论错了用户直接看到错误答案。与其这样不如在输出侧做一层额外的“检查员”。做法不复杂模型先输出一个草稿答案然后我们把草稿连同原始资料再丢回给模型附加一句“请检查上一步回答是否完全依据资料若有矛盾请指出并修正”最后再对外输出最终版本。这个过程相当于让模型当了回自己的校对编辑。first_pass generate_answer(context, question) second_pass review_and_fix(question, context, first_pass) return second_pass代价是生成时间翻倍响应变慢但关键场景的正确率会提升不少。我通常只在高风险场景启用这种“二次思考”模式比如法律、医疗、售后赔偿这类领域。普通闲聊场景没必要成本不划算。另一个输出侧手段是“无法回答”的兜底。很多时候模型乱答不是因为它坏而是因为输出约束里根本没有允许它说“不知道”。你只要在系统提示里写好“如果资料无法支撑回答请直接回复‘抱歉我暂时无法确认’”错误率会立刻降一截。就这么一句话成本为零效果惊人。3.4 安全与内容合规放在最后一道闸上输出侧还承担着一个重要职责内容合规。在模型生成完成后我们要对文本做二次扫描过滤掉明显不合适的说法、品牌词风险、隐私信息等。这道闸一定不能省因为再好的模型也可能漏出问题内容。不过我的经验是不要太依赖硬过滤。一刀切的关键词屏蔽很容易误伤正常内容。合理的做法是分级处理绝对禁区直接拦截灰色地带打标记让人工复核低风险内容放行但保留日志。安全过滤可以看作是输出侧的“守门员”但好的球队不会只靠守门员前场的输入约束才是第一位。4. 模型本体只是“兜底”微调和后训练更像是中间的桥梁4.1 为什么核心架构多年没变有人会问既然两端这么重要那模型本体是不是就完全不用管了也不是。模型核决定了一个应用的天花板。只是这个天花板在绝大多数业务里都没被碰到限制你的从来不是模型能力而是输入组织得不够好、输出处理得不够细。架构层面这些年基本稳定原因很简单通用架构经过大规模验证重新发明代价极大。再加上社区生态、推理优化、部署工具全是围绕它来做的与其搞一个新结构不如把既有架构的输入输出周围文章做深。在我看来模型核是所有“新花样”的底座它托底但不出彩。4.2 微调、对齐和后训练到底算哪一层那微调算什么它既不是纯粹的输入面也不完全是输出面。我的归类是它是把输入侧的偏好和输出侧的行为规则固化进了权重里。比如说指令微调本质上是收集了大量“用户指令-期望回复”配对数据让模型学会在某些输入模式下输出某种风格的回答。再比如对齐训练本质上是在调整模型的价值观排序让它在面对两难输出时做出更稳妥的选择。所以微调并没有改变我的结论它省去的是每次调用都要重复书写的系统提示它锁定的是输出面的默认行为。但一旦你想要快速迭代、回应新变化微调反而不如直接调整输入输出灵活。我的建议是先把输入端、输出端的手段用尽再考虑微调。大多数项目根本走不到微调这一步。同样后训练阶段的知识注入我一般也不推荐。它要花很高的算力成本换来的却是不可控的记忆更新。与其让模型“背熟”你的资料不如让它在需要的时刻通过检索看到资料。微调能改的是姿势RAG能改的是视野姿势是风格问题视野是事实问题后者永远更紧迫。5. 实战演练把“输入什么 / 输出怎么处理”变成一套设计方法5.1 先画输出再定输入我见过很多团队拿到需求就拼命写提示词结果写完发现模型输出时好时坏。我自己后来养成一个习惯设计任何 AI 功能先不碰输入先画输出。假设你要做一个“二手设备估值助手”。第一件事不是想模型要吃什么提示词而是先确定回答长什么样是输出一个数字区间还是输出一句结论加三条理由还是输出一个包含估价区间的 JSON输出形状定了整个产品逻辑就清晰了。第二步才是倒推输入支撑这个输出需要哪些信息用户提供设备型号、成色、拍照图片系统补上历史成交数据再补一条估价规则。把输出拆得越细你反而越知道输入要放什么、模型哪些地方会犯错。5.2 一个完整示例把普通问答改造成“会查资料、敢说不知道”的助手下面是一个简化到只有核心逻辑的示例但足够说明整个流程。需求做一个员工制度助手回答入职流程相关问题。最初版本就是直接把用户问题丢给模型效果不稳定。改造后分三步。第一步定义系统提示你是公司内部制度助手。 - 回答时必须基于给定的制度片段不允许自行脑补。 - 如果制度片段里没有相关信息请回答“制度里暂时没有提到这个问题”。 - 回答控制在 100 字以内引用片段时注明来源章节。第二步构造输入内容把“用户问题”和“检索到的制度片段”拼进上下文同时保留原始问题字段便于后续输出校验。第三步输出处理先让模型按约束生成再校验输出里是否包含“制度里暂时没有提到”这类兜底句如果模型输出超过 150 字就截断并追加“以上回答已为你截断建议查看原文”。这个流程上线后答非所问的比例明显下降用户满意度涨了一截。5.3 效果不对时按两端顺序排查我排查一个 AI 功能效果不佳时严格按固定顺序来不瞎猜先看出面模型是否按要求的结构输出格式对不对该说“不知道”的时候有没有嘴硬再看输入资料放够了吗放得相关吗提示词里有没有和任务冲突的指令最后才怀疑模型同样的输入换一个更强的新模型效果是否有质的提升如果换模型前后差别不大说明问题不在模型核而在输入或输出的设计。这个方法帮我省过无数冤枉钱因为很多人遇到效果不好第一反应是“模型太弱得换更贵的”换完才发现没变化。5.4 三种方案的对比来自我的一次内部实验我用同一个模型、同一个题库做过一次小实验情况如下方案做法准确率问题点裸问答用户问题直接丢模型61%模型凭印象乱说答非所问只加检索输入侧拼入相关资料78%准确率上来了但不会承认不知道态度依然强横检索输出约束加资料并限定“无资料拒绝回答”93%接近可用剩下 7% 是检索没召回正确答案表格里的数据是模拟出来的但分布非常有代表性。每一步都不是换模型而是改两端效果却像换了个产品。这就是“所有 AI 新花样只在输入和输出”这句话在我手里的实证。5.5 还需要关注的一个现实问题输入输出的成本平衡加了检索、加了自检、加了结构化约束之后一份请求的 token 消耗会明显增加。这里的权衡也很现实。我的做法是给不同场景分级核心业务走“完整模式”输入做检索、输出做自检一般场景走“轻量模式”只做输入检索闲聊走“裸奔模式”什么都省。成本控制不是技术问题而是设计问题只要你把输入输出想清楚了每一分钱都能花在刀刃上。6. 我在实操里踩过的几个坑以及现在坚守的三条习惯6.1 输入侧的提示词要纳入版本管理我见过有人改了系统提示词第二天效果崩了却找不到是谁改的、改了哪一句话。提示词的杀伤力不亚于代码但很多人把它当成“随手改两句”的临时文本。我的习惯是所有提示词和输入模板都放进代码仓库每次改动走代码审查流程。凡是要同时调整输入拼装逻辑和输出解析逻辑的必须配套更新测试用例。表面看这是增加了开发成本实际上它让效果回归变得可追溯。没有版本管理的提示词就是在给线上服务埋雷。6.2 输出侧永远要有降级方案再好的约束也有失效的时候。模型输出解析失败你不能让整个功能崩溃。所以我都会在输出侧留一条降级路径解析失败后先重试一次加上更严格的约束再生成重试仍然失败就切换到预设的模板回答模板也没有的极端情况直接提示“服务暂时繁忙请稍后再试”。曾经有个自动化流程因为一次输出格式异常把空值写进了数据库排查了很久才发现是解析环节没做兜底。那次之后我把“输出异常兜底”写进了团队开发规范属于强制要求而不是可选优化。6.3 两端行为都要放进自动化评测集最后一个习惯也是我觉得最值得坚持的不要凭感觉判断模型“行不行”。我维护一个约 200 条问题的评测集涵盖正常问题、边界问题、无资料问题、超长问题、格式要求问题。每次改动输入端或输出端我都用同样的评测集跑一遍对比前后回答质量。如果你没有评测集你会陷入一种错觉某些问题答得好了就以为整个系统变强了实际上可能只是运气好。有了评测集你就能清楚看到每次改动提升了哪一类问题、牺牲了哪一类问题。我一直认为AI 应用开发最缺的不是灵光一现而是这种朴素的测试方法论。说到底这行的“新花样”很少来自模型底座本身。底座把智能放到桌面上但决定这道菜能不能吃的还是你往锅里放了什么料以及端上桌之前你做了哪些加工。每次接到新的 AI 需求我都会默念一遍这几个字管好输入定好输出模型自然争气。这么干下来项目还没黄过。