为什么说 GPT 利好程序员

半年来，ChatGPT (基于 GPT 架构开发的大型语言模型) 彻底颠覆了人们对人工智能的认识，给很多行业都带来了前所未有的冲击。尤其在编码方面，能轻而易举地写出俄罗斯方块、贪吃蛇、1024 等小游戏，能写出电影推荐等可上线的应用程序。在出色完成编码任务的同时，编码质量和效率都让人震撼。以至于很多人开始焦虑，觉得程序员离下岗不远了。为了了解其能力，我深入体验了一回。惊奇地发现，GPT 十分利好程序员，尤其利好程序员。

这篇文章记录了我的体验、观察和对未来的预测，希望与大家分享交流。

GPT 编程初体验

一直想用 GPT 写点代码，感受一下它的编程能力是不是像传说的那样神乎其技，但一直不知道要做点什么，直到百度文心一言发布。

文心一言发布后，测试版界面的水印技术引起了我极大的兴趣。再加上想体验 GPT 写代码的能力，一拍即合，所以借助它的能力，编程实现了类似文心一言界面的 Web 数字水印效果，并部署在了我的网站上。

在做这件事之前，定下了三个目标：

  1. 只写描述，让 GPT 写代码。
  2. 不使用搜索引擎。
  3. 录屏记录整个过程。

结果，GPT 出色地完成了任务，写了 98% 的代码。整个过程都没有使用过搜索引擎。

整个过程也被我记录下来了，主要编程内容包括：

  1. 实现水印效果
  2. 水印防删除增强
  3. 重构代码
  4. 部署到 Github Page 上

录屏也上传在哔哩哔哩上，有兴趣的同学可以去看看。

注：是的，你没有理解错，之前水印去除挑战赛的程序就是 GPT 写的。它告诉我已经做的完美无瑕了，结果很多同学参与比赛并获得了奖金。这说明神奇的工具，在某些人的手里，发挥的作用也很有限，所以完全没有必要焦虑。而且在前端专家面前，Web 数字水印本身就是一个笑话。玩可以，但不推荐用在项目上。

观察

自然语言写代码

自然语言是人类最重要的交流方式，用自然语言人机交互一直是软件开发努力的方向。GPT 的出现，使得用自然语言写代码成为现实。在完成上述 Web 数字水印网站的过程中，我全程用自然语言沟通和引导，GPT 成功理解并写出了符合我预期的代码，并部署到了线上。

下面是我输入的有效信息，我用它实现了类似文心一言界面的 Web 数字水印效果。前面的输入比较具体，过程化，越到后面使用的描述越抽象。

标题：水印的 GPT 文本

创建一个 div (id = eb-watermark) 并将它加到 body 里， 创建一个方法来包裹上述代码，导出这个方法作为 default， 导入 watermark 方法，并运行它。

添加样式到这个 div，样式是 XXX， 添加 shadow-root 到这个 div， 在 shadow root 底下，有一个div，div 是 XXX。

把这些代码抽成一个方法，使用 left 和 top 作为参数， 根据窗口大小创建 left 和 top 的坐标位置，我需要更多的元素充满整个窗口，生成更多的坐标位置。 元素太多了，减少一半。

监听 div id = eb-watermark, 当它的属性改变或者删除时，重新创建它。 测试了，它不能工作，帮我修复。 测试了，它还不工作，我想调试，应该怎么做？ 当样式改变后，它不工作，帮我修复。

保持现有逻辑，当 shadow-root 的子元素被删除或者修改后，重新创建父 div（id=eb-watermark）。 测试了，它不能工作，帮我修复。

保持现有逻辑，监控 innerText 的改变，重新创建水印， 监控 characterData。

修复错误， 检测父元素的父元素。

当窗口大小改变时，重新创建元素。

格式化代码， 重构代码， 这个方法太长了，重构它。

你是一个有 30 年工作经验的前端资深程序员，重构它。

这是一个 React 的程序，请改成 React 的方式 (没有接受)。

怎么使用 Github Action 把这个 React 应用部署到 Github Static Page 上。 Github page 是空白的，那里错了，修复它。

试想想，如果以后我们的源代码是一篇文章，那可读性多好呀。但是你如果将上面的信息直接输入到 GPT 里，它并不能生成我预期的代码。如果在特定的时间，在得到 GPT 输出之后，一步一步地来，恰好每一步都像我视频中的时序一样，那就一定可以做到。

