生成式AI设计模式：提示策略、编排架构与反馈闭环实战解读

做生成式AI应用大半年，我从最初“prompt凑一凑就能上线”的乐观，到被线上badcase反复教育，再到慢慢沉淀出一套能复用的方法论，最大的转折点就在于：我开始用软件工程里的“设计模式”思路去重新审视LLM应用的设计。这个系列第一篇，我先不聊具体的算法调参，而是把我认为最值得先装进脑子里的三个维度的AI设计模式——提示策略、编排架构、反馈闭环——拆开讲透。如果你正在做ChatBot、Agent、RAG类项目，或者刚把大模型接进业务系统、却总感觉输出不稳定、场景一换就崩，这篇文章应该能给你一套真正可落地的思考框架。

1. 为什么生成式AI也需要自己的设计模式

1.1 从GOF到生成式AI：模式思想的一脉相承

经典软件设计模式（GOF那23种）解决的核心问题，是“对象之间如何协作才不至于把代码写成一坨”。它把反复出现的场景抽象成可复用的结构，让后来者不用每次从零开始踩坑。我一直觉得，生成式AI应用设计现在面临的问题，和当年面向对象编程刚普及时候极其相似——工具能力很强，但大多数人不知道该怎么把这种能力稳定、优雅地组合起来。

生成式AI设计模式，本质上就是对这些反复出现的组合方式做命名和提炼。它不关心某个具体的prompt技巧，而是关心更大的结构问题：模型在系统里承担什么角色？上下文怎么流动？工具调用怎么编排？错误怎么回退？结果怎么校验？这些问题的答案，经过多个项目的验证后，会形成一套类似“模板”的解法，就是我们说的AI设计模式。

1.2 没有模式的AI应用会踩哪些坑

我先列举几个自己做项目时真实遇到、也经常在同行交流里被反复提起的痛点：

• 输出不可控：同样的用户问题，早上回答正常，下午换了模型小版本就胡言乱语。没有约束和校验机制，线上事故迟早会来。
• 上下文管理混乱：对话一长就把关键指令“挤”出窗口，或者把无关历史一股脑塞进去，成本和效果双双崩盘。
• 工具调用缺乏兜底：模型在函数调用时选错参数、陷入循环，如果没有超时、重试、人工接管机制，整个流程就卡死。
• 质量评估靠感觉：改了一句prompt，感觉变好了，但没有量化对比，上线后就出问题，回滚都不知道该回到哪个版本。

这些问题的共性是：它们都不是“换个模型、改个prompt”就能解决的，而是系统结构层面的问题。设计模式这个工具，正当其时。

2. 提示策略类设计模式：先让模型把话说对

2.1 示例模式（Few-Shot）：给模型一面镜子

Few-Shot（少样本示例）可能是大多数人最先上手的模式，但真要用好它，比想象中讲究。它的核心原理是：在prompt里给出若干个“输入-输出”对，相当于给模型一面镜子，让它按照示例的格式、口吻、推理粒度来回答。

我在实际项目里的经验是，示例数量不是越多越好。对于大多数任务，3到6个高质量示例的效果就足够好，超过7到8个之后收益递减，反而会挤占上下文空间。更重要的是示例的“分布”：要覆盖典型的边界情况，而不是只挑好看的样本。比如做意图识别，示例里除了“查询订单”“申请退款”，一定要放一到两个“随口闲聊”之类的负样本，否则模型会把什么都分类成业务意图。

示例格式也很关键。同一个任务，示例之间如果格式不统一，模型就会“学坏”。建议把示例的输入输出用固定标签（比如“用户：”“助手：”）明确分隔，并保持一致。我通常会先在纯文本格式上调稳，再改成JSON等结构化输出，避免一上来就纠结复杂格式，问题定位会很困难。

2.2 思维链模式（Chain of Thought）：逼出推理过程

思维链模式（CoT）的原理一句话讲：在要求模型回答之前，先让它把推理步骤写出来。这个模式的价值已经在很多推理任务上被验证过——尤其是数学、逻辑、多跳问答这类“中间步骤决定结果”的场景。它的本质是引导模型把隐式的思考过程显性化，减少跳步带来的错误。

触发方式有两种：显式和隐式。显式就是在prompt里直接写“请一步步分析”，或者“先思考再回答”。隐式则是在示例里体现推理过程，模型会模仿这种风格。实测中，显式触发对复杂任务更稳定，但需要注意，不要让思维链变成“过度自嗨”——模型可能编造出一个看似合理的推理过程，但结论依然是错的。我的做法是：对关键结论同时要求给出依据来源或中间计算结果，方便人工校验。

