AIGC 生成代码正流行，对程序员是好还是坏？

作者 | 褚杏娟

AIGC 最大的价值将表现为重塑生产力、重塑开发者工作流程。现在，AIGC 生成的代码是否可以同于生产？AIGC 会给开发领域带来什么变化？程序员该拒绝还是适应辅助编程工具？

6 月 16 日，WasmEdge 创始人和核心开发者、 Second State 联合创始人 Michael Yuan 博士，品览联合创始人 &CTO、极客时间《AI 大模型应用开发实战营》讲师彭靖田，亚马逊云科技大中华区首席架构师邓明轩做客《极客有约》，一起聊了聊 AIGC 与程序员的那些事儿。本文根据直播内容整理，大家可以点击查看完整视频(https://www.infoq.cn/video/D8fRLD8POS4Nq0PGHVrH)。

AIGC 生成的代码如何？

吴少杰：我提前给三位老师准备了一个问题。作为管理者，我们可能会遇到一些与大语言模型生成代码相关的考虑。现在我将展示一段设置好的代码，邀请三位老师进行点评。

我给大模型的描述是：

你是一个 Python/ target=_blank class=infotextkey>Python 工程师，写一个自动检查公司 git 代码库代码合规的脚本程序，功能包括：代码里是否包含数据库密码、调用 pylint 工具检查代码是否符合规范等，把不规范的代码文件信息发邮件给提交代码的程序员，并抄送他的直属领导。生成的结果如下：

# 邮件相关配置SMTP_SERVER = 'smtp.example.com'SMTP_PORT = 587SMTP_USERNAME = 'your_username'SMTP_PASSword = 'your_password'SENDER_EMAIL = 'your_email@example.com'SUBJECT = '不规范的代码文件信息'

# 检查数据库密码defcheck_database_password(file_path):withopen(file_path, 'r') asfile:content = file.read()ifre.search(r'bpasswordb', content, re.IGNORECASE):returnTruereturnFalse

# 使用 PyLint 检查代码是否符合规范defcheck_code_conformance(file_path):command = f"pylint {file_path}"result = subprocess.run(command, shell=True, capture_output=True, text=True)output = result.stdoutreturnoutput

# 发送邮件通知defsend_email(file_path, recipient, cc):msg = MIMEMultipart()msg['From'] = SENDER_EMAILmsg['To'] = recipientmsg['Cc'] = ccmsg['Subject'] = SUBJECT

body = f"不规范的代码文件：{file_path}"msg.attach(MIMEText(body, 'plain'))

try:smtp_server = smtplib.SMTP(SMTP_SERVER, SMTP_PORT)smtp_server.starttls()smtp_server.login(SMTP_USERNAME, SMTP_PASSWORD)smtp_server.sendmail(SENDER_EMAIL, [recipient, cc], msg.as_string())smtp_server.quit()print("邮件通知已发送")exceptException ase:print(f"发送邮件时发生错误：{str(e)}")

# 主函数defmain():repo_path = '/path/to/your/git/repository'

forroot, dirs, files inos.walk(repo_path):forfile infiles:file_path = os.path.join(root, file)

# 检查数据库密码ifcheck_database_password(file_path):send_email(file_path, RECIPIENT_EMAIL, CC_EMAIL)

# 使用 PyLint 检查代码是否符合规范pylint_output = check_code_conformance(file_path)if"Your code has been rated at"notinpylint_output:send_email(file_path, RECIPIENT_EMAIL, CC_EMAIL)

if__name__ == '__main__':main()

邓明轩：这个问题实际上是对大型语言模型的 Prompt 描述，我认为这也是当前程序员需要学习的一项技能，你必须学会如何与大型语言模型进行交互，你可以告诉它代码块是什么样的，请它简化或转化为一个类或打包到一个类中完成任务。因此，Prompt 是一项非常重要的技能，我提醒大家要去学习，并在实际工作中不断提升，这将决定了后续使用这种基于大型语言模型生成代码工具的效率。Prompt 写得越好，效率就会越高。

关于 Prompt，吴老师使用的是中文，我个人认为，在当前的环境中，如果你的英文水平能够达到一定程度，最好开始使用一些英文的 Prompt。我们必须面对这个现实，即大型语言模型目前无论是国内还是国外训练的，它从各种资源中获取的数据更多是英文的，因此大型语言模型对于理解英文的偏好和能力要强得多。当然，我们希望中文的表现越来越好，但这之前，我们应尽量适应这种工具的发展。

可能有人问：有了大语言模型，我们是否还需要学习英语？根据我的个人使用体验，虽然目前大型语言模型在翻译等方面的表现已经相当出色，但用英语直接与它进行交互会有获取更多信息的能力。因此，从短期来看，我仍然认为学习英语会有所助益，尽管对许多程序员来说英语一直是个难题。

就生成的这段代码而言，总体结构非常完整，代码看起来几乎可以运行，但一些配置项可能需要进一步编写。此外，它提到了 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 时代生成代码的方法。

今天，我们生成代码需要进行多轮对话。ChatGPT 令人惊讶的地方在于能够跟随对话，我们可以继续提问，可以在对话中指代之前提到的内容，而它也能理解我在指代什么。当我提供描述并生成代码后，可以运行该代码并将结果反馈给它，告诉它哪里出错了，然后它可以继续生成下一轮代码，通过多次迭代，生成的代码会越来越符合预期。

我认识一个 CTO，他有大约 10 年没有写过代码了，最近他想要创建一个 Discord 机器人，但对于如何使用 Python 处理他并不熟悉。于是，他向 ChatGPT 描述了想要实现的功能，然后 ChatGPT 生成了一段代码。初次生成的代码并不能正常工作，他就将错误信息反馈给了模型，然后重新生成了一段代码。经过几轮的交互，他花了大约半天的时间在一个不熟悉的领域中生成了大致能够运行的代码。我觉得这展示了 ChatGPT 的能力，尽管并不能完全理解需求，但通过不断交互就能够逐渐实现想要的结果。

这并不是说只需简单的描述，大语言模型就能完全理解。实际上很多时候，我们自己都并不清楚究竟想要什么，我们可能需要先看到一些代码，然后逐渐明确自己的需求。这个过程可能需要花费相当长的时间。尽管如此，我仍然觉得这是一项令人印象深刻的技术。

这也给编程工具的用户界面带来了很大的挑战。Copilot 的使用非常简单，你只需在其中编写注释，然后让它将注释转化为相应的代码。这是一次性的代码生成过程，然而要实现更复杂的功能，就需要一个能够支持对话的用户界面了。

生成代码的质量与安全问题

吴少杰：AI 生成代码的质量高低与哪些因素有关？如何消除 AI 生成代存在的安全隐患？

邓明轩：这里涉及两个问题：质量和安全性。质量与我们对 Prompt 工程的学习和掌握有关。而安全性则有两个方面需要考虑：首先是工具本身提供的安全辅助功能，另一方面是作为代码使用者，我们如何考虑安全问题。

我想提一下亚马逊云科技推出的 Code Whisperer 工具，它实际上对代码的安全性进行了检查和提示。当然，尽管可以使用工具来辅助我们更好、更快速地发现安全问题，但我们仍然需要对项目的代码负责。例如，我们需要考虑是否可能泄露敏感信息或者代码是否可能被错误使用，尤其是在涉及对外服务的方面，我们还需要考虑这些服务是否会对其他系统造成重大损害。

大型语言模型的多轮对话会受限于容量，可能只有几十 KB，因此档面对复杂的项目，或者一个由 10 人或 20 人组成的团队时，其容量可能远远不够。此外，还有整个软件环境，包括软件设计和需求描述等方方面面的考虑。因此，作为程序员，我们需要对这个领域有全面了解，从头到尾清楚了解相关结构。在这种情况下，我们会将其中的细微问题拆分出来，与大型语言模型进行交互，一定程度上避免由于容量限制而无法处理复杂的逻辑跟踪。当然，这也涉及到安全性的问题。

回到质量问题，我认为质量同样是程序员的责任。在这方面，工具也对我们提出了一些要求，如果你的代码质量较高，那它将更容易理解，生成代码的可用性也会更高。最终代码质量的责任仍然在于代码的拥有者，也就是我们自己，我们需要真正对此负责。

Michael Yuan：对于代码质量，有一些简单的方法可以采用，例如将代码与编译器进行链接，使生成的代码立即进行自动编译，并通过编译器提供的错误信息进行修复。此外，还可以与数据库等工具结合使用，自动扫描检测常见的问题。所以，代码质量并不是一个无法解决的科学问题，而是一个工程问题，我们可以通过各种工具的结合来不断接近最优解。

不过，目前对代码质量的控制问题可能会有一些争议。目前，从个人角度来评判代码质量的一个重要标准是可扩展性，也就是代码编写后是否容易修改。然而，现在有一些流派认为，未来尤其是对于前端框架而言，这种代码质量可能并不重要。

可以设想一个未来的场景，整个应用程序都是由大型模型生成的，不存在需要人为修改的问题，如果需求发生变化，只需重新生成代码即可。某些场景下，每次生成的代码都只使用一次，不存在扩展代码的问题。当然，现在可能还无法实现这一点，但这是一个可能出现的未来，如果成为现实，那么会对代码质量的评价产生重大影响。因此，我认为在架构上编写可扩展且优雅的代码并不重要，至少在某些场景中不重要。

我们再谈谈第二点，即安全问题。我认为，人类编写的代码在某种程度上也是相对安全的，否则就不会存在那么多问题，也不会有像 Rust 这样的语言出现。对于安全问题的解决，人们在编写代码时已经用了很多工具，例如 Rust 通过编译器解决内存安全问题、JAVA 通过运行时方法解决内存安全问题等。

多轮对话的有趣之处在于，生成的代码可以通过工具运行，然后将工具的结果反馈给模型，然后模型做进一步优化，这个过程可能比人类做得更好。

彭靖田：我最后补充一个我个人非常认同的观点，即关于“我们今天应该如何解决 AI 生成代码的安全隐患？”这个问题没有太多可讨论的，因为这与 AIGC 无关，代码就是代码，无论是谁生成的都存在安全隐患，所以我不想讨论这个问题。

我更关注生成代码的质量高低，也就是 AI 生成代码的问题。目前，有两种对此完全不同的观点。有一类观点认为，每个人都应该开发自己的大模型，因此出现了很多专注于大模型的创业公司。然而训练语料库是有限的，在 OpenAI 和其他国外大厂已经做了很多投入的情况下，是否值得从零开始开发一个大模型还需要探讨。我们需要知道的是，一些大模型并没有特别针对编写代码这一任务进行增强，特别是当我们要在生产环境中将其作为生产力工具替代选择时。

我们招聘一个研发工程师时为什么要写招聘要求？为什么要对研发工程师进行分类？因为他们花了很多时间进行自我训练，他们的训练来自各种类型的教程、框架手册、项目实践等。如果你的公司有自己的代码库，可能没有开源，或者你正在进行一个特定领域的项目，有许多开源框架和基础项目代码，那么是否应该进行 fine-tuning（微调）？是否可以提升模型的权重，使通过 fine-tuning 得到的模型能够更好地解决代码生成问题，而不是从零开始开发一个模型？我认为这可能是一个可以考虑的方向。

关于 AI 辅助编程工具的使用建议

吴少杰：三位老师平时会 AI 辅助编程工具来做些什么？是否可以提供一些使用建议？

Michael Yuan：我们团队主要使用 Copilot 来生成代码，因为它与 Github 的 IDE 结合非常紧密，我认为这一点非常重要。如果你要在其他地方使用它，你就需要打开另一个用户界面（UI），这将增加工作量。然而，刚才提到的多轮对话生成应用并且使用人工工具进行检查，这是一个很好的方向。比如，我可以将它集成到问题跟踪（Issues）或讨论（Discussion）中。

关于代码质量本身，有很多工具可供选择。今天代码中的许多问题都源自所谓的供应链问题，这意味着你依赖于其他人的代码，如果其他人的代码出了问题，你的代码就会受到影响。另外，复制、粘贴的代码可能会在大型模型中带来更多问题。这段代码可能不是在 NPM 或 Cargo 的包管理器中引入的，而是来自 Apache 或其他许可证的，如果出了问题或者上游进行了修复，开发者可能并不知道，这种情况下就需要更深层次的代码检查器。

在 AIGC 中，这种代码检查器也特别有用，其实就是用同一个工具解决可以两个问题：一个是解决代码来源和许可证不兼容的问题；另一个是，如果上游代码出了问题，有工具可以跟踪并通知开发者，然后对下游代码进行相应的更改。

当然在编写代码后的测试是必不可少的。我们在用的 Rust 有很多工具选择，如快速测试（fast testing）。实际上，快速测试也是一种机器学习方法，它不断测试输入和输出边界，然后看代码是否出错。在这方面，我认为大型开源项目会提供这种专门的服务。我们的项目为什么加入 CNCF，主要是因为 CNCF 与 google 合作提供了这样的服务。但这需要大量的机器时间不断地进行编译和测试。

另外，每个项目的情况可能都不一样。我们使用的是 Rust，因此我们有一套特定类型的工具。而对于使用 Python 的项目，可能要用其他不同的工具，因为它没有内存安全的问题，但有其他要解决的问题。

彭靖田：我觉得目前最好用的工具还是 AI 辅助编程工具本身。大部分工作仍然是基于大模型进行的，开发框架的迁移还不够成熟。

我认为从安全的角度考虑是非常重要的。比如，对于我们要与 Autodesk 工业设计软件（如 AuthCD 和 Rivet）竞争开发的 SaaS 产品，如果接入 AI 生成的代码，需要如何处理呢？实际上，传统的软件工程方法仍然非常有用。软件工程告诉我们需要进行环境划分、编写良好的测试用例、采用不同的测试方法，并在各个环境中有测试人员关注一些边界情况和使用场景。

举个例子，我们有个环节是将用户上传的 CAD 图纸通过计算机视觉和深度学习算法转换为三维模型。但建筑设计师绘制的 CAD 图纸也存在很多问题，他们没有编译器，也没有测试环境，只能依靠施工现场的人逐个解决。这其中有两类测试问题：一种是代码确实存在问题，这类问题可以通过软件工程的方法解决；还有一类问题更偏向于算法和领域场景，即输入数据本身就不够健壮和稳定，这种设计上的问题需要进行降级处理，捕捉异常。

邓明轩：现在的大语言模型在架构上有多种路线，但是现在有一种观点认为，模型的架构本身并不重要，只要我们有充足的连接，即非线性的连接，并提供足够多的数据给模型进行训练，它就能够产生很好的效果。因为这些模型内嵌了大量人类知识，尽管不是全部但可以通过使用足够大的模型将文本输入其中，进而实现预期的效果。因此我个人认为，底层的算法结构可能并不会对上层的应用产生太大影响。

关于代码质量检查工具的使用，我同意两位老师提到的观点，即最好的评估方法就是运行它。现在普遍使用的是解释型语言和编译型语言。在这种情况下，解释型语言具有一定的优势，因为可以直接将生成的代码输入语言环境中进行解释和运行，捕捉可能的错误，然后返回给大语言模型。对于编译型语言如 Rust，需要设置额外的运行时环境来进行编译和运行。总之，对于代码质量来说，“无论是白猫还是黑猫”，只要能够满足需求就是好的。

此外，现在许多与大语言模型相关的接口使用的都是 Python，在神经网络和机器学习领域，Python 是主流语言之一，具有动态解析和良好的语言支持。我认为，未来可能会进一步推动 Python 的发展，比如在大语言模型中生成一段代码后，直接在 Python 的运行环境中进行评估和调试，然后返回结果给大语言模型。

现在有许多与语言相关的 LangChain 或其他外围框架，这可能是未来的发展方向之一。通过额外的框架配合，可以在语言的运行环境中进行多轮对话，自动检查代码质量，无需人工干预，我们只需要描述要完成的任务，然后让系统开始运行即可。如果出现错误，系统会自动进行修改，并再次运行。

关于代码安全性，实际上在我了解 CodeWhisper 时，也思考过版权问题。我们使用大语言模型生成的代码，但对于它的版权关系并不确定，比如它使用了什么开源许可证，如果你的代码在结构上与某个开源许可证中的代码完全一致，那根据过去的案例，你可能会被诉讼。这对于使用这些工具的程序员来说是一个挑战。

零基础如何使用 AIGC 工具

吴少杰：这里有个观众问题道，“零基础学员如何使用好这些工具，需要提升哪些点？比如大模型给出几段代码，但是我却不懂，很好的调试可以达到执行。”

邓明轩：如果是零基础，那么了解一些编程概念是有必要的。如果有一些基础，只是不够深的话，那与大语言模型进行互动是一个不错的方法。

可以从简单的例子开始，比如我们之前写代码时常用的“Hello World”。现在你可以要求模型给你一个 Rust 版本的“Hello World”，虽然可能一开始看不懂，但可以直接运行这段代码，如果出现错误了就把错误信息反馈给模型，询问出了什么问题，这样的交互循环可以让你快速学习新技术。另外，还可以选择一段代码并要求模型解释它是做什么的。然后进一步问，比如要在其中添加一个循环或者一个条件分支该如何实现？总之，你可以慢慢学习，逐渐形成对编程的基本理解，关注在代码的运行逻辑上，而不是语法结构。

每种语言都不同，你并不需要详细研究每种语言的具体细节，只需要理解基本的概念，例如循环、分支，包括递归以及更复杂的数据结构等。关键时通过交互的方式逐步构建这些概念。我认为，有了这些工具之后，学习编程会更快速，而不是有些人担心的那样“程序员会失业，不需要学习了”，这实际上降低了编程和与计算机对话的门槛。

Michael Yuan：“有了更好的工具后，程序员就要失业了。”这种话我听了二十多年了。我还记得过去有种说法，“大家都不要学计算机了，因为都要印度人去做了，你们没有机会了。”但事实证明并非如此。我对大语言模型的理解是，它是程序员的工具，程序员会用它来辅助其他人工作，这就是我不同意 OpenAI 那篇报告的原因。

OpenAI 的报告声称洗碗和刷房子不会失业，但实际上洗碗也会失业，因为程序员会有更多的时间开发出洗碗机器人，取代所有洗碗的人，所以程序员也是可以卷走其他人工作的。大模型可以大幅提高程序员的能力，有了大模型后可以很快地学习和理解。

回到之前的问题，之前计算机科学的书籍和教育对我们有很大的影响，我自己也写过几本书，写书的时候通常会从背景开始、介绍概念开始。有些语言容易有些就难，有些语言概念非常多，比如 Rust 概念很多，学习起来比较困难。但使用大模型后，它可以解释很多东西，还可以完全根据你的学习需求进行定制。

为什么很多人的编程学得不好？因为编程不是一种立竿见影的事情，你需要从一些没有意义的事情开始做起，比如写一个“Hello World”能有什么用？它解决不了实际问题。但就像我之前提到的，有了大模型后，我朋友花了半天时间写了一个 Discord 机器人，你也可以轻松地写出类似的东西。你可能并不完全理解为什么这样写，但你可以逐步改进，通过自己的努力学习快速掌握它的用法。

邓明轩：我当年学习编程语言的时候，买了一本书，还要去机房上课，然后我们敲了一些代码却出现了错误，我们不知道什么意思，老师也不懂，甚至书上也没有解释。我们只能自己摸索和尝试。在那个年代，学习计算机编程是非常困难的。我不知道提问的观众是多大年纪，可能年龄较小。你们非常幸运，生活在这个时代，有机会接触到不断发展和提升的技术。我鼓励你们充分利用这项技术，因为未来可能会有各种惊人的可能性出现。

彭靖田：之前，我将评估一个优秀开发者技能的维度分为四个部分：首先，编程和调试技能，也就是实际操作的能力，占比 40%；其次，项目管理和协作能力，占据 30% 的权重，这意味着作为一个独立的开发者，你能够交付代码，并且能够与团队、需求方、测试方以及其他开发团队成员进行协作；接下来，算法和数据结构，占据 20% 的权重。计算机科学专业的人可能对数据结构和算法会有更深入的理解；最后的 10% 留给软件工程经验，也就是在实践中积累的最佳实践经验以及对优秀软件工程师的观察和学习。

但是现在，我有了不同的看法。关于那 40% 的技能，我会进一步抽象为大模型的应用实战能力。这意味着你有更多的最佳实践，而不是仅仅学习某种编程语言，浪费大量时间和精力去学习每一个知识点。正如这位提问者提到，前后学了 QBasic、Basic、Java、C++、Python、Go 和 Java 的派生版本等多种编程语言，这些语言都介绍了基本的数据类型，这可能会带来一些困扰和混乱。但实际上，数据类型并不是很重要。

一个没有学习过编程语言的人应该如何做？以前我们会从基础语法开始学起，但现在语法并不那么重要了，重要的是对编程语言的理解。比如理解编译型语言和解释型语言的区别，为什么自 Python 3 以来一直在强调类型标注？为什么一个本来应该非常灵活的语言现在越来越强调类型，并且推出了许多相关库？事实上，这就是所谓的 Prompt 实际上变成了与英语一样重要的语言技能。

还有 20% 我留给了人机和团队协作。现在我们可以与人工智能和大型模型进行协作，它们不会抱怨、不会说我们蠢，也不会在背后说坏话。如果你无法与这样的一个合作伙伴进行有效协作，那肯定是你自己的问题。

这些工具还有哪些问题

吴少杰：现在的辅助编程工具还存在哪些问题？提供厂商需要做哪些改进才能更好满足程序员的需要？

邓明轩：目前工具的交互模式和发展都处于不断演进的过程中，还有很多空间可以探索。近一年来，我们经历了一个技术爆炸，整个行业也在思考这些工具应该具备怎样的形态。因此，过多地关注当前工具的局限性可能并不是非常有益。也许三五年后回头来看，我们会发现现在的情况非常有意思。

不同的厂商推出了自己的工具，但他们并不是要将这些工具作为盈利手段，而是通过这些新的交互模式将用户引入到某个平台上。对于如何将这种能力更多地扩展到用户手中，大家应该有相对一致的想法。我个人的体验是，我真的很希望有一个像《钢铁侠》中的贾维斯那样的助手，我可以用自然语言与他进行沟通，他能理解并帮助我完成许多任务。这种辅助性工具确实是我非常期待的东西。

Michael Yuan：我觉得投资人可能更加焦虑，因为他们可能会发现某个工具很好，但过几天就被 OpenAI 或其他公司干掉了，甚至有些简单的工具已经被别人复制了。目前工具方面有很多创新。例如 OpenAI 最近发布的 Function Core 可以直接从大模型生成数据结构，然后与核心函数结合。

工具创新的领域很多，甚至比底层大模型的创新和迭代速度都要快。为什么会这样呢？因为底层大模型需要耗费大量资金和时间进行训练，而现在正是一个百花齐放的时代，有大量不同的想法和方向。对我们来说，一个特别有用的工具是如何让多轮对话生成代码的界面更加友好，能够吸引更多人参与。以前的研发管理工具中并没有考虑到这一点。

吴少杰：三位老师观察，周围使用 AI 工具来生成代码的人多还是不用的比较多？各自团队的研发效率大概能提多少？20% 还是 30%？

Michael Yuan：实际上我们有自己的数据，但我认为还不足以进行直接比较。Twitter 上有很多比较。实际上，一些经验丰富的人更不愿意使用 AIGC，因为他们认为自己可以写得比 AIGC 更好。而那些比较初级的或者经验较少的程序员愿意使用 AIGC，他们代码编写速度和完成度要比那些资深程序员高得多，这不是两倍的差距，而是几十倍的差距。当然，也可以说经验丰富的开发者写出来的代码更容易扩展。但是如果有了几十倍的差距，那么下次直接重写就好了。

邓明轩：我观察到，小型初创公司在技术选型上会更快一些，因为他们可能更加灵活。对于一些大型企业，特别是传统企业，开发部门可能比较庞大、流程也比较复杂，目前找到合适的方法将这些纳入到整个软件工程流程中仍是一个问题，所以我认为还需要观察。

如果你的定位是写一些胶水代码或者试验性代码，那可以快速适应。另外，如果你所在的公司比较灵活，我建议大家去尝试。如果你有一个由 5 个或 10 个人组成的团队，并且你们的效率是巨大公司的 30～40 倍，那么你就可以与这些大型公司竞争了。

当然，对于传统的大型软件开发公司或大型 IT 部门来说，短期内将这些融入到开发流程中具有挑战性，大家可能还没有完全明白该怎么做。我们可以稍微放慢一些节奏，在比如半年或一年后，再来看看如何将这些纳入整个团队中。

彭靖田：这是一个趋势性的事情。拿我们团队来说，我们目前没有专门的运维人员，只有一个后端同事兼任运维工作，如果是一个大公司就会需要一个团队。他需要管理华为、亚马逊云科技以及字节的云平台，每个云平台都有自己的 Kube.NETs 集群，这意味着他需要管理 7～8 个集群。一个云平台上可能会有多个环境，而且不同环境之间的命名空间和优先级可能也不同。七八年前刚接触 Kubernets 时，我就觉得这是一项非常复杂的工作，包括今天的 Kubernets 生态社区中，很多人就在做调度策略、HPA 等各种工作。

但实际上，大多数团队只使用了容器云的一些基础功能，特别是在运维方面，大部分工作都可以自动化。比如 GitLab 现在强调 DevSecOps。整个 CI/CD 流程实际上由许多脚本组成，以前这些脚本被认为是运维专家的特殊技能，但实际上并没有那么神秘，也没有那么多技巧，大模型可以解决这些问题。

我们那位后端同事使用了很多自动化技术，但还没有将 GPT-4 作为日常工具，最近两个月里他一直没有解决一个偶发性问题。我们一直使用较大的节点，最小的节点大约都有 32 个核心和近 200GB 内存的资源池。在这样的一个节点上，我们通常部署 200-400 个应用程序，而这些应用程序的请求资源可能只占用 0.5 个 CPU 核心和 2GB 内存，但这时候，他们的请求已经接近我们的资源上限。但它是一个流水线，不断地在消耗资源，以至于有的应用程序刚启动，另一批应用程序可能已经关闭了。

这里的问题在于，多云环境中的底层硬盘共享有一个阈值限制。当应用程序特别多时，这个默认阈值可能会被打破，导致应用程序无法启动。他发现应用程序无法启动，但 CPU、内存资源都足够。因为多云在虚拟化存储时，借用了一部分硬盘来进行虚拟化存储，但实际上用不满。他无法解决这个问题，我获得权限后把那个节点上的日志原封不动地交给 GPT-4，它告诉我只需重启一个命令，将阈值改为合适的值就可以了。起初，后端同事还不相信，他去 Stack Overflow 上查找，但结果各不相同。最后他按照指示执行了命令，问题解决了。

对我们这个同事来说，这个问题只是一种认知上的偏差，但提升的效率是非常显著的。对于那些 1～3 年里都在写 SQL 和编写 CRUD 业务逻辑的开发工程师来说，未来的代码效率也会大大提升。

AIGC 对程序员的影响

吴少杰：当大规模使用 AI 辅助编程工具时，企业对程序员的要求会发生哪些变化？

邓明轩：我认为，现在互联网降本增效和技术变革可能不处在同一个趋势上。技术变革主要受疫情和国际经济关系等因素的影响，个体很难改变，我们只能在这种情况下尽力发挥自己的价值，比如在降本增效的压力下如何展现自己的能力。

作为个体，我们应该如何适应这个新环境？首先，我们需要在心态上保持开放，接受这种新事物，迅速了解并进行实践。正如刚才提到的，实际上事情变得更容易了，而不是更难了。

另外，要学会学习的方法，这非常重要。未来，具体编程语言的语法结构等可能并不那么重要，重要的是如何具备良好的学习能力、快速适应新环境。我认为这是一项非常重要的技能，这次的技术变革就给我们提出了新的挑战。希望大家保持积极乐观，因为工具也带来了很多机会。

Michael Yuan：程序员有一个优良传统，就是喜欢亲自动手去做，而不是空谈。在技术领域，那些只会谈论却无实际行动的人会让人感到厌烦。大型模型特别好的一点就是，它们可以让人立即动手尝试，我其实很喜欢这一点。

彭老师也讲他的整个项目都是通过 AIGC 完成的，包括项目的推广和市场营销都是由模型生成的。这个过程中有很多工具可以用，一旦尝试了这些，你就会知道这个东西的大致边界在哪里，因此也会有正确的预期。最难的一步可能是迈出第一步。

彭靖田：企业对程序员的要求会有哪些变化？实际上，我认为这个问题并不是从甲方的角度提出的，因为甲方对程序员的要求一直都是一样的：快速、高质量、低成本，就是要多快好省。从这个角度看，无论是程序员、开发人员还是内容生产者，作为提供服务的人，我们需要解决的问题就是如何更快、更好地完成工作。

我们和动物的区别在于我们懂得利用工具，而且我们的工具变得越来越巧妙、易用，我们也越来越擅长改造工具，使其更适合人类的需求。从这个视角来看，我们每个人都应该迅速拥抱这些新工具。想象一下，如果你的老板让你打车，你会站在路上等出租车吗？不会吧，你会使用滴滴、高德地图、美团打车，这个逻辑很简单明了。

嘉宾们的自我介绍：

吴少杰（特邀主持）：

我之前在 58 集团、新浪微博负责过推荐算法相关的工作，现在在垂直行业做智能算法，给业务赋能。

邓明轩：

我已经从事编程工作 23 年了。我 2000 年毕业，陆续加入了 IBM 和苹果等公司。目前我在亚马逊担任首席架构师。个人而言，我对编程非常感兴趣。事实上，从我毕业至今的 20 多年间，我一直都在编写代码。尽管最近一两年由于工作中的事务性任务增多，我编写代码的机会相对较少，但我仍然对此感兴趣并愿意自己去写代码。在当前通用人工智能大语言模型的发展中，我注意到它对整个编程技术产生了巨大影响。我很高兴能够在有生之年经历这一切。

彭靖田：

我从中学开始接触编程，有大约 15 年左右的编程经验了，至今我一直在编程语言和算法一线。2015 年，我在大三时开始接触创业，跟着浙大学长拿到了真格徐小平老师的天使轮融资，做了一个辅助诊疗的 App，是基于 NLP 和深度学习的 AI 系统。从加州大学访学结束后，我加入了华为 2012 实验室，从零到一参与了华为深度学习平台 ModelArts 的设计和研发工作。之后我作为技术合伙人加入了才云科技（2020 年被字节跳动收购后，整合为了字节火山云）。现在这家公司——品览是我的第三段创业经历，我是公司的联合创始人和 CTO。我们致力于用 AIGC 赋能建筑设计，弯道超车 AutoDesk 的产品。

除了创业外，我也非常喜欢开源。从上一轮深度学习的火热时期开始，我在很早期参与了 Tensorflow 项目的开源贡献，2017 年与华为两位同事一起合作出版了国内首本深度剖析 TensorFlow 框架的热销书《深入理解 TensorFlow》。在才云时期，我们与谷歌云团队共同发起了了一个 Kubeflow 的开源项目，它现在已经成为 MLOps 领域的事实标准之一。现在我积极拥抱大模型，也在极客时间开设了《AI 大模型应用开发实战营》课程，欢迎订阅和交流。

Michael Yuan：

相比大家，我的编程起步比较晚，因为我是在博士毕业后才正式开始编程的。当时找不到工作，于是决定尝试寻找程序员的职位。我发现大厂不愿意雇佣没有实际编程经验的人，所以我决定从开源项目入手。那是很多年前，当时 Java 刚刚在服务端起步，所以我早期参与了 JBoss 这个开源项目，我们开发了当时也是现在最流行的 Java application server。后来我们将公司卖给了红帽软件公司。之后，我一直在开源社区中进行项目开发，也在公司工作过，还做过投资人，一直与开源社区和开发人员保持密切联系。期间，我出版了 5 本书。

我目前有一个开源项目叫做 WasmEdge，它是 CNCF 的一个项目。我们主要开发 Rust 和 WebAssembly (Wasm) 在云原生与 AI 的应用框架与运行环境，大家可能会觉得 Rust 语言很受欢迎，但也有很多人认为它很难学。我们现在认为，使用大型语言模型来教授人们学习 Rust 是一件非常有趣的事情。另外，因为我从事研发管理工作已经很多年了，我发现使用大型语言模型，确实可以提高开发效率。