这让我想到了乐谱，虽然乐理简单，但不是每个人都能创作出脍炙人口的歌曲。这让我想到了文章，虽然常用字只有 3500 个，但不是每个人都能写出引人入胜的小说。常说计算机程序设计是一门艺术，没有乐感，没有灵感，但我感觉有了 GPT，成为艺术家就多了一条路。

TDD，你的春天又来了！

先讲一个笑话：

有个程序员去面试，简历里写着自己心算超快。面试官很好奇，问他有多快。程序员自信地说：“秒杀！”，面试官想考验他一下，就问：“17乘以81等于多少？”。程序员秒答：“1377！”。 面试官算了一下，不对啊！程序员嘿嘿一笑：“虽然不对，但是我快呀！”。面试官一看，这哥们儿心思活，还这么快，果断录用了！

GPT 就是这样一位算的很快，但不保证算的对的程序员。也是一位就算对了，但是自己不知道自己算对了的程序员（是的，17x81=1377）。在要求 GPT 重构时，它不止一次的改挂功能，同时引入新的错误。

和这样的程序员合作，验证或保证代码的正确性变得尤为重要。那么 TDD 就是一个很好的解决方案。

分解任务，列 Task，写测试，然后让 GPT 按要求写出实现。这样，整个代码库中，测试成了唯一需要程序员关心的部分。有 GPT 夹持，TDD 会焕发生机。

人机结对编程

在过去的 20 年中，结对编程在软件工程实践中的好处被多次验证。GPT 这种交互式的工作方式，使得人机结对编程成为现实。在大多数情况下，和 GPT 结对编程的效果会大过和人结对编程。主要的优点有：

  • 和 GPT 编程直接简单，没有心理压力。我见过很多程序员，自己一个人写代码又快又好，和别人结对编程时，紧张的手足无措，真实实力发挥不出来。
  • GPT 拥有海量知识库和代码库，这是任何人类都做不到的。站在 GPT 的肩上，你就是巨人。
  • GPT 可以在一定程度上避免程序员的主观误判和主观偏见，从而提高代码质量和安全性。

人机结对编程势必会成为智能时代程序员的常态。

程序员不会失业

为什么法律都写在书里了，打官司还要律师？ —— 知乎问题

像 Fred Brooks 在《No Silver Bullet-Essence and Accident in Software Engineering》中描述的那样，从分析需求到拆解任务这种根本性困难，并不存在任何简单的解决方案。过去几十年中，用来解决软件工程中复杂性问题的方法，如更好的程序设计语言、更好的工具和技术、更好的软件工程实践等，这些方法都只是”意外”（accident）而不是”本质”（essence）。基于意外数据训练的模型，仍然解决不了本质问题。所以我们完全不用焦虑。

从分析需求到拆解任务，这种软件工程中的大部头，仍然是我们的主战场。当然，在整个过程中，我不否认 GPT 可以提升效率、提供建议，但就是不能取代。

如果能丝滑地将业务拆成工序，那么你仍然是一个十分有竞争力的程序员。

如果能对新技术充满好奇，富有探索精神。程序员不但不会失业，而且会借助 GPT，活的更好。

需要更系统的学习

GPT 看似降低了门槛，其实把门槛累的更高了。就像 20 年前，学网络安全就比现在更容易，那个时候，多数网站都还不注重网络安全，到处都是漏洞，稍微了解些网络安全知识，就能发现几个漏洞。你发现一个，它给你堵上，你接着再发现，它再堵上。一来二去，兴趣和激情都有了，技术也会在攻防中逐渐成长起来。而现在呢，初学者想发现漏洞太难了。同理，当 GPT 张口就来，来了就能解决问题的时候，我们还会多问几个为什么吗？还有必要去学习它解决方法背后的原理吗？我在用 GPT 实现水印的过程中，遇到了好几处 bug，我只简单的告诉 GPT 去修复它，结果就被成功地修复了。这样看起来 GPT 无所不能，其实这个只是表象。

更深层的原因是，我有 JS 编程经验，就算不用 GPT，我也能找到 bug 并修复。当我让 GPT 把代码重构成 React 的方式之后，它完成了任务，看起来像 React 程序，也能运行。但是在删掉 DOM 后，发现程序挂了，由于我没有 React 方面的积累，我发现我根本问不出来接下来的问题，所以它也就不能帮我修复。这就要求使用者自己有 React 的编程经验，掌握点皮毛，像我一样，就问不出恰当的问题，当然就不能完成目标。

