神器还是垃圾？那些用 AIGC 编程的人，实践得怎么样了

“大部分脚本，它写的都能运行，而且比我写的还要好。”这是刘立在小试 ChatGPT 之后的感受。现在，网上已经不乏对以 ChatGPT 为代表的代码生成工具的称赞，还有大量五花八门的使用教程。

程序员是好奇心比较强的那批人，也愿意去先吃螃蟹。2020 年 GPT-3 发布后，他们开始摸索用大模型或 AI 来辅助编程。GPT-3 在当时虽被认为是“巅峰之作”，但还不能与人对话，并未引起全民高潮。

对于绝大部分程序员来说，2021 年发布的 Copilot 可能是用大模型辅助编程的启蒙。Copilot 由 GPT-3 修改后的生产版本 OpenAI Codex 提供支持、接受了一系列公共 GitHub 储存库和其他公开可用原始码训练的辅助编程工具。

Copilot 迅速引起了开发者们的注意，并得到了很多程序员的认可。“程序员比较喜欢的一种工作方式是，我讲清楚需求是什么，你能直接给我回答。”WasmEdge 创始人、核心开发者 Michael Yuan 说道。当时的 Copilot 做到了这一点，只要给出比较准确的描述，它就可以自动生成一段代码，使用起来很方便。

“在此之前的产品，大家更多视为玩具，很有意思但不会真正使用，更不会真正花钱。Copilot 做到了让我们付费使用。”Michael 表示，这对一直将 GitHub 视为免费工具的团队来说，选择付费并不是容易的事。

但在当时，Michael 公司内部的开发者对 Copilot 态度是两个极端：一部分程序员非常喜欢它，甚至到了离不开的程度，而另一部分程序员认为它非常“脑残”，甚至看不起用它的程序员。这种态度分化，可能至今仍然存在。

就像 Copilot 创建者之一 Alex Graveley 说的，“代码推理具有明确的线性，而 AI 模型比较适应这种一件事做下去、前一件事对后一件事产生影响的应用场景。”从 GPT-3 发布至今，大模型在生成代码上表现得比生成自然语言要先进一些，因为代码只有是或不是、不容乱说。

到了 GPT-3.5，大模型的编程能力和逻辑能力有了非常大的提高，不仅可以生成代码、添加注释，还可以跟程序员对话，进一步解释这段代码。而经过两年的验证，GitHub 证明了 AIGC 工具在写代码和 Review 代码这两个场景的可用性。

“我从刚开始的天天用它生成代码，到现在摸清楚了，基本上不用。”

以 ChatGPT 为例，ChatGPT 给出的很多答案其实谷歌 +StackOverflow 就可以查到，但是很多新手不会用这套组合，ChatGPT 只是降低了这个门槛，给出了各种质量参差不齐的答案。ChatGPT 通常很难一次就给到正确的代码，需要开发者反复调教。

另外，有开发者评价 ChatGPT 生成的代码很难实际使用，越深层的东西越没用。“稍微进阶一点的代码，生成得又慢又难用, 不调整根本用不了。”

南达科他州立大学生物信息学家 Xijin Ge 曾建议：把 AI 当作暑期实习生，一些开发者也认为其更很适合新手或者作为辅助工具。

不过，还是有开发者表示，虽然是复制粘贴的水平，但能理解代码已经很不错了。在 Michael 看来，代码产生问题的可能性是最低的，因为生成的代码可以立刻用起来进行检测。

很多人吐槽 ChatGPT 总会先给错误代码，再让它检查一遍后就会给出正确答案，这是因为答案的给出是一个概率事件，它只是给出了其中一个答案。要提高正确率、不让它“胡说八道”就要给更详细、准确的提示词，让它能够更好地反馈出所知道的内容。

“泛泛的提问，初次会有惊艳的感觉，但问多了会有错觉：不过如此，那是因为不会提问。”刘立也表示。“当你告诉它回答要有事实根据后，它的准确率就会提高很多。”

这种需求也催生了“Prompt 工程师”这一岗位的大热，他们通过自然语言对预训练大语言模型进行操作，并对输出结果进行调优。凭借大模型的反馈机制，生成的代码马上编译测试，甚至可以有自动化机器人一直测试直到生成生产可用的代码。国内有企业开出 60 万年薪招聘 Prompt 工程师，国外不仅岗位数量更多，年薪甚至最高达到了七位数。

ChatGPT 需要了解项目或需求后才能给出比较好的建议。但大模型的记忆量不大而且都是短程记忆，这常常导致“AI 幻觉”的出现。为解决这个问题，业内目前将目光聚焦在了向量数据库上，向量数据库擅长从非结构化数据中提取见解，查询延迟也更低，很适合 AIGC 应用。

不过，即便可以给出正确的代码，用 AI 生成代码仍有很大的风险。