使用CoT时，采样参数也要相应调整。推理类任务我一般把temperature调到0.2到0.4之间，既能保留少量多样性，又不至于让推理路径飘得太远。做创意生成类任务才需要拉高温度，这两种场景的目标函数完全不同，混用会两头不讨好。

2.3 自一致性模式（Self-Consistency）：用投票对抗随机性

如果说CoT是“把推理过程写出来”，自一致性就是更进一步：让模型多次推理，把结果汇总后投票，选最一致的答案。这个模式利用了LLM的采样随机性——单次回答可能陷入局部错误，但多次推理的共识往往更接近正确。

实操中我会用同一个prompt跑5到10次，每次temperature设置在0.4到0.7之间，让模型有一定探索空间，然后对最终答案聚类。聚类方式可以很简单：完全匹配，或者用另一个LLM判断语义等价。这里有个容易被忽略的点：投票次数不是越多越好。我测过大约10次之后，答案质量提升就开始放缓，但token成本还在线性增长。一般5到8次是性价比最优区间。

自一致性适合离线或准实时的场景，比如生成训练数据、自动批改、内容审核意见汇总。在线场景如果延迟敏感，不太建议直接用，可以用下面要讲的编排模式来降频。

3. 编排架构类设计模式：从单次对话到系统工程

3.1 检索增强生成（RAG）：让模型先查资料再开口

RAG已经是生成式AI应用的地基级模式。它的核心思路很简单：外部知识先检索，再把检索结果拼进prompt，让模型基于这些材料生成答案。直接靠模型“背”知识是不靠谱的，训练数据有截止日期，专业领域更是一问三不知，RAG就是给模型接上外部记忆。

但实现RAG的坑非常多。先说分块，块太小容易断章取义，块太大则可能混入无关信息、稀释相关性。我一般按语义完整性来切块，而不是死抠固定字数，通常200到500个token一个块比较通用，特殊文档（比如表格、法律条款）需要考虑结构边界。向量模型这块，我的建议是不要迷信“最新最强”，先用通用模型跑通链路，再根据领域数据评测后再考虑替换。检索参数里最常调的是top-k，我一般从4到8开始测，配合重排序（rerank）来提升命中率。集齐这三个参数，检索效果的优化就有抓手了。

这里要特别强调：检索质量直接决定生成质量。这个优先级的理解Project里越早越好——如果检索结果本身不相关，prompt写得再精致，模型也只能在错误材料上“无中生有”，这正是RAG项目最常见的badcase来源。

3.2 ReAct模式：让模型动起来

ReAct（Reasoning + Acting）模式，是让模型在“思考”和“行动”之间循环的架构模式：模型根据当前状态决定下一步是继续推理、还是调用工具查询信息，然后根据工具返回的观察结果更新判断，直到得出结论。这在需要实时信息、多步操作的任务里特别有用，比如查航班、订酒店、操作数据库等。

和纯CoT相比，ReAct的关键区别是“外部反馈”——推理的中间结果可以调用工具验证，而不是单纯靠模型内部的知识封闭推导。这个外部反馈极大地减少了幻觉累积的链条断裂问题，但也引入了新的复杂度：工具调用的参数格式错误、循环不终止、工具返回数据超时，都需要额外处理。

一个可参考的实现骨架大致如下：

def react_agent(query, max_steps=5): messages = [{"role": "user", "content": query}] for step in range(max_steps): resp = llm.chat(messages, tools=TOOLS) if resp.is_finish(): return resp.content # 解析工具调用 tool_name, args = parse_tool_call(resp) result = run_tool(tool_name, args) # 把结果作为“观察”塞回对话 messages.append({"role": "tool", "tool_call_id": resp.tool_call_id, "content": result}) return "达到最大步数，人工介入"

这里最关键的是max_steps设置。我在生产环境一般设置3到6步，超过即终止并转入人工。不要天真地以为模型会在几步内收敛，真实场景中工具返回了多个候选结果，模型很可能想挨个尝试一遍，必须由系统强制兜底。

3.3 计划-执行模式（Plan-and-Execute）：先想清楚再干

ReAct适合步骤交互频繁的场景，但如果你让它全程自主决策做一个大型任务，比如“分析这份财报并生成一份PPT”，模型会在中间反复试错，token消耗巨大且容易失控。计划-执行模式把过程改成两段式：先让模型生成一份完整计划（比如1到N个步骤），然后逐步执行、逐步校验。