所以说，要用好 GPT，系统的学习反而更有必要。试想想，如果项目达到一定程度，GPT 每次都修不好某个 bug，而有没有人去系统的学习，这个项目要怎么办呢？

风口预测

一个新技术的诞生总要经过从默默无闻到无所不能，再被贬到一文不值的过程。在刚开始的时候，预测一下未来，其乐无穷！

追赶 GPT

OpenAI 从 2015 年 12 月成立，到 2021 年 4 月宣布推出 GPT-3.5，不过 6.5 年。GPT 使用的 Transformer 模型在 2017 年 6 月才被发布，这么算来，实际仅用了 5 年。5 年时间，追一追是能赶得上的。不止我一个这样想，GPT-3.5 出圈后，一大波公司宣布重金投入人工智能领域。谷歌、百度、阿里等也都发布了自家的大语言模型，一副欣欣向荣的繁忙景象，说实话，我是喜闻乐见的。

百度发布文心一言测试版后，正好遇上 GPT-4，两相比较，嘲讽声此起彼伏。我倒是很欣赏的，现在开始并不晚。不要让芯片被扼喉的悲剧再次上演，应当是我们每个技术人追求的目标。

深度整合

ChatGPT 是最火的那个 GPT 的实例，在 OpenAI 发布 API 后，一大波程序员开始将其集成到自己的应用中，比如微软发布的 Window Copilot，Github 的 Copilot X。OpenAI 也看到了其广泛的应用前景，紧接着推出有应用商店之称的 ChatGPT plugins，给应用接入提供了便利。如何将现有应用和服务智能化，深度整合会是近几年各行业需要面对和解决的问题。

人机交互模式

鉴于 GPT 出色的自然语言理解能力，自然语言交互在各个方面有了新的机会。技术更新需要人们不断的学习。就像搜索引擎出现之后，虽然内容网上都有，但是很多人还是搜不到，信息差一直都存在，需要长期的练习。同样，和 GPT 交流的方式，方法，都需要不断的练习，学习。现在一大波 awesome-prompt 项目出现，如果不去看看，自己真的想不到。

更高级的编程语言

从机器语言到汇编，到 C，C++，Java 和 Python 等高级语言，再到现代编程语言，人们一直在追求用更高级，更抽象的语言和机器交流。自然语言是最高级的语言了，但是由于存在二义性、模糊性，一直不能做为编程语言。这一次，GPT 将自然语言翻译成高级语言，就像 C 被编译成汇编语言一样。不同的是，C 到汇编的编译器是固定的，而 GPT 翻译的时候，却需要人来交流和监督，很难写成固定的编译器或者翻译器，这里就是新的编程语言诞生的机会。我能预见的更高级的编程语言，就类似于伪代码那样，在自然语言的基础上，消除二义性和模糊性。会更加声明式，更加领域化。

版权问题

随着 GPT 模型在各个领域的应用越来越广泛，出现版权问题的可能性也越来越大。为了避免版权问题，使用 GPT 模型时需要注意保护知识产权，遵守相关法律法规，尊重他人版权。同时，也应该尽量避免使用版权保护的数据集和预训练模型，避免侵犯他人的知识产权。

在一些必须使用 GPT 模型的场景中，需要保证版权不被侵犯。版权问题是一个值得关注的话题，保护知识产权是保证持续创新的根本。

语音助手

Siri 最初于 2011 年在 iPhone 4S 上推出，至今 12 年了。我也是从 iPhone 4S 开始使用智能手机的，但我几乎没怎么用过 Siri，因为一直没有遇到过有用的场景。直到这次使用 GPT 来编程的时候，我发现和 GPT 的响应速度相比，我打字的速度实在是太慢了，好几次都有说话的冲动。我想，语音助手的王炸应用场景来了。

后记

由于录了屏，后来又剪辑了一周，发现了很多之前没有发现的问题，收获还是很大的。后来又发现社区里很多人做的更好，比如使用 GPT 分析需求，列 Task，写测试代码，再写实现。这都是我没有做到的，大家可以尝试一番。

我在 3 月 16 日有用 GPT 做水印的想法，在 3 月 19 日并付诸行动录了屏。剪视频花了一周，在 3 月 25 日将视频传到 Bilibili 上，同时有了本文的大纲，但是直到 4 月 10 日才写完。读了两遍发现并不怎么好，但还是发出来。

如果你喜欢这篇文章，欢迎赞赏作者以示鼓励