1. 生成式AI设计模式到底在解决什么问题1.1 从传统设计模式到AI设计模式的思维转变聊生成式AI设计模式之前得先把一个误区掰开很多人一听“设计模式”四个字脑子里立刻浮现的是Java那23种经典模式——单例、工厂、观察者、策略。这些模式解决的是代码结构复用的问题核心诉求是让代码可维护、可扩展。但生成式AI设计模式面对的问题域完全不同它解决的是如何组织与大模型之间的交互流程让输出稳定、可控、可复用。我打个比方。传统设计模式像是建筑行业的标准化构件——门窗尺寸统一、承重梁规格固定你按图纸拼装就行。而生成式AI设计模式更像是导演和演员之间的工作方法——你不能直接命令演员“演一个悲伤的角色”你得给他剧本、情境、情绪记忆甚至示范一遍他才能给出你想要的那条镜头。这个“怎么给指令、怎么给上下文、怎么验证输出”的方法论就是生成式AI设计模式的核心。为什么这件事值得单独拎出来讲因为在实际项目里我见过太多团队把大模型当成一个“万能函数”来调用——输入一段文字期望输出完美结果。结果就是同一个需求今天跑出来能用明天跑出来就胡言乱语换个模型版本之前调好的提示词全部失效。这不是模型的问题是交互架构的问题。设计模式要做的就是把这些不稳定的交互变成可预期、可测试、可迭代的工程流程。1.2 核心设计模式的分类框架我把目前实际项目中验证有效的生成式AI设计模式分成四大类这个分类不是学术上的严格划分而是按“你遇到什么问题就翻哪个工具箱”的实用逻辑来组织的。第一类是输入构造模式解决的是“怎么把需求翻译成模型能理解的输入”。典型的有角色设定模式、少样本示例模式、思维链引导模式。第二类是输出控制模式解决的是“怎么让输出符合格式和内容要求”包括结构化输出模式、约束解码模式、自洽性校验模式。第三类是流程编排模式解决的是“多个步骤怎么串起来”比如链式调用模式、路由分发模式、并行聚合模式。第四类是质量保障模式解决的是“怎么知道输出是对的”涵盖评估器模式、反思迭代模式、人工介入模式。这四类模式不是孤立的实际项目里往往是组合使用。比如一个合同审核系统输入构造阶段用角色设定加少样本示例输出控制阶段用结构化输出流程编排阶段用链式调用质量保障阶段用评估器加人工复核。每个模式解决一个特定环节的问题组合起来才构成完整的工程方案。注意不要试图用一个“超级提示词”解决所有问题。我踩过这个坑——把角色设定、格式要求、示例、约束条件全部塞进一段提示词里结果模型顾此失彼格式对了内容跑偏内容对了格式又乱。拆成多个模式分步处理反而更稳定。1.3 为什么现在必须重视这套方法论有个数据值得琢磨在实际生产环境中未经设计模式优化的提示词输出合格率通常在60%到70%之间波动。而经过系统化设计模式改造后合格率能稳定在90%以上。这20多个百分点的差距就是设计模式的价值。更关键的是可维护性。没有设计模式意识的团队提示词散落在代码各处改一个需求要翻遍整个项目找相关提示词改完还不确定会不会影响其他功能。而采用设计模式后每个模式的实现是独立的、可测试的、可替换的。换模型版本时只需要调整输入构造模式中的适配层下游的输出控制和流程编排完全不受影响。这套方法论适合谁我认为三类人最需要一是正在把AI能力集成到产品中的工程师你需要它来保证系统的稳定性二是负责AI应用架构的技术负责人你需要它来设计可扩展的方案三是对AI应用开发感兴趣但总觉得自己“调不好”提示词的开发者你需要它来建立系统化的思维框架。2. 输入构造模式让模型准确理解你的意图2.1 角色设定模式的正确打开方式角色设定模式听起来简单——不就是告诉模型“你是一个律师”或者“你是一个资深编辑”吗但实际效果差异巨大。我做过对比测试同样是让模型审核一段合同条款三种角色设定的输出质量完全不同。第一种是简单角色“你是一个律师。”输出结果泛泛而谈经常给出“建议咨询专业律师”这种废话。第二种是具体角色“你是一个有十年经验的商事合同律师擅长识别条款中的风险点。”输出开始有针对性能指出具体的风险条款。第三种是角色加场景加目标“你是一个有十年经验的商事合同律师现在代表买方审核一份设备采购合同你的目标是识别对买方不利的条款并给出修改建议。”这种设定下模型输出的专业度和针对性明显提升。为什么会有这种差异因为角色设定本质上是在缩小模型的输出空间。大模型的参数空间极其庞大不加约束时它会从所有可能的回答中采样。角色设定相当于给模型一个“概率聚焦透镜”把输出概率集中到与角色匹配的区域。角色越具体、场景越明确、目标越清晰聚焦效果越好。实操中我总结了一个角色设定的四要素模板身份 经验 场景 目标。身份解决“你是谁”经验解决“你有多专业”场景解决“你现在面对什么情况”目标解决“你要达成什么结果”。四个要素缺一个输出质量就会打折扣。实操心得角色设定不要写“你是一个AI助手”这种废话。模型本来就知道自己是AI你告诉它这个没有任何信息增量。角色设定的每一句话都应该提供模型原本不知道的信息——你的专业领域、你的立场、你的优先级、你的约束条件。2.2 少样本示例模式给模型“打个样”少样本示例模式是我认为性价比最高的设计模式。你不需要微调模型不需要写复杂的提示词工程只需要给模型看几个“输入-输出”的示例它就能模仿着处理新输入。这个模式的原理其实很简单大模型在预训练阶段就学会了“模式匹配”你给它几个示例它就能从中提取出输入到输出的映射规律。但示例的选择有讲究。我见过有人随便找几个例子丢进去结果模型学偏了。示例选择要遵循三个原则代表性、多样性、边界清晰。代表性是指示例要覆盖典型情况。比如做一个情感分类任务你不能只给正面和负面的例子还得给中性的例子。多样性是指示例的表述方式要有变化不能都是同一个句式。边界清晰是指示例的输入输出对应关系要明确不能有歧义。示例数量也有讲究。我的经验是3到5个示例性价比最高。少于3个模型可能提取不出稳定规律多于5个边际收益递减而且会占用宝贵的上下文窗口。如果任务特别复杂可以考虑增加到8到10个但再多就不如考虑微调了。还有一个容易被忽略的细节示例的顺序。我把最有代表性的示例放在最后因为模型对靠近输出位置的示例关注度更高。这个技巧在多个项目中验证有效尤其是分类任务把最容易混淆的类别示例放在最后能明显提升该类的识别准确率。2.3 思维链引导模式让模型“想清楚再回答”思维链引导模式解决的是复杂推理任务的输出质量问题。直接让模型给答案它可能会跳步、会遗漏、会犯低级错误。但如果你引导它一步步思考准确率会显著提升。这个模式的经典实现是在提示词中加入“让我们一步步思考”这样的引导语。但实际用下来这种通用引导语的效果有限。更有效的方式是结构化思维链——你明确告诉模型思考的步骤和顺序。比如做一个财务分析任务我会这样设计思维链第一步提取关键财务指标第二步计算同比和环比变化第三步识别异常波动第四步分析可能原因第五步给出结论和建议。每一步都有明确的输入和输出要求模型按部就班执行输出质量比让它“自由发挥”稳定得多。思维链模式有一个关键决策点思维过程要不要展示给最终用户。我的做法是分场景。如果是内部使用的分析工具思维过程展示出来有助于人工复核如果是面向终端用户的产品思维过程应该隐藏只输出最终结论。技术上实现这个分离很简单——让模型把思维过程放在特定标记内后处理时根据场景决定是否保留。注意思维链不是越长越好。我见过有人把思维链设计成十几步结果模型在中间步骤就“迷路”了后面的推理完全跑偏。一般来说3到7步是比较合理的范围。超过7步的任务建议拆分成多个独立的模型调用用流程编排模式来串联。2.4 输入构造模式的组合策略实际项目中这三种输入构造模式往往是组合使用的。我以一个实际案例来说明组合策略智能客服工单分类系统。首先用角色设定模式定义模型身份“你是一个电商平台的客服工单分类专家熟悉退换货、物流查询、商品咨询、投诉建议四大类工单的处理流程。”然后用少样本示例模式给出每个类别的典型工单和对应分类每个类别给2到3个示例。最后用思维链引导模式设计分类步骤第一步提取工单中的关键信息第二步判断关键信息属于哪个业务领域第三步根据业务领域匹配工单类别第四步输出分类结果和置信度。这个组合方案在实际运行中分类准确率从最初的72%提升到了94%。提升主要来自两个方面少样本示例让模型理解了每个类别的边界思维链让模型的判断过程可追溯、可调试。组合策略的核心原则是角色设定定基调少样本示例定边界思维链定流程。三者各司其职不要混在一起写。我见过有人把角色、示例、思维链全部塞进一段提示词结果模型分不清哪些是背景信息、哪些是操作指令输出质量反而下降。3. 输出控制模式让结果稳定可控3.1 结构化输出模式的实现细节结构化输出模式解决的是输出格式不可控的问题。你让模型输出JSON它可能给你输出一段带解释的文字你让它输出表格它可能给你输出一段散文。这在需要程序化处理输出的场景中是致命的。实现结构化输出有几种方案各有优劣。最简单的是在提示词中明确格式要求比如“请以JSON格式输出包含以下字段category、confidence、reason”。这种方案实现成本低但稳定性一般模型偶尔会“忘记”格式要求。更可靠的方案是提供格式模板。你不只告诉模型要输出JSON还给它一个具体的模板示例让它填充。比如“请按照以下JSON模板输出{category: , confidence: 0.0, reason: }”。这种方案的稳定性明显提升因为模型有了具体的参照物。最可靠的方案是使用模型API提供的结构化输出功能。现在主流的大模型API都支持JSON模式或结构化输出模式你可以在API层面约束输出格式模型会保证输出符合指定的JSON Schema。这种方案几乎不会出现格式错误但需要API支持而且对Schema的复杂度有一定限制。我在实际项目中的选择策略是如果API支持结构化输出优先使用API级别的约束如果不支持使用模板加示例的方案如果对格式要求不那么严格使用简单的格式说明即可。三层方案对应不同的可靠性要求和实现成本。实操心得无论用哪种方案都要在输出后加一层格式校验。我吃过亏——模型输出了看起来像JSON但实际有语法错误的内容直接解析就报错了。加一层校验和重试机制格式错误率能降到接近零。3.2 约束解码模式的参数调优约束解码模式是通过调整模型的解码参数来控制输出的随机性和多样性。核心参数有三个温度、top-p、频率惩罚。温度控制的是输出的随机程度。温度越低输出越确定、越保守温度越高输出越多样、越有创意。我的经验值是需要精确答案的任务如分类、提取温度设在0到0.3之间需要创意输出的任务如文案生成温度设在0.7到1.0之间一般性的问答任务温度设在0.3到0.7之间。top-p控制的是采样范围。top-p设为0.9意味着模型只从概率累计达到90%的候选词中采样。top-p越低输出越集中top-p越高输出越分散。通常和温度配合使用——温度高时top-p可以适当降低温度低时top-p可以适当提高。频率惩罚控制的是模型重复使用相同词汇的倾向。频率惩罚越高模型越倾向于使用不同的表达方式。这个参数在长文本生成中特别有用能有效减少重复和啰嗦。但频率惩罚设得太高会导致输出不连贯我的经验是0.1到0.5之间比较安全。这三个参数的调优没有万能公式需要根据具体任务做实验。我的做法是先固定top-p和频率惩罚为默认值只调温度找到合适的温度区间然后固定温度微调top-p最后根据输出中重复词汇的情况调整频率惩罚。每次只调一个参数观察输出变化这样能建立参数和输出质量之间的因果关系。3.3 自洽性校验模式让模型自己检查自己自洽性校验模式的核心思路是让模型生成多个候选输出然后选择最一致的那个。这个模式特别适合有明确正确答案的任务比如数学计算、逻辑推理、事实问答。具体实现方式是用相同的提示词让模型生成3到5个输出通过设置较高的温度来增加多样性然后比较这些输出的一致性。如果多数输出指向同一个答案这个答案的可信度就比较高如果输出分歧很大说明模型对这个问题的把握不大需要人工介入或换一种方式提问。这个模式的原理基于一个假设正确答案比错误答案更容易被模型稳定地生成。对于模型真正“理解”的问题多次采样会收敛到同一个答案对于模型“模糊”的问题多次采样会分散到不同的答案。这个假设在很多任务中被验证有效尤其是数学和逻辑推理任务。但自洽性校验模式有一个明显的成本问题生成多个输出意味着多倍的API调用费用和延迟。所以它不适合所有场景只适合那些错误代价高、对延迟不敏感的场景。比如医疗诊断辅助、法律条款分析、财务审计这些场景下多花几倍成本换取更高的准确率是值得的。注意自洽性校验不是万能的。如果模型对某个问题存在系统性偏差多次采样会一致地给出错误答案。这种情况下自洽性校验反而会强化错误。所以这个模式要和其他校验手段配合使用不能单独依赖。3.4 输出控制模式的组合与降级策略输出控制模式在实际项目中需要设计降级策略。什么叫降级策略就是当主要方案失效时系统如何优雅地处理而不是直接崩溃。我以一个实际项目为例智能合同条款提取系统。主要方案是使用API的结构化输出功能直接输出JSON格式的条款列表。但如果API调用失败或返回格式异常系统会降级到第二方案使用模板加示例的方式重新请求。如果第二方案也失败降级到第三方案输出自由文本由后处理程序用正则表达式提取关键信息。如果第三方案仍然失败系统会标记该合同为“需人工处理”并通知相关人员。这个三级降级策略保证了系统在各种异常情况下都能给出可用的结果而不是直接报错。降级策略的设计原则是每一级降级都牺牲一定的自动化程度但保证核心功能可用。第一级是全自动结构化输出第二级是半自动格式修复第三级是人工兜底。组合策略方面我通常把结构化输出模式和约束解码模式配合使用。结构化输出模式保证格式约束解码模式保证内容质量。比如一个商品描述生成任务结构化输出模式保证输出包含标题、卖点、规格参数三个部分约束解码模式通过调整温度让描述既有创意又不跑偏。4. 流程编排模式把多个步骤串起来4.1 链式调用模式的设计要点链式调用模式是把一个复杂任务拆分成多个步骤每个步骤调用一次模型前一步的输出作为后一步的输入。这个模式解决的是单次调用无法完成复杂任务的问题。设计链式调用模式时最关键的是步骤拆分。拆得太粗单步任务还是太复杂模型处理不好拆得太细调用次数太多成本和延迟都上去了。我的经验是每个步骤应该是一个独立的、有明确输入输出定义的子任务。如果一个步骤的输入需要依赖前两个步骤的输出那说明拆分可能有问题应该考虑调整拆分方式。我以一个实际项目为例技术文档自动生成系统。第一步提取代码中的函数签名和注释第二步根据函数签名和注释生成每个函数的说明文档第三步把所有函数的说明文档整合成完整的API文档第四步检查文档的完整性和一致性。四个步骤每个步骤的输入输出都很明确前一步的输出直接作为后一步的输入。链式调用模式的一个常见问题是错误传播。如果第一步的输出有错误后面的步骤会基于错误的信息继续处理最终结果完全不可用。解决这个问题的方法是在每个步骤后加校验节点。校验节点检查当前步骤的输出是否符合预期如果不符合要么重试当前步骤要么回退到上一步重新处理。实操心得链式调用中每个步骤的提示词要独立设计不要试图在一个提示词里完成多个步骤。我试过把提取和生成放在一个提示词里结果模型经常混淆两个任务的要求。拆开之后每个步骤的提示词可以针对性地优化整体效果反而更好。4.2 路由分发模式让合适的模型做合适的事路由分发模式的核心思想是不是所有任务都需要用同一个模型处理。简单任务用轻量模型复杂任务用重量模型这样能在保证质量的同时控制成本。实现路由分发有两种方式。一种是基于规则的硬路由你预先定义规则比如“输入长度小于100字且任务类型为分类走轻量模型输入长度大于500字或任务类型为推理走重量模型”。这种方式的优点是可控性强缺点是规则需要人工维护不够灵活。另一种是基于模型判断的软路由你先用一个轻量模型判断任务的复杂度然后根据判断结果决定用哪个模型处理。这种方式的优点是自适应性强缺点是判断本身也有成本而且判断可能出错。我在实际项目中的选择是核心业务用硬路由边缘业务用软路由。核心业务对稳定性要求高硬路由的确定性更合适边缘业务变化快软路由的灵活性更有价值。路由分发模式还有一个变体是多模型投票。对于关键任务同时调用多个不同的模型然后综合它们的输出。如果多个模型给出相同的答案可信度就很高如果分歧很大就标记为需要人工处理。这个变体的成本较高但准确率也最高适合对准确性要求极高的场景。4.3 并行聚合模式提升吞吐量的关键并行聚合模式解决的是处理大量数据时的效率问题。当你需要处理成千上万条数据时串行调用模型的速度完全不可接受。并行聚合模式通过同时发起多个模型调用大幅提升吞吐量。实现并行聚合的关键是任务分片和结果聚合。任务分片是把大批量数据拆分成小批次每个批次独立调用模型。结果聚合是把各个批次的输出合并成最终结果。任务分片的大小需要权衡。分片太小调用次数太多管理开销大分片太大单次调用的延迟高并行度不够。我的经验是根据模型的响应时间和你的并发限制来确定分片大小。如果模型平均响应时间是2秒你的并发限制是10那么分片大小设为10左右比较合适这样能在一次并发中处理完一个分片。结果聚合阶段需要注意顺序问题。并行调用的返回顺序是不确定的你需要根据任务ID或其他标识把结果对应回原始数据。这个细节看起来简单但实际实现时经常出错。我的做法是在每个任务分片时生成唯一ID聚合时根据ID排序确保输出顺序和输入顺序一致。注意并行聚合模式对API的速率限制很敏感。如果并发太高可能触发API的限流机制导致部分请求失败。我的做法是加一个自适应限流器根据API返回的错误信息动态调整并发数。遇到限流就降低并发稳定运行一段时间后再逐步提高。4.4 流程编排模式的异常处理与重试机制流程编排中异常处理是绕不开的话题。模型调用可能因为网络问题、API限流、模型过载等原因失败。没有完善的异常处理机制整个流程就会卡住。我的异常处理策略分三层。第一层是即时重试对于网络超时、临时限流这类瞬时故障立即重试通常重试1到2次就能成功。第二层是退避重试对于持续性的限流或过载采用指数退避策略每次重试的间隔逐渐增加给系统恢复的时间。第三层是降级处理如果重试多次仍然失败降级到备用方案比如换一个模型、简化任务要求、或者标记为人工处理。重试机制有一个容易被忽略的细节幂等性。如果重试的操作不是幂等的可能会导致重复处理。比如一个“生成订单摘要”的任务重试时可能会生成两个摘要。解决方法是给每个任务分配唯一ID重试时检查该ID是否已经处理过避免重复。还有一个经验是记录详细的日志。每次调用模型时记录输入、输出、耗时、使用的模型版本、参数配置等信息。这些日志在排查问题时极其有用。我遇到过一个问题某个批次的输出质量突然下降查日志发现是模型版本在后台更新了提示词没有适配新版本。如果没有详细的日志这个问题可能要排查很久。5. 质量保障模式确保输出可信赖5.1 评估器模式用模型评估模型评估器模式的核心思路是用一个独立的模型调用来评估主模型的输出质量。这个模式解决的是“怎么自动判断输出好不好”的问题。评估器的设计有两种方式。一种是打分式评估让评估模型给主模型的输出打一个分数比如1到10分然后设定阈值低于阈值的输出触发重试或人工审核。另一种是对比式评估让评估模型比较两个候选输出选择更好的那个。对比式评估通常比打分式评估更稳定因为模型更擅长做相对判断而不是绝对判断。评估器的提示词设计很关键。你不能简单地说“请评估这个输出好不好”这样评估模型会给出很泛化的评价。有效的评估器提示词应该包含明确的评估维度和评分标准。比如“请从准确性、完整性、格式规范性三个维度评估以下输出。准确性指输出内容是否与输入要求一致完整性指输出是否覆盖了所有要求的内容格式规范性指输出是否符合指定的格式要求。每个维度1到5分给出总分和具体理由。”评估器模式的一个挑战是评估器本身的可靠性。如果评估器判断不准整个质量保障体系就失效了。我的做法是定期用人工标注的数据校验评估器的准确性如果发现评估器偏差较大就调整评估器的提示词或换一个评估模型。实操心得评估器不要和主模型用同一个模型。我试过用同一个模型评估自己的输出结果它倾向于给自己打高分评估效果很差。换一个不同系列的模型做评估器评估的客观性明显提升。5.2 反思迭代模式让模型自我改进反思迭代模式是让模型先生成一个初稿然后自己审查初稿找出问题并改进生成第二稿。这个过程可以重复多次直到输出质量达到要求。实现反思迭代的关键是审查提示词的设计。审查提示词要引导模型从特定角度审视自己的输出。比如“请检查以下输出是否存在事实错误、逻辑漏洞、格式问题。对于每个发现的问题说明具体位置和修改建议。”这种结构化的审查提示词比“请检查有没有问题”有效得多。反思迭代的轮次需要控制。我的经验是2到3轮效果最好。第一轮通常能发现明显的问题第二轮能发现一些细节问题第三轮之后改进幅度就很小了。超过3轮不仅收益递减还可能引入新的问题——模型在反复修改中可能“过度修正”把原本正确的内容改错了。这个模式特别适合写作类任务。我做一个技术博客生成系统时用反思迭代模式让模型先写初稿然后审查逻辑连贯性再审查技术准确性最后审查语言表达。经过三轮迭代输出质量比单次生成提升了至少一个档次。5.3 人工介入模式什么时候该让人来把关人工介入模式不是技术方案而是流程设计。它的核心问题是在什么环节、什么条件下应该让人来审核或处理。我的经验是设置三个介入触发条件。第一是置信度低于阈值当模型的输出置信度低于某个阈值时自动转人工审核。第二是涉及高风险决策当输出涉及财务、法律、医疗等高风险领域时无论置信度高低都需要人工复核。第三是用户主动要求当用户对输出表示不满意或要求人工服务时直接转人工。人工介入模式的设计要点是降低人工审核的成本。你不能让审核人员从头开始检查而应该把模型的输出、置信度、关键依据都整理好审核人员只需要做确认或修改。我设计过一个审核界面左边显示模型输出右边显示置信度和关键依据审核人员可以一键确认或修改。这个设计把单条审核时间从平均3分钟降到了40秒。注意人工介入不是失败而是质量保障体系的一部分。不要觉得转人工就是系统做得不好。在关键业务场景中人工介入是必要的安全网。关键是设计好介入的触发条件和审核流程让介入高效、不冗余。5.4 质量保障模式的组合与持续优化质量保障模式需要组合使用才能形成完整的保障体系。我的标准组合是评估器做初筛反思迭代做改进人工介入做兜底。具体流程是主模型生成输出后评估器立即评估质量。如果评估通过直接输出如果评估不通过触发反思迭代让模型自我改进。改进后的输出再次评估如果通过则输出如果仍不通过转人工处理。这个流程在多个项目中验证有效能在保证质量的同时控制人工介入的比例。持续优化方面我建议建立质量数据闭环。每次人工介入的处理结果都记录下来定期分析人工修改的模式和规律。如果发现某类问题频繁出现就针对性地优化提示词或调整设计模式。这个闭环让系统的输出质量随时间持续提升而不是停留在初始水平。我做过一个统计一个采用完整质量保障模式的系统运行三个月后人工介入率从最初的15%降到了4%以下。下降的主要原因是评估器的判断越来越准以及提示词根据人工反馈做了针对性优化。这个数据说明质量保障模式不是静态的而是需要持续迭代的。6. 实际项目中的模式组合与踩坑记录6.1 一个完整项目的模式选型过程我以一个实际做过的项目为例完整展示设计模式的选型过程。项目需求是自动生成电商平台的商品描述文案要求包含标题、卖点、规格参数三个部分语言风格要符合平台调性且不能出现违禁词。第一步是需求拆解。我把任务拆成四个子任务提取商品原始信息、生成标题和卖点、生成规格参数描述、违禁词检查。第二步是模式匹配。提取商品信息用结构化输出模式生成标题和卖点用角色设定加少样本示例模式生成规格参数用结构化输出加约束解码模式违禁词检查用评估器模式。第三步是流程编排。四个子任务用链式调用模式串联每个子任务后加校验节点。第四步是质量保障。整体输出用评估器做最终审核置信度低的转人工。这个方案在实际运行中单条商品描述的生成时间约8秒人工介入率约6%客户满意度评分4.7分满分5分。对比最初没有设计模式的版本生成时间从15秒降到了8秒人工介入率从25%降到了6%。6.2 常见踩坑记录与解决方案坑一提示词过长导致模型“遗忘”前面的指令。我做过一个复杂任务提示词写了2000多字结果模型只关注了最后几百字的内容前面的角色设定和示例完全被忽略了。解决方案是把长提示词拆分成多个短提示词用链式调用模式串联。如果必须用长提示词把最重要的指令放在开头和结尾中间放辅助信息。坑二少样本示例的格式不一致导致模型困惑。我收集示例时没有统一格式有的示例输入是问句有的是陈述句有的输出是JSON有的是纯文本。模型从这些不一致的示例中提取不出稳定的模式输出质量很差。解决方案是严格统一示例格式输入怎么组织、输出怎么组织所有示例保持一致。坑三并行调用时API限流导致大量失败。我做一个批量处理任务时一次性发起了50个并发请求结果触发了API的限流机制超过一半的请求返回429错误。解决方案是加自适应限流器初始并发设为5根据API返回的错误信息动态调整。稳定运行后再逐步提高并发最终稳定在15个并发。坑四评估器过于严格导致大量不必要的重试。我设置的评估器阈值太高很多质量已经不错的输出被判定为不合格触发了大量重试成本和延迟都上去了。解决方案是调整评估器的评分标准把阈值从8分降到6分同时增加人工抽检来校准评估器的准确性。坑五模型版本更新导致提示词失效。有一次模型后台更新了版本之前调好的提示词输出质量突然下降。排查后发现新版本对格式要求更严格之前的提示词没有明确指定输出格式。解决方案是在提示词中显式指定输出格式并加格式校验节点。同时建立模型版本监控机制版本更新时自动运行回归测试。6.3 模式组合的优先级与取舍原则在实际项目中不是所有模式都需要用上。我的优先级排序是输入构造模式 输出控制模式 质量保障模式 流程编排模式。输入构造模式优先级最高因为输入质量直接决定输出质量的上限。输入构造没做好后面的模式再完善也弥补不了。输出控制模式次之它保证输出能被程序化处理。质量保障模式再次它保证输出的可信度。流程编排模式最后它解决的是效率和规模问题。取舍原则是先保证质量再优化效率。我见过一些团队一上来就搞复杂的流程编排结果单步质量都没做好整体效果很差。正确的做法是先优化单步的输入构造和输出控制把单步质量做到90分以上再用流程编排把多个步骤串起来。还有一个原则是能用简单模式解决就不用复杂模式。比如一个简单的分类任务用角色设定加少样本示例就能达到95%的准确率就不需要上思维链和评估器。过度设计不仅增加成本还增加维护复杂度。6.4 从项目实践中提炼的经验法则经过多个项目的实践我提炼了几条经验法则供参考。法则一提示词的长度和任务复杂度成正比但不要超过模型上下文窗口的30%。超过这个比例模型对提示词中后部分的关注度会明显下降。法则二少样本示例的数量以3到5个为最佳超过8个边际收益递减。如果任务特别复杂需要更多示例考虑用微调代替少样本。法则三温度参数和任务类型强相关。分类、提取类任务温度设0到0.3问答、分析类任务设0.3到0.7创意生成类任务设0.7到1.0。法则四任何关键任务都要有降级方案。没有降级方案的系统在生产环境中是脆弱的一次API故障就可能导致整个系统不可用。法则五质量保障的投入应该和错误的代价成正比。错误代价高的场景多花成本做评估和人工复核是值得的错误代价低的场景简单校验即可。这些法则不是绝对的但可以作为项目初期的参考基准。实际项目中还需要根据具体需求和资源约束做调整。我在实际使用中发现遵循这些法则的项目上线后的稳定性和用户满意度都明显高于没有遵循的项目。