如何使用GPT进行代码及机械操作
- 启发式的项目
- 可分析式代码平台
- 基本流程
- 难点和重点
- 前言（preface）
- 可识别格式
- 前端模板
- 代码
启发式的项目
Awesome ChatGPT Prompts
我大概讲解一下这个项目，自GPT大火之后，很多人在不断的探索GPT的最佳应用场所和使用方式，除了基本的上下文关联式聊天和语法编程等常规操作，有一些人也算是将GPT用出了一个很了不起的境界了，这个git上存储了很多这样的案例。这些人将一些前言（preface）尽可能详细的描绘，之后给到GPT，然后GPT就会按照其描绘进行一些符合预期的对话，这些对话可以是某一个领域内高深的言论，也可以是极具情色色彩的“文爱”。
那么这个preface为什么不能是一些可分析式的代码平台呢？
可分析式代码平台
可分析指的是可以分析人类高级语言；
代码指的是将人类语言分析后的结果转化为代码平台可以看的懂的语言（eg:JSON）
总的来说，就是通过AI进行人语分析，将人语转化为可识别至代码的语言的一系列操作。
基本流程
- 由前端进行用户语言采纳
- 采纳用户语言之后，进行数据的转化（这一步我省略了，你可以进行语音识别，也可以只支持文字）
- 每一次的对话session是需要保存的，这样可能可以判断到该对话是否是第一次的对话，并且可以实现多用户同时对话，这一步还是蛮重要的，这里我们可以采用AI所提供的APIsession进行保存，因为即使你自定义了session也是需要将对话和session一起发送至AI平台的
- 如果是第一次对话需要由中台发送前言至AI，这一部分结果是不需要收集并反馈的，他只是简单和通知到AI，并和AI进行一些约定
- 将用户的语言发送至AI
- AI分析语言并进行JSON式反馈
- 中台接受到回应之后判断AI返回的结果是一个操作式的指令还是对话式的指令
- 如果是对话式的直接返回至前端即可，但如果是操作式的指令，需要中台进行JSON的解构，并对JSON中的相关内容进行invoke，之后将结果值返回给前端
- 前端收到结果后，通过对返回结果的解构套用相应的模板
在这个过程中会有几个难点和重点是需要我们进行注重分析的
难点和重点
相比较于传统智能语音，我的理论优秀在于
- 我并不是按照关键词检索来进行指令匹配的，关于关键词匹配实现的这种智能方式，我谓其”假智能“、“低智能”，首先我们需要考虑到关键词的优先级问题以及汉语中多义词的考虑问题，如果简单的进行文字对应匹配，那我们的程序在关键词庞大的过程中是很容易出现误解的，比如，某一个方法的关键词中含有”长大“，另一个方法关键词中包含”长“和”大"，那么当一个问题中包含”长大“时，程序可能优先选择的时先遍历到的方法，当然这里只是一个比喻，如果你研究到语言这一门学问你会深切意识到，语言和关键词是两件事情。
- 上下文关联的问题，要知道关键词匹配的这种算法是无法进行上下文匹配这种高级手段的，下面是一段话：
用户：请给我一个我司这月的员工考勤的表格出来
AI：（打印表格）
用户：很奇怪，张三在这月请假多天，我想看看他请假的原因都是些什么
AI：（打印张三请假原因表格）
用户：（很生气，因为张三糊弄请假原有）把他叫来我办公室
AI：（发送给张三来领导办公室的信息）
以上对话我们可以看到，第一段对话，关键词式的智能是可以做到的，但是第二段对话就比较难了，因为毕竟用户所述语言有上下文关联的情况，但是还并不是特别复杂；但是第三段对话是传统智能所无法达到的，因为”他“在传统AI中，代指不明 - 这个是目前AI也未解决的事情，但是有所改善：语意模糊问题。这个问题指的是我们的语言往往是语意不明确的，但是我们的方法是语意明确的，怎么理解呢？比如：我想要一份四月份的员工的每日上班的考勤记录，这句话是很明确的一种语意，但是日常生活中我们可能并不会这么说，我们可能会说，我要这个月的考勤记录，但是传统智能可能由于关键词缺失就不会进行指令的继续执行了。
前言（preface）
这一部分是很重要的，并且这一部分也是 awesome-chatgpt-prompts项目的主要内容，如何与AI进行约定是很重要的。
这一部分我是设计了一个注解，将我们预期执行的方法加注解，注解中主要包含方法的描述
在进行前言沟通时，我们会将方法的位置及其描述一起发送，也就是说为了避免语义不明的问题，我只需要AI对我所提供的方法进行选择，选上了，再通过反射执行方法，最后将方法的反参返回。
可识别格式
这一部分也是重要内容，我们需要与AI进行沟通，让它的返回参数（即他的回答）是我们代码所能看懂的格式才可能让我们的代码进行反射执行，如果AI也只是单纯给我们发送一段语言，那于我的这种没嘴巴的代码，是否使用AI又有什么用处呢？
前端模板
要知道前端只是发送了一句话，就需要应对我们不可定的反参确实是一种很难处理的行为。
这里我建议使用模板，比如：日常对话式为一种模板，表格式为一种模板，折线图为一种模板，这样有什么好处呢，一处设计，处处使用。代码的复用性嘛！
当然，业务的复杂性可能不能使我们代码的复用性那么高，适当的进行模板的精确化也是可行的。
代码
我们目前已经有一部分的代码投入使用，但是整体思维是我自己的，我正在将代码进行整体，尽快摘出一个框架。