各种 AIGC 编程工具会标注这些生成代码的来源，因此企业不清楚来源，即使是开源代码也有不同的许可证需要遵守，但许可证通常不可见。另外，对企业来说，使用第三方工具还有数据泄露风险。因此，Linux 基金会也不鼓励项目直接用 ChatGPT 等来写代码，三星、苹果等公司都不允许员工在内部使用 AI 辅助编程工具，甚至谷歌也提醒自己的工程师避免直接使用 Bard 生成的代码。

除此之外，生成代码还有版权问题。版权必须要百分之百匹配，只是部分匹配不算严格拥有版权。代码版权是可以检测的，比如发现某段代码是 GPL 的则可以重新生成。但这并不代表版权问题很容易解决，原理上可以用工程化方式解决，但要消耗大量的人力、时间和金钱。

“能用工具实现的尽量不需要人参与，人只做机器无法完成的事情。”

相对写代码，Review 代码就没有上述问题。Review 代码主要有两步：第一步是做自动化检测；第二步是提供反馈，至于对反馈是执行还是不执行、怎么执行，还是由人来决定。

Review 代码很重要，但传统的方式又很麻烦。大项目中，可能是初级程序员花了数个小时写完代码，然后资深且对项目熟悉的人需要花上几天的时间来 Review 代码。

因此，ChatGPT 刚出来没多久，Michael 团队就做了一次 Review 代码测试：在 Patch 文件故意添加了一个无限循环的 Bug 让 ChatGPT 检查，看它能否读懂 Patch 文件并找出其中的 Bug。结果，ChatGPT 不仅读懂了，还找出了这个无限循环，并礼貌地说：有时候无限循环是代码逻辑的一部分，但是这个是 Bug，可以再检查下。

“当时我们很震惊，觉得是不是又有一个产品需要付费了。”Michael 玩笑道。

一方面，很多开发者会用 ChatGPT 等工具来 Review 公司的业务代码。公司团队成员彼此熟悉，很多时候同事之间碍于情面很难直接指出对方的问题，用工具 Review 代码就更直接些，没有其他因素干扰沟通。还有一些新的开发者不会读编码规则，ChatGPT 等可以自动检查并指出不规范的地方，并耐心对待对总是犯错的人。

另一方面，ChatGPT 等工具也可以用来帮助 Review 开源社区里提交的代码。开源社区的人互不认识，项目负责人也不清楚提交者的能力和目的，用工具 Review 会减少很多时间和沟通成本，也可以及时给提交代码的人反馈，避免拖延。

“我们社区以前就遇到过这样的问题，因为人手有限，不能第一时间反馈，就有贡献者觉得不爽。用了工具后，我们可以知道新提交的代码大概在解决什么问题再检查反馈给提交者，这种体验对开源社区来说是很大的提升。”Michael 表示。

Michael 认为，现在 ChatGPT 在纯算法题方面已经达到了很高的水平。他举了个例子：团队里有人用 JavaScript 写了一个 Check Prime 函数，用来检查输入的整数是不是质数。通常的做法是从 2、3、4……一直试到√n，看能否被整除，能被整除就说明这个数不是质数。当用 ChatGPT 自动 Review 时，ChatGPT 提出这个算法可以改进：偶数不用重新 Check，因为不能被 2 整除的数必然不能被 4、6、8 等偶数整除。

“这是很多人可能会漏掉的一点。ChatGTP 不仅可以提醒出来，程序员还可以跟它继续对话，比如继续追问质数是不是也这样，达到举一反三的效果。”Michael 说道。

有人详细 对比了 用辅助编程工具与不用工具的程序员之间的差别。拥有 19 年编程经验 Alex 100% 纯手动编程，仅拥有 4 年开发经验的 Hamid 采用手写代码 +Copilot+GPT-4+ 无代码开发。对于同个项目，Hamid 在一周之内完成，端到端测试与测试覆盖率均达到 100%，开发总成本为 3819 美元；Alex 则只完成了 7%，开发成本为 3520 美元。

生产力上的巨大差异引发了网友们的广泛讨论。Michael 也以 Review 代码为例说道，“PR  Review 代码通常需要 3～4 天，如果一个公司全面贯彻用 ChatGPT，时间降到一天的可能性是很大的。”

当然，有人提出这样的观点：有经验的程序员写的代码质量高，没有经验的程序员无非就是不停测试、跟工具讲正确的话让它生成短代码，但工具没有全局观，所以大概率生成出来的代码很难维护。

Michael 对此的想法是，之前的代码要易管理是因为维护成本很高，如果有工具可以把写代码的成本降低 10 倍、速度提高 20 倍，那么业务代码根本就不需要维护，有了新需求直接重写就可以。就像今天没有人要维护编译器出来的二进制文件，只需要维护源代码就可以了。

