AIGC 生成代码正流行,对程序员是好还是坏?( 二 )


就生成的这段代码而言,总体结构非常完整,代码看起来几乎可以运行,但一些配置项可能需要进一步编写 。此外,它提到了 SMTP 。在很多年前分析 SMTP 协议时,我们需要了解各种配置和端口等信息,如果现在要我突然写这样的代码,可能要花很长的时间去检查各种细节,不过有了这些工具就可以帮助生成相关代码 。
我之前与少杰讨论过这个话题:如果你的基础扎实,能力为 2,那这个工具就是一个倍增器,可以增加 40 倍,变成 80;但如果你的能力只有 1,那么它只会增加 40 。** 你的基础能力在使用这个工具时会被放大 。** 因此,我建议大家深入了解编程语言的本质以及底层技术等知识,你可能无需记住具体的字段或 main 结构,因为现在大型语言模型可以帮助生成 。
彭靖田:这个问题,我从两个角度来考虑 。首先,大型模型有能力生成代码,但最终这段代码要能运行才会成为有价值的交付物 。因此,我们通常会将生成的代码与开发人员编写的代码进行比较,包括代码是否适合进入生产环境 。这其中的一个重要方面是 Prompt 的应用,比如当我们讨论一段代码是否适合在生产环境中使用时,九要考虑我们的 Prompt 是否会检查密码以明文形式存储 。
现在,我们只进行了一轮的对话和询问,目前的输出结果已经足够好,开发人员能提供这样的代码也相当不错了 。但这段代码要投入生产环境,通常第一反应可能是是否需要一个配置管理器或将配置保存为 YAML 文件?例如在端口号和配置项中出现的用户名和密码,生成的代码将密码作为明文字符串放置在代码文件中,这不是一个很好的做法 。这个问题也在于在初始需求中没有给大语言模型足够详细的信息,但通过进行多轮对话,大型模型可以更好地解决 。
关于一个优秀的大型模型或使用大型模型生成良好代码的最佳实践,我认为有两个关键点需要注意 。第一是描述清楚需求细节,甚至可以将自己视为一名架构师,将大模型想象为拥有不同背景(例如前端、后端脚本等)的员工,作为架构师的你应该如何提出需求?第二是要多轮问询、逐步完善 。我做过一个小实验,使用 GPT-4 完整地生成了一个开源项目,目标是进行完整的双语电子书翻译 。这个项目的整体代码库可能有几千行,完全是由 GPT-4 生成的,但是经过了许多轮的对话 。
站在架构师的角度,最初的问题可能不是具体的 100 行代码程序,而是让大模型理解你如何设计这段代码,例如需要分成哪几个模块、数据库密码检查是否只需要一个简单的函数就够了等,所有这些都可以通过架构设计来完成 。总之,多轮对话、逐步完善并将自己视为架构师,用这种自上而下的设计让中间节点和叶子节点的代码变得更加友好 。
邓明轩:我完全同意彭老师提到的观点 。作为开发者,我们应该将自己视为架构师来思考这个问题 。对于这些编程工具、AI 工具,我们可以称之为 Copilot,辅助驾驶而非主驾驶 。因此,我们真正使用的时候,不能期望只描述一个需求就可以迅速完成一个完整的软件 。相反,它为我们提供了代码块,我们有责任将这些组织起来,包括项目的工程时间规划、项目管理等,只有通过自己的思考,我们才能更好地利用这个“副驾驶” 。我们不能把方向盘交给它,让它代替我们驾驶,这是不合适的做法 。
另外,彭老师提到我们的任务是检查安全性,而在生成的代码中又涉及密码等敏感信息,这引发了一个问题:当前的语言模型是基于 Transformer 架构的,而且大多数情况下是盲目生成的,它缺乏自省能力,如果直接向它提问,它会按照神经网络的方式逐字生成结果 。因此,我们需要进行多轮对话 。也就是说,当我向它提问并生成了一段文本后,我可以将这段文本反馈给它,询问是否符合要求或者提出其他的要求 。这些都是与大型语言模型进行互动的良好实践 。
Michael Yuan:我很大程度上同意两位老师的观点,这里只提出一点:当运行一个 Python 脚本时,很可能是在本地环境下进行分析,在这种情况下,使用明文密码可能并不是一个问题 。
那么,这就涉及到 Prompt 工程师在做什么的问题 。Prompt 工程师是否会最终消失?我觉得不太可能,因为 Prompt 工程师是在应对需求并解决需求,就和人与人之间的对话一样,需要经过多轮交流 。
现在,我们公司里大约一半的开发者都在使用 Copilot,每个人每月支付大约 10 美元,因为有一些程序员非常依赖 Copilot 。他们之前是这样使用 Copilot 的:描述一个算法,然后让它生成相应的代码,而并不是像今天这个案例一样,已经将业务需求分割好后再描述一个具体场景 。比如我需要对一个向量进行排序,这都是已知的算法,但我懒得找,所以让 Copilot 来帮忙,我写一个简短的提示,然后让它生成代码 。这就是 Copilot 和 GPT-3 时代生成代码的方法 。


推荐阅读