生成式 AI 这两年从“新鲜玩意”变成了日常工具但真正把它用进项目里很多人还是停留在“打开对话框问一句、复制答案贴回去”的阶段。我前后参与过几个把大模型能力嵌进业务流程的小项目踩过的坑比写过的提示词还多。这篇就围绕“基于 ChatGPT 和 OpenAI 模型的现代生成式 AI”这个主题把我对整套东西的理解、选型逻辑、落地步骤和排错经验摊开讲一遍。核心关键词是生成式 AI、大模型应用、提示词工程、API 集成、上下文管理适合刚接触大模型应用开发的工程师、想给产品加 AI 能力的产品同学以及自己动手做小工具的技术爱好者。读完你至少能搞清楚一套能跑起来的生成式 AI 应用由哪几块拼成、每块为什么这么选、参数怎么定、出问题往哪查。1. 整体设计与思路拆解1.1 先想清楚“生成式”到底改变了什么传统软件的逻辑是“输入确定、输出确定”你写 if-else程序按分支走。生成式 AI 的逻辑是“输入一段自然语言输出一段概率上最合理的自然语言”它没有固定分支靠的是模型在海量语料里学到的模式。这个根本差异决定了整套架构的设计思路你不能指望它百分百按格式输出所以要在外面套一层“约束和校验”你不能指望它记住上一次对话所以要把上下文显式传进去你不能指望它知道你的私有数据所以要做检索增强。我见过不少项目一上来就想让模型“直接干活”结果输出格式飘忽、事实张口就来最后归咎于“模型不行”。其实问题多半出在架构层把不确定性当确定性用本身就是设计错误。合理的做法是把大模型当成一个“能力很强但需要明确指令、需要边界约束的实习生”外面配好流程、校验和兜底。1.2 三层结构接入层、编排层、应用层我习惯把生成式 AI 应用拆成三层。接入层负责和模型服务通信处理鉴权、重试、限流、超时编排层负责拼装提示词、管理上下文、调用工具、解析输出应用层是具体业务比如客服问答、文档摘要、代码辅助。这么分层的好处是换模型、调参数、改提示词都只动一层不会牵一发动全身。为什么强调分层因为实际项目里模型会换、价格会变、接口会升级。如果业务代码里到处散落着请求模型的代码改一次要翻遍整个仓库。分层之后接入层封装成一个客户端编排层封装成一组“任务函数”应用层只管调用任务函数拿结果。这个思路和传统后端把数据库访问封装成 DAO 是一回事只是对象从数据库换成了模型。1.3 为什么优先选对话式模型而不是纯补全模型早期很多任务是“给前半句补后半句”现在主流做法是用对话式接口把指令、示例、用户输入组织成消息列表。原因很实际对话格式天然支持“系统指令 多轮上下文”你能把角色设定、输出要求、few-shot 示例都塞进 system 消息里模型遵循度明显更高。纯补全接口要自己拼字符串格式一乱模型就懵。另一个考量是生态。对话式接口的周边工具、示例、社区讨论都更丰富遇到问题更容易找到参考。我在选型时的原则是能用对话式就不碰纯补全除非任务确实是纯粹的文本续写且对成本极度敏感。1.4 成本与延迟的权衡思路生成式 AI 的成本主要看输入输出 token 数延迟主要看输出长度和模型规模。一个常见误区是“什么都用最大最强的模型”结果账单吓人、响应还慢。我的做法是按任务分级简单分类、抽取用轻量模型复杂推理、长文生成用强模型。同一个应用里混用不同档位的模型完全正常关键是给每个任务定好“够用就行”的标准。延迟方面输出 token 是主要瓶颈因为是一个一个吐出来的。所以提示词里要明确“简洁回答”“不超过多少字”别让模型自由发挥写一大篇。流式输出能显著改善体感用户看到字一个个出来即使总时长没变等待感也低很多。2. 核心细节解析与实操要点2.1 提示词工程把要求写死把示例给足提示词不是“随便描述一下”而是一份给模型的规格说明书。我总结的写法是四段式角色与目标、输入说明、输出格式、约束与示例。角色与目标告诉模型“你是谁、要干什么”输入说明交代数据长什么样输出格式用明确的模板或 JSON schema 约束约束与示例把边界情况和正确样例摆出来。举个实际例子做文档摘要任务提示词可以这样组织先说明“你是一名技术文档编辑任务是把长文压缩成要点”再给出输入是“一段 Markdown 文本”输出要求“三条以内的短句每条不超过 30 字”最后附一个输入输出示例。实测下来带示例的提示词比纯描述的遵循度高出一大截尤其是格式类要求。注意提示词里不要用“尽量”“最好”这类模糊词模型会当成可选项。要写“必须”“禁止”“只能”。2.2 上下文管理窗口有限取舍有讲究对话式模型的上下文窗口虽然越来越大但不是无限的而且塞得越多成本越高、关键信息越容易被稀释。我的经验是只保留和当前任务相关的历史。多轮对话里早期寒暄、跑题的来回完全可以裁掉保留最近几轮加上一条“历史摘要”就够了。具体做法是维护一个消息列表每次请求前做一次“压缩”把超过 N 轮之前的对话用模型自己总结成一段话替换掉原始消息。这样既保留了语义连续性又控制了 token 数。另一种做法是“滑动窗口”只留最近 K 轮简单粗暴但够用。选哪种看任务需要长期记忆的用摘要短对话用滑动窗口。2.3 输出结构化让模型吐 JSON 的可靠办法业务系统要的是结构化数据不是一段散文。让模型输出 JSON 有几个要点第一在提示词里给出完整的 JSON 模板字段名、类型、嵌套关系都写清楚第二明确“只输出 JSON不要任何解释文字”第三拿到结果后做一次解析校验解析失败就重试或走兜底。即便如此模型偶尔还是会加个“好的以下是结果”之类的前缀。所以解析前要先做清洗比如找到第一个{和最后一个}之间的内容再解析。更稳的做法是用支持“结构化输出”的接口能力把 schema 直接传给模型让它按 schema 生成这样格式错误的概率大幅下降。我现在的习惯是能用结构化输出能力就用不能用的才靠提示词硬约束加解析兜底。2.4 参数调节温度、最大长度、惩罚项怎么定几个关键参数得心里有数。温度temperature控制随机性做事实问答、抽取、分类时调低0 到 0.3要创意文案时调高0.7 到 1.0。最大输出长度按任务定摘要类给 200 到 500 token长文生成才给上千。频率惩罚和存在惩罚用来抑制重复长文生成时适当加一点能减少车轱辘话。这里有个容易忽略的点温度调低不等于输出完全确定只是概率分布更集中。所以对“必须完全一致”的场景不能依赖模型得在外部做缓存或规则校验。我一般会在接入层加一层结果缓存相同输入直接返回上次结果既省钱又稳定。2.5 安全与内容边界输入输出都要过一遍生成式应用必须考虑内容安全。输入端要做基本的注入防护比如用户输入里夹带“忽略以上指令”这类话术时要在编排层做检测和隔离别让用户输入直接拼进 system 消息。输出端要做内容过滤对敏感、违规内容做拦截。这块不是可选项是上线前的必做项。具体实现上我会在编排层加一个“输入清洗”步骤和一个“输出审核”步骤。输入清洗做长度限制、特殊字符处理、指令注入关键词检测输出审核可以先用规则过滤明显问题再视情况用模型做二次判断。两层下来大部分风险能挡住。3. 实操过程与核心环节实现3.1 环境准备与客户端封装先搭一个最小可用的客户端。以 Python 为例核心是封装一个请求函数处理鉴权、超时、重试。下面是一个简化版的结构重点看分层和异常处理import time import json class ModelClient: def __init__(self, api_key, base_url, timeout30, max_retries3): self.api_key api_key self.base_url base_url self.timeout timeout self.max_retries max_retries def chat(self, messages, modeldefault, temperature0.3, max_tokens500): payload { model: model, messages: messages, temperature: temperature, max_tokens: max_tokens, } for attempt in range(self.max_retries): try: resp self._post(payload) return self._parse(resp) except TimeoutError: if attempt self.max_retries - 1: raise time.sleep(2 ** attempt) # 指数退避 except RateLimitError: time.sleep(5) raise RuntimeError(请求失败已达最大重试次数)这段代码的关键点指数退避重试应对限流和瞬时故障超时设置防止请求挂死统一解析把各家返回格式差异挡在接入层内部。参数上超时给 30 秒对大多数任务够用重试 3 次是经验值再多意义不大。3.2 编排层任务函数的写法编排层把“拼提示词、调模型、解析结果”打包成一个任务函数。以“从用户反馈里抽取问题分类和情绪”为例def extract_feedback(client, text): system_prompt ( 你是客服质检助手。从用户反馈中抽取两个字段 category问题分类只能是功能、性能、界面、其他 sentiment情绪只能是正面、中性、负面。 只输出 JSON不要解释。 ) messages [ {role: system, content: system_prompt}, {role: user, content: text}, ] raw client.chat(messages, temperature0.0, max_tokens100) return parse_json_safely(raw)这里温度给 0因为分类任务要稳定max_tokens 给 100因为输出就两个字段给多了浪费。parse_json_safely负责清洗和解析解析失败返回一个默认结构并记录日志保证上层不会因为一条脏数据崩掉。3.3 检索增强让模型用上私有知识模型不知道你的内部文档硬问就会编。检索增强的做法是先把文档切块、向量化存起来用户提问时先检索最相关的几块拼进提示词里让模型“基于以下资料回答”。切块大小我一般给 300 到 500 字重叠 50 字左右保证语义完整又不至于太碎。检索环节的关键是“召回质量”。向量检索对语义相似有效但对精确关键词匹配弱所以实际项目里常做“混合检索”向量召回加关键词召回再合并去重。拼提示词时明确写“只根据提供的资料回答资料里没有就说不知道”能显著减少胡编。3.4 流式输出与前端配合流式输出把模型吐字的过程实时推给前端体感提升明显。实现上接入层用流式请求逐块读取编排层做一次缓冲和拼接应用层通过 SSE 或 WebSocket 推给前端。要注意的是流式下错误处理更麻烦因为响应已经开始推了才发现出错只能中断并提示重试。我的做法是流式只用于“展示型”输出比如聊天回复、长文生成对需要严格解析的结构化任务还是用非流式等完整结果再解析。两者按任务类型分开别为了统一而统一。3.5 一个完整的调用链路示例把上面几块串起来一次典型请求的链路是用户输入 → 输入清洗 → 检索相关资料 → 拼装消息列表system 资料 历史 用户输入→ 调模型 → 输出审核 → 解析/格式化 → 返回前端。每一步都有日志记录方便出问题时定位是哪一环出的错。日志我建议至少记请求 ID、模型名、输入 token 数、输出 token 数、耗时、是否命中缓存、是否重试。这些数据积累下来既能做成本分析也能发现“哪类请求特别慢、特别贵”的优化点。4. 常见问题与排查技巧实录4.1 输出格式不对、解析失败这是最高频的问题。排查顺序先看原始输出长什么样是不是带了多余前缀后缀再看提示词里的格式约束够不够硬最后看是不是温度太高导致格式漂移。解决办法按优先级改用结构化输出能力 加强提示词约束并给示例 解析前做清洗 解析失败重试一次 兜底默认值。4.2 回答胡编、事实错误模型编造内容通常是因为“不知道但被要求回答”。对策是在提示词里明确“不确定就说不知道”提供参考资料并要求“只基于资料回答”对关键事实做外部校验。检索增强能解决大部分“不知道私有知识”的编造剩下的靠提示词和校验兜。4.3 响应慢、超时先分清是模型侧慢还是网络侧慢。看日志里的耗时分布如果大部分时间在等模型输出就压缩输出长度、换轻量模型、上流式如果是网络抖动加重试和超时。长文生成任务可以考虑“分段生成再拼接”每段控制在合理长度。4.4 成本超预期查三件事是不是所有任务都用了强模型、输入里是不是塞了过多无关上下文、有没有做缓存。优化手段对应任务分级用不同模型、上下文做压缩和裁剪、相同输入走缓存。我见过一个项目光是把“每次请求都带上全部历史”改成“只带最近三轮”成本就降了一半多。4.5 常见问题速查表现象可能原因排查动作解决方向输出带多余文字提示词约束不够硬看原始输出加“只输出X”约束、结构化输出JSON 解析失败格式漂移、温度高打印原始串清洗、降温度、重试兜底回答编造缺资料、被要求必答核对事实检索增强、允许说不知道响应超时输出过长、模型大看耗时分布压缩输出、换模型、流式成本偏高强模型滥用、上下文冗余看 token 统计任务分级、上下文裁剪、缓存限流报错请求过密看错误码指数退避、排队、配额管理4.6 几条踩坑心得第一别在业务代码里直接拼提示词集中到编排层改起来才不痛苦。第二任何依赖模型输出的地方都要有兜底模型不是数据库不能假设它一定返回预期格式。第三上线前一定要做一轮“对抗测试”故意输入奇怪内容、超长内容、指令注入内容看系统扛不扛得住。第四token 统计要尽早接入不然月底看账单才发现问题就晚了。我个人在实际操作中的体会是生成式 AI 项目的成败模型能力只占一部分更多取决于外围的工程化程度——提示词管理、上下文控制、输出校验、错误兜底、成本监控这些“不性感”的活儿才是决定能不能稳定跑起来的关键。把模型当成一个需要明确指令和边界约束的组件来对待而不是一个万能的黑盒很多问题在设计阶段就能规避掉。