这个模式带给我最大的好处是可控性。计划可以先展示给用户确认，用户认可后再开始执行；执行中每个步骤都有独立的输入输出，可以单独评测。代价则是灵活性下降——如果前置步骤的结果和计划预期不符，整个计划可能需要动态调整。理想的设计里，会在执行环节引入一个“再规划”的检查点，允许模型在必要时修改剩余计划。

计划-执行模式特别适合内容生产、数据分析报告、多文档处理这类“流程相对固定、但单步粒度很大”的任务。和ReAct做个粗略对比：

3.4 多智能体模式：让模型们协作

严格来说，多智能体是编排架构上更上层的一种组合模式。它的思路是让多个拥有不同角色、不同系统提示词的LLM实例分工协作。比如一个“规划者”负责拆解任务，“执行者”负责干活，“评审者”负责把关。每个智能体都有自己独立的上下文和状态，通过消息传递协作。

这种模式最直观的价值是角色隔离。评审者不会受到执行者推理路径的影响，能更客观地发现错误；执行者也不会被评审者的风格带偏。代价则是成本和延迟的成倍增加，而且多智能体之间的协调本身可能产生新的失败点。就我目前的实践经验，大多数项目用单智能体加上严格的反馈闭环就足够了，多智能体更适合“任务边界清晰、子任务之间相对独立”的场景。

4. 反馈闭环类设计模式：让模型学会自我修正

4.1 反射模式（Reflection）：自己检查自己

反射模式是让模型对自己输出的内容进行审视、批评和修正。常见做法是在第一次生成之后，附加一轮指令如“请检查你刚才的答案，找出可能的错误或不完整之处，并给出改进版本”。

这个模式在代码生成、文本润色、结构化转换等场景里效果明显。比如让模型写一个Python函数，第一版可能存在边界条件遗漏，反射一轮后往往能补上。要注意两点：一是反射目标和修改权限要限定，避免模型在“修正”时改动了原本正确的内容；二是反射不能无限递归，一般最多两轮，第三轮的收益趋近于零，还会把答案改得四不像。成本上，一轮反射约等于两次输入token，需要算清楚账。

4.2 独立评审模式（Critic）：换个“人”来挑刺

反射模式最大的隐患是“自我催眠”——模型会在自己的推理路径上越走越自信，甚至把低级错误合理化。独立评审模式的思路是引入一个独立的评审角色，让它在不看原推理过程的情况下，仅根据任务要求、原始输入和模型输出进行评判。这个评审智能体有自己的系统提示词，不受生成智能体的上下文污染。

我用这个模式做了个小实验，同一篇技术文章摘要，自我反思只改动了格式，而独立评审找出了两个关键数字的错误。原因不难理解：独立评审相当于一次“换角度重看”，它更接近读者的视角。实际落地中，可以让评审智能体输出结构化建议（错误列表、严重级别、修改建议），然后由主智能体或人工决定是否采纳。如果业务对准确率要求高，可以考虑用更强的模型做评审者，即使生成端模型较弱，整体效果也能得到明显提升。

4.3 评估驱动模式（Eval-Driven）：把prompt当代码来迭代

前面几个模式解决的是单次运行内的质量，评估驱动模式解决的是长期迭代中的“回归”问题。说白了，就是给prompt和整个Agent流程建立自动化测试集，每次改动都跑一遍分数，用数据说话。

建eval集是这里最核心也最花时间的部分。我建议从三个来源收集样本：线上真实用户问题（脱敏后）、历史badcase、模拟边界情况。第一批不需要太多，20到50条就够用了，但必须有人工标注的“标准答案”。评估方式可以有两类：一是规则判断（字段格式、关键词、可执行性），二是LLM-as-Judge让模型打分。初始阶段可以先让另一个大模型打分，但最终一定要抽一部分人工复核，防止评估器本身有偏好。

一旦跑通这套流程，再改prompt或者换模型版本时就不会两眼一抹黑。我在自己项目里把这套东西简称为“Prompt的CI/CD”——改动前先跑基线记录分数，改动后再跑同一套集合并对比。这个习惯，让我至少避免了三次上线后才发现效果倒退的事故。

5. 实战案例：把三种模式组合起来的客服问答Agent

