生成式AI设计模式全景：把不可控模型变成可控业务

生成式AI设计模式十一把“不可控的模型”变成“可控的业务”聊到生成式AI设计模式很多人第一反应是“这跟23种设计模式有什么关系”“是不是背完Java设计模式那套口诀就够用了”。我最早也是这么想的直到真正上手做了几个LLM应用才意识到这一领域的设计模式和传统面向对象的套路完全是两套逻辑——它不解决“对象怎么协作”的问题而是解决“一个概率模型怎么稳定输出”的问题。说直白点传统设计模式的底层是确定的代码生成式AI设计模式的底层是一个每次回答都可能不一样的模型我们做架构的核心目标就是用工程方式把这团“不确定”驯化成可预期、可复用的业务能力。这篇文章是这个系列的第十一篇。前几篇我们拆过提示词工程的基础手法也聊过Agent的调度骨架我原本打算顺着这个系列继续往下一个个模式细拆。但后台收到不少读者反馈说系列文章追到一半反而“只见树木不见森林”——每个单点模式都看懂了但真到自己设计一个完整系统的时候不知道该在什么环节用什么模式、模式之间怎么搭配组合。所以这一篇我临时调整了方向不急着讲新模式而是把整个“生成式AI设计模式”的版图从头到尾梳理一遍给你一张能挂墙上的全景图以及一个可以直接上手的最小工具箱。1. 先搞明白这类设计模式到底在解决什么问题1.1 一个概率模型凭什么谈“设计模式”传统设计模式之所以存在是因为我们在用类、对象、接口这些抽象来管理代码复杂度追求的是确定性——同样的输入走同样的分支返回同样的结果。但LLM应用完全不是这个逻辑大模型的输出天然带有随机性同样的提示词、同样的参数两次生成的内容可能差之千里。这就像你给一位很有才华但情绪不稳定的实习生派活他能力很强但他今天心情好不好、有没有理解你的真实需求直接决定交付质量。所以我给生成式AI设计模式下的定义一句话就能说清它是把“模型自由发挥的不可控”约束成“业务可接受的确定性”的一整套工程方法论。具体到落地这套方法论围绕三个问题展开让模型稳定输出什么输出的结构、格式、语气、长度是否符合下游系统的预期。让模型知道去哪里找什么面对超出训练数据范围的知识如何在不重新训练模型的前提下补充事实。让模型犯错成本变低当生成结果不可靠时系统如何发现、纠正、回退而不是把错误直接暴露给用户。任何一个生产级的生成式AI应用底层都是在这三个问题之间做权衡。设计模式就是权衡的惯用解法它不是万能的但它是被反复验证过的捷径。1.2 与传统23种设计模式的本质差异很多人抱着“软考设计模式速记”那样的心态来看生成式AI设计模式觉得都是“名字UML适用场景”三件套背下来就行。我理解这个惯性但必须提醒一下这两者的本体完全不同。传统设计模式的核心抽象是类和对象关注的是对象之间的职责划分与通信方式生成式AI设计模式的核心抽象是提示词、上下文和生成策略关注的是模型输入输出的编排与控制。具体差异我列了一张表维度传统设计模式生成式AI设计模式核心抽象类、对象、接口提示词、上下文窗口、生成参数、记忆追求目标代码复用、解耦、可维护输出可控、质量稳定、成本可预测不确定性可确定性建模异常是少数不确定是常态一切围绕“管理不确定”测试方式单测、集成测试可断言需要评估集、护栏、人工抽检失败代价报错、抛异常可定位修复静默错误看起来正常但内容不对理解这张表比背下十个模式名更重要。它能帮你在设计系统的时候判断自己到底在处理“传统工程问题”还是“模型不确定问题”从而决定该用哪一套方法。2. 一张全景图把生成式AI设计模式分门别类2.1 按三个层次分基础构造、组合设计、架构级模式我习惯把生成式AI设计模式分成三层从低到高分别是基础构造模式解决“怎么让单次生成更可靠”组合设计模式解决“怎么把多次生成串成完整流程”架构级模式解决“怎么把LLM接入真实业务系统”。第一层基础构造模式是你天天都在用的只是未必意识到它们是“模式”。比如提示词模板化、结构化输出约束、少样本示例注入、温度与采样参数调节这些都属于这一层。它们的特点是改动小、见效快、不涉及跨模块协作只针对单次“模型调用”。如果你刚入门先把这一层吃透性价比最高。第二层组合设计模式解决的是“一次生成搞不定”的问题。典型的有检索增强生成RAG、思维链、自一致性、反射与自校验、多智能体协作、记忆管理等。这一层的共同特征是用多次推理、多轮交互、多个组件协作来弥补单次生成能力的不足。比如RAG是把“生成”和“检索”组合反思模式是把“生成”和“评估”组合多智能体是把“多个分工模型”组合。这一层是当前业界实战的主战场。第三层架构级模式关注的是LLM如何嵌入整个软件系统。比如模型网关统一管理多个模型提供方、缓存层重复请求命中复用、人机回退置信度低时交给人工、可观测性与评估体系、渐进式交付影子模式、金丝雀发布等。这一层的模式偏工程化它们本身可能不直接调用模型但决定了LLM应用能否稳定长期运行。很多团队模型调通了但上线就崩问题往往出在这一层。2.2 按四大目标分可控性、质量、效率、复杂度除了按层次分我还会按目标维度给模式分类因为实际选型的时候你通常是从“我遇到了什么问题”出发而不是从“我知道什么模式”出发。提升可控性的模式结构化输出约束、提示词模板化、护栏设计、输出校验。这类模式的共同点是“给模型划边界”让模型在你划定的轨道内跑不跑偏、不越界。提升质量的模式少样本示例、思维链、反思与自校验、多智能体辩论、RAG知识注入。这类模式的核心是“增加有效信息”通过多轮推理、外部知识、多方校验提高生成的准确度和深度。提升效率与降成本的模式缓存复用、模型路由简单问题用便宜的小模型、难题用大模型、批量推理、渐进式生成。这类模式的本质是“把算力花在刀刃上”不让每一个请求都走最贵的那条链路。降低系统复杂度的模式Agent编排框架、消息总线、流程引擎、模型网关封装。这类模式解决的问题是“组件多了之后怎么管”让多模型、多工具、多数据源协同不变成一团乱麻。这里有一个关键认知一个模式往往同时满足多个目标。比如RAG它既提升了知识可控性也提升了回答质量还通过限制模型“自编”降低了事实错误率。所以分类是为了帮你记忆和检索而不是非此即彼的标签。2.3 贯穿所有模式的底层主线不确定性管理你可能会问这么多模式有没有一条线把它们串起来我的答案是几乎所有生成式AI设计模式都是在管理某种形式的不确定性。这也是我写这个系列以来最重要的心得。我顺着这个思路把主流模式逐一映射到“不确定性类型”上你感受一下RAG管理的是“知识不确定”当模型不知道答案时用检索把外部事实注入Agent工具调用管理的是“路径不确定”当完成一个任务有多条路线时用规划加执行去试探自校验与反思管理的是“质量不确定”当生成结果可能出错时用二次评估来兜底缓存管理的是“成本不确定”当重复请求造成浪费时用命中来拦截护栏管理的是“边界不确定”当模型可能越界生成不适内容时用规则拉回来多智能体管理的是“分工不确定”当一个复杂任务没有唯一解时用角色拆解来控制。这条主线一旦打通你对“设计模式”的理解就从背名词升级到了“为每一种不确定性找到对应的管理策略”。我再分享一个实用技巧当你接到一个LLM应用需求时先别急着选模式先问自己三个问题——这个系统最大的不确定性是什么是模型不知道答案还是模型不知道怎么回答还是模型答错了没人发现。答案出来模式基本也就出来了。这个思考顺序比从模式列表倒推更符合真实业务场景。3. 核心机制解读把握每个模式的“为什么”和“怎么用”3.1 单次生成层提示词结构、输出约束、温度控制基础构造模式里的三个动作虽然简单但它们决定了整个系统的下限。先看提示词结构。一个生产级的提示词模板通常会包含角色设定、任务说明、输入数据、约束条件、输出格式、示例这几个区块。我见过很多团队把全部信息塞进一个段落模型抓不住重点返回结果五花八门。按区块组织提示词本质上是帮模型降低阅读理解成本让它把注意力放在你真正关心的维度上。我的习惯是“约束条件单独成段落”并且用编号列出来而不是埋在叙述文字里。实测下来的效果是模型跑题率显著下降。再说输出约束。让模型返回JSON、Markdown还是纯文本这个选择看似微小实际影响巨大。如果需要下游程序解析我强烈建议明确指定输出格式并配上JSON Schema示例。这里有个经验之谈纯靠文字描述格式不如给一个“填充式”的示例模板模型对实例的遵循能力远高于对抽象描述的遵守能力。你可以把完整输出示例塞进少样本区再告诉它“严格按示例格式输出”成功率会高很多。最后说温度。温度参数控制随机性高低但很多新手误以为温度越低越好。我带项目时踩过这个坑把温度调成0结果模型在需要创意发散的环节变得呆板、重复。正确的做法是按任务类型选择事实抽取、分类、代码生成这类“确定性优先”的任务温度设0到0.3头脑风暴、文案生成、故事创作这类“多样性优先”的任务温度设0.7到1.0。这个参数选型本身就是最简单的“设计模式”。3.2 多次生成层RAG与思维链背后的协作逻辑当单次生成满足不了需求时就要引入多次生成的组合模式其中两个最高频的是RAG和思维链。RAG的核心逻辑是“先检索再生成”本质上是给模型外挂了一个可更新的知识库。它的关键不在于“要不要用向量数据库”而在于检索的质量决定了生成质量的上限。我踩过的坑是纠结用什么向量库、怎么调embedding却忽略了检索结果里混入了大量不相关段落模型被噪声带偏。现在的做法是分层检索加重排先用向量检索粗召回再用重排模型精排只把Top-K相关段落送进提示词输出质量提升非常明显。如果你不想引入重排模型可以用“关键词加向量混合检索”兜底效果也会好于纯向量。思维链模式的核心则是“让模型把推理过程显式写出来”。我刚开始不理解为什么多写几步“让我们一步一步思考”就能提升准确率后来想明白了思维链实际上是给模型一个“草稿区”让它先组织逻辑再输出答案而不是直接跳到最后结论。这对复杂推理任务特别有效。需要注意的技巧是思维链提示词要结合具体任务来写只写“一步一步思考”效果有限。好的做法是给一两步示例示范推理的颗粒度和方向。3.3 系统级保障记忆管理、缓存复用与人机协作再往上走就是系统级模式这部分决定应用能不能长期稳定运行。记忆管理是所有多轮对话应用绕不开的。很多人直接把全部历史记录塞进上下文窗口很快就满了。我常用的做法是三层记忆短期记忆只保留最近几轮对话长期记忆抽取用户的关键偏好存进向量库工作记忆保存当前会话中正在执行任务的状态。这套做法跟传统应用里的“缓存策略”很像核心思想是“用得上的才放进来”。实现上不需要多复杂的框架一个数组加一个向量库就能起步。缓存复用则是降本增效最直接的手段。一个做法是语义缓存把用户的提问经过embedding向量化在缓存里找相似度高的历史请求直接复用结果但有个坑缓存键必须兼顾语义相似度和敏感数据隔离。更简单的做法是精确匹配缓存用规范化后的原始文本做键相同问题直接返回安全性高但命中率低。我的建议是两层结合精确匹配兜底保安全语义匹配提命中但敏感场景务必禁用语义匹配。人机协作也是生产系统里极其重要的兜底模式。模型置信度低于阈值时不硬着头皮生成答案而是触发人工介入流程把“模型不确定”显式暴露成“需要人工决策”。很多团队只关注模型正答率没设计“不确定时怎么办”的机制这导致错误以其昏昏使人昭昭地流到用户端。置信度打分可以是简单的自评估也可以是分类器判断关键是你要有一个“我不会”的出口而不是让模型永远硬答。4. 生产最常用模式工具箱直接复制这套选型思路4.1 十个高频模式的适用场景与选型表讲了这么多我把目前生产项目里真正用得上、重复利用率最高的十个模式整理成一个速查表方便你做选型参考模式解决的核心问题适用场景成本量级落地优先级提示词模板化让每次生成吃同样的“药”所有标准化任务极低先做结构化输出约束让模型输出能被程序解析数据抽取、API对接极低先做多轮反思自校验让模型自己发现自己错了摘要、翻译、代码生成中多一次推理高RAG检索增强让模型知道训练数据外的事知识库问答、企业文档中高索引与检索成本高思维链推理让模型把过程想清楚再答数学、逻辑、规划中多步推理高少样本示例注入让模型准确模仿预期风格文案生成、风格迁移低占少量token高语义缓存复用让重复问题不再重复烧钱客服、高频FAQ低中模型路由让难题用大模型、简题用小模型混合负载场景低节省总成本中记忆分层管理让长对话不“失忆”又不爆窗陪伴类、助手类、Agent中高护栏与输出校验让生成内容不越过安全边界所有面向用户的场景中必做这个表是我个人项目经验的沉淀优先级排序基于“投入产出比”而非“舆论热度”。比如多轮反思它只增加一次推理调用却能显著降低幻觉率和低级错误在所有模式里性价比非常高而语义缓存虽然听起来很“智能”但它涉及语义相似度的误判风险需要配套做好数据隔离所以我把它排在中优先级。4.2 最小落地组合三个模式组成一个可用闭环如果你现在要做一个相对完整的LLM应用但又不想一次上十几个模式我推荐你从三个模式开始搭一个最小闭环第一个是提示词模板化加结构化输出把输入输出的边界先画清楚保证系统“能跑起来”第二个是输出校验加护栏对模型返回内容做规则校验字段缺失、格式错误、敏感词命中都拦截住保证系统“跑不坏”第三个是RAG或少样本注入按任务类型注入外部知识或示例保证系统“跑得准”。这三步对应的是先保能用再保安全最后保质量。我见过很多团队一上来就搞多智能体、搞复杂编排结果连输出格式都不稳定基础不牢上层建筑全是空中楼阁。先按这个最小闭环把第一个场景跑通再回头加记忆、加缓存、加路由你会明显感到每一步都有清晰的价值增量。5. 落地避坑与面试实战从能聊到能打的最后一公里5.1 五个踩坑点与规避方式这个部分算是我自己的血泪总结每一条都对应过一次线上事故或者一次返工。第一个坑是把模板当“万能咒语”。一份提示词在A场景效果好换到B场景可能一塌糊涂。规避方式是建立评估集把10到20个典型输入固定下来每改版一次模板就跑一遍回归用分数说话而不是靠感觉。第二个坑是输出校验形同虚设。很多团队只校验“非空”不校验“正确”。我推荐的校验分三层格式校验JSON能否解析、字段是否齐全、语义校验关键字段是否与输入矛盾、安全校验是否命中敏感词或违规指令。落地时先从第一层做起再逐步加强。第三个坑是RAG检索质量差却优先优化生成。生成端再调优喂进去的上下文是错的和不完整的输出天花板就锁死了。检索管线的优先级应该高于生成管线的调优先把数据清洗、切分策略、重排逻辑做好。第四个坑是无脑堆记忆。什么样的历史都往上下文里塞窗口爆掉是最直观的后果更隐蔽的问题是无关历史干扰当轮推理。建议记忆注入前做一轮相关性筛选宁可少给不要乱给。第五个坑是忽略成本监控。生成式AI的账单随着调用量增长是线性的不像传统服务器有资源复用。建议从第一天就记录每次调用的模型规格、token消耗、缓存命中率周一复盘上周成本用数据推动选型优化。我见过一个团队上线一个月后发现45%的调用是重复问题加上语义缓存后成本直接降了三成。5.2 面试官最常问的三个问题与思考框架因为热词里出现了“生成式AI”“设计模式面试题”我顺手把这一节也更新了。如果你正在准备AI应用岗位的面试以下三个问题的思考框架建议收好。第一个问题是“如何让LLM的输出稳定可控”。回答的层次感是先说清楚不稳定来自模型随机性与提示语理解波动然后给出工程手段——结构化输出约束加输出校验加多轮反思最后用评估集量化稳定性的提升。关键是别只回答“设置temperature为0”这个答案太浅了。第二个问题是“RAG和微调怎么选”。我的回答框架是知识时效性强、需要引用来源的可信回答优先RAG需要固定风格、指令遵循能力提升的优先微调两者可以结合RAG管知识、微调管行为。回答时顺带说一句“RAG不会更新模型内部的权重所以它适合动态知识不适合改变模型的推理习惯”会显得专业很多。第三个问题是“如何评估一个LLM应用上线后的质量”。思路是离线阶段建评估集跑自动指标覆盖格式准确率、事实一致性、安全性在线阶段埋点记录用户反馈与异常下游行为灰度阶段用影子模式对比新旧版本输出。核心表达是“质量评估不是上线前的一次性动作而是伴随整个生命周期的持续过程”。5.3 这个系列后续的选题方向因为这一篇是系列第十一篇我最后交代一下后面的路怎么走。我规划给“生成式AI设计模式”后续的选题方向有这样几个一是Agent设计模式的专题深化包括工具调用编排、任务规划决策、多智能体沟通协议二是评估与质量保障模式包括红队评测、自动化评估器、可观测性埋点、回归测试集构建三是成本优化模式的进阶实践比如模型路由策略、混合推理、prompt压缩四是面向行业场景的定制模式比如金融合规生成、客服多轮对话、代码辅助审查里沉淀出来的特有套路。换句话说这一篇全景梳理只是把已经出现的模式做了盘点接下来还会有更多细节等待展开。如果你有特别想看的场景也欢迎在评论区留言我会把高频需求纳入后续选题。我个人在实际项目里的体会是设计模式再多核心始终是那条主线——你能否清晰说清你的系统里“什么是确定的、什么是不确定的、你用什么机制管理这份不确定性”。想通这一条读任何模式文章都会事半功倍想不通背再多速记口诀也只是纸上谈兵。希望这一篇十—梳理能帮你把框架搭起来让后续的每一篇单点拆解都能挂在这张图上有位置安放。