“AI 又出新花样了”——这句话过去两年我听了无数次。但如果你真的把那些被吹上天的“新能力”拆开看会发现一个非常朴素的规律模型还是那个模型变的一直是它两端的输入和输出。所有 Agent、RAG、推理增强、结构化输出、工具调用本质都是在做同一件事——决定模型“看什么”和“说什么”。这篇文章我想把大模型的能力拆成三层架构来讲。它不是一个精准的学术定义而是一种非常实用的工程视角。用这个视角去审视你手头的 AI 功能很多“为什么这个方案有效、那个方案翻车”的问题会变得异常清晰。1. 三层架构的底层认知模型并不是“能力本体”很多人对大模型有一个误解觉得 GPT 这类模型是一个“会思考的引擎”给它一个意图它就能自己搞定一切。这个误解直接导致了一批失败的技术方案——比如有人把 2000 页的合同直接塞进上下文让模型做合规审查结果前 300 页的内容在后续对话中被模型忘得干干净净有人试图让模型自己解高次方程结果它一本正经地给出了一堆看似合理但第一步就错的推导。工程真相是大模型只是一个“概率性的文本续写器”。它没有持久记忆、不会计算、不能访问实时数据、也不具备稳定的判断力。它唯一擅长的事情是根据你给的上下文预测最合理的下一段话。这就像一个只有“短期记忆”的同事——你递给他的每一份材料他都“读过”但一小时后你说“记得刚才第三段的结论吗”他大概率已经模糊了。而且这位同事有个怪癖他只按“你最后强调的写法”来输出中间你顺嘴提过一句的规则他通常会选择性遗忘。理解了这一点三层架构的划分就顺理成章了层级核心归属通俗理解第一层模型本体不可变的参数空间一个能力上限固定的“实习生”第二层输入塑形我们让模型看到的东西给实习生准备的“工作清单 参考资料 要求文本”第三层输出管控我们对模型产出的约束与加工检查实习生交上来的文件“格式对不对、结论可不可用”所以你在市面上看到的那些新产品拆开以后无非是三类操作要么在第二层疯狂加“参考资料”和“规则说明”要么在第三层加一层“格式化模板 自动校验”要么是第二层和第三层之间打通了一个“多轮循环”——让模型的输出再次成为输入。ChatGPT 的 Code Interpreter、各类 Agent 框架本质都是这套循环。1.1 为什么说模型本体的能力“更新”最不值钱现在很多厂商的宣传口径是“我们升级到了 X 版大模型所以能力大幅提升”。但站在工程视角模型版本的更新对大多数应用来说是最不重要的变量。我见过不少团队平均每季度换一次基座模型但应用的体验曲线并没有质变——因为他们的输入输出结构一直没动。这就像换了一台更强的发动机但传动轴还是老旧的。真正决定应用体验的从来不是你用哪个版本的模型而是你喂给它的信息结构是否合理、你对输出结果的管控是否到位。2. 输入塑形让“实习生”看见你真正想让他看的东西输入层的设计决定了模型能力的下限。你给它的材料越符合它“文本续写”的本能它发挥得就越稳定。这层看起来简单但坑最深。2.1 上下文注入的“预算思维”绝大多数开发者都知道要往系统提示词里塞背景知识但很少有人把“上下文预算”当成一种稀缺资源来管理。模型能接受的 Token 是有限的而它的注意力分布并不均匀——它更容易记住上下文开头和结尾的内容中间的细节很容易被稀释。这不是玄学而是注意力机制的空间偏置。我见过一个典型失败案例某团队做了一个法律问答机器人把一部 300 万字的法律汇编全部塞进上下文指望模型精准引用。结果模型输出的内容既没有条理也经常引用错误条款。后来改成“先用一个小模型做关键词检索选出最相关的 20 条条款只把这 20 条作为上下文注入”准确率直接提升了一倍多。所以请记住一条铁律给模型看的资料永远只给“做当前任务最需要的那一页”而不是整本书。多不一定好越多反而越容易让模型抓不住重点。真正专业的做法是先分析当前任务需要哪些具体信息维度用独立的检索器或向量库召回 Top K 相关资料将召回的资料按重要性排序后灌入上下文最重要的放最前面和最后面上下文里明确标注“请优先参考第 N 条资料其余仅供辅助”。这样的输入结构比一次性盲目塞入海量内容稳定得多。2.2 指令设计的“接口思维”提示词不是魔法咒语而是接口标准。你的输入格式稳定输出才会稳定。很多翻车案例都出在提示词“太灵活”——今天说“请你总结一下”明天说“给个摘要”后天说“提炼要点”。模型对同一意图的多种表达可能会产生微妙但致命的行为差异。我习惯给提示词设计一种“僵硬的模板”风格角色一句话说清楚任务用编号列清输出格式写死甚至给出一个极简的“示例输出”。模型不需要理解你的审美它只需要知道“这个输入结构下输出必须长这样”。模板必须遵守三条原则明确领域边界告诉模型哪些是它不需要处理的。比如“你是发票信息抽取助手仅识别发票页面中的文字不回答其他问题”格式化输出约束用 JSON 或 Markdown 结构把输出的字段钉死优先级说明当上下文里的信息和用户问题冲突时以谁为准。这点不写清楚模型经常自由发挥。2.3 工具定义的“说明书策略”在 Agent 类应用中模型需要学会“选择工具”。你会发现工具定义本身就是输入层的一部分它的核心是“翻译”把工具的参数、限制、使用条件翻译成模型能理解的自然语言说明书。很多团队给工具起的名字特别随意比如一个“查询天气”的功能函数名叫 fetchAqi描述写“get pm2.5 data”。模型看到这种工具描述根本不理解它和“今天适合跑步吗”这个问题有什么关系。好的工具描述应该是工具名获取城市实时空气质量 参数城市名称 说明当用户询问某地空气污染、PM2.5、跑步适宜性时调用此工具获取最新数据。 如果参数不明确先追问城市名。这套“说明书策略”能显著减少模型乱调工具的次数。它不是高深的算法但胜过很多花哨的调度逻辑。3. 输出管控真正拉开产品体验差距的“护城河”如果说输入层决定模型能力的下限那输出层直接决定你产品的质量天花板。同样的模型、同样的输入不同的输出管控策略产出的结果可以是一个能用、一个完全不能用。3.1 结构化输出的强制手段很多人第一次让模型输出 JSON会被它气死多了一个尾逗号、字段名花式大小写、注释混在 JSON 里。这不能怪模型因为普通文本续写天然不擅长遵循格式规范。输出层要做的是用工程手段“强制”而不是“劝说”。实操中我有三招受限解码比如 JSON Mode / 函数调用模式直接从解码阶段把非 JSON 的 Token 概率降到零。这是最可靠的手段但要注意它只保证“语法上像 JSON”不保证字段语义正确前端正则 Schema 校验拿模型输出的文本去做 JSON Schema 校验不通过就让它重写或者扔进一个轻量级的纠错模型里修复固定字段 填充式输出让模型只写“值”不写“键”。例如提示词里写好{title: , 让模型只补全...}的部分再拼接成完整 JSON。这种做法能极大降低出错率。3.2 置信度路由让模型承认“我不会”输出管控不仅仅是格式化还包括对“模型能力边界”的管理。你可以让模型在遇到自己不擅长的任务时不硬答而是输出一个低置信度标识然后你的系统自动把它路由给人工、另一个模型或者一个专门的检索流程。比如做一个客服机器人不是所有问题都适合让模型直接回答。让它先给自己的答案打个分如果低于 0.6直接触发“转人工客服”流程。这个简单的输出动作可以让整体满意度提升好几个档次。模型不需要真的知道自己“错没错”它只需要被引导着去“反思自己的把握程度”。3.3 输出后处理的“镜像校验”这是我在生产环境里吃过亏之后总结的方法。模型输出文本后不要急着直接用它而是把它的答案“折返”成输入再做一次交叉验证。举一个实际案例模型负责从简历里抽取姓名、电话、邮箱。它抽出了一个电话“138-0000-1234”。我写了一个后处理脚本把这个号码重组成纯数字然后去原文里做精确匹配。如果匹配不到说明模型编造了号码直接标记为抽取错误。这种“输出折返校验”能拦截掉很大一部分幻觉数据。同样的思路也适用于长文本摘要让模型先总结然后把总结塞给它问“以下内容是原文中的事实吗列出原文依据”。这个二次验证的成本很低但能筛掉大量信息失真。4. 经典案例拆解输入输出循环如何把“新花样”变成“真能力”下面用我实际带过的一个模拟项目来走一遍流程。这个项目叫“企业知识库智能问答助手”听起来很普通但各种新功能——联网搜索、工具调用、多轮对话——全都齐了。它是个绝佳的解剖样本。4.1 需求画像与架构选型需求是企业内部有大量的制度文件、培训材料、项目文档员工需要快速检索“出差报销流程是什么”“某项目的截止时间是哪天”。起初团队想得很宏大用 RAG、用 Agent、用向量库、再来个自动摘要。我拦住了说先别急着堆技术我们先画一张“输入输出流程图”。用户输入自然语言问题第一层处理判断这个问题是“直接知识库里能查到的”还是“需要调外部逻辑的”比如费用计算、日期推算第二层处理检索相关知识片段注入上下文模型输出回答文本第三层处理提取“最终答案 引用来源编号 置信度”三重结构。仅这个流程走下来我们发现 70% 的需求根本不需要 Agent 或多轮循环——一次检索 一次生成就够了。4.2 输入层改造把“模糊提问”变成“明确查询”光靠用户原话去检索效果不稳定。我们做了个轻量级的改写模块先把用户问题里涉及的同义词、缩写、部门名统一映射成知识库里的标准词汇。比如员工问“出差打车怎么报销”改写器会把它标准化为“交通费报销流程”然后再去检索。这一步细小但省了大模型的力气。更重要的是它将“用户的语言”和“库里的语言”做了对齐让后续注入的上下文更精准。实践下来同样的模型这个步骤让答案准确率提高了 20% 左右。4.3 输出层改造让每次回答都能回溯验证我坚持在输出里加了两个固定字段一个是“证据来源”模型必须引用知识库的片段编号另一个是“未覆盖声明”如果模型觉得上下文不足以支撑回答必须明说“知识库未找到相关内容”而不是编一个答案。后处理时脚本会检查每个“证据来源”编号是否存在、是否真的出现在注入的上下文中。如果来源编号瞎编整个回答直接判定无效触发重新检索。这是输出层对幻觉的硬约束。4.4 输入输出的循环优化Agent 的真相这个项目后期我们加入了一个“多轮修正”功能模型首次输出答案后如果置信度低系统会拿这个答案去反查知识库把补充的相关片段再次注入让模型生成第二版答案。这一版因为补充了上下文往往比第一版丰富得多。这个循环本质上就是最简版的 Agent 机制——没有真正的“思考”只有输入输出的反复交替。它效果好不是因为模型突然变聪明了而是因为每一轮迭代都让它“看到”了更多相关的信息同时在输出层被纠正了方向。5. 避免“输入输出陷阱”五个最常见的翻车现场我把这几年踩过的坑和同行交流中最常出现的问题整理成五个典型陷阱每一个都对应着“输入层”或“输出层”的疏忽。5.1 陷阱一上下文塞满以为就是“增强输入”“我把 50 份文档全喂给它了为什么回答还是错”——因为模型根本记不住中间那 30 份。解决办法是检索不是硬塞。这也是 RAG 最朴素的动机通过检索器挑出最相关的片段而不是让模型阅读全部语料。5.2 陷阱二输出格式要求写在提示词里就完事写“请以 JSON 格式输出”模型可能输出一个带注释的 JSON、带 markdown 的 JSON甚至输出“以下是一个 JSON”这种垃圾前缀。必须在解码层或后处理层用工程手段强制而不是依靠模型的“自觉”。5.3 陷阱三完全信任模型输出的代码和数字模型生成的代码不一定能跑算出来的数字不一定对。正确姿势是把代码扔进沙箱执行把数字做回原文校验。把模型输出的验证交给确定性程序这是我们工程师的本分。5.4 陷阱四没有为模型设置“拒绝路径”所有“必须回答”的系统都会失败因为模型一定会硬答。给它一个合法的“我不知道”出口配合低置信度路由比逼它回答强得多。别怕用户收到“知识库没找到”就失望这恰恰是维持长期信任的关键。5.5 陷阱五把输入输出循环做成无限循环多轮迭代不是越多越好。每轮迭代都有概率引入新的细微误差而且成本翻倍。我在生产环境用过的原则是循环最多两轮。两轮之后如果置信度还低直接转人工或给兜底答案。一轮能解决的事绝不无脑转十轮。6. 用“输入输出”眼光重看当前所有的 AI 新功能用这套框架去审视现在市面上的新功能你会看得很通透功能/产品本质操作联网搜索从网络获取最新文本作为上下文注入输入塑形RAG 知识库从库里检索相关资料作为上下文注入输入塑形工具调用把外部 API 调用结果写入上下文继续生成输入塑形 输出循环代码解释器把代码执行的输出作为新输入继续迭代输入输出循环长文本写作把“章节大纲 前文摘要”作为输入保证连贯性输入塑形多模型投票多个输出结果做比较或融合输出后处理思维链让模型先输出推理过程再把推理过程作为后续输出的条件输入输出链这七个“花样”没有一个是改变了模型本体。它们全部在“输入什么”和“输出怎么处理”这两端发力。认清这一点你就不会再被无休止的“新概念”给绕晕了。以我的习惯拿到一个新 AI 应用的宣传资料我第一件事不是看它用了什么大模型、什么框架而是画一张非常简陋的流程图输入从哪里来经过哪些改写和检索模型在这个环节看到了什么输出被如何处理和校验如果输出不对会不会回灌这张图画清楚了这个功能对我而言就“透明”了。我强烈建议你也试试这个习惯——它会帮你省下大量追逐热门技术的时间把精力放回真正决定产品体验的地方。模型会换、框架会变、概念会迭代但“输入输出两端做文章”这个底层逻辑至少在未来几年内不会变。
