企业官网建设流程全解析

简介：《Developing Apps with GPT-4 and ChatGPT》英文原版电子书，面向希望将大模型能力落地到实际产品中的开发者、产品经理与AI学习者，讨论如何基于GPT-4与ChatGPT构建智能聊天机器人、内容生成器及交互式应用。内容从模型能力与提示设计切入，延伸至API调用、对话上下文管理、输出质量控制、应用架构与集成部署等环节，兼顾概念解释与工程实践，适合具备一定编程基础、希望从“会用”走向“会做”的读者。资源为PDF格式，共1个文件，压缩包约2.86MB，便于在电脑和阅读器上查阅。已有1133人学习下载，在AI应用开发方向具有一定参考热度。读者可借此梳理从需求拆解、原型搭建到功能扩展的完整链路，理解聊天机器人、内容生成等场景的实现要点，并借助O'Reilly原版内容建立较系统的GPT应用开发知识框架。

1. 大语言模型到底是什么：从“接话茬”说起

微信群里有人发一句“今天天气不错，要不我们……”，底下立马有人接“出去走走”。没人教过他怎么接，他也没查过天气，但接得八九不离十。GPT-4 和 ChatGPT 干的活儿，核心跟这个“接话茬的人”很像：给一段上文，猜下一段最可能长什么样。如今 ai、ChatGPT 这类词天天刷屏，剥掉包装，中间的核心动作朴素得有点出人意料。搞懂这个动作，你就能明白它为什么能写文案、能当客服，也能一本正经地胡说八道。这份资料做的事，就是把这个动作拆开，再告诉你怎样把它接到自己的程序里。

2. 为什么会有 Transformer：一句话背后的一整套分工

2.1 从 AI 到大语言模型：一层套一层的嵌套关系

人工智能这个词现在被用得极泛，但比较公认的一种说法是：让计算机去完成那些通常需要人脑才能完成的任务。手机导航预测前方拥堵、策略游戏里会包抄的电脑对手，从外面看都挺“聪明”。不过这类系统多半是人把规则写死了，路况怎么变、兵力怎么配，都是工程师事先想好的判断，机器只是执行。

机器学习换了个路子。它不直接写判断规则，而是给算法一大堆例子，让它自己从例子里找规律。这个思路从 1950 年代就开始了，几十年里积累了一大批算法，深度学习是其中比较出名的一支——它用多层神经网络去自动提取特征，省掉了大量人工设计规则的功夫。再往下切一层，就是 transformer。它不是某个产品，而是一种网络结构的设计方案，2017 年被提出来，最初是为了解决机器翻译这类“输入一段序列、输出另一段序列”的问题。

把这条链摆清楚很重要，因为它解释了为什么一个做应用的人也要懂底层：AI 是个大圈，机器学习是里面的一个圈，深度学习再往里，transformer 又在深度学习的圈里。GPT-4 和 ChatGPT 站在这条链的最末端，是“大语言模型”。语言模型这个词听着玄，其实就一句话——它给一段文本算概率，判断下一个词最可能是什么。加个“大”字，指的是训练时喂进去的文本量和参数规模都到了一个新量级，量变引起质变，于是它不光能接话，还能翻译、分类、答问、写代码。

还有一个词经常和这些混在一起：自然语言处理，也就是 NLP。它不是一个层级，而是一个应用方向，研究的是计算机怎么和人写的文字打交道。文本分类、自动翻译、问答、文本生成，都在这个方向下面。现代 NLP 方案大多建立在机器学习之上，而大语言模型恰好是其中最擅长“生成”的那一类。

2.2 自注意力和交叉注意力：模型怎么知道该看哪儿

先想一个很日常的问题：一句话里某个字到底什么意思，很多时候得看它旁边站着谁。“苹果”单拎出来是水果，放进“苹果发布会”里就变成了品牌。早年的 n-gram 模型应对这个问题的办法很朴素——统计前面几个词后面最常跟哪个词，按频率挑一个。它只看很近的几个词，句子一长就抓瞎，写出来的东西常常前言不搭后语。后来的循环神经网络和长短期记忆网络能记住更长的序列，理解上下文的能力强了不少，但处理方式是一个词一个词往前推，数据一多就慢得让人难受。

