最近刚拿到一个历史系统的源代码，简单看了一下，头就有点大，代码内容明显是多年叠加的结果，如果要修改真的是个慢功夫。还好我这次的目的只是了解代码的业务实现，那就可以用到新工具了。同时，我发现交互式学习是个好东西🤓。
代码中的业务
先啰嗦一句，为什么要从代码中看业务，其实很多业务已经和业务人员沟通过，但是业务人员多表述的他们看到的内容，系统如何处理的，这就不知道了。实际上随着业务系统的多年建设，企业的业务从系统建立后就已经不再只是业务人员最初提出的业务了，系统代码对业务的已经产生了深远的影响，甚至说有些业务逻辑，当前实际作业的业务人员都不知道来龙去脉，但是系统仍然按照之前多方约定的规则在执行，所以说查看系统的实际业务运营逻辑对了解企业实际业务是很有必要的。
提交代码
既然要利用 GPT，那么第一步就是要把源代码提交给 GPT，这里简单的复制是不可能的，太长了，需要用到一个插件，它可以做到分批上传，并且抑制 GPT 在上传期间的反馈，但是做不到绝对抑制，这会导致后提提问时，GPT 会把自己的反馈也当做源代码的内容进行总结，最终使回答发生偏差。我在问的时候，要求只对我提交的内容进行分析，这样就好了很多。
第一个问题
上传完毕代码后，可以先问一下以上代码的整体业务逻辑什么，这样可以大概了解一下这个源文件实现的功能，也为以后继续发问细节找好方向。这里需要注意的是上传的代码最好是一个业务的串行实现，不要是多个业务的函数几个，你是要问一个业务的逻辑，如果给了一堆业务不相关的函数，也没法问出来什么。
问主要实现业务的逻辑
拿到了主要业务逻辑之后，就可以针对其中核心业务实现进行追问，像一些变量初始化之类的就可以忽略了。这里一般会问出一些核心业务对象的处理逻辑，例如合同在哪几种情况下有处理，分别逻辑是什么。也会识别出一些关联对象，例如合同，供应商等，可以围绕关联对象的处理逻辑记性询问，也可以直接问这个对象的状态有哪些，例如合同的状态包括哪些值。幸运的话，代码中对状态有判断，那么主要状态及处理逻辑就都有了。
询问关键表
在询问业务逻辑时大概率会遇到与业务表的交互，可以让 GPT 总结一下遇到了哪些表以及哪些字段，字段含义，与业务的交互逻辑。多角度问答案会重复，也会加强印象。这样比单纯看表结构要好的多。
问输出
输出很重要，问问输出内容和格式有时候会很有用。问完了输出格式后，可以让 GPT 根据代码逻辑和格式要求，模拟输出一个样本，再对样本做解释，非常舒服。
问缩写
很多变量或者函数都是中文缩写的，这个让我复原有点难度，不过让 GPT 根据上下文推测中文缩写的原始还是不正是它的强项吗？哈哈哈
问业务常识
代码逻辑懂了，但是业务含义又不懂，其实很多业务都是有业界通用说法的，只要问一下业务专家一般情况下这个业务含义是什么就行了，你说巧不巧，GPT恰巧就是业务领域的专家，一般业务还都看不到它。
