当提到领先的人工智能研究机构，OpenAI 人工智能公司绝对是其中之一。作为全球最知名的 AI 研究机构之一，OpenAI 的成果和贡献不可谓不深远。它在自然语言处理和生成领域的 GPT 系列模型（GPT-1、GPT-2、GPT-3）尤为出色，引领了该领域的发展。
如果还不清楚怎么注册使用 GPT 的同学，不妨看看这篇《（建议收藏）ChatGPT 被锁中国区 ip ？别慌，看这篇ChatGPT & OpenAI 注册使用指北》。
大家好，我是祯民。最近 ChatGPT 对各个领域都造成了不小的冲击，大家或多或少都已经和 ChatGPT 对话过，并且也得到了不少答案和结果，相信对它的能力也有了较为清晰的认知。
当然这篇文章的重点并不是怎么注册使用 ChatGPT 或是怎么搭建一个自己的 ChatGPT 服务，在很多同学的印象里，ChatGPT 是一个人工智能的模型，可以通过聊天的方式得到一些答案。这个并不是一个全面的认知，它能做到的事情也远不及此。
通过 GPT 模型 , 可以批量智能并且自动化地完成各行各业的工作。在这篇文章中，我们就将来学习 GPT 的高阶玩法 — 基于GPT模型开发自动化应用, 通过这篇文章的学习，大家将对 GPT 模型产生一个初步的认知，并且具备使用 GPT 模型应用到自己需要的方向的基本开发能力，形成整个 AI 应用维度的架构思维。本文将从以下几个大方向展开这部分的学习：
- GPT 模型篇：通过这部分的学习，大家将对 GPT 模型具备一个相对清晰的认知，并且了解怎么根据自己的应用场景灵活选用模型。实际上，我们使用的 ChatGPT 只是其中的一种模型，即 GPT-3.5-turbo 模型。
- GPT 接入篇：这部分我们将结合实际的例子来介绍 GPT 模型的接入，涵盖流获取、流式接入等高阶玩法。
- GPT 应用篇：这部分我会基于我最近开发 GPT 模型的 vscode 自动化测试插件 GPT Unit Test，来具体剖析整个方案是如何设计的，并延伸到其他方向应该如何展开具体的 AI 应用。
全文干货很多，建议收藏深读！ 本文虽会以技术视角展开，但是并没有较深的技术门槛，非技术同学也可以关注，其中的 AI 应用思路相信会对优秀的你有不一样的启发，在这个领域，想法💡远比技术要更有价值。
GPT 模型篇
初识 — 什么是 GPT 模型？
GPT (Generative Pre-trained Transformer) 模型是一种基于 Transformer 结构的预训练语言模型，由 OpenAI 人工智能公司开发。它表现出色的原因是它能够在大规模文本数据上进行预训练，并根据任务进行微调，从而在多种自然语言处理任务上取得优异的结果。
GPT 模型是在大规模语料库上进行训练的。在预训练阶段，它会学习构建句子的基本结构、单词之间的关系、句子的文法和语法等等。在对其进行微调后，它可以实现诸如对话生成、文本摘要、机器翻译、命名实体识别等任务。
简单来说，GPT 是一种预训练算法模型，在它的基础上，存在一些变体，具备更大的预训练规模和数据集，使得它的自然语言能力更强，我们一直使用 ChatGPT 就是其中的一种变体。
因为这个性质，GPT 也可以被理解为是一系列预训练模型的统称，这些变体其实我们也可以称它们为 GPT 模型。经过这样的描述，相信大家也可以理解，GPT 模型的能力来自于大量数据集的反复预训练，不同的变体之间的差异也与训练的次数、规模和数据集息息相关。
差异 — GPT-3 , GPT-3.5, GPT-4 模型之间有什么区别？
InstructGPT（2022 年 1 月）是一系列 GPT-3 模型（包括 text-davinci-001、text-davinci-002 和 text-davinci-003）统称，于GPT-3相比，它的最大不同是针对人类指令（reinforcement learning with human feedback, RLHF）进行了微调 ； InstructGPT 产生的幻觉更少，更真实，但它在生成的多样性或者说创意上相对更差，因为它们试图在“对齐”的前提下，将人类偏好/价值观硬塞进原始数据模型中。
ChatGPT（2022 年 11 月）更进一步。 为了训练 ChatGPT，OpenAI 对 InstructGPT 对话模型进行了微调（马斯克在Twitter上指出openai 使用了Twitter 数据）, 这种微调在一定程度上也是可以的, 区别在于使用的policy and reward model
在了解了什么是 GPT 模型后，我们来看一下它的变体。当然除了 GPT-3, GPT-3.5, GPT-4 以外还有 GPT-2，GPT-2的能力在各方面都比较差，也不适合微调，这里就不展示描述了。
首先大家需要了解 GPT-3, GPT-3.5, GPT-4 都是具备对人类指令做出基本有效反馈的模型：
- GPT-3 模型也称 davinci 模型，它虽然具备基础的响应能力，但是创造性比较差，在逻辑构造方面也比较难形成有规律或者说逻辑紧密的回答，所以通常来说，项目的应用（即 GPT 模型 的接入）我们并不会直接选用 GPT-3 模型，更多是用于模型微调，来产生适合业务的变体。
- GPT-3.5 模型是在 GPT-3 模型的基础上微调的产物，相比之下，它具备更强的语言逻辑组织能力和创造力，也是目前使用范围比较广的 GPT 模型。
- GPT-4 模型在 GPT-3.5 模型上提供了更具有时效性的数据集来进行训练，在时效性、创造力上都有一定的提升，缺陷是还没有完全公开，需要体验名额，或者接入微软提供的 azure gpt 模型使用。
清晰认知 — 最近大火的 ChatGPT 使用的是哪种模型？
那么我们平时常用 web ChatGPT 使用的是哪种模型呢？通常来说，使用的都是 GPT-3.5 模型，即 gpt-3.5-turbo 和 gpt-3.5-turbo-0301 这两种模型。
上文我们也提到 GPT-3 模型通常是不会直接用来应用的，而 GPT-3.5 模型是在 GPT-3 模型基础上做出的更具创造力的模型，也是最基本适合应用直接使用的模型。至于 GPT-4 模型目前还没有直接推广，需要和企业签订协议，或者拿到体验名额后才能尝试。（不过目前我实验下来的效果，个人感觉，GPT-4 和 GPT-3.5 并没有太大差异, 主要差异还是在时效性和 token 长度上）
大家在看完 GPT 接入篇后也可以尝试接入一下 GPT-3 模型试试效果，相比目前的答案实体，GPT-3 的答案更像是信息的堆砌，所以这也是 GPT-3 模型通常是作为其他模型母体的原因。
思路确定 — 应用阶段，我们应该选择哪种模型？
如果你的应用比较轻量，没有过多的业务背景或是技术壁垒（即没办法在外网查阅到），那么可以直接接入 GPT-3.5 及以上模型。
反之，如果你的应用需要了解业务背景，或者存在一些自研的能力，形成了技术壁垒，又或者是在时效性上有更高的要求，那么则需要以 GPT-3 模型为母体，进行微调。
微调的文档可以参考platform.openai.com/docs/api-re… ，这里不再赘述，需要注意的是，请提前准备好和你业务背景、技术能力相关的训练数据，微调的效果与数据集的完整度和逻辑可靠性强相关。
GPT 接入篇
迈出第一步 — GPT 模型的接入 ?
相信大家在上面的学习中，应该已经对 GPT 模型有了一个较为清晰的认知，事实上，GPT 模型提供可以为应用接入的能力，我们可以按照自己想法为自己的业务接入 GPT，并基于它批量完成一些工程化的事情。
当然这里提到的自动化能力，绝不仅仅是 ChatGPT 这种 web 聊天这么简单, 通过对实际业务场景的通用性问题总结以及规律性结果处理，我们完全可以做到自动化完成一些工程化的事情，比如测试，代码优化等等，这个就是后话了，我们会在应用篇详细介绍。
GPT 模型提供了 fetch 和 npm 包两种方式接入，当然这两种接入方式底层都是相同的，npm 包可以理解为是基于 fetch 逻辑的 nodejs 包装。接下来，我会结合实际的例子来给大家详细讲解 GPT 模型的接入以及实际业务接入使用中必须解决的一系列问题。
GPT 模型接入 — fetch
GPT 模型可以通过接口的方式来完成接入，上面我们提到 GPT-3 模型有很多变体，分别用于不同行业方向，比如 图片、聊天等，具体的文档大家可以参考 platform.openai.com/docs/api-re…
下面我们将以聊天模型的接入展开介绍，这个是我们应用中最常用的模型（即使不是用来做聊天室），它的结果更具备逻辑性，容易总结出通用性问题并集中处理, 我们来看下面的例子
const messages = "Once upon a time";
const apiKey = "<INSERT_YOUR_API_KEY_HERE>"; // OpenAI API 授权密钥
const apiUrl = "https://api.openai.com/v1/chat/completions";
const headers = {
"Content-Type": "application/json",
Authorization: `Bearer ${apiKey}`,
};
const data = {
messages,
max_tokens: 5,
};
const options = {
method: "POST",
headers,
body: JSON.stringify(data),
};
fetch(apiUrl, options)
.then((res) => res.json())
.then((json) => console.log(json))
.catch((err) => console.error(err));
在上面的例子中，我们实现了一个简单的 fetch 方式的接入，其中 apiurl 即是 chatgpt 模型的接入地址，我们需要获取到 openAPI KEY 并作为鉴权传入 headers 中，其中 openAPI Key 可以从 openAI 账号中生成，是一个用户信息鉴权 key，使用过程将会消耗 openAI 的额度，大家可以到 platform.openai.com/account/api… 生成。
data 的部分是 openAI 提供给我们的参数，可以进行一些自定义的配置，大家需要关注的有下面这些参数：
- model：文本生成器使用的模型，即 GPT-3.5及以上 模型
- messages：文本生成器的输入，表示您要向 API 提出的问题或问题描述。
- temperature：控制生成的文本的随机性。值越高，生成的文本越具有创造性和想象力。当然并不是越高越好，值越高，答案存在错误的可能性也越高，需要根据业务场景灵活调整，默认为 0.7。
- max_tokens：生成文本的最大长度，以 token 数量为单位。默认为 150，最大为 2048。
- top_p：控制模型多个单词的权重。取值范围从 0 到 1，默认为 1.0。
- n：请求 API 生成的新文本的数量。默认为 1。
- stop：如果生成的文本包含以下任意一个字符串，即停止文本生成过程。默认为一个空数组 []。
- presence_penalty：生成文本时减少出现重复子串。若设置，则模型尝试消除两个已经重复出现的词语间的文本。默认为 0.0。
- frequency_penalty：在生成文本时惩罚使用过于频繁的单词。较高的值有助于提高生成文本的多样性，但可能会导致生成文本的不连贯性等问题。默认为 0.0。
需要额外注意的是，该模型输入（即 messages）最大为 4096 token，这里 token 的单位指的是自然语言处理领域中的最小语言单位，可以理解成小于等于1个单词，而输出（即max_tokens)最大为 2048 token。
也就是说如果问题过大，或者说回答过大，都将会造成内容的截断，常规的调用并不能无限制地问答，当然这个也是有解法的，我们会在下文中流相关部分详细介绍。
GPT 模型接入 — npm 包
除 fetch 调用外，我们还可以通过 npm 包的方式完成接入，当然底层都是用 fetch 链接，我们需要安装一下 npm 包的依赖。
npm install openai --save
我们来结合例子看看具体应该怎么通过 npm 接入 GPT 模型
const openai = require("openai");
const prompt = "Once upon a time";
const apiKey = "<INSERT_YOUR_API_KEY_HERE>"; // OpenAI API 授权密钥
openai.api_key = apiKey;
const parameters = {
model: 'text-davinci-003',
prompt,
max_tokens: 5,
};
openai.Completion.create(parameters)
.then((response) => console.log(response))
.catch((err) => console.error(err));
不过需要注意的一点是，fetch 中我们举例调用的 chatgpt 模型，即 gpt-3.5-turbo 及以上模型，而 npm 包不需要填 fetch 链接，如果想调用了 davinci 模型（即 gpt-3），参数需要有一些调整，需要将 messages 换成 promt，因为 davinci 底层调用的链接其实是 api.openai.com/v1/completi…
如果用的是 gpt-3.5-turbo 及以上模型, 那么 parameters 中的问题描述参数请用 messages。
流获取 — 如何实现打字机的效果？
web-gpt 中我们看到的 gpt 往往是一个一个字吐出来的，相比常规接口的完全返回再显示，这种交互体验明显更佳，这个又是怎么实现的呢？我们可以来看下面的示例
let answer = '';
const resolveData = async (reader: ReadableStreamDefaultReader<Uint8Array>): Promise<void> => {
const { done, value } = await reader.read();
if (done) {
return reader.releaseLock();
}
const decoder = new TextDecoder('utf-8');
const chunk = decoder.decode(value, { stream: true });
const chunks = chunk
.split('data:')
.map(data => {
const trimData = data.trim();
if (trimData === '') {
return undefined;
}
if (trimData === '[DONE]') {
return undefined;
}
return JSON.parse(data.trim());
})
.filter(data => data);
chunks.forEach(data => {
const token = data.choices[0].delta.content;
if (token !== undefined) {
answer += token;
}
});
return resolveData(reader);
};
const openApiAsk = async () => {
const chat = await fetch('https://api.openai.com/v1/chat/completions', {
headers: {
'Content-Type': 'application/json',
Authorization: 'Bearer your key',
},
method: 'POST',
body: JSON.stringify({
messages: [
{
role: 'user',
content: prompt,
},
],
model: 'gpt-3.5-turbo',
stream: true,
}),
});
const reader = chat.body?.getReader();
if (!reader) {
return;
}
await resolveData(reader);
reader.releaseLock();
};
在上面的例子中，我们在请求中补充了一个请求参数，即 stream: true，这将使得 openAI 返回的结果将返回一个可读流，我们就可以通过反复递归，拿到一点内容显示一点内容，直到返回的内容为 [DONE] 为止，这样就可以实现打字机的效果了
多层 prompt — 如何解决输入过长和返回截断的问题？
上文中我们有提到，chatgpt 不管是输入还是输出都存在着 token 的限制，输入如果过长，gpt 将会直接返回服务端错误，而如果回复的内容过长，则会导致 gpt 提供的答案是截断不完整的，这两个问题，我们都可以通过多层 prompt 的方式来解决
我们先看看输入过长应该怎么解决，我们来看下面的示例
/**
* 按指定 token 分割文件
* @param dirPath
* @param tokenSize
*/
async splitFileByToken(dirPath: string) {
const fileContent = fs.createReadStream(dirPath); // 创建一个可读流
const rl = readline.createInterface({ input: fileContent, crlfDelay: Infinity });
let tokens = []; // 记录当前已读的 token 数组
let files = []; // 记录拆分后的所有文件内容
// 逐行读取 token
for await (const line of rl) {
tokens.push(...line.split(/s+/).filter(t => !!t));
}
// 按 tokenSize 为最小粒度写入
while (tokens.length >= this.tokenSize) {
files.push(tokens.slice(0, this.tokenSize).join(' '));
tokens.splice(0, this.tokenSize);
}
if (tokens.length > 0) {
files.push(tokens.join(' '));
}
return files;
}
上面的函数，我们按照 token 拆分了一个文件（因为需要提供文件代码给 gpt），然后我们就可以再返回一个 prompt 数组，来尽可能保证 prompt 信息的完整
/**
* AI 询问, 返回符合预期的用例代码块
* @param dirPath
* @param lastQuestion
* @returns
*/
async aiAsk(dirPath: string, lastQuestion?: AIQuestionItem[]): Promise<string> {
const questions: AIQuestionItem[] = lastQuestion ? [...lastQuestion, {
role: "user",
content: "继续输出没说完的代码"
}] : [
this.getQuestionTemplate(dirPath),
...await this.generateCodeByToken(dirPath),
...await this.generateIncrementalTestQuestion(dirPath),
{
role: "user",
content: "我希望你的答案中代码的部分可以包括在``` ``` 中, 遵循 markdown 语法, 比如 typescript 的代码，请在写作 ```typescript your code ```"
},
];
const response = await axios.post(this.openAIURL, {
messages: questions,
max_tokens: 2048,
temperature: this.temperature
}, {
headers: {
'Content-Type': 'application/json',
'accept': 'application/json',
}
});
const answer = response?.data?.choices?.[0]?.message?.content;
// 如果本次数据为非正常截断, 需要继续获取, 并完成代码块的拼接
if (response?.data?.choices?.[0]?.finish_reason !== 'stop') {
const restResponse = await this.aiAsk(dirPath, [...questions, {
role: 'assistant',
content: answer
}]);
return `${removeAbnormalCode(getCode(answer))}${removeAbnormalCode(restResponse)}`;
} else {
return getCode(answer);
}
}
在上面的 case 中，我们提供给 gpt 的 prompt 是一个问题的数组，这样询问一个问题，就等同于你打开 web-gpt 询问了多个问题，从而规避了单个问题 token 过长的问题。
同时我们可以看到，我们其实还做了一个额外的递归处理，如果 finish_reason 不等于 stop 的话，那么意味着答案过长被截断了，对于这种场景，我们会再补充一个问题，比如“继续”之类，让 gpt 继续回答，我们来为答案完成一个拼接，从而获得一个尽量完整的答案进行处理。
当然这个 case 并不是完美的，当 prompt 层级过多后，gpt 有可能会丢失较前层级 prompt 的优先级，从而导致询问的信息并不全面。更妥当的做法，其实还得是升级模型，比如换 gpt-4-32k 来提高 token 。
GPT应用篇
抛砖引玉 — 基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)
在完成上面的学习后，相信大家对 GPT 模型和它的接入都有了初步的认知，可能已经对做一个自己的应用跃跃欲试了，在这里想提醒一下大家：
因为 GPT 模型本质上是一个训练集模型，这意味着你问它的所有问题，都会上传到外部，注意隐私和数据安全是很重要的事情，一些内部或者公司内的代码或者敏感信息不要拿来问 GPT 哦～
我们言归正传，在应用篇我会以我最近写的一个 demo — “基于 GPT 模型的自动化测试 vscode 插件（GPT Unit Test)” 为大家讲解应该如何应用 GPT 模型到你感兴趣的方向中，希望对大家有一定启发。
这个插件已经发布到了 vscode extensions，大家可以直接安装使用
插件的使用很简单，在安装完成插件后，文件夹和文件的右键目录中会多出一个选项 generate unit test，点击后如果没填写有效 openApi key 会要求填写，鉴权完成后即可自动为需要的文件目录或是文件生成单元测试，当然也支持 ignore 文件和测试库等配置，具体的大家可以阅读 readme，其中有更详细的解答。
因为是个 demo,所以可能仍然有bug，但是主流程上经过测试是没有问题的，如果你出现不能使用的情况，可能是以下情况：
- 中国区ip被锁，需要替换虚拟 ip, 因为底层它用的还是 openAI 的能力
- vscode 的 engines 版本低于 1.77.0，这个需要升级 vscode 版本
- 输入的 token 限制，测试文件过大，这个 demo 版还没支持，目前测试下来 300 行上下的文件测试质量还是很在线的
- 其他的一些问题，这个你可以在评论区或是按照 readme 中贡献 & issue 的方式联系我，我会尽快答复你
当然这个插件也许不一定会继续迭代，这只是我技术建设抽离出来的一个 demo 版本，在隐私性没办法做得更好，所以只适合 C 端项目（GPT 是公开的），后续的迭代可能都会以我内部对应的技术建设项目为主（大家用不了0x0），所以这也是我不开放贡献的核心原因。
如果是插件主流程阻塞的问题我也许还是会修的，目前看来没有，主要还是会根据我的个人时间来决定（几乎没什么个人时间）。
虽然但是～我想这个插件作为一个 AI 应用方向，用来抛砖引玉我相信会是很好的借鉴，也期待得到更多大家的反馈。下面我们就来具体谈谈这个插件是如何设计的。
场景还原 — GPT Unit Test 是如何设计 & 与 GPT 模型结合的？
我们先来看看这个插件的流程图
其实可以看到整个流程是并不复杂的，除了 openAI 的流式接入外，主要的逻辑都只是一些 i/o 操作，而且这边我们并没有与 GPT 建立持久化连接。
因为在这个 case 中，单元测试有一个重要的特点，就是单一原则上体现比较强，在对于一个组件的测试中，我会拆分为 n 个文件，每个文件独立测试，依赖的部分 gpt 则采用 mock 的方式完成，即 A 引用 B, 那么 A 的单测中只保证 B 和 使用 B 调用的内容存在，而 B 的功能则在 B 的用例中跑。
经过上面的拆分，一个组件的测试我们将不再需要关注整体，GPT Unit Test 的最小粒度就被拆分为了文件，而不是组件或是其他代码集合。接下来只需要按照常规的遍历文件系统，逐步以流的方式写入就行，具体接入的代码在 GPT 接入篇有讲解，还不清楚的同学可以回过头看看。
方向调研 — 如何判断 GPT 模型在某个方向的可行性？
回顾上面的过程，我们可以发现 AI 的应用技术门槛并不高，相反更高的反而是方案的设计以及你如何去应用，就像是一个“万能”（偶尔会胡说八道）的接口，只要可以找到对应方向的使用规律，就很容易拿到预期的结果，并做一些事情。
这里帮大家提取了这个过程真正需要关注的、消耗时间的三点：
- 可靠性验证：保证 AI 帮你完成的事情是可靠的，这个过程需要经过大量 case 对比，将 AI 完成的用例和我写的进行对比，看看谁优谁劣，这里怎么对比的我就不赘述了，单元测试的部分不是这篇指南关注的重点。当然最后我得出了结论，AI 写的用例覆盖率、mock 和单一原则都很在线，不亚于我写的。
- 通用性问题的总结：你使用 AI 不仅是解决单个问题，那么在每次解决之后，这些问法之间是否有共通的地方，能否总结出在一定微调后就可以使用的通用性问题，这个过程需要经过反复测试，并补充边缘情况的限制。比如 GPT Unit Test 使用的通用性问法就是这个
使用 jest 和 xxx （插件暴露出来给用户配置，暂时提供三个，mocha， enzyme 和 react-testing-library ） 为下面文件覆盖单元测试，要求所有的用例代码写在一起，且覆盖率达到 100%。需要测试的文件路径为 zzz (文件系统里取出来） ，且在单元测试的文件上一级目录，需要使用相对路径完成引用，请注意引用路径。请根据上述要求给出完整可用，具备有效依赖引用的代码。需要覆盖单元测试的文件代码如下 yyy
- 结果是否规律可提取：每次拿到的结果是否存在一定规律，能否按照一定的格式或者套路提取出你需要的内容，这也是为什么我要求 gpt 把所有的用例代码写在一起的原因，通过这种方式我就能使用正则提取出代码块，再进行文件写入，这个同样也是需要通过 case 测试并对通用性问题进行补充的。
如果说，你感兴趣一个方向，并且希望这个方向可以使用 AI 提高效率，或者创造收益价值，那不妨回顾一下这三点，如果这三点都想清楚了，那 GPT 模型在这个方向一定是大有可为的。
你也可以做到！– 将 GPT 模型应用到某个方向的可复刻实践方案
经过上面的学习，相信很多同学心里都已经有了自己的答案，将 GPT 模型应用到某个方向的可复刻实践方案无非就是三点：
- 可靠性验证
- 通用性问题的总结
- 规律性结果提取
当我们处理一个大问题的时候，我们有一个常见的算法思路，就是分治法，通过把大问题拆解为小问题，再逐步将小问题解决，从而达到解决大问题的目的。在将 OpenAI 应用到某个方向的时候，也是相同的道理。
以自动化测试为例，如果我需要使得 OpenAI 能够批量去处理某些场景，那么首先 OpenAI首先要能解决某个例子的自动化测试用例生成，因为一个都不能解决，那就不用去考虑批量或者说更多场景的事情了。
如果每个小问题都逐一解决后，我们需要考虑的就只剩下对比这些问法中间的共同点与不同点了，通过这个过程，提取出通用性问法就是能够应用到这个方向的关键了。 就和动态规划的动态表达式一样，难的并不是动态规划，而是表达式的提取，当完成这一步 OpenAI 在这个方向的应用就已经完成大半了。
在拿到通用性问法后，至少可以说明这个方向是可行的了，在绝大多数场景下，一个合适的问法都可以拿到一个比较有规律的答案，我们通过正则等字符串处理的方式就能拿到最终的结果。如果结果比较多样性，那大概率是因为通用性问题缺乏一些限制。
就比如“为下面文件生成用例，要求覆盖率100%，且当前文件路径为xxx，请使用合理的相对路径引入”远远比“为下面文件生成用例”得到的答案更具备规律性，如果因为结果不够规律，不知道该怎么提取结果，在放弃前不妨试试多加一些限制（即使这些限制在你看来像是废话）
当前这些更像是纸上谈兵，具体怎么问也要结合实际场景，和大量 case 测试后才能提取出来，不妨大胆试试，宁愿犯错，也不要什么都不做。不仅是测试，类似代码优化、性能优化、代码迁移重构其实 AI 都可以做到，而且我相信大有可为，至少在这个领域，想法💡远比技术要更有价值。
小结
这篇指南我们分别就 GPT模型、GPT模型接入、GPT模型应用三个方向结合例子详细学习了 GPT 的高阶玩法 — GPT模型自动化应用，不管是搭建一个私服 chatgpt，还是利用 gpt 的能力完成一些工程化，或者是代码优化的内容，都可以参考上面的部分，相信大有可为～
还是那句话，在这个领域，想法💡也许远比技术要更有价值，GPT 的应用还远不及此，最近推出的 GPT 克隆人、AutoGPT 都让人眼前一亮。
也许有一天流浪地球 2 中的数字生命也不再是幻想，如果用 websocket 搭建两个 gpt-3,并且通过一定的数据微调让他们扮演两个人，互相对话训练又会发生什么呢？
这个方向有太多可以探索的东西，希望大家可以不设边界，多去尝试，也许真的你就是改变世界的那个人～如果对这方向有疑惑或者需要探讨的内容，也欢迎大家在评论区与我交流！