注意力机制解决的就是“该看哪儿”这件事。它给句子里每个词分配一个权重，告诉模型：现在要处理的这个位置，前面哪些词更值得关注。打个比方，它像一盏聚光灯，照在输入文本的某些片段上，把无关的细节压暗。

这套机制有两种用法，名字很像，作用完全不同。

自注意力是模型看自己。处理一句话时，它评估句中每个词和其他词的关系有多紧密。举个例子：“小明收到了同事们的表扬，他很高兴。”要让模型弄明白“他”指的是谁，自注意力会把较高的权重分给“小明”，较低的分给“同事们”，于是“他”被正确绑定到小明身上。更进一步，模型还能从多个词的组合里长出新的概念，比如把“小明”和“同事们”连起来，形成“小明的同事”这层关系。这就是为什么大语言模型不只是记住词，还能抓住词与词之间的结构。

交叉注意力是模型看别人。它主要出现在“输入一段、输出另一段”的任务里，比如翻译。原文里有个很典型的例子：把“某地这段时间天气晴朗”译成另一种语言，当模型要写出对应“晴朗”的那个词时，交叉注意力会把更多权重压到输入里的“晴朗”和“天气”上，因为它俩跟目标词的含义最相关。没有这盏灯，译文就容易跑偏。

一句话区分：自注意力解决“这句话内部谁跟谁有关系”，交叉注意力解决“输出这个词该回头看输入的哪一块”。前者是理解，后者是对齐。

2.3 编码器与解码器：GPT 为什么只留了一半

一个标准的 transformer 由两半组成：编码器和解码器。编码器的任务是读入原始文本，把里面的有用特征提取出来，压成一个有意义的数值表示，业内叫 embedding——你可以把它理解成一段话被翻译成了模型内部能运算的“摘要向量”。解码器拿着这份摘要，生成目标输出，可能是一段译文，也可能是一段摘要。两者之间靠交叉注意力对接，让解码器在写每个词时都能回头查一眼编码器整理的资料。

GPT 只保留了后半截。它没有编码器，因此也不需要交叉注意力来对接编码器的产物，整个模型只靠解码器内部的自注意力，一边看上文一边往下写。这个取舍带来一个很直接的后果：它没有“先把整段话彻底读懂、再动笔”的阶段，理解与生成是同一个动作的两面。它擅长顺着已有内容铺开，不擅长像搜索引擎那样精确检索一条事实——这也是后面要讲的“幻觉”问题的结构根源。

顺带一提，另一类模型走的是反方向，只保留编码器。这类模型擅长判断“这两句话是不是一个意思”“这段文本属于哪个类别”，但不擅长写长文。同一个架构，取哪一半，决定了它适合干什么。

2.4 并行化：为什么这套结构能喂下那么多数据

循环神经网络有个绕不过去的限制：它必须按顺序处理，第一个词算完才能算第二个，像传话游戏，一个接一个。这个顺序依赖在数学上没法拆开，GPU 再强也只能干等着。

transformer 把这条链砍断了。句子里所有位置可以同时计算注意力权重，彼此不依赖前一步的结果，天然适合并行。这个特性看着不起眼，却是“大”的前提条件——只有能并行，才能把海量文本高效地喂进去训练；只有训练数据足够多，模型才能学到足够细的语言规律。很多技术演进的转折点就是这样，真正的突破往往不在最显眼的地方，而在某个让效率突然提高一截的工程细节上。

3. Token 与“猜下一个词”：模型眼里其实没有字

3.1 分词：一句话进门先被切成碎片

模型不认识汉字的字形，也不认识英文字母。文本进来第一件事是被切成小块，每块映射成一个整数编号，这个过程叫分词，切出来的每一块叫 token。

切法不是按字也不是按词，而是介于两者之间。英文里常见的整词可能是一个 token，生僻词会被拆成词根和词缀，标点、空格也各占一份。原文给过一个很直观的例子：一句“今天天气不错，所以我决定”送进去，可能被切成类似["The", "wea", "ther", "is", "nice", "today", ",", "so", "I", "de", "ci", "ded", "to"]这样一串碎片。注意“weather”被劈成了两半，“decided”被劈成了三段。

