1. 大模型三层架构到底在拆什么1.1 从一个常见困惑说起很多人第一次接触大模型应用开发时都会有一种“眼花缭乱”的感觉。今天看到有人用大模型做知识库问答明天看到有人用它做自动化报告生成后天又看到有人用它做多轮对话客服再往后还有代码补全、文档摘要、意图识别、数据抽取、角色扮演、流程编排。表面上看这些应用形态差异极大甚至像是完全不同的产品方向但真正拆开看会发现它们大多数都落在同一套底层结构里。这套结构我习惯把它叫做“大模型三层架构”。它不是某个官方标准也不是某个框架强制规定的分层方式而是我在实际做项目时总结出来的一种理解模型应用的方法。它的核心判断非常直接所有 AI 新花样本质上只在两个地方发生变化一个是“输入什么”另一个是“输出怎么处理”。这句话听起来有点绝对但实际项目做多了会发现它非常接近真相。模型本身的能力边界当然重要参数规模、训练数据、推理成本、上下文长度、工具调用能力都会影响最终效果可是当我们讨论一个具体 AI 应用为什么好用、为什么不好用、为什么贵、为什么慢、为什么不稳定时问题往往不在模型本身而在输入构造和输出处理上。举个很常见的例子。同样是做“合同信息抽取”有人效果很好有人效果很差。差的那一方可能会说“模型不行”但实际排查后经常发现问题出在输入里塞了太多无关条款或者没有告诉模型要抽取哪些字段或者输出后没有做结构化校验。模型还是那个模型输入和输出处理一变结果就完全不同。所以三层架构的价值不在于把系统画得很复杂而在于帮助我们快速定位问题。你可以把它理解成一条流水线第一层负责把现实世界的信息变成模型能吃的输入第二层负责模型推理第三层负责把模型吐出来的内容变成业务能用的结果。大多数创新其实都发生在第一层和第三层。1.2 三层架构的基本划分为了后面讲得更清楚我先把这三层定义一下。不同团队可能有不同叫法但核心逻辑一致。层级名称主要职责常见技术点第一层输入构造层把用户需求、业务数据、上下文、工具结果组织成模型可理解的输入提示词模板、上下文拼接、检索增强、历史压缩、多模态输入第二层模型推理层调用大模型完成理解、生成、推理、规划、工具选择等模型选型、参数配置、推理策略、多模型路由、缓存第三层输出处理层把模型输出转成业务可用结果并做校验、修复、渲染、执行结构化解析、格式校验、结果重排、敏感过滤、自动重试这个划分看起来简单但真正有价值的是它背后的判断第二层通常变化最慢第一层和第三层变化最快。模型升级可能几个月一次但输入构造和输出处理的优化可以每天做。很多团队把大量精力花在“换更强模型”上却忽略了输入和输出层才是最容易产生业务收益的地方。我见过一个很典型的项目早期用大模型做工单分类准确率一直上不去。团队第一反应是换模型从一个小模型换到更大的模型成本翻了几倍准确率只提升了一点点。后来重新梳理输入把工单标题、用户描述、历史处理记录、产品模块、优先级字段按固定结构拼进去同时把输出限制为固定类别并增加低置信度转人工规则准确率直接上了一个台阶。模型没换效果却好了很多。这就是三层架构拆解的意义它让你知道该在哪里使劲。1.3 为什么说新花样主要集中在输入和输出大模型本身的能力可以粗略理解为“根据输入预测输出”。它像一个非常擅长模式匹配和语言生成的引擎但它不知道你的业务规则不知道你的数据库结构不知道你希望输出什么格式也不知道结果该怎么用。它只能根据你给它的输入生成它认为合理的输出。所以当我们要让大模型完成一个具体任务时真正的工作量往往不在模型内部而在模型外面。你需要告诉它什么你需要它返回什么你拿到返回后怎么用这三件事决定了应用的上限。比如“让大模型写周报”这个需求。模型本身当然会写周报但如果你只输入“帮我写周报”它只能编。如果你输入本周完成事项、遇到的问题、下周计划、项目背景、汇报对象、语气要求它就能写得像样。如果你再要求它输出固定格式并且自动检查是否遗漏关键字段它就能直接进入业务系统。这里的变化全部发生在输入和输出层。再比如“让大模型做客服”。模型可以回答用户问题但如果没有输入订单信息、产品知识、历史对话、用户情绪它就容易答非所问。如果输出后不做敏感词过滤、不判断是否需要转人工、不记录会话状态它就无法真正上线。这些也都是输入和输出层的工作。所以当你看到一个 AI 新应用时不要先被它的名字吓到。你可以问三个问题它的输入是什么它的输出怎么处理它中间用了什么模型大多数情况下前两个问题才是关键。2. 第一层输入构造层决定模型看到什么2.1 输入构造层的核心任务输入构造层的任务是把现实世界里的信息整理成模型能够理解并且有利于完成任务的形式。它要解决的不是“模型会不会”而是“模型知不知道”。模型不知道你的业务背景不知道你的数据格式不知道你的约束条件所以你需要通过输入把这些信息补进去。这一层通常包含几个关键动作任务定义、上下文选择、信息压缩、格式组织、示例注入、工具结果拼接。每一个动作都会直接影响模型输出质量。任务定义是第一步。你要用清晰的语言告诉模型它要做什么。比如“请判断以下文本的情感倾向”就比“看看这段话”好得多。任务定义越明确模型越不容易跑偏。上下文选择是第二步。大模型有上下文长度限制你不能把所有信息都塞进去。你需要判断哪些信息对当前任务有用哪些是噪声。比如做知识库问答时检索回来的文档可能有很多段但真正相关的可能只有一两段。选错了模型就会被误导。信息压缩是第三步。当上下文太长时你需要做摘要、截断、重排或者分层组织。比如多轮对话历史太长你可以保留最近几轮再把更早的历史压缩成摘要。这样既保留关键信息又不会超出限制。格式组织是第四步。同样的信息用不同格式呈现模型理解效果可能不同。结构化字段、Markdown 表格、JSON、编号列表各有适用场景。一般来说需要模型精确处理的内容用结构化格式更好需要模型理解语义的内容用自然语言更好。示例注入是第五步。也就是常说的少样本提示。给模型几个输入输出示例它更容易模仿格式和风格。示例的质量比数量更重要错误示例会把模型带偏。工具结果拼接是第六步。当模型需要调用外部工具时工具返回的结果也要作为输入的一部分。比如查询天气、搜索知识库、读取数据库这些结果怎么拼进提示词直接影响模型下一步推理。2.2 输入构造的常见模式在实际项目中输入构造有几种常见模式每种模式适合不同场景。第一种是直接拼接模式。把用户输入、系统提示、历史对话简单拼在一起。这种模式实现简单适合轻量场景比如简单问答、文本改写。但它的缺点是上下文容易混乱信息多了以后模型抓不住重点。第二种是模板填充模式。预先定义好提示词模板把变量填进去。比如你是一个客服助手。请根据以下信息回答用户问题。 用户问题{question} 订单状态{order_status} 产品名称{product_name} 历史对话{history} 要求 1. 只根据给定信息回答不要编造。 2. 如果信息不足请说明需要补充什么。 3. 回答控制在 100 字以内。这种模式适合业务规则明确的场景比如客服、工单分类、信息抽取。模板可以版本化管理方便迭代。第三种是检索增强模式。先从知识库、数据库、文档中检索相关内容再把检索结果和用户问题一起送给模型。这种模式适合知识问答、文档助手、企业搜索。它的关键是检索质量检索不准模型再强也没用。第四种是多轮记忆模式。把历史对话按一定策略组织起来比如最近 N 轮完整保留更早的做摘要。这种模式适合对话机器人、陪伴类应用、多轮任务办理。它的难点是记忆压缩和关键信息保留。第五种是多模态输入模式。除了文本还输入图片、表格、音频转写文本等。这种模式适合文档理解、图像问答、会议纪要。它的关键是不同模态信息的对齐和融合。这几种模式不是互斥的实际项目里经常组合使用。比如一个企业知识助手可能同时用模板填充、检索增强和多轮记忆。2.3 输入构造的实操要点输入构造看起来只是“拼提示词”但实际做起来有很多细节。以下是我踩过坑之后总结的几个要点。第一任务指令要放在显眼位置。模型对开头和结尾的内容通常更敏感。如果你把关键指令埋在中间模型可能忽略。所以系统提示、任务要求、输出格式这些关键信息最好放在输入的开头或结尾。第二信息要有层次。不要把所有内容混在一起。可以用分隔符、标题、编号来区分不同部分。比如【任务】 请从以下文本中抽取公司名称、金额、日期。 【文本】 ... 【输出格式】 JSON字段为 company、amount、date。这种层次感能帮助模型快速定位信息。第三示例要精选。少样本提示里示例不是越多越好。一般来说3 到 5 个高质量示例就够。示例要覆盖典型情况也要覆盖边界情况。如果示例里有错误模型会学错。第四上下文要控制长度。不要觉得塞得越多越好。无关信息会稀释关键信息增加模型困惑。我通常会把上下文控制在模型上限的 50% 到 70%留出空间给输出和推理。第五要处理冲突信息。如果输入里有矛盾内容模型可能随机选一个。你需要提前解决冲突或者在提示词里说明优先级。比如“如果知识库和用户描述冲突以知识库为准”。第六要保留原始信息。压缩和摘要会丢信息所以关键字段最好保留原文。比如金额、日期、编号这些不要摘要直接原样传入。第七要做输入校验。用户输入可能为空、超长、包含特殊字符、包含注入指令。输入层要做基本清洗和校验避免模型被恶意输入带偏。提示输入构造层的优化往往比换模型更划算。每次模型效果不好时先检查输入是否清晰、完整、无歧义再考虑换模型。2.4 一个输入构造的完整案例假设我们要做一个“会议纪要生成”功能。用户上传一段会议转写文本系统输出结构化会议纪要包括议题、结论、待办事项、负责人、截止时间。输入构造层可以这样设计你是一个会议纪要助手。请根据以下会议转写文本生成结构化会议纪要。 【会议背景】 会议主题{meeting_topic} 参会人员{participants} 会议时间{meeting_time} 【转写文本】 {transcript} 【输出要求】 请输出 JSON包含以下字段 - topics议题列表每个议题包含 title 和 summary - decisions结论列表 - action_items待办列表每项包含 task、owner、deadline - risks风险或待确认事项 要求 1. 只根据转写文本内容生成不要编造。 2. 如果某项信息缺失填写“未明确”。 3. 待办事项要尽量提取负责人和截止时间。 4. 输出必须是合法 JSON不要添加额外解释。这个输入构造里任务定义、背景信息、原始文本、输出格式、约束条件都很清楚。模型拿到这样的输入生成质量会明显高于只给一段转写文本。如果转写文本很长还需要做分段处理。可以按议题切分每段单独生成摘要最后再合并。也可以先让模型识别议题边界再分别处理。这些都是输入构造层的工作。3. 第二层模型推理层到底该怎么选和怎么用3.1 模型选型的核心考量模型推理层是大家最熟悉的一层因为它直接涉及“用哪个模型”。但模型选型不是简单地选最大最强的而是要综合考虑任务难度、成本、延迟、稳定性、数据合规、部署方式等因素。任务难度是第一个考量。简单任务比如文本分类、格式转换、关键词抽取小模型往往就够用。复杂任务比如多步推理、代码生成、长文档理解可能需要更强的模型。我的经验是先用小模型试效果不够再升级。不要一上来就用最贵的模型否则成本很难控制。成本是第二个考量。大模型调用通常按输入和输出 token 计费。输入越长、输出越多成本越高。如果一个任务每天调用几十万次单次成本差一点总成本差距就很大。所以模型选型要算账。延迟是第三个考量。有些场景对响应速度要求高比如实时客服、语音助手、在线搜索。大模型推理慢用户体验就差。这时候可能需要小模型、缓存、流式输出、并行调用等手段。稳定性是第四个考量。模型服务可能限流、超时、返回异常。生产系统要考虑重试、降级、熔断。不能把业务完全绑在一个模型上。数据合规是第五个考量。有些数据不能出内网那就需要私有化部署或本地模型。有些场景对数据留存有要求那就需要选择符合要求的服务方式。部署方式是第六个考量。API 调用最省事但可控性差。私有化部署可控性强但运维成本高。混合部署可以兼顾但架构复杂。3.2 推理参数怎么调模型推理时有一堆参数可以调比如温度、top_p、最大输出长度、重复惩罚、停止词等。这些参数直接影响输出风格和稳定性。温度控制随机性。温度低输出更确定、更保守温度高输出更多样、更有创意。做信息抽取、分类、代码生成时温度通常设低比如 0 到 0.3。做创意写作、头脑风暴时温度可以设高比如 0.7 到 1.0。top_p 控制采样范围。它和温度类似但机制不同。一般来说调一个就行不要同时大调。我通常固定 top_p 为 0.9 左右然后调温度。最大输出长度要设合理。设太短输出被截断设太长浪费成本还可能让模型啰嗦。根据任务预估输出长度留一定余量。重复惩罚用于减少重复内容。但设太高可能导致输出不自然。一般 1.0 到 1.2 之间比较安全。停止词用于让模型在特定位置停止。比如输出 JSON 时可以设置停止词为特定标记避免模型继续生成无关内容。这些参数没有万能值需要根据任务实测。建议做一个小型评测集固定输入调不同参数看输出质量。不要凭感觉调。3.3 多模型路由与降级策略生产系统里单一模型往往不够。不同任务适合不同模型不同时段模型服务状态也不同。所以多模型路由和降级策略很重要。多模型路由可以按任务类型路由。比如简单分类走小模型复杂推理走大模型代码任务走代码专用模型。也可以按用户等级路由付费用户走更强模型免费用户走轻量模型。降级策略用于应对异常。比如主模型超时自动切到备用模型主模型限流排队或切到轻量模型模型输出质量差触发重试或转人工。我做过一个项目主模型偶尔会返回空结果。后来加了一个规则如果输出为空或格式错误自动用备用模型重试一次如果还失败返回兜底话术并记录日志。这样系统稳定性提升很多。3.4 缓存与批处理大模型调用成本高延迟也高。缓存和批处理是两个有效的优化手段。缓存适用于重复请求。比如很多用户问同样的问题或者同一段文本被多次处理。可以把输入哈希后作为 key输出作为 value 缓存起来。下次同样输入直接返回缓存结果。缓存要注意失效策略比如知识库更新后相关缓存要清除。批处理适用于离线任务。比如批量生成摘要、批量分类、批量抽取。可以把多个请求合并成一个批次一次调用处理多条。这样能提高吞吐降低成本。但批处理要注意单条失败不影响整批以及输出顺序对应。3.5 模型推理层的常见误区第一个误区是“模型越大越好”。实际上很多任务小模型足够大模型反而慢且贵。选型要看任务不要盲目追大。第二个误区是“提示词万能”。提示词很重要但它不能解决所有问题。如果任务本身需要外部知识就要做检索如果需要精确计算就要用工具如果需要严格格式就要做输出校验。第三个误区是“一次调用解决所有问题”。复杂任务往往需要拆解成多步每步调用模型或工具。一次调用让模型做太多事容易出错。第四个误区是“忽略成本”。模型调用成本会随规模增长。早期不觉得量大了以后成本很吓人。所以从一开始就要关注 token 消耗做优化。第五个误区是“不做评测”。模型效果不能凭感觉。要建立评测集定期跑分对比不同模型、不同提示词、不同参数的效果。没有评测优化就是盲人摸象。4. 第三层输出处理层才是业务落地的关键4.1 输出处理层的核心任务模型输出通常是一段文本。但业务系统需要的是结构化数据、可执行动作、可展示内容。所以输出处理层的任务就是把模型输出转成业务可用的结果。这一层通常包含几个关键动作解析、校验、修复、重排、过滤、渲染、执行。解析是把文本转成结构化数据。比如模型输出 JSON你要解析成对象模型输出 Markdown 表格你要解析成行和列模型输出自然语言你可能要用规则或小模型抽取字段。校验是检查输出是否符合要求。比如 JSON 是否合法字段是否齐全类型是否正确值是否在允许范围内。校验不通过就要处理。修复是对不合格输出做补救。比如 JSON 缺字段可以补默认值格式错误可以重新调用模型修复内容不完整可以触发重试。重排是对多个输出排序。比如检索增强生成时模型可能生成多个候选答案你需要按相关性、置信度、业务规则排序。过滤是去掉不合适内容。比如敏感词、违规内容、无关信息、重复内容。过滤规则可以基于关键词、正则、分类模型。渲染是把结果转成展示形式。比如生成 HTML、Markdown、图表、语音。渲染要考虑用户体验和终端适配。执行是把结果转成动作。比如调用 API、写入数据库、发送消息、创建工单。执行要考虑幂等、事务、失败重试。4.2 结构化输出的实现方式结构化输出是输出处理层最常见的需求。业务系统通常不喜欢自然语言而喜欢 JSON、表格、枚举值。让模型输出结构化内容有几种常见方式。第一种是提示词约束。在提示词里明确要求输出 JSON并给出 schema。比如请输出 JSON格式如下 { category: 类别, confidence: 0.0 到 1.0, reason: 简要理由 }这种方式简单但模型不一定严格遵守。可能多输出解释可能字段名不对可能 JSON 不合法。第二种是少样本示例。给几个输入输出示例让模型模仿。这种方式比单纯约束效果好但示例要精选。第三种是结构化输出功能。有些模型服务提供 JSON 模式或 schema 约束能强制输出合法 JSON。这种方式最可靠但依赖模型服务支持。第四种是输出后解析修复。不管模型怎么输出都用解析器提取 JSON。如果解析失败用正则或小模型修复。这种方式最通用但需要写不少处理逻辑。第五种是多轮校验。先让模型输出再让另一个模型或规则校验不合格就重新生成。这种方式质量高但成本也高。实际项目里我通常组合使用提示词约束加少样本示例再加输出后解析修复。如果模型服务支持结构化输出就优先用。4.3 输出校验与自动修复输出校验是保证系统稳定的关键。没有校验模型偶尔的胡言乱语就会直接进入业务系统造成事故。校验可以分为几层。第一层是格式校验检查 JSON 是否合法、字段是否存在、类型是否正确。第二层是范围校验检查值是否在允许范围内比如分类是否在枚举里金额是否为正数。第三层是业务校验检查是否符合业务规则比如日期不能早于今天负责人必须在员工列表里。第四层是一致性校验检查多个字段之间是否矛盾比如开始时间不能晚于结束时间。校验不通过时有几种处理方式。一种是自动修复比如补默认值、截断超长字段、修正格式。一种是重新生成把错误信息拼回提示词让模型重新输出。一种是降级处理返回兜底结果或转人工。一种是记录日志供后续分析。自动修复要小心不能把错误数据修成看似正确的错误数据。比如模型输出金额为“未知”你自动修复为 0可能导致业务错误。所以修复规则要明确不确定的就不要修。4.4 输出过滤与安全输出过滤是很多应用上线前的必备环节。模型可能生成不合适内容包括敏感信息、歧视性语言、虚假信息、侵权内容。过滤层要尽量拦住这些内容。过滤可以在几个层面做。输入层过滤用户输入避免恶意提示。模型层用安全提示词约束模型行为。输出层用规则和模型双重过滤。规则过滤可以用关键词、正则、黑名单。这种方式快但容易漏。模型过滤可以用分类模型判断内容是否安全。这种方式准但慢且贵。实际项目里通常组合使用先规则快速拦截再模型精细判断。除了安全过滤还有业务过滤。比如去掉重复内容、去掉无关段落、去掉模型自我评价、去掉多余解释。这些过滤能提升输出质量。4.5 输出处理层的实操案例回到会议纪要的例子。模型输出可能是这样的{ topics: [ {title: 项目进度, summary: 当前进度符合预期} ], decisions: [下周完成测试], action_items: [ {task: 完成测试报告, owner: 未明确, deadline: 下周五} ], risks: [测试资源不足] }输出处理层要做几件事。第一解析 JSON如果失败就尝试修复。第二校验字段检查 topics、decisions、action_items、risks 是否存在且类型正确。第三业务校验检查 owner 是否在员工列表里deadline 是否是合法日期。第四如果 owner 未明确可以触发一个补充流程让用户指定负责人。第五把结果渲染成 Markdown 或 HTML展示给用户。第六把待办事项写入任务系统并发送提醒。这一层的工作量往往比输入层还大但它决定了系统能不能真正用起来。5. 三层架构的联动与常见问题排查5.1 三层如何联动三层架构不是孤立的。输入层影响模型层模型层影响输出层输出层的问题也可能需要回到输入层解决。比如输出格式总是不对可能是输入层没有说清楚格式要求。输出内容有幻觉可能是输入层没有提供足够知识或者模型层温度太高。输出太慢可能是输入太长导致推理慢或者模型选得太大。输出成本太高可能是输入冗余太多或者输出太长。所以排查问题时不要只盯着模型层。要沿着三层逐层检查。5.2 常见问题速查表问题现象可能原因排查方向解决思路输出格式不对输入未明确格式模型不遵守检查提示词、示例、模型结构化输出支持加格式约束、加示例、用结构化输出、输出后修复输出内容编造输入缺少知识模型自由发挥检查是否提供足够上下文温度是否过高加检索、加约束、降温度、要求引用来源输出太慢输入太长模型太大并发高检查 token 数、模型选型、调用量压缩输入、换小模型、加缓存、批处理输出成本高输入冗余输出啰嗦调用频繁检查 token 消耗、调用次数精简输入、限制输出、缓存、路由输出不稳定温度高提示词模糊模型波动检查参数、提示词、评测集降温度、明确提示词、固定种子、多模型对比输出被截断最大输出长度不够检查输出长度设置调大最大输出长度或分段生成输出重复重复惩罚低提示词要求重复检查重复惩罚、提示词调高重复惩罚优化提示词输出敏感内容过滤不足提示词约束弱检查过滤规则、安全提示词加强过滤、加安全提示、人工审核5.3 独家避坑技巧第一个技巧是先做评测集再优化。不要凭感觉调提示词。先收集几十条典型输入人工标注期望输出形成评测集。每次改动后跑评测看指标变化。这样优化才有方向。第二个技巧是输入输出都留日志。生产系统要记录每次调用的输入、输出、参数、耗时、成本。出问题时可以回溯。日志要注意脱敏避免泄露敏感信息。第三个技巧是小步快跑。不要一次改太多。每次只改一个变量观察效果。比如先改提示词再调温度再换模型。这样能知道哪个改动有效。第四个技巧是准备兜底方案。模型可能失败输出可能不合格。要有兜底话术、转人工、默认值、缓存结果。不要让用户看到错误页面。第五个技巧是关注长尾。平均效果好不代表没问题。要看最差的那些案例往往长尾案例暴露了系统的根本缺陷。第六个技巧是定期回归测试。模型服务可能更新提示词可能改动业务规则可能变化。定期跑评测集确保效果没有退化。5.4 一个完整的排查实例假设一个知识库问答系统上线后用户反馈“回答不准确”。怎么排查先看输入层。检索回来的文档是否相关如果检索不准模型再强也没用。检查检索策略、关键词、向量模型、召回数量。如果检索结果里有正确答案但模型没用到检查提示词是否要求模型优先使用检索内容。再看模型层。模型是否适合这个任务温度是否太高上下文是否太长导致关键信息被淹没可以换模型对比调温度压缩上下文。最后看输出层。模型输出是否被正确解析是否有过滤规则误删了正确答案是否有渲染问题导致用户看不到关键内容逐层排查后往往能定位到具体原因。可能是检索召回不够可能是提示词没强调引用可能是输出过滤太激进。找到原因后针对性优化。6. 从三层架构看 AI 应用的扩展方向6.1 输入层的扩展空间输入层的扩展空间非常大。除了文本还可以接入更多数据源比如数据库、API、文件、图像、音频、视频。可以做更智能的检索比如混合检索、多跳检索、图检索。可以做更精细的上下文管理比如动态压缩、重要性排序、记忆分层。可以做更个性化的输入构造比如根据用户画像、历史行为、当前场景调整提示词。输入层的创新往往能带来最直接的效果提升。因为模型能力短期内变化不大但输入质量可以持续优化。6.2 输出层的扩展空间输出层的扩展空间同样大。除了结构化解析还可以做自动执行比如调用工具、创建任务、发送通知。可以做多模态输出比如生成图表、语音、视频。可以做交互式输出比如让用户确认、修改、补充。可以做自适应输出根据用户反馈调整后续输出。输出层是离业务最近的一层也是最能体现产品差异的一层。同样的模型输出处理做得好用户体验就好很多。6.3 模型层的扩展空间模型层虽然变化慢但也有扩展空间。比如多模型协作让不同模型分别负责不同子任务。比如模型微调用领域数据提升特定任务效果。比如模型蒸馏把小模型训练得接近大模型效果。比如模型编排把多个模型调用组织成工作流。模型层的优化通常成本较高周期较长但一旦做好能形成技术壁垒。6.4 三层架构的通用性这套三层架构不仅适用于文本应用也适用于多模态应用、Agent 应用、自动化流程。输入层负责感知和上下文模型层负责推理和决策输出层负责行动和反馈。任何 AI 应用都可以用这个框架来分析。当你看到一个新技术、新产品时可以用三层架构快速拆解它的输入有什么特别它的模型用了什么它的输出怎么处理这样你就能快速理解它的核心价值而不是被表面概念迷惑。7. 个人实操体会我做 AI 应用这几年最大的体会是不要神化模型也不要低估工程。模型很重要但模型只是三层架构中的一层。真正决定应用成败的往往是输入构造和输出处理这些“脏活累活”。很多团队喜欢追新模型、新框架、新概念但实际落地时卡住他们的往往是提示词没写好、检索不准、输出没校验、异常没处理。这些问题不解决换再多模型也没用。反过来有些团队模型用得不算先进但输入构造做得很细输出处理做得很稳系统上线后效果很好用户也很满意。这就是工程的价值。如果你正在做 AI 应用我的建议是先把三层架构画出来明确每层做什么。然后从输入层和输出层开始优化这两层投入产出比最高。模型层保持关注但不要频繁更换除非有明确证据表明当前模型是瓶颈。最后分享一个小技巧每次遇到效果问题先问自己三个问题。模型看到了什么模型输出了什么输出后发生了什么把这三个问题回答清楚大部分问题都能定位。这个习惯帮我省了很多排查时间也让我对系统理解更深。