开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

上篇文章我写了自己用 GPT 处理输入生成更漂亮的 Stable Diffusion 的 prompt，有几个人留言嘲讽 GPT，我拉黑了事。最近似乎用 GPT 的人多了，各种拿着 GPT 失误的回答进行无脑嘲讽的人就越来越多。我不知道这种嘲讽是出于什么心理，是对新技术的不屑，还是对未来的恐慌？GPT 作为一个新生事物，尽管它已经“进化” 到相当”智能”的地步，失误，犯错也是在所难免。有必要揪着它数学计算的不完善，或者在某些问题上一本正经地胡说八道不放，就一杆子打死么？

我能理解非技术人员把 GPT 仅仅当作一个玩具，玩厌了或者遇到问题了就把这家伙当成 “言过其实” 的绣花枕头；但技术人员这么做，大概率是还没有找到正确开启 GPT 的钥匙。

GPT 聊天能力之外的「超能力」

聊天问答，其实是 GPT 的最浅层能力。对于程序员而言，GPT 最有价值的能力是其「自然语言编程能力」，或者说 “prompt engineering”。我们可以充分利用这种能力，在 GPT 上「编程」，来解决特定的需求。在具体开始编程时前，我觉得有必要聊聊 GPT 或者说 GPT-3 之后，突然涌现出来三个非常有价值的，只有生物甚至高等生物才具备的能力：

大范围理解抽象指令的能力：任意给定一个抽象的指令，比如 “翻译”，或者 “生成数据库迁移脚本”，他可以正确执行
理解例子的能力：给定一个或者多个例子，让他按相同的规律执行。如果你不知道该如何给 GPT 合适的指令，那么可以通过给它足够多的例子（一般一两个即可），让它举一反三。
对复杂问题进行分治的能力：对于一个复杂问题，如果要求 GPT 分布思考，一步步给出答案，那么他做对的可能性非常高。

GPT 理解指令的能力大家可能觉得并不稀奇，你的 alexa 也可以理解一些指令。但 GPT 厉害之处在于，它能理解的指令几乎涵盖人类活动的所有领域，无论多么冷门。

图片[1]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

GPT 理解例子的能力让人拍案叫绝，有时候我感觉它真的像一个有智慧的生物。之前的人工智能产品没有这个能力，因而它们只能处理特定领域的问题，而 GPT 的学习例子的能力，则是一种非常通用的能力，GPT 作为基础模型，加上我们精心准备的例子，就好像 GPT 通过学习，临时构建了一个新的，解决特定问题的模型，这是非常了不起的。

图片[2]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

对复杂问题的分治能力，也是 GPT 让人感到惊艳的地方。有时候复杂的问题，你只是要求它一步一步推理，每步都给出中间过程，它就能给出更好的结果。这就跟我要求我们家小宝做数学详细写解题步骤，她做对的概率就大大提高一样。

图片[3]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

如何使用 GPT 这种「超能力」

如果你对 GPT 涌现出的上述能力感到兴奋，那么，你完全（暂时）不用写一行代码，就把你的 GPT 按照特定需求，打造成一个个你的专属的机器人或者助手。以下是我自己的 GPT 主要助手，有陪我聊天的（随心聊 – 常规操作），有帮我对网上文章做内容梗概的（内容梗概助手），有做中英文翻译的（翻译助手），还有帮我写 Stable Diffusion prompt 的（SD 助手）。我还在尝试用 GPT 打造一个纯虚拟的 postgres 学习环境，用户在这里就像面对一台真实的 PG 服务器，就是想看它能力的边界在哪里（事实上，相当惊艳啊，我可以虚拟创建表，添加数据，查询，更新，然后查询到的数据是更新后的）：

图片[4]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

以内容梗概助手为例。有时候 hacker news 上的文章内容太长我不愿意看，或者我就想了解个大概，就可以把文章贴到这里，然后它自动帮我 summary，打 tag，描述文章的情绪，甚至帮我写三条情绪积极，中立，消极的评论，以 YAML 返回（以下是一篇关于 Trump 被刑事指控的英文新闻的 summary）：

图片[5]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

好，既然大家看了这么多例子，是不是也摩拳擦掌准备试试呢？既然大家都是开发者，那么我就放一个我晚上突然灵光一动，写的比较硬核的 migration-bot，供大家参考。这个 bot 的灵感来源于我今年年初 hackathon 做的 renovate，一个自动化生成数据库迁移脚本的工具。我在 renovate 上花了四天几乎不休少眠的日夜，写下了两千多行代码。今晚我开完一个短会突然想：如果用 renovate 的思想让 GPT 做数据库迁移，是不是可行呢？于是我花了大约15分钟写下了如下规则和例子：

图片[6]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

一个基本功能完备的 migration bot 就完成了。不太客气地说，我觉得我算是一个相当不错的程序员，四天使出吃奶的力写两千行 Rust 代码，做完一个基本可用的产品，算是相当高效了。然而，使用 GPT，我可以 15 分钟风轻云淡地把需求一描述，最简单的例子一给，就完成一个类似的 POC，这种几个数量级的效率的碾压让我自己都一身冷汗。你可以看看我给的例子，那是青铜级别以下的，简单到不能简单的例子。而我喂给 GPT 的 current schema，是我直接 pg_dump 出来的，我之前 bilibili 做 reservation 系统讲座的数据库，有四百多行 SQL（以下截图不全），相对于我的例子，妥妥王者级别的数据：

图片[7]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

但 GPT 完全能够理解这些 SQL，并以其作为 base schema，开始帮我计算 migration 脚本：

图片[8]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

这些都是小打小闹，我的 renovate 也能很好支持，似乎不足为奇。接下来这个就厉害了：

图片[9]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

这是 renovate 没有，也无法支持的能力。毕竟 renovate 无法理解自然语言，也就无法做这种 migration 的需求。

最后这个结果就完全出乎我的意料，并让我大呼「我擦」：

图片[10]-葫芦娃AI-一起学AI开发者正确开启 GPT 的钥匙-葫芦娃AI-一起学AI葫芦娃AI

renovate 那个项目我之所以放在一边停了很久，就是因为如果某些数据库改动是破坏性更新，那么你仅仅是给出迁移的脚本还不够，你要考虑这种 schema 的更改是否安全。一个单纯是由规则建立的工具（代码其实就是给定的规则）很难完全捕获各种潜在的风险，因而在 renovate 中，这些可能引发破坏性更新的迁移，我一律不支持了事，这就使得工具的实用性大打折扣。现在，通过 GPT，起码，我得到了一个看上去非常靠谱的迁移脚本（我并未验证）。

如果你再回过头去看我为 migration-bot 撰写的规则和例子，它们相对代码而言要「模糊」得多，简单得多，且很多东西还欠考虑。但 GPT 以它自己「读万卷书，阅千人事」的超大规模知识和经验，顺利地理解了我的需求，还很好地理解了我的隐含需求。

文章版权归作者所有，未经允许请勿转载。

THE END