纸上谈兵多了容易飘，我拿一个实际做过的客服问答Agent来串一遍。这个系统同时使用了RAG、ReAct和评估驱动三类模式，算是比较典型的结构。

任务背景：某SaaS产品需要做一个客服机器人，覆盖产品使用问答、账号问题、工单创建三类需求，且要求最终可以无缝转接人工。

整体架构简化为四层：

1. 入口意图分类：先用一个低温度（0.1）的轻量分类调用，把用户输入分为“问答咨询”“账号操作”“闲聊”三类。这一步成本低，能有效防止后续高成本流程被无关对话触发。
2. RAG主链路：对于问答咨询，走检索增强生成。知识库切块约300 token，向量检索取top-8，加一轮重排序后保留top-4。这一步确保回答能定位到正确文档。
3. ReAct工具链路：对于账号操作，走多步工具调用。提供查订单、查账号状态两个工具，max_steps设为4，超时转人工。
4. 反馈闭环：对所有生成结果，统一过一次“答案校验”。校验规则包括：是否引用了知识库片段、答案长度是否合理、是否包含兜底联系方式。不满足则强制进入人工会话。
5. 上线后，把每周badcase沉淀到eval集，跑回归对比，再决定下一轮优化方向。

这个案例里，三个维度的模式各司其职：提示策略让每一步的模型输出更稳定，编排架构把不同任务分派到合适的流程里，反馈闭环保证整体质量可控。想表达的核心观点是：设计模式不是某一个神奇模板，而是一套系统性的取舍方法。真正难的不是知道这些模式，而是知道什么场景该组合它们、如何设置参数。

6. 常见问题与排查技巧实录

6.1 思维链模式下模型输出又长又啰嗦

这个几乎是必然遇到的。一旦prompt里写了“请一步步分析”，模型会有可能对简单问题也写出几百字的推理过程，既浪费token又影响体验。我的做法是：在prompt里明确“只输出关键步骤，不要解释无关细节”，必要时限制输出长度，最终答案通过后处理截断。更稳妥的办法是让模型先输出JSON结构，其中包含“reasoning”和“answer”两个字段，再由系统层决定是否展示推理部分。

6.2 RAG检索不到关键内容，答案质量上不去

大多数情况不是模型问题，而是检索链路问题。可以按顺序排查：先看分块是否把关键信息切断了；再看embedding模型在领域数据上的表现；再看top-k是否太小、重排序是否引入偏差。我遇到过的最隐蔽问题是：用户问题的说法和知识库原文差异很大，向量检索召回率看似还行，但关键片段排序太靠后，被top-k截掉了。解法是增加一个“关键词-语义”混合检索，或者把top-k调大后模型压不过噪音。这种问题靠Prompt很难解决，必须回到检索侧修。

6.3 ReAct循环不终止，工具调用反复失败

先说系统侧兜底：max_steps和超时一定要配。脚本里很容易只配了max_steps而忽略工具本身的超时时间，结果工具接口卡住，整个循环挂在那。再说模型侧调试：工具描述要写得像函数文档一样严格，参数名、类型、约束、示例都要写清楚。还有一个容易被忽略的坑，模型在工具返回内容为空时会反复调用同一个工具，需要在工具描述里说明“无结果时不要重复查询，直接告知用户未查到”。

6.4 Prompt多次修改后效果忽好忽坏

几乎每个做LLM应用的团队都会遇到这个问题。症状是：你改了一个细节，A场景效果变好，B场景却变差了，但你完全没意识到，因为B场景没有在你的验收清单里。解法就是我前面说的评估驱动模式，把改动前和改动后的版本都跑一遍固定eval集，对比各项指标。没有这个机制，所有的prompt优化都像是蒙眼在迷宫里走路。

结尾

说了这么多，我在实际操作中最大的体会是：生成式AI设计模式不是什么高深理论，它就是把工程中反复出现的问题和最优解沉淀下来，让后来者能站在前人的肩膀上。但也不要神话它，每个模式都有自己的适用边界和代价，组合使用、动态取舍才是常态。我自己的习惯是：拿到一个需求，先明确任务边界和用户最不能接受的问题，再从提示策略、编排架构、反馈闭环三个维度去挑合适的模式，然后小步快跑地迭代验证。最后再分享一个小技巧：把每个模式的关键参数（温度、示例数、步数、top-k）做成一个可配置的清单，每次上线前都过一遍，能帮你少踩不少无谓的坑。这套方法论我还在持续完善，后续会把更多模式细节和项目实战拆开来聊。