每种模型都自带一个分词器，切法由它训练时用的词表决定，换个模型，同一句话的 token 数可能就不一样。这里有个经验值可以参考：英文文本里，100 个 token 大约相当于 75 个单词。中文没有这么统一的换算，颗粒度通常更细，同样意思的一句话，占的 token 数未必比英文少。

提示：判断一段文本贵不贵、塞不塞得下，看字数是不准的，得看 token 数。

3.2 概率表：每次只往前挪一个 token

切完之后，模型做的事简单到有点反直觉：它对着词表里每一个可能的 token 打一个分，转成概率，挑一个作为下一个输出，拼到已有文本后面，然后拿这串更长的文本再预测下一个。

原文的例子是“今天天气不错，所以我决定”，模型算下来，“出门”这个词的概率最高，于是接上。接完再算“出门”后面跟什么，可能是“走走”。一个 token 一个 token 地往外挪，最后就成了一段完整的话。

这个机制解释了很多现象。它为什么有时候会重复？因为重复的词在概率上确实容易连续占优。它为什么每次回答不完全一样？因为采样时不一定总挑概率最高的那个，会按概率随机抽。有一个参数专门控制这个随机程度，通常叫 temperature：调低，输出更保守、更确定，适合客服、数据抽取这类要稳定的场景；调高，输出更发散，适合头脑风暴、文案起标题。这不是“创造力开关”，本质只是把概率分布压平或者拉尖。

3.3 上下文窗口：模型的“桌面”有多大

模型能同时看到的 token 总数是有限的，这个上限叫上下文窗口。原文提到两个规格：8,192 个 token 和 32,768 个 token。可以把它想成一张桌面：桌上能摊开的纸就这么多，超出部分要么放不下，要么被挤掉。

这个限制在实际开发里处处碰壁。想把一份几十页的文档丢进去让它总结，一算 token 就超了；做多轮对话，聊到十几轮之后，最早那几句已经被挤出窗口，模型自然就“忘”了开头说了什么。所以工程上的常规做法是切块：把长文本按 token 预算切成若干段，逐段处理，再把结果拼起来。

# 按 token 预算切分长文本：保证每一块都能塞进模型的上下文窗口 def chunk_by_tokens(text, encode, window=8192, reserve=1024, overlap=128): # window: 模型单次能接受的总 token 上限 # reserve: 留给模型输出的空间，不能全给输入占满 # overlap: 相邻块之间的重叠量，避免一句话被拦腰截断后语义丢失 budget = window - reserve ids = encode(text) # 文本 -> token 编号序列 chunks, start = [], 0 while start < len(ids): end = min(start + budget, len(ids)) chunks.append(ids[start:end]) if end == len(ids): break start = end - overlap # 回退一点再切下一块 return chunks

这段逻辑的关键在三个数。window是硬上限，原文给出的两个规格就是 8192 和 32768，选哪个直接决定每块能放多少内容。reserve是给输出留的余量，如果输入把窗口占满，模型就没地方写答案了。overlap是补救措施，纯粹按长度硬切，很容易把一句话切成两半，前后两块各拿到半句，语义都残了；留一点重叠，让边界处的信息在两块里都出现一次，拼接时才不会断层。

4. 常见误区：五个最容易混为一谈的概念

4.1 误区一：GPT-4 和 ChatGPT 是同一个东西

易混点：两个词几乎总是成对出现，很多人以为只是叫法不同。

为什么混：它们确实绑在一起出现在同一个产品里，日常对话中没人会特意区分“我现在用的是模型还是产品”。

怎么区分：GPT-4 是模型，是一堆训练好的参数加上一套推理接口，输入 token、输出 token，仅此而已。ChatGPT 是产品，是把这类模型套上对话界面、会话管理、系统提示词、历史记录之后形成的成品。打个比方，一个是发动机，一个是整车。发动机可以装到船上、装到发电机上，整车只能按它的方式开。理解这一层，你就明白为什么同一个模型能在客服系统、写作工具、代码补全里以完全不同的形态出现。

