1. 从“会用”到“会造”拆解ChatGPT应用开发的核心思路很多人第一次接触ChatGPT停留在“问一句答一句”的聊天层面。但真正让开发者兴奋的是把它当成一个可编程的推理引擎嵌进自己的产品里。我最初也是从写提示词玩起后来发现光靠对话框根本撑不起一个完整应用——你需要处理上下文、管理会话状态、控制输出格式、对接外部数据。这些活儿才是“创建人工智能应用程序”的真正门槛。所谓用ChatGPT创建人工智能应用程序本质上是三件事的叠加大模型能力调用、业务逻辑编排、用户交互封装。ChatGPT在这里扮演的是“大脑”它负责理解意图、生成内容、做出判断而你的代码负责给它喂数据、约束它的行为、把它的输出变成用户能用的功能。适合谁来参考如果你有基础编程能力想做一个智能客服、文档问答助手、内容生成工具或者只是想搞明白那些AI产品到底怎么搭出来的这篇内容就是为你准备的。我见过太多人卡在第一步以为要训练模型、要买GPU、要搞深度学习。其实完全不用。调用现成的模型接口配合合理的工程架构就能做出体验相当不错的产品。下面我按实际开发顺序把每个环节拆开讲。1.1 为什么选ChatGPT而不是自己训模型自己训练一个可用的对话模型成本至少是百万级人民币起步还需要专业算法团队。而调用ChatGPT的接口按token计费一个中小型应用每月的成本可能就几十到几百块。这个账很好算你花在训练上的钱和时间足够你把产品迭代几十个版本了。更重要的是ChatGPT的能力边界足够宽。它能写代码、能翻译、能总结、能做逻辑推理这意味着你不需要为每个功能单独准备模型。一个接口多种用途。我在做文档问答工具时同一个模型既负责理解用户问题又负责从检索到的段落里提取答案还负责把答案改写成友好的语气。如果换成传统方案至少需要三个不同的NLP模型串联。当然选ChatGPT也有代价。你依赖外部服务网络延迟、接口限流、费用波动都是风险。所以架构设计上必须考虑降级方案和缓存策略这个后面会细说。1.2 应用架构的三种典型模式根据我实际做过的项目用ChatGPT构建应用大致分三种模式复杂度依次递增。第一种是直连模式用户输入直接发给ChatGPT返回结果直接展示。适合做简单的翻译工具、文案生成器。开发量极小一个接口调用就搞定。缺点是没法处理复杂任务模型容易跑偏。第二种是编排模式在用户和模型之间加一层逻辑层。这层逻辑负责组装提示词、管理对话历史、调用外部工具、校验输出格式。大部分有价值的AI应用都属于这一类。比如智能客服你需要先从知识库检索相关文档把文档内容塞进提示词再让模型基于文档回答。这层编排逻辑才是你产品的核心竞争力。第三种是代理模式让模型自己决定调用哪些工具、按什么顺序执行。比如用户说“帮我查一下明天北京的天气然后推荐穿什么衣服”模型需要先调用天气接口拿到结果后再推理穿衣建议。这种模式最接近“智能体”的概念开发难度也最高需要处理工具调用的异常、循环终止条件、多步推理的中间状态。我建议新手从第二种模式入手。直连模式太简单学不到东西代理模式太复杂容易劝退。编排模式刚好能让你理解AI应用的核心工程问题。1.3 关键设计决策提示词工程与上下文管理提示词不是随便写几句话就完事。我踩过的最大坑就是早期把提示词写得太随意导致模型输出格式不稳定前端解析经常报错。后来我总结了一套模板结构角色定义 任务描述 输出格式约束 示例。这四部分缺一不可。角色定义让模型知道自己是干什么的比如“你是一个专业的法律文书助手”。任务描述说清楚要做什么比如“根据用户提供的案情生成一份起诉状草稿”。输出格式约束最关键你要明确告诉模型返回JSON还是Markdown每个字段叫什么名字。示例则是给模型一个参照尤其是复杂格式给一个例子比写十句描述都管用。上下文管理是另一个容易被忽视的点。ChatGPT接口本身是无状态的每次调用都要把历史对话重新发过去。但你不能无限往里面塞历史token有上限费用也会飙升。我的做法是保留最近N轮对话同时对更早的历史做摘要压缩。摘要本身也可以让模型来做成本很低。提示上下文窗口不是越大越好。塞太多无关历史反而会干扰模型对当前问题的判断。我一般保留最近5到10轮具体看任务复杂度。2. 核心细节解析从接口调用到产品级封装这一部分讲具体的技术实现。我会以Python为例因为生态最成熟文档最全。其他语言逻辑类似只是SDK不同。2.1 接口调用的最小可行代码先看最基础的调用。你需要一个API Key这个在平台后台申请。然后安装官方SDK写几行代码就能跑通。from openai import OpenAI client OpenAI(api_key你的API Key) response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是一个 helpful 的助手}, {role: user, content: 用一句话解释什么是机器学习} ], temperature0.7, max_tokens200 ) print(response.choices[0].message.content)这段代码里model参数指定用哪个模型。messages是一个列表包含系统角色和用户角色。temperature控制随机性0表示最确定1表示最随机。max_tokens限制返回长度防止费用失控。我建议新手先把这段代码跑通理解每个参数的含义。然后逐步加功能加多轮对话、加流式输出、加错误处理。2.2 参数调优temperature、top_p与惩罚项这几个参数直接决定输出质量但很多人调不好。我按实际经验给一组参考值。参数作用推荐范围适用场景temperature控制随机性0.2-0.5事实问答、代码生成temperature控制随机性0.7-0.9创意写作、头脑风暴top_p核采样控制候选词范围0.9-1.0一般配合temperature使用frequency_penalty降低重复词频率0.0-0.5长文本生成防止复读presence_penalty鼓励引入新话题0.0-0.5对话场景避免绕圈子我的习惯是做工具类应用temperature设0.3做内容生成设0.8。frequency_penalty和presence_penalty一般不动除非发现模型明显在重复。注意temperature和top_p不建议同时调选一个调就行两个都调容易让输出变得不可控。2.3 流式输出让用户不用干等ChatGPT网页版那种一个字一个字往外蹦的效果就是流式输出。技术上通过SSEServer-Sent Events实现。好处是用户感知的响应时间大幅缩短体验好很多。stream client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 写一首关于秋天的诗}], streamTrue ) for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)流式输出有个坑你没法在生成过程中做格式校验。因为内容是一段段来的可能前半段是合法JSON后半段突然多了个逗号。所以如果应用对输出格式要求严格要么等完整返回后再校验要么在提示词里把格式约束写得极其明确。2.4 函数调用让模型操作你的系统这是从“聊天”到“应用”的关键一步。函数调用允许你定义一组工具模型根据用户意图决定调用哪个并返回结构化参数。比如用户说“帮我查一下订单12345的状态”模型会返回一个函数调用请求参数是订单号12345你的代码拿到后去查数据库再把结果喂回模型生成最终回复。tools [ { type: function, function: { name: query_order, description: 根据订单号查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 订单12345到哪了}], toolstools, tool_choiceauto )模型返回的tool_calls字段里包含函数名和参数。你执行完函数后把结果以role: tool的消息追加到对话里再次调用模型它就会基于函数结果生成自然语言回复。这个机制让AI应用真正有了“手脚”。我做过一个内部工具把数据库查询、邮件发送、日历创建都封装成函数用户用自然语言就能完成复杂操作。开发量不大但体验提升非常明显。注意函数调用的参数校验一定要做。模型可能返回不存在的订单号或者格式不对的参数。你的代码必须能处理这些异常不能直接信任模型输出。3. 实操过程从零搭建一个文档问答助手光讲理论没意思我带你走一遍完整流程。这个助手的功能是用户上传PDF文档然后可以针对文档内容提问助手基于文档回答。这是最常见的AI应用形态之一。3.1 技术选型与整体流程核心组件四个文档解析、文本切分、向量检索、对话生成。文档解析用PyPDF2或pdfplumber文本切分自己写逻辑向量检索用开源的FAISS或Chroma对话生成调ChatGPT接口。整体流程用户上传PDF → 解析出文本 → 切成小段 → 每段转成向量存起来 → 用户提问 → 问题转向量 → 检索最相似的段落 → 把段落和问题一起发给ChatGPT → 返回答案。这个架构叫RAG检索增强生成是目前最实用的AI应用模式。它解决了大模型的两个痛点一是模型不知道你的私有数据二是模型容易胡编乱造。通过检索相关文档作为依据答案的准确性和可信度大幅提升。3.2 文档切分的参数计算与实操切分看着简单其实很讲究。切太大检索精度下降切太小语义不完整。我的经验值是每段300到500个token相邻段之间重叠50到100个token。为什么要有重叠因为一句话可能被切断导致语义丢失。重叠部分保证每个关键信息至少完整出现在一个段里。具体计算假设你的文档平均每100个token对应200个汉字那300个token大约是600个汉字。你可以按段落切如果段落太长再按句子切。def split_text(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks这是按字符切的简化版。实际项目中我会用tiktoken库精确计算token数避免超出模型限制。切分完记得给每个段加一个唯一ID方便后续检索和引用。3.3 向量化与检索的实操细节向量化就是把文本转成一串数字语义相近的文本向量距离近。OpenAI提供了embedding接口调用很简单。def get_embedding(text): response client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding把所有段落的向量存到FAISS索引里。用户提问时把问题也转成向量然后在索引里找最相似的K个段落。K一般取3到5太多会引入噪声太少可能漏掉关键信息。检索到段落之后组装提示词。我的模板是这样的你是一个文档问答助手。请根据以下参考文档回答用户问题。 如果文档中没有相关信息请直接说“文档中未提及”不要编造。 参考文档 {检索到的段落} 用户问题{用户问题}这个提示词的关键在于“不要编造”这句。没有这句约束模型很容易自由发挥。加上之后回答的可靠性明显提升。3.4 完整代码框架与运行效果把上面的模块串起来大概两百行代码就能跑通一个可用的版本。我实际部署时加了几个优化一是缓存embedding结果避免重复计算二是对检索结果做重排序用交叉编码器提升精度三是加了一个“不知道”的兜底逻辑当检索相似度低于阈值时直接回复“文档中未找到相关内容”。运行效果方面我拿一份50页的技术白皮书测试问了20个问题18个回答准确2个因为文档本身没写清楚而回复“未提及”。这个准确率对于内部知识库场景已经够用了。实操心得embedding模型建议用text-embedding-3-small性价比最高。large版本效果提升有限但成本翻了好几倍。除非对精度要求极高否则small足够。4. 常见问题与排查技巧实录开发过程中遇到的问题五花八门我挑几个最有代表性的整理成速查表。问题现象可能原因排查方法解决方案接口返回401API Key无效或过期检查Key是否正确复制重新生成Key确认账户余额返回内容被截断max_tokens设太小查看finish_reason字段调大max_tokens或分段请求输出格式不稳定提示词约束不够检查提示词是否有格式说明加JSON schema约束加示例响应速度慢网络延迟或模型负载高测ping换时间段测试用流式输出加本地缓存费用超预期上下文太长或调用频繁查看用量统计压缩历史加缓存设预算上限模型胡编乱造缺乏事实约束检查提示词加“不知道就说不知道”用RAG多轮对话混乱历史管理不当检查messages列表限制历史轮数做摘要压缩4.1 输出格式不稳定的根治方法这是最高频的问题。模型有时候返回纯文本有时候返回带Markdown的有时候JSON里多一个逗号。我的根治方法是用函数调用强制结构化输出。定义一个函数参数就是你要的字段让模型必须通过函数调用来返回。这样格式由schema保证不会跑偏。如果不用函数调用那就在提示词里把格式写到极致。比如“返回JSON不要有任何其他文字不要用Markdown代码块包裹字段名用双引号”。然后加一个解析失败的兜底逻辑失败就重试一次。4.2 费用控制的三个实用技巧第一缓存。相同或相似的问题直接返回缓存结果。我用Redis做缓存命中率大概30%费用直接降三成。第二压缩上下文。历史对话不要全发保留最近几轮更早的做摘要。摘要可以让模型生成成本很低。第三选对模型。不是所有任务都需要最强的模型。简单分类、提取关键词用便宜的小模型复杂推理再用大模型。我一般先用小模型试效果不够再换大的。4.3 网络与连接问题的排查思路接口调不通先分清楚是网络问题还是账户问题。网络问题表现为超时、连接被拒账户问题表现为401、429。超时的话检查你的服务器能不能正常访问外部服务DNS解析是否正常。429是限流需要加退避重试逻辑。import time def call_with_retry(func, max_retries3): for i in range(max_retries): try: return func() except Exception as e: if i max_retries - 1: raise time.sleep(2 ** i)这个指数退避重试逻辑很实用能解决大部分临时性故障。注意重试次数不要太多否则用户等太久。4.4 模型“不听话”时的提示词调试技巧模型不按你要求的格式输出或者答非所问九成是提示词的问题。我的调试步骤先简化提示词只保留最核心的指令看模型能不能正确执行。然后逐步加约束每加一条测试一次定位是哪条约束导致的问题。另一个技巧是把指令放在用户消息里而不是系统消息里。有些模型对系统消息的遵循度不如用户消息。我试过同样的内容放系统消息里模型忽略放用户消息里就乖乖执行。这个因模型而异但值得一试。注意不要指望一次写出完美的提示词。我做一个功能提示词至少迭代十几次。每次改完拿一组测试用例跑一遍记录通过率慢慢就调优了。5. 从Demo到产品上线前必须考虑的几件事代码跑通只是第一步真正上线还有很多坑。我按重要性排序讲几个。5.1 错误处理与降级方案ChatGPT接口不是100%可用的。网络抖动、服务限流、模型过载都会导致调用失败。你的应用必须有降级方案。最简单的降级是返回一个友好的错误提示让用户稍后重试。好一点的降级是切换到备用模型或者返回缓存中的相似答案。我在生产环境里设了三层降级主模型调用失败 → 切备用模型 → 备用也失败 → 返回预设的兜底话术。同时记录失败日志方便后续分析。5.2 用户输入的安全过滤用户可能输入各种奇怪的内容包括试图让模型执行危险操作的提示词。虽然模型本身有安全对齐但你不能完全依赖它。我的做法是在输入端加一层过滤检测明显的恶意模式比如“忽略之前的指令”、“你现在是...”这类。检测到就直接拒绝不发给模型。输出端也要过滤。模型可能生成不适当的内容尤其是用户诱导的情况下。加一个关键词黑名单命中就替换或拦截。5.3 性能优化让响应更快用户能接受的等待时间大概是3秒以内。超过这个数体验就明显下降。优化手段有几个一是用流式输出让用户先看到内容二是缓存高频问题的答案三是并行处理比如检索和意图识别同时做四是选离用户近的服务器节点。我实测下来流式输出对感知速度的提升最明显。同样3秒的总耗时流式输出用户1秒内就能看到第一个字感觉快很多。5.4 成本监控与预算控制上线前一定要设预算上限。我见过有人忘了设限一夜之间跑掉几千块。OpenAI后台可以设硬限制和软限制硬限制到了直接停软限制到了发邮件提醒。另外按项目维度记录token消耗方便分析哪个功能最费钱。如果预算紧张可以考虑用开源模型替代部分场景。比如简单的文本分类、关键词提取用本地部署的小模型完全够用成本几乎为零。复杂任务再调ChatGPT。这种混合架构能省不少钱。6. 进阶方向让应用更智能的几种思路基础版本跑通之后可以考虑加一些进阶能力。6.1 多轮对话的状态管理简单的多轮对话就是保留历史消息。但复杂场景下你需要管理对话状态。比如订票场景用户说“帮我订一张去北京的票”然后说“改成上海”模型需要知道“改成”指的是修改目的地。这需要维护一个结构化的状态对象记录当前任务的各个槽位。我的做法是用函数调用来更新状态。定义一个update_state函数模型每次识别到用户意图变化就调用它参数是变化的字段。这样状态管理就变成了函数调用逻辑清晰不容易乱。6.2 接入外部知识库的RAG优化基础RAG就是向量检索加生成。优化方向有几个一是混合检索向量检索加关键词检索取长补短二是重排序用交叉编码器对检索结果精排三是查询改写让模型先把用户问题改写成更适合检索的形式。查询改写效果很明显。用户问“这个怎么弄”直接检索可能找不到相关内容。让模型先改写成“XX功能的操作步骤”检索命中率大幅提升。这个改写本身也是一次模型调用成本很低但收益很高。6.3 多模型路由与成本优化不同任务用不同模型。简单任务用小模型复杂任务用大模型。怎么判断任务复杂度可以用一个轻量分类器或者直接用规则。比如问题长度超过一定阈值、包含多个子问题就路由到大模型。我做过一个路由层根据问题类型分发到不同模型。整体成本降了40%效果几乎没损失。这个思路值得一试。6.4 用户反馈闭环与持续迭代上线不是终点。收集用户反馈标记哪些回答好、哪些不好用这些数据持续优化提示词和检索策略。我一般会加一个“这个回答有帮助吗”的按钮用户点踩的回答人工review找出共性问题。积累几百条反馈之后你会发现一些规律。比如某类问题模型总是答不好那就针对性优化提示词或者补充相关知识库。这个迭代过程是产品越来越好的关键。最后分享一个小技巧做AI应用不要追求一步到位。先做一个能跑的最小版本上线收集反馈然后快速迭代。我见过太多人憋大招做了三个月还没上线结果方向错了全白费。小步快跑快速验证才是做AI产品的正确姿势。 ChatGPT应用开发实战：从接口调用到产品级封装
1. 从“会用”到“会造”拆解ChatGPT应用开发的核心思路很多人第一次接触ChatGPT停留在“问一句答一句”的聊天层面。但真正让开发者兴奋的是把它当成一个可编程的推理引擎嵌进自己的产品里。我最初也是从写提示词玩起后来发现光靠对话框根本撑不起一个完整应用——你需要处理上下文、管理会话状态、控制输出格式、对接外部数据。这些活儿才是“创建人工智能应用程序”的真正门槛。所谓用ChatGPT创建人工智能应用程序本质上是三件事的叠加大模型能力调用、业务逻辑编排、用户交互封装。ChatGPT在这里扮演的是“大脑”它负责理解意图、生成内容、做出判断而你的代码负责给它喂数据、约束它的行为、把它的输出变成用户能用的功能。适合谁来参考如果你有基础编程能力想做一个智能客服、文档问答助手、内容生成工具或者只是想搞明白那些AI产品到底怎么搭出来的这篇内容就是为你准备的。我见过太多人卡在第一步以为要训练模型、要买GPU、要搞深度学习。其实完全不用。调用现成的模型接口配合合理的工程架构就能做出体验相当不错的产品。下面我按实际开发顺序把每个环节拆开讲。1.1 为什么选ChatGPT而不是自己训模型自己训练一个可用的对话模型成本至少是百万级人民币起步还需要专业算法团队。而调用ChatGPT的接口按token计费一个中小型应用每月的成本可能就几十到几百块。这个账很好算你花在训练上的钱和时间足够你把产品迭代几十个版本了。更重要的是ChatGPT的能力边界足够宽。它能写代码、能翻译、能总结、能做逻辑推理这意味着你不需要为每个功能单独准备模型。一个接口多种用途。我在做文档问答工具时同一个模型既负责理解用户问题又负责从检索到的段落里提取答案还负责把答案改写成友好的语气。如果换成传统方案至少需要三个不同的NLP模型串联。当然选ChatGPT也有代价。你依赖外部服务网络延迟、接口限流、费用波动都是风险。所以架构设计上必须考虑降级方案和缓存策略这个后面会细说。1.2 应用架构的三种典型模式根据我实际做过的项目用ChatGPT构建应用大致分三种模式复杂度依次递增。第一种是直连模式用户输入直接发给ChatGPT返回结果直接展示。适合做简单的翻译工具、文案生成器。开发量极小一个接口调用就搞定。缺点是没法处理复杂任务模型容易跑偏。第二种是编排模式在用户和模型之间加一层逻辑层。这层逻辑负责组装提示词、管理对话历史、调用外部工具、校验输出格式。大部分有价值的AI应用都属于这一类。比如智能客服你需要先从知识库检索相关文档把文档内容塞进提示词再让模型基于文档回答。这层编排逻辑才是你产品的核心竞争力。第三种是代理模式让模型自己决定调用哪些工具、按什么顺序执行。比如用户说“帮我查一下明天北京的天气然后推荐穿什么衣服”模型需要先调用天气接口拿到结果后再推理穿衣建议。这种模式最接近“智能体”的概念开发难度也最高需要处理工具调用的异常、循环终止条件、多步推理的中间状态。我建议新手从第二种模式入手。直连模式太简单学不到东西代理模式太复杂容易劝退。编排模式刚好能让你理解AI应用的核心工程问题。1.3 关键设计决策提示词工程与上下文管理提示词不是随便写几句话就完事。我踩过的最大坑就是早期把提示词写得太随意导致模型输出格式不稳定前端解析经常报错。后来我总结了一套模板结构角色定义 任务描述 输出格式约束 示例。这四部分缺一不可。角色定义让模型知道自己是干什么的比如“你是一个专业的法律文书助手”。任务描述说清楚要做什么比如“根据用户提供的案情生成一份起诉状草稿”。输出格式约束最关键你要明确告诉模型返回JSON还是Markdown每个字段叫什么名字。示例则是给模型一个参照尤其是复杂格式给一个例子比写十句描述都管用。上下文管理是另一个容易被忽视的点。ChatGPT接口本身是无状态的每次调用都要把历史对话重新发过去。但你不能无限往里面塞历史token有上限费用也会飙升。我的做法是保留最近N轮对话同时对更早的历史做摘要压缩。摘要本身也可以让模型来做成本很低。提示上下文窗口不是越大越好。塞太多无关历史反而会干扰模型对当前问题的判断。我一般保留最近5到10轮具体看任务复杂度。2. 核心细节解析从接口调用到产品级封装这一部分讲具体的技术实现。我会以Python为例因为生态最成熟文档最全。其他语言逻辑类似只是SDK不同。2.1 接口调用的最小可行代码先看最基础的调用。你需要一个API Key这个在平台后台申请。然后安装官方SDK写几行代码就能跑通。from openai import OpenAI client OpenAI(api_key你的API Key) response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 你是一个 helpful 的助手}, {role: user, content: 用一句话解释什么是机器学习} ], temperature0.7, max_tokens200 ) print(response.choices[0].message.content)这段代码里model参数指定用哪个模型。messages是一个列表包含系统角色和用户角色。temperature控制随机性0表示最确定1表示最随机。max_tokens限制返回长度防止费用失控。我建议新手先把这段代码跑通理解每个参数的含义。然后逐步加功能加多轮对话、加流式输出、加错误处理。2.2 参数调优temperature、top_p与惩罚项这几个参数直接决定输出质量但很多人调不好。我按实际经验给一组参考值。参数作用推荐范围适用场景temperature控制随机性0.2-0.5事实问答、代码生成temperature控制随机性0.7-0.9创意写作、头脑风暴top_p核采样控制候选词范围0.9-1.0一般配合temperature使用frequency_penalty降低重复词频率0.0-0.5长文本生成防止复读presence_penalty鼓励引入新话题0.0-0.5对话场景避免绕圈子我的习惯是做工具类应用temperature设0.3做内容生成设0.8。frequency_penalty和presence_penalty一般不动除非发现模型明显在重复。注意temperature和top_p不建议同时调选一个调就行两个都调容易让输出变得不可控。2.3 流式输出让用户不用干等ChatGPT网页版那种一个字一个字往外蹦的效果就是流式输出。技术上通过SSEServer-Sent Events实现。好处是用户感知的响应时间大幅缩短体验好很多。stream client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 写一首关于秋天的诗}], streamTrue ) for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)流式输出有个坑你没法在生成过程中做格式校验。因为内容是一段段来的可能前半段是合法JSON后半段突然多了个逗号。所以如果应用对输出格式要求严格要么等完整返回后再校验要么在提示词里把格式约束写得极其明确。2.4 函数调用让模型操作你的系统这是从“聊天”到“应用”的关键一步。函数调用允许你定义一组工具模型根据用户意图决定调用哪个并返回结构化参数。比如用户说“帮我查一下订单12345的状态”模型会返回一个函数调用请求参数是订单号12345你的代码拿到后去查数据库再把结果喂回模型生成最终回复。tools [ { type: function, function: { name: query_order, description: 根据订单号查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } } ] response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: 订单12345到哪了}], toolstools, tool_choiceauto )模型返回的tool_calls字段里包含函数名和参数。你执行完函数后把结果以role: tool的消息追加到对话里再次调用模型它就会基于函数结果生成自然语言回复。这个机制让AI应用真正有了“手脚”。我做过一个内部工具把数据库查询、邮件发送、日历创建都封装成函数用户用自然语言就能完成复杂操作。开发量不大但体验提升非常明显。注意函数调用的参数校验一定要做。模型可能返回不存在的订单号或者格式不对的参数。你的代码必须能处理这些异常不能直接信任模型输出。3. 实操过程从零搭建一个文档问答助手光讲理论没意思我带你走一遍完整流程。这个助手的功能是用户上传PDF文档然后可以针对文档内容提问助手基于文档回答。这是最常见的AI应用形态之一。3.1 技术选型与整体流程核心组件四个文档解析、文本切分、向量检索、对话生成。文档解析用PyPDF2或pdfplumber文本切分自己写逻辑向量检索用开源的FAISS或Chroma对话生成调ChatGPT接口。整体流程用户上传PDF → 解析出文本 → 切成小段 → 每段转成向量存起来 → 用户提问 → 问题转向量 → 检索最相似的段落 → 把段落和问题一起发给ChatGPT → 返回答案。这个架构叫RAG检索增强生成是目前最实用的AI应用模式。它解决了大模型的两个痛点一是模型不知道你的私有数据二是模型容易胡编乱造。通过检索相关文档作为依据答案的准确性和可信度大幅提升。3.2 文档切分的参数计算与实操切分看着简单其实很讲究。切太大检索精度下降切太小语义不完整。我的经验值是每段300到500个token相邻段之间重叠50到100个token。为什么要有重叠因为一句话可能被切断导致语义丢失。重叠部分保证每个关键信息至少完整出现在一个段里。具体计算假设你的文档平均每100个token对应200个汉字那300个token大约是600个汉字。你可以按段落切如果段落太长再按句子切。def split_text(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks这是按字符切的简化版。实际项目中我会用tiktoken库精确计算token数避免超出模型限制。切分完记得给每个段加一个唯一ID方便后续检索和引用。3.3 向量化与检索的实操细节向量化就是把文本转成一串数字语义相近的文本向量距离近。OpenAI提供了embedding接口调用很简单。def get_embedding(text): response client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding把所有段落的向量存到FAISS索引里。用户提问时把问题也转成向量然后在索引里找最相似的K个段落。K一般取3到5太多会引入噪声太少可能漏掉关键信息。检索到段落之后组装提示词。我的模板是这样的你是一个文档问答助手。请根据以下参考文档回答用户问题。 如果文档中没有相关信息请直接说“文档中未提及”不要编造。 参考文档 {检索到的段落} 用户问题{用户问题}这个提示词的关键在于“不要编造”这句。没有这句约束模型很容易自由发挥。加上之后回答的可靠性明显提升。3.4 完整代码框架与运行效果把上面的模块串起来大概两百行代码就能跑通一个可用的版本。我实际部署时加了几个优化一是缓存embedding结果避免重复计算二是对检索结果做重排序用交叉编码器提升精度三是加了一个“不知道”的兜底逻辑当检索相似度低于阈值时直接回复“文档中未找到相关内容”。运行效果方面我拿一份50页的技术白皮书测试问了20个问题18个回答准确2个因为文档本身没写清楚而回复“未提及”。这个准确率对于内部知识库场景已经够用了。实操心得embedding模型建议用text-embedding-3-small性价比最高。large版本效果提升有限但成本翻了好几倍。除非对精度要求极高否则small足够。4. 常见问题与排查技巧实录开发过程中遇到的问题五花八门我挑几个最有代表性的整理成速查表。问题现象可能原因排查方法解决方案接口返回401API Key无效或过期检查Key是否正确复制重新生成Key确认账户余额返回内容被截断max_tokens设太小查看finish_reason字段调大max_tokens或分段请求输出格式不稳定提示词约束不够检查提示词是否有格式说明加JSON schema约束加示例响应速度慢网络延迟或模型负载高测ping换时间段测试用流式输出加本地缓存费用超预期上下文太长或调用频繁查看用量统计压缩历史加缓存设预算上限模型胡编乱造缺乏事实约束检查提示词加“不知道就说不知道”用RAG多轮对话混乱历史管理不当检查messages列表限制历史轮数做摘要压缩4.1 输出格式不稳定的根治方法这是最高频的问题。模型有时候返回纯文本有时候返回带Markdown的有时候JSON里多一个逗号。我的根治方法是用函数调用强制结构化输出。定义一个函数参数就是你要的字段让模型必须通过函数调用来返回。这样格式由schema保证不会跑偏。如果不用函数调用那就在提示词里把格式写到极致。比如“返回JSON不要有任何其他文字不要用Markdown代码块包裹字段名用双引号”。然后加一个解析失败的兜底逻辑失败就重试一次。4.2 费用控制的三个实用技巧第一缓存。相同或相似的问题直接返回缓存结果。我用Redis做缓存命中率大概30%费用直接降三成。第二压缩上下文。历史对话不要全发保留最近几轮更早的做摘要。摘要可以让模型生成成本很低。第三选对模型。不是所有任务都需要最强的模型。简单分类、提取关键词用便宜的小模型复杂推理再用大模型。我一般先用小模型试效果不够再换大的。4.3 网络与连接问题的排查思路接口调不通先分清楚是网络问题还是账户问题。网络问题表现为超时、连接被拒账户问题表现为401、429。超时的话检查你的服务器能不能正常访问外部服务DNS解析是否正常。429是限流需要加退避重试逻辑。import time def call_with_retry(func, max_retries3): for i in range(max_retries): try: return func() except Exception as e: if i max_retries - 1: raise time.sleep(2 ** i)这个指数退避重试逻辑很实用能解决大部分临时性故障。注意重试次数不要太多否则用户等太久。4.4 模型“不听话”时的提示词调试技巧模型不按你要求的格式输出或者答非所问九成是提示词的问题。我的调试步骤先简化提示词只保留最核心的指令看模型能不能正确执行。然后逐步加约束每加一条测试一次定位是哪条约束导致的问题。另一个技巧是把指令放在用户消息里而不是系统消息里。有些模型对系统消息的遵循度不如用户消息。我试过同样的内容放系统消息里模型忽略放用户消息里就乖乖执行。这个因模型而异但值得一试。注意不要指望一次写出完美的提示词。我做一个功能提示词至少迭代十几次。每次改完拿一组测试用例跑一遍记录通过率慢慢就调优了。5. 从Demo到产品上线前必须考虑的几件事代码跑通只是第一步真正上线还有很多坑。我按重要性排序讲几个。5.1 错误处理与降级方案ChatGPT接口不是100%可用的。网络抖动、服务限流、模型过载都会导致调用失败。你的应用必须有降级方案。最简单的降级是返回一个友好的错误提示让用户稍后重试。好一点的降级是切换到备用模型或者返回缓存中的相似答案。我在生产环境里设了三层降级主模型调用失败 → 切备用模型 → 备用也失败 → 返回预设的兜底话术。同时记录失败日志方便后续分析。5.2 用户输入的安全过滤用户可能输入各种奇怪的内容包括试图让模型执行危险操作的提示词。虽然模型本身有安全对齐但你不能完全依赖它。我的做法是在输入端加一层过滤检测明显的恶意模式比如“忽略之前的指令”、“你现在是...”这类。检测到就直接拒绝不发给模型。输出端也要过滤。模型可能生成不适当的内容尤其是用户诱导的情况下。加一个关键词黑名单命中就替换或拦截。5.3 性能优化让响应更快用户能接受的等待时间大概是3秒以内。超过这个数体验就明显下降。优化手段有几个一是用流式输出让用户先看到内容二是缓存高频问题的答案三是并行处理比如检索和意图识别同时做四是选离用户近的服务器节点。我实测下来流式输出对感知速度的提升最明显。同样3秒的总耗时流式输出用户1秒内就能看到第一个字感觉快很多。5.4 成本监控与预算控制上线前一定要设预算上限。我见过有人忘了设限一夜之间跑掉几千块。OpenAI后台可以设硬限制和软限制硬限制到了直接停软限制到了发邮件提醒。另外按项目维度记录token消耗方便分析哪个功能最费钱。如果预算紧张可以考虑用开源模型替代部分场景。比如简单的文本分类、关键词提取用本地部署的小模型完全够用成本几乎为零。复杂任务再调ChatGPT。这种混合架构能省不少钱。6. 进阶方向让应用更智能的几种思路基础版本跑通之后可以考虑加一些进阶能力。6.1 多轮对话的状态管理简单的多轮对话就是保留历史消息。但复杂场景下你需要管理对话状态。比如订票场景用户说“帮我订一张去北京的票”然后说“改成上海”模型需要知道“改成”指的是修改目的地。这需要维护一个结构化的状态对象记录当前任务的各个槽位。我的做法是用函数调用来更新状态。定义一个update_state函数模型每次识别到用户意图变化就调用它参数是变化的字段。这样状态管理就变成了函数调用逻辑清晰不容易乱。6.2 接入外部知识库的RAG优化基础RAG就是向量检索加生成。优化方向有几个一是混合检索向量检索加关键词检索取长补短二是重排序用交叉编码器对检索结果精排三是查询改写让模型先把用户问题改写成更适合检索的形式。查询改写效果很明显。用户问“这个怎么弄”直接检索可能找不到相关内容。让模型先改写成“XX功能的操作步骤”检索命中率大幅提升。这个改写本身也是一次模型调用成本很低但收益很高。6.3 多模型路由与成本优化不同任务用不同模型。简单任务用小模型复杂任务用大模型。怎么判断任务复杂度可以用一个轻量分类器或者直接用规则。比如问题长度超过一定阈值、包含多个子问题就路由到大模型。我做过一个路由层根据问题类型分发到不同模型。整体成本降了40%效果几乎没损失。这个思路值得一试。6.4 用户反馈闭环与持续迭代上线不是终点。收集用户反馈标记哪些回答好、哪些不好用这些数据持续优化提示词和检索策略。我一般会加一个“这个回答有帮助吗”的按钮用户点踩的回答人工review找出共性问题。积累几百条反馈之后你会发现一些规律。比如某类问题模型总是答不好那就针对性优化提示词或者补充相关知识库。这个迭代过程是产品越来越好的关键。最后分享一个小技巧做AI应用不要追求一步到位。先做一个能跑的最小版本上线收集反馈然后快速迭代。我见过太多人憋大招做了三个月还没上线结果方向错了全白费。小步快跑快速验证才是做AI产品的正确姿势。