简介这是一份由Olivier Caelen与Marie-Alice Blete合著、OReilly Media出品的英文技术电子书围绕GPT-4与ChatGPT讲解如何构建智能聊天机器人、内容生成器及应用面向希望将大语言模型引入实际产品开发的中高级开发者与算法工程师。当前展示的是Early Release版本开篇从GPT-4与ChatGPT的核心基础切入逐步拆解模型能力边界、交互方式与开发环境准备帮助读者在正式版出版前尽早掌握相关技术脉络。全书以第一章“GPT-4 and ChatGPT Essentials”为起点系统介绍必备知识后续章节则聚焦应用开发路径适合作为从理论认知过渡到动手实践的桥梁读物。资源包内共1个文件类型为PDF文档整体体积仅2.86MB文件紧凑便于移动端或离线阅读目前已有1133人学习或下载印证了其在开发者群体中的参考价值。读者可在早期版本中快速获得大模型应用开发的全局视图与设计启发包括如何组织对话流程、选择合适的模型能力以及规划智能化功能落地为自建ChatGPT类应用打下扎实基础。1. 慢着这不止是一本 API 手册那么简单不少开发者拿到《Developing Apps with GPT-4 and ChatGPT》这份资料后第一反应是把它当成打交道用的大模型接口文档来查。带着这个预期去读通常第一遍就会失望里面没有完整的端点清单没有标准化的错误码表通篇更像是一位老工程师在讲——一个真正可用的 GPT-4 应用是用什么样的骨架把对话能力组织起来的。它真正要解决的是能聊天和能当应用之间的那道设计鸿沟谁在主控、谁来记状态、模型输出怎么变成系统里真实发生的动作。适合的是那些已经试过提示词、发现单靠调话术总在原地打转正想把原型往生产推的开发者。读它之前最好先把心态切到做工程设计而不是查字典。2. 把聊天变成应用GPT-4 应用的主控模型与最小骨架2.1 为什么对话编排是应用骨架而不是提示词的事一个常见误用是觉得 GPT-4 应用 把提示词写长一点 把用户问题丢进去 展示返回结果。这种单发请求的写法做 Demo 可以做真实功能马上会撞上三堵墙。第一堵是状态墙用户说把刚才那个订单取消应用根本不知道刚才那个指哪个订单因为每次请求都是独立的上下文在你的代码里而不在模型里。第二堵是权限墙模型只能输出文字它没法真的去查库存、改数据库、发通知所有动作都得由你的代码执行。第三堵是成本墙一个像样的业务流程光靠提示词把所有规则塞进一次请求Token 消耗会膨胀到没法商用。所以翻开这本书真正值得先吸收的是一句话GPT-4 只是你系统里的一个组件它有输入输出有擅长的推理但它不拥有你的业务状态。应用的主控权在你自己写的编排层里。编排层负责决定什么时候把请求发给模型、带哪些上下文、模型回复之后要执行什么本地逻辑模型负责的是其中理解和生成这一段。把这个边界划清楚后面所有的参数调整、函数调用、上下文管理才有的放矢。我一般会在项目里先画一张数据流草图用户输入先进路由路由判断走哪个子任务子任务决定怎么组装消息组装后的消息发给模型模型输出交给一个解释器解释器转成具体的函数调用。这张图画完代码写起来就是填空。下面这个最小骨架就是把这张草图落成可运行代码的第一步。2.2 一个能直接跑起来的 Python 最小应用请求封装与参数说明# 该示例用于演示 GPT-4 应用的最小请求骨架请替换为实际可用的配置 import os import json import requests # 所有连接信息从环境变量读取避免硬编码密钥 API_BASE os.environ.get(GPT_API_BASE) # 接口入口地址 API_KEY os.environ.get(GPT_API_KEY) # 访问密钥 MODEL os.environ.get(GPT_MODEL, gpt-4) # 模型名默认取 gpt-4 def chat_once(messages, temperature0.3, max_tokens1024): 发送一次对话请求返回消息内容。 url f{API_BASE}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: messages, temperature: temperature, max_tokens: max_tokens, } resp requests.post(url, headersheaders, jsonpayload, timeout(5, 30)) resp.raise_for_status() # 非 2xx 直接抛异常方便上层感知 data resp.json() return data[choices][0][message][content] # 带上少量历史消息的调用方式 if __name__ __main__: messages [ {role: system, content: 你是一个订单助手回答要简短。}, {role: user, content: 我的订单 SZ20240101 什么时候发货}, ] reply chat_once(messages) print(reply)这段代码做的事情很朴素把消息列表发送出去拿到完整的返回内容。但它把几个关键参数暴露出来了。temperature控制随机性值越低输出越确定订单查询这类功能我通常压在 0.2 附近文案创作再放到 0.7 以上。max_tokens是输出上限不是整体上限它直接影响成本和响应时间宁可设小一点再截断提示也不要让它无节制地生成。timeout(5, 30)把连接超时和读取超时分开前者 5 秒后者 30 秒避免网络抖动时请求长时间挂起。messages是结构的核心。它由 system、user、assistant 三类消息组成system 消息定义模型的角色和行为边界user 是本次输入assistant 历史消息则负责把之前的对话语境带回来。注意这里每个消息都带role字段API 靠这个字段判断对话顺序乱序会导致上下文错乱。另外历史消息里如果含有已执行动作的结果应该单独用一段拼接进去比如系统已取消订单 #1234而不是只放一句模型说过的好的。2.3 意图路由与上下文管理让一次对话干多件事最小骨架跑通之后下一步是处理用户什么都会问的现实。不能把所有话都丢给一个 system 消息去管那样提示词会越写越长、互相打架。常见做法是加一层意图路由先判断用户来干什么再决定用哪套提示词和哪套工具。这一步可以用关键词规则做也可以用模型做规则优先因为规则可控、零成本。# 意图路由先用简单规则快速分流再考虑是否引入模型判断 INTENT_RULES [ (查订单, [订单, 物流, 发货, 快递]), (退换货, [退货, 换货, 退款, 售后]), (咨询, [怎么, 什么, 如何, ?]), ] def route(intent_text): 返回命中的意图名称未命中返回默认值。 for intent, keywords in INTENT_RULES: if any(kw in intent_text for kw in keywords): return intent return default def build_prompt(intent): 不同意图使用不同的 system 指令与上下文策略。 prompt_map { 查订单: 只回答订单状态与物流信息不确定时直接说明。, 退换货: 引导用户确认订单号先解释退换流程再收集信息。, 咨询: 回答产品相关问题涉及价格时要提示可能变化。, } return prompt_map.get(intent, 你是通用助理回答简洁。)路由做对之后上下文管理就有了边界查订单的对话只把订单表和物流消息拼进去退换货的对话只带售后政策。不同意图之间不要共享消息历史否则模型会被无关内容干扰Token 也会浪费。这里有个细节判断完意图之后build_prompt返回的 system 消息要放在消息列表的第一位并且历史消息只保留最近 N 轮超出部分用一句摘要代替。摘要怎么写也有讲究不要写用户问了发货时间而要写用户等待订单 SZ20240101 的发货确认保留关键实体。到这里骨架已经能处理多类任务 多轮对话了。但此时模型还只能说话不能做事。真正让它从聊天机器人变成应用的是下一步要给模型装上的工具调用能力。3. 给模型装上手功能调用是应用开发的分水岭3.1 为什么功能调用改变了应用写法在功能调用出现之前让模型执行动作的常见路子是让模型输出一段约定格式的文本比如调用函数check_order参数{order_id: 123}然后再写正则去解析。这个方案在演示环境能用一上真实业务就摇摇欲坠。模型偶尔会在括号里多加一个引号、把字段名缩写、或者直接说我要调用函数了但是忘了参数任何一个小偏差都会让解析器静默失败然后用户收到系统繁忙。功能调用机制相当于把让模型声明自己要用什么工具、传什么参数这件事从文本协议升级成了结构化协议。模型输出的不是自然语言是带类型标记的函数名和参数列表你的代码只需要解析这个结构、执行对应函数、把结果回填给模型。这样一来解析失败率大幅下降模型 → 代码这条链路的可靠性问题是靠协议本身解决的不是靠更灵活的提示词碰运气。但这套机制不是自动生效的你要做三件事定义工具清单、把清单随请求发出、处理模型回传的调用请求。工具清单本质上是 JSON Schema字段名、类型、必填项写清楚模型才能按规范生成参数。下面用一个订单查询工具走一遍。3.2 注册工具与解析请求一个订单查询的工具示例# 工具定义一个订单查询函数 TOOLS [ { type: function, function: { name: query_order, description: 根据订单号查询订单状态与物流信息, parameters: { type: object, properties: { order_id: { type: string, description: 订单号格式为字母 SZ 加数字, } }, required: [order_id], }, }, } ] def query_order(order_id): 实际执行查询的本地函数返回结果给模型。 # 这里应该是查数据库或调内部服务演示用静态数据 if order_id SZ20240101: return {status: shipped, eta: 2024-02-01} return {status: not_found} def run_conversation(messages): 发送携带工具定义的请求处理模型的调用请求。 payload { model: MODEL, messages: messages, tools: TOOLS, tool_choice: auto, # 让模型自行决定是否需要调用工具 } resp requests.post(f{API_BASE}/chat/completions, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout(5, 30)) return resp.json()注意tool_choice这个参数。设成auto表示模型按需决定如果你希望某次对话必须使用某个工具可以直接写{type: function, function: {name: query_order}}。description字段要尽量写清楚工具的使用边界模型是靠它来匹配用户意图的写根据订单号查询比写查询函数好用得多。参数 schema 里required不要滥用确有必要才填否则模型为了凑齐参数可能会编造值。响应里如果模型确实想调用工具会多出一个tool_calls字段内容包含工具名和参数对象。此时message.content通常是空的你的代码看到tool_calls就必须转向执行分支而不要试图去读自然语言回复。3.3 完整闭环执行本地函数并回填结果# 处理工具调用并回填形成模型请求 - 代码执行 - 结果返回闭环 def execute_tool_calls(message, messages): 解析模型返回的工具调用执行本地函数并把结果追加到消息历史。 if not message.get(tool_calls): return messages messages.append({role: assistant, content: None, tool_calls: message[tool_calls]}) for call in message[tool_calls]: func_name call[function][name] raw_args json.loads(call[function][arguments]) if call[function].get(arguments) else {} print(f[exec] {func_name}({raw_args})) # 本地日志便于排查 if func_name query_order: result query_order(raw_args.get(order_id)) else: result {error: funknown function: {func_name}} messages.append({ role: tool, tool_call_id: call[id], content: json.dumps(result, ensure_asciiFalse), }) return messages这段代码的核心有两处。一处是把助手消息带着tool_calls原样放回历史这是协议要求的乱改会报格式错误另一处是每条工具结果都要带上tool_call_id这个 ID 来自模型给你的调用请求保证结果和调用是一一对应的。回填之后要把整套messages再发一次请求模型会读取工具返回的 JSON组织成给用户的自然语言回复。所以一次带工具的操作实际上会发起两轮请求第一轮拿到调用意图第二轮拿到最终答复。边界在哪儿一是所有本地函数必须快速返回如果查询要几秒建议先给模型一个查询中的中间状态再异步回填而不是阻塞整个对话。二是函数执行要放在沙箱环境里别让模型能直接调用删除或写库的裸函数一定要包一层校验比如检查订单号格式、核对当前用户是否有权限。三是工具数量控制在十个以内太多的工具定义会吃掉大量上下文空间而且模型容易选错工具必要时做分组的做法是先路由到业务域再给该业务域单独传一组工具。到这里一个完整的带手应用已经成型了。但细节里藏着的坑往往是在开发环境欢快地跑通、到了生产就原形毕露的。下面是我建议你在上生产之前逐条对着排查的五个场景。4. 上生产前先排雷GPT-4 应用最容易翻车的 5 个场景4.1 上下文无限膨胀账单和延迟是怎么失控的现象应用刚上线正常跑了几天后响应越来越慢费用曲线陡增偶尔报上下文超长错误。原因代码把用户每次对话的原始消息全部追加进messages从不清理。会话越长每次请求带的 Token 越多模型处理时间随之变长费用按输入 Token 计费自然水涨船高。解决给会话设置窗口策略。保留最近 6 轮对话原文超出部分让模型生成一条摘要塞进系统消息摘要专注于保留业务关键信息订单号、用户意图、已确认的前提条件、待办事项。另一种做法是超过窗口直接截断并提醒用户较早的消息已被压缩多数场景下用户是可以接受的。关键是这个逻辑要写在会话服务里而不是靠调用方自觉。4.2 同一个提示词换了模型版本就翻车现象开发环境用 A 版本模型调试好的一套提示词部署到线上发现输出格式变了原本稳定的 JSON 结构开始漏字段。原因模型服务方会迭代版本行为随之微调你的提示词越苛刻、对格式要求越细版本变更的冲击就越大。这属于黑匣子变化不是你的代码逻辑出问题。解决把提示词里对格式的约束从描述性要求改成示例性要求。不只说返回 JSON要给一个完整的字段示例并注明严格按此结构不要添加额外字段。输出端再加一道校验层解析失败就重试一次并携带上次的错误信息让模型修正——这个自纠错流程比把提示词写到天花乱坠有用得多。4.3 超时重试后的重复动作现象用户在界面上点了一次取消订单等了十几秒没反应又点了一次结果产生两个取消请求。原因网络超时后客户端重试但第一次请求其实已经到达服务端并执行了只是响应没能及时返回。模型这边没有幂等概念同样的指令执行两次业务端就被重复下单或重复取消了。解决请求里带一个幂等键比如用会话 ID 加操作序号生成本地函数执行前先查幂等表已执行过就直接返回上次结果。这是一条事后补救也基本来不及的坑必须在设计工具调用时就预留request_id参数。像取消、转账这类敏感操作我还会在函数里加二次确认参数要求模型先确认用户意愿再执行进一步降低误操作概率。4.4 让模型输出 JSON结果却不是合法 JSON现象应用逻辑要求模型只输出结构化数据但它偶尔给你带json标记或者夹杂一句下面是你要的数据再贴上 JSON。原因模型生成的是文本不是数据对象。json.loads要求字符串百分之百合法多一个字符都会整个失败。解决优先用函数调用机制拿到结构化参数它走的是协议通道天然规避这个问题。如果一定要解析自然语言里的 JSON先用正则把代码围栏剥掉再定位第一个{和最后一个}截取片段最后解析。工具类 JSON 字段固定的话还可以用 pydantic 这类校验库做模型字段缺失时给出默认值而不是直接让整个请求失败。4.5 拿真实 API 当回归测试环境现象测试用例的断言经常飘同样输入有时通过有时失败测试跑完还产生一笔不小的费用。原因模型输出有随机性直接拿真实接口做断言等于把非确定性服务当成确定性服务来测再加上每次回归都在烧 Token。解决把模型调用封装成可替换的接口日常开发与回归测试注入本地录制好的样本响应只在发布前跑一轮真实链路做冒烟测试。回归用例聚焦两件事路由是否命中正确意图、工具调用参数是否生成正确用语义断言而非字符串相等。真实链路测试保留少数几条关键业务路径就够了其余交给样本库。这条习惯能同时把测试稳定性和成本两个问题摁住。5. 把开发成本打下来的最后一招本地回归样本库最后一招是我在做过一个订单助手型应用之后沉淀下来的习惯建一个本地回归样本库。它的思路是把所有和模型交互的边界场景固化成本地文件开发、联调、回归通通打在本地只在发布前才走一次真实模型。这样做的直接好处是测试不再受网络、额度和模型行为波动影响跑十遍和跑一遍结果一模一样。样本库的组织结构按场景分目录每个场景放一对输入输出文件输入存messages和工具定义输出存模型响应或工具调用结果。跑回归时把消息组装 → 模型调用 → 工具执行 → 回填再请求这条链路的模型调用部分替换成本地读取其他逻辑全部照走。覆盖面优先选这些单轮直接答复、多轮追问、工具调用成功、工具调用参数缺失、模型返回 JSON 夹杂多余文字、超长上下文触发截断。每个样本都对应一个曾经翻过车的现场记录的意义就是防止再翻。上面这个样本库的做法配合一个小的本地校验脚本把样本里的输出字段缺失、工具参数类型错误、幂等键重复这三类问题做成自动检查。每次改完提示词或路由逻辑跑一遍全量样本能看到哪些旧场景被改坏了再决定要不要收下这个变化。这套流程把模型应用开发从靠感觉调提示词变成了批量验证、坏了我知道对团队协作尤其有意义——新人接手也能通过样本快速理解系统行为。我自己在这条路上栽过的最大跟头就是刚上手时贪快跳过样本库直接拿真实 API 调了一天最后花在排查到底是我参数错了还是模型抽风上的时间比重写一遍还多。从那以后所有 GPT-4 相关的项目都坚持本地优先测试真实链路只做发布前的冒烟。项目越到后期这套习惯省下的钱和时间就越明显。如果你现在正被调好了又变、测了又飘折磨不妨先从录一个样本开始把一次成功调用固化下来再慢慢织成一张网。希望帮到你。本文还有配套的精品资源点击获取