几十年前，程序员写汇编语言，之后成了写抽象的高级语言，后来有了 Python 等。之前的汇编语言程序员会觉得今天的程序员都不叫程序员，因为机器不能直接理解、代码还需要编译，他们会认为程序员的能力下降了。从这个意义上来讲，编程的门槛确实降低了。

今天的程序员有个很重要的能力就是像机器那样思考，如果有一天用自然语言编程、用需求编程，这个技能或许就不重要了，但程序员需要思考的东西会更高一层。

“我觉得未来，开发者需要维护的会是需求，一旦需求变了就可以直接重新生成代码，尤其在前端应用上。”Michael 表示，前端的需求相对比较直接、框架也多，这意味着前端领域有各种各样完成项目的方法，这是对工具友好的。

随着各种 AIGC 工具的流行，写代码这件事可能会发生本质上的改变，今天写代码非常重要，也许在未来会变得不重要，会更倾向产品经理去做。

如今，用软件写代码越来越“copy”化，很多新的开发工具完全围绕这个理念设计，用不用 AI 辅助编程工具的差距似乎越来越大。虽然有泄露数据、代码来源不明等风险，但对于企业来说，当这个差距到了一两倍时就会不可接受。

在这种矛盾下，各企业开始寻求训练自己的模型，即使不对外商业化，但只要能用低成本训练出自己的模型供公司内部的开发者们使用，并提高了生产力就可以了。这促使很多企业和个人特别关注开源大模型，毕竟从零开始训练大模型的成本实在是太高了。

众所周知，要做自己的大模型，预训练非常重要，但又非常容易出错和昂贵，没有几百万美金搞定不了。另外，由于 GPU 内存问题，OpenAI 这样的公司都会对用户输入的上下文长度和一次输出的内容长度进行限制。

Meta 2 月“泄露”的 LLaMA 为开源大模型提供了实验的可能。LLaMA 已经用大量语料做好了预训练，其他人在上面微调即可，训练成本及训练速度都要优于 GPT3.5。

现在很多开源模型都是基于 LLaMA 进行二次训练，如 Vicuna、Alpaca、GPT4All-Snoozy 等。以 LlaMA 的衍生模型 Alpaca 为例，其训练成本仅用了 52k 数据和 600 美元，这对企业来说是完全可以接受的。

但现在的开源大模型还处于鱼龙混杂的阶段。虽然很多开源大模型都说自己跑分很高，但没有一个开源大模型能够证明训练数据集跟跑分数据集是分开的，事实上也很难分开，互联网上到处都是 GPT 生成的内容，很容易污染跑分水准点。所以虽然跑分很好，但真正用起来的时候就会发现，绝大部分并没有达到声称的 90% 的水平。

开源虽然降低了企业使用大模型的门槛，但还不够低，有些公司已经开始重新组织自己的 AI 部门进行探索。

根据 Stack Overflow 的最新调查，44% 的开发人员会在开发过程中使用 AI 工具，这也意味着有 56% 的人还没有用。实际上，经过调查和询问，确实有很多程序员只是初步试玩了下，并没有将 ChatGPT 或 Copilot 用在工作中。

“只能说有没有关注新技术吧，没有在用的人估计还不清楚能给自己节约多少时间。”开发者张涛说道。虽然张涛所在企业明确不要在公司使用 ChatGPT 等，但他还是会自己偷偷使用。

在 Michael 看来，如今的大模型虽然并不完美，但它更多是让大家看见了很多未来的希望。程序员与 AIGC 是赋能关系，而非取代的关系。拒绝 AIGC 工具的人可以不喜欢，但至少可以包容，对它们提出的意见可以视而不见但不用着急拒绝。

“我可能就是属于比较乐观派的，认为这东西有用，不过我也说服不了不用的人。有人说这些工具有各种各样的问题，他们说得都对，只是我认为这些问题有办法解决而已。”Michael 说道。

电子刊推荐

AIGC 行业有哪些最新动态？Prompt 工程师、AIGC 辅助编程实践如何了？企业在算力优化、智能客服等表现如何？

本文节选自《架构师特刊：天工开物 AIGC》。本期我们围绕“AIGC”主题，邀请了来自不同领域、不同行业的 AIGC 早期实践者进行分享，还汇集了最近备受关注的热门事件，尽可能为读者同步 AIGC 领域的第一手信息！识别下图二维码，即可获取电子刊！

7 月 21 日即将开幕的深圳 ArchSummit 架构师峰会后，我们特别策划了深度培训，如果你对大模型开发相关内容感兴趣，欢迎关注培训：《基于大模型的私有知识应用开发》。

扫码或点击「阅读原文」，可查看培训详情，咨询购票可联系票务经理瑞丽：18514549229（微信同手机号）

读者福利