4.2 误区二：模型“懂”你说的话

易混点：它回答得头头是道，很容易让人以为它真的理解了内容。

为什么混：语言本身就是理解的载体，一段通顺、切题、有逻辑的回答，从外部看和“理解”几乎无法分辨。

怎么区分：回到第 3 章那个机制——它做的是概率预测，不是查证。它没有内建的事实数据库，也没有“这句话是真是假”的判断环节。所以在它训练语料里出现得少、或者压根不存在的信息上，它会顺着语言的惯性编出一个看起来很像样的答案，这就是所谓的幻觉。判断标准很简单：涉及具体数字、日期、引用、人名机构名这类必须精确的内容，一律去外部核实；涉及风格、结构、改写、归纳这类任务，它翻车的概率低得多。

4.3 误区三：token 等于字，也等于词

易混点：中文语境下，很多人默认“一个汉字一个 token”，英文语境下默认“一个单词一个 token”。

为什么混：短句子里这个近似常常成立，估出来的数差不了太多，于是就被当成了规律。

怎么区分：token 是分词器切出来的单位，切法由词表决定。同一个词，常见形式可能是一整块，生僻形式可能被拆成好几块；标点、空格、换行也各自占位。所以“限制 4000 字”和“限制 4000 token”完全是两回事，前者宽松得多还是严格得多，取决于文本内容。做预算时老老实实用分词器算一遍，比凭感觉估靠谱。

4.4 误区四：上下文窗口等于模型的记忆

易混点：能聊十几轮不跑题，看起来像记住了之前说过的所有事。

为什么混：窗口内的信息确实会被带进每一次计算，表现上跟“记得”没有区别。

怎么区分：窗口是临时的、有上限的、随对话推进不断被挤出的。这一轮结束，窗口里的东西不会沉淀到任何地方；下一轮重新开始，模型对你一无所知。真正的长期记忆得靠外部机制——把历史对话存进数据库，下次按相关性检索出来再拼进 prompt。把窗口当记忆用，最常见的翻车现场是：聊到后半程，模型突然把开头明确否定过的方案又提了一遍，因为它确实看不到了。

4.5 误区五：Transformer 就是大语言模型

易混点：讲原理时两个词经常互换着用，听着像同义词。

为什么混：几乎所有主流大语言模型都基于 transformer，二者高度重合。

怎么区分：transformer 是 2017 年提出的一种网络结构，是设计方案；大语言模型是“用海量文本训练出来的、规模足够大的语言模型”，是成品。同一个结构，参数少、数据少，就是个普通模型，没人叫它大语言模型；结构之外，还有分词方案、训练方法、对齐策略一大堆东西共同决定最终表现。把架构当成产品，就像把“内燃机原理”当成“某款车”——原理对了，但离能开上路还差很远。

5. 这份资料为什么先讲原理再讲开发

5.1 从“会接话”到“能干活”：聊天机器人和内容生成器差在哪

这份资料的副标题写得很直白：构建智能聊天机器人、内容生成器等等。这两类应用看着都是“让模型说话”，底下的工程结构差别不小。

聊天机器人的核心是状态管理。用户不会一次把需求说全，往往是聊上三五轮才把背景交代清楚，模型必须能顺着前文往下接。这就带来一串问题：历史对话怎么存、存多长、超窗口了怎么裁、裁掉的部分要不要做摘要补回去。系统提示词也得设计，得让模型知道自己扮演什么角色、能回答什么、遇到边界情况怎么处理。

内容生成器更接近批处理。输入一份结构化数据，输出一段成稿，中间不太需要多轮交互，但对输出格式的稳定性要求高得多——一会儿输出 JSON、一会儿输出一段散文，下游程序就没法解析了。这类场景通常要把 temperature 压得很低，再配合明确的格式约束。

两类应用共享同一套底层认知：token 怎么算、窗口怎么用、prompt 怎么组织。差别只在这些参数往哪个方向调。

5.2 调整 prompt 之前，先算清楚 token 和上下文这笔账

很多人上手第一件事是反复改 prompt，觉得措辞对了效果就好了。改到后面会发现瓶颈往往不在措辞，而在几个更硬的约束上。

第一个是长度预算。一次请求能塞多少内容、能返回多长，都是明码标价的。把一份长报告整段丢进去，很可能输入就把窗口吃掉大半，模型没空间好好写答案。第二个是位置效应。窗口里的信息不是等权重的，放在开头和结尾的内容更容易被抓住，中间部分容易被忽略——这不是玄学，是长上下文场景里反复被观察到的现象。第三个是输出长度控制。不给上限，模型可能洋洋洒洒写一大段把预算烧光；给太紧，答案又会被硬生生截断在半句话上。

# 一次最简的对话请求：四个参数决定输出长什么样 resp = client.chat.completions.create( model="gpt-4", messages=[ # system 定角色和边界，比在 user 里反复叮嘱更稳 {"role": "system", "content": "你是一名严谨的客服助手，只回答订单相关问题"}, {"role": "user", "content": "我的订单到哪了？"} ], temperature=0.2, # 越低越保守；客服场景不适合天马行空 max_tokens=300 # 单次回答的长度上限，防止长篇大论烧预算 )

四个参数各有分工。model决定用哪个规格，规格不同上下文窗口大小也不同，这一步选错后面全白搭。messages里的角色划分不是装饰，system里写的内容对输出的约束力通常比塞在用户消息里更强。temperature控制随机性，取值越低输出越贴近概率最高的那条路，适合要稳定复现的场景。max_tokens是硬性截断，设小了答案会断在半句，设大了成本失控，得按实际回答长度定。

这份资料的价值就在这儿：它没有停在“讲清楚概念”这一步，而是把概念和参数之间的对应关系摆出来——为什么窗口是这个数、为什么温度要这样设、为什么历史对话需要裁剪。早期发布形态意味着部分章节还在补齐，正文与代码样例也未经最终润色，读的时候可以把注意力放在思路而不是逐字照抄上。

6. 什么时候该翻这份资料，什么时候别指望它

6.1 三种适合上手的场景

第一种是想把对话能力接进自己系统的人。你手上有个业务系统，想让用户用自然语言提问，后台自动查数据、组织答案。这时候需要的是理解 prompt 怎么组织、上下文怎么管、输出怎么约束，这份资料讲的就是这条路径。

第二种是刚接触大语言模型、概念一堆但对不上号的人。AI、机器学习、深度学习、transformer、大语言模型这几个词天天见，但谁是谁的子集、谁是谁的实现，脑子里的层次是乱的。从头顺着读一遍，这条链就理顺了。

第三种是要做内容生成类工具的人。批量写摘要、批量改写、批量生成结构化字段，这类任务对格式稳定性要求高，对交互性要求低，正好对应资料里内容生成器那部分思路。

6.2 三种容易搞错方向的情况

第一种是把它当模型训练手册。这份资料讲的是“怎么用现成的模型开发应用”，不是“怎么从零训一个模型”。想调参、想做微调、想研究训练策略，方向不对。

第二种是拿它当精确知识来源。模型本身会编，讲模型的书也可能因为早期发布而存在未定稿的部分。涉及具体数值、接口细节的地方，以官方文档为准。

第三种是期望它解决业务判断。模型能组织语言，不能替你决定该给用户什么答案。业务流程、合规边界、异常处理，这些还是得人来设计。

我自己最早做这类项目时踩过一个坑：花了两天反复调 prompt，措辞换了十几版，效果就是上不去。后来把每一轮的 token 数打出来一看，历史对话早就把窗口吃掉了大半，模型能看到的上下文只剩下最近两轮，前面交代的业务背景全丢了。那两天改的措辞，全是在一个信息残缺的前提下打转。从那以后我每次动手写第一行代码之前，都强制先把 token 预算和窗口分配算一遍，把“模型到底能看到什么”写在纸上，再谈 prompt 怎么写。希望帮到你。

本文还有配套的精品资源，点击获取